From nobody Tue Apr 4 05:33:35 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153FF129677; Tue, 4 Apr 2017 05:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-Y-BRPb2s64; Tue, 4 Apr 2017 05:33:31 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3332129673; Tue, 4 Apr 2017 05:33:31 -0700 (PDT) Received: from [192.168.1.10] (unknown [119.95.45.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 290461801581; Tue, 4 Apr 2017 14:33:24 +0200 (CEST) From: Loa Andersson To: "mpls@ietf.org" , idr@ietf.org, BESS Cc: "mpls-chairs@ietf.org" , bess-chairs@ietf.org, idr-chairs@ietf.org, "" , draft-ietf-mpls-rfc3107bis@ietf.org Message-ID: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> Date: Tue, 4 Apr 2017 20:33:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:33:34 -0000 Working Groups, This is to initiate a two week working group last call in four working groups on draft-ietf-mpls-rfc3107bis-01. According to agreement when we decided to host this document in the MPLS working group, this last call is also copied to the IDR and BESS working groups. Please send your comments to the mpls wg mailing list (mpls@ietf.org), if you are not subscribed to the mpls wg list, send to "your own" working group mailing list, and we'll make sure they are posted to the MPLS wg list. There are no IPR disclosures against this document. All the authors and contributors have stated on the working group mailing list that they are not aware of any other IPRs that relates to this document. This working group last call ends April 20, 2017. /Loa MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 4 14:37:39 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A16E124D37; Tue, 4 Apr 2017 14:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqhmNWig26ET; Tue, 4 Apr 2017 14:37:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8F71296EA; Tue, 4 Apr 2017 14:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43998; q=dns/txt; s=iport; t=1491341853; x=1492551453; h=from:to:cc:subject:date:message-id:mime-version; bh=Cw+uMb+Cn6uaxFlZdhFZWITKbiR44NYyKM3VHyyiUqA=; b=LABjeDdmPUEmQJThbOm8jcarr1gYQvARRKYMRvht8v3fDgrmEvoH/9df oQzBNjoOEvmxCDqKL3g1I6RFnNYuP9RjoTML8LTY/yii1xsYqZnSpbcTd dXhLq5QBf8ewlURgO/6smGq2myGA0G+MzJ26Z9YxsuHX5JPFDj1zjo3TQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgAVEeRY/4MNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5mYYELB4NcihKnLoIOKoV4HIMpPxgBAgEBAQEBAQFrHQuFP1YSAQY?= =?us-ascii?q?6AQkCBDAnBA4ZiXoOj2CdXIImK4o9AQEBAQEBAQEBAQEBAQEBAQEBAQEZBYZOg?= =?us-ascii?q?gWKRC6CMQWPZ4YzhlMBiiaIKYF9hS6DWYY4k3QBHziBBVsVQREBhkd1AQGIDIE?= =?us-ascii?q?NAQEB?= X-IronPort-AV: E=Sophos;i="5.36,275,1486425600"; d="scan'208,217";a="407599147" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2017 21:37:32 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v34LbW0d002838 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 21:37:32 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 16:37:31 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 4 Apr 2017 16:37:31 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-bess-evpn-etree@ietf.org" CC: "bess-chairs@ietf.org" , "bess@ietf.org" , Thomas Morin Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09 Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+Q== Date: Tue, 4 Apr 2017 21:37:31 +0000 Message-ID: <8A9E130E-0A0C-4DE5-BB35-98EE3C305E4B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_8A9E130E0A0C4DE5BB3598EE3C305E4Bciscocom_" MIME-Version: 1.0 Archived-At: Subject: [bess] AD Review of draft-ietf-bess-evpn-etree-09 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:37:38 -0000 --_000_8A9E130E0A0C4DE5BB3598EE3C305E4Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpJIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAg SW4gZ2VuZXJhbCwgdGhlIGRvY3VtZW50IGNvdWxkIGJlbmVmaXQgZnJvbSBhbiBlZGl0b3JpYWwg cGFzcyB0byBpbXByb3ZlIHJlYWRhYmlsaXR5OyBJIHB1dCBpbiBzb21lIHN1Z2dlc3Rpb25zIGJl bG93LCBidXQgSeKAmW0gc3VyZSBJIGRpZG7igJl0IG1lbnRpb24gYWxsLiAgSSBkb27igJl0IHRo aW5rIHRoYXQgbXkgY29tbWVudHMgKGV2ZW4gdGhlIE1ham9yIG9uZXMpIHdpbGwgYmUgaGFyZCB0 byByZXNvbHZlIOKAkyBtb3N0IGFyZSBhcm91bmQgcHJvdmlkaW5nIGNsYXJpdHkgYW5kIGNvbnNp c3RlbmN5LiAgSeKAmWxsIHdhaXQgZm9yIGEgcmV2aXNlZCBkcmFmdCBiZWZvcmUgc3RhcnRpbmcg dGhlIElFVEYgTGFzdCBDYWxsLg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KDQoNCk1ham9yOg0K DQpNMS4gQm90aCB0aGUgSW50cm9kdWN0aW9uIGFuZCB0aGUgQWJzdHJhY3QgbWVudGlvbiB0aGF0 IOKAnHRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGhvdyB0aGUgZnVuY3Rpb25hbCByZXF1aXJlbWVu dHMgZm9yIEUtVHJlZSBzZXJ2aWNlIGNhbiBiZSBlYXNpbHkgbWV04oCm4oCdICBJdCBzZWVtcyB0 byBtZSB0aGF0IFJGQzczODcgaXMgdXNlZCBhcyB0aGUgYnVpbGRpbmcgYmxvY2sgZm9yIHRoaXMg ZG9jdW1lbnQuICBXaHkgaXMgaXQgbm90IGEgTm9ybWF0aXZlIHJlZmVyZW5jZT8NCg0KDQpNMi4g VGhlcmUgaXMgbm8gcmVmZXJlbmNlIHRvIEUtVHJlZS4gIFBsZWFzZSBhZGQgYSBOb3JtYXRpdmUg b25lLg0KDQoNCk0zLiBJbiBTZWN0aW9uIDIuMiAoU2NlbmFyaW8gMjogTGVhZiBPUiBSb290IHNp dGUocykgcGVyIEFDKTog4oCc4oCmdGhlbiBhIHNpbmdsZSBSVCBwZXIgRVZJIE1BWSBiZSB1c2Vk 4oCm4oCdICBJIHRoaW5rIHRoYXQg4oCcTUFZ4oCdIGlzIG91dCBvZiBwbGFjZSBiZWNhdXNlIGl0 IHNlZW1zIHRvIGJlIGV4cHJlc3NpbmcganVzdCBhIGZhY3QuICBBbHNvLCBwbGVhc2Uga2VlcCB0 aGUgbm9ybWF0aXZlIGxhbmd1YWdlIHdoZXJlIHRoZSBvcGVyYXRpb24gaXMgZGVmaW5lZCAoaW4g dGhpcyBjYXNlIGluIDMuMSkuDQoNCg0KTTQuIFNlY3Rpb24gMy4xIChLbm93biBVbmljYXN0IFRy YWZmaWMpIHRhbGtzIGFib3V0IGhvdyBpbiB0aGUg4oCcbXVsdGktaG9taW5nIHNjZW5hcmlvIG9m IHNlY3Rpb24gMi4y4oCmdGhlIFBFIE1BWSBhZHZlcnRpc2UgbGVhZiBpbmRpY2F0aW9uIGFsb25n IHdpdGggdGhlIEV0aGVybmV0IEEtRCBwZXIgRVZJIHJvdXRl4oCdLiAgR2l2ZW4gdGhhdCB0aGUg dGV4dCBsYXRlciBzYXlzIHRoYXQg4oCcaW4gY2FzZSBvZiBkaXNjcmVwYW5jeSwgdGhlIG11bHRp LWhvbWluZyBmb3IgdGhhdCBwYWlyIG9mIFBFcyBpcyBhc3N1bWVkIHRvIGJlIGluIGRlZmF1bHQg InJvb3QiIG1vZGXigJ0sIEkgZmluZCB0aGUg4oCcTUFZ4oCdIG5vdCBzdWZmaWNpZW50LiAgSWYg d2Ugd2FudCB0byBwcmV2ZW50IGFzIG1hbnkgZGlzY3JlcGFuY2llcyBhcyBwb3NzaWJsZSwgc2hv dWxkbuKAmXQgdGhhdCBiZSBhIOKAnFNIT1VMROKAnSAob3IgZXZlbiBhIOKAnE1VU1TigJ0pPyAg IEdpdmVuIHRoZSBsb2NhbCBjb25maWd1cmF0aW9uLCB3aHkgd291bGQgdGhlIFBFIG5vdCB3YW50 IHRvIGluY2x1ZGUgdGhlIGxlYWYgaW5kaWNhdGlvbuKApmV2ZXLigKY/DQoNCg0KTTUuIEluIFNl Y3Rpb24gNS4xIChFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5KSB0aGVyZSBpcyByZWR1bmRhbnQg aW5mb3JtYXRpb24gKGZpcnN0IGFuZCBsYXN0IHBhcmFncmFwaHMpLiAgQW1vbmcgdGhhdCByZWR1 bmRhbnQgaW5mb3JtYXRpb24gdGhlcmUgaXMgbm8gY29uc2lzdGVuY3k6IOKAnHRoZSBMZWFmIExh YmVsIGZpZWxkIGlzIHNldCB0byBhIHZhbGlkIE1QTFMgbGFiZWzigJ0gYW5kIOKAnHRoZSBMZWFm IExhYmVsIE1VU1QgYmUgc2V0IHRvIGEgdmFsaWQgTVBMUyBsYWJlbOKAnSDigJMgcGxlYXNlIGJl IGNvbnNpc3RlbnQgYW5kIHNwZWNpZnkgdGhpbmdzIGp1c3Qgb25jZS4NCg0KTTUuMS4gQlRXLCB0 aGF0IGlzIGEg4oCcdmFsaWQgTVBMUyBsYWJlbOKAnT8gIEhvdyB3b3VsZCBhIHJlY2VpdmVyIHJl Y29nbml6ZSBpdD8gIFBsZWFzZSBhZGQgYSByZWZlcmVuY2UgdG8gYXZvaWQgY29uZnVzaW9uLg0K DQoNCk02LiBEZWZpbml0aW9uIG9mIHRoZSBFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5DQoNCk02 LjEuIE9ubHkgb25lIEZsYWcgaXMgZGVmaW5lZC4gIFdoYXQgYWJvdXQgdGhlIG90aGVycz8gIFBs ZWFzZSBzZXQgdXAgYSByZWdpc3RyeS4NCg0KTTYuMi4gW01pbm9yXSBQbGVhc2UgcHV0IGEgRmln dXJlIG51bWJlciBhbmQgaGVhZGluZyBmb3IgdGhlIGNvbW11bml0eSBmb3JtYXQuDQoNCk02LjMu IEl0IGxvb2tzIGxpa2UgdGhlIFJlc2VydmVkIGZpZWxkcyBhcmUgc2V0IHRvIDAuICBXaGF0IHNo b3VsZCBoYXBwZW4gaWYgdGhlIHJlY2VpdmVyIGdldHMgc29tZXRoaW5nIGVsc2U/DQoNCk02LjQu IOKAnOKApnRoZSBMZWFmLUluZGljYXRpb24gZmxhZyBNVVNUIGJlIHNldCB0byBvbmUgYW5kIExl YWYgTGFiZWwgaXMgc2V0IHRvIHplcm8uIFRoZSByZWNlaXZlZCBQRSBzaG91bGQgaWdub3JlIExl YWYgTGFiZWwgYW5kIG9ubHkgcHJvY2Vzc2VzIExlYWYtSW5kaWNhdGlvbiBmbGFnLuKAnSAgV2hh dCBpZiB0aGUgTGVhZiBMYWJlbCBpcyBub3Qgc2V0IHRvIHplcm8/ICBUaGUgc2Vjb25kIHNlbnRl bmNlIHNheXMgdG8gaWdub3JlIGl0LCBidXQgdGhlIGZpcnN0IG9uZSB0aGF0IGl0IOKAnE1VU1Qg YmXigKZzZXQgdG8gemVyb+KAnS4gIFdoaWNoIG9uZSBpcyBpdD8gIE1heWJlIGJvdGjigKYgIEJl IHNwZWNpZmljIQ0KDQpNNi41LiDigJzigKZ0aGUgTGVhZiBMYWJlbCBNVVNUIGJlIHNldCB0byBh IHZhbGlkIE1QTFMgbGFiZWwgYW5kIHRoZSBMZWFmLUluZGljYXRpb24gZmxhZyBzaG91bGQgYmUg c2V0IHRvIHplcm8uIFRoZSByZWNlaXZlZCBQRSBzaG91bGQgaWdub3JlIHRoZSBMZWFmLUluZGlj YXRpb24gZmxhZy7igJ0gIFNpbWlsYXIgcXVlc3Rpb24gZm9yIHRoZSBMZWFmLUluZGljYXRpb24g Yml0Lg0KDQpNNi42LiDigJxBIG5vbi12YWxpZCBNUExTIGxhYmVsIHdoZW4gc2VudCBhbG9uZyB3 aXRoIHRoZSBFdGhlcm5ldCBBLUQgcGVyIEVTIHJvdXRlLCBzaG91bGQgYmUgbG9nZ2VkIGFzIGFu IGVycm9yLuKAnSAgSeKAmW0gYXNzdW1pbmcgdGhhdCBub3Qgb25seSB0aGUgbG9nZ2luZyBpcyBu ZWVkZWQsIGJ1dCBpcyB0aGUgcm91dGUgaWdub3JlZC9kaXNjYXJkZWQgdG9vPw0KDQoNCk03LiBU aGUgUE1TSSBUdW5uZWwgQXR0cmlidXRlOiAgUGxlYXNlIGJlIGNsZWFyIHRvIHRoZSBmYWN0IHRo YXQgdGhlIEMgYml0IGlzIGJlaW5nIGRlZmluZWQvaW50cm9kdWNlZCBpbiB0aGlzIGRvY3VtZW50 IChhbmQgbm90IGp1c3Qgc3RhcnQgdGFsa2luZyBhYm91dCBpdCBhcyBpZiBpdCBpcyB3ZWxsLWtu b3duIHRvIGV2ZXJ5IHJlYWRlcikuDQoNCk03LjEuIEl0IGlzIG5vdCBjbGVhciB0byBtZSBob3cg dGhlIEMgYml0IGlzIHRvIGJlIHVzZWQuICBTZWN0aW9uIDUuMiBzYXlzIHRoYXQg4oCcdGhlIGhp Z2gtb3JkZXIgYml0IG9mIHRoZSB0dW5uZWwgdHlwZSBmaWVsZCAoQyBiaXQgLSBDb21wb3NpdGUg dHVubmVsIGJpdCkgaXMgc2V0IHdoaWxlIHRoZSByZW1haW5pbmcgbG93LW9yZGVyIHNldmVuIGJp dHMgaW5kaWNhdGUgdGhlIHR1bm5lbCB0eXBlIGFzIGJlZm9yZS7igJ0gICBCdXQgMy4zLjEgc2F5 cyB0aGF0IHRoZSDigJxuZXcgY29tcG9zaXRlIHR1bm5lbCB0eXBlIGlzIGFkdmVydGlzZWQgYnkg dGhlIHJvb3QgUEUgdG8gc2ltdWx0YW5lb3VzbHkgaW5kaWNhdGUgYSBQMk1QIHR1bm5lbCBpbiB0 cmFuc21pdCBkaXJlY3Rpb24gYW5kIGFuIGluZ3Jlc3MtcmVwbGljYXRpb24gdHVubmVsIGluIHRo ZSByZWNlaXZlIGRpcmVjdGlvbuKApuKAnS4gIEtub3dpbmcsIGZyb20gNS4yIHRoYXQgd2hlbiB0 aGUgQyBiaXQgaXMgc2V0IOKAnFR1bm5lbCBUeXBlc+KApjB4MDYgJ0luZ3Jlc3MgUmVwbGljYXRp b24nIGlzIGludmFsaWTigJ0sIHRoZW4gZG9lcyB0aGUgQyBiaXQgaGF2ZSBhIHNldCBtZWFuaW5n IG9yID8/PyAgIFtCVFcsIHMvaXMvYXJlXQ0KDQpNNy4yLiBbTWlub3JdIEluIHNvbWUgcGxhY2Vz IHlvdSB0YWxrIGFib3V0IHRoZSDigJxDIGJpdOKAnSBvciDigJxDb21wb3NpdGUgdHVubmVsIGJp dOKAnSwgYnV0IGxhdGVyIG1lbnRpb24gdGhlIOKAnENvbXBvc2l0ZSBmbGFn4oCdLiAgSeKAmW0g YXNzdW1pbmcgaXQgaXMgdGhlIHNhbWUgdGhpbmcg4oCTIHBsZWFzZSBiZSBjb25zaXN0ZW50IQ0K DQpNNy4zLiDigJxpbnZhbGlkIHR1bm5lbCB0eXBl4oCdICBSRkM2NTE0IHRhbGtzIGFib3V0IGFu IOKAnHVuZGVmaW5lZCB0dW5uZWwgdHlwZeKAnS4gIERvIHlvdSBtZWFuIHRoZSBzYW1lIHRoaW5n PyAgSWYgeW91IGRvLCBwbGVhc2UgdXNlIHRoZSByaWdodCB0ZXJtaW5vbG9neSBhbmQgcHV0IGEg cmVmZXJlbmNlIHRvIHJmYzY1MTQgaGVyZSB0byByZW1pbmQgcGVvcGxlIHdoZXJlIHRoZSBhY3Rp b24gaXMgZGVmaW5lZC4NCg0KDQpNOC4gU2VjdGlvbiA4LjEgKENvbnNpZGVyYXRpb25zIGZvciBQ TVNJIFR1bm5lbCBUeXBlcykuDQoNCk04LjEuIFdoYXQgc2hvdWxkIHRoZSBuYW1lIG9mIHRoZSBi aXQgYmU/ICBDIGJpdCwg4oCcY29tcG9zaXRlIHR1bm5lbHPigJ0gb3Ig4oCcQ29tcG9zaXRlIHR1 bm5lbCBiaXTigJ0g4oCTIGFsbCAzIHZlcnNpb25zIGFyZSB1c2VkLCBhbmQgSUFOQSB3aWxsIHdh bnQgc3BlY2lmaWMgZGlyZWN0aW9ucy4NCg0KTTguMi4g4oCc4oCmYnkgcmVtb3ZpbmcgdGhlIGVu dHJpZXMgZm9yIDB4RkItMHhGRSBhbmQgMHgwRuKAnSAgVGhlIHJhbmdlIGJldHdlZW4gMHg4MC0w eEZBIGFsc28gbmVlZHMgdG8gYmUgY2hhbmdlZC91cGRhdGVkLiAgcy8weDBGLzB4RkYuICBJdCBt YXkgYmUgY2xlYXJlciB0byB3cml0ZSB0aGF0IHRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGUgcmFu Z2UgMHg4MC0weEZGLg0KDQpNOC4zLiDigJzigKZhbmQgcmVwbGFjaW5nIHRoZW0gYnnigKbigJ0g ICBQbGVhc2UgZm9ybWF0IHRoZSB0YWJsZSBzbyB0aGF0IHNwYWNpbmcgaXMgYWxpZ25lZCAoZm9y IGJldHRlciBjbGFyaXR5IGZvciBJQU5BKS4gIEFsc28sIHBsZWFzZSBpbmNsdWRlIGluIGl0IGFs bCB0aGUgcmVhbGxvY2F0ZWQgc3BhY2U7IGZvciBleGFtcGxlOg0KDQogICBWYWx1ZSAgICAgICAg IE1lYW5pbmcgICAgICAgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlDQoweDBCLTB4N0EgICAg IFVuYXNzaWduZWQNCiAweDdCLTB4N0UgICAgIFJlc2VydmVkIGZvciBFeHBlcmltZW50YWwgVXNl ICAgW3RoaXMgZG9jdW1lbnRdDQoweDdGICAgICAgICAgIFJlc2VydmVkICAgICAgICAgICAgICAg ICAgICAgICAgW3RoaXMgZG9jdW1lbnRdDQoweDgwLTB4RkYgICAgIENvbXBvc2l0ZSBUdW5uZWxz ICAgICAgICAgICAgICAgW3RoaXMgZG9jdW1lbnRdDQoNCg0KTTguNC4gV2hhdCBpcyAweDdGIHJl c2VydmVkIGZvcj8gIEl0IGRvZXNu4oCZdCBzZWVtIHRvIGJlIHVzZWQgaW4gdGhpcyBkb2N1bWVu dC4gIFdoeSBhIGRpZmZlcmVudCByZWdpc3RyYXRpb24gcHJvY2VkdXJlPw0KDQoNCg0KDQpNaW5v cjoNCg0KUDEuIHMvYW5kIFJGQyBjYWxsZWQgIkEgRnJhbWV3b3JrIGZvciBFLVRyZWUgU2Vydmlj ZSBvdmVyIE1QTFMgTmV0d29yayIuL1JGQzczODcgKCJBIEZyYW1ld29yayBmb3IgRXRoZXJuZXQg VHJlZSAoRS1UcmVlKSBTZXJ2aWNlIG92ZXIgYSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGlu ZyAoTVBMUykgTmV0d29yayIpLg0KDQpQMi4gUGxlYXNlIGV4cGFuZCBFVlBOIG9uIGZpcnN0IHVz ZS4gIEkga25vdyB0aGF0IHRoaXMgaXMgYSB3ZWxsLWtub3duIHRlcm0g4oCTIHBsZWFzZSBjb25z aWRlciB0YWxraW5nIHRvIHRoZSBSRkMgRWRpdG9yIChvbmNlIHRoaXMgZG9jdW1lbnQgZ2V0cyB0 byB0aGVtKSBpbiBvcmRlciB0byBpbmNsdWRlIOKAnEVWUE7igJ0gaW4gdGhlIOKAnFJGQyBFZGl0 b3IgQWJicmV2aWF0aW9ucyBMaXN04oCdIFsxXS4NCg0KUDIuMS4gIFBsZWFzZSBhbHNvIGV4cGFu ZDogREYsIEJVTeKApg0KDQpbMV0gaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvbWF0ZXJpYWxz L2FiYnJldi5leHBhbnNpb24udHh0DQoNClAzLiBUaGUgYWJicmV2aWF0aW9uIGZvciBFdGhlcm5l dCBTZWdtZW50IGlzIGludHJvZHVjZWQgaW4gU2VjdGlvbiAzLjLigKZwbGVhc2UgaW50cm9kdWNl IGl0IG9uIGZpcnN0IG1lbnRpb24gKFNlY3Rpb24gMikgYXMgaXQgZ2V0cyB1c2VkIGJlZm9yZSAz LjIuICBBbHNvLCB0aGUgYWJicmV2aWF0aW9uIGZvciBBdHRhY2htZW50IENpcmN1aXQgaXMgaW50 cm9kdWNlZCBhZnRlciBBQyBoYXMgYmVlbiB1c2VkIHNldmVyYWwgdGltZXMuICBFQyBpcyB1c2Vk IHcvb3V0IGRlZmluaXRpb24uDQoNClA0LiDigJxFLVRSRUUgZm9yIFZQTFPigJ0gIFBsZWFzZSBh ZGQgYW4gSW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHJmYzc3OTYuDQoNClA1LiDigJzigKZuZXcg QkdQIEV4dGVuZGVkIENvbW11bml0eSBmb3IgbGVhZiBpbmRpY2F0aW9uIGFzIHNob3duIGxhdGVy IGluIHRoaXMgZG9jdW1lbnQu4oCdICBQbGVhc2UgaW5jbHVkZSBhIGZvcndhcmQgcmVmZXJlbmNl IHRvIFNlY3Rpb24gNS4xLg0KDQpQNi4g4oCcTUFDIG1vYmlsaXR5IHByb2NlZHVyZXPigJ0gIFdo YXQgYXJlIHRob3NlPyAgUGxlYXNlIGFkZCBhIHJlZmVyZW5jZS4NCg0KUDcuIFNlY3Rpb24gMy4y LjEgKEJVTSB0cmFmZmljIG9yaWdpbmF0ZWQgZnJvbSBhIHNpbmdsZS1ob21lZCBzaXRlIG9uIGEg bGVhZiBBQykgc3RhcnRzIGJ5IHRhbGtpbmcgYWJvdXQg4oCcYSBzcGVjaWFsIE1QTFMgbGFiZWzi gJ0g4oCTIGV2ZW4gdGhvdWdoIHRoZXJl4oCZcyBhIHJlZmVyZW5jZSBsYXRlciB0byA1LjEsIHBs ZWFzZSBiZSBleHBsaWNpdCAod3JpdGluZyBzb21ldGhpbmcgbGlrZSB0aGlzKTog4oCcdGhlIFBF IGFkZHMgdGhlIExlYWYgTGFiZWwgYWR2ZXJ0aXNlZCB1c2luZyB0aGUgRS1UcmVlIEV4dGVuZGVk IENvbW11bml0eSAoU2VjdGlvbiA1LjEp4oCdLiAgICAgU2ltcGxpZnlpbmcgdGhlIHRleHQgd2ls bCBnbyBhIGxvbmcgd2F5IHRvIG1ha2luZyBpbXBsZW1lbnRhdGlvbiBlYXNpZXIuDQoNClA4LiDi gJxJUkIgdXNlIGNhc2UgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC7igJ0g IEFuIEluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLWJlc3MtZXZwbi1pbnRlci1z dWJuZXQtZm9yd2FyZGluZyB3b3VsZCBiZSBuaWNlLg0KDQpQOS4gSXQgd291bGQgYmUgbmljZSB0 byBpbmNsdWRlIGEg4oCcbWFw4oCdIG9mIHRoZSBkb2N1bWVudCBpbiB0aGUgSW50cm9kdWN0aW9u OiAoc29tZXRoaW5nIGxpa2UpIOKAnFNlY3Rpb24gMiB0YWxrcyBhYm91dCBibGFo4oCmU2VjdGlv biAzIGRlZmluZXPigKbigJ0uDQoNClAxMC4gcy9FVlBOIE1BQyBBZHZlcnRpc2VtZW50IHJvdXRl L01BQy9JUCBBZHZlcnRpc2VtZW50IFJvdXRlICAgICBQbGVhc2UgYmUgc3BlY2lmaWMhDQoNClAx MS4g4oCcVG8gc3VwcG9ydCBtdWx0aWNhc3QvYnJvYWRjYXN0IGZyb20gUm9vdCB0byBMZWFmIHNp dGVzLCBlaXRoZXIgYSBQMk1QIHRyZWUgcm9vdGVkIGF0IHRoZSBQRShzKSB3aXRoIHRoZSBSb290 IHNpdGUocykgb3IgaW5ncmVzcyByZXBsaWNhdGlvbiBjYW4gYmUgdXNlZC7igJ0gIFJlZmVyZW5j ZXMgd291bGQgYmUgdmVyeSBuaWNlIQ0KDQpQMTIuIFNlY3Rpb24gNS4zIGRvZXNu4oCZdCBleGlz dC4NCg0KUDEzLiBCb3RoIFNlY3Rpb25zIDMgYW5kIDQgbWVudGlvbiB0aGUgc2FtZSB0aGluZ3Mg KG90aGVyIHRhZ2dpbmcgbWVjaGFuaXNtcyBhbmQgSVJCKSBvdXQgb2Ygc2NvcGUuICBJdCB3b3Vs ZCBiZSBuaWNlIHRvIG1lbnRpb24gY29tbW9uIHBpZWNlcyBvZiB0aGUgb3BlcmF0aW9uIGluIGEg c2luZ2xlIHBsYWNlLg0KDQpQMTQuIOKAnFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gbmV3IEJH UCBFeHRlbmRlZCBDb21tdW5pdHkgZm9yIEVWUE4u4oCdICBJIG9ubHkgc2VlIG9uZS4NCg0KUDE1 LiBBIE5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gcmZjNDM2MCBpcyBuZWVkZWQgaW4gNS4xLg0KDQpQ MTYuIFRoZXJl4oCZcyBubyBuZWVkIHRvIHRoZSByZWZlcmVuY2UgdG8gcmZjNzE1MyBiZWNhdXNl IHlvdeKAmXJlIHJlZmVycmluZyB0byB0aGUgcmVnaXN0cnkgaXRzZWxmLg0KDQpQMTcuIFRoZSAn VXBkYXRlczogJyBsaW5lIGluIHRoZSBkcmFmdCBoZWFkZXIgc2hvdWxkIGxpc3Qgb25seSB0aGUg X251bWJlcnNfIG9mIHRoZSBSRkNzIHdoaWNoIHdpbGwgYmUgdXBkYXRlZCBieSB0aGlzIGRvY3Vt ZW50IChpZiBhcHByb3ZlZCk7IGl0IHNob3VsZCBub3QgaW5jbHVkZSB0aGUgd29yZCAnUkZDJyBp biB0aGUgbGlzdC4NCg0KUDE4LiBUaGVyZSBpcyBubyByZWZlcmVuY2UgdG8gcmZjNTIyNi4NCg0K DQpOaXRzOg0KDQpOMS4gVGhlcmUgYXJlIGEgbG90IG9mIHZlcnkgbG9uZyBzZW50ZW5jZXPigKYg IEl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIGlkZWFzIHdlcmUgY29tcG9zZWQgc28gdGhhdCB0aGUg b3ZlcmFsbCBkb2N1bWVudCB3YXMgZWFzaWVyIHRvIHJlYWQuICBGb3IgYW4gZXhhbXBsZSwgdGFr ZSBhIGxvb2sgYXQgdGhlIGxhc3QgcGFyYWdyYXBoIGluIDIuMuKApiAgTm8gc3BlY2lmaWMgYWN0 aW9uIHJlcXVpcmVkIGhlcmUsIGJ1dCBpdCB3b3VsZCBiZSBuaWNlIHRvIGdpdmUgaXQgYW4gZWRp dGluZyBwYXNzLg0KDQpOMi4gcy8gZWFjaCBvZiBpdHMgTUFDL0lQIEFkdmVydGlzZW1lbnQgcm91 dGUvZWFjaCBvZiBpdHMgTUFDL0lQIEFkdmVydGlzZW1lbnQgcm91dGVzDQoNCk4zLiBBbm90aGVy IGV4YW1wbGUgb2Ygd2hlcmUgdGhlIHRleHQgaXMgbm90IGFzIGNsZWFyIGFzIGl0IGNvdWxkIGJl IGZvciBhIHNwZWNpZmljYXRpb24gaXMgU2VjdGlvbiAzLjIsIHdoZXJlIHRhZ2dpbmcgTVBMUyBm cmFtZXMgaXMgbWFuZGF0ZWQgKOKAnHRoZSBNUExTLWVuY2Fwc3VsYXRlZCBmcmFtZXMgTVVTVCBi ZSB0YWdnZWQgd2l0aCBhbiBpbmRpY2F0aW9uIHdoZW4gdGhleSBvcmlnaW5hdGVkIGZyb20gYSBM ZWFmIEFD4oCdKSwgYnV0IHRoZXJlIGlzIG5vIGluZGljYXRpb24gb24gaG93IHRvIGRvIHRoaXMg dW50aWwgMyBwYXJhZ3JhcGhzIGxhdGVyIOKAkyBhIHNlZW1pbmdseSB1bnJlbGF0ZWQgZGlzY3Vz c2lvbiBpcyBoZWxkIGluIGJldHdlZW7igKYNCg0KTjQuIOKAnHdl4oCdIGlzIHVzZWQgYSBjb3Vw bGUgb2YgdGltZXMgKG91dHNpZGUgdGhlIEFja25vd2xlZGdlbWVudHMpIOKAkyBwbGVhc2UgY2hh bmdlIHRoYXQgdG8g4oCcdGhpcyBkb2N1bWVudOKAnSAob3Igc29tZXRoaW5nIHNpbWlsYXIpLg0K DQpONS4gcy93aGVyZSBhbmQgRXRoZXJuZXQgU2VnbWVudC93aGVyZSBhbiBFdGhlcm5ldCBTZWdt ZW50DQoNCk42LiBzL2RyYWZ0L2RvY3VtZW50DQo= --_000_8A9E130E0A0C4DE5BB3598EE3C305E4Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQt d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIGF1 dGhvcnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGp1c3Qg ZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiZuYnNwOyBJbiBnZW5lcmFsLCB0aGUgZG9j dW1lbnQgY291bGQgYmVuZWZpdCBmcm9tIGFuIGVkaXRvcmlhbCBwYXNzIHRvIGltcHJvdmUgcmVh ZGFiaWxpdHk7IEkgcHV0IGluIHNvbWUgc3VnZ2VzdGlvbnMgYmVsb3csIGJ1dCBJ4oCZbSBzdXJl IEkgZGlkbuKAmXQgbWVudGlvbiBhbGwuJm5ic3A7IEkgZG9u4oCZdCB0aGluaw0KIHRoYXQgbXkg Y29tbWVudHMgKGV2ZW4gdGhlIE1ham9yIG9uZXMpIHdpbGwgYmUgaGFyZCB0byByZXNvbHZlIOKA kyBtb3N0IGFyZSBhcm91bmQgcHJvdmlkaW5nIGNsYXJpdHkgYW5kIGNvbnNpc3RlbmN5LiZuYnNw OyBJ4oCZbGwgd2FpdCBmb3IgYSByZXZpc2VkIGRyYWZ0IGJlZm9yZSBzdGFydGluZyB0aGUgSUVU RiBMYXN0IENhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbHZhcm8u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1ham9yOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTEuIEJvdGggdGhlIEludHJvZHVjdGlvbiBh bmQgdGhlIEFic3RyYWN0IG1lbnRpb24gdGhhdCDigJx0aGlzIGRvY3VtZW50IGRpc2N1c3NlcyBo b3cgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGZvciBFLVRyZWUgc2VydmljZSBjYW4gYmUg ZWFzaWx5IG1ldOKApuKAnSZuYnNwOyBJdCBzZWVtcyB0byBtZSB0aGF0IFJGQzczODcgaXMgdXNl ZCBhcyB0aGUgYnVpbGRpbmcNCiBibG9jayBmb3IgdGhpcyBkb2N1bWVudC4mbmJzcDsgV2h5IGlz IGl0IG5vdCBhIE5vcm1hdGl2ZSByZWZlcmVuY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTIuIFRoZXJlIGlzIG5v IHJlZmVyZW5jZSB0byBFLVRyZWUuJm5ic3A7IFBsZWFzZSBhZGQgYSBOb3JtYXRpdmUgb25lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPk0zLiBJbiBTZWN0aW9uIDIuMiAoU2NlbmFyaW8gMjogTGVhZiBPUiBSb290IHNp dGUocykgcGVyIEFDKTog4oCc4oCmdGhlbiBhIHNpbmdsZSBSVCBwZXIgRVZJIE1BWSBiZSB1c2Vk 4oCm4oCdJm5ic3A7IEkgdGhpbmsgdGhhdCDigJxNQVnigJ0gaXMgb3V0IG9mIHBsYWNlIGJlY2F1 c2UgaXQgc2VlbXMgdG8gYmUgZXhwcmVzc2luZyBqdXN0IGEgZmFjdC4mbmJzcDsgQWxzbywgcGxl YXNlIGtlZXANCiB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIHdoZXJlIHRoZSBvcGVyYXRpb24gaXMg ZGVmaW5lZCAoaW4gdGhpcyBjYXNlIGluIDMuMSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTQuIFNlY3Rpb24gMy4x IChLbm93biBVbmljYXN0IFRyYWZmaWMpIHRhbGtzIGFib3V0IGhvdyBpbiB0aGUg4oCcbXVsdGkt aG9taW5nIHNjZW5hcmlvIG9mIHNlY3Rpb24gMi4y4oCmdGhlIFBFIE1BWSBhZHZlcnRpc2UgbGVh ZiBpbmRpY2F0aW9uIGFsb25nIHdpdGggdGhlIEV0aGVybmV0IEEtRCBwZXIgRVZJIHJvdXRl4oCd LiZuYnNwOyBHaXZlbiB0aGF0IHRoZSB0ZXh0IGxhdGVyDQogc2F5cyB0aGF0IOKAnGluIGNhc2Ug b2YgZGlzY3JlcGFuY3ksIHRoZSBtdWx0aS1ob21pbmcgZm9yIHRoYXQgcGFpciBvZiBQRXMgaXMg YXNzdW1lZCB0byBiZSBpbiBkZWZhdWx0ICZxdW90O3Jvb3QmcXVvdDsgbW9kZeKAnSwgSSBmaW5k IHRoZSDigJxNQVnigJ0gbm90IHN1ZmZpY2llbnQuJm5ic3A7IElmIHdlIHdhbnQgdG8gcHJldmVu dCBhcyBtYW55IGRpc2NyZXBhbmNpZXMgYXMgcG9zc2libGUsIHNob3VsZG7igJl0IHRoYXQgYmUg YSDigJxTSE9VTETigJ0gKG9yIGV2ZW4gYSDigJxNVVNU4oCdKT8mbmJzcDsmbmJzcDsNCiBHaXZl biB0aGUgbG9jYWwgY29uZmlndXJhdGlvbiwgd2h5IHdvdWxkIHRoZSBQRSBub3Qgd2FudCB0byBp bmNsdWRlIHRoZSBsZWFmIGluZGljYXRpb27igKZldmVy4oCmPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk01LiBJbiBT ZWN0aW9uIDUuMSAoRS1UUkVFIEV4dGVuZGVkIENvbW11bml0eSkgdGhlcmUgaXMgcmVkdW5kYW50 IGluZm9ybWF0aW9uIChmaXJzdCBhbmQgbGFzdCBwYXJhZ3JhcGhzKS4mbmJzcDsgQW1vbmcgdGhh dCByZWR1bmRhbnQgaW5mb3JtYXRpb24gdGhlcmUgaXMgbm8gY29uc2lzdGVuY3k6IOKAnHRoZSBM ZWFmIExhYmVsIGZpZWxkIGlzIHNldCB0byBhIHZhbGlkDQogTVBMUyBsYWJlbOKAnSBhbmQg4oCc dGhlIExlYWYgTGFiZWwgTVVTVCBiZSBzZXQgdG8gYSB2YWxpZCBNUExTIGxhYmVs4oCdIOKAkyBw bGVhc2UgYmUgY29uc2lzdGVudCBhbmQgc3BlY2lmeSB0aGluZ3MganVzdCBvbmNlLiZuYnNwOw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNS4xLiBCVFcsIHRo YXQgaXMgYSDigJx2YWxpZCBNUExTIGxhYmVs4oCdPyZuYnNwOyBIb3cgd291bGQgYSByZWNlaXZl ciByZWNvZ25pemUgaXQ/Jm5ic3A7IFBsZWFzZSBhZGQgYSByZWZlcmVuY2UgdG8gYXZvaWQgY29u ZnVzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk02LiBEZWZpbml0aW9uIG9mIHRoZSBFLVRSRUUgRXh0ZW5kZWQg Q29tbXVuaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNi4x LiBPbmx5IG9uZSBGbGFnIGlzIGRlZmluZWQuJm5ic3A7IFdoYXQgYWJvdXQgdGhlIG90aGVycz8m bmJzcDsgUGxlYXNlIHNldCB1cCBhIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+TTYuMi4gW01pbm9yXSBQbGVhc2UgcHV0IGEgRmlndXJlIG51bWJl ciBhbmQgaGVhZGluZyBmb3IgdGhlIGNvbW11bml0eSBmb3JtYXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNi4zLiBJdCBsb29rcyBsaWtlIHRoZSBSZXNlcnZl ZCBmaWVsZHMgYXJlIHNldCB0byAwLiZuYnNwOyBXaGF0IHNob3VsZCBoYXBwZW4gaWYgdGhlIHJl Y2VpdmVyIGdldHMgc29tZXRoaW5nIGVsc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5NNi40LiDigJzigKZ0aGUgTGVhZi1JbmRpY2F0aW9uIGZsYWcgTVVTVCBi ZSBzZXQgdG8gb25lIGFuZCBMZWFmIExhYmVsIGlzIHNldCB0byB6ZXJvLiBUaGUgcmVjZWl2ZWQg UEUgc2hvdWxkIGlnbm9yZSBMZWFmIExhYmVsIGFuZCBvbmx5IHByb2Nlc3NlcyBMZWFmLUluZGlj YXRpb24gZmxhZy7igJ0mbmJzcDsgV2hhdCBpZiB0aGUgTGVhZiBMYWJlbCBpcyBub3Qgc2V0IHRv IHplcm8/Jm5ic3A7DQogVGhlIHNlY29uZCBzZW50ZW5jZSBzYXlzIHRvIGlnbm9yZSBpdCwgYnV0 IHRoZSBmaXJzdCBvbmUgdGhhdCBpdCDigJxNVVNUIGJl4oCmc2V0IHRvIHplcm/igJ0uJm5ic3A7 IFdoaWNoIG9uZSBpcyBpdD8mbmJzcDsgTWF5YmUgYm90aOKApiZuYnNwOyBCZSBzcGVjaWZpYyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk02LjUuIOKAnOKApnRo ZSBMZWFmIExhYmVsIE1VU1QgYmUgc2V0IHRvIGEgdmFsaWQgTVBMUyBsYWJlbCBhbmQgdGhlIExl YWYtSW5kaWNhdGlvbiBmbGFnIHNob3VsZCBiZSBzZXQgdG8gemVyby4gVGhlIHJlY2VpdmVkIFBF IHNob3VsZCBpZ25vcmUgdGhlIExlYWYtSW5kaWNhdGlvbiBmbGFnLuKAnSZuYnNwOyBTaW1pbGFy IHF1ZXN0aW9uIGZvciB0aGUgTGVhZi1JbmRpY2F0aW9uDQogYml0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTYuNi4g4oCcQSBub24tdmFsaWQgTVBMUyBsYWJl bCB3aGVuIHNlbnQgYWxvbmcgd2l0aCB0aGUgRXRoZXJuZXQgQS1EIHBlciBFUyByb3V0ZSwgc2hv dWxkIGJlIGxvZ2dlZCBhcyBhbiBlcnJvci7igJ0mbmJzcDsgSeKAmW0gYXNzdW1pbmcgdGhhdCBu b3Qgb25seSB0aGUgbG9nZ2luZyBpcyBuZWVkZWQsIGJ1dCBpcyB0aGUgcm91dGUgaWdub3JlZC9k aXNjYXJkZWQgdG9vPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk03LiBUaGUgUE1TSSBUdW5uZWwgQXR0cmlidXRlOiZu YnNwOyBQbGVhc2UgYmUgY2xlYXIgdG8gdGhlIGZhY3QgdGhhdCB0aGUgQyBiaXQgaXMgYmVpbmcg ZGVmaW5lZC9pbnRyb2R1Y2VkIGluIHRoaXMgZG9jdW1lbnQgKGFuZCBub3QganVzdCBzdGFydCB0 YWxraW5nIGFib3V0IGl0IGFzIGlmIGl0IGlzIHdlbGwta25vd24gdG8gZXZlcnkgcmVhZGVyKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk03LjEuIEl0IGlzIG5v dCBjbGVhciB0byBtZSBob3cgdGhlIEMgYml0IGlzIHRvIGJlIHVzZWQuJm5ic3A7IFNlY3Rpb24g NS4yIHNheXMgdGhhdCDigJx0aGUgaGlnaC1vcmRlciBiaXQgb2YgdGhlIHR1bm5lbCB0eXBlIGZp ZWxkIChDIGJpdCAtIENvbXBvc2l0ZSB0dW5uZWwgYml0KSBpcyBzZXQgd2hpbGUgdGhlIHJlbWFp bmluZyBsb3ctb3JkZXIgc2V2ZW4gYml0cyBpbmRpY2F0ZQ0KIHRoZSB0dW5uZWwgdHlwZSBhcyBi ZWZvcmUu4oCdJm5ic3A7Jm5ic3A7IEJ1dCAzLjMuMSBzYXlzIHRoYXQgdGhlIOKAnG5ldyBjb21w b3NpdGUgdHVubmVsIHR5cGUgaXMgYWR2ZXJ0aXNlZCBieSB0aGUgcm9vdCBQRSB0byBzaW11bHRh bmVvdXNseSBpbmRpY2F0ZSBhIFAyTVAgdHVubmVsIGluIHRyYW5zbWl0IGRpcmVjdGlvbiBhbmQg YW4gaW5ncmVzcy1yZXBsaWNhdGlvbiB0dW5uZWwgaW4gdGhlIHJlY2VpdmUgZGlyZWN0aW9u4oCm 4oCdLiZuYnNwOyBLbm93aW5nLCBmcm9tIDUuMiB0aGF0DQogd2hlbiB0aGUgQyBiaXQgaXMgc2V0 IOKAnFR1bm5lbCBUeXBlc+KApjB4MDYgJ0luZ3Jlc3MgUmVwbGljYXRpb24nIGlzIGludmFsaWTi gJ0sIHRoZW4gZG9lcyB0aGUgQyBiaXQgaGF2ZSBhIHNldCBtZWFuaW5nIG9yID8/PyZuYnNwOyZu YnNwOyBbQlRXLCBzL2lzL2FyZV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPk03LjIuIFtNaW5vcl0gSW4gc29tZSBwbGFjZXMgeW91IHRhbGsgYWJvdXQgdGhlIOKA nEMgYml04oCdIG9yIOKAnENvbXBvc2l0ZSB0dW5uZWwgYml04oCdLCBidXQgbGF0ZXIgbWVudGlv biB0aGUg4oCcQ29tcG9zaXRlIGZsYWfigJ0uJm5ic3A7IEnigJltIGFzc3VtaW5nIGl0IGlzIHRo ZSBzYW1lIHRoaW5nIOKAkyBwbGVhc2UgYmUgY29uc2lzdGVudCE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk03LjMuIOKAnGludmFsaWQgdHVubmVsIHR5cGXigJ0m bmJzcDsgUkZDNjUxNCB0YWxrcyBhYm91dCBhbiDigJx1bmRlZmluZWQgdHVubmVsIHR5cGXigJ0u Jm5ic3A7IERvIHlvdSBtZWFuIHRoZSBzYW1lIHRoaW5nPyZuYnNwOyBJZiB5b3UgZG8sIHBsZWFz ZSB1c2UgdGhlIHJpZ2h0IHRlcm1pbm9sb2d5IGFuZCBwdXQgYSByZWZlcmVuY2UgdG8gcmZjNjUx NCBoZXJlIHRvIHJlbWluZCBwZW9wbGUgd2hlcmUNCiB0aGUgYWN0aW9uIGlzIGRlZmluZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+TTguIFNlY3Rpb24gOC4xIChDb25zaWRlcmF0aW9ucyBmb3IgUE1TSSBUdW5uZWwg VHlwZXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTguMS4g V2hhdCBzaG91bGQgdGhlIG5hbWUgb2YgdGhlIGJpdCBiZT8mbmJzcDsgQyBiaXQsIOKAnGNvbXBv c2l0ZSB0dW5uZWxz4oCdIG9yIOKAnENvbXBvc2l0ZSB0dW5uZWwgYml04oCdIOKAkyBhbGwgMyB2 ZXJzaW9ucyBhcmUgdXNlZCwgYW5kIElBTkEgd2lsbCB3YW50IHNwZWNpZmljIGRpcmVjdGlvbnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NOC4yLiDigJzigKZi eSByZW1vdmluZyB0aGUgZW50cmllcyBmb3IgMHhGQi0weEZFIGFuZCAweDBG4oCdJm5ic3A7IFRo ZSByYW5nZSBiZXR3ZWVuIDB4ODAtMHhGQSBhbHNvIG5lZWRzIHRvIGJlIGNoYW5nZWQvdXBkYXRl ZC4mbmJzcDsgcy8weDBGLzB4RkYuJm5ic3A7IEl0IG1heSBiZSBjbGVhcmVyIHRvIHdyaXRlIHRo YXQgdGhpcyBkb2N1bWVudCB1cGRhdGVzIHRoZSByYW5nZSAweDgwLTB4RkYuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NOC4zLiDigJzigKZhbmQgcmVwbGFjaW5n IHRoZW0gYnnigKbigJ0mbmJzcDsmbmJzcDsgUGxlYXNlIGZvcm1hdCB0aGUgdGFibGUgc28gdGhh dCBzcGFjaW5nIGlzIGFsaWduZWQgKGZvciBiZXR0ZXIgY2xhcml0eSBmb3IgSUFOQSkuJm5ic3A7 IEFsc28sIHBsZWFzZSBpbmNsdWRlIGluIGl0IGFsbCB0aGUgcmVhbGxvY2F0ZWQgc3BhY2U7IGZv ciBleGFtcGxlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcyI+VmFsdWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTWVhbmluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWZlcmVuY2U8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+MHgwQi0weDdBJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFVuYXNzaWduZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsweDdCLTB4N0UmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzZXJ2ZWQgZm9yIEV4cGVyaW1lbnRhbCBVc2UmbmJzcDsg Jm5ic3A7W3RoaXMgZG9jdW1lbnRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPjB4N0YmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUmVzZXJ2ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW3RoaXMgZG9jdW1lbnRdPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjB4ODAtMHhGRiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBDb21wb3NpdGUgVHVubmVscyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBbdGhpcyBkb2N1bWVudF0mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk04LjQuIFdoYXQgaXMgMHg3RiByZXNlcnZlZCBmb3I/Jm5i c3A7IEl0IGRvZXNu4oCZdCBzZWVtIHRvIGJlIHVzZWQgaW4gdGhpcyBkb2N1bWVudC4mbmJzcDsg V2h5IGEgZGlmZmVyZW50IHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmU/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NaW5vcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlAxLiBzL2FuZCBSRkMgY2FsbGVkICZxdW90O0EgRnJhbWV3b3JrIGZvciBFLVRyZWUgU2Vydmlj ZSBvdmVyIE1QTFMgTmV0d29yayZxdW90Oy4vUkZDNzM4NyAoJnF1b3Q7QSBGcmFtZXdvcmsgZm9y IEV0aGVybmV0IFRyZWUgKEUtVHJlZSkgU2VydmljZSBvdmVyIGEgTXVsdGlwcm90b2NvbCBMYWJl bCBTd2l0Y2hpbmcgKE1QTFMpIE5ldHdvcmsmcXVvdDspLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UDIuIFBsZWFzZSBleHBhbmQgRVZQTiBvbiBmaXJzdCB1c2Uu Jm5ic3A7IEkga25vdyB0aGF0IHRoaXMgaXMgYSB3ZWxsLWtub3duIHRlcm0g4oCTIHBsZWFzZSBj b25zaWRlciB0YWxraW5nIHRvIHRoZSBSRkMgRWRpdG9yIChvbmNlIHRoaXMgZG9jdW1lbnQgZ2V0 cyB0byB0aGVtKSBpbiBvcmRlciB0byBpbmNsdWRlIOKAnEVWUE7igJ0gaW4gdGhlIOKAnFJGQyBF ZGl0b3IgQWJicmV2aWF0aW9ucw0KIExpc3TigJ0gWzFdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UDIuMS4mbmJzcDsgUGxlYXNlIGFsc28gZXhwYW5kOiBERiwg QlVN4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bMV0gPGEg aHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvbWF0ZXJpYWxzL2FiYnJldi5leHBhbnNp b24udHh0Ij4NCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhw YW5zaW9uLnR4dDwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5QMy4gVGhlIGFiYnJldmlhdGlvbiBmb3IgRXRoZXJuZXQgU2VnbWVudCBpcyBpbnRyb2R1Y2Vk IGluIFNlY3Rpb24gMy4y4oCmcGxlYXNlIGludHJvZHVjZSBpdCBvbiBmaXJzdCBtZW50aW9uIChT ZWN0aW9uIDIpIGFzIGl0IGdldHMgdXNlZCBiZWZvcmUgMy4yLiZuYnNwOyBBbHNvLCB0aGUgYWJi cmV2aWF0aW9uIGZvciBBdHRhY2htZW50IENpcmN1aXQgaXMgaW50cm9kdWNlZA0KIGFmdGVyIEFD IGhhcyBiZWVuIHVzZWQgc2V2ZXJhbCB0aW1lcy4mbmJzcDsgRUMgaXMgdXNlZCB3L291dCBkZWZp bml0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDQuIOKA nEUtVFJFRSBmb3IgVlBMU+KAnSZuYnNwOyBQbGVhc2UgYWRkIGFuIEluZm9ybWF0aXZlIHJlZmVy ZW5jZSB0byByZmM3Nzk2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+UDUuIOKAnOKApm5ldyBCR1AgRXh0ZW5kZWQgQ29tbXVuaXR5IGZvciBsZWFmIGluZGljYXRp b24gYXMgc2hvd24gbGF0ZXIgaW4gdGhpcyBkb2N1bWVudC7igJ0mbmJzcDsgUGxlYXNlIGluY2x1 ZGUgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byBTZWN0aW9uIDUuMS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA2LiDigJxNQUMgbW9iaWxpdHkgcHJvY2VkdXJlc+KA nSZuYnNwOyBXaGF0IGFyZSB0aG9zZT8mbmJzcDsgUGxlYXNlIGFkZCBhIHJlZmVyZW5jZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA3LiBTZWN0aW9uIDMuMi4x IChCVU0gdHJhZmZpYyBvcmlnaW5hdGVkIGZyb20gYSBzaW5nbGUtaG9tZWQgc2l0ZSBvbiBhIGxl YWYgQUMpIHN0YXJ0cyBieSB0YWxraW5nIGFib3V0IOKAnGEgc3BlY2lhbCBNUExTIGxhYmVs4oCd IOKAkyBldmVuIHRob3VnaCB0aGVyZeKAmXMgYSByZWZlcmVuY2UgbGF0ZXIgdG8gNS4xLCBwbGVh c2UgYmUgZXhwbGljaXQgKHdyaXRpbmcgc29tZXRoaW5nDQogbGlrZSB0aGlzKTog4oCcdGhlIFBF IGFkZHMgdGhlIExlYWYgTGFiZWwgYWR2ZXJ0aXNlZCB1c2luZyB0aGUgRS1UcmVlIEV4dGVuZGVk IENvbW11bml0eSAoU2VjdGlvbiA1LjEp4oCdLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTaW1w bGlmeWluZyB0aGUgdGV4dCB3aWxsIGdvIGEgbG9uZyB3YXkgdG8gbWFraW5nIGltcGxlbWVudGF0 aW9uIGVhc2llci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA4 LiDigJxJUkIgdXNlIGNhc2UgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC7i gJ0mbmJzcDsgQW4gSW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtYmVzcy1ldnBu LWludGVyLXN1Ym5ldC1mb3J3YXJkaW5nIHdvdWxkIGJlIG5pY2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QOS4gSXQgd291bGQgYmUgbmljZSB0byBpbmNsdWRl IGEg4oCcbWFw4oCdIG9mIHRoZSBkb2N1bWVudCBpbiB0aGUgSW50cm9kdWN0aW9uOiAoc29tZXRo aW5nIGxpa2UpIOKAnFNlY3Rpb24gMiB0YWxrcyBhYm91dCBibGFo4oCmU2VjdGlvbiAzIGRlZmlu ZXPigKbigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMTAu IHMvRVZQTiBNQUMgQWR2ZXJ0aXNlbWVudCByb3V0ZS9NQUMvSVAgQWR2ZXJ0aXNlbWVudCBSb3V0 ZSZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtQbGVhc2UgYmUgc3BlY2lmaWMhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMTEuIOKAnFRvIHN1cHBvcnQgbXVsdGlj YXN0L2Jyb2FkY2FzdCBmcm9tIFJvb3QgdG8gTGVhZiBzaXRlcywgZWl0aGVyIGEgUDJNUCB0cmVl IHJvb3RlZCBhdCB0aGUgUEUocykgd2l0aCB0aGUgUm9vdCBzaXRlKHMpIG9yIGluZ3Jlc3MgcmVw bGljYXRpb24gY2FuIGJlIHVzZWQu4oCdJm5ic3A7IFJlZmVyZW5jZXMgd291bGQgYmUgdmVyeSBu aWNlITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDEyLiBTZWN0 aW9uIDUuMyBkb2VzbuKAmXQgZXhpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5QMTMuIEJvdGggU2VjdGlvbnMgMyBhbmQgNCBtZW50aW9uIHRoZSBzYW1lIHRo aW5ncyAob3RoZXIgdGFnZ2luZyBtZWNoYW5pc21zIGFuZCBJUkIpIG91dCBvZiBzY29wZS4mbmJz cDsgSXQgd291bGQgYmUgbmljZSB0byBtZW50aW9uIGNvbW1vbiBwaWVjZXMgb2YgdGhlIG9wZXJh dGlvbiBpbiBhIHNpbmdsZSBwbGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlAxNC4g4oCcVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBuZXcgQkdQIEV4dGVu ZGVkIENvbW11bml0eSBmb3IgRVZQTi7igJ0mbmJzcDsgSSBvbmx5IHNlZSBvbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMTUuIEEgTm9ybWF0aXZlIHJlZmVy ZW5jZSB0byByZmM0MzYwIGlzIG5lZWRlZCBpbiA1LjEuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5QMTYuIFRoZXJl4oCZcyBubyBuZWVkIHRvIHRoZSByZWZlcmVu Y2UgdG8gcmZjNzE1MyBiZWNhdXNlIHlvdeKAmXJlIHJlZmVycmluZyB0byB0aGUgcmVnaXN0cnkg aXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDE3LiBU aGUgJ1VwZGF0ZXM6ICcgbGluZSBpbiB0aGUgZHJhZnQgaGVhZGVyIHNob3VsZCBsaXN0IG9ubHkg dGhlIF9udW1iZXJzXyBvZiB0aGUgUkZDcyB3aGljaCB3aWxsIGJlIHVwZGF0ZWQgYnkgdGhpcyBk b2N1bWVudCAoaWYgYXBwcm92ZWQpOyBpdCBzaG91bGQgbm90IGluY2x1ZGUgdGhlIHdvcmQgJ1JG QycgaW4gdGhlIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5QMTguIFRoZXJlIGlzIG5vIHJlZmVyZW5jZSB0byByZmM1MjI2LiZuYnNwOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Tml0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk4xLiBU aGVyZSBhcmUgYSBsb3Qgb2YgdmVyeSBsb25nIHNlbnRlbmNlc+KApiZuYnNwOyBJdCB3b3VsZCBi ZSBuaWNlIGlmIHRoZSBpZGVhcyB3ZXJlIGNvbXBvc2VkIHNvIHRoYXQgdGhlIG92ZXJhbGwgZG9j dW1lbnQgd2FzIGVhc2llciB0byByZWFkLiZuYnNwOyBGb3IgYW4gZXhhbXBsZSwgdGFrZSBhIGxv b2sgYXQgdGhlIGxhc3QgcGFyYWdyYXBoIGluIDIuMuKApiZuYnNwOyBObyBzcGVjaWZpYw0KIGFj dGlvbiByZXF1aXJlZCBoZXJlLCBidXQgaXQgd291bGQgYmUgbmljZSB0byBnaXZlIGl0IGFuIGVk aXRpbmcgcGFzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk4y LiBzLzwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPg0KZWFjaCBvZiBpdHMg TUFDL0lQIEFkdmVydGlzZW1lbnQgcm91dGUvZWFjaCBvZiBpdHMgTUFDL0lQIEFkdmVydGlzZW1l bnQgcm91dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OMy4g QW5vdGhlciBleGFtcGxlIG9mIHdoZXJlIHRoZSB0ZXh0IGlzIG5vdCBhcyBjbGVhciBhcyBpdCBj b3VsZCBiZSBmb3IgYSBzcGVjaWZpY2F0aW9uIGlzIFNlY3Rpb24gMy4yLCB3aGVyZSB0YWdnaW5n IE1QTFMgZnJhbWVzIGlzIG1hbmRhdGVkICjigJx0aGUgTVBMUy1lbmNhcHN1bGF0ZWQgZnJhbWVz IE1VU1QgYmUgdGFnZ2VkIHdpdGggYW4gaW5kaWNhdGlvbg0KIHdoZW4gdGhleSBvcmlnaW5hdGVk IGZyb20gYSBMZWFmIEFD4oCdKSwgYnV0IHRoZXJlIGlzIG5vIGluZGljYXRpb24gb24gaG93IHRv IGRvIHRoaXMgdW50aWwgMyBwYXJhZ3JhcGhzIGxhdGVyIOKAkyBhIHNlZW1pbmdseSB1bnJlbGF0 ZWQgZGlzY3Vzc2lvbiBpcyBoZWxkIGluIGJldHdlZW7igKYNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+TjQuIOKAnHdl4oCdIGlzIHVzZWQgYSBjb3VwbGUgb2Yg dGltZXMgKG91dHNpZGUgdGhlIEFja25vd2xlZGdlbWVudHMpIOKAkyBwbGVhc2UgY2hhbmdlIHRo YXQgdG8g4oCcdGhpcyBkb2N1bWVudOKAnSAob3Igc29tZXRoaW5nIHNpbWlsYXIpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TjUuIHMvd2hlcmUgYW5kIEV0aGVy bmV0IFNlZ21lbnQvd2hlcmUgYW4gRXRoZXJuZXQgU2VnbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+TjYuIHMvZHJhZnQvZG9jdW1lbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8A9E130E0A0C4DE5BB3598EE3C305E4Bciscocom_-- From nobody Thu Apr 6 03:09:12 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C495D120046; Thu, 6 Apr 2017 03:09:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149147335073.21946.3847454341263601428@ietfa.amsl.com> Date: Thu, 06 Apr 2017 03:09:10 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-proxy-arp-nd-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 10:09:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Operational Aspects of Proxy-ARP/ND in EVPN Networks Authors : Jorge Rabadan Senthil Sathappan Kiran Nagaraj Wim Henderickx Greg Hankins Thomas King Daniel Melzer Erik Nordmark Filename : draft-ietf-bess-evpn-proxy-arp-nd-02.txt Pages : 22 Date : 2017-04-06 Abstract: The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast- forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs, as explained in [RFC6820]. This document describes how the [RFC7432] EVPN proxy- ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy-arp-nd-02 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-proxy-arp-nd-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-proxy-arp-nd-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 7 14:47:00 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0AD128B92; Fri, 7 Apr 2017 14:46:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149160161083.11232.11409617444161707051.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 14:46:50 -0700 Archived-At: Subject: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 21:46:52 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-bess-evpn-vpws-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I did have some non-Discuss questions that you might wish to think about before the document is approved ... In the Abstract This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. everything is exceptionally clear, except that I don't know what the "traditional way" of signaling means. The same phrase appears in Section 1 Introduction This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P services. These benefits include single-active redundancy as well as all-active redundancy with flow-based load-balancing. Furthermore, the use of EVPN for VPWS eliminates the need for traditional way of PW signaling for P2P Ethernet services, as described in section 4. with the addition of "as described in section 4", but I didn't see an explicit statement in Section 4 that explained what was replacing the "traditional way". Even a clear reference to an RFC where the "traditional way" was defined would be helpful. It would probably be helpful to expand acronums like "P2P" on first use. I immediately thought "peer to peer?" but I bet you didn't mean that. Yes, there's a terminology section, but it's three and a half pages into the document. In this text, For EVPL service, the Ethernet frames transported over an MPLS/IP network SHOULD remain ^^^^^^ tagged with the originating VLAN-ID (VID) and any VID translation MUST be performed at the disposition PE. why is this a SHOULD? I guess my first question should be "does this still work if you don't?" In this text, In multihoming scenarios, both B and P flags MUST NOT be both set. the double both(s) made this difficult to parse. Is it saying In multihoming scenarios, the B and P flags MUST be cleared. or something else? But I'm guessing, and the rest of that paragraph made me doubt my guesses. From nobody Fri Apr 7 15:58:45 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBD7129469; Fri, 7 Apr 2017 15:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNV8Jy_1RBiJ; Fri, 7 Apr 2017 15:58:32 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F847129490; Fri, 7 Apr 2017 15:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3648; q=dns/txt; s=iport; t=1491605872; x=1492815472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=spHySaT9dfOTQd+ddDMpf6uRIM0vipJCrB+W4bDjo4U=; b=GQzen/a/zWQaNC0LCfCI3Juz7pu8vE/TsNpUR89NiqZ0oLCpOp6opNoB gN6R2Xzqg/7DDQpbZYM4yaOoX/52R85sN3Mvq4v87rZrFLLzAWlZceveh HGOxumsXWqXEbfvuV+DngDme24JxMfjg00i7H8kpOGaqvkaPpocXllyXo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAGGehY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXKZXo09gg8fC4V4AoNePxgBAgEBAQEBAQFrKIUWAgE?= =?us-ascii?q?DAQE4NAsQAgEINhAhBgslAgQBDQWJdwMVDqx7hzENgy0BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYs+glGBVxEBToUzBYklBZMTOwGGf4cchDyBfoUuihSLAIh+AR8?= =?us-ascii?q?4fQhbFUGEWx0ZgUp1AYcKgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,168,1488844800"; d="scan'208";a="408546456" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 22:57:51 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v37MvpoG031349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 22:57:51 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Apr 2017 18:57:50 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 7 Apr 2017 18:57:50 -0400 From: "Acee Lindem (acee)" To: Spencer Dawkins , The IESG CC: "zzhang@juniper.net" , "draft-ietf-bess-evpn-vpws@ietf.org" , "bess-chairs@ietf.org" , "bess@ietf.org" , "Alvaro Retana (aretana)" Thread-Topic: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT) Thread-Index: AQHSr+iG6cNaUXQKF0uToizt/aKp+qG6hOyA Date: Fri, 7 Apr 2017 22:57:50 +0000 Message-ID: References: <149160161083.11232.11409617444161707051.idtracker@ietfa.amsl.com> In-Reply-To: <149160161083.11232.11409617444161707051.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 22:58:36 -0000 Hi Spencer,=20 On 4/7/17, 5:46 PM, "BESS on behalf of Spencer Dawkins" wrote: >Spencer Dawkins has entered the following ballot position for >draft-ietf-bess-evpn-vpws-11: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I did have some non-Discuss questions that you might wish to think about >before the document is approved ... > >In the Abstract > > This document describes how EVPN can be used to support Virtual > Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the > following characteristics for VPWS: single-active as well as all- > active multi-homing with flow-based load-balancing, eliminates the > need for traditional way of Pseudowire (PW) signaling, and provides > fast protection convergence upon node or link failure. > >everything is exceptionally clear, except that I don't know what the >"traditional way" of signaling means. > >The same phrase appears in Section 1 Introduction > > This document describes how EVPN can be used to support Virtual > Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN > mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P > services. These benefits include single-active redundancy as well as > all-active redundancy with flow-based load-balancing. Furthermore, > the use of EVPN for VPWS eliminates the need for traditional way of > PW signaling for P2P Ethernet services, as described in section 4. > >with the addition of "as described in section 4", but I didn't see an >explicit statement in Section 4 that explained what was replacing the >"traditional way". Even a clear reference to an RFC where the >"traditional way" was defined would be helpful. > >It would probably be helpful to expand acronums like "P2P" on first use. >I immediately thought "peer to peer?" but I bet you didn't mean that. >Yes, there's a terminology section, but it's three and a half pages into >the document. > >In this text,=20 > > For EVPL service, > the Ethernet frames transported over an MPLS/IP network SHOULD >remain > ^^^^^^ > tagged with the originating VLAN-ID (VID) and any VID translation > MUST be performed at the disposition PE. > >why is this a SHOULD? I guess my first question should be "does this >still work if you don't?" > >In this text, > > In multihoming scenarios, both B and P flags MUST NOT be both set. >=20 > >the double both(s) made this difficult to parse. Is it saying > > In multihoming scenarios, the B and P flags MUST be cleared. > >or something else? But I'm guessing, and the rest of that paragraph made >me doubt my guesses. I think it is clear that it means they are mutually exclusive. Thanks, Acee (Routing Directorate Reviewer of this draft) > > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Sat Apr 8 22:57:22 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCB5129417; Sat, 8 Apr 2017 22:57:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: draft-ietf-bess-evpn-vpws.all@ietf.org, ietf@ietf.org, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149171742319.3063.4555090995663652452@ietfa.amsl.com> Date: Sat, 08 Apr 2017 22:57:03 -0700 Archived-At: Subject: [bess] Genart telechat review of draft-ietf-bess-evpn-vpws-11 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 05:57:03 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-bess-evpn-vpws-?? Reviewer: Roni Even Review Date: 2017-04-08 IETF LC End Date: 2017-03-10 IESG Telechat date: 2017-04-13 Summary: Major issues: Minor issues: Nits/editorial comments: In section 1 second paragraph "[RFC7432] provides the ability " looks like the reference is not a link to RFC7432. From nobody Sun Apr 9 20:51:35 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28579128B92; Sun, 9 Apr 2017 20:51:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149179628509.3082.18080226248230795996@ietfa.amsl.com> Date: Sun, 09 Apr 2017 20:51:25 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-df-election-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 03:51:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : A new Designated Forwarder Election for the EVPN Authors : Satya Ranjan Mohanty Keyur Patel Ali Sajassi John Drake Antoni Przygienda Filename : draft-ietf-bess-evpn-df-election-02.txt Pages : 15 Date : 2017-04-09 Abstract: This document describes an improved EVPN Designated Forwarder Election (DF) algorithm which can be used to enhance operational experience in terms of convergence speed and robustness over a WAN deploying EVPN The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-02 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-df-election-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-df-election-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 11 03:49:03 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2C5129416; Tue, 11 Apr 2017 03:49:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149190774166.15750.6183308399468219556@ietfa.amsl.com> Date: Tue, 11 Apr 2017 03:49:01 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-ac-df-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 10:49:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : AC-Influenced Designated Forwarder Election for EVPN Authors : Jorge Rabadan Kiran Nagaraj Senthil Sathappan Vinod Prabhu Wim Henderickx Autumn Liu Wen Lin Filename : draft-ietf-bess-evpn-ac-df-01.txt Pages : 10 Date : 2017-04-11 Abstract: The Designated Forwarder (DF) in EVPN networks is the PE responsible for sending multicast, broadcast and unknown unicast traffic to a multi-homed CE, on a given Ethernet Tag on a particular Ethernet Segment (ES). The DF is selected based on the list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network. While PE node or link failures trigger the DF re-election for a given , individual Attachment Circuit (AC) or MAC-VRF failures do not trigger such DF re-election and the traffic may therefore be permanently impacted, even though there is an alternative path. This document improves the DF election algorithm so that the AC status can influence the result of the election and this type of "logical" failures can be protected too. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ac-df/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-ac-df-01 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ac-df-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-ac-df-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 11 09:28:26 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ED812EAFC; Tue, 11 Apr 2017 09:28:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192810403.15694.4770626767263445612.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 09:28:24 -0700 Archived-At: Subject: [bess] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-bess-evpn-vpws-11=3A_=28with_COMMENT=29?= X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 16:28:24 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-bess-evpn-vpws-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor comments: 1) Agree with Warren that all the acronyms make it hard to read. Please check that you've spelled out all acronyms at the first occurrence in the intro accordingly, including EVPN. 2) section 3.1: Is the B flag even needed? Doesn't P=0 indicate that this is the Backup PE? 3) I would maybe move section 5 right after the intro because it provides some background on the benefits of this extension. 4) Are you sure there are no additional security consideration based on the information provided in this extension? E.g. an attacker indicates being the primary PE and thereby causes a conflict, or problems based on the indication of a small MTU by an attacker? Not sure if there is any risk or if that is covered somewhere else...? From nobody Tue Apr 11 09:33:15 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6B212EB0C; Tue, 11 Apr 2017 09:33:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192838671.15661.4860933182922034660@ietfa.amsl.com> Date: Tue, 11 Apr 2017 09:33:06 -0700 Archived-At: Subject: [bess] IPR Disclosure Orange's Statement about IPR related to draft-mackie-bess-nsh-bgp-control-plane X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 16:33:07 -0000 Dear John Drake, Eric C. Rosen, Jim Uttaro, Luay Jalil, Adrian Farrel: An IPR disclosure that pertains to your Internet-Draft entitled "BGP Control Plane for NSH SFC" (draft-mackie-bess-nsh-bgp-control-plane) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2980/). The title of the IPR disclosure is "Orange's Statement about IPR related to draft-mackie-bess-nsh-bgp-control-plane" Thank you IETF Secretariat From nobody Tue Apr 11 09:34:57 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7972912EB00; Tue, 11 Apr 2017 09:34:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192848949.15710.2371394446510583524.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 09:34:49 -0700 Archived-At: Subject: [bess] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-bess-evpn-vpws-11=3A_=28with_COMMENT=29?= X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 16:34:50 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-bess-evpn-vpws-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd write-up says: "Two IPR discussions from Juniper & Cisco respectively: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws Haven't seen WG discussion on that." Can we confirm that the wg is aware of the IPRs before publication? Other minor comments: 1) Agree with Warren that all the acronyms make it hard to read. Please check that you've spelled out all acronyms at the first occurrence in the intro accordingly, including EVPN. 2) section 3.1: Is the B flag even needed? Doesn't P=0 indicate that this is the Backup PE? 3) I would maybe move section 5 right after the intro because it provides some background on the benefits of this extension. 4) Are you sure there are no additional security consideration based on the information provided in this extension? E.g. an attacker indicates being the primary PE and thereby causes a conflict, or problems based on the indication of a small MTU by an attacker? Not sure if there is any risk or if that is covered somewhere else...? From nobody Tue Apr 11 09:43:14 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A19F12EADF; Tue, 11 Apr 2017 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JKM6czY3xIe; Tue, 11 Apr 2017 09:43:05 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3119129536; Tue, 11 Apr 2017 09:43:03 -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=1491928984; x=1493138584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y/O7apEnEqnBX3XjnwwBZDVnaceTr8lERtzoXHOXUCc=; b=InC8Ur1FxunkMY9YjTu3SSBihhskga/IxPIP9y5lyehxz1m4JyXXpwJt ax+//48CXYKTiWPrSva9waT5oCZ+ziIOZ/qI6T9c/uJYDtkm5EskmQ+w0 ag0NOU2KIB3yLD0IPRx+gF2CGZBHcLM+4Lh/KYbySa5i4BDLce4hx3C0k g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgB7Bu1Y/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE6JDhGOCDzCFdAIag0c/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?GIxFFEAIBCBoCJgICAjAVBQsCBAENBYoQDqkTgiaKfgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFgQuFRYIFgmuDF4E/gwYugjEBBIkljH6GXAGGf4tekUSUAAEfOIE?= =?us-ascii?q?FWxVSAYRJHBmBSnUFiEOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,186,1488844800"; d="scan'208";a="409674588" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 16:43:03 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3BGh3Km020157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 16:43:03 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 11:43:02 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 11:43:02 -0500 From: "Alvaro Retana (aretana)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "Zhaohui (Jeffrey) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-bess-evpn-vpws-11:_(with_COMMENT)?= Thread-Index: AQHSsuGLYB71Hx0fZEWW7PDbt90vOKHAcF2A Date: Tue, 11 Apr 2017 16:43:02 +0000 Message-ID: <1DE88F3F-615C-4B75-BB71-AA2E47530DBF@cisco.com> References: <149192848949.15710.2371394446510583524.idtracker@ietfa.amsl.com> In-Reply-To: <149192848949.15710.2371394446510583524.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: <7409CC1DA8AA7B42A442FD1E3C756E63@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-bess-evpn-vpws-11=3A_=28with_COMMENT=29?= X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 16:43:06 -0000 SGkhDQoNClllcywgdGhlIFdHIHdhcyBtYWRlIGF3YXJlIG9mIHRoZSBJUFIgYXQgdGhlIFdHTEM6 DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYmVzcy9JNV9HSTQ0MjIx RVpKR1FHV0hWZHYwdWtiR2svP3FpZD0wODY0OWM3MjFlYmRiMTExYzIxNWY2ODU0ZmYwYzI0MSAN Cg0KQWx2YXJvLg0KDQoNCg0KDQpPbiA0LzExLzE3LCAxMjozNCBQTSwgIk1pcmphIEvDvGhsZXdp bmQiIDxpZXRmQGt1ZWhsZXdpbmQubmV0PiB3cm90ZToNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVO VDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIHNoZXBoZXJkIHdyaXRlLXVwIHNheXM6DQoiVHdvIElQ UiBkaXNjdXNzaW9ucyBmcm9tIEp1bmlwZXIgJiBDaXNjbyByZXNwZWN0aXZlbHk6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1kcmFmdCZpZD1kcmFmdC1p ZXRmLWJlc3MtZXZwbi12cHdzDQpIYXZlbid0IHNlZW4gV0cgZGlzY3Vzc2lvbiBvbiB0aGF0LiIN CkNhbiB3ZSBjb25maXJtIHRoYXQgdGhlIHdnIGlzIGF3YXJlIG9mIHRoZSBJUFJzIGJlZm9yZSBw dWJsaWNhdGlvbj8NCg0KDQoNCg== From nobody Tue Apr 11 11:57:29 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C37CE12EC73; Tue, 11 Apr 2017 11:57:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193704779.15804.811920504827002567.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 11:57:27 -0700 Archived-At: Subject: [bess] Alissa Cooper's No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:57:28 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-bess-evpn-vpws-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From Roni's Gen-ART review: Nits/editorial comments: In section 1 second paragraph "[RFC7432] provides the ability " looks like the reference is not a link to RFC7432. From nobody Tue Apr 11 16:43:40 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E4D1286B1; Tue, 11 Apr 2017 16:43:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 16:43:38 -0700 Archived-At: Subject: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 23:43:38 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bess-evpn-vpws-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- First, thank you for a clearly written document that contained enough context to trigger my hazy memory of some of the technical details. My concern is around this paragraph in the Introduction: "The MPLS label value in the Ethernet A-D route can be set to the VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may have a global scope or local scope per PE and may also be equal to the VPWS service instance identifier set in the Ethernet A-D route. " First, I recognize that folks have implemented and deployed EVPN with VXLAN. That's fine. There is an ISE RFC 7348 that describes VXLAN. Depending on what you (authors, shepherd, AD, WG) decide to do about the rest of my concern, it is likely that this should be normative references - which would be a downref. Second, the paragraph here isn't really adequate to describe how to implement the functionality. I don't see how: a) The ingress PE decides which VNIs it can send based upon the VNI=MPLS_label from the egress. Is there an assumption that VXLAN allows sending all VNIs across the particular VPWS, whether port-based, VLAN-based, etc? b) Is there an assumption that the egress PE-advertised MPLS label also indicates the VNI to be used? That seems like another mode, like the VLAN-based service, except it is perhaps VNI + VLAN-based service? Please don't take this Discuss as a reason to remove the paragraph and the implied functionality. If it's implemented and deployed (and I think it is) - then what I really want is to just have it adequately written down so that others can interoperably implement. The downref to VXLAN should just be a matter of process nuisance (i.e. another IETF Last Call and handling any concerns). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or "This specification" or... 2) Sec 3.1: " C If set to 1, a Control word [RFC4448] MUST be present when sending EVPN packets to this PE." Given discussions with IEEE about real MACs starting with 4 and 6 in top nibble, adding a statement about it being BCP to include the control word (unless using Entropy Label) would be a good idea. From nobody Wed Apr 12 01:54:12 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D163313013C; Wed, 12 Apr 2017 01:54:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149198725081.15710.15224462292182821549@ietfa.amsl.com> Date: Wed, 12 Apr 2017 01:54:10 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-l2l3-vpn-mcast-mib-07.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:54:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : L2L3 VPN Multicast MIB Authors : Zhaohui (Jeffrey) Zhang Hiroshi Tsunoda Filename : draft-ietf-bess-l2l3-vpn-mcast-mib-07.txt Pages : 19 Date : 2017-04-12 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes common managed objects used by other MIB modules which are designed for monitoring and/or configuring both Layer 2 and Layer 3 Virtual Private Networks (VPN) that support multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-07 https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 12 11:14:14 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22D712EB19; Wed, 12 Apr 2017 11:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5kW-ZL2cffL; Wed, 12 Apr 2017 11:14:09 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0054.outbound.protection.outlook.com [104.47.38.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9D21277BB; Wed, 12 Apr 2017 11:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OK2miiVRajo9ApqapwCXIa6lhBliwR8AtSyXl94hv7U=; b=RS+19+cSsBvK/7O2o/GxoMZptNShdWNyIWJR8+wcm5My547iDJSsaFugP1novwL0yhgxsqXkk/a30ITDvfWG27C6E16iZrno/TZCD6NYeJ4R2X3rMJTy+7rWLEn78nakZ6YVCmzd9lfNgy6k3ZE1Tyh60ZdfKC8qWfxoR7XgZqs= Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 12 Apr 2017 18:14:07 +0000 Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.1034.012; Wed, 12 Apr 2017 18:14:07 +0000 From: Sami Boutros To: Alia Atlas , The IESG CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "aretana@cisco.com" , "Zhaohui (Jeffrey) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) Thread-Index: AQHSsx164xCqEvIbFkeIlM5ejr6GlaHBlYIA Date: Wed, 12 Apr 2017 18:14:07 +0000 Message-ID: References: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> In-Reply-To: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [208.91.2.2] x-microsoft-exchange-diagnostics: 1; BN6PR05MB3009; 7:gUese4/SMSEc0pqtVvdymVjP91q/9atkXkTA2/QvlprcxTizrZMH+YytXzZusMoOtPYAUDseQs9k8OwZ7Y0JJmDs7Mx2tPHfjAl2tWKMjwkQJQTvoGb6hqOrVZabKQzLS7r3BoJhefSQT0Yl3tt+GCReDepqkBi0KrWtVZdDZ2caD/OOtvI2Q/iZKmVEQ0FVnLB6edv6CM2PiaZpssProQatDR+TasDkwNWsLOMxi5T2goDT00amaQo3d65g9/p1t1tgRtBAV0L9NQp5l9Upew2z/R7EMBXb2w0lNC2dt52fmBkPYARypNq8qU4KRqcikARdnekg4zMgZ5aCIfYR4A==; 20:uILUsC6Uzb3y6hQg2/58ollAuYb9kHrNjEPdNphikv89RiUJxCWl9NB3oOSCMF1+6vDbzyRiXpMWVpRuCXdlmIxHSqT/gnn2DGPPWopu3uZIJ8VRJvemd27xXXAv+0rC0+i8wBw3i9C0eN4J7wFiRfbBm+EcdsDQbiTNk8ROQVE= x-ms-office365-filtering-correlation-id: ed9b5293-e8d1-435e-f746-08d481cfb5bb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR05MB3009; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:BN6PR05MB3009; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB3009; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39450400003)(39400400002)(39410400002)(24454002)(377454003)(36756003)(2900100001)(83716003)(122556002)(82746002)(8936002)(229853002)(2950100002)(575784001)(86362001)(230783001)(66066001)(5660300001)(33656002)(102836003)(2906002)(7736002)(305945005)(50986999)(345774005)(76176999)(54356999)(99286003)(3846002)(3280700002)(8666007)(38730400002)(3660700001)(4326008)(6512007)(53936002)(39060400002)(6306002)(54906002)(6486002)(77096006)(189998001)(6246003)(6436002)(81166006)(6506006)(53546009)(8676002)(25786009)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3009; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1C65F527CA56204DB1FC120DF0AC1784@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 18:14:07.0968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3009 Archived-At: Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:14:13 -0000 SGkgQWxpYSwNCg0KUGxlYXNlIHNlZSBjb21tZW50cyBpbmxpbmUuDQoNCg0KT24gNC8xMS8xNywg NDo0MyBQTSwgIkFsaWEgQXRsYXMiIDxha2F0bGFzQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5BbGlh IEF0bGFzIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPmRy YWZ0LWlldGYtYmVzcy1ldnBuLXZwd3MtMTE6IERpc2N1c3MNCj4NCj5XaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj5l bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcw0KPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0K PlBsZWFzZSByZWZlciB0byBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pZXNnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3JpdGVy aWEuaHRtbCZkPUR3SUNhUSZjPXVpbGFLOTBENFRPVm9INThKTlhSZ1Emcj1JVnpjVFJMUWRwdGEw OEwwYl95MnpEa3F2d0poUktNQ0FiWC0ySy1MVjk4Jm09NzhzUE5FckktcmxqU0ZBYU01Yjc2X1Fh RFNUejJCRF84bnkwRHhjZjRzTSZzPXM4b2F0N3ZVRHg2TkhWMHZPZWhVbF9mTGpzTEhzVHFtaHQz eElIb09yMkkmZT0gDQo+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4NCj4NCj5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9y Z19kb2NfZHJhZnQtMkRpZXRmLTJEYmVzcy0yRGV2cG4tMkR2cHdzXyZkPUR3SUNhUSZjPXVpbGFL OTBENFRPVm9INThKTlhSZ1Emcj1JVnpjVFJMUWRwdGEwOEwwYl95MnpEa3F2d0poUktNQ0FiWC0y Sy1MVjk4Jm09NzhzUE5FckktcmxqU0ZBYU01Yjc2X1FhRFNUejJCRF84bnkwRHhjZjRzTSZzPU1s SktYaXNRVHIxYWhlUzhoYWh0eS1pRkRPQ1NfR2hNMzdYMmxNVUFINTQmZT0gDQo+DQo+DQo+DQo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPkRJU0NVU1M6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPkZpcnN0LCB0aGFu ayB5b3UgZm9yIGEgY2xlYXJseSB3cml0dGVuIGRvY3VtZW50IHRoYXQgY29udGFpbmVkIGVub3Vn aA0KPmNvbnRleHQgdG8gdHJpZ2dlciBteSBoYXp5DQo+bWVtb3J5IG9mIHNvbWUgb2YgdGhlIHRl Y2huaWNhbCBkZXRhaWxzLg0KPg0KPk15IGNvbmNlcm4gaXMgYXJvdW5kIHRoaXMgcGFyYWdyYXBo IGluIHRoZSBJbnRyb2R1Y3Rpb246DQo+DQo+IlRoZSBNUExTIGxhYmVsIHZhbHVlIGluIHRoZSBF dGhlcm5ldCBBLUQgcm91dGUgY2FuIGJlIHNldCB0byB0aGUNCj4gICBWWExBTiBOZXR3b3JrIElk ZW50aWZpZXIgKFZOSSkgZm9yIFZYTEFOIGVuY2FwLCBhbmQgdGhpcyBWTkkgbWF5DQo+aGF2ZQ0K PiAgIGEgZ2xvYmFsIHNjb3BlIG9yIGxvY2FsIHNjb3BlIHBlciBQRSBhbmQgbWF5IGFsc28gYmUg ZXF1YWwgdG8gdGhlDQo+ICAgVlBXUyBzZXJ2aWNlIGluc3RhbmNlIGlkZW50aWZpZXIgc2V0IGlu IHRoZSBFdGhlcm5ldCBBLUQgcm91dGUuDQo+Ig0KPg0KPkZpcnN0LCBJIHJlY29nbml6ZSB0aGF0 IGZvbGtzIGhhdmUgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIEVWUE4gd2l0aA0KPlZYTEFOLg0K PlRoYXQncyBmaW5lLiAgVGhlcmUgaXMgYW4gSVNFIFJGQyA3MzQ4IHRoYXQgZGVzY3JpYmVzIFZY TEFOLiAgIERlcGVuZGluZw0KPm9uIHdoYXQNCj55b3UgKGF1dGhvcnMsIHNoZXBoZXJkLCBBRCwg V0cpIGRlY2lkZSB0byBkbyBhYm91dCB0aGUgcmVzdCBvZiBteQ0KPmNvbmNlcm4sIGl0IGlzDQo+ bGlrZWx5IHRoYXQgdGhpcyBzaG91bGQgYmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgLSB3aGljaCB3 b3VsZCBiZSBhDQo+ZG93bnJlZi4NCg0KSSBjYW4gYWRkIHRoZSA3MzQ4IGFzIGEgbm9ybWF0aXZl IHJlZmVyZW5jZS4NCg0KPg0KPlNlY29uZCwgdGhlIHBhcmFncmFwaCBoZXJlIGlzbid0IHJlYWxs eSBhZGVxdWF0ZSB0byBkZXNjcmliZSBob3cgdG8NCj5pbXBsZW1lbnQgdGhlDQo+ZnVuY3Rpb25h bGl0eS4gICBJIGRvbid0IHNlZSBob3c6DQo+ICAgIGEpIFRoZSBpbmdyZXNzIFBFIGRlY2lkZXMg d2hpY2ggVk5JcyBpdCBjYW4gc2VuZCBiYXNlZCB1cG9uIHRoZQ0KPlZOST1NUExTX2xhYmVsDQo+ ICAgICAgICBmcm9tIHRoZSBlZ3Jlc3MuICAgSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0aGF0IFZY TEFOIGFsbG93cw0KPnNlbmRpbmcgYWxsIFZOSXMgYWNyb3NzDQo+ICAgICAgICB0aGUgcGFydGlj dWxhciBWUFdTLCB3aGV0aGVyIHBvcnQtYmFzZWQsIFZMQU4tYmFzZWQsIGV0Yz8NCg0KV2UgYXJl IHNpZ25hbGluZyBFdGhlcm5ldCBBLUQgcm91dGUgcGVyIFZQV1MgaW5zdGFuY2UsIGFuZCBpbiB0 aGVyZSB3ZSB3aWxsIHNpZ25hbCANClZOSSBpbnN0ZWFkIG9mIGFuIE1QTFMgbGFiZWwgZm9yIFZ4 TEFOIGVuY2FwLg0KDQo+ICAgIGIpIElzIHRoZXJlIGFuIGFzc3VtcHRpb24gdGhhdCB0aGUgZWdy ZXNzIFBFLWFkdmVydGlzZWQgTVBMUyBsYWJlbA0KPmFsc28gaW5kaWNhdGVzIHRoZQ0KPiAgICAg ICAgIFZOSSB0byBiZSB1c2VkPyAgDQoNCkVWUE4gY2FuIHdvcmsgd2l0aCBkaWZmZXJlbnQgZW5j YXBzdWxhdGlvbnMgYSBCR1AgVHVubmVsIEVuY2Fwc3VsYXRpb24gQXR0cmlidXRlIA0KVGhhdCBz cGVjaWZpZXMgdGhlIHR1bm5lbCB0eXBlIHdpbGwgYmUgYWRkZWQgdG8gdGhlIEV0aGVybmV0IEEt RCByb3V0ZS4NCg0KDQo+VGhhdCBzZWVtcyBsaWtlIGFub3RoZXIgbW9kZSwgbGlrZSB0aGUNCj5W TEFOLWJhc2VkIHNlcnZpY2UsIGV4Y2VwdA0KPiAgICAgICAgIGl0IGlzIHBlcmhhcHMgVk5JICsg VkxBTi1iYXNlZCBzZXJ2aWNlPw0KDQpUaGUgZHJhZnQgbGlzdHMgY2xlYXJseSB0aGUgZGlmZmVy ZW50IHNlcnZpY2UgaW50ZXJmYWNlIHR5cGVzLCBhbmQgdGhlcmUgd2lsbCANCmJlIG9ubHkgb25l IFZOSSBwZXIgVlBXUyBpbnN0YW5jZSB3ZXRoZXIgdGhpcyBpcyBWbGFuIG9yIHBvcnQgYmFzZWQu DQoNCj4NCj5QbGVhc2UgZG9uJ3QgdGFrZSB0aGlzIERpc2N1c3MgYXMgYSByZWFzb24gdG8gcmVt b3ZlIHRoZSBwYXJhZ3JhcGggYW5kDQo+dGhlIGltcGxpZWQgZnVuY3Rpb25hbGl0eS4NCj5JZiBp dCdzIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCAoYW5kIEkgdGhpbmsgaXQgaXMpIC0gdGhlbiB3 aGF0IEkgcmVhbGx5DQo+d2FudCBpcyB0byBqdXN0IGhhdmUgaXQNCj5hZGVxdWF0ZWx5IHdyaXR0 ZW4gZG93biBzbyB0aGF0IG90aGVycyBjYW4gaW50ZXJvcGVyYWJseSBpbXBsZW1lbnQuICBUaGUN Cj5kb3ducmVmIHRvIFZYTEFODQo+c2hvdWxkIGp1c3QgYmUgYSBtYXR0ZXIgb2YgcHJvY2VzcyBu dWlzYW5jZSAoaS5lLiBhbm90aGVyIElFVEYgTGFzdCBDYWxsDQo+YW5kIGhhbmRsaW5nIGFueSBj b25jZXJucykuDQo+DQoNClNob3VsZCBJIGFkZCB0aGUgNzM0OCBhcyBhIG5vcm1hdGl2ZSByZWZl cmVuY2U/DQoNCg0KDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPg0KPjEpIChOaXQpIFNlYyAzLjEgIlRoaXMgZHJhZnQiIGZvciBhbiBSRkMgc2hvdWxkIGJl ICJUaGlzIGRvY3VtZW50IiBvcg0KPiJUaGlzIHNwZWNpZmljYXRpb24iIG9yLi4uDQoNCldpbGwg Zml4Lg0KPg0KPjIpIFNlYyAzLjE6ICAiICAgIEMgICAgICBJZiBzZXQgdG8gMSwgYSBDb250cm9s IHdvcmQgW1JGQzQ0NDhdIE1VU1QgYmUNCj5wcmVzZW50IHdoZW4gc2VuZGluZyBFVlBOIHBhY2tl dHMgdG8gdGhpcyBQRS4iDQo+ICAgR2l2ZW4gZGlzY3Vzc2lvbnMgd2l0aCBJRUVFIGFib3V0IHJl YWwgTUFDcyBzdGFydGluZyB3aXRoIDQgYW5kIDYgaW4NCj50b3AgbmliYmxlLCBhZGRpbmcgYSBz dGF0ZW1lbnQgYWJvdXQgaXQgYmVpbmcgQkNQIHRvIGluY2x1ZGUNCj4gICB0aGUgY29udHJvbCB3 b3JkICh1bmxlc3MgdXNpbmcgRW50cm9weSBMYWJlbCkgd291bGQgYmUgYSBnb29kIGlkZWEuDQo+ DQpDb3VsZCB5b3Ugc3VnZ2VzdCBzb21lIHRleHQ/IA0KDQpTaG91bGQgSSBzdWJtaXQgLTEyIHdp dGggdGhlIGNoYW5nZXM/DQoNClRoYW5rcywNCg0KU2FtaQ0KPg0K From nobody Wed Apr 12 12:49:01 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B506C129498; Wed, 12 Apr 2017 12:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTEjaVxP4NhR; Wed, 12 Apr 2017 12:48:51 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F7E1289B5; Wed, 12 Apr 2017 12:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6528; q=dns/txt; s=iport; t=1492026531; x=1493236131; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=66JCRWH1LL+rFyYVSsmgqehRSKKjUyVPforqneTD1+Q=; b=abFP9/ff2zaqd6KAfG2WuSYiKINq27+SkQP9fOp4fwNMbmDiQsApUmgU 7eepjzxAF2nKKyI6iYwdMzKuEeckriVrzLmGjNFvJPeH69xk5Hp8wrHDy y6umifBnipy/CTl1SXl0AFk6eJkUkU1Bx25k7K6pc1szvboy2WdGrp1vg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAwCzg+5Y/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5EyH4gajT+CDyiFfAIag2c/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRYBBAEjEUUFCwIBCA4MAiYCAgIfERUQAgQBDQWJfgMNCKlAgiaHMA2DUwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BC4VGgV0rCYJjglGBVxEBgyIugjEFiSeNAIY?= =?us-ascii?q?oOwGHAYcchEOBf1WEWYoXiwKIfwEfOH0IWxVSAYR+gUp1hnSBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208";a="410707216" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 19:48:50 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3CJmoi6024385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 19:48:50 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 14:48:49 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 14:48:49 -0500 From: "Alvaro Retana (aretana)" To: Sami Boutros , Alia Atlas , "The IESG" CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "Zhaohui (Jeffrey) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) Thread-Index: AQHSsx16Ya7h52QeOUmDSLg7l0/3XKHBlYIAgACgoQA= Date: Wed, 12 Apr 2017 19:48:49 +0000 Message-ID: <37F7F0F8-25C7-4C22-9663-75D129365193@cisco.com> References: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:48:54 -0000 U2FtaToNCg0KSGkhDQoNCkxldOKAmXMgZ28gYWhlYWQgYW5kIGFkZCB0aGUgdGV4dCB0byBleHBs YWluIHRoZSBvcGVyYXRpb24gd2l0aCBWWExBTiDigJMgSSB0aGluayB0aGF0IHRoZSByZWZlcmVu Y2UgdG8gcmZjNzM0OCBzaG91bGQgYmUgTm9ybWF0aXZlLg0KDQpJ4oCZbGwgdGFrZSBjYXJlIG9m IGRlYWxpbmcgd2l0aCB0aGUgZG93bnJlZiB3aGVuIHdl4oCZcmUgcmVhZHkgd2l0aCB0aGUgbmV3 IHRleHQuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCg0KDQoNCg0KT24gNC8xMi8xNywgMjox NCBQTSwgIlNhbWkgQm91dHJvcyIgPHNib3V0cm9zQHZtd2FyZS5jb20+IHdyb3RlOg0KDQpIaSBB bGlhLA0KDQpQbGVhc2Ugc2VlIGNvbW1lbnRzIGlubGluZS4NCg0KDQpPbiA0LzExLzE3LCA0OjQz IFBNLCAiQWxpYSBBdGxhcyIgPGFrYXRsYXNAZ21haWwuY29tPiB3cm90ZToNCg0KPkFsaWEgQXRs YXMgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ZHJhZnQt aWV0Zi1iZXNzLWV2cG4tdnB3cy0xMTogRGlzY3Vzcw0KPg0KPldoZW4gcmVzcG9uZGluZywgcGxl YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPmVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzDQo+aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+UGxl YXNlIHJlZmVyIHRvIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50X2Rpc2N1c3MtMkRjcml0ZXJpYS5o dG1sJmQ9RHdJQ2FRJmM9dWlsYUs5MEQ0VE9Wb0g1OEpOWFJnUSZyPUlWemNUUkxRZHB0YTA4TDBi X3kyekRrcXZ3SmhSS01DQWJYLTJLLUxWOTgmbT03OHNQTkVySS1ybGpTRkFhTTViNzZfUWFEU1R6 MkJEXzhueTBEeGNmNHNNJnM9czhvYXQ3dlVEeDZOSFYwdk9laFVsX2ZManNMSHNUcW1odDN4SUhv T3IySSZlPSANCj5mb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP TU1FTlQgcG9zaXRpb25zLg0KPg0KPg0KPlRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2Rv Y19kcmFmdC0yRGlldGYtMkRiZXNzLTJEZXZwbi0yRHZwd3NfJmQ9RHdJQ2FRJmM9dWlsYUs5MEQ0 VE9Wb0g1OEpOWFJnUSZyPUlWemNUUkxRZHB0YTA4TDBiX3kyekRrcXZ3SmhSS01DQWJYLTJLLUxW OTgmbT03OHNQTkVySS1ybGpTRkFhTTViNzZfUWFEU1R6MkJEXzhueTBEeGNmNHNNJnM9TWxKS1hp c1FUcjFhaGVTOGhhaHR5LWlGRE9DU19HaE0zN1gybE1VQUg1NCZlPSANCj4NCj4NCj4NCj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+RElTQ1VTUzoNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+Rmlyc3QsIHRoYW5rIHlv dSBmb3IgYSBjbGVhcmx5IHdyaXR0ZW4gZG9jdW1lbnQgdGhhdCBjb250YWluZWQgZW5vdWdoDQo+ Y29udGV4dCB0byB0cmlnZ2VyIG15IGhhenkNCj5tZW1vcnkgb2Ygc29tZSBvZiB0aGUgdGVjaG5p Y2FsIGRldGFpbHMuDQo+DQo+TXkgY29uY2VybiBpcyBhcm91bmQgdGhpcyBwYXJhZ3JhcGggaW4g dGhlIEludHJvZHVjdGlvbjoNCj4NCj4iVGhlIE1QTFMgbGFiZWwgdmFsdWUgaW4gdGhlIEV0aGVy bmV0IEEtRCByb3V0ZSBjYW4gYmUgc2V0IHRvIHRoZQ0KPiAgIFZYTEFOIE5ldHdvcmsgSWRlbnRp ZmllciAoVk5JKSBmb3IgVlhMQU4gZW5jYXAsIGFuZCB0aGlzIFZOSSBtYXkNCj5oYXZlDQo+ICAg YSBnbG9iYWwgc2NvcGUgb3IgbG9jYWwgc2NvcGUgcGVyIFBFIGFuZCBtYXkgYWxzbyBiZSBlcXVh bCB0byB0aGUNCj4gICBWUFdTIHNlcnZpY2UgaW5zdGFuY2UgaWRlbnRpZmllciBzZXQgaW4gdGhl IEV0aGVybmV0IEEtRCByb3V0ZS4NCj4iDQo+DQo+Rmlyc3QsIEkgcmVjb2duaXplIHRoYXQgZm9s a3MgaGF2ZSBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQgRVZQTiB3aXRoDQo+VlhMQU4uDQo+VGhh dCdzIGZpbmUuICBUaGVyZSBpcyBhbiBJU0UgUkZDIDczNDggdGhhdCBkZXNjcmliZXMgVlhMQU4u ICAgRGVwZW5kaW5nDQo+b24gd2hhdA0KPnlvdSAoYXV0aG9ycywgc2hlcGhlcmQsIEFELCBXRykg ZGVjaWRlIHRvIGRvIGFib3V0IHRoZSByZXN0IG9mIG15DQo+Y29uY2VybiwgaXQgaXMNCj5saWtl bHkgdGhhdCB0aGlzIHNob3VsZCBiZSBub3JtYXRpdmUgcmVmZXJlbmNlcyAtIHdoaWNoIHdvdWxk IGJlIGENCj5kb3ducmVmLg0KDQpJIGNhbiBhZGQgdGhlIDczNDggYXMgYSBub3JtYXRpdmUgcmVm ZXJlbmNlLg0KDQo+DQo+U2Vjb25kLCB0aGUgcGFyYWdyYXBoIGhlcmUgaXNuJ3QgcmVhbGx5IGFk ZXF1YXRlIHRvIGRlc2NyaWJlIGhvdyB0bw0KPmltcGxlbWVudCB0aGUNCj5mdW5jdGlvbmFsaXR5 LiAgIEkgZG9uJ3Qgc2VlIGhvdzoNCj4gICAgYSkgVGhlIGluZ3Jlc3MgUEUgZGVjaWRlcyB3aGlj aCBWTklzIGl0IGNhbiBzZW5kIGJhc2VkIHVwb24gdGhlDQo+Vk5JPU1QTFNfbGFiZWwNCj4gICAg ICAgIGZyb20gdGhlIGVncmVzcy4gICBJcyB0aGVyZSBhbiBhc3N1bXB0aW9uIHRoYXQgVlhMQU4g YWxsb3dzDQo+c2VuZGluZyBhbGwgVk5JcyBhY3Jvc3MNCj4gICAgICAgIHRoZSBwYXJ0aWN1bGFy IFZQV1MsIHdoZXRoZXIgcG9ydC1iYXNlZCwgVkxBTi1iYXNlZCwgZXRjPw0KDQpXZSBhcmUgc2ln bmFsaW5nIEV0aGVybmV0IEEtRCByb3V0ZSBwZXIgVlBXUyBpbnN0YW5jZSwgYW5kIGluIHRoZXJl IHdlIHdpbGwgc2lnbmFsIA0KVk5JIGluc3RlYWQgb2YgYW4gTVBMUyBsYWJlbCBmb3IgVnhMQU4g ZW5jYXAuDQoNCj4gICAgYikgSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0aGF0IHRoZSBlZ3Jlc3Mg UEUtYWR2ZXJ0aXNlZCBNUExTIGxhYmVsDQo+YWxzbyBpbmRpY2F0ZXMgdGhlDQo+ICAgICAgICAg Vk5JIHRvIGJlIHVzZWQ/ICANCg0KRVZQTiBjYW4gd29yayB3aXRoIGRpZmZlcmVudCBlbmNhcHN1 bGF0aW9ucyBhIEJHUCBUdW5uZWwgRW5jYXBzdWxhdGlvbiBBdHRyaWJ1dGUgDQpUaGF0IHNwZWNp ZmllcyB0aGUgdHVubmVsIHR5cGUgd2lsbCBiZSBhZGRlZCB0byB0aGUgRXRoZXJuZXQgQS1EIHJv dXRlLg0KDQoNCj5UaGF0IHNlZW1zIGxpa2UgYW5vdGhlciBtb2RlLCBsaWtlIHRoZQ0KPlZMQU4t YmFzZWQgc2VydmljZSwgZXhjZXB0DQo+ICAgICAgICAgaXQgaXMgcGVyaGFwcyBWTkkgKyBWTEFO LWJhc2VkIHNlcnZpY2U/DQoNClRoZSBkcmFmdCBsaXN0cyBjbGVhcmx5IHRoZSBkaWZmZXJlbnQg c2VydmljZSBpbnRlcmZhY2UgdHlwZXMsIGFuZCB0aGVyZSB3aWxsIA0KYmUgb25seSBvbmUgVk5J IHBlciBWUFdTIGluc3RhbmNlIHdldGhlciB0aGlzIGlzIFZsYW4gb3IgcG9ydCBiYXNlZC4NCg0K Pg0KPlBsZWFzZSBkb24ndCB0YWtlIHRoaXMgRGlzY3VzcyBhcyBhIHJlYXNvbiB0byByZW1vdmUg dGhlIHBhcmFncmFwaCBhbmQNCj50aGUgaW1wbGllZCBmdW5jdGlvbmFsaXR5Lg0KPklmIGl0J3Mg aW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIChhbmQgSSB0aGluayBpdCBpcykgLSB0aGVuIHdoYXQg SSByZWFsbHkNCj53YW50IGlzIHRvIGp1c3QgaGF2ZSBpdA0KPmFkZXF1YXRlbHkgd3JpdHRlbiBk b3duIHNvIHRoYXQgb3RoZXJzIGNhbiBpbnRlcm9wZXJhYmx5IGltcGxlbWVudC4gIFRoZQ0KPmRv d25yZWYgdG8gVlhMQU4NCj5zaG91bGQganVzdCBiZSBhIG1hdHRlciBvZiBwcm9jZXNzIG51aXNh bmNlIChpLmUuIGFub3RoZXIgSUVURiBMYXN0IENhbGwNCj5hbmQgaGFuZGxpbmcgYW55IGNvbmNl cm5zKS4NCj4NCg0KU2hvdWxkIEkgYWRkIHRoZSA3MzQ4IGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5j ZT8NCg0KDQoNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Q09NTUVOVDoNCj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ DQo+MSkgKE5pdCkgU2VjIDMuMSAiVGhpcyBkcmFmdCIgZm9yIGFuIFJGQyBzaG91bGQgYmUgIlRo aXMgZG9jdW1lbnQiIG9yDQo+IlRoaXMgc3BlY2lmaWNhdGlvbiIgb3IuLi4NCg0KV2lsbCBmaXgu DQo+DQo+MikgU2VjIDMuMTogICIgICAgQyAgICAgIElmIHNldCB0byAxLCBhIENvbnRyb2wgd29y ZCBbUkZDNDQ0OF0gTVVTVCBiZQ0KPnByZXNlbnQgd2hlbiBzZW5kaW5nIEVWUE4gcGFja2V0cyB0 byB0aGlzIFBFLiINCj4gICBHaXZlbiBkaXNjdXNzaW9ucyB3aXRoIElFRUUgYWJvdXQgcmVhbCBN QUNzIHN0YXJ0aW5nIHdpdGggNCBhbmQgNiBpbg0KPnRvcCBuaWJibGUsIGFkZGluZyBhIHN0YXRl bWVudCBhYm91dCBpdCBiZWluZyBCQ1AgdG8gaW5jbHVkZQ0KPiAgIHRoZSBjb250cm9sIHdvcmQg KHVubGVzcyB1c2luZyBFbnRyb3B5IExhYmVsKSB3b3VsZCBiZSBhIGdvb2QgaWRlYS4NCj4NCkNv dWxkIHlvdSBzdWdnZXN0IHNvbWUgdGV4dD8gDQoNClNob3VsZCBJIHN1Ym1pdCAtMTIgd2l0aCB0 aGUgY2hhbmdlcz8NCg0KVGhhbmtzLA0KDQpTYW1pDQo+DQoNCg0K From nobody Wed Apr 12 13:20:04 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD68F129A99; Wed, 12 Apr 2017 13:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It9cj6cL2-LQ; Wed, 12 Apr 2017 13:20:00 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0105.outbound.protection.outlook.com [104.47.34.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F232D12778E; Wed, 12 Apr 2017 13:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ut9Chj5O57lskO3kclOCMtzJOQtpHzCm1TnmNDjf8dI=; b=a4D7luY+PreYv4C5MT1Q87Yk0EfL3FF5EBxw6VnKt5e9gxD+NtLufxvWI5YgNp5OsZErEWOR3EWNXnapjhdY4coDpI2IGFiS0jZPOa7ZmZvwW5emtLc8HUVEVTQCPjIEReErszJg2vDECogQJ/SDGtsUuPnRQVMsPOa/a9V3lB0= Received: from CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) by CY4PR05MB3141.namprd05.prod.outlook.com (10.172.155.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 12 Apr 2017 20:19:58 +0000 Received: from CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) by CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) with mapi id 15.01.1047.006; Wed, 12 Apr 2017 20:19:57 +0000 From: John E Drake To: "Alvaro Retana (aretana)" , Sami Boutros , Alia Atlas , The IESG CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) Thread-Index: AQHSsx1zKv/EapKDaUOJhsksFTeynKHCCuuAgAAadYCAAAgZYA== Date: Wed, 12 Apr 2017 20:19:57 +0000 Message-ID: References: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> <37F7F0F8-25C7-4C22-9663-75D129365193@cisco.com> In-Reply-To: <37F7F0F8-25C7-4C22-9663-75D129365193@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3141; 7:Ze6n8QYbGS0xj6VFMbITrWdQ60YbOnffK/9fTZwSx5fVddsULxFZSQkx1sdB2GvLZdO4FxpXntDJE1Ng9frsprU6+tqpu8o7N4A+PgXysxDkb+l6nApvDYusz+YC0zCp5UEQESmH36DfcMd6z81SXmgfMd0A9IppkWGXp+nZTd2W7QJSg92gJ20JIwO6N3UpYWTyF9aF4qvaHS96Wd48acDxiilV0fyU7PNrhkEAmIx6i1VO1OZriyRlhmL5ieKMuiAJ5WDs1glr0QN8VaQsFgPLS8esaLGTp6B2Qi3gyljMTtC2/WBGQKJ9AjKZkpNQKUEU6uN4zdRxBX1fftzsRA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39410400002)(39400400002)(39850400002)(39840400002)(377454003)(43544003)(13464003)(24454002)(85664002)(6436002)(2900100001)(8936002)(74316002)(7736002)(8676002)(81166006)(122556002)(305945005)(25786009)(2950100002)(189998001)(5660300001)(6506006)(77096006)(345774005)(7696004)(86362001)(33656002)(38730400002)(6116002)(3280700002)(3660700001)(3846002)(2906002)(102836003)(230783001)(53546009)(66066001)(53936002)(4326008)(9686003)(39060400002)(229853002)(6306002)(54356999)(76176999)(99286003)(54906002)(50986999)(575784001)(55016002)(6246003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3141; H:CO2PR05MB618.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: e38c4b20-693d-4d9b-55cb-08d481e14a14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR05MB3141; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(10436049006162)(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(6072148); SRVR:CY4PR05MB3141; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3141; x-forefront-prvs: 027578BB13 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 20:19:57.5772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3141 Archived-At: Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:20:03 -0000 U2FtaSwNCg0KSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIHVzZSBhIGdsb2JhbCBWTkkgYmVjYXVz ZSBpZiB3ZSBkbyB3ZSB3aWxsIGJlIGxpbWl0ZWQgdG8gb25lIGNpcmN1aXQgcGVyIGdsb2JhbCBW TkkgZHVlIHRvIHRoZSBmYWN0IHRoYXQgd2UgZGVtdXggdHJhZmZpYyBzdHJpY3RseSB1c2luZyB0 aGUgbGFiZWwgdmFsdWUgYW5kIG5vdCB0aGUgTUFDIGFkZHJlc3MuDQoNCllvdXJzIElycmVzcGVj dGl2ZWx5LA0KDQpKb2huDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSBbbWFpbHRvOmFyZXRhbmFAY2lzY28uY29tXQ0KPiBT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDEyLCAyMDE3IDM6NDkgUE0NCj4gVG86IFNhbWkgQm91dHJv cyA8c2JvdXRyb3NAdm13YXJlLmNvbT47IEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPjsN Cj4gVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLWJlc3MtZXZwbi12 cHdzQGlldGYub3JnOyBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZw0KPiA8enpoYW5nQGp1bmlwZXIu bmV0PjsgYmVzcy1jaGFpcnNAaWV0Zi5vcmc7IGJlc3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IEFsaWEgQXRsYXMnIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tdnB3cy0xMTogKHdp dGggRElTQ1VTUw0KPiBhbmQgQ09NTUVOVCkNCj4gDQo+IFNhbWk6DQo+IA0KPiBIaSENCj4gDQo+ IExldOKAmXMgZ28gYWhlYWQgYW5kIGFkZCB0aGUgdGV4dCB0byBleHBsYWluIHRoZSBvcGVyYXRp b24gd2l0aCBWWExBTiDigJMgSSB0aGluaw0KPiB0aGF0IHRoZSByZWZlcmVuY2UgdG8gcmZjNzM0 OCBzaG91bGQgYmUgTm9ybWF0aXZlLg0KPiANCj4gSeKAmWxsIHRha2UgY2FyZSBvZiBkZWFsaW5n IHdpdGggdGhlIGRvd25yZWYgd2hlbiB3ZeKAmXJlIHJlYWR5IHdpdGggdGhlIG5ldyB0ZXh0Lg0K PiANCj4gVGhhbmtzIQ0KPiANCj4gQWx2YXJvLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBP biA0LzEyLzE3LCAyOjE0IFBNLCAiU2FtaSBCb3V0cm9zIiA8c2JvdXRyb3NAdm13YXJlLmNvbT4g d3JvdGU6DQo+IA0KPiBIaSBBbGlhLA0KPiANCj4gUGxlYXNlIHNlZSBjb21tZW50cyBpbmxpbmUu DQo+IA0KPiANCj4gT24gNC8xMS8xNywgNDo0MyBQTSwgIkFsaWEgQXRsYXMiIDxha2F0bGFzQGdt YWlsLmNvbT4gd3JvdGU6DQo+IA0KPiA+QWxpYSBBdGxhcyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPmRyYWZ0LWlldGYtYmVzcy1ldnBuLXZwd3MtMTE6 IERpc2N1c3MNCj4gPg0KPiA+V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID5lbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiA+aW50 cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+UGxlYXNlIHJlZmVy IHRvDQo+ID5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19pZXNnXw0KPiA+c3RhdGVtZW50X2Rpc2N1c3MtDQo+IDJEY3JpdGVy aWEuaHRtbCZkPUR3SUNhUSZjPXVpbGFLOTBENFRPVm9INThKTlhSZ1Emcj1JDQo+ID5WemNUUkxR ZHB0YTA4TDBiX3kyekRrcXZ3SmhSS01DQWJYLTJLLUxWOTgmbT03OHNQTkVySS0NCj4gcmxqU0ZB YU01Yjc2X1FhRFMNCj4gPlR6MkJEXzhueTBEeGNmNHNNJnM9czhvYXQ3dlVEeDZOSFYwdk9laFVs X2ZManNMSHNUcW1odDN4SUhvT3IySSZlDQo+ID0NCj4gPmZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4NCj4gPg0KPiA+VGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KPiA+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm8NCj4gPnJnX2RvY19kcmFmdC0yRGlldGYtMkRiZXNz LTJEZXZwbi0NCj4gMkR2cHdzXyZkPUR3SUNhUSZjPXVpbGFLOTBENFRPVm9INThKTg0KPiA+WFJn USZyPUlWemNUUkxRZHB0YTA4TDBiX3kyekRrcXZ3SmhSS01DQWJYLTJLLUxWOTgmbT03OHNQTkVy SS0NCj4gcmxqU0ZBYU01DQo+ID5iNzZfUWFEU1R6MkJEXzhueTBEeGNmNHNNJnM9TWxKS1hpc1FU cjFhaGVTOGhhaHR5LQ0KPiBpRkRPQ1NfR2hNMzdYMmxNVUFINTQNCj4gPiZlPQ0KPiA+DQo+ID4N Cj4gPg0KPiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+RElTQ1VTUzoNCj4gPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pg0KPiA+Rmlyc3QsIHRoYW5rIHlvdSBmb3IgYSBjbGVhcmx5IHdyaXR0ZW4gZG9jdW1lbnQgdGhh dCBjb250YWluZWQgZW5vdWdoDQo+ID5jb250ZXh0IHRvIHRyaWdnZXIgbXkgaGF6eSBtZW1vcnkg b2Ygc29tZSBvZiB0aGUgdGVjaG5pY2FsIGRldGFpbHMuDQo+ID4NCj4gPk15IGNvbmNlcm4gaXMg YXJvdW5kIHRoaXMgcGFyYWdyYXBoIGluIHRoZSBJbnRyb2R1Y3Rpb246DQo+ID4NCj4gPiJUaGUg TVBMUyBsYWJlbCB2YWx1ZSBpbiB0aGUgRXRoZXJuZXQgQS1EIHJvdXRlIGNhbiBiZSBzZXQgdG8g dGhlDQo+ID4gICBWWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKFZOSSkgZm9yIFZYTEFOIGVuY2Fw LCBhbmQgdGhpcyBWTkkgbWF5DQo+ID5oYXZlDQo+ID4gICBhIGdsb2JhbCBzY29wZSBvciBsb2Nh bCBzY29wZSBwZXIgUEUgYW5kIG1heSBhbHNvIGJlIGVxdWFsIHRvIHRoZQ0KPiA+ICAgVlBXUyBz ZXJ2aWNlIGluc3RhbmNlIGlkZW50aWZpZXIgc2V0IGluIHRoZSBFdGhlcm5ldCBBLUQgcm91dGUu DQo+ID4iDQo+ID4NCj4gPkZpcnN0LCBJIHJlY29nbml6ZSB0aGF0IGZvbGtzIGhhdmUgaW1wbGVt ZW50ZWQgYW5kIGRlcGxveWVkIEVWUE4gd2l0aA0KPiA+VlhMQU4uDQo+ID5UaGF0J3MgZmluZS4g IFRoZXJlIGlzIGFuIElTRSBSRkMgNzM0OCB0aGF0IGRlc2NyaWJlcyBWWExBTi4gICBEZXBlbmRp bmcNCj4gPm9uIHdoYXQNCj4gPnlvdSAoYXV0aG9ycywgc2hlcGhlcmQsIEFELCBXRykgZGVjaWRl IHRvIGRvIGFib3V0IHRoZSByZXN0IG9mIG15DQo+ID5jb25jZXJuLCBpdCBpcyBsaWtlbHkgdGhh dCB0aGlzIHNob3VsZCBiZSBub3JtYXRpdmUgcmVmZXJlbmNlcyAtIHdoaWNoDQo+ID53b3VsZCBi ZSBhIGRvd25yZWYuDQo+IA0KPiBJIGNhbiBhZGQgdGhlIDczNDggYXMgYSBub3JtYXRpdmUgcmVm ZXJlbmNlLg0KPiANCj4gPg0KPiA+U2Vjb25kLCB0aGUgcGFyYWdyYXBoIGhlcmUgaXNuJ3QgcmVh bGx5IGFkZXF1YXRlIHRvIGRlc2NyaWJlIGhvdyB0bw0KPiA+aW1wbGVtZW50IHRoZQ0KPiA+ZnVu Y3Rpb25hbGl0eS4gICBJIGRvbid0IHNlZSBob3c6DQo+ID4gICAgYSkgVGhlIGluZ3Jlc3MgUEUg ZGVjaWRlcyB3aGljaCBWTklzIGl0IGNhbiBzZW5kIGJhc2VkIHVwb24gdGhlDQo+ID5WTkk9TVBM U19sYWJlbA0KPiA+ICAgICAgICBmcm9tIHRoZSBlZ3Jlc3MuICAgSXMgdGhlcmUgYW4gYXNzdW1w dGlvbiB0aGF0IFZYTEFOIGFsbG93cw0KPiA+c2VuZGluZyBhbGwgVk5JcyBhY3Jvc3MNCj4gPiAg ICAgICAgdGhlIHBhcnRpY3VsYXIgVlBXUywgd2hldGhlciBwb3J0LWJhc2VkLCBWTEFOLWJhc2Vk LCBldGM/DQo+IA0KPiBXZSBhcmUgc2lnbmFsaW5nIEV0aGVybmV0IEEtRCByb3V0ZSBwZXIgVlBX UyBpbnN0YW5jZSwgYW5kIGluIHRoZXJlIHdlIHdpbGwNCj4gc2lnbmFsIFZOSSBpbnN0ZWFkIG9m IGFuIE1QTFMgbGFiZWwgZm9yIFZ4TEFOIGVuY2FwLg0KPiANCj4gPiAgICBiKSBJcyB0aGVyZSBh biBhc3N1bXB0aW9uIHRoYXQgdGhlIGVncmVzcyBQRS1hZHZlcnRpc2VkIE1QTFMgbGFiZWwNCj4g PmFsc28gaW5kaWNhdGVzIHRoZQ0KPiA+ICAgICAgICAgVk5JIHRvIGJlIHVzZWQ/DQo+IA0KPiBF VlBOIGNhbiB3b3JrIHdpdGggZGlmZmVyZW50IGVuY2Fwc3VsYXRpb25zIGEgQkdQIFR1bm5lbCBF bmNhcHN1bGF0aW9uDQo+IEF0dHJpYnV0ZSBUaGF0IHNwZWNpZmllcyB0aGUgdHVubmVsIHR5cGUg d2lsbCBiZSBhZGRlZCB0byB0aGUgRXRoZXJuZXQgQS1EIHJvdXRlLg0KPiANCj4gDQo+ID5UaGF0 IHNlZW1zIGxpa2UgYW5vdGhlciBtb2RlLCBsaWtlIHRoZQ0KPiA+VkxBTi1iYXNlZCBzZXJ2aWNl LCBleGNlcHQNCj4gPiAgICAgICAgIGl0IGlzIHBlcmhhcHMgVk5JICsgVkxBTi1iYXNlZCBzZXJ2 aWNlPw0KPiANCj4gVGhlIGRyYWZ0IGxpc3RzIGNsZWFybHkgdGhlIGRpZmZlcmVudCBzZXJ2aWNl IGludGVyZmFjZSB0eXBlcywgYW5kIHRoZXJlIHdpbGwNCj4gYmUgb25seSBvbmUgVk5JIHBlciBW UFdTIGluc3RhbmNlIHdldGhlciB0aGlzIGlzIFZsYW4gb3IgcG9ydCBiYXNlZC4NCj4gDQo+ID4N Cj4gPlBsZWFzZSBkb24ndCB0YWtlIHRoaXMgRGlzY3VzcyBhcyBhIHJlYXNvbiB0byByZW1vdmUg dGhlIHBhcmFncmFwaCBhbmQNCj4gPnRoZSBpbXBsaWVkIGZ1bmN0aW9uYWxpdHkuDQo+ID5JZiBp dCdzIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCAoYW5kIEkgdGhpbmsgaXQgaXMpIC0gdGhlbiB3 aGF0IEkgcmVhbGx5DQo+ID53YW50IGlzIHRvIGp1c3QgaGF2ZSBpdA0KPiA+YWRlcXVhdGVseSB3 cml0dGVuIGRvd24gc28gdGhhdCBvdGhlcnMgY2FuIGludGVyb3BlcmFibHkgaW1wbGVtZW50LiAg VGhlDQo+ID5kb3ducmVmIHRvIFZYTEFODQo+ID5zaG91bGQganVzdCBiZSBhIG1hdHRlciBvZiBw cm9jZXNzIG51aXNhbmNlIChpLmUuIGFub3RoZXIgSUVURiBMYXN0IENhbGwNCj4gPmFuZCBoYW5k bGluZyBhbnkgY29uY2VybnMpLg0KPiA+DQo+IA0KPiBTaG91bGQgSSBhZGQgdGhlIDczNDggYXMg YSBub3JtYXRpdmUgcmVmZXJlbmNlPw0KPiANCj4gDQo+IA0KPiA+DQo+ID4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID5DT01NRU5UOg0KPiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4xKSAoTml0KSBTZWMgMy4x ICJUaGlzIGRyYWZ0IiBmb3IgYW4gUkZDIHNob3VsZCBiZSAiVGhpcyBkb2N1bWVudCIgb3INCj4g PiJUaGlzIHNwZWNpZmljYXRpb24iIG9yLi4uDQo+IA0KPiBXaWxsIGZpeC4NCj4gPg0KPiA+Mikg U2VjIDMuMTogICIgICAgQyAgICAgIElmIHNldCB0byAxLCBhIENvbnRyb2wgd29yZCBbUkZDNDQ0 OF0gTVVTVCBiZQ0KPiA+cHJlc2VudCB3aGVuIHNlbmRpbmcgRVZQTiBwYWNrZXRzIHRvIHRoaXMg UEUuIg0KPiA+ICAgR2l2ZW4gZGlzY3Vzc2lvbnMgd2l0aCBJRUVFIGFib3V0IHJlYWwgTUFDcyBz dGFydGluZyB3aXRoIDQgYW5kIDYgaW4NCj4gPnRvcCBuaWJibGUsIGFkZGluZyBhIHN0YXRlbWVu dCBhYm91dCBpdCBiZWluZyBCQ1AgdG8gaW5jbHVkZQ0KPiA+ICAgdGhlIGNvbnRyb2wgd29yZCAo dW5sZXNzIHVzaW5nIEVudHJvcHkgTGFiZWwpIHdvdWxkIGJlIGEgZ29vZCBpZGVhLg0KPiA+DQo+ IENvdWxkIHlvdSBzdWdnZXN0IHNvbWUgdGV4dD8NCj4gDQo+IFNob3VsZCBJIHN1Ym1pdCAtMTIg d2l0aCB0aGUgY2hhbmdlcz8NCj4gDQo+IFRoYW5rcywNCj4gDQo+IFNhbWkNCj4gPg0KPiANCg0K From nobody Wed Apr 12 13:37:49 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9D129ABD; Wed, 12 Apr 2017 13:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNUWJi1R8VRZ; Wed, 12 Apr 2017 13:37:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0B2120227; Wed, 12 Apr 2017 13:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16391; q=dns/txt; s=iport; t=1492029463; x=1493239063; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KgNHmPYZjyUmiXfeCtvuZfODyuAYMUrrFIdbP8TV+ys=; b=NNlEiRpEPSO7DBQruAlElZV2niH//00Bi3hGUtCmu9ku1YVZ2T2kUEY7 3TR9SydKjMi3R6fGi4jJqqvG7ZcBBmNKs5QsFoDD8v15pO0SbzmKKpc6Z rGlCsy3l3qkv/p/fewMv3d3+IjhcpJk8G4UweBuCCz7pTKDxji0rs2gvW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQDBj+5Y/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm46K2GBC415kVSIGogKhTWCDyyFeAKEAT8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQEDLUwMBAIBCBEDAQEBAQkeBw8SERQJCAIEAQ0FiX4DFQ6rX4cwDYNTA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWILoMXglFGgREKBwE8hUUFh1SBU5MoOwG?= =?us-ascii?q?HAYcchEOBf4UuiheLAoh/AR84fQhbFYVRgUp1AQGGYw8XghcBAQE?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208,217";a="221807409" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 20:37:41 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3CKbfeX026574 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 20:37:41 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 16:37:40 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 16:37:40 -0400 From: "Ali Sajassi (sajassi)" To: John E Drake , "Alvaro Retana (aretana)" , Sami Boutros , Alia Atlas , The IESG CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) Thread-Index: AQHSsx1yAy4qtNKAdE62Naw9yxd7kqHCTfmAgAAadYCAAAizgP//wea7 Date: Wed, 12 Apr 2017 20:37:40 +0000 Message-ID: References: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> <37F7F0F8-25C7-4C22-9663-75D129365193@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_f6bftof55agadukglwg2f1y71492029285522emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:37:47 -0000 --_000_f6bftof55agadukglwg2f1y71492029285522emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi John, Still that gives us 16 millions P2P EVCs. Cheers, Ali Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: John E Drake Date: 4/12/17 1:20 PM (GMT-08:00) To: "Alvaro Retana (aretana)" , Sami Boutros , Alia Atlas , The IESG Cc: draft-ietf-bess-evpn-vpws@ietf.org, "Jeffrey (Zhaohui) Zhang" , bess-chairs@ietf.org, bess@ietf.org Subject: RE: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DIS= CUSS and COMMENT) Sami, I don't think we want to use a global VNI because if we do we will be limit= ed to one circuit per global VNI due to the fact that we demux traffic stri= ctly using the label value and not the MAC address. Yours Irrespectively, John > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] > Sent: Wednesday, April 12, 2017 3:49 PM > To: Sami Boutros ; Alia Atlas ; > The IESG > Cc: draft-ietf-bess-evpn-vpws@ietf.org; Jeffrey (Zhaohui) Zhang > ; bess-chairs@ietf.org; bess@ietf.org > Subject: Re: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with D= ISCUSS > and COMMENT) > > Sami: > > Hi! > > Let=92s go ahead and add the text to explain the operation with VXLAN =96= I think > that the reference to rfc7348 should be Normative. > > I=92ll take care of dealing with the downref when we=92re ready with the = new text. > > Thanks! > > Alvaro. > > > > > > > On 4/12/17, 2:14 PM, "Sami Boutros" wrote: > > Hi Alia, > > Please see comments inline. > > > On 4/11/17, 4:43 PM, "Alia Atlas" wrote: > > >Alia Atlas has entered the following ballot position for > >draft-ietf-bess-evpn-vpws-11: Discuss > > > >When responding, please keep the subject line intact and reply to all > >email addresses included in the To and CC lines. (Feel free to cut this > >introductory paragraph, however.) > > > > > >Please refer to > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_iesg= _ > >statement_discuss- > 2Dcriteria.html&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DI > >VzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D78sPNErI- > rljSFAaM5b76_QaDS > >Tz2BD_8ny0Dxcf4sM&s=3Ds8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoOr2I&e > =3D > >for more information about IESG DISCUSS and COMMENT positions. > > > > > >The document, along with other ballot positions, can be found here: > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.= o > >rg_doc_draft-2Dietf-2Dbess-2Devpn- > 2Dvpws_&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JN > >XRgQ&r=3DIVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D78sPNErI- > rljSFAaM5 > >b76_QaDSTz2BD_8ny0Dxcf4sM&s=3DMlJKXisQTr1aheS8hahty- > iFDOCS_GhM37X2lMUAH54 > >&e=3D > > > > > > > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >First, thank you for a clearly written document that contained enough > >context to trigger my hazy memory of some of the technical details. > > > >My concern is around this paragraph in the Introduction: > > > >"The MPLS label value in the Ethernet A-D route can be set to the > > VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may > >have > > a global scope or local scope per PE and may also be equal to the > > VPWS service instance identifier set in the Ethernet A-D route. > >" > > > >First, I recognize that folks have implemented and deployed EVPN with > >VXLAN. > >That's fine. There is an ISE RFC 7348 that describes VXLAN. Depending > >on what > >you (authors, shepherd, AD, WG) decide to do about the rest of my > >concern, it is likely that this should be normative references - which > >would be a downref. > > I can add the 7348 as a normative reference. > > > > >Second, the paragraph here isn't really adequate to describe how to > >implement the > >functionality. I don't see how: > > a) The ingress PE decides which VNIs it can send based upon the > >VNI=3DMPLS_label > > from the egress. Is there an assumption that VXLAN allows > >sending all VNIs across > > the particular VPWS, whether port-based, VLAN-based, etc? > > We are signaling Ethernet A-D route per VPWS instance, and in there we wi= ll > signal VNI instead of an MPLS label for VxLAN encap. > > > b) Is there an assumption that the egress PE-advertised MPLS label > >also indicates the > > VNI to be used? > > EVPN can work with different encapsulations a BGP Tunnel Encapsulation > Attribute That specifies the tunnel type will be added to the Ethernet A-= D route. > > > >That seems like another mode, like the > >VLAN-based service, except > > it is perhaps VNI + VLAN-based service? > > The draft lists clearly the different service interface types, and there = will > be only one VNI per VPWS instance wether this is Vlan or port based. > > > > >Please don't take this Discuss as a reason to remove the paragraph and > >the implied functionality. > >If it's implemented and deployed (and I think it is) - then what I reall= y > >want is to just have it > >adequately written down so that others can interoperably implement. The > >downref to VXLAN > >should just be a matter of process nuisance (i.e. another IETF Last Call > >and handling any concerns). > > > > Should I add the 7348 as a normative reference? > > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or > >"This specification" or... > > Will fix. > > > >2) Sec 3.1: " C If set to 1, a Control word [RFC4448] MUST be > >present when sending EVPN packets to this PE." > > Given discussions with IEEE about real MACs starting with 4 and 6 in > >top nibble, adding a statement about it being BCP to include > > the control word (unless using Entropy Label) would be a good idea. > > > Could you suggest some text? > > Should I submit -12 with the changes? > > Thanks, > > Sami > > > --_000_f6bftof55agadukglwg2f1y71492029285522emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi John, 
Still that gives us 16 millions P2P EVCs. 

Cheers, 
Ali



Sent from my Veriz= on, Samsung Galaxy smartphone


-------- Original message --------
From: John E Drake <jdrake@juniper.net>
Date: 4/12/17 1:20 PM (GMT-08:00)
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, Sami Bou= tros <sboutros@vmware.com>, Alia Atlas <akatlas@gmail.com>, The= IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-vpws@ietf.org, "Jeffrey (Zhaohui) Zhang"= <zzhang@juniper.net>, bess-chairs@ietf.org, bess@ietf.org
Subject: RE: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DIS= CUSS and COMMENT)

Sami,

I don't think we want to use a global VNI because if we do we will be limit= ed to one circuit per global VNI due to the fact that we demux traffic stri= ctly using the label value and not the MAC address.

Yours Irrespectively,

John


> -----Original Message-----
> From: Alvaro Retana (aretana) [ma= ilto:aretana@cisco.com]
> Sent: Wednesday, April 12, 2017 3:49 PM
> To: Sami Boutros <sboutros@vmware.com>; Alia Atlas <akatlas@g= mail.com>;
> The IESG <iesg@ietf.org>
> Cc: draft-ietf-bess-evpn-vpws@ietf.org; Jeffrey (Zhaohui) Zhang
> <zzhang@juniper.net>; bess-chairs@ietf.org; bess@ietf.org
> Subject: Re: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (wit= h DISCUSS
> and COMMENT)
>
> Sami:
>
> Hi!
>
> Let=92s go ahead and add the text to explain the operation with VXLAN = =96 I think
> that the reference to rfc7348 should be Normative.
>
> I=92ll take care of dealing with the downref when we=92re ready with t= he new text.
>
> Thanks!
>
> Alvaro.
>
>
>
>
>
>
> On 4/12/17, 2:14 PM, "Sami Boutros" <sboutros@vmware.com&= gt; wrote:
>
> Hi Alia,
>
> Please see comments inline.
>
>
> On 4/11/17, 4:43 PM, "Alia Atlas" <akatlas@gmail.com> = wrote:
>
> >Alia Atlas has entered the following ballot position for
> >draft-ietf-bess-evpn-vpws-11: Discuss
> >
> >When responding, please keep the subject line intact and reply to = all
> >email addresses included in the To and CC lines. (Feel free to cut= this
> >introductory paragraph, however.)
> >
> >
> >Please refer to
> >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_iesg_
> >statement_discuss-
> 2Dcriteria.html&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3D= I
> >VzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D78sPNErI-
> rljSFAaM5b76_QaDS
> >Tz2BD_8ny0Dxcf4sM&s=3Ds8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoO= r2I&e
> =3D
> >for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> >The document, along with other ballot positions, can be found here= :
> >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= datatracker.ietf.o
> >rg_doc_draft-2Dietf-2Dbess-2Devpn-
> 2Dvpws_&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JN
> >XRgQ&r=3DIVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D7= 8sPNErI-
> rljSFAaM5
> >b76_QaDSTz2BD_8ny0Dxcf4sM&s=3DMlJKXisQTr1aheS8hahty-
> iFDOCS_GhM37X2lMUAH54
> >&e=3D
> >
> >
> >
> >------------------------------------------------------------------= ----
> >DISCUSS:
> >------------------------------------------------------------------= ----
> >
> >First, thank you for a clearly written document that contained eno= ugh
> >context to trigger my hazy memory of some of the technical details= .
> >
> >My concern is around this paragraph in the Introduction:
> >
> >"The MPLS label value in the Ethernet A-D route can be set to= the
> >   VXLAN Network Identifier (VNI) for VXLAN encap, and t= his VNI may
> >have
> >   a global scope or local scope per PE and may also be = equal to the
> >   VPWS service instance identifier set in the Ethernet = A-D route.
> >"
> >
> >First, I recognize that folks have implemented and deployed EVPN w= ith
> >VXLAN.
> >That's fine.  There is an ISE RFC 7348 that describes VXLAN.&= nbsp;  Depending
> >on what
> >you (authors, shepherd, AD, WG) decide to do about the rest of my<= br> > >concern, it is likely that this should be normative references - w= hich
> >would be a downref.
>
> I can add the 7348 as a normative reference.
>
> >
> >Second, the paragraph here isn't really adequate to describe how t= o
> >implement the
> >functionality.   I don't see how:
> >    a) The ingress PE decides which VNIs it can sen= d based upon the
> >VNI=3DMPLS_label
> >        from the egress. &= nbsp; Is there an assumption that VXLAN allows
> >sending all VNIs across
> >        the particular VPWS, wh= ether port-based, VLAN-based, etc?
>
> We are signaling Ethernet A-D route per VPWS instance, and in there we= will
> signal VNI instead of an MPLS label for VxLAN encap.
>
> >    b) Is there an assumption that the egress PE-ad= vertised MPLS label
> >also indicates the
> >         VNI to be used? >
> EVPN can work with different encapsulations a BGP Tunnel Encapsulation=
> Attribute That specifies the tunnel type will be added to the Ethernet= A-D route.
>
>
> >That seems like another mode, like the
> >VLAN-based service, except
> >         it is perhaps VNI= + VLAN-based service?
>
> The draft lists clearly the different service interface types, and the= re will
> be only one VNI per VPWS instance wether this is Vlan or port based. >
> >
> >Please don't take this Discuss as a reason to remove the paragraph= and
> >the implied functionality.
> >If it's implemented and deployed (and I think it is) - then what I= really
> >want is to just have it
> >adequately written down so that others can interoperably implement= .  The
> >downref to VXLAN
> >should just be a matter of process nuisance (i.e. another IETF Las= t Call
> >and handling any concerns).
> >
>
> Should I add the 7348 as a normative reference?
>
>
>
> >
> >------------------------------------------------------------------= ----
> >COMMENT:
> >------------------------------------------------------------------= ----
> >
> >1) (Nit) Sec 3.1 "This draft" for an RFC should be "= ;This document" or
> >"This specification" or...
>
> Will fix.
> >
> >2) Sec 3.1:  "    C   &nbs= p;  If set to 1, a Control word [RFC4448] MUST be
> >present when sending EVPN packets to this PE."
> >   Given discussions with IEEE about real MACs starting = with 4 and 6 in
> >top nibble, adding a statement about it being BCP to include
> >   the control word (unless using Entropy Label) would b= e a good idea.
> >
> Could you suggest some text?
>
> Should I submit -12 with the changes?
>
> Thanks,
>
> Sami
> >
>

--_000_f6bftof55agadukglwg2f1y71492029285522emailandroidcom_-- From nobody Wed Apr 12 14:00:07 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAC12EB49; Wed, 12 Apr 2017 14:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APfIn7rKSFxP; Wed, 12 Apr 2017 14:00:02 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0120.outbound.protection.outlook.com [104.47.34.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D87129ACC; Wed, 12 Apr 2017 14:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UwYRzaKGRwEIvA6GBzRA0bkATTDxoliXhz2bqWUhFjo=; b=V5h9diOcRtCTAFgxz9hDEjE7wp3eCxYR5WeubdaA1p734f1aZ79H/7ARQ/XznBAjB+oSOvPdWeK1uwoHvheJQO3pyGfgq4+ScXQkrA0EFDyTZuwdtqT9BId8wZIPflYHKtJFUm8TANMs3KcZAsCQKsspv0cnwwoIhkv46PyRp6g= Received: from CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) by MWHPR05MB3152.namprd05.prod.outlook.com (10.173.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 12 Apr 2017 21:00:01 +0000 Received: from CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) by CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) with mapi id 15.01.1047.006; Wed, 12 Apr 2017 21:00:00 +0000 From: John E Drake To: "Ali Sajassi (sajassi)" , "Alvaro Retana (aretana)" , Sami Boutros , Alia Atlas , The IESG CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) Thread-Index: AQHSsx1zKv/EapKDaUOJhsksFTeynKHCCuuAgAAadYCAAAgZYIAABY0AgAAFUWA= Date: Wed, 12 Apr 2017 21:00:00 +0000 Message-ID: References: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> <37F7F0F8-25C7-4C22-9663-75D129365193@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; MWHPR05MB3152; 7:ysMxfbPptJOFwpQQSXiAs1GjiplpJ1ue22RVKVfIELWIlDYPr0O0nsEbnD2/6U7K+B/olZfEgjEbf1Lw8ID95DhxjSJgyAETTSvh02wgIkd+RG1Nm8U1y/erjBwP4glm7Ww5cLK5ZOheY0WwtQBca1mBVZjkNXUC8EYQ/vJeJG3qSMoT2947j02NZSXAgxt6IeLchHTxBB8kY5ffyLM0BDHfr/qY+C+tcbqa0E96WiINjBSeYfOPPehoitrmH8ZeYlyhmdN7lp34rVjLOWTiuJV1lykaZ1uhH6M1jx3RU2JPx7glGm1HDC8gGIfUldCZfJqeFa/FBTBa6pq5eOdEVQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39410400002)(39840400002)(39860400002)(39450400003)(85664002)(43544003)(13464003)(24454002)(377454003)(8676002)(81166006)(53546009)(7906003)(25786009)(8936002)(66066001)(7736002)(2900100001)(4326008)(53936002)(74316002)(6436002)(236005)(54906002)(5660300001)(99286003)(54896002)(6306002)(6506006)(606005)(9686003)(93886004)(55016002)(6246003)(39060400002)(38730400002)(77096006)(3280700002)(2950100002)(7696004)(122556002)(345774005)(19609705001)(189998001)(230783001)(86362001)(3660700001)(575784001)(3846002)(102836003)(790700001)(6116002)(33656002)(76176999)(54356999)(229853002)(50986999)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3152; H:CO2PR05MB618.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 12826e03-dac4-4801-8cd2-08d481e6e281 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR05MB3152; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(10436049006162)(138986009662008)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR05MB3152; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3152; x-forefront-prvs: 027578BB13 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR05MB618B555E4095698E4AC7D5DC7030CO2PR05MB618namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 21:00:00.7278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3152 Archived-At: Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:00:06 -0000 --_000_CO2PR05MB618B555E4095698E4AC7D5DC7030CO2PR05MB618namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ali, That's correct, however ensuring global uniqueness when it is completely un= necessary seems like an imposition on the network administrators. Yours Irrespectively, John From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Wednesday, April 12, 2017 4:38 PM To: John E Drake ; Alvaro Retana (aretana) ; Sami Boutros ; Alia Atlas = ; The IESG Cc: draft-ietf-bess-evpn-vpws@ietf.org; Jeffrey (Zhaohui) Zhang ; bess-chairs@ietf.org; bess@ietf.org Subject: RE: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DIS= CUSS and COMMENT) Hi John, Still that gives us 16 millions P2P EVCs. Cheers, Ali Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: John E Drake > Date: 4/12/17 1:20 PM (GMT-08:00) To: "Alvaro Retana (aretana)" >= , Sami Boutros >, Alia Atla= s >, The IESG > Cc: draft-ietf-bess-evpn-vpws@ietf.org, "Jeffrey (Zhaohui) Zhang" >, bess-chairs@ietf.org, bess@ietf.org Subject: RE: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DIS= CUSS and COMMENT) Sami, I don't think we want to use a global VNI because if we do we will be limit= ed to one circuit per global VNI due to the fact that we demux traffic stri= ctly using the label value and not the MAC address. Yours Irrespectively, John > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] > Sent: Wednesday, April 12, 2017 3:49 PM > To: Sami Boutros >; Alia = Atlas >; > The IESG > > Cc: draft-ietf-bess-evpn-vpws@ietf.org; Jeffrey (Zhaohui) Zhang > >; bess-chairs@ietf.org; bess@ietf.org > Subject: Re: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with D= ISCUSS > and COMMENT) > > Sami: > > Hi! > > Let's go ahead and add the text to explain the operation with VXLAN - I t= hink > that the reference to rfc7348 should be Normative. > > I'll take care of dealing with the downref when we're ready with the new = text. > > Thanks! > > Alvaro. > > > > > > > On 4/12/17, 2:14 PM, "Sami Boutros" > wrote: > > Hi Alia, > > Please see comments inline. > > > On 4/11/17, 4:43 PM, "Alia Atlas" > wrote: > > >Alia Atlas has entered the following ballot position for > >draft-ietf-bess-evpn-vpws-11: Discuss > > > >When responding, please keep the subject line intact and reply to all > >email addresses included in the To and CC lines. (Feel free to cut this > >introductory paragraph, however.) > > > > > >Please refer to > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_iesg= _ > >statement_discuss- > 2Dcriteria.html&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DI > >VzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D78sPNErI- > rljSFAaM5b76_QaDS > >Tz2BD_8ny0Dxcf4sM&s=3Ds8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoOr2I&e > =3D > >for more information about IESG DISCUSS and COMMENT positions. > > > > > >The document, along with other ballot positions, can be found here: > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.= o > >rg_doc_draft-2Dietf-2Dbess-2Devpn- > 2Dvpws_&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JN > >XRgQ&r=3DIVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D78sPNErI- > rljSFAaM5 > >b76_QaDSTz2BD_8ny0Dxcf4sM&s=3DMlJKXisQTr1aheS8hahty- > iFDOCS_GhM37X2lMUAH54 > >&e=3D > > > > > > > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >First, thank you for a clearly written document that contained enough > >context to trigger my hazy memory of some of the technical details. > > > >My concern is around this paragraph in the Introduction: > > > >"The MPLS label value in the Ethernet A-D route can be set to the > > VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may > >have > > a global scope or local scope per PE and may also be equal to the > > VPWS service instance identifier set in the Ethernet A-D route. > >" > > > >First, I recognize that folks have implemented and deployed EVPN with > >VXLAN. > >That's fine. There is an ISE RFC 7348 that describes VXLAN. Depending > >on what > >you (authors, shepherd, AD, WG) decide to do about the rest of my > >concern, it is likely that this should be normative references - which > >would be a downref. > > I can add the 7348 as a normative reference. > > > > >Second, the paragraph here isn't really adequate to describe how to > >implement the > >functionality. I don't see how: > > a) The ingress PE decides which VNIs it can send based upon the > >VNI=3DMPLS_label > > from the egress. Is there an assumption that VXLAN allows > >sending all VNIs across > > the particular VPWS, whether port-based, VLAN-based, etc? > > We are signaling Ethernet A-D route per VPWS instance, and in there we wi= ll > signal VNI instead of an MPLS label for VxLAN encap. > > > b) Is there an assumption that the egress PE-advertised MPLS label > >also indicates the > > VNI to be used? > > EVPN can work with different encapsulations a BGP Tunnel Encapsulation > Attribute That specifies the tunnel type will be added to the Ethernet A-= D route. > > > >That seems like another mode, like the > >VLAN-based service, except > > it is perhaps VNI + VLAN-based service? > > The draft lists clearly the different service interface types, and there = will > be only one VNI per VPWS instance wether this is Vlan or port based. > > > > >Please don't take this Discuss as a reason to remove the paragraph and > >the implied functionality. > >If it's implemented and deployed (and I think it is) - then what I reall= y > >want is to just have it > >adequately written down so that others can interoperably implement. The > >downref to VXLAN > >should just be a matter of process nuisance (i.e. another IETF Last Call > >and handling any concerns). > > > > Should I add the 7348 as a normative reference? > > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or > >"This specification" or... > > Will fix. > > > >2) Sec 3.1: " C If set to 1, a Control word [RFC4448] MUST be > >present when sending EVPN packets to this PE." > > Given discussions with IEEE about real MACs starting with 4 and 6 in > >top nibble, adding a statement about it being BCP to include > > the control word (unless using Entropy Label) would be a good idea. > > > Could you suggest some text? > > Should I submit -12 with the changes? > > Thanks, > > Sami > > > --_000_CO2PR05MB618B555E4095698E4AC7D5DC7030CO2PR05MB618namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ali,

 

That’s correct, however ensurin= g global uniqueness when it is completely unnecessary seems like an imposit= ion on the network administrators.  

 

Yours Irrespectively,

 

John

 

From: Ali Sajassi (sajassi) [mailto:= sajassi@cisco.com]
Sent: Wednesday, April 12, 2017 4:38 PM
To: John E Drake <jdrake@juniper.net>; Alvaro Retana (aretana)= <aretana@cisco.com>; Sami Boutros <sboutros@vmware.com>; Alia = Atlas <akatlas@gmail.com>; The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-vpws@ietf.org; Jeffrey (Zhaohui) Zhang <= zzhang@juniper.net>; bess-chairs@ietf.org; bess@ietf.org
Subject: RE: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (w= ith DISCUSS and COMMENT)

 

Hi John, 

Still that gives us 16 millions P2P EVCs. =

 

Cheers, 

Ali

 

 

 

Sent = from my Verizon, Samsung Galaxy smartphone



-------- Original message --------
From: John E Drake <jdrake@juniper= .net>
Date: 4/12/17 1:20 PM (GMT-08:00)
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, Sami Boutros <sboutros@vmware.com>, Alia Atlas <akatlas@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-e= vpn-vpws@ietf.org, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, bess-chairs@ietf.org, bess@ietf.org
Subject: RE: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DIS= CUSS and COMMENT)

Sami,

I don't think we want to use a global VNI because if we do we will be limit= ed to one circuit per global VNI due to the fact that we demux traffic stri= ctly using the label value and not the MAC address.

Yours Irrespectively,

John


> -----Original Message-----
> From: Alvaro Retana (aretana) [ma= ilto:aretana@cisco.com]
> Sent: Wednesday, April 12, 2017 3:49 PM
> To: Sami Boutros <sboutros@v= mware.com>; Alia Atlas <akat= las@gmail.com>;
> The IESG <iesg@ietf.org> > Cc: draft-ietf-b= ess-evpn-vpws@ietf.org; Jeffrey (Zhaohui) Zhang
> <zzhang@juniper.net>; = bess-chairs@ietf.org; bess@ietf.org
> Subject: Re: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (wit= h DISCUSS
> and COMMENT)
>
> Sami:
>
> Hi!
>
> Let’s go ahead and add the text to explain the operation with VX= LAN – I think
> that the reference to rfc7348 should be Normative.
>
> I’ll take care of dealing with the downref when we’re read= y with the new text.
>
> Thanks!
>
> Alvaro.
>
>
>
>
>
>
> On 4/12/17, 2:14 PM, "Sami Boutros" <sboutros@vmware.com> wrote:
>
> Hi Alia,
>
> Please see comments inline.
>
>
> On 4/11/17, 4:43 PM, "Alia Atlas" <akatlas@gmail.com> wrote:
>
> >Alia Atlas has entered the following ballot position for
> >draft-ietf-bess-evpn-vpws-11: Discuss
> >
> >When responding, please keep the subject line intact and reply to = all
> >email addresses included in the To and CC lines. (Feel free to cut= this
> >introductory paragraph, however.)
> >
> >
> >Please refer to
> >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_iesg_
> >statement_discuss-
> 2Dcriteria.html&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3D= I
> >VzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D78sPNErI-
> rljSFAaM5b76_QaDS
> >Tz2BD_8ny0Dxcf4sM&s=3Ds8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoO= r2I&e
> =3D
> >for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> >The document, along with other ballot positions, can be found here= :
> >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= datatracker.ietf.o
> >rg_doc_draft-2Dietf-2Dbess-2Devpn-
> 2Dvpws_&d=3DDwICaQ&c=3DuilaK90D4TOVoH58JN
> >XRgQ&r=3DIVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D7= 8sPNErI-
> rljSFAaM5
> >b76_QaDSTz2BD_8ny0Dxcf4sM&s=3DMlJKXisQTr1aheS8hahty-
> iFDOCS_GhM37X2lMUAH54
> >&e=3D
> >
> >
> >
> >------------------------------------------------------------------= ----
> >DISCUSS:
> >------------------------------------------------------------------= ----
> >
> >First, thank you for a clearly written document that contained eno= ugh
> >context to trigger my hazy memory of some of the technical details= .
> >
> >My concern is around this paragraph in the Introduction:
> >
> >"The MPLS label value in the Ethernet A-D route can be set to= the
> >   VXLAN Network Identifier (VNI) for VXLAN encap, and t= his VNI may
> >have
> >   a global scope or local scope per PE and may also be = equal to the
> >   VPWS service instance identifier set in the Ethernet = A-D route.
> >"
> >
> >First, I recognize that folks have implemented and deployed EVPN w= ith
> >VXLAN.
> >That's fine.  There is an ISE RFC 7348 that describes VXLAN.&= nbsp;  Depending
> >on what
> >you (authors, shepherd, AD, WG) decide to do about the rest of my<= br> > >concern, it is likely that this should be normative references - w= hich
> >would be a downref.
>
> I can add the 7348 as a normative reference.
>
> >
> >Second, the paragraph here isn't really adequate to describe how t= o
> >implement the
> >functionality.   I don't see how:
> >    a) The ingress PE decides which VNIs it can sen= d based upon the
> >VNI=3DMPLS_label
> >        from the egress. &= nbsp; Is there an assumption that VXLAN allows
> >sending all VNIs across
> >        the particular VPWS, wh= ether port-based, VLAN-based, etc?
>
> We are signaling Ethernet A-D route per VPWS instance, and in there we= will
> signal VNI instead of an MPLS label for VxLAN encap.
>
> >    b) Is there an assumption that the egress PE-ad= vertised MPLS label
> >also indicates the
> >         VNI to be used? >
> EVPN can work with different encapsulations a BGP Tunnel Encapsulation=
> Attribute That specifies the tunnel type will be added to the Ethernet= A-D route.
>
>
> >That seems like another mode, like the
> >VLAN-based service, except
> >         it is perhaps VNI= + VLAN-based service?
>
> The draft lists clearly the different service interface types, and the= re will
> be only one VNI per VPWS instance wether this is Vlan or port based. >
> >
> >Please don't take this Discuss as a reason to remove the paragraph= and
> >the implied functionality.
> >If it's implemented and deployed (and I think it is) - then what I= really
> >want is to just have it
> >adequately written down so that others can interoperably implement= .  The
> >downref to VXLAN
> >should just be a matter of process nuisance (i.e. another IETF Las= t Call
> >and handling any concerns).
> >
>
> Should I add the 7348 as a normative reference?
>
>
>
> >
> >------------------------------------------------------------------= ----
> >COMMENT:
> >------------------------------------------------------------------= ----
> >
> >1) (Nit) Sec 3.1 "This draft" for an RFC should be "= ;This document" or
> >"This specification" or...
>
> Will fix.
> >
> >2) Sec 3.1:  "    C   &nbs= p;  If set to 1, a Control word [RFC4448] MUST be
> >present when sending EVPN packets to this PE."
> >   Given discussions with IEEE about real MACs starting = with 4 and 6 in
> >top nibble, adding a statement about it being BCP to include
> >   the control word (unless using Entropy Label) would b= e a good idea.
> >
> Could you suggest some text?
>
> Should I submit -12 with the changes?
>
> Thanks,
>
> Sami
> >
>

--_000_CO2PR05MB618B555E4095698E4AC7D5DC7030CO2PR05MB618namprd_-- From nobody Wed Apr 12 15:54:17 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD426127A91; Wed, 12 Apr 2017 15:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMFoCsUy_rif; Wed, 12 Apr 2017 15:54:11 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0057.outbound.protection.outlook.com [104.47.34.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92BD312EB5D; Wed, 12 Apr 2017 15:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eE7d62KdoyGHp/DUzSgmS6htv9xOZARX+/eaGbNBwZ8=; b=eYkiMPCRAE0KHZsNSILk+98l52u5exkaOtc2tVtrxUdCq7gBvDgRUg3Zu8JcAD/vAwWkj9J4gIj3Wh+CTIF68XqO3IW95HWjXHwhtJs5fps1EXSrC92iw0BBzMExOOCniFV5IbIL7cNNOtOoSbRS0LERclSgLtMJc6EmZh3KW4M= Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 12 Apr 2017 22:54:04 +0000 Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.1034.012; Wed, 12 Apr 2017 22:54:04 +0000 From: Sami Boutros To: John E Drake , "Alvaro Retana (aretana)" , Alia Atlas , The IESG , "Ali Sajassi (sajassi)" CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) Thread-Index: AQHSsx164xCqEvIbFkeIlM5ejr6GlaHBlYIAgACP3oCAAAizgP//tbWA Date: Wed, 12 Apr 2017 22:54:04 +0000 Message-ID: <2F64CC4A-4343-42FE-8E54-3B42A4FB6DE9@vmware.com> References: <149195421839.15653.9414778746456999406.idtracker@ietfa.amsl.com> <37F7F0F8-25C7-4C22-9663-75D129365193@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=vmware.com; x-originating-ip: [208.91.2.2] x-microsoft-exchange-diagnostics: 1; BN6PR05MB3009; 7:1mCN4VqwRdJOxEMX1bjuX+n1pqI6AngDEjP/tonK5NRr/NRJfIAtDZVqgn8hcODvcj4EIakCOL30v0KTCS9+9mEx3FLMkyhcXAg58E+DUMPFBVzDTsdKAYN5vCFR/1UwzUiREypyXB0oMqLiGj4C1Q/XMFlLqRtKTE9kPU9RKXBeoraScYcBa89YxGex90yO+Nncs4ptds0sfn49xgavKsbH36VOjbWsMRVD5JVPFwvO6Cp/uyHzl8ZemwDSFo5kc3MpdjiowTf2nfoUBCpKpZ6NOOxA7eRHHCd7Qp20lXmG0hviQgGfPrVOx0Z94H7BI2VNWjRDz1FPf6HpiwFzfA==; 20:uTJEiIM6l7s6v5zjWfKn8pQQJUA7EIvbrsUJoX/gun0g19NXposdH4ZWAwModAwc8R7KYaL9hkTrZ84erX5vUAQKCi4he1M3nvKp8EflVr1BiydLAPi/Z8IMqSNVp8e5wp0Ohp5dKHc9sKe1nFLjIIQws9CNAlVR//Xw/ENM1W8= x-ms-office365-filtering-correlation-id: 483b3844-c68a-468f-e734-08d481f6d1cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR05MB3009; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(10436049006162)(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN6PR05MB3009; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB3009; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39450400003)(39860400002)(39840400002)(39400400002)(39410400002)(24454002)(377454003)(43544003)(13464003)(85664002)(2900100001)(36756003)(83716003)(122556002)(82746002)(8936002)(229853002)(2950100002)(86362001)(575784001)(93886004)(230783001)(66066001)(5660300001)(33656002)(102836003)(7736002)(2906002)(305945005)(50986999)(345774005)(54356999)(76176999)(99286003)(3660700001)(8666007)(3280700002)(38730400002)(1941001)(4326008)(6512007)(3846002)(53936002)(39060400002)(6306002)(54906002)(77096006)(189998001)(81156014)(6436002)(81166006)(6246003)(6506006)(6486002)(8676002)(6116002)(25786009)(53546009)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3009; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <71D1C9D3D4754E4F894364DE6D2FF7D5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 22:54:04.6372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3009 Archived-At: Subject: Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 22:54:15 -0000 SGksDQoNCkhlcmUgaXMgdGhlIHRleHQgdXBkYXRlZCwgcGxlYXNlIGxldCBtZSBrbm93IGlmIHRo aXMgbG9va3MgZ29vZC4NCg0KIlRoZSBNUExTIGxhYmVsIHZhbHVlIGluIHRoZSBFdGhlcm5ldCBB LUQgcm91dGUgY2FuIGJlIHNldCB0byB0aGUgVlhMQU4gTmV0d29yayBJZGVudGlmaWVyIChWTkkp IGZvciBWWExBTiBlbmNhcCBhcyBwZXIgW1JGQzczNDhdLCBhbmQgdGhpcyBWTkkgd2lsbCBoYXZl IGEgbG9jYWwgc2NvcGUgcGVyIFBFIGFuZCBtYXkgYWxzbyBiZSBlcXVhbCB0byB0aGUgVlBXUyBz ZXJ2aWNlIGluc3RhbmNlIGlkZW50aWZpZXIgc2V0IGluIHRoZSBFdGhlcm5ldCBBLUQgcm91dGUu 4oCdDQoNCldpbGwgYWRkIGEgTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkM3MzQ4Lg0KDQpJIGNh biBhZGQgYXMgd2VsbCB0aGUgZm9sbG93aW5nOg0KDQoiV2hlbiB1c2luZyBWWExBTiBlbmNhcCwg dGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBkZWZpbmVkIGluIFtkcmFm dC1pZXRmLWlkci10dW5uZWwtZW5jYXBzXSBhbmQgW1JGQzU1MTJdIGlzIGluY2x1ZGVkIGluIHRo ZSBFdGhlcm5ldCBBLUQgcm91dGUuIg0KDQpBbmQgYWRkICBhIE5vcm1hdGl2ZSByZWZlcmVuY2Ug dG8gW1JGQzU1MTJdIGFuZCBJbmZvcm1hdGl2ZSB0byB0aGUgdHVubmVsLWVuY2Fwcy4NCg0KVGhh bmtzLA0KDQpTYW1pDQoNCg0KDQpPbiA0LzEyLzE3LCAxOjE5IFBNLCAiSm9obiBFIERyYWtlIiA8 amRyYWtlQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPlNhbWksDQo+DQo+SSBkb24ndCB0aGluayB3 ZSB3YW50IHRvIHVzZSBhIGdsb2JhbCBWTkkgYmVjYXVzZSBpZiB3ZSBkbyB3ZSB3aWxsIGJlIGxp bWl0ZWQgdG8gb25lIGNpcmN1aXQgcGVyIGdsb2JhbCBWTkkgZHVlIHRvIHRoZSBmYWN0IHRoYXQg d2UgZGVtdXggdHJhZmZpYyBzdHJpY3RseSB1c2luZyB0aGUgbGFiZWwgdmFsdWUgYW5kIG5vdCB0 aGUgTUFDIGFkZHJlc3MuDQo+DQo+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+DQo+Sm9obg0KPg0K Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEFsdmFybyBSZXRhbmEg KGFyZXRhbmEpIFttYWlsdG86YXJldGFuYUBjaXNjby5jb21dDQo+PiBTZW50OiBXZWRuZXNkYXks IEFwcmlsIDEyLCAyMDE3IDM6NDkgUE0NCj4+IFRvOiBTYW1pIEJvdXRyb3MgPHNib3V0cm9zQHZt d2FyZS5jb20+OyBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbT47DQo+PiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4+IENjOiBkcmFmdC1pZXRmLWJlc3MtZXZwbi12cHdzQGlldGYub3Jn OyBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZw0KPj4gPHp6aGFuZ0BqdW5pcGVyLm5ldD47IGJlc3Mt Y2hhaXJzQGlldGYub3JnOyBiZXNzQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogQWxpYSBBdGxh cycgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJlc3MtZXZwbi12cHdzLTExOiAod2l0aCBESVNDVVNT DQo+PiBhbmQgQ09NTUVOVCkNCj4+IA0KPj4gU2FtaToNCj4+IA0KPj4gSGkhDQo+PiANCj4+IExl dOKAmXMgZ28gYWhlYWQgYW5kIGFkZCB0aGUgdGV4dCB0byBleHBsYWluIHRoZSBvcGVyYXRpb24g d2l0aCBWWExBTiDigJMgSSB0aGluaw0KPj4gdGhhdCB0aGUgcmVmZXJlbmNlIHRvIHJmYzczNDgg c2hvdWxkIGJlIE5vcm1hdGl2ZS4NCj4+IA0KPj4gSeKAmWxsIHRha2UgY2FyZSBvZiBkZWFsaW5n IHdpdGggdGhlIGRvd25yZWYgd2hlbiB3ZeKAmXJlIHJlYWR5IHdpdGggdGhlIG5ldyB0ZXh0Lg0K Pj4gDQo+PiBUaGFua3MhDQo+PiANCj4+IEFsdmFyby4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g DQo+PiANCj4+IE9uIDQvMTIvMTcsIDI6MTQgUE0sICJTYW1pIEJvdXRyb3MiIDxzYm91dHJvc0B2 bXdhcmUuY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgQWxpYSwNCj4+IA0KPj4gUGxlYXNlIHNlZSBj b21tZW50cyBpbmxpbmUuDQo+PiANCj4+IA0KPj4gT24gNC8xMS8xNywgNDo0MyBQTSwgIkFsaWEg QXRsYXMiIDxha2F0bGFzQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+ID5BbGlhIEF0bGFzIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPj4gPmRyYWZ0LWll dGYtYmVzcy1ldnBuLXZwd3MtMTE6IERpc2N1c3MNCj4+ID4NCj4+ID5XaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4+ ID5lbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcw0KPj4gPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K Pj4gPg0KPj4gPg0KPj4gPlBsZWFzZSByZWZlciB0bw0KPj4gPmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2llc2dfDQo+PiA+ c3RhdGVtZW50X2Rpc2N1c3MtDQo+PiAyRGNyaXRlcmlhLmh0bWwmZD1Ed0lDYVEmYz11aWxhSzkw RDRUT1ZvSDU4Sk5YUmdRJnI9SQ0KPj4gPlZ6Y1RSTFFkcHRhMDhMMGJfeTJ6RGtxdndKaFJLTUNB YlgtMkstTFY5OCZtPTc4c1BORXJJLQ0KPj4gcmxqU0ZBYU01Yjc2X1FhRFMNCj4+ID5UejJCRF84 bnkwRHhjZjRzTSZzPXM4b2F0N3ZVRHg2TkhWMHZPZWhVbF9mTGpzTEhzVHFtaHQzeElIb09yMkkm ZQ0KPj4gPQ0KPj4gPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuDQo+PiA+DQo+PiA+DQo+PiA+VGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPj4gPmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNr ZXIuaWV0Zi5vDQo+PiA+cmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGJlc3MtMkRldnBuLQ0KPj4gMkR2 cHdzXyZkPUR3SUNhUSZjPXVpbGFLOTBENFRPVm9INThKTg0KPj4gPlhSZ1Emcj1JVnpjVFJMUWRw dGEwOEwwYl95MnpEa3F2d0poUktNQ0FiWC0ySy1MVjk4Jm09NzhzUE5FckktDQo+PiBybGpTRkFh TTUNCj4+ID5iNzZfUWFEU1R6MkJEXzhueTBEeGNmNHNNJnM9TWxKS1hpc1FUcjFhaGVTOGhhaHR5 LQ0KPj4gaUZET0NTX0doTTM3WDJsTVVBSDU0DQo+PiA+JmU9DQo+PiA+DQo+PiA+DQo+PiA+DQo+ PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4gPkRJU0NVU1M6DQo+PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPg0K Pj4gPkZpcnN0LCB0aGFuayB5b3UgZm9yIGEgY2xlYXJseSB3cml0dGVuIGRvY3VtZW50IHRoYXQg Y29udGFpbmVkIGVub3VnaA0KPj4gPmNvbnRleHQgdG8gdHJpZ2dlciBteSBoYXp5IG1lbW9yeSBv ZiBzb21lIG9mIHRoZSB0ZWNobmljYWwgZGV0YWlscy4NCj4+ID4NCj4+ID5NeSBjb25jZXJuIGlz IGFyb3VuZCB0aGlzIHBhcmFncmFwaCBpbiB0aGUgSW50cm9kdWN0aW9uOg0KPj4gPg0KPj4gPiJU aGUgTVBMUyBsYWJlbCB2YWx1ZSBpbiB0aGUgRXRoZXJuZXQgQS1EIHJvdXRlIGNhbiBiZSBzZXQg dG8gdGhlDQo+PiA+ICAgVlhMQU4gTmV0d29yayBJZGVudGlmaWVyIChWTkkpIGZvciBWWExBTiBl bmNhcCwgYW5kIHRoaXMgVk5JIG1heQ0KPj4gPmhhdmUNCj4+ID4gICBhIGdsb2JhbCBzY29wZSBv ciBsb2NhbCBzY29wZSBwZXIgUEUgYW5kIG1heSBhbHNvIGJlIGVxdWFsIHRvIHRoZQ0KPj4gPiAg IFZQV1Mgc2VydmljZSBpbnN0YW5jZSBpZGVudGlmaWVyIHNldCBpbiB0aGUgRXRoZXJuZXQgQS1E IHJvdXRlLg0KPj4gPiINCj4+ID4NCj4+ID5GaXJzdCwgSSByZWNvZ25pemUgdGhhdCBmb2xrcyBo YXZlIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCBFVlBOIHdpdGgNCj4+ID5WWExBTi4NCj4+ID5U aGF0J3MgZmluZS4gIFRoZXJlIGlzIGFuIElTRSBSRkMgNzM0OCB0aGF0IGRlc2NyaWJlcyBWWExB Ti4gICBEZXBlbmRpbmcNCj4+ID5vbiB3aGF0DQo+PiA+eW91IChhdXRob3JzLCBzaGVwaGVyZCwg QUQsIFdHKSBkZWNpZGUgdG8gZG8gYWJvdXQgdGhlIHJlc3Qgb2YgbXkNCj4+ID5jb25jZXJuLCBp dCBpcyBsaWtlbHkgdGhhdCB0aGlzIHNob3VsZCBiZSBub3JtYXRpdmUgcmVmZXJlbmNlcyAtIHdo aWNoDQo+PiA+d291bGQgYmUgYSBkb3ducmVmLg0KPj4gDQo+PiBJIGNhbiBhZGQgdGhlIDczNDgg YXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlLg0KPj4gDQo+PiA+DQo+PiA+U2Vjb25kLCB0aGUgcGFy YWdyYXBoIGhlcmUgaXNuJ3QgcmVhbGx5IGFkZXF1YXRlIHRvIGRlc2NyaWJlIGhvdyB0bw0KPj4g PmltcGxlbWVudCB0aGUNCj4+ID5mdW5jdGlvbmFsaXR5LiAgIEkgZG9uJ3Qgc2VlIGhvdzoNCj4+ ID4gICAgYSkgVGhlIGluZ3Jlc3MgUEUgZGVjaWRlcyB3aGljaCBWTklzIGl0IGNhbiBzZW5kIGJh c2VkIHVwb24gdGhlDQo+PiA+Vk5JPU1QTFNfbGFiZWwNCj4+ID4gICAgICAgIGZyb20gdGhlIGVn cmVzcy4gICBJcyB0aGVyZSBhbiBhc3N1bXB0aW9uIHRoYXQgVlhMQU4gYWxsb3dzDQo+PiA+c2Vu ZGluZyBhbGwgVk5JcyBhY3Jvc3MNCj4+ID4gICAgICAgIHRoZSBwYXJ0aWN1bGFyIFZQV1MsIHdo ZXRoZXIgcG9ydC1iYXNlZCwgVkxBTi1iYXNlZCwgZXRjPw0KPj4gDQo+PiBXZSBhcmUgc2lnbmFs aW5nIEV0aGVybmV0IEEtRCByb3V0ZSBwZXIgVlBXUyBpbnN0YW5jZSwgYW5kIGluIHRoZXJlIHdl IHdpbGwNCj4+IHNpZ25hbCBWTkkgaW5zdGVhZCBvZiBhbiBNUExTIGxhYmVsIGZvciBWeExBTiBl bmNhcC4NCj4+IA0KPj4gPiAgICBiKSBJcyB0aGVyZSBhbiBhc3N1bXB0aW9uIHRoYXQgdGhlIGVn cmVzcyBQRS1hZHZlcnRpc2VkIE1QTFMgbGFiZWwNCj4+ID5hbHNvIGluZGljYXRlcyB0aGUNCj4+ ID4gICAgICAgICBWTkkgdG8gYmUgdXNlZD8NCj4+IA0KPj4gRVZQTiBjYW4gd29yayB3aXRoIGRp ZmZlcmVudCBlbmNhcHN1bGF0aW9ucyBhIEJHUCBUdW5uZWwgRW5jYXBzdWxhdGlvbg0KPj4gQXR0 cmlidXRlIFRoYXQgc3BlY2lmaWVzIHRoZSB0dW5uZWwgdHlwZSB3aWxsIGJlIGFkZGVkIHRvIHRo ZSBFdGhlcm5ldCBBLUQgcm91dGUuDQo+PiANCj4+IA0KPj4gPlRoYXQgc2VlbXMgbGlrZSBhbm90 aGVyIG1vZGUsIGxpa2UgdGhlDQo+PiA+VkxBTi1iYXNlZCBzZXJ2aWNlLCBleGNlcHQNCj4+ID4g ICAgICAgICBpdCBpcyBwZXJoYXBzIFZOSSArIFZMQU4tYmFzZWQgc2VydmljZT8NCj4+IA0KPj4g VGhlIGRyYWZ0IGxpc3RzIGNsZWFybHkgdGhlIGRpZmZlcmVudCBzZXJ2aWNlIGludGVyZmFjZSB0 eXBlcywgYW5kIHRoZXJlIHdpbGwNCj4+IGJlIG9ubHkgb25lIFZOSSBwZXIgVlBXUyBpbnN0YW5j ZSB3ZXRoZXIgdGhpcyBpcyBWbGFuIG9yIHBvcnQgYmFzZWQuDQo+PiANCj4+ID4NCj4+ID5QbGVh c2UgZG9uJ3QgdGFrZSB0aGlzIERpc2N1c3MgYXMgYSByZWFzb24gdG8gcmVtb3ZlIHRoZSBwYXJh Z3JhcGggYW5kDQo+PiA+dGhlIGltcGxpZWQgZnVuY3Rpb25hbGl0eS4NCj4+ID5JZiBpdCdzIGlt cGxlbWVudGVkIGFuZCBkZXBsb3llZCAoYW5kIEkgdGhpbmsgaXQgaXMpIC0gdGhlbiB3aGF0IEkg cmVhbGx5DQo+PiA+d2FudCBpcyB0byBqdXN0IGhhdmUgaXQNCj4+ID5hZGVxdWF0ZWx5IHdyaXR0 ZW4gZG93biBzbyB0aGF0IG90aGVycyBjYW4gaW50ZXJvcGVyYWJseSBpbXBsZW1lbnQuICBUaGUN Cj4+ID5kb3ducmVmIHRvIFZYTEFODQo+PiA+c2hvdWxkIGp1c3QgYmUgYSBtYXR0ZXIgb2YgcHJv Y2VzcyBudWlzYW5jZSAoaS5lLiBhbm90aGVyIElFVEYgTGFzdCBDYWxsDQo+PiA+YW5kIGhhbmRs aW5nIGFueSBjb25jZXJucykuDQo+PiA+DQo+PiANCj4+IFNob3VsZCBJIGFkZCB0aGUgNzM0OCBh cyBhIG5vcm1hdGl2ZSByZWZlcmVuY2U/DQo+PiANCj4+IA0KPj4gDQo+PiA+DQo+PiA+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4gPkNPTU1FTlQ6DQo+PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPg0KPj4gPjEpIChO aXQpIFNlYyAzLjEgIlRoaXMgZHJhZnQiIGZvciBhbiBSRkMgc2hvdWxkIGJlICJUaGlzIGRvY3Vt ZW50IiBvcg0KPj4gPiJUaGlzIHNwZWNpZmljYXRpb24iIG9yLi4uDQo+PiANCj4+IFdpbGwgZml4 Lg0KPj4gPg0KPj4gPjIpIFNlYyAzLjE6ICAiICAgIEMgICAgICBJZiBzZXQgdG8gMSwgYSBDb250 cm9sIHdvcmQgW1JGQzQ0NDhdIE1VU1QgYmUNCj4+ID5wcmVzZW50IHdoZW4gc2VuZGluZyBFVlBO IHBhY2tldHMgdG8gdGhpcyBQRS4iDQo+PiA+ICAgR2l2ZW4gZGlzY3Vzc2lvbnMgd2l0aCBJRUVF IGFib3V0IHJlYWwgTUFDcyBzdGFydGluZyB3aXRoIDQgYW5kIDYgaW4NCj4+ID50b3AgbmliYmxl LCBhZGRpbmcgYSBzdGF0ZW1lbnQgYWJvdXQgaXQgYmVpbmcgQkNQIHRvIGluY2x1ZGUNCj4+ID4g ICB0aGUgY29udHJvbCB3b3JkICh1bmxlc3MgdXNpbmcgRW50cm9weSBMYWJlbCkgd291bGQgYmUg YSBnb29kIGlkZWEuDQo+PiA+DQo+PiBDb3VsZCB5b3Ugc3VnZ2VzdCBzb21lIHRleHQ/DQo+PiAN Cj4+IFNob3VsZCBJIHN1Ym1pdCAtMTIgd2l0aCB0aGUgY2hhbmdlcz8NCj4+IA0KPj4gVGhhbmtz LA0KPj4gDQo+PiBTYW1pDQo+PiA+DQo+PiANCj4NCg== From nobody Thu Apr 13 02:42:54 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B3913146F for ; Thu, 13 Apr 2017 02:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhA7RE7ZRL6k for ; Thu, 13 Apr 2017 02:42:37 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7E012941D for ; Thu, 13 Apr 2017 02:42:36 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id m36so41576583qtb.0 for ; Thu, 13 Apr 2017 02:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=6s2h4fAfHj4vyv6m2kaXa43DOLHWhanJNllmXHcCX5U=; b=droeD7WXTa8IEwLDuiOBWk/ZcP7yNGJz+7Z1lO1zKiK5MsVg7M28TZkG/kzd1UUsS5 GOS+dzV1+ZMQnShs8F38Aj8AIBE2LSEKI/emP9EWtgXQikG2I6Fip8mqeTR4rxEP4+sp Kat/XU4r4EYwKvjRvTVuYdxHeiyrI2o9Ev0h+P/pFuzKQ/DjKc0e8/MXZY+xLmNhAPxN TUuUtaTZ2OF4yKdvhXbwpcyrPxBb+5/lWfwsgaMTYyte+X4FOROvxG0cZttyP7/27alx DJP9wmwztdX6V4c6DAzBCMq3tbRbQcJDcZucXPZyzHcuLAPiLfu6yIo0cq4l/1/pNEGx 1Hjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=6s2h4fAfHj4vyv6m2kaXa43DOLHWhanJNllmXHcCX5U=; b=GfwW1uDg+M2L/d5enF4SICVbWWAWCIwf/y3XWKRfoqLtEaloyu3TS0FPFoDqWiJIIC NDxP7tsc0RdLlqjSbRpw4ZBgJT8KfSJ3rIJPw58KuSRZTqiCP+/woRSJs4AJicvVNCcr CoRoySFJ5I3U9TVOeX9Z9aHbSOoc0RFTLvf/qgZLryvBXDbyP7IsLD30IAKAE0gpF/eS C265nMYaM7EBy4ksIbtDsx1DH67Qm8ziCemMvt0Ft/JCKS5O3l/2VLegYRNIyAfEVgaE 0CbulvrAKYCZDYYJVFz+STl2SqExlesvWLOXUt2wk0RAUqw1WT5O7Y38bmhhp9TPpDgj 66ug== X-Gm-Message-State: AN3rC/78gkYq67h+vHU85ijwXz2MjTVpc9yi/q6/vqDpgv65bKHStfN7 FX0+UAVee29OylmHHl/mZ1yVBANS0ASh X-Received: by 10.200.3.216 with SMTP id z24mr1993147qtg.124.1492076554259; Thu, 13 Apr 2017 02:42:34 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.30.52 with HTTP; Thu, 13 Apr 2017 02:41:53 -0700 (PDT) In-Reply-To: <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> From: Hiroshi Tsunoda Date: Thu, 13 Apr 2017 18:41:53 +0900 X-Google-Sender-Auth: jE5mSYwe6RjMOM-I1oIeB7b0u80 Message-ID: To: Glenn Mansfield Keeni Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:42:46 -0000 Dear Glenn, I posted a new revision taking into account your latest comments. In the new revision, the following two new textual conventions are added to L2L3-VPN-MCAST-TC-MIB. - L2L3VpnMcastProviderTunnelPointer - L2L3VpnMcastProviderTunnelPointerType This change is to provide a mean to specify the table type referred by the object in L2L3-VPN-MCAST-MIB. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-07.= txt Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-07 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vpn-mcast-mib-07 Please see some notes below. > A. Sec 1.1 Terminology. > 1. The scope of the MIB is "Layer 2 and Layer 3 Virtual Private > Networks (VPN) that support multicast". This phrase appears > multiple times in the text. > It would be better to coin a term (eg L2/L3-VPN-MCast) for the > above in Sec 1.1 Terminology and use it in the text. Hmm, that phrase appears in Abstract, Sec.3, and MIB definition. In my humble opinion, that current style seems better because the MIB definition part may be read separately from this document. Thus, I keep the current style. > B. TC-MIB > 1 L2L3VpnMcastProviderTunnelType enumeration order: > Is there any rationale behind the difference in ordering in > Sec 1.1 Terminology and the enumeration in the textual convention? > Could these be aligned? The enumeration order in the textual convention is based on Section 5 of [RFC6514]. In Sec.1.1, I would like to categorize tunnel setup techniques based on the protocol. Thus, there is the difference in ordering in those sections. > C. L2L3-VPN-MCAST-MIB > 1. DESCRIPTION > The description states > "This MIB module will be used by other MIB modules designed for > managing multicast in Layer 2 (L2) VPNs [RFC7117] and > Layer 3 (L3) VPNs [RFC6513], [RFC6514]" > > The statement differs from that in the abstract: > "designed for monitoring and/or configuring both > Layer 2 and Layer 3 Virtual Private Networks (VPN) that support > multicast." > > Please align the descriptions. > [The description in the abstract appears more appropriate.] Thank you. I fixed the description according to your recommendation. > 2. OID tree structure: > Is there any particular reason to have the l2L3VpnMcastStates subtree= ? > If no, then l2L3VpnMcastPmsiTunnelAttributeTable can come directly > under l2L3VpnMcastObjects Fixed. Now l2L3VpnMcastPmsiTunnelAttributeTable is directy under l2L3VpnMcastObjects. > 3. l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE > DESCRIPTION > "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId > may be represented as an entry in other table, e.g, > mplsTunnelTable [RFC3812]. > There must be some means to specify which "other table" table this > RowPointer points too unless it points to a single prespecified > Table (mplsTunnelTable). I defined a new object, l2L3VpnMcastPmsiTunnelPointerType, in L2L3-VPN-MCAST-MIB. This usage of this object is to specify the type of l2L3VpnMcastPmsiTunnelPointer. Its syntax is L2L3VpnMcastProviderTunnelPointerType which is defined in L2L3-VPN-MCAST-TC-MIB. I hope this fulfills your requirement. > D. Other issues: > > 1. It is stated that this MIB will be used by other MIBs > "designed for monitoring and/or configuring both > Layer 2 and Layer 3 Virtual Private Networks (VPN) that support > multicast." > > Is there a use case for this MIB? That would make it easier to > understand and review the applicability. MCAST-VPN-MIB, defined in other document, use this MIB to get the information of BGP PMSI attribute. MCAST-VPN-MIB has several tables for monitoring and configuring several types of PMSI (I-PMSI, S-PMSI, etc). Each table is required to have the attribute information and has the pointer to a row in l2L3VpnMcastPmsiTunnelAttributeTable. I hope this answers your question. > 2. You are sure that notifications are not required ? I think no notifications are required. I and Jeffery do not find any useful notifications regarding this MIB for operators/administrators. > 3. You are sure that read-write and/or read-create operations are not > required for rows in l2L3VpnMcastPmsiTunnelAttributeTable? > > Then the purpose of this MIB will be limited to > o provide a pointer to tables like ifXTable for further attribut= es > o provide a list of tunnels > only? The content of the table comes only from signaling. Therefore, I think read-write and read-create operations are not required. > E. Editorial issues > A complete editorial review is TBD. > > 1. line 99: Typo? > < BPG auto-discovery (A-D) routes. > > BPG auto-discovery (A-D) routes. > 2. line 102: Typo > < This document defines a textual conventions (TC) > > This document defines a textual convention (TC) > 3. line 134: nit > < A PE uses to send > > A PE uses it to send Fixed. Thank you very much for pointing these out. Thanks. -- tsuno 2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni : > Dear Tsunoda, >> I think that I have addressed all of Glenn's comments in >> this revision. > Thanks for addressing the comments. The MIB compiles OK and > is looking good. It is shaping up well. > A new set of comments is attached. Please check and do the > > needful. > Glenn > On 2017/02/21 16:50, Hiroshi Tsunoda wrote: >> >> Dear Glenn and BESS WG, >> >> I posted a new revision as follows. >> I think that I have addressed all of Glenn's comments in this revision. >> >> In this revision, I have tried to add more detailed explanation >> throughout the document. >> Please review and let me know if there are any misunderstanding from >> technical view points. >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-= 06.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-06 >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vpn-mcast-mib-0= 6 >> >> Please see some notes below. >> >>> 1. Introduction >>> >>> 1.1 >>> Would be very nice if a short explanations of MVPN and >>> L2 VPN Multicast were given. With emphasis on the operational >>> aspects. >> >> >> I have updated Introduction. I hope this update fulfills your >> requirements. >> >>> 1.4 .... there are 2 types of PMSIs .. >>> >>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>> >>> >>> please make these explanations more gentle(complete) to the reader. >>> Also, give the references where these terms are defined. >> >> >> More gentle explanation and references were added in Terminology >> section (Sec.1.1). >> >>> 3.2 some more text like the following will be good. >>> L2L3-VPN-MCAST-MIB contains >>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>> an enumeration of the provider tunnel types and, >>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>> composed of multiple attributes that depend on the tunnel type an= d >>> uniquely identify a tunnel. This table will be used to ... monito= r >>> the tunnels supported by the system at a given point of time (?) >>> It may also be used in conjunction with XXXX-mib to obtain the >>> other details of a tunnel by following the row pointer of the >>> corresponding tunnel's row in this table. >>> [ Please treat the above as a template and modify the text as >>> appropriate ..] >> >> >> Fixed in this revision. Please look at Sec. 3 Summary of MIB Module. >> >>> 3.3 Since this will become a standard document, please take care of >>> definitions and notations used in the document. >>> The notation I/S-PMSI is not defined. If you must use a new >>> term/notation, define it before use. >> >> >> The notation I/S-PMSI is defined in Sec.1.1 now. >> >>> 4.8 >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>> MAX-ACCESS not-accessible >>>> STATUS current >>>> DESCRIPTION >>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>> The entries may be referred to by I-PMSI or S-PMSI table >>>> entries defined in other MIBs, e.g. mvpnMIB in >>>> [I-D.ietf-bess-mvpn-mib]." >>> >>> >>> It would seem that each row in this table is an index for a PTA >>> and may contain pointers to rows in tables of other MIB modules >>> which may contain more details for the PTA. Is that correct? >>> Please reword the DESCRIPTION acordingly. >>> Also see comments in 4.15 >> >> >> I have changed DESCRIPTION as follows. >> >> "An entry of this table corresponds with a >> PMSI Tunnel attribute and is created by a PE router >> that advertises and receives the attribute. >> The entry in the table will be referred by other MIB modules >> which are designed for monitoring and/or configuring >> both L2 and L3 VPN that support multicast." >> >> >>> 4.10-3 >>> the phrase UDP-based S-PMSI appears here for the first time. >>> Somewhere earlier it should be made clear that UDP too may be used >>> in signaling. >> >> >> In Introduction, I have explained that BGP and UDP are used in signaling= . >> >>> 4.13 >>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>> >>>> DESCRIPTION >>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>> field in PMSI Tunnel Attribute of the corresponding >>>> I/S-PMSI A-D or Leaf A-D route." >>> >>> o Does this description cover all the types? If not, then cover all t= he >>> types unless there is a good reason to focus only on the above type= s. >>> o I/S-PMSI: unexplained notation. >> >> >> Fixed. >> >>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>> >>> Please indicate that the first column gives the size >> >> >> I have updated the table as follows. >> >> Size (in octets) l2L3VpnMcastPmsiTunnelAttributeType >> IPv4 IPv6 (tunneling technology) >> -------------------------------------------------- >> 0 0 noTunnelId (No tunnel information presen= t) >> 12 24 rsvpP2mp (RSVP-TE P2MP LSP) >> 17 29 ldpP2mp (mLDP P2MP LSP) >> 8 32 pimSsm (PIM-SSM Tree) >> >>>> 8/32 pimAsm >>>> 8/32 pimSsm >>>> 8/32 pimBidir >>>> 4/16 ingressReplication >>> >>> >>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>> 8 or 32 octets of this attribute are filled with >>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>> Identifier field in PMSI Tunnel Attribute of the >>>> corresponding I/S-PMSI A-D route." >>> >>> >>> A more generous description of the AttributeID would be good. All the >>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>> summary would be very nice. >> >> >> Fixed. I have summarized Section 5 of RFC 6514 here. >> >>> 4.15 >>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>> >>>> SYNTAX RowPointer >>>> DESCRIPTION >>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>> pointer is null." >>> >>> I am having problems understanding this. Will help if you can give >>> a use case of how this will be used. As of now the intent is unclear. >>> A RowPointer cannot be pointing to "some MIB table". It must be >>> pointer to a specific row in a specific table. If this is a pointer t= o >>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >> >> >> I have changed DESCRIPTION as follows. >> >> "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId >> may be represented as an entry in other table, e.g, >> mplsTunnelTable [RFC3812]. If there is such entry, >> this object will point to the row pertaining to the entry. >> Otherwise, the pointer is null." >> >>> 5.0 >>>> >>>> 5. Security Considerations >>> >>> TBD >> >> >> I have rewritten this part according to the guideline described in >> RFC4181 Sec.3.4. >> >>> 6.0 >>>> >>>> 6. IANA Considerations >>> >>> >>>> IANA is requested to root MIB objects in the MIB module contained in >>>> this document under the mib-2 subtree. >>> >>> >>> Please Note: >>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need = to >>> put the definitions in a separate MIB module. That would mean a >>> separate branch in the mib-2 subtree. Then the maintenance of the >>> TC can be carried out by some entity ( IANA or, some WG or, whoever = is >>> responsible for maintaining the TC) independent of other MIB objects= . >>> If that is the intent you will need to define 2 mib modules and you >>> will >>> need to request 2 branches in the mib-2 subtree- one for the module >>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >> >> >> Now, this document defines following two MIB modules: >> - the module containing the L2L3VpnMcastProviderTunnelType TC >> - the module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >> >> -- tsuno >> >> 2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni : >>> >>> Dear Tsunoda, >>>> >>>> I will submit the next version within three days. >>>> The next versionbwill address all of remained your >>>> comments. >>> >>> Great! Looking forward to the revised draft. >>> >>> Glenn >>> >>> On 2017/02/18 16:30, Hiroshi Tsunoda wrote: >>>> >>>> >>>> Dear Glenn, >>>> >>>> I am sorry I kept you waiting so long for the revised version, I have >>>> been side tracked by other things. >>>> I will submit the next version within three days. The next version >>>> will address all of remained your comments. >>>> The summary of remained TODOs is shown below. Please wait a little >>>> more >>>> time. >>>> ------------- >>>> 1. Add general explanation about MVPN, multicast in VPLS >>>> Define and explain some technical terms, such as PIM-MVPN, >>>> UDP-based S-PMSI etc. >>>> >>>> 2. Revise summary of the MIB module >>>> >>>> 3. Revise MIB definition >>>> a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable >>>> b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to >>>> cover all cases. >>>> c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId >>>> d. Fix the description of l2L3VpnMcastPmsiTunnelPointer >>>> >>>> 4. Split the MIB module into two separate modules. >>>> >>>> 5. Revise security considertations >>>> ------------- >>>> >>>> P.S. Update of mvpn-mib-02 will be submitted by the end of this month. >>>> >>>> Best regards, >>>> >>>> -- tsuno >>>> >>>> 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : >>>>> >>>>> >>>>> Hi Tsunoda, >>>>>> >>>>>> >>>>>> I have started to volunteer to help to move this document forward. >>>>> >>>>> >>>>> Great! >>>>>> >>>>>> >>>>>> I posted a new revision and addressed all editorial things in >>>>>> that revision. >>>>> >>>>> >>>>> Got this. Looks good. >>>>>> >>>>>> >>>>>> Please give me some more time for revising other parts, >>>>> >>>>> >>>>> No problems. Will be looking forward to the revised document. >>>>> >>>>> Glenn >>>>> >>>>> >>>>> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>>>>> >>>>>> >>>>>> >>>>>> Dear Glenn, >>>>>> >>>>>> Thanks for your careful review and detailed comments/suggestions. >>>>>> I have started to volunteer to help to move this document forward. >>>>>> I posted a new revision and addressed all editorial things in that >>>>>> revision. >>>>>> Please give me some more time for revising other parts, >>>>>> in order to be familiar with the context of the original and related >>>>>> documents. >>>>>> >>>>>> URL: >>>>>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 >>>>>> Diff: >>>>>> >>>>>> >>>>>> >>>>>> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vpn-mcast= -mib-05.txt >>>>>> >>>>>> Please see some notes below. >>>>>> >>>>>>> 0. Abstract. >>>>>>> 0.1. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> it describes common managed objects used to configure >>>>>>> >>>>>>> >>>>>>> >>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>> >>>>>>> There are no writable MOs in this MIB. So it does not look >>>>>>> as though this MIB will be used for configuration directly. >>>>>>> The use case scenario for monitoring is not clear, either. >>>>>>> It appears that the MIB module(s) in this document will be >>>>>>> used by other modules which are designed for monitoring and/ >>>>>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>>>>> wording. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1. Introduction >>>>>>> >>>>>>> 1.1 >>>>>>> Would be very nice if a short explanations of MVPN and >>>>>>> L2 VPN Multicast were given. With emphasis on the operational >>>>>>> aspects. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise. >>>>>> >>>>>>> 1.2 >>>>>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>>>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1.3 >>>>>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1.4 .... there are 2 types of PMSIs .. >>>>>>> >>>>>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> please make these explanations more gentle(complete) to the >>>>>>> reader. >>>>>>> Also, give the references where these terms are defined. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise. >>>>>> >>>>>>> 3. Summary of MIB Module >>>>>>> 3.1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>>>>> >>>>>>> >>>>>>> >>>>>>> Typo: I/S-PMSI, (see 3.3 below). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 3.2 some more text like the following will be good. >>>>>>> L2L3-VPN-MCAST-MIB contains >>>>>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that >>>>>>> provides >>>>>>> an enumeration of the provider tunnel types and, >>>>>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index >>>>>>> is >>>>>>> composed of multiple attributes that depend on the tunnel typ= e >>>>>>> and >>>>>>> uniquely identify a tunnel. This table will be used to ... >>>>>>> monitor >>>>>>> the tunnels supported by the system at a given point of time >>>>>>> (?) >>>>>>> It may also be used in conjunction with XXXX-mib to obtain th= e >>>>>>> other details of a tunnel by following the row pointer of the >>>>>>> corresponding tunnel's row in this table. >>>>>>> [ Please treat the above as a template and modify the text as >>>>>>> appropriate ..] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 3.3 Since this will become a standard document, please take care of >>>>>>> definitions and notations used in the document. >>>>>>> The notation I/S-PMSI is not defined. If you must use a new >>>>>>> term/notation, define it before use. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 4. Definitions >>>>>>> >>>>>>>> IMPORTS >>>>>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4.1 Since this is not a Experimental MIB do not import use >>>>>>> experimental. >>>>>>> It is good practice to keep the draft in the as "close to final >>>>>>> form" >>>>>>> as possible. (See below) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please update this date. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Updated. >>>>>> >>>>>>> 4.3 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "This MIB contains common managed object definitions for >>>>>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Would be good if you could rearrange the text. Something like >>>>>>> "This MIB module will be used for managing multicast in Layer = 2 >>>>>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>>>>> Or, even better >>>>>>> "This MIB module will be used by other MIB modules designed fo= r >>>>>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>>>>> [RFC6513], [RFC6514] >>>>>>> Or, a combination of both, depending on the envisaged use case >>>>>>> scenarios. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Rearranged the text along with your comment. >>>>>> >>>>>>> 4.4 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ::=3D { experimental 999 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please >>>>>>> o Replace "experimental" by the branch where this mib module >>>>>>> will >>>>>>> be anchored; that is a decision that the WG will take, >>>>>>> probably. >>>>>>> o Import the branch in the IMPORTS statement >>>>>>> [ In the IANA Considerations section a branch in the mib-2 >>>>>>> subtree >>>>>>> is requested. In that case this must be >>>>>>> ::=3D { mib-2 XXX } >>>>>>> ] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.5 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Please also remove the ", experimental" text from earlier >>>>>>>> -- IMPORTS section. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Remove these instructions. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed. >>>>>> >>>>>>> 4.5.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Texual convention >>>>>>> >>>>>>> >>>>>>> >>>>>>> Typo: -- Textual convention >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.6 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> L2L3VpnMcastProviderTunnelType ::=3D TEXTUAL-CONVENTION >>>>>>>> DESCRIPTION >>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>>>>> in future RFCs, and those will be allowed as >>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>> >>>>>>> >>>>>>> >>>>>>> The part >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Additional types may be defined >>>>>>>> in future RFCs, and those will be allowed as >>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>> >>>>>>> >>>>>>> >>>>>>> may be deleted. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Deleted. >>>>>> >>>>>>> 4.7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Top level components of this MIB. >>>>>>>> -- tables, scalars, conformance information >>>>>>>> >>>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB = 1 } >>>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB = 2 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::=3D { l2L3VpnMcastObjects= 1 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> should be >>>>>>> >>>>>>> -- Top level components of this MIB. >>>>>>> >>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB= 1 } >>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB= 2 } >>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::=3D { l2L3VpnMcastObj= ects >>>>>>> 1 >>>>>>> } >>>>>>> >>>>>>> -- tables, scalars, conformance information >>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.8 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>> MAX-ACCESS not-accessible >>>>>>>> STATUS current >>>>>>>> DESCRIPTION >>>>>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>>>>> [I-D.ietf-bess-mvpn-mib]." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It would seem that each row in this table is an index for a PTA >>>>>>> and may contain pointers to rows in tables of other MIB modules >>>>>>> which may contain more details for the PTA. Is that correct? >>>>>>> Please reword the DESCRIPTION acordingly. >>>>>>> Also see comments in 4.15 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I need some more time to understand the original context. >>>>>> >>>>>>> 4.9 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>> "An entry in this table corresponds to a PTA >>>>>>>> that is advertised/received on this router. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntr= y" >>>>>>> so "entry in this table" does not fit in well. >>>>>>> A rewording like >>>>>>> "A conceptual row corresponding to a PTA >>>>>>> that is advertised/received on this router. >>>>>>> .... >>>>>>> would be better. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.10 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>> they are just as signaled by BGP. >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>> they're derived from the S-PMSI Join Message. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Note that BGP-based signaling may be used for >>>>>>>> PIM-MVPN as well." >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is the signaling mechanism important here? If it isn't then the >>>>>>> above part of the description is redundant. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed the above part. >>>>>> >>>>>>> 4.10-2 >>>>>>> PIM-MVPN appears for the first time. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Defined the notation of PIM-MVPM as follows >>>>>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>>>>> However, I think that some descriptions may be required for this >>>>>> somewhere in this document. That is TBD. >>>>>> >>>>>>> 4.10-3 >>>>>>> the phrase UDP-based S-PMSI appears here for the first time. >>>>>>> Somewhere earlier it should be made clear that UDP too may be use= d >>>>>>> in signaling. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. >>>>>> >>>>>>> 4.11 >>>>>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>>> >>>>>>> >>>>>>> >>>>>>> "this" is unclear. >>>>>>> Something like "the value of this object is 0" will be better= . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>>> More bits may be defined in the future and >>>>>>>> they will be registered in IANA Registry xxxx." >>>>>>> >>>>>>> >>>>>>> >>>>>>> This part is probably redundant. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed. >>>>>> >>>>>>> 4.12 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>>>>> -- and remove this note. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Look at the comments in 6.0 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The above description ("IANA Registry xxxx.") was removed, >>>>>> thus this part was also removed. >>>>>> >>>>>>> 4.13 >>>>>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>> I/S-PMSI A-D or Leaf A-D route." >>>>>>> >>>>>>> >>>>>>> >>>>>>> o Does this description cover all the types? If not, then cover a= ll >>>>>>> the >>>>>>> types unless there is a good reason to focus only on the above >>>>>>> types. >>>>>>> o I/S-PMSI: unexplained notation. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to address this point. >>>>>> >>>>>>> 4.14 >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>>>>> >>>>>>> >>>>>>> >>>>>>> It appears that you also allow sizes "16" and "32"; these must be >>>>>>> included. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please indicate that the first column gives the size >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I made a change as follows. >>>>>> >>>>>> Size l2L3VpnMcastPmsiTunnelAttributeType >>>>>> (IPv4/IPv6) >>>>>> -------------------------------------------------- >>>>>> (snip) >>>>>> 8/32 pimAsm >>>>>> (snip) >>>>>> >>>>>> Is this OK? >>>>>> >>>>>>>> 8/32 pimAsm >>>>>>>> 8/32 pimSsm >>>>>>>> 8/32 pimBidir >>>>>>>> 4/16 ingressReplication >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>>>> 8 or 32 octets of this attribute are filled with >>>>>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>>>>> Identifier field in PMSI Tunnel Attribute of the >>>>>>>> corresponding I/S-PMSI A-D route." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A more generous description of the AttributeID would be good. All >>>>>>> the >>>>>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A >>>>>>> simple >>>>>>> summary would be very nice. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 4.15 >>>>>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> SYNTAX RowPointer >>>>>>>> DESCRIPTION >>>>>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTab= le >>>>>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>>>>> pointer is null." >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am having problems understanding this. Will help if you can giv= e >>>>>>> a use case of how this will be used. As of now the intent is >>>>>>> unclear. >>>>>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>>>>> pointer to a specific row in a specific table. If this is a point= er >>>>>>> to >>>>>>> a row in the mplsTunnelTable spell it out clearly and >>>>>>> unambiguously. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I will need some more time to understand the original context. >>>>>> >>>>>>> 4.16 >>>>>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>> DESCRIPTION >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "If the tunnel has a corresponding interface, this is the >>>>>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>>>>> >>>>>>> >>>>>>> >>>>>>> This description is better. Would be even better with >>>>>>> "If the tunnel has a corresponding entry in the ifXTable, >>>>>>> this object will point to the row pertaining to the entry >>>>>>> ..... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.17 >>>>>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "Support of these object is not required." >>>>>>> >>>>>>> >>>>>>> >>>>>>> Support of these objects is not required. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 5.0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 5. Security Considerations >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Still TBD. >>>>>> >>>>>>> 6.0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 6. IANA Considerations >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> IANA is requested to root MIB objects in the MIB module contained >>>>>>>> in >>>>>>>> this document under the mib-2 subtree. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please Note: >>>>>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you >>>>>>> need >>>>>>> to >>>>>>> put the definitions in a separate MIB module. That would mean a >>>>>>> separate branch in the mib-2 subtree. Then the maintenance of t= he >>>>>>> TC can be carried out by some entity ( IANA or, some WG or, >>>>>>> whoever >>>>>>> is >>>>>>> responsible for maintaining the TC) independent of other MIB >>>>>>> objects. >>>>>>> If that is the intent you will need to define 2 mib modules and >>>>>>> you >>>>>>> will >>>>>>> need to request 2 branches in the mib-2 subtree- one for the >>>>>>> module >>>>>>> containing the L2L3VpnMcastProviderTunnelType TC and another for >>>>>>> the >>>>>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I will address this point in the next revision. >>>>>> >>>>>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Jeffrey, >>>>>>> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >>>>>>> document. It took me some time to do this review. But now here it >>>>>>> is. A (near complete) review of >>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>> is >>>>>>> attached. Hope this helps. >>>>>>> I understand that the Security Considerations section is TBD. >>>>>>> >>>>>>> Glenn >>>>>>> >>>>>>> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Glenn, >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>>>>>>>> Sent: Sunday, May 08, 2016 11:02 AM >>>>>>>>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>>>>>>>> ; EXT - thomas.morin@orange.com >>>>>>>>> >>>>>>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>>>>>> Vigoureux >>>>>>>>> ; bess@ietf.org; mib-doctors@ietf.org >>>>>>>>> Subject: Re: [bess] MIBDoc review of >>>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>>>>>>> 02.txt >>>>>>>>> >>>>>>>>> Jeffrey, >>>>>>>>> > Thanks for your comments. I've addressed most of your comments >>>>>>>>> > in the new revision: >>>>>>>>> Thanks for your cooperation. I will need at least one more revisi= on >>>>>>>>> with the following comments/recommendations addressed before I wi= ll >>>>>>>>> be able to complete the detailed review. In the following the >>>>>>>>> numbers >>>>>>>>> refer to the issue numbers in the initial review. The issues that >>>>>>>>> are >>>>>>>>> addressed and closed are not listed. For brevity, the issue >>>>>>>>> descriptions have been trimmed. In case of doubts please look at >>>>>>>>> the >>>>>>>>> response mail appended below. >>>>>>>>> Hope this helps. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks for your detailed comments/suggestions. I posted a new >>>>>>>> revision >>>>>>>> with the following issues addressed. >>>>>>>> >>>>>>>> URL: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcas= t-mib-04.txt >>>>>>>> Status: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mi= b/ >>>>>>>> Htmlized: >>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>> Diff: >>>>>>>> >>>>>>>> >>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vpn-mcast= -mib-04 >>>>>>>> >>>>>>>> Please see some notes below. >>>>>>>> >>>>>>>>> >>>>>>>>> Glenn >>>>>>>>> >>>>>>>>> -----------------------------------------------------------------= -- >>>>>>>>> >>>>>>>>> Comments: >>>>>>>>> >>>>>>>>> 1.1 >>>>>>>>> > I had thought this would be standard/obvious for all MIB >>>>>>>>> objects >>>>>>>>> - >>>>>>>>> We will comeback to this time and again, whereever possible make >>>>>>>>> matters explicit and clear. That will help. >>>>>>>>> > Is it enough to say something similar? For example: >>>>>>>>> > In particular, it describes common managed objects us= ed >>>>>>>>> > to configure and/or monitor both L2 and L3 VPN >>>>>>>>> Multicast. >>>>>>>>> That is better. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I take it that this is already closed in -03 revision. >>>>>>>> >>>>>>>>> >>>>>>>>> 2.2 >>>>>>>>> > Having said that, I'll explain PMSI a bit further. >>>>>>>>> PMSI explanation is good. >>>>>>>>> Please use the same style/format for I-PMSI and S-PMSI. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think -03 revision already use the same style/format for I-PMSI >>>>>>>> and >>>>>>>> S-PMSI? >>>>>>>> >>>>>>>>> >>>>>>>>> 2.3 >>>>>>>>> > No difference. I was using "Layer 3" or "L3" but it was point= ed >>>>>>>>> out >>>>>>>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs >>>>>>>>> and >>>>>>>>> I >>>>>>>>> > was advised to change it accordingly. Looks like I did not >>>>>>>>> change >>>>>>>>> all >>>>>>>>> > the cases. >>>>>>>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 >>>>>>>>> VPN" >>>>>>>>> so >>>>>>>>> > I'll change it back. >>>>>>>>> No problems. just make sure that the same expression/notation is >>>>>>>>> used >>>>>>>>> uniformly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I take it that this is also addressed in -03 already. >>>>>>>> >>>>>>>>> 3. >>>>>>>>> > > > 3. Summary of MIB Module. >>>>>>>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- t= he >>>>>>>>> > > > structure of the MIB, short descriptions of the >>>>>>>>> table(s) >>>>>>>>> > > > including usage of the table(s) for management and/or >>>>>>>>> by >>>>>>>>> > > > other MIB(s). >>>>>>>>> > >>>>>>>>> > I had that, but have added one sentence about the only table. >>>>>>>>> A sentence or two about the textual convention will be good. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Added in -04. >>>>>>>> >>>>>>>>> > > > 4. MIB syntax checking: >>>>>>>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>> > >>>>>>>>> > I used simpleweb's validation tool but looks like I did not u= se >>>>>>>>> the >>>>>>>>> > strictest level of validation. I've now fixed the following >>>>>>>>> issues >>>>>>>>> and >>>>>>>>> > verified. >>>>>>>>> Good. >>>>>>>>> 5. >>>>>>>>> > > > >>>>>>>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses >>>>>>>>> liberally. >>>>>>>>> > > > Wherever possible, provide references for objects used >>>>>>>>> in >>>>>>>>> > > > the MIB. The references will point to specific section= s/ >>>>>>>>> > > > sub-sections of the RFCs defining the protocol for whi= ch >>>>>>>>> the >>>>>>>>> > > > MIB is being designed. It will greatly improve the >>>>>>>>> readability >>>>>>>>> > > > of the document. >>>>>>>>> > >>>>>>>>> > Added. >>>>>>>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>>>>>>> improve on it. >>>>>>>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>>>>>>> clause move it to a separate REFERENCE clause. The addition of th= e >>>>>>>>> section number is an improvement. It is friendlier to the reader. >>>>>>>>> Note. Same comment for other OBJECTs too. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Oh I missed that. All fixed. >>>>>>>> >>>>>>>>> 7.1 >>>>>>>>> > > > 7.1 CONTACT-INFO >>>>>>>>> > > > Following the conventions (including indentation styl= e) >>>>>>>>> will >>>>>>>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>> > > > Will be good if it does not overflow into the next >>>>>>>>> page. >>>>>>>>> > >>>>>>>>> > Fixed. >>>>>>>>> The format is OK. The Postal address etc., need not have been >>>>>>>>> deleted. Please put the complete contact information as in the >>>>>>>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> 7.3 >>>>>>>>> > I kept "experimental 99" so that I could continue to use mib >>>>>>>>> tools >>>>>>>>> > to validate; but I added notes for the editor to replace them = as >>>>>>>>> you >>>>>>>>> > indicated. >>>>>>>>> Use of "experimental 99" is not recommended. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Do you mean 99 is not a good number? What about 9999? As I >>>>>>>> explained, >>>>>>>> I >>>>>>>> kept it so that we can use mib tools to validate, and I've added >>>>>>>> detailed >>>>>>>> notes for the editor. >>>>>>>> >>>>>>>>> 8 >>>>>>>>> > > > 8. Specific MO and TC related comments. >>>>>>>>> > Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>> replace >>>>>>>>> > with things like rsvpP2mp. >>>>>>>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ok this is closed already then. >>>>>>>> >>>>>>>>> 8.2 >>>>>>>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>> > The intent is to simply return the octet value of the flags >>>>>>>>> > field, w/o listing individual bits like "Leaf Information >>>>>>>>> Required". >>>>>>>>> > More bits could be defined in the future but the MIB would not >>>>>>>>> change. >>>>>>>>> > >>>>>>>>> > Is that OK? >>>>>>>>> As far as possible, the meaning of the objects must be made clear= . >>>>>>>>> That will help implementors and operators- users of the MIB. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I added the definition for one existing bit and reference to the >>>>>>>> IANA >>>>>>>> registry being created for this flag field. >>>>>>>> >>>>>>>>> >>>>>>>>> 8.3 >>>>>>>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>> > Depending on the tunnel type, there could be different sizes. >>>>>>>>> > Future tunnel types could have other sizes that not specified >>>>>>>>> > today. I was thinking to just give a size >>>>>>>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexibl= e. >>>>>>>>> > Is that ok? >>>>>>>>> I see that you have changed the size upper limit to 50. >>>>>>>>> If the size varies continuously from 0 to 50 the above descriptio= n >>>>>>>>> is correct. >>>>>>>>> Please confirm, explain and cite appropriate reference. If the si= ze >>>>>>>>> may change in the future that must be stated too. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I changed to discrete sizes for currently defined tunnel types. >>>>>>>> >>>>>>>>> >>>>>>>>> 8.4 >>>>>>>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>> > > > SYNTAX RowPointer >>>>>>>>> > > > MAX-ACCESS read-only >>>>>>>>> > > > STATUS current >>>>>>>>> > > > DESCRIPTION >>>>>>>>> > > > "If the tunnel has a corresponding interface, >>>>>>>>> > > > this is the row pointer to the ifName table.= " >>>>>>>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>>>>>>> > > > want to say this object points to the correspondin= g >>>>>>>>> > > > row in the ifTable? >>>>>>>>> > >>>>>>>>> > Yes. Fixed. >>>>>>>>> Not quite. >>>>>>>>> What is ifName table ? ifName is a columnar object in the >>>>>>>>> ifXTable. >>>>>>>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding ro= w >>>>>>>>> in >>>>>>>>> the >>>>>>>>> ifXTable table ? Please fix accordingly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You're right. Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> 9. >>>>>>>>> > > > 9. The Security Considerations section does not follow >>>>>>>>> > > > the Security Guidelines for IETF MIB Modules >>>>>>>>> > > > >>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>> > > > Please fix. >>>>>>>>> > >>>>>>>>> > I was really hoping that it would not have to be that >>>>>>>>> > tedious. SNMP/MIB secur >>>>>>>>> ity should be no different from the >>>>>>>>> > CLI security - once you secure the infrastructure >>>>>>>>> > then what's more to do? >>>>>>>>> > >>>>>>>>> > I'll need more time to work on this. Let me try to address >>>>>>>>> > the issues in the other mib first and come back to this. >>>>>>>>> >>>>>>>>> Please take your time. Looking at examples will help. And let me >>>>>>>>> know where I can help. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I will need to work on that later. >>>>>>>> >>>>>>>>> >>>>>>>>> 10.1 >>>>>>>>> > > > 10.1 Checking nits according to >>>>>>>>> > > > http://www.ietf.org/id-info/checklist : >>>>>>>>> > Should I break them into different lines or just keep them >>>>>>>>> > as is? Any example of expected indentation if I break the >>>>>>>>> > lines? >>>>>>>>> No problems at all to break lines. >>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>>>>>>> ::=3D {l2L3VpnMcastConformance 1} >>>>>>>>> Should do. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Done. >>>>>>>> >>>>>>>>> >>>>>>>>> 10.2 >>>>>>>>> > > > 10.2 Checking references for intended status: Proposed >>>>>>>>> Standard >>>>>>>>> > > > =3D=3D Missing Reference: 'RFC 7117' is mentioned on= line >>>>>>>>> 76, >>>>>>>>> > > > but not defined >>>>>>>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and >>>>>>>>> other >>>>>>>>> > I hope I understood and fixed it (removing the space in "RFC >>>>>>>>> 7117"). >>>>>>>>> I would recommend that you put it as [RFC6513], [RFC6514], >>>>>>>>> [RFC7117] >>>>>>>>> That is simpler to parse. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I see some other documents do not have comma between multiple >>>>>>>> references >>>>>>>> so I followed that. >>>>>>>> >>>>>>>>> >>>>>>>>> > > > 11. There is another WIP MVPN-MIB in >>>>>>>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>>>>>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MI= B. >>>>>>>>> > > > Is there a good reason for not merging the 2 >>>>>>>>> documents? >>>>>>>>> > > > I have not seen any discussion or explanation on thi= s. >>>>>>>>> > > > I may have missed it. >>>>>>>>> > > > Please clarify or, give some pointers. >>>>>>>>> > >>>>>>>>> > As mentioned in the introduction: >>>>>>>>> > >>>>>>>>> > this memo describes managed objects common to both VPLS >>>>>>>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>>>>>>> > in the work and both would reference common >>>>>>>>> >>>>>>>>> > objects defined in this MIB. >>>>>>>>> >>>>>>>>> OK. So you are saying that this MIB contains core objects that >>>>>>>>> will be used to manage implementations of various multicast VPN >>>>>>>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>>>>>>> you spell it out at the beginning. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes. I thought I did it already: >>>>>>>> >>>>>>>> 1. Introduction >>>>>>>> >>>>>>>> ... and this memo describes managed objects common to both VPLS >>>>>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Jeffrey >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----------------------------------------------------------------= ----- >>>>>>>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Glenn, >>>>>>>>>> >>>>>>>>>> Thanks for your comments. I've addressed most of your comments i= n >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> new revision: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> URL: >>>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> l2l3-vpn-mcast-mib-03.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Status: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> vpn-mcast-mib/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Htmlized: >>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> mcast-mib-03 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Diff: >>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> vpn-mcast-mib-03 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please see below. >>>>>>>>>> >>>>>>>>>>> 1. Abstract: >>>>>>>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>>>>>>> applications for operations, monitoring and management >>>>>>>>>>> would be good. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I had thought this would be standard/obvious for all MIB objects= - >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> read-write ones are used to control how a device works, and the >>>>>>>>> read-only >>>>>>>>> ones are used for monitoring. Do I really need to say it >>>>>>>>> explicitly? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see RFC 4382 has the following: >>>>>>>>>> >>>>>>>>>> This memo defines a portion of the Management Information Bas= e >>>>>>>>>> (MIB) >>>>>>>>>> for use with network management protocols in the Internet >>>>>>>>>> community. >>>>>>>>>> In particular, it describes managed objects to configure and/= or >>>>>>>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>>>>>>> Networks on a Multiprotocol Label Switching (MPLS) Label >>>>>>>>>> Switching >>>>>>>>>> Router (LSR) supporting this feature. >>>>>>>>>> >>>>>>>>>> Is it enough to say something similar? For example: >>>>>>>>>> >>>>>>>>>> In particular, it describes common managed objects used = to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> configure >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. Introduction >>>>>>>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>>>>>>> appearing for the first time. (PE, VPLS,..) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>>>>>>> terms that are used, nicely with reference to the protocol >>>>>>>>>>> documents will improve readability. >>>>>>>>>>> e.g. >>>>>>>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As the paragraph alluded to, this MIB needs to be understood in >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> general context of L2/L3 multicast VPN and providing good >>>>>>>>> explanation >>>>>>>>> of >>>>>>>>> the terms is not attempted. The references for the terms are the >>>>>>>>> the >>>>>>>>> RFCs >>>>>>>>> for the relevant technologies. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Having said that, I'll explain PMSI a bit further. >>>>>>>>>> >>>>>>>>>>> 2.3 Is there a difference between >>>>>>>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>>>>>>> RFC 7117 and RFC 6513/6514" >>>>>>>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>>>>>>> and >>>>>>>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>>>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>>>>>>> If these are the same, it will be helpful to stick to the >>>>>>>>>>> same expression. If these are not the same, the dictinction >>>>>>>>>>> should be clarified. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>>> out >>>>>>>>>> that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I w= as >>>>>>>>> advised to change it accordingly. Looks like I did not change all >>>>>>>>> the >>>>>>>>> cases. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN= " >>>>>>>>>> so >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll change it back. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3. Summary of MIB Module. >>>>>>>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>>>> structure of the MIB, short descriptions of the table(s) >>>>>>>>>>> including usage of the table(s) for management and/or by >>>>>>>>>>> other MIB(s). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I had that, but have added one sentence about the only table. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> MIB definitions: >>>>>>>>>>> 4. MIB syntax checking: >>>>>>>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I used simpleweb's validation tool but looks like I did not use >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> strictest level of validation. I've now fixed the following issue= s >>>>>>>>> and >>>>>>>>> verified. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> See later question/comments below. >>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: >>>>>>>>>>> current >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this modul= e >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never us= ed >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never >>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is >>>>>>>>> never >>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never us= ed >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is neve= r >>>>>>>>> used >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Removed the above unused imports. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>>>>>>> Wherever possible, provide references for objects used in >>>>>>>>>>> the MIB. The references will point to specific sections/ >>>>>>>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>>>>>>> MIB is being designed. It will greatly improve the readabili= ty >>>>>>>>>>> of the document. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Added. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 6. IMPORTS clause >>>>>>>>>>> MIB modules from which items are imported must be cited and >>>>>>>>>>> included in the normative references. >>>>>>>>>>> The conventional style is >>>>>>>>>>> mplsStdMIB >>>>>>>>>>> FROM MPLS-TC-STD-MIB -- >>>>>>>>>>> [RFC3811] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Added. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic >>>>>>>>>>> errors.) >>>>>>>>>>> 7.1 CONTACT-INFO >>>>>>>>>>> Following the conventions (including indentation style) wil= l >>>>>>>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>>>> Will be good if it does not overflow into the next page. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7.2 REVISION clause: follow the convention recommended in RFC41= 81 >>>>>>>>>>> sec 4.5 >>>>>>>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>>>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>>>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove thi= s >>>>>>>>>>> note: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> 7.3 OID assignment: follow the convention recommended in RFC418= 1 >>>>>>>>>>> sec 4.5 i >>>>>>>>>>> replace >>>>>>>>>>> ::=3D { experimental 99 } -- number to be assigned >>>>>>>>>>> by >>>>>>>>>>> ::=3D { XXX } >>>>>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove >>>>>>>>>>> this >>>>>>>>>>> note >>>>>>>>>>> will be the subtree under which the module will be >>>>>>>>>>> registered. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I kept "experimental 99" so that I could continue to use mib too= ls >>>>>>>>>> to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> validate; but I added notes for the editor to replace them as you >>>>>>>>> indicated. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8. Specific MO and TC related comments. >>>>>>>>>>> L2L3VpnMcastProviderTunnelType ::=3D TEXTUAL-CONVENTION >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>>>>> BGP/MPLS L2 or IP VPN." >>>>>>>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>>>>>>> rsvp-p2mp (1), >>>>>>>>>>> ldp-p2mp (2), >>>>>>>>>>> pim-asm (3), >>>>>>>>>>> pim-ssm (4), >>>>>>>>>>> pim-bidir (5), >>>>>>>>>>> ingress-replication (6), >>>>>>>>>>> ldp-mp2mp (7) >>>>>>>>>>> >>>>>>>>>>> o Would be nice to align the enumeration labels with the >>>>>>>>>>> labels in the protocol document RFC 6514 unless there is >>>>>>>>>>> a good reason for not doing so. (You will have to take >>>>>>>>>>> care of the smi compilation errors too; '-' is not allowe= d >>>>>>>>>>> ). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>>> replace >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> with things like rsvpP2mp. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Or could/should I just remove the definitions, so that if a new >>>>>>>>>> type >>>>>>>>>> is >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> defined in the future there is no need to update the MIB? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "An entry in this table corresponds to an PMSI >>>>>>>>>>> attribute >>>>>>>>>>> that is advertised/received on this router. >>>>>>>>>>> For BGP-based signaling (for I-PMSI via >>>>>>>>>>> auto-discovery >>>>>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>>>>> they are just as signaled by BGP (RFC 6514 sectio= n >>>>>>>>>>> 5, >>>>>>>>>>> 'PMSI Tunnel attribute'). >>>>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>>>> they're derived from S-PMSI Join Message >>>>>>>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>>>>>>> >>>>>>>>>>> Note that BGP-based signaling may be used for >>>>>>>>>>> PIM-MVPN as well." >>>>>>>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>>>>>>> o Please give the reference for this Table. >>>>>>>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>>>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>>>>>>> both? >>>>>>>>>>> Any other pointers? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this >>>>>>>>>>> is >>>>>>>>>>> 0. >>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Fla= gs >>>>>>>>>>> field in PMSI Tunnel Attribute of the correspondi= ng >>>>>>>>>>> I/S-PMSI A-D route." >>>>>>>>>>> ::=3D { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>>>>>>> o Please confirm that the above is a complete enumeration = of >>>>>>>>>>> the >>>>>>>>>>> types of signalling. >>>>>>>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>>>>>>> "Leaf Information Required". That is useful information. >>>>>>>>>>> Please include in the description. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The intent is to simply return the octet value of the flags fiel= d, >>>>>>>>>> w/o >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> listing individual bits like "Leaf Information Required". More bi= ts >>>>>>>>> could >>>>>>>>> be defined in the future but the MIB would not change. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is that OK? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the >>>>>>>>>>> first >>>>>>>>>>> four or sixteen octets of this attribute are fill= ed >>>>>>>>>>> with >>>>>>>>>>> the provider tunnel group address (IPv4 or IPv6).= . >>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the >>>>>>>>>>> Tunnel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Identifier >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Field in PMSI Tunnel Attribute of the correspondi= ng >>>>>>>>>>> I/S- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> PMSI >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A-D route." >>>>>>>>>>> o Check the size specifications. The specs above say it can >>>>>>>>>>> be >>>>>>>>>>> all sizes 0..37. That is not clear from the DESCRIPTION >>>>>>>>>>> clause. >>>>>>>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>>>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Identifiers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress >>>>>>>>>>> Replication,MP2MP. >>>>>>>>>>> It appears that the sizes (range) for each case will be >>>>>>>>>>> different. >>>>>>>>>>> Please clarify that, and if there are discrete sizes, >>>>>>>>>>> specify >>>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Depending on the tunnel type, there could be different sizes. >>>>>>>>>> Future >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> tunnel types could have other sizes that not specified today. I w= as >>>>>>>>> thinking to just give a size range so that it is flexible. Is tha= t >>>>>>>>> ok? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "If the tunnel exists in some MIB table, this is th= e >>>>>>>>>>> row pointer to it." >>>>>>>>>>> o "some MIB table" : specify which MIB table. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could >>>>>>>>>> be >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> whatever table that a tunnel may be put into. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> o In what case will the tunnel exist and in what case will = it >>>>>>>>>>> not? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If a device supports mplsTunnelTable and the tunnel is represent= ed >>>>>>>>>> there, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> then it exists. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> o What will be the behaviour if the above condition is not >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> satisfied? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A null pointer should be given. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "If the tunnel has a corresponding interface, this = is >>>>>>>>>>> the >>>>>>>>>>> row pointer to the ifName table." >>>>>>>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want = to >>>>>>>>>>> say >>>>>>>>>>> this object points to the corresponding row in the >>>>>>>>>>> ifTable? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes. Fixed. >>>>>>>>>> >>>>>>>>>>> o In what case does the TunnelIf exist and in what case wi= ll >>>>>>>>>>> it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> not? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Some tunnels may not have a corresponding interface. >>>>>>>>>> >>>>>>>>>>> o What will be expected if the tunnel does not have a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> corresponding >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> interface? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Null row pointer. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9. The Security Considerations section does not follow the >>>>>>>>>>> Security >>>>>>>>>>> Guidelines for IETF MIB Modules >>>>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>>>> Please fix. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I was really hoping that it would not have to be that tedious. >>>>>>>>>> SNMP/MIB >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> security should be no different from the CLI security - once you >>>>>>>>> secure >>>>>>>>> the infrastructure then what's more to do? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll need more time to work on this. Let me try to address the >>>>>>>>>> issues >>>>>>>>>> in >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> the other mib first and come back to this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 10.ID-nits >>>>>>>>>>> 10.1 Checking nits according to >>>>>>>>>>> http://www.ietf.org/id-info/checklist >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------= --- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** There are 4 instances of too long lines in the document= , >>>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> longest one >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> being 3 characters in excess of 72. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I fixed some but there still three too long lines: >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>>>>>>> L2L3VpnMcastProviderTunnelType, >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::=3D >>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::=3D >>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Should I break them into different lines or just keep them as is= ? >>>>>>>>>> Any >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> example of expected indentation if I break the lines? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 10.2 Checking references for intended status: Proposed Standard >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------= --- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> =3D=3D Missing Reference: 'RFC 7117' is mentioned on line = 76, >>>>>>>>>>> but >>>>>>>>>>> not >>>>>>>>>>> defined >>>>>>>>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other 2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni : > Dear Tsunoda, >> I think that I have addressed all of Glenn's comments in >> this revision. > Thanks for addressing the comments. The MIB compiles OK and > is looking good. It is shaping up well. > A new set of comments is attached. Please check and do the > > needful. > Glenn > On 2017/02/21 16:50, Hiroshi Tsunoda wrote: >> >> Dear Glenn and BESS WG, >> >> I posted a new revision as follows. >> I think that I have addressed all of Glenn's comments in this revision. >> >> In this revision, I have tried to add more detailed explanation >> throughout the document. >> Please review and let me know if there are any misunderstanding from >> technical view points. >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-= 06.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-06 >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vpn-mcast-mib-0= 6 >> >> Please see some notes below. >> >>> 1. Introduction >>> >>> 1.1 >>> Would be very nice if a short explanations of MVPN and >>> L2 VPN Multicast were given. With emphasis on the operational >>> aspects. >> >> >> I have updated Introduction. I hope this update fulfills your >> requirements. >> >>> 1.4 .... there are 2 types of PMSIs .. >>> >>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>> >>> >>> please make these explanations more gentle(complete) to the reader. >>> Also, give the references where these terms are defined. >> >> >> More gentle explanation and references were added in Terminology >> section (Sec.1.1). >> >>> 3.2 some more text like the following will be good. >>> L2L3-VPN-MCAST-MIB contains >>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>> an enumeration of the provider tunnel types and, >>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>> composed of multiple attributes that depend on the tunnel type an= d >>> uniquely identify a tunnel. This table will be used to ... monito= r >>> the tunnels supported by the system at a given point of time (?) >>> It may also be used in conjunction with XXXX-mib to obtain the >>> other details of a tunnel by following the row pointer of the >>> corresponding tunnel's row in this table. >>> [ Please treat the above as a template and modify the text as >>> appropriate ..] >> >> >> Fixed in this revision. Please look at Sec. 3 Summary of MIB Module. >> >>> 3.3 Since this will become a standard document, please take care of >>> definitions and notations used in the document. >>> The notation I/S-PMSI is not defined. If you must use a new >>> term/notation, define it before use. >> >> >> The notation I/S-PMSI is defined in Sec.1.1 now. >> >>> 4.8 >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>> MAX-ACCESS not-accessible >>>> STATUS current >>>> DESCRIPTION >>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>> The entries may be referred to by I-PMSI or S-PMSI table >>>> entries defined in other MIBs, e.g. mvpnMIB in >>>> [I-D.ietf-bess-mvpn-mib]." >>> >>> >>> It would seem that each row in this table is an index for a PTA >>> and may contain pointers to rows in tables of other MIB modules >>> which may contain more details for the PTA. Is that correct? >>> Please reword the DESCRIPTION acordingly. >>> Also see comments in 4.15 >> >> >> I have changed DESCRIPTION as follows. >> >> "An entry of this table corresponds with a >> PMSI Tunnel attribute and is created by a PE router >> that advertises and receives the attribute. >> The entry in the table will be referred by other MIB modules >> which are designed for monitoring and/or configuring >> both L2 and L3 VPN that support multicast." >> >> >>> 4.10-3 >>> the phrase UDP-based S-PMSI appears here for the first time. >>> Somewhere earlier it should be made clear that UDP too may be used >>> in signaling. >> >> >> In Introduction, I have explained that BGP and UDP are used in signaling= . >> >>> 4.13 >>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>> >>>> DESCRIPTION >>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>> field in PMSI Tunnel Attribute of the corresponding >>>> I/S-PMSI A-D or Leaf A-D route." >>> >>> o Does this description cover all the types? If not, then cover all t= he >>> types unless there is a good reason to focus only on the above type= s. >>> o I/S-PMSI: unexplained notation. >> >> >> Fixed. >> >>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>> >>> Please indicate that the first column gives the size >> >> >> I have updated the table as follows. >> >> Size (in octets) l2L3VpnMcastPmsiTunnelAttributeType >> IPv4 IPv6 (tunneling technology) >> -------------------------------------------------- >> 0 0 noTunnelId (No tunnel information presen= t) >> 12 24 rsvpP2mp (RSVP-TE P2MP LSP) >> 17 29 ldpP2mp (mLDP P2MP LSP) >> 8 32 pimSsm (PIM-SSM Tree) >> >>>> 8/32 pimAsm >>>> 8/32 pimSsm >>>> 8/32 pimBidir >>>> 4/16 ingressReplication >>> >>> >>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>> 8 or 32 octets of this attribute are filled with >>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>> Identifier field in PMSI Tunnel Attribute of the >>>> corresponding I/S-PMSI A-D route." >>> >>> >>> A more generous description of the AttributeID would be good. All the >>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>> summary would be very nice. >> >> >> Fixed. I have summarized Section 5 of RFC 6514 here. >> >>> 4.15 >>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>> >>>> SYNTAX RowPointer >>>> DESCRIPTION >>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>> pointer is null." >>> >>> I am having problems understanding this. Will help if you can give >>> a use case of how this will be used. As of now the intent is unclear. >>> A RowPointer cannot be pointing to "some MIB table". It must be >>> pointer to a specific row in a specific table. If this is a pointer t= o >>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >> >> >> I have changed DESCRIPTION as follows. >> >> "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId >> may be represented as an entry in other table, e.g, >> mplsTunnelTable [RFC3812]. If there is such entry, >> this object will point to the row pertaining to the entry. >> Otherwise, the pointer is null." >> >>> 5.0 >>>> >>>> 5. Security Considerations >>> >>> TBD >> >> >> I have rewritten this part according to the guideline described in >> RFC4181 Sec.3.4. >> >>> 6.0 >>>> >>>> 6. IANA Considerations >>> >>> >>>> IANA is requested to root MIB objects in the MIB module contained in >>>> this document under the mib-2 subtree. >>> >>> >>> Please Note: >>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need = to >>> put the definitions in a separate MIB module. That would mean a >>> separate branch in the mib-2 subtree. Then the maintenance of the >>> TC can be carried out by some entity ( IANA or, some WG or, whoever = is >>> responsible for maintaining the TC) independent of other MIB objects= . >>> If that is the intent you will need to define 2 mib modules and you >>> will >>> need to request 2 branches in the mib-2 subtree- one for the module >>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >> >> >> Now, this document defines following two MIB modules: >> - the module containing the L2L3VpnMcastProviderTunnelType TC >> - the module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >> >> -- tsuno >> >> 2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni : >>> >>> Dear Tsunoda, >>>> >>>> I will submit the next version within three days. >>>> The next versionbwill address all of remained your >>>> comments. >>> >>> Great! Looking forward to the revised draft. >>> >>> Glenn >>> >>> On 2017/02/18 16:30, Hiroshi Tsunoda wrote: >>>> >>>> >>>> Dear Glenn, >>>> >>>> I am sorry I kept you waiting so long for the revised version, I have >>>> been side tracked by other things. >>>> I will submit the next version within three days. The next version >>>> will address all of remained your comments. >>>> The summary of remained TODOs is shown below. Please wait a little >>>> more >>>> time. >>>> ------------- >>>> 1. Add general explanation about MVPN, multicast in VPLS >>>> Define and explain some technical terms, such as PIM-MVPN, >>>> UDP-based S-PMSI etc. >>>> >>>> 2. Revise summary of the MIB module >>>> >>>> 3. Revise MIB definition >>>> a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable >>>> b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to >>>> cover all cases. >>>> c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId >>>> d. Fix the description of l2L3VpnMcastPmsiTunnelPointer >>>> >>>> 4. Split the MIB module into two separate modules. >>>> >>>> 5. Revise security considertations >>>> ------------- >>>> >>>> P.S. Update of mvpn-mib-02 will be submitted by the end of this month. >>>> >>>> Best regards, >>>> >>>> -- tsuno >>>> >>>> 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : >>>>> >>>>> >>>>> Hi Tsunoda, >>>>>> >>>>>> >>>>>> I have started to volunteer to help to move this document forward. >>>>> >>>>> >>>>> Great! >>>>>> >>>>>> >>>>>> I posted a new revision and addressed all editorial things in >>>>>> that revision. >>>>> >>>>> >>>>> Got this. Looks good. >>>>>> >>>>>> >>>>>> Please give me some more time for revising other parts, >>>>> >>>>> >>>>> No problems. Will be looking forward to the revised document. >>>>> >>>>> Glenn >>>>> >>>>> >>>>> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>>>>> >>>>>> >>>>>> >>>>>> Dear Glenn, >>>>>> >>>>>> Thanks for your careful review and detailed comments/suggestions. >>>>>> I have started to volunteer to help to move this document forward. >>>>>> I posted a new revision and addressed all editorial things in that >>>>>> revision. >>>>>> Please give me some more time for revising other parts, >>>>>> in order to be familiar with the context of the original and related >>>>>> documents. >>>>>> >>>>>> URL: >>>>>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 >>>>>> Diff: >>>>>> >>>>>> >>>>>> >>>>>> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vpn-mcast= -mib-05.txt >>>>>> >>>>>> Please see some notes below. >>>>>> >>>>>>> 0. Abstract. >>>>>>> 0.1. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> it describes common managed objects used to configure >>>>>>> >>>>>>> >>>>>>> >>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>> >>>>>>> There are no writable MOs in this MIB. So it does not look >>>>>>> as though this MIB will be used for configuration directly. >>>>>>> The use case scenario for monitoring is not clear, either. >>>>>>> It appears that the MIB module(s) in this document will be >>>>>>> used by other modules which are designed for monitoring and/ >>>>>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>>>>> wording. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1. Introduction >>>>>>> >>>>>>> 1.1 >>>>>>> Would be very nice if a short explanations of MVPN and >>>>>>> L2 VPN Multicast were given. With emphasis on the operational >>>>>>> aspects. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise. >>>>>> >>>>>>> 1.2 >>>>>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>>>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1.3 >>>>>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1.4 .... there are 2 types of PMSIs .. >>>>>>> >>>>>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> please make these explanations more gentle(complete) to the >>>>>>> reader. >>>>>>> Also, give the references where these terms are defined. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise. >>>>>> >>>>>>> 3. Summary of MIB Module >>>>>>> 3.1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>>>>> >>>>>>> >>>>>>> >>>>>>> Typo: I/S-PMSI, (see 3.3 below). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 3.2 some more text like the following will be good. >>>>>>> L2L3-VPN-MCAST-MIB contains >>>>>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that >>>>>>> provides >>>>>>> an enumeration of the provider tunnel types and, >>>>>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index >>>>>>> is >>>>>>> composed of multiple attributes that depend on the tunnel typ= e >>>>>>> and >>>>>>> uniquely identify a tunnel. This table will be used to ... >>>>>>> monitor >>>>>>> the tunnels supported by the system at a given point of time >>>>>>> (?) >>>>>>> It may also be used in conjunction with XXXX-mib to obtain th= e >>>>>>> other details of a tunnel by following the row pointer of the >>>>>>> corresponding tunnel's row in this table. >>>>>>> [ Please treat the above as a template and modify the text as >>>>>>> appropriate ..] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 3.3 Since this will become a standard document, please take care of >>>>>>> definitions and notations used in the document. >>>>>>> The notation I/S-PMSI is not defined. If you must use a new >>>>>>> term/notation, define it before use. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 4. Definitions >>>>>>> >>>>>>>> IMPORTS >>>>>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4.1 Since this is not a Experimental MIB do not import use >>>>>>> experimental. >>>>>>> It is good practice to keep the draft in the as "close to final >>>>>>> form" >>>>>>> as possible. (See below) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please update this date. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Updated. >>>>>> >>>>>>> 4.3 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "This MIB contains common managed object definitions for >>>>>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Would be good if you could rearrange the text. Something like >>>>>>> "This MIB module will be used for managing multicast in Layer = 2 >>>>>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>>>>> Or, even better >>>>>>> "This MIB module will be used by other MIB modules designed fo= r >>>>>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>>>>> [RFC6513], [RFC6514] >>>>>>> Or, a combination of both, depending on the envisaged use case >>>>>>> scenarios. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Rearranged the text along with your comment. >>>>>> >>>>>>> 4.4 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ::=3D { experimental 999 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please >>>>>>> o Replace "experimental" by the branch where this mib module >>>>>>> will >>>>>>> be anchored; that is a decision that the WG will take, >>>>>>> probably. >>>>>>> o Import the branch in the IMPORTS statement >>>>>>> [ In the IANA Considerations section a branch in the mib-2 >>>>>>> subtree >>>>>>> is requested. In that case this must be >>>>>>> ::=3D { mib-2 XXX } >>>>>>> ] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.5 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Please also remove the ", experimental" text from earlier >>>>>>>> -- IMPORTS section. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Remove these instructions. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed. >>>>>> >>>>>>> 4.5.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Texual convention >>>>>>> >>>>>>> >>>>>>> >>>>>>> Typo: -- Textual convention >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.6 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> L2L3VpnMcastProviderTunnelType ::=3D TEXTUAL-CONVENTION >>>>>>>> DESCRIPTION >>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>>>>> in future RFCs, and those will be allowed as >>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>> >>>>>>> >>>>>>> >>>>>>> The part >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Additional types may be defined >>>>>>>> in future RFCs, and those will be allowed as >>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>> >>>>>>> >>>>>>> >>>>>>> may be deleted. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Deleted. >>>>>> >>>>>>> 4.7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Top level components of this MIB. >>>>>>>> -- tables, scalars, conformance information >>>>>>>> >>>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB = 1 } >>>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB = 2 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::=3D { l2L3VpnMcastObjects= 1 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> should be >>>>>>> >>>>>>> -- Top level components of this MIB. >>>>>>> >>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB= 1 } >>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::=3D { l2L3VpnMcastMIB= 2 } >>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::=3D { l2L3VpnMcastObj= ects >>>>>>> 1 >>>>>>> } >>>>>>> >>>>>>> -- tables, scalars, conformance information >>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.8 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>> MAX-ACCESS not-accessible >>>>>>>> STATUS current >>>>>>>> DESCRIPTION >>>>>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>>>>> [I-D.ietf-bess-mvpn-mib]." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It would seem that each row in this table is an index for a PTA >>>>>>> and may contain pointers to rows in tables of other MIB modules >>>>>>> which may contain more details for the PTA. Is that correct? >>>>>>> Please reword the DESCRIPTION acordingly. >>>>>>> Also see comments in 4.15 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I need some more time to understand the original context. >>>>>> >>>>>>> 4.9 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>> "An entry in this table corresponds to a PTA >>>>>>>> that is advertised/received on this router. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntr= y" >>>>>>> so "entry in this table" does not fit in well. >>>>>>> A rewording like >>>>>>> "A conceptual row corresponding to a PTA >>>>>>> that is advertised/received on this router. >>>>>>> .... >>>>>>> would be better. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.10 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>> they are just as signaled by BGP. >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>> they're derived from the S-PMSI Join Message. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Note that BGP-based signaling may be used for >>>>>>>> PIM-MVPN as well." >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is the signaling mechanism important here? If it isn't then the >>>>>>> above part of the description is redundant. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed the above part. >>>>>> >>>>>>> 4.10-2 >>>>>>> PIM-MVPN appears for the first time. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Defined the notation of PIM-MVPM as follows >>>>>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>>>>> However, I think that some descriptions may be required for this >>>>>> somewhere in this document. That is TBD. >>>>>> >>>>>>> 4.10-3 >>>>>>> the phrase UDP-based S-PMSI appears here for the first time. >>>>>>> Somewhere earlier it should be made clear that UDP too may be use= d >>>>>>> in signaling. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. >>>>>> >>>>>>> 4.11 >>>>>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>>> >>>>>>> >>>>>>> >>>>>>> "this" is unclear. >>>>>>> Something like "the value of this object is 0" will be better= . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>>> More bits may be defined in the future and >>>>>>>> they will be registered in IANA Registry xxxx." >>>>>>> >>>>>>> >>>>>>> >>>>>>> This part is probably redundant. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed. >>>>>> >>>>>>> 4.12 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>>>>> -- and remove this note. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Look at the comments in 6.0 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The above description ("IANA Registry xxxx.") was removed, >>>>>> thus this part was also removed. >>>>>> >>>>>>> 4.13 >>>>>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>> I/S-PMSI A-D or Leaf A-D route." >>>>>>> >>>>>>> >>>>>>> >>>>>>> o Does this description cover all the types? If not, then cover a= ll >>>>>>> the >>>>>>> types unless there is a good reason to focus only on the above >>>>>>> types. >>>>>>> o I/S-PMSI: unexplained notation. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to address this point. >>>>>> >>>>>>> 4.14 >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>>>>> >>>>>>> >>>>>>> >>>>>>> It appears that you also allow sizes "16" and "32"; these must be >>>>>>> included. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please indicate that the first column gives the size >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I made a change as follows. >>>>>> >>>>>> Size l2L3VpnMcastPmsiTunnelAttributeType >>>>>> (IPv4/IPv6) >>>>>> -------------------------------------------------- >>>>>> (snip) >>>>>> 8/32 pimAsm >>>>>> (snip) >>>>>> >>>>>> Is this OK? >>>>>> >>>>>>>> 8/32 pimAsm >>>>>>>> 8/32 pimSsm >>>>>>>> 8/32 pimBidir >>>>>>>> 4/16 ingressReplication >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>>>> 8 or 32 octets of this attribute are filled with >>>>>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>>>>> Identifier field in PMSI Tunnel Attribute of the >>>>>>>> corresponding I/S-PMSI A-D route." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A more generous description of the AttributeID would be good. All >>>>>>> the >>>>>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A >>>>>>> simple >>>>>>> summary would be very nice. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 4.15 >>>>>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> SYNTAX RowPointer >>>>>>>> DESCRIPTION >>>>>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTab= le >>>>>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>>>>> pointer is null." >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am having problems understanding this. Will help if you can giv= e >>>>>>> a use case of how this will be used. As of now the intent is >>>>>>> unclear. >>>>>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>>>>> pointer to a specific row in a specific table. If this is a point= er >>>>>>> to >>>>>>> a row in the mplsTunnelTable spell it out clearly and >>>>>>> unambiguously. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I will need some more time to understand the original context. >>>>>> >>>>>>> 4.16 >>>>>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>> DESCRIPTION >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "If the tunnel has a corresponding interface, this is the >>>>>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>>>>> >>>>>>> >>>>>>> >>>>>>> This description is better. Would be even better with >>>>>>> "If the tunnel has a corresponding entry in the ifXTable, >>>>>>> this object will point to the row pertaining to the entry >>>>>>> ..... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.17 >>>>>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "Support of these object is not required." >>>>>>> >>>>>>> >>>>>>> >>>>>>> Support of these objects is not required. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 5.0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 5. Security Considerations >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Still TBD. >>>>>> >>>>>>> 6.0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 6. IANA Considerations >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> IANA is requested to root MIB objects in the MIB module contained >>>>>>>> in >>>>>>>> this document under the mib-2 subtree. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please Note: >>>>>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you >>>>>>> need >>>>>>> to >>>>>>> put the definitions in a separate MIB module. That would mean a >>>>>>> separate branch in the mib-2 subtree. Then the maintenance of t= he >>>>>>> TC can be carried out by some entity ( IANA or, some WG or, >>>>>>> whoever >>>>>>> is >>>>>>> responsible for maintaining the TC) independent of other MIB >>>>>>> objects. >>>>>>> If that is the intent you will need to define 2 mib modules and >>>>>>> you >>>>>>> will >>>>>>> need to request 2 branches in the mib-2 subtree- one for the >>>>>>> module >>>>>>> containing the L2L3VpnMcastProviderTunnelType TC and another for >>>>>>> the >>>>>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I will address this point in the next revision. >>>>>> >>>>>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Jeffrey, >>>>>>> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >>>>>>> document. It took me some time to do this review. But now here it >>>>>>> is. A (near complete) review of >>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>> is >>>>>>> attached. Hope this helps. >>>>>>> I understand that the Security Considerations section is TBD. >>>>>>> >>>>>>> Glenn >>>>>>> >>>>>>> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Glenn, >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>>>>>>>> Sent: Sunday, May 08, 2016 11:02 AM >>>>>>>>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>>>>>>>> ; EXT - thomas.morin@orange.com >>>>>>>>> >>>>>>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>>>>>> Vigoureux >>>>>>>>> ; bess@ietf.org; mib-doctors@ietf.org >>>>>>>>> Subject: Re: [bess] MIBDoc review of >>>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>>>>>>> 02.txt >>>>>>>>> >>>>>>>>> Jeffrey, >>>>>>>>> > Thanks for your comments. I've addressed most of your comments >>>>>>>>> > in the new revision: >>>>>>>>> Thanks for your cooperation. I will need at least one more revisi= on >>>>>>>>> with the following comments/recommendations addressed before I wi= ll >>>>>>>>> be able to complete the detailed review. In the following the >>>>>>>>> numbers >>>>>>>>> refer to the issue numbers in the initial review. The issues that >>>>>>>>> are >>>>>>>>> addressed and closed are not listed. For brevity, the issue >>>>>>>>> descriptions have been trimmed. In case of doubts please look at >>>>>>>>> the >>>>>>>>> response mail appended below. >>>>>>>>> Hope this helps. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks for your detailed comments/suggestions. I posted a new >>>>>>>> revision >>>>>>>> with the following issues addressed. >>>>>>>> >>>>>>>> URL: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcas= t-mib-04.txt >>>>>>>> Status: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mi= b/ >>>>>>>> Htmlized: >>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>> Diff: >>>>>>>> >>>>>>>> >>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vpn-mcast= -mib-04 >>>>>>>> >>>>>>>> Please see some notes below. >>>>>>>> >>>>>>>>> >>>>>>>>> Glenn >>>>>>>>> >>>>>>>>> -----------------------------------------------------------------= -- >>>>>>>>> >>>>>>>>> Comments: >>>>>>>>> >>>>>>>>> 1.1 >>>>>>>>> > I had thought this would be standard/obvious for all MIB >>>>>>>>> objects >>>>>>>>> - >>>>>>>>> We will comeback to this time and again, whereever possible make >>>>>>>>> matters explicit and clear. That will help. >>>>>>>>> > Is it enough to say something similar? For example: >>>>>>>>> > In particular, it describes common managed objects us= ed >>>>>>>>> > to configure and/or monitor both L2 and L3 VPN >>>>>>>>> Multicast. >>>>>>>>> That is better. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I take it that this is already closed in -03 revision. >>>>>>>> >>>>>>>>> >>>>>>>>> 2.2 >>>>>>>>> > Having said that, I'll explain PMSI a bit further. >>>>>>>>> PMSI explanation is good. >>>>>>>>> Please use the same style/format for I-PMSI and S-PMSI. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think -03 revision already use the same style/format for I-PMSI >>>>>>>> and >>>>>>>> S-PMSI? >>>>>>>> >>>>>>>>> >>>>>>>>> 2.3 >>>>>>>>> > No difference. I was using "Layer 3" or "L3" but it was point= ed >>>>>>>>> out >>>>>>>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs >>>>>>>>> and >>>>>>>>> I >>>>>>>>> > was advised to change it accordingly. Looks like I did not >>>>>>>>> change >>>>>>>>> all >>>>>>>>> > the cases. >>>>>>>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 >>>>>>>>> VPN" >>>>>>>>> so >>>>>>>>> > I'll change it back. >>>>>>>>> No problems. just make sure that the same expression/notation is >>>>>>>>> used >>>>>>>>> uniformly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I take it that this is also addressed in -03 already. >>>>>>>> >>>>>>>>> 3. >>>>>>>>> > > > 3. Summary of MIB Module. >>>>>>>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- t= he >>>>>>>>> > > > structure of the MIB, short descriptions of the >>>>>>>>> table(s) >>>>>>>>> > > > including usage of the table(s) for management and/or >>>>>>>>> by >>>>>>>>> > > > other MIB(s). >>>>>>>>> > >>>>>>>>> > I had that, but have added one sentence about the only table. >>>>>>>>> A sentence or two about the textual convention will be good. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Added in -04. >>>>>>>> >>>>>>>>> > > > 4. MIB syntax checking: >>>>>>>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>> > >>>>>>>>> > I used simpleweb's validation tool but looks like I did not u= se >>>>>>>>> the >>>>>>>>> > strictest level of validation. I've now fixed the following >>>>>>>>> issues >>>>>>>>> and >>>>>>>>> > verified. >>>>>>>>> Good. >>>>>>>>> 5. >>>>>>>>> > > > >>>>>>>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses >>>>>>>>> liberally. >>>>>>>>> > > > Wherever possible, provide references for objects used >>>>>>>>> in >>>>>>>>> > > > the MIB. The references will point to specific section= s/ >>>>>>>>> > > > sub-sections of the RFCs defining the protocol for whi= ch >>>>>>>>> the >>>>>>>>> > > > MIB is being designed. It will greatly improve the >>>>>>>>> readability >>>>>>>>> > > > of the document. >>>>>>>>> > >>>>>>>>> > Added. >>>>>>>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>>>>>>> improve on it. >>>>>>>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>>>>>>> clause move it to a separate REFERENCE clause. The addition of th= e >>>>>>>>> section number is an improvement. It is friendlier to the reader. >>>>>>>>> Note. Same comment for other OBJECTs too. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Oh I missed that. All fixed. >>>>>>>> >>>>>>>>> 7.1 >>>>>>>>> > > > 7.1 CONTACT-INFO >>>>>>>>> > > > Following the conventions (including indentation styl= e) >>>>>>>>> will >>>>>>>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>> > > > Will be good if it does not overflow into the next >>>>>>>>> page. >>>>>>>>> > >>>>>>>>> > Fixed. >>>>>>>>> The format is OK. The Postal address etc., need not have been >>>>>>>>> deleted. Please put the complete contact information as in the >>>>>>>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> 7.3 >>>>>>>>> > I kept "experimental 99" so that I could continue to use mib >>>>>>>>> tools >>>>>>>>> > to validate; but I added notes for the editor to replace them = as >>>>>>>>> you >>>>>>>>> > indicated. >>>>>>>>> Use of "experimental 99" is not recommended. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Do you mean 99 is not a good number? What about 9999? As I >>>>>>>> explained, >>>>>>>> I >>>>>>>> kept it so that we can use mib tools to validate, and I've added >>>>>>>> detailed >>>>>>>> notes for the editor. >>>>>>>> >>>>>>>>> 8 >>>>>>>>> > > > 8. Specific MO and TC related comments. >>>>>>>>> > Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>> replace >>>>>>>>> > with things like rsvpP2mp. >>>>>>>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ok this is closed already then. >>>>>>>> >>>>>>>>> 8.2 >>>>>>>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>> > The intent is to simply return the octet value of the flags >>>>>>>>> > field, w/o listing individual bits like "Leaf Information >>>>>>>>> Required". >>>>>>>>> > More bits could be defined in the future but the MIB would not >>>>>>>>> change. >>>>>>>>> > >>>>>>>>> > Is that OK? >>>>>>>>> As far as possible, the meaning of the objects must be made clear= . >>>>>>>>> That will help implementors and operators- users of the MIB. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I added the definition for one existing bit and reference to the >>>>>>>> IANA >>>>>>>> registry being created for this flag field. >>>>>>>> >>>>>>>>> >>>>>>>>> 8.3 >>>>>>>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>> > Depending on the tunnel type, there could be different sizes. >>>>>>>>> > Future tunnel types could have other sizes that not specified >>>>>>>>> > today. I was thinking to just give a size >>>>>>>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexibl= e. >>>>>>>>> > Is that ok? >>>>>>>>> I see that you have changed the size upper limit to 50. >>>>>>>>> If the size varies continuously from 0 to 50 the above descriptio= n >>>>>>>>> is correct. >>>>>>>>> Please confirm, explain and cite appropriate reference. If the si= ze >>>>>>>>> may change in the future that must be stated too. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I changed to discrete sizes for currently defined tunnel types. >>>>>>>> >>>>>>>>> >>>>>>>>> 8.4 >>>>>>>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>> > > > SYNTAX RowPointer >>>>>>>>> > > > MAX-ACCESS read-only >>>>>>>>> > > > STATUS current >>>>>>>>> > > > DESCRIPTION >>>>>>>>> > > > "If the tunnel has a corresponding interface, >>>>>>>>> > > > this is the row pointer to the ifName table.= " >>>>>>>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>>>>>>> > > > want to say this object points to the correspondin= g >>>>>>>>> > > > row in the ifTable? >>>>>>>>> > >>>>>>>>> > Yes. Fixed. >>>>>>>>> Not quite. >>>>>>>>> What is ifName table ? ifName is a columnar object in the >>>>>>>>> ifXTable. >>>>>>>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding ro= w >>>>>>>>> in >>>>>>>>> the >>>>>>>>> ifXTable table ? Please fix accordingly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You're right. Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> 9. >>>>>>>>> > > > 9. The Security Considerations section does not follow >>>>>>>>> > > > the Security Guidelines for IETF MIB Modules >>>>>>>>> > > > >>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>> > > > Please fix. >>>>>>>>> > >>>>>>>>> > I was really hoping that it would not have to be that >>>>>>>>> > tedious. SNMP/MIB secur >>>>>>>>> ity should be no different from the >>>>>>>>> > CLI security - once you secure the infrastructure >>>>>>>>> > then what's more to do? >>>>>>>>> > >>>>>>>>> > I'll need more time to work on this. Let me try to address >>>>>>>>> > the issues in the other mib first and come back to this. >>>>>>>>> >>>>>>>>> Please take your time. Looking at examples will help. And let me >>>>>>>>> know where I can help. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I will need to work on that later. >>>>>>>> >>>>>>>>> >>>>>>>>> 10.1 >>>>>>>>> > > > 10.1 Checking nits according to >>>>>>>>> > > > http://www.ietf.org/id-info/checklist : >>>>>>>>> > Should I break them into different lines or just keep them >>>>>>>>> > as is? Any example of expected indentation if I break the >>>>>>>>> > lines? >>>>>>>>> No problems at all to break lines. >>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>>>>>>> ::=3D {l2L3VpnMcastConformance 1} >>>>>>>>> Should do. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Done. >>>>>>>> >>>>>>>>> >>>>>>>>> 10.2 >>>>>>>>> > > > 10.2 Checking references for intended status: Proposed >>>>>>>>> Standard >>>>>>>>> > > > =3D=3D Missing Reference: 'RFC 7117' is mentioned on= line >>>>>>>>> 76, >>>>>>>>> > > > but not defined >>>>>>>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and >>>>>>>>> other >>>>>>>>> > I hope I understood and fixed it (removing the space in "RFC >>>>>>>>> 7117"). >>>>>>>>> I would recommend that you put it as [RFC6513], [RFC6514], >>>>>>>>> [RFC7117] >>>>>>>>> That is simpler to parse. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I see some other documents do not have comma between multiple >>>>>>>> references >>>>>>>> so I followed that. >>>>>>>> >>>>>>>>> >>>>>>>>> > > > 11. There is another WIP MVPN-MIB in >>>>>>>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>>>>>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MI= B. >>>>>>>>> > > > Is there a good reason for not merging the 2 >>>>>>>>> documents? >>>>>>>>> > > > I have not seen any discussion or explanation on thi= s. >>>>>>>>> > > > I may have missed it. >>>>>>>>> > > > Please clarify or, give some pointers. >>>>>>>>> > >>>>>>>>> > As mentioned in the introduction: >>>>>>>>> > >>>>>>>>> > this memo describes managed objects common to both VPLS >>>>>>>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>>>>>>> > in the work and both would reference common >>>>>>>>> >>>>>>>>> > objects defined in this MIB. >>>>>>>>> >>>>>>>>> OK. So you are saying that this MIB contains core objects that >>>>>>>>> will be used to manage implementations of various multicast VPN >>>>>>>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>>>>>>> you spell it out at the beginning. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes. I thought I did it already: >>>>>>>> >>>>>>>> 1. Introduction >>>>>>>> >>>>>>>> ... and this memo describes managed objects common to both VPLS >>>>>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Jeffrey >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----------------------------------------------------------------= ----- >>>>>>>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Glenn, >>>>>>>>>> >>>>>>>>>> Thanks for your comments. I've addressed most of your comments i= n >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> new revision: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> URL: >>>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> l2l3-vpn-mcast-mib-03.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Status: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> vpn-mcast-mib/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Htmlized: >>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> mcast-mib-03 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Diff: >>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> vpn-mcast-mib-03 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please see below. >>>>>>>>>> >>>>>>>>>>> 1. Abstract: >>>>>>>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>>>>>>> applications for operations, monitoring and management >>>>>>>>>>> would be good. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I had thought this would be standard/obvious for all MIB objects= - >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> read-write ones are used to control how a device works, and the >>>>>>>>> read-only >>>>>>>>> ones are used for monitoring. Do I really need to say it >>>>>>>>> explicitly? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see RFC 4382 has the following: >>>>>>>>>> >>>>>>>>>> This memo defines a portion of the Management Information Bas= e >>>>>>>>>> (MIB) >>>>>>>>>> for use with network management protocols in the Internet >>>>>>>>>> community. >>>>>>>>>> In particular, it describes managed objects to configure and/= or >>>>>>>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>>>>>>> Networks on a Multiprotocol Label Switching (MPLS) Label >>>>>>>>>> Switching >>>>>>>>>> Router (LSR) supporting this feature. >>>>>>>>>> >>>>>>>>>> Is it enough to say something similar? For example: >>>>>>>>>> >>>>>>>>>> In particular, it describes common managed objects used = to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> configure >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. Introduction >>>>>>>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>>>>>>> appearing for the first time. (PE, VPLS,..) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>>>>>>> terms that are used, nicely with reference to the protocol >>>>>>>>>>> documents will improve readability. >>>>>>>>>>> e.g. >>>>>>>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As the paragraph alluded to, this MIB needs to be understood in >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> general context of L2/L3 multicast VPN and providing good >>>>>>>>> explanation >>>>>>>>> of >>>>>>>>> the terms is not attempted. The references for the terms are the >>>>>>>>> the >>>>>>>>> RFCs >>>>>>>>> for the relevant technologies. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Having said that, I'll explain PMSI a bit further. >>>>>>>>>> >>>>>>>>>>> 2.3 Is there a difference between >>>>>>>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>>>>>>> RFC 7117 and RFC 6513/6514" >>>>>>>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>>>>>>> and >>>>>>>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>>>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>>>>>>> If these are the same, it will be helpful to stick to the >>>>>>>>>>> same expression. If these are not the same, the dictinction >>>>>>>>>>> should be clarified. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>>> out >>>>>>>>>> that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I w= as >>>>>>>>> advised to change it accordingly. Looks like I did not change all >>>>>>>>> the >>>>>>>>> cases. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN= " >>>>>>>>>> so >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll change it back. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3. Summary of MIB Module. >>>>>>>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>>>> structure of the MIB, short descriptions of the table(s) >>>>>>>>>>> including usage of the table(s) for management and/or by >>>>>>>>>>> other MIB(s). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I had that, but have added one sentence about the only table. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> MIB definitions: >>>>>>>>>>> 4. MIB syntax checking: >>>>>>>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I used simpleweb's validation tool but looks like I did not use >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> strictest level of validation. I've now fixed the following issue= s >>>>>>>>> and >>>>>>>>> verified. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> See later question/comments below. >>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: >>>>>>>>>>> current >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this modul= e >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never us= ed >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never >>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is >>>>>>>>> never >>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never us= ed >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is neve= r >>>>>>>>> used >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Removed the above unused imports. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>>>>>>> Wherever possible, provide references for objects used in >>>>>>>>>>> the MIB. The references will point to specific sections/ >>>>>>>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>>>>>>> MIB is being designed. It will greatly improve the readabili= ty >>>>>>>>>>> of the document. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Added. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 6. IMPORTS clause >>>>>>>>>>> MIB modules from which items are imported must be cited and >>>>>>>>>>> included in the normative references. >>>>>>>>>>> The conventional style is >>>>>>>>>>> mplsStdMIB >>>>>>>>>>> FROM MPLS-TC-STD-MIB -- >>>>>>>>>>> [RFC3811] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Added. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic >>>>>>>>>>> errors.) >>>>>>>>>>> 7.1 CONTACT-INFO >>>>>>>>>>> Following the conventions (including indentation style) wil= l >>>>>>>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>>>> Will be good if it does not overflow into the next page. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7.2 REVISION clause: follow the convention recommended in RFC41= 81 >>>>>>>>>>> sec 4.5 >>>>>>>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>>>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>>>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove thi= s >>>>>>>>>>> note: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> 7.3 OID assignment: follow the convention recommended in RFC418= 1 >>>>>>>>>>> sec 4.5 i >>>>>>>>>>> replace >>>>>>>>>>> ::=3D { experimental 99 } -- number to be assigned >>>>>>>>>>> by >>>>>>>>>>> ::=3D { XXX } >>>>>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove >>>>>>>>>>> this >>>>>>>>>>> note >>>>>>>>>>> will be the subtree under which the module will be >>>>>>>>>>> registered. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I kept "experimental 99" so that I could continue to use mib too= ls >>>>>>>>>> to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> validate; but I added notes for the editor to replace them as you >>>>>>>>> indicated. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8. Specific MO and TC related comments. >>>>>>>>>>> L2L3VpnMcastProviderTunnelType ::=3D TEXTUAL-CONVENTION >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>>>>> BGP/MPLS L2 or IP VPN." >>>>>>>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>>>>>>> rsvp-p2mp (1), >>>>>>>>>>> ldp-p2mp (2), >>>>>>>>>>> pim-asm (3), >>>>>>>>>>> pim-ssm (4), >>>>>>>>>>> pim-bidir (5), >>>>>>>>>>> ingress-replication (6), >>>>>>>>>>> ldp-mp2mp (7) >>>>>>>>>>> >>>>>>>>>>> o Would be nice to align the enumeration labels with the >>>>>>>>>>> labels in the protocol document RFC 6514 unless there is >>>>>>>>>>> a good reason for not doing so. (You will have to take >>>>>>>>>>> care of the smi compilation errors too; '-' is not allowe= d >>>>>>>>>>> ). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>>> replace >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> with things like rsvpP2mp. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Or could/should I just remove the definitions, so that if a new >>>>>>>>>> type >>>>>>>>>> is >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> defined in the future there is no need to update the MIB? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "An entry in this table corresponds to an PMSI >>>>>>>>>>> attribute >>>>>>>>>>> that is advertised/received on this router. >>>>>>>>>>> For BGP-based signaling (for I-PMSI via >>>>>>>>>>> auto-discovery >>>>>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>>>>> they are just as signaled by BGP (RFC 6514 sectio= n >>>>>>>>>>> 5, >>>>>>>>>>> 'PMSI Tunnel attribute'). >>>>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>>>> they're derived from S-PMSI Join Message >>>>>>>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>>>>>>> >>>>>>>>>>> Note that BGP-based signaling may be used for >>>>>>>>>>> PIM-MVPN as well." >>>>>>>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>>>>>>> o Please give the reference for this Table. >>>>>>>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>>>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>>>>>>> both? >>>>>>>>>>> Any other pointers? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this >>>>>>>>>>> is >>>>>>>>>>> 0. >>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Fla= gs >>>>>>>>>>> field in PMSI Tunnel Attribute of the correspondi= ng >>>>>>>>>>> I/S-PMSI A-D route." >>>>>>>>>>> ::=3D { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>>>>>>> o Please confirm that the above is a complete enumeration = of >>>>>>>>>>> the >>>>>>>>>>> types of signalling. >>>>>>>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>>>>>>> "Leaf Information Required". That is useful information. >>>>>>>>>>> Please include in the description. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The intent is to simply return the octet value of the flags fiel= d, >>>>>>>>>> w/o >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> listing individual bits like "Leaf Information Required". More bi= ts >>>>>>>>> could >>>>>>>>> be defined in the future but the MIB would not change. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is that OK? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the >>>>>>>>>>> first >>>>>>>>>>> four or sixteen octets of this attribute are fill= ed >>>>>>>>>>> with >>>>>>>>>>> the provider tunnel group address (IPv4 or IPv6).= . >>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the >>>>>>>>>>> Tunnel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Identifier >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Field in PMSI Tunnel Attribute of the correspondi= ng >>>>>>>>>>> I/S- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> PMSI >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A-D route." >>>>>>>>>>> o Check the size specifications. The specs above say it can >>>>>>>>>>> be >>>>>>>>>>> all sizes 0..37. That is not clear from the DESCRIPTION >>>>>>>>>>> clause. >>>>>>>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>>>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Identifiers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress >>>>>>>>>>> Replication,MP2MP. >>>>>>>>>>> It appears that the sizes (range) for each case will be >>>>>>>>>>> different. >>>>>>>>>>> Please clarify that, and if there are discrete sizes, >>>>>>>>>>> specify >>>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Depending on the tunnel type, there could be different sizes. >>>>>>>>>> Future >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> tunnel types could have other sizes that not specified today. I w= as >>>>>>>>> thinking to just give a size range so that it is flexible. Is tha= t >>>>>>>>> ok? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "If the tunnel exists in some MIB table, this is th= e >>>>>>>>>>> row pointer to it." >>>>>>>>>>> o "some MIB table" : specify which MIB table. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could >>>>>>>>>> be >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> whatever table that a tunnel may be put into. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> o In what case will the tunnel exist and in what case will = it >>>>>>>>>>> not? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If a device supports mplsTunnelTable and the tunnel is represent= ed >>>>>>>>>> there, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> then it exists. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> o What will be the behaviour if the above condition is not >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> satisfied? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A null pointer should be given. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "If the tunnel has a corresponding interface, this = is >>>>>>>>>>> the >>>>>>>>>>> row pointer to the ifName table." >>>>>>>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want = to >>>>>>>>>>> say >>>>>>>>>>> this object points to the corresponding row in the >>>>>>>>>>> ifTable? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes. Fixed. >>>>>>>>>> >>>>>>>>>>> o In what case does the TunnelIf exist and in what case wi= ll >>>>>>>>>>> it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> not? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Some tunnels may not have a corresponding interface. >>>>>>>>>> >>>>>>>>>>> o What will be expected if the tunnel does not have a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> corresponding >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> interface? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Null row pointer. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9. The Security Considerations section does not follow the >>>>>>>>>>> Security >>>>>>>>>>> Guidelines for IETF MIB Modules >>>>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>>>> Please fix. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I was really hoping that it would not have to be that tedious. >>>>>>>>>> SNMP/MIB >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> security should be no different from the CLI security - once you >>>>>>>>> secure >>>>>>>>> the infrastructure then what's more to do? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll need more time to work on this. Let me try to address the >>>>>>>>>> issues >>>>>>>>>> in >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> the other mib first and come back to this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 10.ID-nits >>>>>>>>>>> 10.1 Checking nits according to >>>>>>>>>>> http://www.ietf.org/id-info/checklist >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------= --- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** There are 4 instances of too long lines in the document= , >>>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> longest one >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> being 3 characters in excess of 72. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I fixed some but there still three too long lines: >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>>>>>>> L2L3VpnMcastProviderTunnelType, >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::=3D >>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::=3D >>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> S > > ... > > [=E3=82=AF=E3=83=AA=E3=83=83=E3=83=97=E3=81=97=E3=81=9F=E3=83=A1=E3=83=83= =E3=82=BB=E3=83=BC=E3=82=B8] From nobody Thu Apr 13 11:04:27 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB02A12EB0B; Thu, 13 Apr 2017 11:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTAh8npLPzyD; Thu, 13 Apr 2017 11:04:17 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0112.outbound.protection.outlook.com [104.47.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BCB12EAF6; Thu, 13 Apr 2017 11:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BVg/YX3DvG8vyzu6q4k8nEF8av1gTmo83yXw6hkY55U=; b=MW7GgMl4gXStyvzJ0xFyp1Yrye609ONOlDlQSqY28hpmoQjIXtXZ8F1QuwmWScra3Qwg4WMSjGRYtfAdTj69dxCQIBTxIC7eHHOGu095pptSAZ7TxCw+EAtswvGA7f8CGibrzmLUAYbCVsTdrJnbYTrYN4yzW6sqLI+U77WQWV0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; Received: from [192.168.0.22] (88.182.48.47) by AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 13 Apr 2017 18:04:13 +0000 To: BESS CC: Reply-To: BESS From: Martin Vigoureux Message-ID: Date: Thu, 13 Apr 2017 20:04:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [88.182.48.47] X-ClientProxiedBy: VI1PR07CA0190.eurprd07.prod.outlook.com (10.166.77.142) To AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) X-MS-Office365-Filtering-Correlation-Id: cc9621ff-8263-43d9-6d56-08d482977e8b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2468; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 3:6UvFtvzPkA9dR9UgJMoMCnqcCu5bbsdoQaUJzme0/bFHtxCx9n59eSXm5Z6JBclRRtut8hHtMAUvVoo+juvQBekEK2TMUZS6p1mxN3Uz5HxM4ZLToEcH0M1fMRHl3ukUPsf3jO1xh8PYxnRtmjubq7Yt8hhRwurpBjXxPnvuktT6lapjVk3cUbTAsqRTjXITQuq3w5yDvvWNCRW8i1wVRUBgPhSxfSuy7KzFdNGH+92Rf2H7LgthhxOsWjPJ1MYBF0zuxEg6O66EzUvUFWQCQxb/Yr4Oa2/1pv2EpcOfH2l0a0vF/KcWmz2M9G18cY1EL8yFvmliMGtFT/iptitZrPjaKFbANuVt9JBk8b+R8jw=; 25:zeGb66SPxLxvxjtoPahR9mzmIyL1000AElm/ZQVXFFyZuvfbVqa/Z9Z9spkfOfu5cB+V0t/+0JR/nS9MwhabqUICU1kD+p8Nq9eTuCsuiZW3M7H6ncBzQBxq6v6PupW7lxuWuhA7qGlhAMwD04Xicpw7nPu5qBMVhfMZARhAgdOIaPMqu1uo96YtunPgjnen/2k+W/ajrPRIoUdKGKnMz688dwJHOXezCJKajPTASbauBqTEawatxQzWfNE41+yLSBsUcfEawNlhU/B7n8vLNbr2IOIa347SgzLCYtG0q9hL7dHobsKU8wf3TQYCYGN5VC0ZdSbZGvxAYV0dTO2DVc1B/InMu5N2dqxOaWeEwZQ3ITty2ywXNZ9dTpwsjR5fjyAejUfaOh06cuJ2tak/BFr2itgDG59cygH9uxRnWn2ApNMB2grIVI6qmd+2yEXT3ru/0ojPLK78dyrHZkF9t9ETi69Ef7PqQfBSQsucZSU= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 31:hnCLBFbXB/T+0MLXM3qH25DIgPPXUpCGu68iUO0PxUZwP/xsvpk4H6sFMcYWzAYMS4jw7KPhaH8BIDtMjisrMcISCRjU7tIGoni/YU+sLJ6iFn37Cw7hRBnGTPE0iFQtTTAJ69j/MIIKOvvwKA/IZXFRtjEI6MBETNc71NcgDGslEw8pDnVlkAVKks1G3BA/jWw5WsHKwRftV0hpNmHM4UqsOwtJveqrtcgn9gx7rXN/rJE2Y/YMZ5e0EnG9pYmDIolESizJ0ark/pSUmSX06U8/HL6h6YueFqI22eOVCYs=; 20:+QaPtsu3qkda9NFRRUZTCdEupnhpvUQLsTydm/kOR4Is8jTscwn3T2GZq7767Xvlxomt4uqZ9RqBrdopaBgbFVWQ1uh4KmCN69RJAMlLPeRJ9n5kOWtfrGKTUamhzxqSvppa5Z+w1+gtNOvjmSFQdCzedIIejy1c5NFCufct/QNGDjp7ngLCYV7AKwyY338aiZF9D5WZmNV77bHN7+aeUzU6O3UtN0IOr/914TyHVPfvVe2v48pH7NNmBikd2ppV7oqFsQnSYcS57KqKWZbS0xPYwiXVGq9AdyXwEgdyiFz4l/HoXOsLwZ1JBKXam1mfVjQXJPS3pTOkDz51IK2RRLjpzbiUPqiHDJHyoK6S0Wz/XNSzxvEnp3BQUDaw6/4PZdK0wxj7Lqpl7VKL4j2AFFrviRxMuhaVijaVxU7qVdGVuicP1i5PH5L99sb4dV2rAnKb4LfNPU8cUmXsrq809Wr9yqPJAkbE+AuXPgwfTXGMO/61WPiGErDlrfIYyUne X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2468; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 4:D8asxXoXpyNjoGdil4D1uBJX1jn3wvNh1VkmLY6VJxPg2ID/Qs1R3yOEsEasdvg7COQBH2nB8zKBKMJLVXDmGF6Tcf8hgHD1RVKGzhstw93yUwP6UhTUisoes6/n59ZOX5CgvNyZFyXiEQnENvM71/wSaoyS11ppqQaPN3WqXMQcfXzWqDmeYwCMQEwYV2pBZCg8UqhdL8O2vhoNVWN6NIRnlWtBlB/BGyzO/OK+b/TpO4KcUaHbjY8TfN8cNx7c+SrlHXe0Txu99RNwVNhwVxGBlQ/nz2/PiZdB8f1smbJjomNmVz8J19eTxLAke1wATD6Qi46z0suhLQQCMLQXDrFOiYR0FeCCo3LdHyXucVjqtIEDP2PDBza49IsSioeSWIx+GNjmMc3VyhQbEsPfz3bml6D/BUhKqCWT8vtq/2KS7vSZTbBAC3AWOvewmpnnvA06Eaylt8XCShtcQyxjQifXqkWtBUc8+ifw7y4Szrxbd2Hay9T11FXr+WZviJDoWGTQd15nZF2BAp6QibnyU9CCPfXSqcSkMP4VYq5M5JtKlp903wMJfiulDypykx4JbkM15dfB6aaCY8dVHLwoztYTapoxJ5cRI3Dmc3oyrAnoHJdH5bd1z4x7iJKoIcrG8QE37t3fqkYo4zmlxcHYmbt9E7hQZYLhHtKMfrMSUBYjFEYS1mBwpiJ5a2sdDRKe8q5IQt/FgzfTcTWXRH9uuP3e8AkQscnydA9bbl6+E0ij7nBjHsKCWdx7QcORX/7SUyRF2tTCaurcQOgIDWwohg== X-Forefront-PRVS: 02760F0D1C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39860400002)(39450400003)(39410400002)(39840400002)(39850400002)(43066003)(4001350100001)(189998001)(6916009)(23676002)(36756003)(31696002)(50466002)(450100002)(117156002)(86362001)(53936002)(47776003)(230783001)(6306002)(25786009)(110136004)(38730400002)(4326008)(66066001)(65956001)(6486002)(7736002)(65826007)(6116002)(305945005)(50986999)(33646002)(90366009)(5660300001)(64126003)(31686004)(42186005)(81166006)(8676002)(230700001)(77096006)(54356999)(3846002)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2468; H:[192.168.0.22]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI0Njg7MjM6OTlpTVJOanhKSFRpY0Y2M25KMmpCV1M5?= =?utf-8?B?dUlCdHExUlRiak9USXJhK1JjN01vNkZzZ1Y0QVoyWmhXeXgwQ3VjcTg0RFVH?= =?utf-8?B?RVdDeFkyWVhIaDFZVnRSNFEvWk05RUtUSy9aSExqTjZRemtHbTl3ZjR2c2o3?= =?utf-8?B?N2pBRlNYRFRwbnBWRGZ0bFBsZXpOUHhZOXUwUitKclRwZDFWRXJJTW9SR0pa?= =?utf-8?B?Um0rNmlHWUZPaGdGTWxSbER2ZHVWYWc2MlNDaFlxQnFYeDdwM2pxK0h3cjVB?= =?utf-8?B?UmJOVktER0NLb0dhY2M2Z3B6TU1wQ2ZOam8rajY4T1pJNGFSM0tuTmc2TkZG?= =?utf-8?B?THF0NzRlbkJLYXhIQkRvZUIyQjBUS2VSNFBIdkYxWDMyWk5WZ3RtUWJxVFF0?= =?utf-8?B?aWV3ZXdCMnBFTUp4R0ZkbEdtWEhCSldRWnR3a01yMEExRmt2NE5SM01vUnBu?= =?utf-8?B?R3BkV21LbGJHZnRLSlVLbDBwSVdUNXpHYlFFZS85UXVua1U1YnpGOFB4VFFh?= =?utf-8?B?RnlmdGZIS2hFVm9EQTJiVU5rN1gyQVBhYjZtRVZid1VFMGJRRWpraHVDdVNY?= =?utf-8?B?RzRlWlVDZldGVnY0dkdrUjVzak5ZYWtQSWJ3R3hiWHEzOHFIU0UxSmF5WXhm?= =?utf-8?B?NDVYR3NWbitwU0NhM01BdTdCakowMHJxR3Rkd1cxMGtzdnFTSkJoaUc4V25G?= =?utf-8?B?a3QwTlFlQm02WG9ObXA1djNPSGJtRDlUK0hKNmsvWWxGMGs1aERqQWREK0tz?= =?utf-8?B?UFhKa2NDblVJZ3pGdTk0cEdRT05jWkxtRm9xT1RlMHcrcTFZUE43N1ZkVUZO?= =?utf-8?B?aVdsSjNYK2JIN29sVmwrK3J5SmIyWkQ4Kzk2dzVuUEs1WnNtSnJSeFE5eTky?= =?utf-8?B?dWZJbjloYTV5RmE2Z3JTRzhJUElmd2hzbTBBNXVoWjgrNk4ydmpSY3lweitJ?= =?utf-8?B?N1YzMHgyVkFhMmlVL3g4NEVwTTV6OWpNSytZSUxieGtwOHhBL3g0blduSW1P?= =?utf-8?B?eEVabGlpRjVDNUVJWkxvbnBtaWdWcDBVQno4OFlnd051RGZKNE5BUHBqK3RK?= =?utf-8?B?MTI3TUp2bSt1QUhDRkxVSVJlNGtEa0kzZGk4dmRROGJkWVlWVkRRck5pUnlj?= =?utf-8?B?elRGcGJ0MHo2UlNIWURtZUc2ZXNKcmE2ajlTZDlmY0dRamlSbmszczdQaE5W?= =?utf-8?B?cTdYd09MdFBZYy9ySHZVY2pqOFROdVFxZlVmNlZ1cUFGNzd5N3FEcnRxNVBj?= =?utf-8?B?d1N2d05BbUh2Z0ZRWGRGd0lwM2NRNFJOdW5nYVE1NEMxcTNnMlB0L1ZCc1NR?= =?utf-8?B?WE53emJzZ0hJakdyNlhXRStEeXk5SWdlZ2ZzdGhMYW15ZHMyQzIzNW9MTk5x?= =?utf-8?B?ZkhFYUdWSWJNVzVaUzFRaFYrcEh0U2Fab1ZYemFIckJvRy9yait0THczdXNo?= =?utf-8?B?emhRTVhiQktIOG1aSnlmWElHQnAyNWw5WUczMmxkUm5pOGQyTXRjL21DTHYy?= =?utf-8?B?TGJZQVZpRU5kVjhWdXFUOGw4TldIYzJaZjd6NjZ1K05Bb0pxc2xHck9vRFZP?= =?utf-8?B?akRpYnlYLzN0KzYzd0syTWVVdFZwN2tMNTdtaGsydHpZYkVIQTZwS1BhTmJY?= =?utf-8?Q?vR+0ubHCteph8hKQAaKwQw?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 6:4tK0Th9yf6uneLkIGsLGspMejKdCYly4HyensDqG5FX18IqWEXjcIRDRQWYHs1iZSvvgE8W073hC/WlExgtSRed4Bu/rf29Ye2UTTBNxxt7PbfpsK6Fnk2O8IriBRbJZNlmw40priu6NvN/yPFa07X0D6xOUAgdyapLFHYsXKc8Dievo1kTgZF7azaJgd1Adh+j8QwOlm9l15yUsGxh17lFuZHDCvAsFPYPyzir3fiia1ZISnlRUShG3JvLHgPEWXFNUyDtMG7D8A3os1nMoDuVjm0gLsC4wN6NPaO+GcrBw8HvcreZdVOGHW4zOmY31oUmqX1Ra0DLLKS1918x+NybndMSE4pyW4/r5cpqGD4WCVLp/bTUPkteBXJOzxGSm+IOrZvQaNrUD1tLg2DmYgIhdVcPhvypYVoOr2AF8fl6TfNopzTygnHHWyudbA9OUt+B+OhUFFU6fOpIcu97MADH27rbafOLOnc2yusSO358=; 5:D++WRa1Hll6WyjAcVmisBS1Kh4ys3aD0WQkeXQilkwHiYa5cG8oifHW6Xe5y3D0uWQzSoyh1zJ7IQ1kQXUgWwmtLrr2p6quGnGyPV3DeqDKLbv9k+BsPxnLBXwn2JJYviwgZxF95fWJgflnqMo+Uog==; 24:BzD5n0FLocNWgx5JBbQeXmVGw5lWcgX3KfrtrUcvhfwerb288UgL8b+5pGtIpo5yn95fHBsUgzbwHZ5ybpwjc+eBPviOad/1MksXs/87j2I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 7:U1lqDUKV2GvWqGAo3pKLdkWMwusPUpE2WTD7WH/13WpI8aQ5KDEZAj5q1047zsqcjWCBWi+G2KQpZJUVxr5/8HWBn2RlPiLiEGHTHLrwFuMCfisRQKyCWFuOUTt9LWw5bDOcWpbS3hjWn1ZPQERJjZo8uh7BGQ0Fhj/y1QW26GzgKoOVCtLczQDeh+D6eb6HpowKK+qz0Ek4U4feLs6vEwsbaJDFcckZVyXecYie+bqc3GBtL3dWs8WlwfNRrNZna430qUpVucq6nPla+w6GNxv3NW2C5sV+dEj6Q+ST300GGm4MofmwAgXYCf/MsPomZ9xXkZo9qr/OGwsiXlSYjg== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2017 18:04:13.7669 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468 Archived-At: Subject: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 18:04:19 -0000 WG Given the IPR disclosed [1] against draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for comment specifically to let people express a revised opinion on how draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS. This call for comment is open until the 5th of May Thanks M&T [1] https://datatracker.ietf.org/ipr/2980/ From nobody Thu Apr 13 12:03:52 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1B12956C; Thu, 13 Apr 2017 12:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7lJzT3kRAXD; Thu, 13 Apr 2017 12:03:42 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0122.outbound.protection.outlook.com [104.47.37.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A6312EB24; Thu, 13 Apr 2017 12:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1bRjLOMFnTAAeMA93q4OqeFyWFoJcvUX/fB0jA285HY=; b=DUKTaI3TGyWFwk9BzNJPEN4NQQkd4SA+Sh3MIl4YCW8lN95hpcH1qaSUkbZAcsUErhxNCwxxNvHuDPUUVMJdeo5Zo3VgVgq3rvz2byqi36U9G1LJJwZ/BUXx+S7omUxUBcD46CretODnAxw61v75uzFAxo28okzh3u8HBxfMJj4= Received: from CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) by CO2PR05MB620.namprd05.prod.outlook.com (10.141.198.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 13 Apr 2017 19:03:41 +0000 Received: from CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) by CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) with mapi id 15.01.1047.006; Thu, 13 Apr 2017 19:03:41 +0000 From: John E Drake To: BESS CC: "sfc@ietf.org" Thread-Topic: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure Thread-Index: AQHStIBizWROpzavekSV7f1EGZ67jKHDp4LQ Date: Thu, 13 Apr 2017 19:03:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; CO2PR05MB620; 7:hcc2NdSMatIq/h9thhhgm3g+uy54ppnj3gX4PY7PJxOJaxFQTE6Gc7yxQ9Jg8USmOaeSbKwkzpKWu3vHTRe749PaB/TZBYr0ckZEl9I/Mw/X90XfBI+IQinzhdP3QdbUMsKCZ5kOpEQhtgJFSZ3Dwv1dioqCwCZN3qPp8nUJltz0g0c9rcdHGfkCUbx2c3PNI4MtE3AEQxaYUcOvgD1g3X78vuEQ2ED8KTYYCEomM/tClmeoKXZMGCSKVCtPA+rqPinL/BVXITSz47+ra4h1Y95dRGWKrlg7+iXWB5sYA03hPtb5zVtrH7KAGnxLSKVqCDcqULTSQf9hTrfpB6pCvw== x-ms-office365-filtering-correlation-id: c68bfefd-619a-4d2a-1f6c-08d4829fccc1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO2PR05MB620; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(6072148); SRVR:CO2PR05MB620; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB620; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39410400002)(39400400002)(39840400002)(39450400003)(13464003)(377454003)(305945005)(6246003)(53936002)(450100002)(77096006)(86362001)(25786009)(122556002)(54356999)(4326008)(50986999)(7736002)(229853002)(76176999)(2950100002)(230783001)(66066001)(2900100001)(6916009)(74316002)(189998001)(53546009)(55016002)(8936002)(99286003)(2906002)(38730400002)(110136004)(9686003)(3280700002)(5660300001)(6306002)(3660700001)(6506006)(6436002)(102836003)(6116002)(3846002)(7696004)(8676002)(81166006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB620; H:CO2PR05MB618.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2017 19:03:41.1295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB620 Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:03:44 -0000 M&T, I still support the adoption. I looked at the subject patent and it appear= s to have very little to do with draft-mackie. I think this means that the= IPR assertion would be similarly made against *any* solution developed by = BESS. Yours Irrespectively, John > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Thursday, April 13, 2017 2:04 PM > To: BESS > Cc: sfc@ietf.org > Subject: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control= -plane > adoption following the IPR disclosure >=20 > WG >=20 > Given the IPR disclosed [1] against > draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for comme= nt > specifically to let people express a revised opinion on how draft-ietf-be= ss-nsh- > bgp-control-plane should be pursued in BESS. >=20 > This call for comment is open until the 5th of May >=20 > Thanks > M&T >=20 > [1] https://datatracker.ietf.org/ipr/2980/ >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Apr 14 09:27:29 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6C21294E1 for ; Fri, 14 Apr 2017 09:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqrPz9Zwpzuq for ; Fri, 14 Apr 2017 09:27:25 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0055.outbound.protection.outlook.com [104.47.33.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E35D126BF0 for ; Fri, 14 Apr 2017 09:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=47Il7Jaf3Iz9MP8rlqtlh8KvOU5tBDTFszqX4U5ASE0=; b=qnngjJPTg5O86WVNM9xG9Ygon2fs0mnIntrgniVbhf2+EPxZc1HJhkRZIW4f2yaTRYzy9VH2UgfAUxAm7FPx7unmpxUHEpQvmaMERYu3E9xJNfB/12aSbDwvvTtXTdHU02mLuvuotjdQN+8G1a/UG9LfCxThRKt4lmpMf8ePQMA= Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3011.namprd05.prod.outlook.com (10.173.19.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 14 Apr 2017 16:27:21 +0000 Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.1047.006; Fri, 14 Apr 2017 16:27:21 +0000 From: Sami Boutros To: Thomas Morin CC: "Ali Sajassi (sajassi)" , John E Drake , "Sami Boutros (via Google Docs)" , "bess@ietf.org" Thread-Topic: WG adoption for draft-boutros-bess-vxlan-evpn-02.txt Thread-Index: AQHStTv9GbqsIm5vA0CWTtI9M2thlQ== Date: Fri, 14 Apr 2017 16:27:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [50.131.13.252] x-microsoft-exchange-diagnostics: 1; BN6PR05MB3011; 7:sx9acTx08zZcRgXEU3MIUhKNyzvq2yg87Z70u/kSVR/skJSYbmOfA2murWobC170DmWlioAeNHk6Mf6jGaokyWxCUHRHcLN1bUt5n7vtdgO+z6a6WlZyDEtTD7Nf9j5GUPEaYZyn+MR+JirnTl1y3P+l20TLF0fXwaySytEOkUUENGqkzisxCnlc50H1ndL4vxeZWiK85qR50RXDJIf04EO7YX1kNpmFmQfYA6o9Nq2zDX+uUTzf9w1QhgKz/fAY54uJjJezS/gSbpoXMSEYAXfgJ/1cyo1kTrWSsLzDF2hRzKB3uOUQEW6FEL76LY7Exs33vlseyMjtbi78KAdN5g==; 20:MH4Ifti0PKLf+Jwp0NTg7iSt9IrtoGIvxvzxxUqGX+hLoainUY7jZcLMSyYAPwmtxmeSsykrNZxtMq292vMbYeNHMgqFqYwShR6u9iiZQQtVUbM+ogOVhG3snAzKwDf6u8fi1XouaLF+bug1fqj0xvIO0VxiU6eiYXlgdV6nnyM= x-ms-office365-filtering-correlation-id: 46308445-125b-48d0-71b1-08d4835320a3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR05MB3011; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR05MB3011; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB3011; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39860400002)(39400400002)(39850400002)(39450400003)(39410400002)(82746002)(5660300001)(99286003)(54906002)(3846002)(6436002)(54896002)(77096006)(6486002)(36756003)(6116002)(102836003)(8666007)(83716003)(7736002)(33656002)(86362001)(122556002)(2900100001)(50986999)(54356999)(53936002)(6916009)(81166006)(229853002)(8676002)(39060400002)(66066001)(4326008)(558084003)(2906002)(230783001)(8936002)(3280700002)(6512007)(25786009)(6246003)(189998001)(3660700001)(110136004)(38730400002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3011; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5DFB63444348F183E7DB5FD1162A6Cvmwarecom_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2017 16:27:21.8118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3011 Archived-At: Subject: Re: [bess] WG adoption for draft-boutros-bess-vxlan-evpn-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:27:27 -0000 --_000_DB5DFB63444348F183E7DB5FD1162A6Cvmwarecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGhvbWFzLA0KDQpDYW4gd2UgcGxlYXNlIGFzayBmb3IgYSBXRyBhZG9wdGlvbiBmb3IgdGhl IGFib3ZlIGRyYWZ0Pw0KDQpUaGFua3MsDQoNClNhbWkNCg== --_000_DB5DFB63444348F183E7DB5FD1162A6Cvmwarecom_ Content-Type: text/html; charset="utf-8" Content-ID: <1FA5CAECD58C434F9C0256A3CA152C90@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIFRob21hcyw8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2FuIHdlIHBsZWFzZSBhc2sgZm9yIGEgV0cgYWRvcHRp b24gZm9yIHRoZSBhYm92ZSBkcmFmdD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRo YW5rcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNhbWk8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGlkPSIiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvc3Bhbj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB5DFB63444348F183E7DB5FD1162A6Cvmwarecom_-- From nobody Fri Apr 14 09:43:04 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0BE129421; Fri, 14 Apr 2017 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuQQUWX2e1xi; Fri, 14 Apr 2017 09:42:59 -0700 (PDT) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AFF128B8E; Fri, 14 Apr 2017 09:42:59 -0700 (PDT) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 0346C60078; Fri, 14 Apr 2017 16:42:59 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 707E46005A; Fri, 14 Apr 2017 16:42:58 +0000 (UTC) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0015.outbound.protection.outlook.com [216.32.180.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx2-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 4873D60062; Fri, 14 Apr 2017 16:42:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=coEsBthsiZHzOqwf7LzLzn1i7k7/P0KNvpyQdl4jTe4=; b=N3hUKbS9ID3oUKHohg2wFuZCywhXYgitS1KO4tXn3upXp9cv32PVBEpbpTxIew6iSG/KkhXsCIa8sXAv2Tdgsfi3rJ7RyMsRZkk3WBloOBSKWSpBGC12KEoKUbBTXC0l9Vdkv93BzKkh6ukhMKQ/Xn2JzcAPMTH/vCl0Zg9LiQ4= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 14 Apr 2017 16:42:53 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.1034.013; Fri, 14 Apr 2017 16:42:53 +0000 From: Keyur Patel To: John E Drake , BESS CC: "sfc@ietf.org" Thread-Topic: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure Thread-Index: AQHStIBoTpcAU7/6x06W+mRrGKG62qHDqFOAgAD1pAA= Date: Fri, 14 Apr 2017 16:42:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [96.68.143.133] x-microsoft-exchange-diagnostics: 1; BY2PR18MB0262; 7:Aovkwn6sBBlyexC48kHrAzkWQS3wyDAgBLlNMM4pzFAd0utGHdJoWxokoA1scMPMMEUF4BrK0hxd7Ylbty+vGt285RZtWsrl1tHmh2ep3RBtb+cPYjd8m3QRXL1LoUy+MMuN+38uHe1oMbxFZdGf5bd81ISA/D5/xnw03DDdVzH26sHl+PlF9XkNOwJEr+t13CiCx+MjQTzs/zodDqDxkOja0X6u/IHrXlAobDa8Cab2pEfaWFwNnsv6+WNnP68lQj2coA6cpleM3NXareqz3w+56OZO9laR4U8pwSBTSrXwp6OnY6EWzVrMEWWAWyXUjnAwkmiWedJ5j8M90Zft1g== x-ms-office365-filtering-correlation-id: 63c911c0-6695-4258-47d4-08d483554c2f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075); SRVR:BY2PR18MB0262; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(2016111802025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6043046)(6072148); SRVR:BY2PR18MB0262; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0262; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39830400002)(39400400002)(13464003)(24454002)(377454003)(2906002)(5660300001)(83716003)(6246003)(53936002)(33656002)(3660700001)(229853002)(3280700002)(8676002)(86362001)(81166006)(8936002)(230783001)(66066001)(122556002)(2950100002)(189998001)(6512007)(6306002)(25786009)(53546009)(7736002)(305945005)(6486002)(77096006)(8666007)(2900100001)(6436002)(6506006)(99286003)(38730400002)(36756003)(4326008)(3846002)(6116002)(102836003)(50986999)(82746002)(76176999)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0262; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2017 16:42:53.8458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0262 X-MDID: 1492188178-7eGUeczLpWAO Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:43:03 -0000 QWdyZWUgd2l0aCBKb2huLiBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uLg0KDQpPbiA0LzEzLzE3LCAx MjowMyBQTSwgInNmYyBvbiBiZWhhbGYgb2YgSm9obiBFIERyYWtlIiA8c2ZjLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGpkcmFrZUBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCiAgICBNJlQs DQogICAgDQogICAgSSBzdGlsbCBzdXBwb3J0IHRoZSBhZG9wdGlvbi4gIEkgbG9va2VkIGF0IHRo ZSBzdWJqZWN0IHBhdGVudCBhbmQgaXQgYXBwZWFycyB0byBoYXZlIHZlcnkgbGl0dGxlIHRvIGRv IHdpdGggZHJhZnQtbWFja2llLiAgSSB0aGluayB0aGlzIG1lYW5zIHRoYXQgdGhlIElQUiBhc3Nl cnRpb24gd291bGQgYmUgc2ltaWxhcmx5IG1hZGUgYWdhaW5zdCAqYW55KiBzb2x1dGlvbiBkZXZl bG9wZWQgYnkgQkVTUy4NCiAgICANCiAgICBZb3VycyBJcnJlc3BlY3RpdmVseSwNCiAgICANCiAg ICBKb2huDQogICAgDQogICAgDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAg ID4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN YXJ0aW4gVmlnb3VyZXV4DQogICAgPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTMsIDIwMTcgMjow NCBQTQ0KICAgID4gVG86IEJFU1MgPGJlc3NAaWV0Zi5vcmc+DQogICAgPiBDYzogc2ZjQGlldGYu b3JnDQogICAgPiBTdWJqZWN0OiBbc2ZjXSBFeHRyYSB0aW1lIHRvIHJlZmxlY3Qgb24gZHJhZnQt bWFja2llLWJlc3MtbnNoLWJncC1jb250cm9sLXBsYW5lDQogICAgPiBhZG9wdGlvbiBmb2xsb3dp bmcgdGhlIElQUiBkaXNjbG9zdXJlDQogICAgPiANCiAgICA+IFdHDQogICAgPiANCiAgICA+IEdp dmVuIHRoZSBJUFIgZGlzY2xvc2VkIFsxXSBhZ2FpbnN0DQogICAgPiBkcmFmdC1tYWNraWUtYmVz cy1uc2gtYmdwLWNvbnRyb2wtcGxhbmUsIHdlIGFyZSBzdGFydGluZyBhIGNhbGwgZm9yIGNvbW1l bnQNCiAgICA+IHNwZWNpZmljYWxseSB0byBsZXQgcGVvcGxlIGV4cHJlc3MgYSByZXZpc2VkIG9w aW5pb24gb24gaG93IGRyYWZ0LWlldGYtYmVzcy1uc2gtDQogICAgPiBiZ3AtY29udHJvbC1wbGFu ZSBzaG91bGQgYmUgcHVyc3VlZCBpbiBCRVNTLg0KICAgID4gDQogICAgPiBUaGlzIGNhbGwgZm9y IGNvbW1lbnQgaXMgb3BlbiB1bnRpbCB0aGUgNXRoIG9mIE1heQ0KICAgID4gDQogICAgPiBUaGFu a3MNCiAgICA+IE0mVA0KICAgID4gDQogICAgPiBbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9pcHIvMjk4MC8NCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICA+IHNmYyBtYWlsaW5nIGxpc3QNCiAgICA+IHNmY0Bp ZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN CiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgIHNmYyBtYWlsaW5nIGxpc3QNCiAgICBzZmNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KICAgIA0KDQo= From nobody Fri Apr 14 09:45:24 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F311294DF; Fri, 14 Apr 2017 09:45:22 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56mv0ntRkMkz; Fri, 14 Apr 2017 09:45:18 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C54129449; Fri, 14 Apr 2017 09:45:18 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id c198so42655983pfc.1; Fri, 14 Apr 2017 09:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :cc:to; bh=YKSkvfMezTQLfOQZxfJ2hNZuFF9mPAPFTjkutqV2RVU=; b=gxFOBqOlqLEXygOaFiA98q/k1lLHbJQtnZm9fSuKuzVuToL7v9Ms4SCIKMVZGp7bqp XIRNsOWSxXOnMs20DwjNQ5kyOfLZw1s1tWkZWBoEzg+FGyaMZ18uMu4lpJXaNnCD2Awf J688Kr9LpridZna3Z/H4JAB/FLeqtkxzN5LOqzw6lnWyr6clVHd1U0EV/f15dX1k6vSe gS3P2G9DFtKWGDRg1UzB6LafU6zzw39DbOAMvh2xBf+2HpuOgdMCgy/0uKtIrZ+Ar2Lj K0MdefVuptO7sPSTjXDkWwX9EOpbMAiP4RL1R53tT0C748jCjzi+ROW0Fc+VHjRbWgac xc7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:cc:to; bh=YKSkvfMezTQLfOQZxfJ2hNZuFF9mPAPFTjkutqV2RVU=; b=RxKUhpgIFNjfJ9nSMrcW1d34ZMcF/vSRAIPu7ToReo5ZtXDrGKfLC4k59q/aAFq6Hg W3lGldyORoKY5/Vzp8CSkbkXS6XXra5tIMe258Hc2CzUQSBJDOPLs7ktPtOHhHkqEImp TPf7Sn7mqUr9M/+6HsQ0dPFyiT+povHRXy8V27SBvg2lgKVKk/0V1qnLSugA/JUf2jhw q+b47krXJMoNVn2yJuf4aES+mXijJgzEBrrD0/iR9MlcauN6G/RK8mUuV2njtDpfoihU 0WsEZhBE+8r7FxWnKLnXPFaRDTGD9DS5xb3UFEP2qZjCb6+ES7E1hy1Kv9Ll+1BYGZbl HUeQ== X-Gm-Message-State: AN3rC/6WMD9UTJ0xaoNFDhJO0lrU6kIiT3rYjxbnYjMKQDXCfM64zHpW GMikbUBIPpe6F10jdG0= X-Received: by 10.99.7.14 with SMTP id 14mr3492521pgh.226.1492188318031; Fri, 14 Apr 2017 09:45:18 -0700 (PDT) Received: from [192.168.1.32] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id c83sm4220024pfd.113.2017.04.14.09.45.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 09:45:16 -0700 (PDT) From: Jeff Tantsura Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Fri, 14 Apr 2017 09:45:15 -0700 Message-Id: <03E692EE-D1EC-45C4-85EB-D2FC06778081@gmail.com> Cc: BESS , "sfc@ietf.org" To: Martin Vigoureux X-Mailer: iPhone Mail (14E304) Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:45:22 -0000 Yes/support Regards, Jeff > On Apr 13, 2017, at 11:04, Martin Vigoureux w= rote: >=20 > WG >=20 > Given the IPR disclosed [1] against=20 > draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for=20 > comment specifically to let people express a revised opinion on how=20 > draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS. >=20 > This call for comment is open until the 5th of May >=20 > Thanks > M&T >=20 > [1] https://datatracker.ietf.org/ipr/2980/ >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Apr 14 09:45:49 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BB6129449; Fri, 14 Apr 2017 09:45:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149218833729.15800.6366416224828408137@ietfa.amsl.com> Date: Fri, 14 Apr 2017 09:45:37 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-vpws-12.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:45:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : VPWS support in EVPN Authors : Sami Boutros Ali Sajassi Samer Salam John Drake Jorge Rabadan Filename : draft-ietf-bess-evpn-vpws-12.txt Pages : 14 Date : 2017-04-14 Abstract: This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-12 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-vpws-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 14 09:49:52 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4ED128B8E; Fri, 14 Apr 2017 09:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IHY1zLxilmM; Fri, 14 Apr 2017 09:49:40 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C4B1294CE; Fri, 14 Apr 2017 09:49:38 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3EGkA7f048083; Fri, 14 Apr 2017 12:49:35 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 29twq13gm3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Apr 2017 12:49:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3EGnYeS008512; Fri, 14 Apr 2017 12:49:34 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3EGnRkI008365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Apr 2017 12:49:31 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 14 Apr 2017 16:49:17 GMT Received: from MISOUT7MSGUSRCA.ITServices.sbc.com ([169.254.1.23]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0319.002; Fri, 14 Apr 2017 12:49:17 -0400 From: "LINGALA, AVINASH" To: John E Drake , BESS CC: "sfc@ietf.org" Thread-Topic: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure Thread-Index: AQHStIi1T7yWCm1sxEC3sJbVK6tw6KHFANjA Date: Fri, 14 Apr 2017 16:49:17 +0000 Message-ID: <69C84E23D6485E46BBAC817C2860E07D37EAEC5E@MISOUT7MSGUSRCA.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.198.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-14_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704140143 Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:49:42 -0000 I still support the adoption. Thanks, Avinash=20 -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of John E Drake Sent: Thursday, April 13, 2017 3:04 PM To: BESS Cc: sfc@ietf.org Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bg= p-control-plane adoption following the IPR disclosure M&T, I still support the adoption. I looked at the subject patent and it appear= s to have very little to do with draft-mackie. I think this means that the= IPR assertion would be similarly made against *any* solution developed by = BESS. Yours Irrespectively, John > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Thursday, April 13, 2017 2:04 PM > To: BESS > Cc: sfc@ietf.org > Subject: [sfc] Extra time to reflect on=20 > draft-mackie-bess-nsh-bgp-control-plane > adoption following the IPR disclosure >=20 > WG >=20 > Given the IPR disclosed [1] against > draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for=20 > comment specifically to let people express a revised opinion on how=20 > draft-ietf-bess-nsh- bgp-control-plane should be pursued in BESS. >=20 > This call for comment is open until the 5th of May >=20 > Thanks > M&T >=20 > [1]=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf. > org_ipr_2980_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DBrp6KjSZbKLoy2Ukj= hwk > Cg&m=3DehMaQDD-dPc_aAvjT9K9ornHKFsasBzQssYKQYdShn4&s=3D9bX6EnFiFVIJKujVIt= H > 4RkKo597AyFSnYMqrfdXh09I&e=3D >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail > man_listinfo_sfc&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DBrp6KjSZbKLoy2= Ukj > hwkCg&m=3DehMaQDD-dPc_aAvjT9K9ornHKFsasBzQssYKQYdShn4&s=3D8kpNlzV6glIyOof= c > Wti-2MnPBPXhixi3LNv5vJt-Tq0&e=3D _______________________________________________ BESS mailing list BESS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_bess&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DBrp6KjSZbKLoy2Ukjh= wkCg&m=3DehMaQDD-dPc_aAvjT9K9ornHKFsasBzQssYKQYdShn4&s=3DafbSOZlylyqyYgt13e= NgSrNn0q63XptOW9vecNk51l4&e=3D=20 From nobody Fri Apr 14 12:07:30 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5F512954B; Fri, 14 Apr 2017 12:07:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-bess-evpn-vpws@ietf.org, zzhang@juniper.net, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, bess@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149219683526.15863.17095606318967333428.idtracker@ietfa.amsl.com> Date: Fri, 14 Apr 2017 12:07:15 -0700 Archived-At: Subject: [bess] Last Call: (VPWS support in EVPN) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 19:07:15 -0000 The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'VPWS support in EVPN' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2635/ https://datatracker.ietf.org/ipr/2125/ The document contains these normative downward references. See RFC 3967 for additional information: rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - Independent Submission Editor stream) From nobody Fri Apr 14 13:01:43 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB9129646; Fri, 14 Apr 2017 13:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OylKP21naGR2; Fri, 14 Apr 2017 13:01:39 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690671289B5; Fri, 14 Apr 2017 13:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1080; q=dns/txt; s=iport; t=1492200099; x=1493409699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Yc2lXa5+Q4BoJ9NL8yOZZWZPEgbLaBXKn5ZI/oHn1+Q=; b=AyjVaVeYT50XwCff1TqXsHPbcxSapsjf/lKAUhnmW9ksbDMkJ6vmw2g1 e7aX2jeyPnk8u2dWGzv4CyzYeRtl/K0EZttDB0loOI3DVrQbxP0uSnJau 50tCVciO/F3OkVPpeqxPxdE501LOEWhgjRD1TSwPEAOZTaaYQ/tWDVebM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAQBdKfFY/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KFac6gg8hC4V4AhqDZT8YAQIBAQEBAQEBayiFFgI?= =?us-ascii?q?BAwEBGwYROgsQAgEIGgIfBwICAiULFRACBA4FH4l4Dqk2giaLEAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgQuHJIMXhFeDBoJfAQSdFwGHA4thkUaUCQEfOIEFYxV?= =?us-ascii?q?BhReBSnWIO4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,200,1488844800"; d="scan'208";a="410441438" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2017 20:01:38 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3EK1cUa002434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Apr 2017 20:01:38 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Apr 2017 16:01:37 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 14 Apr 2017 16:01:37 -0400 From: "Acee Lindem (acee)" To: BESS CC: "sfc@ietf.org" Thread-Topic: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure Thread-Index: AQHStIBxnI3ZBjZ5Z0OY2Wmh/edc+6HFStYA Date: Fri, 14 Apr 2017 20:01:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <5177F680EDDCEB4F9EC29EA73393B506@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 20:01:41 -0000 U3VwcG9ydC4gV2hpbGUgSSB3b27igJl0IGNvbW1lbnQgb24gc3BlY2lmaWNzLCB0aGUgSVBSIGFw cGVhcnMgdG8gb25seSBhcHBseQ0KdG8gb25lIGFzcGVjdCBvZiB0aGUgcHJvcG9zZWQgU0ZDIG1l Y2hhbmlzbXMuDQpUaGFua3MsDQpBY2VlIA0KDQpPbiA0LzEzLzE3LCAyOjA0IFBNLCAiQkVTUyBv biBiZWhhbGYgb2YgTWFydGluIFZpZ291cmV1eCINCjxiZXNzLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIG1hcnRpbi52aWdvdXJldXhAbm9raWEuY29tPiB3cm90ZToNCg0KPldHDQo+DQo+ R2l2ZW4gdGhlIElQUiBkaXNjbG9zZWQgWzFdIGFnYWluc3QNCj5kcmFmdC1tYWNraWUtYmVzcy1u c2gtYmdwLWNvbnRyb2wtcGxhbmUsIHdlIGFyZSBzdGFydGluZyBhIGNhbGwgZm9yDQo+Y29tbWVu dCBzcGVjaWZpY2FsbHkgdG8gbGV0IHBlb3BsZSBleHByZXNzIGEgcmV2aXNlZCBvcGluaW9uIG9u IGhvdw0KPmRyYWZ0LWlldGYtYmVzcy1uc2gtYmdwLWNvbnRyb2wtcGxhbmUgc2hvdWxkIGJlIHB1 cnN1ZWQgaW4gQkVTUy4NCj4NCj5UaGlzIGNhbGwgZm9yIGNvbW1lbnQgaXMgb3BlbiB1bnRpbCB0 aGUgNXRoIG9mIE1heQ0KPg0KPlRoYW5rcw0KPk0mVA0KPg0KPlsxXSBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2lwci8yOTgwLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+QkVTUyBtYWlsaW5nIGxpc3QNCj5CRVNTQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQoNCg== From nobody Fri Apr 14 14:29:04 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B1F129514; Fri, 14 Apr 2017 14:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1U5-_xk_rk0; Fri, 14 Apr 2017 14:28:53 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E496B12950C; Fri, 14 Apr 2017 14:28:52 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so101324317oif.0; Fri, 14 Apr 2017 14:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hBDoch/eBOwPvXbnGVs1lTYsY46DZ7+1i5bHgDbs8EY=; b=oID2M8m6gurp+6jVdExcPGlkbk5QsoFDfttE8aJWG2jlE2W6Zf3oyOofWIKVBNElKe ziuyt3JL1JB8/izabzHZV86B1mOAalmpEJNDU5JLcPM4zkJoh3wW2kEiGFbSzmE0CjZe EkoAMxthNg+dbHSh6cqgyejUVz7YdRG/1PpjfhbZGGfClvfsy5cGlvno+Tt+nZTjmfr3 ax/mGbxUI1aa7wFiNGvu3FWMnCtmqoGsaOJihu+T0uSHmemqApT9uwjI976XFUo7bHly B5bSzAjUEOoaxYkhdKJ7+dneZT/BsGcB4Mek0vPabTitz6QPNTx/E0dcUdzOnq+wJfAV M9dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hBDoch/eBOwPvXbnGVs1lTYsY46DZ7+1i5bHgDbs8EY=; b=VeZWRBGkE8KCIw1YO8/Al26Ngs0AbBpwl5QJEJJNGfcZr+AD4x5lKoOHdbqBcW+Dyv EsDSoQV84OUUS8I1UeCMjKX0ISzfHdQguHkr9ZlVYbSK32XYhzRPwx1cuA6WWvq+/yBj GrzLUx4pG26+karsYv/klmuera7jq/P3KUW1B0F1x1hGUJJAlBI2mAnPKLMJcyEgQJ7f sSiylJVn7uyc1npocDyK/PoOniN7ILnw3PK/hBeZkmCjdiYFpM75Xgb/k9lrauZpvymo zvSImIBBdkddcbJdi16h04RFHLmJGSKsmCWN71HEozC6z4XMrX8PNR1ObVOUjvNhLic7 /z0w== X-Gm-Message-State: AN3rC/5Y8QdO2DwZa/6ifs+ZewTbl5ranQATNo5+ubZSvv9jXeJ6ZiiG se0DPaHV3OxmWHzKdQBU6syBAKEmcw== X-Received: by 10.157.30.202 with SMTP id n68mr7039532otn.252.1492205332314; Fri, 14 Apr 2017 14:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.201 with HTTP; Fri, 14 Apr 2017 14:28:31 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 14 Apr 2017 17:28:31 -0400 Message-ID: To: Keyur Patel Cc: John E Drake , BESS , "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a113ba450c3c0e5054d2720e3 Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:28:55 -0000 --001a113ba450c3c0e5054d2720e3 Content-Type: text/plain; charset=UTF-8 I also agree with John. Cheers, Andy On Fri, Apr 14, 2017 at 12:42 PM, Keyur Patel wrote: > Agree with John. I support the adoption. > > On 4/13/17, 12:03 PM, "sfc on behalf of John E Drake" < > sfc-bounces@ietf.org on behalf of jdrake@juniper.net> wrote: > > M&T, > > I still support the adoption. I looked at the subject patent and it > appears to have very little to do with draft-mackie. I think this means > that the IPR assertion would be similarly made against *any* solution > developed by BESS. > > Yours Irrespectively, > > John > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin > Vigoureux > > Sent: Thursday, April 13, 2017 2:04 PM > > To: BESS > > Cc: sfc@ietf.org > > Subject: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp- > control-plane > > adoption following the IPR disclosure > > > > WG > > > > Given the IPR disclosed [1] against > > draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for > comment > > specifically to let people express a revised opinion on how > draft-ietf-bess-nsh- > > bgp-control-plane should be pursued in BESS. > > > > This call for comment is open until the 5th of May > > > > Thanks > > M&T > > > > [1] https://datatracker.ietf.org/ipr/2980/ > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --001a113ba450c3c0e5054d2720e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also agree with John.

Cheers,
Andy

On F= ri, Apr 14, 2017 at 12:42 PM, Keyur Patel <keyur@arrcus.com> = wrote:
Agree with John. I support the ado= ption.

On 4/13/17, 12:03 PM, "sfc on behalf of John E Drake" <sfc-bounces@ietf.org on behalf of jdrake@juniper.net> wrote:

=C2=A0 =C2=A0 M&T,

=C2=A0 =C2=A0 I still support the adoption.=C2=A0 I looked at the subject p= atent and it appears to have very little to do with draft-mackie.=C2=A0 I t= hink this means that the IPR assertion would be similarly made against *any= * solution developed by BESS.

=C2=A0 =C2=A0 Yours Irrespectively,

=C2=A0 =C2=A0 John


=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Vigoureux
=C2=A0 =C2=A0 > Sent: Thursday, April 13, 2017 2:04 PM
=C2=A0 =C2=A0 > To: BESS <bess@ietf.= org>
=C2=A0 =C2=A0 > Cc: sfc@ietf.org
=C2=A0 =C2=A0 > Subject: [sfc] Extra time to reflect on draft-mackie-bes= s-nsh-bgp-control-plane
=C2=A0 =C2=A0 > adoption following the IPR disclosure
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > WG
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Given the IPR disclosed [1] against
=C2=A0 =C2=A0 > draft-mackie-bess-nsh-bgp-control-plane, we are sta= rting a call for comment
=C2=A0 =C2=A0 > specifically to let people express a revised opinion on = how draft-ietf-bess-nsh-
=C2=A0 =C2=A0 > bgp-control-plane should be pursued in BESS.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This call for comment is open until the 5th of May
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks
=C2=A0 =C2=A0 > M&T
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > [1] https://datatracker.ietf.org/ipr/2= 980/
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > sfc mailing list
=C2=A0 =C2=A0 > sfc@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listin= fo/sfc

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 sfc mailing list
=C2=A0 =C2=A0 sfc@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/sf= c


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

--001a113ba450c3c0e5054d2720e3-- From nobody Fri Apr 14 16:31:23 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51681129ADA; Fri, 14 Apr 2017 16:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdz1jqeEWyqw; Fri, 14 Apr 2017 16:31:05 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBE5129513; Fri, 14 Apr 2017 16:31:05 -0700 (PDT) Received: from [192.168.0.92] (cysvpn05.priv.cysol.co.jp [192.168.0.92]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id v3ENUur8014415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 15 Apr 2017 08:30:56 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" From: Glenn Mansfield Keeni Message-ID: <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> Date: Sat, 15 Apr 2017 08:30:51 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 23:31:15 -0000 Hi Tsunoda, Got this. Thanks for the good work. I hope to review this draft and get back to you by the end of next week. Cheers Glenn On 2017/04/13 18:41, Hiroshi Tsunoda wrote: > Dear Glenn, > > I posted a new revision taking into account your latest comments. > In the new revision, the following two new textual conventions are > added to L2L3-VPN-MCAST-TC-MIB. > - L2L3VpnMcastProviderTunnelPointer > - L2L3VpnMcastProviderTunnelPointerType > > This change is to provide a mean to specify the table type referred > by the object in L2L3-VPN-MCAST-MIB. > > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-07.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-07 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-07 > > Please see some notes below. > >> A. Sec 1.1 Terminology. >> 1. The scope of the MIB is "Layer 2 and Layer 3 Virtual Private >> Networks (VPN) that support multicast". This phrase appears >> multiple times in the text. >> It would be better to coin a term (eg L2/L3-VPN-MCast) for the >> above in Sec 1.1 Terminology and use it in the text. > > Hmm, that phrase appears in Abstract, Sec.3, and MIB definition. > In my humble opinion, that current style seems better because > the MIB definition part may be read separately from this document. > Thus, I keep the current style. > >> B. TC-MIB >> 1 L2L3VpnMcastProviderTunnelType enumeration order: >> Is there any rationale behind the difference in ordering in >> Sec 1.1 Terminology and the enumeration in the textual convention? >> Could these be aligned? > > The enumeration order in the textual convention is based on > Section 5 of [RFC6514]. > In Sec.1.1, I would like to categorize tunnel setup techniques > based on the protocol. > > Thus, there is the difference in ordering in those sections. > >> C. L2L3-VPN-MCAST-MIB >> 1. DESCRIPTION >> The description states >> "This MIB module will be used by other MIB modules designed for >> managing multicast in Layer 2 (L2) VPNs [RFC7117] and >> Layer 3 (L3) VPNs [RFC6513], [RFC6514]" >> >> The statement differs from that in the abstract: >> "designed for monitoring and/or configuring both >> Layer 2 and Layer 3 Virtual Private Networks (VPN) that support >> multicast." >> >> Please align the descriptions. >> [The description in the abstract appears more appropriate.] > > Thank you. I fixed the description according to your recommendation. > >> 2. OID tree structure: >> Is there any particular reason to have the l2L3VpnMcastStates subtree? >> If no, then l2L3VpnMcastPmsiTunnelAttributeTable can come directly >> under l2L3VpnMcastObjects > > Fixed. Now l2L3VpnMcastPmsiTunnelAttributeTable is directy under > l2L3VpnMcastObjects. > >> 3. l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >> DESCRIPTION >> "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId >> may be represented as an entry in other table, e.g, >> mplsTunnelTable [RFC3812]. >> There must be some means to specify which "other table" table this >> RowPointer points too unless it points to a single prespecified >> Table (mplsTunnelTable). > > I defined a new object, l2L3VpnMcastPmsiTunnelPointerType, in > L2L3-VPN-MCAST-MIB. > This usage of this object is to specify the type of > l2L3VpnMcastPmsiTunnelPointer. > Its syntax is L2L3VpnMcastProviderTunnelPointerType which is defined > in L2L3-VPN-MCAST-TC-MIB. > > I hope this fulfills your requirement. > >> D. Other issues: >> >> 1. It is stated that this MIB will be used by other MIBs >> "designed for monitoring and/or configuring both >> Layer 2 and Layer 3 Virtual Private Networks (VPN) that support >> multicast." >> >> Is there a use case for this MIB? That would make it easier to >> understand and review the applicability. > > MCAST-VPN-MIB, defined in other document, use this MIB > to get the information of BGP PMSI attribute. > MCAST-VPN-MIB has several tables for monitoring and configuring > several types of PMSI (I-PMSI, S-PMSI, etc). > Each table is required to have the attribute information and has > the pointer to a row in l2L3VpnMcastPmsiTunnelAttributeTable. > > I hope this answers your question. > >> 2. You are sure that notifications are not required ? > > I think no notifications are required. > I and Jeffery do not find any useful notifications regarding this MIB > for operators/administrators. > >> 3. You are sure that read-write and/or read-create operations are not >> required for rows in l2L3VpnMcastPmsiTunnelAttributeTable? >> >> Then the purpose of this MIB will be limited to >> o provide a pointer to tables like ifXTable for further attributes >> o provide a list of tunnels >> only? > > The content of the table comes only from signaling. > Therefore, I think read-write and read-create operations are not required. > >> E. Editorial issues >> A complete editorial review is TBD. >> >> 1. line 99: Typo? >> < BPG auto-discovery (A-D) routes. >> > BPG auto-discovery (A-D) routes. >> 2. line 102: Typo >> < This document defines a textual conventions (TC) >> > This document defines a textual convention (TC) >> 3. line 134: nit >> < A PE uses to send >> > A PE uses it to send > > Fixed. Thank you very much for pointing these out. > > Thanks. > > -- tsuno > > 2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni : >> Dear Tsunoda, >>> I think that I have addressed all of Glenn's comments in >>> this revision. >> Thanks for addressing the comments. The MIB compiles OK and >> is looking good. It is shaping up well. >> A new set of comments is attached. Please check and do the >> >> needful. >> Glenn >> On 2017/02/21 16:50, Hiroshi Tsunoda wrote: >>> >>> Dear Glenn and BESS WG, >>> >>> I posted a new revision as follows. >>> I think that I have addressed all of Glenn's comments in this revision. >>> >>> In this revision, I have tried to add more detailed explanation >>> throughout the document. >>> Please review and let me know if there are any misunderstanding from >>> technical view points. >>> >>> URL: >>> >>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-06.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-06 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-06 >>> >>> Please see some notes below. >>> >>>> 1. Introduction >>>> >>>> 1.1 >>>> Would be very nice if a short explanations of MVPN and >>>> L2 VPN Multicast were given. With emphasis on the operational >>>> aspects. >>> >>> >>> I have updated Introduction. I hope this update fulfills your >>> requirements. >>> >>>> 1.4 .... there are 2 types of PMSIs .. >>>> >>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>> >>>> >>>> please make these explanations more gentle(complete) to the reader. >>>> Also, give the references where these terms are defined. >>> >>> >>> More gentle explanation and references were added in Terminology >>> section (Sec.1.1). >>> >>>> 3.2 some more text like the following will be good. >>>> L2L3-VPN-MCAST-MIB contains >>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>>> an enumeration of the provider tunnel types and, >>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>>> composed of multiple attributes that depend on the tunnel type and >>>> uniquely identify a tunnel. This table will be used to ... monitor >>>> the tunnels supported by the system at a given point of time (?) >>>> It may also be used in conjunction with XXXX-mib to obtain the >>>> other details of a tunnel by following the row pointer of the >>>> corresponding tunnel's row in this table. >>>> [ Please treat the above as a template and modify the text as >>>> appropriate ..] >>> >>> >>> Fixed in this revision. Please look at Sec. 3 Summary of MIB Module. >>> >>>> 3.3 Since this will become a standard document, please take care of >>>> definitions and notations used in the document. >>>> The notation I/S-PMSI is not defined. If you must use a new >>>> term/notation, define it before use. >>> >>> >>> The notation I/S-PMSI is defined in Sec.1.1 now. >>> >>>> 4.8 >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>> [I-D.ietf-bess-mvpn-mib]." >>>> >>>> >>>> It would seem that each row in this table is an index for a PTA >>>> and may contain pointers to rows in tables of other MIB modules >>>> which may contain more details for the PTA. Is that correct? >>>> Please reword the DESCRIPTION acordingly. >>>> Also see comments in 4.15 >>> >>> >>> I have changed DESCRIPTION as follows. >>> >>> "An entry of this table corresponds with a >>> PMSI Tunnel attribute and is created by a PE router >>> that advertises and receives the attribute. >>> The entry in the table will be referred by other MIB modules >>> which are designed for monitoring and/or configuring >>> both L2 and L3 VPN that support multicast." >>> >>> >>>> 4.10-3 >>>> the phrase UDP-based S-PMSI appears here for the first time. >>>> Somewhere earlier it should be made clear that UDP too may be used >>>> in signaling. >>> >>> >>> In Introduction, I have explained that BGP and UDP are used in signaling. >>> >>>> 4.13 >>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>> >>>>> DESCRIPTION >>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>> field in PMSI Tunnel Attribute of the corresponding >>>>> I/S-PMSI A-D or Leaf A-D route." >>>> >>>> o Does this description cover all the types? If not, then cover all the >>>> types unless there is a good reason to focus only on the above types. >>>> o I/S-PMSI: unexplained notation. >>> >>> >>> Fixed. >>> >>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>> >>>> Please indicate that the first column gives the size >>> >>> >>> I have updated the table as follows. >>> >>> Size (in octets) l2L3VpnMcastPmsiTunnelAttributeType >>> IPv4 IPv6 (tunneling technology) >>> -------------------------------------------------- >>> 0 0 noTunnelId (No tunnel information present) >>> 12 24 rsvpP2mp (RSVP-TE P2MP LSP) >>> 17 29 ldpP2mp (mLDP P2MP LSP) >>> 8 32 pimSsm (PIM-SSM Tree) >>> >>>>> 8/32 pimAsm >>>>> 8/32 pimSsm >>>>> 8/32 pimBidir >>>>> 4/16 ingressReplication >>>> >>>> >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>> 8 or 32 octets of this attribute are filled with >>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>> Identifier field in PMSI Tunnel Attribute of the >>>>> corresponding I/S-PMSI A-D route." >>>> >>>> >>>> A more generous description of the AttributeID would be good. All the >>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>>> summary would be very nice. >>> >>> >>> Fixed. I have summarized Section 5 of RFC 6514 here. >>> >>>> 4.15 >>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>> >>>>> SYNTAX RowPointer >>>>> DESCRIPTION >>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>> pointer is null." >>>> >>>> I am having problems understanding this. Will help if you can give >>>> a use case of how this will be used. As of now the intent is unclear. >>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>> pointer to a specific row in a specific table. If this is a pointer to >>>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >>> >>> >>> I have changed DESCRIPTION as follows. >>> >>> "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId >>> may be represented as an entry in other table, e.g, >>> mplsTunnelTable [RFC3812]. If there is such entry, >>> this object will point to the row pertaining to the entry. >>> Otherwise, the pointer is null." >>> >>>> 5.0 >>>>> >>>>> 5. Security Considerations >>>> >>>> TBD >>> >>> >>> I have rewritten this part according to the guideline described in >>> RFC4181 Sec.3.4. >>> >>>> 6.0 >>>>> >>>>> 6. IANA Considerations >>>> >>>> >>>>> IANA is requested to root MIB objects in the MIB module contained in >>>>> this document under the mib-2 subtree. >>>> >>>> >>>> Please Note: >>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to >>>> put the definitions in a separate MIB module. That would mean a >>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>> TC can be carried out by some entity ( IANA or, some WG or, whoever is >>>> responsible for maintaining the TC) independent of other MIB objects. >>>> If that is the intent you will need to define 2 mib modules and you >>>> will >>>> need to request 2 branches in the mib-2 subtree- one for the module >>>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>> >>> >>> Now, this document defines following two MIB modules: >>> - the module containing the L2L3VpnMcastProviderTunnelType TC >>> - the module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>> >>> -- tsuno >>> >>> 2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni : >>>> >>>> Dear Tsunoda, >>>>> >>>>> I will submit the next version within three days. >>>>> The next versionbwill address all of remained your >>>>> comments. >>>> >>>> Great! Looking forward to the revised draft. >>>> >>>> Glenn >>>> >>>> On 2017/02/18 16:30, Hiroshi Tsunoda wrote: >>>>> >>>>> >>>>> Dear Glenn, >>>>> >>>>> I am sorry I kept you waiting so long for the revised version, I have >>>>> been side tracked by other things. >>>>> I will submit the next version within three days. The next version >>>>> will address all of remained your comments. >>>>> The summary of remained TODOs is shown below. Please wait a little >>>>> more >>>>> time. >>>>> ------------- >>>>> 1. Add general explanation about MVPN, multicast in VPLS >>>>> Define and explain some technical terms, such as PIM-MVPN, >>>>> UDP-based S-PMSI etc. >>>>> >>>>> 2. Revise summary of the MIB module >>>>> >>>>> 3. Revise MIB definition >>>>> a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable >>>>> b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to >>>>> cover all cases. >>>>> c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId >>>>> d. Fix the description of l2L3VpnMcastPmsiTunnelPointer >>>>> >>>>> 4. Split the MIB module into two separate modules. >>>>> >>>>> 5. Revise security considertations >>>>> ------------- >>>>> >>>>> P.S. Update of mvpn-mib-02 will be submitted by the end of this month. >>>>> >>>>> Best regards, >>>>> >>>>> -- tsuno >>>>> >>>>> 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : >>>>>> >>>>>> >>>>>> Hi Tsunoda, >>>>>>> >>>>>>> >>>>>>> I have started to volunteer to help to move this document forward. >>>>>> >>>>>> >>>>>> Great! >>>>>>> >>>>>>> >>>>>>> I posted a new revision and addressed all editorial things in >>>>>>> that revision. >>>>>> >>>>>> >>>>>> Got this. Looks good. >>>>>>> >>>>>>> >>>>>>> Please give me some more time for revising other parts, >>>>>> >>>>>> >>>>>> No problems. Will be looking forward to the revised document. >>>>>> >>>>>> Glenn >>>>>> >>>>>> >>>>>> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dear Glenn, >>>>>>> >>>>>>> Thanks for your careful review and detailed comments/suggestions. >>>>>>> I have started to volunteer to help to move this document forward. >>>>>>> I posted a new revision and addressed all editorial things in that >>>>>>> revision. >>>>>>> Please give me some more time for revising other parts, >>>>>>> in order to be familiar with the context of the original and related >>>>>>> documents. >>>>>>> >>>>>>> URL: >>>>>>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>>> Htmlized: >>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 >>>>>>> Diff: >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>>> >>>>>>> Please see some notes below. >>>>>>> >>>>>>>> 0. Abstract. >>>>>>>> 0.1. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> it describes common managed objects used to configure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>>> >>>>>>>> There are no writable MOs in this MIB. So it does not look >>>>>>>> as though this MIB will be used for configuration directly. >>>>>>>> The use case scenario for monitoring is not clear, either. >>>>>>>> It appears that the MIB module(s) in this document will be >>>>>>>> used by other modules which are designed for monitoring and/ >>>>>>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>>>>>> wording. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 1. Introduction >>>>>>>> >>>>>>>> 1.1 >>>>>>>> Would be very nice if a short explanations of MVPN and >>>>>>>> L2 VPN Multicast were given. With emphasis on the operational >>>>>>>> aspects. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise. >>>>>>> >>>>>>>> 1.2 >>>>>>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>>>>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 1.3 >>>>>>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 1.4 .... there are 2 types of PMSIs .. >>>>>>>> >>>>>>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>>>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> please make these explanations more gentle(complete) to the >>>>>>>> reader. >>>>>>>> Also, give the references where these terms are defined. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise. >>>>>>> >>>>>>>> 3. Summary of MIB Module >>>>>>>> 3.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Typo: I/S-PMSI, (see 3.3 below). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 3.2 some more text like the following will be good. >>>>>>>> L2L3-VPN-MCAST-MIB contains >>>>>>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that >>>>>>>> provides >>>>>>>> an enumeration of the provider tunnel types and, >>>>>>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index >>>>>>>> is >>>>>>>> composed of multiple attributes that depend on the tunnel type >>>>>>>> and >>>>>>>> uniquely identify a tunnel. This table will be used to ... >>>>>>>> monitor >>>>>>>> the tunnels supported by the system at a given point of time >>>>>>>> (?) >>>>>>>> It may also be used in conjunction with XXXX-mib to obtain the >>>>>>>> other details of a tunnel by following the row pointer of the >>>>>>>> corresponding tunnel's row in this table. >>>>>>>> [ Please treat the above as a template and modify the text as >>>>>>>> appropriate ..] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise this point. >>>>>>> >>>>>>>> 3.3 Since this will become a standard document, please take care of >>>>>>>> definitions and notations used in the document. >>>>>>>> The notation I/S-PMSI is not defined. If you must use a new >>>>>>>> term/notation, define it before use. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise this point. >>>>>>> >>>>>>>> 4. Definitions >>>>>>>> >>>>>>>>> IMPORTS >>>>>>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4.1 Since this is not a Experimental MIB do not import use >>>>>>>> experimental. >>>>>>>> It is good practice to keep the draft in the as "close to final >>>>>>>> form" >>>>>>>> as possible. (See below) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please update this date. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Updated. >>>>>>> >>>>>>>> 4.3 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> DESCRIPTION >>>>>>>>> "This MIB contains common managed object definitions for >>>>>>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>>>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Would be good if you could rearrange the text. Something like >>>>>>>> "This MIB module will be used for managing multicast in Layer 2 >>>>>>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>>>>>> Or, even better >>>>>>>> "This MIB module will be used by other MIB modules designed for >>>>>>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>>>>>> [RFC6513], [RFC6514] >>>>>>>> Or, a combination of both, depending on the envisaged use case >>>>>>>> scenarios. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Rearranged the text along with your comment. >>>>>>> >>>>>>>> 4.4 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ::= { experimental 999 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please >>>>>>>> o Replace "experimental" by the branch where this mib module >>>>>>>> will >>>>>>>> be anchored; that is a decision that the WG will take, >>>>>>>> probably. >>>>>>>> o Import the branch in the IMPORTS statement >>>>>>>> [ In the IANA Considerations section a branch in the mib-2 >>>>>>>> subtree >>>>>>>> is requested. In that case this must be >>>>>>>> ::= { mib-2 XXX } >>>>>>>> ] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.5 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Please also remove the ", experimental" text from earlier >>>>>>>>> -- IMPORTS section. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Remove these instructions. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Removed. >>>>>>> >>>>>>>> 4.5.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Texual convention >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Typo: -- Textual convention >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.6 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>>>> DESCRIPTION >>>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>>>>>> in future RFCs, and those will be allowed as >>>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The part >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Additional types may be defined >>>>>>>>> in future RFCs, and those will be allowed as >>>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> may be deleted. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Deleted. >>>>>>> >>>>>>>> 4.7 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Top level components of this MIB. >>>>>>>>> -- tables, scalars, conformance information >>>>>>>>> >>>>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>>>> >>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> should be >>>>>>>> >>>>>>>> -- Top level components of this MIB. >>>>>>>> >>>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects >>>>>>>> 1 >>>>>>>> } >>>>>>>> >>>>>>>> -- tables, scalars, conformance information >>>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.8 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>> STATUS current >>>>>>>>> DESCRIPTION >>>>>>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>>>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>>>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>>>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>>>>>> [I-D.ietf-bess-mvpn-mib]." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It would seem that each row in this table is an index for a PTA >>>>>>>> and may contain pointers to rows in tables of other MIB modules >>>>>>>> which may contain more details for the PTA. Is that correct? >>>>>>>> Please reword the DESCRIPTION acordingly. >>>>>>>> Also see comments in 4.15 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. I need some more time to understand the original context. >>>>>>> >>>>>>>> 4.9 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>>> "An entry in this table corresponds to a PTA >>>>>>>>> that is advertised/received on this router. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >>>>>>>> so "entry in this table" does not fit in well. >>>>>>>> A rewording like >>>>>>>> "A conceptual row corresponding to a PTA >>>>>>>> that is advertised/received on this router. >>>>>>>> .... >>>>>>>> would be better. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.10 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>>> they are just as signaled by BGP. >>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>> they're derived from the S-PMSI Join Message. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Note that BGP-based signaling may be used for >>>>>>>>> PIM-MVPN as well." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Is the signaling mechanism important here? If it isn't then the >>>>>>>> above part of the description is redundant. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Removed the above part. >>>>>>> >>>>>>>> 4.10-2 >>>>>>>> PIM-MVPN appears for the first time. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Defined the notation of PIM-MVPM as follows >>>>>>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>>>>>> However, I think that some descriptions may be required for this >>>>>>> somewhere in this document. That is TBD. >>>>>>> >>>>>>>> 4.10-3 >>>>>>>> the phrase UDP-based S-PMSI appears here for the first time. >>>>>>>> Somewhere earlier it should be made clear that UDP too may be used >>>>>>>> in signaling. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. >>>>>>> >>>>>>>> 4.11 >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "this" is unclear. >>>>>>>> Something like "the value of this object is 0" will be better. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>>> More bits may be defined in the future and >>>>>>>>> they will be registered in IANA Registry xxxx." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This part is probably redundant. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Removed. >>>>>>> >>>>>>>> 4.12 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>>>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>>>>>> -- and remove this note. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Look at the comments in 6.0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above description ("IANA Registry xxxx.") was removed, >>>>>>> thus this part was also removed. >>>>>>> >>>>>>>> 4.13 >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> DESCRIPTION >>>>>>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>>> I/S-PMSI A-D or Leaf A-D route." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> o Does this description cover all the types? If not, then cover all >>>>>>>> the >>>>>>>> types unless there is a good reason to focus only on the above >>>>>>>> types. >>>>>>>> o I/S-PMSI: unexplained notation. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to address this point. >>>>>>> >>>>>>>> 4.14 >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It appears that you also allow sizes "16" and "32"; these must be >>>>>>>> included. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please indicate that the first column gives the size >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I made a change as follows. >>>>>>> >>>>>>> Size l2L3VpnMcastPmsiTunnelAttributeType >>>>>>> (IPv4/IPv6) >>>>>>> -------------------------------------------------- >>>>>>> (snip) >>>>>>> 8/32 pimAsm >>>>>>> (snip) >>>>>>> >>>>>>> Is this OK? >>>>>>> >>>>>>>>> 8/32 pimAsm >>>>>>>>> 8/32 pimSsm >>>>>>>>> 8/32 pimBidir >>>>>>>>> 4/16 ingressReplication >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>>>>> 8 or 32 octets of this attribute are filled with >>>>>>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>>>>>> Identifier field in PMSI Tunnel Attribute of the >>>>>>>>> corresponding I/S-PMSI A-D route." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A more generous description of the AttributeID would be good. All >>>>>>>> the >>>>>>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A >>>>>>>> simple >>>>>>>> summary would be very nice. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise this point. >>>>>>> >>>>>>>> 4.15 >>>>>>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> SYNTAX RowPointer >>>>>>>>> DESCRIPTION >>>>>>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>>>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>>>>>> pointer is null." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am having problems understanding this. Will help if you can give >>>>>>>> a use case of how this will be used. As of now the intent is >>>>>>>> unclear. >>>>>>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>>>>>> pointer to a specific row in a specific table. If this is a pointer >>>>>>>> to >>>>>>>> a row in the mplsTunnelTable spell it out clearly and >>>>>>>> unambiguously. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. I will need some more time to understand the original context. >>>>>>> >>>>>>>> 4.16 >>>>>>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>> DESCRIPTION >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> "If the tunnel has a corresponding interface, this is the >>>>>>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This description is better. Would be even better with >>>>>>>> "If the tunnel has a corresponding entry in the ifXTable, >>>>>>>> this object will point to the row pertaining to the entry >>>>>>>> ..... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.17 >>>>>>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> DESCRIPTION >>>>>>>>> "Support of these object is not required." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Support of these objects is not required. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 5.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 5. Security Considerations >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> TBD >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Still TBD. >>>>>>> >>>>>>>> 6.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 6. IANA Considerations >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> IANA is requested to root MIB objects in the MIB module contained >>>>>>>>> in >>>>>>>>> this document under the mib-2 subtree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please Note: >>>>>>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you >>>>>>>> need >>>>>>>> to >>>>>>>> put the definitions in a separate MIB module. That would mean a >>>>>>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>>>>>> TC can be carried out by some entity ( IANA or, some WG or, >>>>>>>> whoever >>>>>>>> is >>>>>>>> responsible for maintaining the TC) independent of other MIB >>>>>>>> objects. >>>>>>>> If that is the intent you will need to define 2 mib modules and >>>>>>>> you >>>>>>>> will >>>>>>>> need to request 2 branches in the mib-2 subtree- one for the >>>>>>>> module >>>>>>>> containing the L2L3VpnMcastProviderTunnelType TC and another for >>>>>>>> the >>>>>>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. I will address this point in the next revision. >>>>>>> >>>>>>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Jeffrey, >>>>>>>> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >>>>>>>> document. It took me some time to do this review. But now here it >>>>>>>> is. A (near complete) review of >>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>>> is >>>>>>>> attached. Hope this helps. >>>>>>>> I understand that the Security Considerations section is TBD. >>>>>>>> >>>>>>>> Glenn >>>>>>>> >>>>>>>> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Glenn, >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>>>>>>>>> Sent: Sunday, May 08, 2016 11:02 AM >>>>>>>>>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>>>>>>>>> ; EXT - thomas.morin@orange.com >>>>>>>>>> >>>>>>>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>>>>>>> Vigoureux >>>>>>>>>> ; bess@ietf.org; mib-doctors@ietf.org >>>>>>>>>> Subject: Re: [bess] MIBDoc review of >>>>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>>>>>>>> 02.txt >>>>>>>>>> >>>>>>>>>> Jeffrey, >>>>>>>>>> > Thanks for your comments. I've addressed most of your comments >>>>>>>>>> > in the new revision: >>>>>>>>>> Thanks for your cooperation. I will need at least one more revision >>>>>>>>>> with the following comments/recommendations addressed before I will >>>>>>>>>> be able to complete the detailed review. In the following the >>>>>>>>>> numbers >>>>>>>>>> refer to the issue numbers in the initial review. The issues that >>>>>>>>>> are >>>>>>>>>> addressed and closed are not listed. For brevity, the issue >>>>>>>>>> descriptions have been trimmed. In case of doubts please look at >>>>>>>>>> the >>>>>>>>>> response mail appended below. >>>>>>>>>> Hope this helps. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for your detailed comments/suggestions. I posted a new >>>>>>>>> revision >>>>>>>>> with the following issues addressed. >>>>>>>>> >>>>>>>>> URL: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>>>> Status: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>>>>> Htmlized: >>>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>>> Diff: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>>> >>>>>>>>> Please see some notes below. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Glenn >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> Comments: >>>>>>>>>> >>>>>>>>>> 1.1 >>>>>>>>>> > I had thought this would be standard/obvious for all MIB >>>>>>>>>> objects >>>>>>>>>> - >>>>>>>>>> We will comeback to this time and again, whereever possible make >>>>>>>>>> matters explicit and clear. That will help. >>>>>>>>>> > Is it enough to say something similar? For example: >>>>>>>>>> > In particular, it describes common managed objects used >>>>>>>>>> > to configure and/or monitor both L2 and L3 VPN >>>>>>>>>> Multicast. >>>>>>>>>> That is better. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I take it that this is already closed in -03 revision. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2.2 >>>>>>>>>> > Having said that, I'll explain PMSI a bit further. >>>>>>>>>> PMSI explanation is good. >>>>>>>>>> Please use the same style/format for I-PMSI and S-PMSI. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think -03 revision already use the same style/format for I-PMSI >>>>>>>>> and >>>>>>>>> S-PMSI? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2.3 >>>>>>>>>> > No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>>> out >>>>>>>>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs >>>>>>>>>> and >>>>>>>>>> I >>>>>>>>>> > was advised to change it accordingly. Looks like I did not >>>>>>>>>> change >>>>>>>>>> all >>>>>>>>>> > the cases. >>>>>>>>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 >>>>>>>>>> VPN" >>>>>>>>>> so >>>>>>>>>> > I'll change it back. >>>>>>>>>> No problems. just make sure that the same expression/notation is >>>>>>>>>> used >>>>>>>>>> uniformly. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I take it that this is also addressed in -03 already. >>>>>>>>> >>>>>>>>>> 3. >>>>>>>>>> > > > 3. Summary of MIB Module. >>>>>>>>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>>> > > > structure of the MIB, short descriptions of the >>>>>>>>>> table(s) >>>>>>>>>> > > > including usage of the table(s) for management and/or >>>>>>>>>> by >>>>>>>>>> > > > other MIB(s). >>>>>>>>>> > >>>>>>>>>> > I had that, but have added one sentence about the only table. >>>>>>>>>> A sentence or two about the textual convention will be good. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Added in -04. >>>>>>>>> >>>>>>>>>> > > > 4. MIB syntax checking: >>>>>>>>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>>> > >>>>>>>>>> > I used simpleweb's validation tool but looks like I did not use >>>>>>>>>> the >>>>>>>>>> > strictest level of validation. I've now fixed the following >>>>>>>>>> issues >>>>>>>>>> and >>>>>>>>>> > verified. >>>>>>>>>> Good. >>>>>>>>>> 5. >>>>>>>>>> > > > >>>>>>>>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses >>>>>>>>>> liberally. >>>>>>>>>> > > > Wherever possible, provide references for objects used >>>>>>>>>> in >>>>>>>>>> > > > the MIB. The references will point to specific sections/ >>>>>>>>>> > > > sub-sections of the RFCs defining the protocol for which >>>>>>>>>> the >>>>>>>>>> > > > MIB is being designed. It will greatly improve the >>>>>>>>>> readability >>>>>>>>>> > > > of the document. >>>>>>>>>> > >>>>>>>>>> > Added. >>>>>>>>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>>>>>>>> improve on it. >>>>>>>>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>>>>>>>> clause move it to a separate REFERENCE clause. The addition of the >>>>>>>>>> section number is an improvement. It is friendlier to the reader. >>>>>>>>>> Note. Same comment for other OBJECTs too. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Oh I missed that. All fixed. >>>>>>>>> >>>>>>>>>> 7.1 >>>>>>>>>> > > > 7.1 CONTACT-INFO >>>>>>>>>> > > > Following the conventions (including indentation style) >>>>>>>>>> will >>>>>>>>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>>> > > > Will be good if it does not overflow into the next >>>>>>>>>> page. >>>>>>>>>> > >>>>>>>>>> > Fixed. >>>>>>>>>> The format is OK. The Postal address etc., need not have been >>>>>>>>>> deleted. Please put the complete contact information as in the >>>>>>>>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> 7.3 >>>>>>>>>> > I kept "experimental 99" so that I could continue to use mib >>>>>>>>>> tools >>>>>>>>>> > to validate; but I added notes for the editor to replace them as >>>>>>>>>> you >>>>>>>>>> > indicated. >>>>>>>>>> Use of "experimental 99" is not recommended. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Do you mean 99 is not a good number? What about 9999? As I >>>>>>>>> explained, >>>>>>>>> I >>>>>>>>> kept it so that we can use mib tools to validate, and I've added >>>>>>>>> detailed >>>>>>>>> notes for the editor. >>>>>>>>> >>>>>>>>>> 8 >>>>>>>>>> > > > 8. Specific MO and TC related comments. >>>>>>>>>> > Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>>> replace >>>>>>>>>> > with things like rsvpP2mp. >>>>>>>>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ok this is closed already then. >>>>>>>>> >>>>>>>>>> 8.2 >>>>>>>>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>>> > The intent is to simply return the octet value of the flags >>>>>>>>>> > field, w/o listing individual bits like "Leaf Information >>>>>>>>>> Required". >>>>>>>>>> > More bits could be defined in the future but the MIB would not >>>>>>>>>> change. >>>>>>>>>> > >>>>>>>>>> > Is that OK? >>>>>>>>>> As far as possible, the meaning of the objects must be made clear. >>>>>>>>>> That will help implementors and operators- users of the MIB. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I added the definition for one existing bit and reference to the >>>>>>>>> IANA >>>>>>>>> registry being created for this flag field. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 8.3 >>>>>>>>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>>> > Depending on the tunnel type, there could be different sizes. >>>>>>>>>> > Future tunnel types could have other sizes that not specified >>>>>>>>>> > today. I was thinking to just give a size >>>>>>>>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>>>>>>>>> > Is that ok? >>>>>>>>>> I see that you have changed the size upper limit to 50. >>>>>>>>>> If the size varies continuously from 0 to 50 the above description >>>>>>>>>> is correct. >>>>>>>>>> Please confirm, explain and cite appropriate reference. If the size >>>>>>>>>> may change in the future that must be stated too. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I changed to discrete sizes for currently defined tunnel types. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 8.4 >>>>>>>>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>>> > > > SYNTAX RowPointer >>>>>>>>>> > > > MAX-ACCESS read-only >>>>>>>>>> > > > STATUS current >>>>>>>>>> > > > DESCRIPTION >>>>>>>>>> > > > "If the tunnel has a corresponding interface, >>>>>>>>>> > > > this is the row pointer to the ifName table." >>>>>>>>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>>>>>>>> > > > want to say this object points to the corresponding >>>>>>>>>> > > > row in the ifTable? >>>>>>>>>> > >>>>>>>>>> > Yes. Fixed. >>>>>>>>>> Not quite. >>>>>>>>>> What is ifName table ? ifName is a columnar object in the >>>>>>>>>> ifXTable. >>>>>>>>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row >>>>>>>>>> in >>>>>>>>>> the >>>>>>>>>> ifXTable table ? Please fix accordingly. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> You're right. Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9. >>>>>>>>>> > > > 9. The Security Considerations section does not follow >>>>>>>>>> > > > the Security Guidelines for IETF MIB Modules >>>>>>>>>> > > > >>>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>>> > > > Please fix. >>>>>>>>>> > >>>>>>>>>> > I was really hoping that it would not have to be that >>>>>>>>>> > tedious. SNMP/MIB secur >>>>>>>>>> ity should be no different from the >>>>>>>>>> > CLI security - once you secure the infrastructure >>>>>>>>>> > then what's more to do? >>>>>>>>>> > >>>>>>>>>> > I'll need more time to work on this. Let me try to address >>>>>>>>>> > the issues in the other mib first and come back to this. >>>>>>>>>> >>>>>>>>>> Please take your time. Looking at examples will help. And let me >>>>>>>>>> know where I can help. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I will need to work on that later. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 10.1 >>>>>>>>>> > > > 10.1 Checking nits according to >>>>>>>>>> > > > http://www.ietf.org/id-info/checklist : >>>>>>>>>> > Should I break them into different lines or just keep them >>>>>>>>>> > as is? Any example of expected indentation if I break the >>>>>>>>>> > lines? >>>>>>>>>> No problems at all to break lines. >>>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>>>>>>>> ::= {l2L3VpnMcastConformance 1} >>>>>>>>>> Should do. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Done. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 10.2 >>>>>>>>>> > > > 10.2 Checking references for intended status: Proposed >>>>>>>>>> Standard >>>>>>>>>> > > > == Missing Reference: 'RFC 7117' is mentioned on line >>>>>>>>>> 76, >>>>>>>>>> > > > but not defined >>>>>>>>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and >>>>>>>>>> other >>>>>>>>>> > I hope I understood and fixed it (removing the space in "RFC >>>>>>>>>> 7117"). >>>>>>>>>> I would recommend that you put it as [RFC6513], [RFC6514], >>>>>>>>>> [RFC7117] >>>>>>>>>> That is simpler to parse. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I see some other documents do not have comma between multiple >>>>>>>>> references >>>>>>>>> so I followed that. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > > > 11. There is another WIP MVPN-MIB in >>>>>>>>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>>>>>>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>>>>>>> > > > Is there a good reason for not merging the 2 >>>>>>>>>> documents? >>>>>>>>>> > > > I have not seen any discussion or explanation on this. >>>>>>>>>> > > > I may have missed it. >>>>>>>>>> > > > Please clarify or, give some pointers. >>>>>>>>>> > >>>>>>>>>> > As mentioned in the introduction: >>>>>>>>>> > >>>>>>>>>> > this memo describes managed objects common to both VPLS >>>>>>>>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>>>>>>>> > in the work and both would reference common >>>>>>>>>> >>>>>>>>>> > objects defined in this MIB. >>>>>>>>>> >>>>>>>>>> OK. So you are saying that this MIB contains core objects that >>>>>>>>>> will be used to manage implementations of various multicast VPN >>>>>>>>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>>>>>>>> you spell it out at the beginning. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes. I thought I did it already: >>>>>>>>> >>>>>>>>> 1. Introduction >>>>>>>>> >>>>>>>>> ... and this memo describes managed objects common to both VPLS >>>>>>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Jeffrey >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Glenn, >>>>>>>>>>> >>>>>>>>>>> Thanks for your comments. I've addressed most of your comments in >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> new revision: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> URL: >>>>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> l2l3-vpn-mcast-mib-03.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Status: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> vpn-mcast-mib/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Htmlized: >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> mcast-mib-03 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Diff: >>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> vpn-mcast-mib-03 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please see below. >>>>>>>>>>> >>>>>>>>>>>> 1. Abstract: >>>>>>>>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>>>>>>>> applications for operations, monitoring and management >>>>>>>>>>>> would be good. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I had thought this would be standard/obvious for all MIB objects - >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> read-write ones are used to control how a device works, and the >>>>>>>>>> read-only >>>>>>>>>> ones are used for monitoring. Do I really need to say it >>>>>>>>>> explicitly? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see RFC 4382 has the following: >>>>>>>>>>> >>>>>>>>>>> This memo defines a portion of the Management Information Base >>>>>>>>>>> (MIB) >>>>>>>>>>> for use with network management protocols in the Internet >>>>>>>>>>> community. >>>>>>>>>>> In particular, it describes managed objects to configure and/or >>>>>>>>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>>>>>>>> Networks on a Multiprotocol Label Switching (MPLS) Label >>>>>>>>>>> Switching >>>>>>>>>>> Router (LSR) supporting this feature. >>>>>>>>>>> >>>>>>>>>>> Is it enough to say something similar? For example: >>>>>>>>>>> >>>>>>>>>>> In particular, it describes common managed objects used to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> configure >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2. Introduction >>>>>>>>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>>>>>>>> appearing for the first time. (PE, VPLS,..) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>>>>>>>> terms that are used, nicely with reference to the protocol >>>>>>>>>>>> documents will improve readability. >>>>>>>>>>>> e.g. >>>>>>>>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As the paragraph alluded to, this MIB needs to be understood in >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> general context of L2/L3 multicast VPN and providing good >>>>>>>>>> explanation >>>>>>>>>> of >>>>>>>>>> the terms is not attempted. The references for the terms are the >>>>>>>>>> the >>>>>>>>>> RFCs >>>>>>>>>> for the relevant technologies. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Having said that, I'll explain PMSI a bit further. >>>>>>>>>>> >>>>>>>>>>>> 2.3 Is there a difference between >>>>>>>>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>>>>>>>> RFC 7117 and RFC 6513/6514" >>>>>>>>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>>>>>>>> and >>>>>>>>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>>>>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>>>>>>>> If these are the same, it will be helpful to stick to the >>>>>>>>>>>> same expression. If these are not the same, the dictinction >>>>>>>>>>>> should be clarified. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>>>> out >>>>>>>>>>> that >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>>>>>>>>> advised to change it accordingly. Looks like I did not change all >>>>>>>>>> the >>>>>>>>>> cases. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" >>>>>>>>>>> so >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll change it back. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3. Summary of MIB Module. >>>>>>>>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>>>>> structure of the MIB, short descriptions of the table(s) >>>>>>>>>>>> including usage of the table(s) for management and/or by >>>>>>>>>>>> other MIB(s). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I had that, but have added one sentence about the only table. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> MIB definitions: >>>>>>>>>>>> 4. MIB syntax checking: >>>>>>>>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I used simpleweb's validation tool but looks like I did not use >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> strictest level of validation. I've now fixed the following issues >>>>>>>>>> and >>>>>>>>>> verified. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> See later question/comments below. >>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: >>>>>>>>>>>> current >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never >>>>>>>>>> used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is >>>>>>>>>> never >>>>>>>>>> used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never >>>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Removed the above unused imports. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>>>>>>>> Wherever possible, provide references for objects used in >>>>>>>>>>>> the MIB. The references will point to specific sections/ >>>>>>>>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>>>>>>>> MIB is being designed. It will greatly improve the readability >>>>>>>>>>>> of the document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Added. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 6. IMPORTS clause >>>>>>>>>>>> MIB modules from which items are imported must be cited and >>>>>>>>>>>> included in the normative references. >>>>>>>>>>>> The conventional style is >>>>>>>>>>>> mplsStdMIB >>>>>>>>>>>> FROM MPLS-TC-STD-MIB -- >>>>>>>>>>>> [RFC3811] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Added. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic >>>>>>>>>>>> errors.) >>>>>>>>>>>> 7.1 CONTACT-INFO >>>>>>>>>>>> Following the conventions (including indentation style) will >>>>>>>>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>>>>> Will be good if it does not overflow into the next page. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>>>>>>>>> sec 4.5 >>>>>>>>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>>>>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>>>>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this >>>>>>>>>>>> note: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>>>>>>>>> sec 4.5 i >>>>>>>>>>>> replace >>>>>>>>>>>> ::= { experimental 99 } -- number to be assigned >>>>>>>>>>>> by >>>>>>>>>>>> ::= { XXX } >>>>>>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove >>>>>>>>>>>> this >>>>>>>>>>>> note >>>>>>>>>>>> will be the subtree under which the module will be >>>>>>>>>>>> registered. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I kept "experimental 99" so that I could continue to use mib tools >>>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> validate; but I added notes for the editor to replace them as you >>>>>>>>>> indicated. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8. Specific MO and TC related comments. >>>>>>>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>>>>>> BGP/MPLS L2 or IP VPN." >>>>>>>>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>>>>>>>> rsvp-p2mp (1), >>>>>>>>>>>> ldp-p2mp (2), >>>>>>>>>>>> pim-asm (3), >>>>>>>>>>>> pim-ssm (4), >>>>>>>>>>>> pim-bidir (5), >>>>>>>>>>>> ingress-replication (6), >>>>>>>>>>>> ldp-mp2mp (7) >>>>>>>>>>>> >>>>>>>>>>>> o Would be nice to align the enumeration labels with the >>>>>>>>>>>> labels in the protocol document RFC 6514 unless there is >>>>>>>>>>>> a good reason for not doing so. (You will have to take >>>>>>>>>>>> care of the smi compilation errors too; '-' is not allowed >>>>>>>>>>>> ). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>>>> replace >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> with things like rsvpP2mp. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Or could/should I just remove the definitions, so that if a new >>>>>>>>>>> type >>>>>>>>>>> is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> defined in the future there is no need to update the MIB? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "An entry in this table corresponds to an PMSI >>>>>>>>>>>> attribute >>>>>>>>>>>> that is advertised/received on this router. >>>>>>>>>>>> For BGP-based signaling (for I-PMSI via >>>>>>>>>>>> auto-discovery >>>>>>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>>>>>> they are just as signaled by BGP (RFC 6514 section >>>>>>>>>>>> 5, >>>>>>>>>>>> 'PMSI Tunnel attribute'). >>>>>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>>>>> they're derived from S-PMSI Join Message >>>>>>>>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>>>>>>>> >>>>>>>>>>>> Note that BGP-based signaling may be used for >>>>>>>>>>>> PIM-MVPN as well." >>>>>>>>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>>>>>>>> o Please give the reference for this Table. >>>>>>>>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>>>>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>>>>>>>> both? >>>>>>>>>>>> Any other pointers? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this >>>>>>>>>>>> is >>>>>>>>>>>> 0. >>>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>>>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>>>>>> I/S-PMSI A-D route." >>>>>>>>>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>>>>>>>> o Please confirm that the above is a complete enumeration of >>>>>>>>>>>> the >>>>>>>>>>>> types of signalling. >>>>>>>>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>>>>>>>> "Leaf Information Required". That is useful information. >>>>>>>>>>>> Please include in the description. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The intent is to simply return the octet value of the flags field, >>>>>>>>>>> w/o >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> listing individual bits like "Leaf Information Required". More bits >>>>>>>>>> could >>>>>>>>>> be defined in the future but the MIB would not change. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Is that OK? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the >>>>>>>>>>>> first >>>>>>>>>>>> four or sixteen octets of this attribute are filled >>>>>>>>>>>> with >>>>>>>>>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the >>>>>>>>>>>> Tunnel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Identifier >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Field in PMSI Tunnel Attribute of the corresponding >>>>>>>>>>>> I/S- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> PMSI >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A-D route." >>>>>>>>>>>> o Check the size specifications. The specs above say it can >>>>>>>>>>>> be >>>>>>>>>>>> all sizes 0..37. That is not clear from the DESCRIPTION >>>>>>>>>>>> clause. >>>>>>>>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>>>>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Identifiers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress >>>>>>>>>>>> Replication,MP2MP. >>>>>>>>>>>> It appears that the sizes (range) for each case will be >>>>>>>>>>>> different. >>>>>>>>>>>> Please clarify that, and if there are discrete sizes, >>>>>>>>>>>> specify >>>>>>>>>>>> accordingly. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Depending on the tunnel type, there could be different sizes. >>>>>>>>>>> Future >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> tunnel types could have other sizes that not specified today. I was >>>>>>>>>> thinking to just give a size range so that it is flexible. Is that >>>>>>>>>> ok? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "If the tunnel exists in some MIB table, this is the >>>>>>>>>>>> row pointer to it." >>>>>>>>>>>> o "some MIB table" : specify which MIB table. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could >>>>>>>>>>> be >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> whatever table that a tunnel may be put into. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> o In what case will the tunnel exist and in what case will it >>>>>>>>>>>> not? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If a device supports mplsTunnelTable and the tunnel is represented >>>>>>>>>>> there, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> then it exists. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> o What will be the behaviour if the above condition is not >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> satisfied? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A null pointer should be given. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "If the tunnel has a corresponding interface, this is >>>>>>>>>>>> the >>>>>>>>>>>> row pointer to the ifName table." >>>>>>>>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want to >>>>>>>>>>>> say >>>>>>>>>>>> this object points to the corresponding row in the >>>>>>>>>>>> ifTable? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes. Fixed. >>>>>>>>>>> >>>>>>>>>>>> o In what case does the TunnelIf exist and in what case will >>>>>>>>>>>> it >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> not? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Some tunnels may not have a corresponding interface. >>>>>>>>>>> >>>>>>>>>>>> o What will be expected if the tunnel does not have a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> corresponding >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> interface? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Null row pointer. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 9. The Security Considerations section does not follow the >>>>>>>>>>>> Security >>>>>>>>>>>> Guidelines for IETF MIB Modules >>>>>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>>>>> Please fix. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was really hoping that it would not have to be that tedious. >>>>>>>>>>> SNMP/MIB >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> security should be no different from the CLI security - once you >>>>>>>>>> secure >>>>>>>>>> the infrastructure then what's more to do? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll need more time to work on this. Let me try to address the >>>>>>>>>>> issues >>>>>>>>>>> in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the other mib first and come back to this. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 10.ID-nits >>>>>>>>>>>> 10.1 Checking nits according to >>>>>>>>>>>> http://www.ietf.org/id-info/checklist >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** There are 4 instances of too long lines in the document, >>>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> longest one >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> being 3 characters in excess of 72. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I fixed some but there still three too long lines: >>>>>>>>>>> >>>>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>>>>>>>> L2L3VpnMcastProviderTunnelType, >>>>>>>>>>> >>>>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= >>>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= >>>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Should I break them into different lines or just keep them as is? >>>>>>>>>>> Any >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> example of expected indentation if I break the lines? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 10.2 Checking references for intended status: Proposed Standard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, >>>>>>>>>>>> but >>>>>>>>>>>> not >>>>>>>>>>>> defined >>>>>>>>>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other > > 2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni : >> Dear Tsunoda, >>> I think that I have addressed all of Glenn's comments in >>> this revision. >> Thanks for addressing the comments. The MIB compiles OK and >> is looking good. It is shaping up well. >> A new set of comments is attached. Please check and do the >> >> needful. >> Glenn >> On 2017/02/21 16:50, Hiroshi Tsunoda wrote: >>> >>> Dear Glenn and BESS WG, >>> >>> I posted a new revision as follows. >>> I think that I have addressed all of Glenn's comments in this revision. >>> >>> In this revision, I have tried to add more detailed explanation >>> throughout the document. >>> Please review and let me know if there are any misunderstanding from >>> technical view points. >>> >>> URL: >>> >>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-06.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-06 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-06 >>> >>> Please see some notes below. >>> >>>> 1. Introduction >>>> >>>> 1.1 >>>> Would be very nice if a short explanations of MVPN and >>>> L2 VPN Multicast were given. With emphasis on the operational >>>> aspects. >>> >>> >>> I have updated Introduction. I hope this update fulfills your >>> requirements. >>> >>>> 1.4 .... there are 2 types of PMSIs .. >>>> >>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>> >>>> >>>> please make these explanations more gentle(complete) to the reader. >>>> Also, give the references where these terms are defined. >>> >>> >>> More gentle explanation and references were added in Terminology >>> section (Sec.1.1). >>> >>>> 3.2 some more text like the following will be good. >>>> L2L3-VPN-MCAST-MIB contains >>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>>> an enumeration of the provider tunnel types and, >>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>>> composed of multiple attributes that depend on the tunnel type and >>>> uniquely identify a tunnel. This table will be used to ... monitor >>>> the tunnels supported by the system at a given point of time (?) >>>> It may also be used in conjunction with XXXX-mib to obtain the >>>> other details of a tunnel by following the row pointer of the >>>> corresponding tunnel's row in this table. >>>> [ Please treat the above as a template and modify the text as >>>> appropriate ..] >>> >>> >>> Fixed in this revision. Please look at Sec. 3 Summary of MIB Module. >>> >>>> 3.3 Since this will become a standard document, please take care of >>>> definitions and notations used in the document. >>>> The notation I/S-PMSI is not defined. If you must use a new >>>> term/notation, define it before use. >>> >>> >>> The notation I/S-PMSI is defined in Sec.1.1 now. >>> >>>> 4.8 >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>> [I-D.ietf-bess-mvpn-mib]." >>>> >>>> >>>> It would seem that each row in this table is an index for a PTA >>>> and may contain pointers to rows in tables of other MIB modules >>>> which may contain more details for the PTA. Is that correct? >>>> Please reword the DESCRIPTION acordingly. >>>> Also see comments in 4.15 >>> >>> >>> I have changed DESCRIPTION as follows. >>> >>> "An entry of this table corresponds with a >>> PMSI Tunnel attribute and is created by a PE router >>> that advertises and receives the attribute. >>> The entry in the table will be referred by other MIB modules >>> which are designed for monitoring and/or configuring >>> both L2 and L3 VPN that support multicast." >>> >>> >>>> 4.10-3 >>>> the phrase UDP-based S-PMSI appears here for the first time. >>>> Somewhere earlier it should be made clear that UDP too may be used >>>> in signaling. >>> >>> >>> In Introduction, I have explained that BGP and UDP are used in signaling. >>> >>>> 4.13 >>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>> >>>>> DESCRIPTION >>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>> field in PMSI Tunnel Attribute of the corresponding >>>>> I/S-PMSI A-D or Leaf A-D route." >>>> >>>> o Does this description cover all the types? If not, then cover all the >>>> types unless there is a good reason to focus only on the above types. >>>> o I/S-PMSI: unexplained notation. >>> >>> >>> Fixed. >>> >>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>> >>>> Please indicate that the first column gives the size >>> >>> >>> I have updated the table as follows. >>> >>> Size (in octets) l2L3VpnMcastPmsiTunnelAttributeType >>> IPv4 IPv6 (tunneling technology) >>> -------------------------------------------------- >>> 0 0 noTunnelId (No tunnel information present) >>> 12 24 rsvpP2mp (RSVP-TE P2MP LSP) >>> 17 29 ldpP2mp (mLDP P2MP LSP) >>> 8 32 pimSsm (PIM-SSM Tree) >>> >>>>> 8/32 pimAsm >>>>> 8/32 pimSsm >>>>> 8/32 pimBidir >>>>> 4/16 ingressReplication >>>> >>>> >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>> 8 or 32 octets of this attribute are filled with >>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>> Identifier field in PMSI Tunnel Attribute of the >>>>> corresponding I/S-PMSI A-D route." >>>> >>>> >>>> A more generous description of the AttributeID would be good. All the >>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>>> summary would be very nice. >>> >>> >>> Fixed. I have summarized Section 5 of RFC 6514 here. >>> >>>> 4.15 >>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>> >>>>> SYNTAX RowPointer >>>>> DESCRIPTION >>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>> pointer is null." >>>> >>>> I am having problems understanding this. Will help if you can give >>>> a use case of how this will be used. As of now the intent is unclear. >>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>> pointer to a specific row in a specific table. If this is a pointer to >>>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >>> >>> >>> I have changed DESCRIPTION as follows. >>> >>> "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId >>> may be represented as an entry in other table, e.g, >>> mplsTunnelTable [RFC3812]. If there is such entry, >>> this object will point to the row pertaining to the entry. >>> Otherwise, the pointer is null." >>> >>>> 5.0 >>>>> >>>>> 5. Security Considerations >>>> >>>> TBD >>> >>> >>> I have rewritten this part according to the guideline described in >>> RFC4181 Sec.3.4. >>> >>>> 6.0 >>>>> >>>>> 6. IANA Considerations >>>> >>>> >>>>> IANA is requested to root MIB objects in the MIB module contained in >>>>> this document under the mib-2 subtree. >>>> >>>> >>>> Please Note: >>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to >>>> put the definitions in a separate MIB module. That would mean a >>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>> TC can be carried out by some entity ( IANA or, some WG or, whoever is >>>> responsible for maintaining the TC) independent of other MIB objects. >>>> If that is the intent you will need to define 2 mib modules and you >>>> will >>>> need to request 2 branches in the mib-2 subtree- one for the module >>>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>> >>> >>> Now, this document defines following two MIB modules: >>> - the module containing the L2L3VpnMcastProviderTunnelType TC >>> - the module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>> >>> -- tsuno >>> >>> 2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni : >>>> >>>> Dear Tsunoda, >>>>> >>>>> I will submit the next version within three days. >>>>> The next versionbwill address all of remained your >>>>> comments. >>>> >>>> Great! Looking forward to the revised draft. >>>> >>>> Glenn >>>> >>>> On 2017/02/18 16:30, Hiroshi Tsunoda wrote: >>>>> >>>>> >>>>> Dear Glenn, >>>>> >>>>> I am sorry I kept you waiting so long for the revised version, I have >>>>> been side tracked by other things. >>>>> I will submit the next version within three days. The next version >>>>> will address all of remained your comments. >>>>> The summary of remained TODOs is shown below. Please wait a little >>>>> more >>>>> time. >>>>> ------------- >>>>> 1. Add general explanation about MVPN, multicast in VPLS >>>>> Define and explain some technical terms, such as PIM-MVPN, >>>>> UDP-based S-PMSI etc. >>>>> >>>>> 2. Revise summary of the MIB module >>>>> >>>>> 3. Revise MIB definition >>>>> a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable >>>>> b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to >>>>> cover all cases. >>>>> c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId >>>>> d. Fix the description of l2L3VpnMcastPmsiTunnelPointer >>>>> >>>>> 4. Split the MIB module into two separate modules. >>>>> >>>>> 5. Revise security considertations >>>>> ------------- >>>>> >>>>> P.S. Update of mvpn-mib-02 will be submitted by the end of this month. >>>>> >>>>> Best regards, >>>>> >>>>> -- tsuno >>>>> >>>>> 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : >>>>>> >>>>>> >>>>>> Hi Tsunoda, >>>>>>> >>>>>>> >>>>>>> I have started to volunteer to help to move this document forward. >>>>>> >>>>>> >>>>>> Great! >>>>>>> >>>>>>> >>>>>>> I posted a new revision and addressed all editorial things in >>>>>>> that revision. >>>>>> >>>>>> >>>>>> Got this. Looks good. >>>>>>> >>>>>>> >>>>>>> Please give me some more time for revising other parts, >>>>>> >>>>>> >>>>>> No problems. Will be looking forward to the revised document. >>>>>> >>>>>> Glenn >>>>>> >>>>>> >>>>>> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dear Glenn, >>>>>>> >>>>>>> Thanks for your careful review and detailed comments/suggestions. >>>>>>> I have started to volunteer to help to move this document forward. >>>>>>> I posted a new revision and addressed all editorial things in that >>>>>>> revision. >>>>>>> Please give me some more time for revising other parts, >>>>>>> in order to be familiar with the context of the original and related >>>>>>> documents. >>>>>>> >>>>>>> URL: >>>>>>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>>> Htmlized: >>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 >>>>>>> Diff: >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>>> >>>>>>> Please see some notes below. >>>>>>> >>>>>>>> 0. Abstract. >>>>>>>> 0.1. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> it describes common managed objects used to configure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>>> >>>>>>>> There are no writable MOs in this MIB. So it does not look >>>>>>>> as though this MIB will be used for configuration directly. >>>>>>>> The use case scenario for monitoring is not clear, either. >>>>>>>> It appears that the MIB module(s) in this document will be >>>>>>>> used by other modules which are designed for monitoring and/ >>>>>>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>>>>>> wording. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 1. Introduction >>>>>>>> >>>>>>>> 1.1 >>>>>>>> Would be very nice if a short explanations of MVPN and >>>>>>>> L2 VPN Multicast were given. With emphasis on the operational >>>>>>>> aspects. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise. >>>>>>> >>>>>>>> 1.2 >>>>>>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>>>>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 1.3 >>>>>>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 1.4 .... there are 2 types of PMSIs .. >>>>>>>> >>>>>>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>>>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> please make these explanations more gentle(complete) to the >>>>>>>> reader. >>>>>>>> Also, give the references where these terms are defined. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise. >>>>>>> >>>>>>>> 3. Summary of MIB Module >>>>>>>> 3.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Typo: I/S-PMSI, (see 3.3 below). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 3.2 some more text like the following will be good. >>>>>>>> L2L3-VPN-MCAST-MIB contains >>>>>>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that >>>>>>>> provides >>>>>>>> an enumeration of the provider tunnel types and, >>>>>>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index >>>>>>>> is >>>>>>>> composed of multiple attributes that depend on the tunnel type >>>>>>>> and >>>>>>>> uniquely identify a tunnel. This table will be used to ... >>>>>>>> monitor >>>>>>>> the tunnels supported by the system at a given point of time >>>>>>>> (?) >>>>>>>> It may also be used in conjunction with XXXX-mib to obtain the >>>>>>>> other details of a tunnel by following the row pointer of the >>>>>>>> corresponding tunnel's row in this table. >>>>>>>> [ Please treat the above as a template and modify the text as >>>>>>>> appropriate ..] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise this point. >>>>>>> >>>>>>>> 3.3 Since this will become a standard document, please take care of >>>>>>>> definitions and notations used in the document. >>>>>>>> The notation I/S-PMSI is not defined. If you must use a new >>>>>>>> term/notation, define it before use. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise this point. >>>>>>> >>>>>>>> 4. Definitions >>>>>>>> >>>>>>>>> IMPORTS >>>>>>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4.1 Since this is not a Experimental MIB do not import use >>>>>>>> experimental. >>>>>>>> It is good practice to keep the draft in the as "close to final >>>>>>>> form" >>>>>>>> as possible. (See below) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please update this date. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Updated. >>>>>>> >>>>>>>> 4.3 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> DESCRIPTION >>>>>>>>> "This MIB contains common managed object definitions for >>>>>>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>>>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Would be good if you could rearrange the text. Something like >>>>>>>> "This MIB module will be used for managing multicast in Layer 2 >>>>>>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>>>>>> Or, even better >>>>>>>> "This MIB module will be used by other MIB modules designed for >>>>>>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>>>>>> [RFC6513], [RFC6514] >>>>>>>> Or, a combination of both, depending on the envisaged use case >>>>>>>> scenarios. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Rearranged the text along with your comment. >>>>>>> >>>>>>>> 4.4 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ::= { experimental 999 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please >>>>>>>> o Replace "experimental" by the branch where this mib module >>>>>>>> will >>>>>>>> be anchored; that is a decision that the WG will take, >>>>>>>> probably. >>>>>>>> o Import the branch in the IMPORTS statement >>>>>>>> [ In the IANA Considerations section a branch in the mib-2 >>>>>>>> subtree >>>>>>>> is requested. In that case this must be >>>>>>>> ::= { mib-2 XXX } >>>>>>>> ] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.5 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Please also remove the ", experimental" text from earlier >>>>>>>>> -- IMPORTS section. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Remove these instructions. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Removed. >>>>>>> >>>>>>>> 4.5.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Texual convention >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Typo: -- Textual convention >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.6 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>>>> DESCRIPTION >>>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>>>>>> in future RFCs, and those will be allowed as >>>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The part >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Additional types may be defined >>>>>>>>> in future RFCs, and those will be allowed as >>>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> may be deleted. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Deleted. >>>>>>> >>>>>>>> 4.7 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Top level components of this MIB. >>>>>>>>> -- tables, scalars, conformance information >>>>>>>>> >>>>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>>>> >>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> should be >>>>>>>> >>>>>>>> -- Top level components of this MIB. >>>>>>>> >>>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects >>>>>>>> 1 >>>>>>>> } >>>>>>>> >>>>>>>> -- tables, scalars, conformance information >>>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.8 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>> STATUS current >>>>>>>>> DESCRIPTION >>>>>>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>>>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>>>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>>>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>>>>>> [I-D.ietf-bess-mvpn-mib]." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It would seem that each row in this table is an index for a PTA >>>>>>>> and may contain pointers to rows in tables of other MIB modules >>>>>>>> which may contain more details for the PTA. Is that correct? >>>>>>>> Please reword the DESCRIPTION acordingly. >>>>>>>> Also see comments in 4.15 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. I need some more time to understand the original context. >>>>>>> >>>>>>>> 4.9 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>>> "An entry in this table corresponds to a PTA >>>>>>>>> that is advertised/received on this router. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >>>>>>>> so "entry in this table" does not fit in well. >>>>>>>> A rewording like >>>>>>>> "A conceptual row corresponding to a PTA >>>>>>>> that is advertised/received on this router. >>>>>>>> .... >>>>>>>> would be better. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.10 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>>> they are just as signaled by BGP. >>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>> they're derived from the S-PMSI Join Message. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Note that BGP-based signaling may be used for >>>>>>>>> PIM-MVPN as well." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Is the signaling mechanism important here? If it isn't then the >>>>>>>> above part of the description is redundant. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Removed the above part. >>>>>>> >>>>>>>> 4.10-2 >>>>>>>> PIM-MVPN appears for the first time. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Defined the notation of PIM-MVPM as follows >>>>>>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>>>>>> However, I think that some descriptions may be required for this >>>>>>> somewhere in this document. That is TBD. >>>>>>> >>>>>>>> 4.10-3 >>>>>>>> the phrase UDP-based S-PMSI appears here for the first time. >>>>>>>> Somewhere earlier it should be made clear that UDP too may be used >>>>>>>> in signaling. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. >>>>>>> >>>>>>>> 4.11 >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "this" is unclear. >>>>>>>> Something like "the value of this object is 0" will be better. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>>> More bits may be defined in the future and >>>>>>>>> they will be registered in IANA Registry xxxx." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This part is probably redundant. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Removed. >>>>>>> >>>>>>>> 4.12 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>>>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>>>>>> -- and remove this note. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Look at the comments in 6.0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above description ("IANA Registry xxxx.") was removed, >>>>>>> thus this part was also removed. >>>>>>> >>>>>>>> 4.13 >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> DESCRIPTION >>>>>>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>>> I/S-PMSI A-D or Leaf A-D route." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> o Does this description cover all the types? If not, then cover all >>>>>>>> the >>>>>>>> types unless there is a good reason to focus only on the above >>>>>>>> types. >>>>>>>> o I/S-PMSI: unexplained notation. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to address this point. >>>>>>> >>>>>>>> 4.14 >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It appears that you also allow sizes "16" and "32"; these must be >>>>>>>> included. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please indicate that the first column gives the size >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I made a change as follows. >>>>>>> >>>>>>> Size l2L3VpnMcastPmsiTunnelAttributeType >>>>>>> (IPv4/IPv6) >>>>>>> -------------------------------------------------- >>>>>>> (snip) >>>>>>> 8/32 pimAsm >>>>>>> (snip) >>>>>>> >>>>>>> Is this OK? >>>>>>> >>>>>>>>> 8/32 pimAsm >>>>>>>>> 8/32 pimSsm >>>>>>>>> 8/32 pimBidir >>>>>>>>> 4/16 ingressReplication >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>>>>> 8 or 32 octets of this attribute are filled with >>>>>>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>>>>>> Identifier field in PMSI Tunnel Attribute of the >>>>>>>>> corresponding I/S-PMSI A-D route." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A more generous description of the AttributeID would be good. All >>>>>>>> the >>>>>>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A >>>>>>>> simple >>>>>>>> summary would be very nice. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. Please give me some more time to revise this point. >>>>>>> >>>>>>>> 4.15 >>>>>>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> SYNTAX RowPointer >>>>>>>>> DESCRIPTION >>>>>>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>>>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>>>>>> pointer is null." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am having problems understanding this. Will help if you can give >>>>>>>> a use case of how this will be used. As of now the intent is >>>>>>>> unclear. >>>>>>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>>>>>> pointer to a specific row in a specific table. If this is a pointer >>>>>>>> to >>>>>>>> a row in the mplsTunnelTable spell it out clearly and >>>>>>>> unambiguously. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. I will need some more time to understand the original context. >>>>>>> >>>>>>>> 4.16 >>>>>>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>> DESCRIPTION >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> "If the tunnel has a corresponding interface, this is the >>>>>>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This description is better. Would be even better with >>>>>>>> "If the tunnel has a corresponding entry in the ifXTable, >>>>>>>> this object will point to the row pertaining to the entry >>>>>>>> ..... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 4.17 >>>>>>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> DESCRIPTION >>>>>>>>> "Support of these object is not required." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Support of these objects is not required. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 5.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 5. Security Considerations >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> TBD >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Still TBD. >>>>>>> >>>>>>>> 6.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 6. IANA Considerations >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> IANA is requested to root MIB objects in the MIB module contained >>>>>>>>> in >>>>>>>>> this document under the mib-2 subtree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please Note: >>>>>>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you >>>>>>>> need >>>>>>>> to >>>>>>>> put the definitions in a separate MIB module. That would mean a >>>>>>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>>>>>> TC can be carried out by some entity ( IANA or, some WG or, >>>>>>>> whoever >>>>>>>> is >>>>>>>> responsible for maintaining the TC) independent of other MIB >>>>>>>> objects. >>>>>>>> If that is the intent you will need to define 2 mib modules and >>>>>>>> you >>>>>>>> will >>>>>>>> need to request 2 branches in the mib-2 subtree- one for the >>>>>>>> module >>>>>>>> containing the L2L3VpnMcastProviderTunnelType TC and another for >>>>>>>> the >>>>>>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD. I will address this point in the next revision. >>>>>>> >>>>>>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Jeffrey, >>>>>>>> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >>>>>>>> document. It took me some time to do this review. But now here it >>>>>>>> is. A (near complete) review of >>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>>> is >>>>>>>> attached. Hope this helps. >>>>>>>> I understand that the Security Considerations section is TBD. >>>>>>>> >>>>>>>> Glenn >>>>>>>> >>>>>>>> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Glenn, >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>>>>>>>>> Sent: Sunday, May 08, 2016 11:02 AM >>>>>>>>>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>>>>>>>>> ; EXT - thomas.morin@orange.com >>>>>>>>>> >>>>>>>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>>>>>>> Vigoureux >>>>>>>>>> ; bess@ietf.org; mib-doctors@ietf.org >>>>>>>>>> Subject: Re: [bess] MIBDoc review of >>>>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>>>>>>>> 02.txt >>>>>>>>>> >>>>>>>>>> Jeffrey, >>>>>>>>>> > Thanks for your comments. I've addressed most of your comments >>>>>>>>>> > in the new revision: >>>>>>>>>> Thanks for your cooperation. I will need at least one more revision >>>>>>>>>> with the following comments/recommendations addressed before I will >>>>>>>>>> be able to complete the detailed review. In the following the >>>>>>>>>> numbers >>>>>>>>>> refer to the issue numbers in the initial review. The issues that >>>>>>>>>> are >>>>>>>>>> addressed and closed are not listed. For brevity, the issue >>>>>>>>>> descriptions have been trimmed. In case of doubts please look at >>>>>>>>>> the >>>>>>>>>> response mail appended below. >>>>>>>>>> Hope this helps. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for your detailed comments/suggestions. I posted a new >>>>>>>>> revision >>>>>>>>> with the following issues addressed. >>>>>>>>> >>>>>>>>> URL: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>>>> Status: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>>>>> Htmlized: >>>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>>> Diff: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>>> >>>>>>>>> Please see some notes below. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Glenn >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> Comments: >>>>>>>>>> >>>>>>>>>> 1.1 >>>>>>>>>> > I had thought this would be standard/obvious for all MIB >>>>>>>>>> objects >>>>>>>>>> - >>>>>>>>>> We will comeback to this time and again, whereever possible make >>>>>>>>>> matters explicit and clear. That will help. >>>>>>>>>> > Is it enough to say something similar? For example: >>>>>>>>>> > In particular, it describes common managed objects used >>>>>>>>>> > to configure and/or monitor both L2 and L3 VPN >>>>>>>>>> Multicast. >>>>>>>>>> That is better. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I take it that this is already closed in -03 revision. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2.2 >>>>>>>>>> > Having said that, I'll explain PMSI a bit further. >>>>>>>>>> PMSI explanation is good. >>>>>>>>>> Please use the same style/format for I-PMSI and S-PMSI. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think -03 revision already use the same style/format for I-PMSI >>>>>>>>> and >>>>>>>>> S-PMSI? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2.3 >>>>>>>>>> > No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>>> out >>>>>>>>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs >>>>>>>>>> and >>>>>>>>>> I >>>>>>>>>> > was advised to change it accordingly. Looks like I did not >>>>>>>>>> change >>>>>>>>>> all >>>>>>>>>> > the cases. >>>>>>>>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 >>>>>>>>>> VPN" >>>>>>>>>> so >>>>>>>>>> > I'll change it back. >>>>>>>>>> No problems. just make sure that the same expression/notation is >>>>>>>>>> used >>>>>>>>>> uniformly. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I take it that this is also addressed in -03 already. >>>>>>>>> >>>>>>>>>> 3. >>>>>>>>>> > > > 3. Summary of MIB Module. >>>>>>>>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>>> > > > structure of the MIB, short descriptions of the >>>>>>>>>> table(s) >>>>>>>>>> > > > including usage of the table(s) for management and/or >>>>>>>>>> by >>>>>>>>>> > > > other MIB(s). >>>>>>>>>> > >>>>>>>>>> > I had that, but have added one sentence about the only table. >>>>>>>>>> A sentence or two about the textual convention will be good. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Added in -04. >>>>>>>>> >>>>>>>>>> > > > 4. MIB syntax checking: >>>>>>>>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>>> > >>>>>>>>>> > I used simpleweb's validation tool but looks like I did not use >>>>>>>>>> the >>>>>>>>>> > strictest level of validation. I've now fixed the following >>>>>>>>>> issues >>>>>>>>>> and >>>>>>>>>> > verified. >>>>>>>>>> Good. >>>>>>>>>> 5. >>>>>>>>>> > > > >>>>>>>>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses >>>>>>>>>> liberally. >>>>>>>>>> > > > Wherever possible, provide references for objects used >>>>>>>>>> in >>>>>>>>>> > > > the MIB. The references will point to specific sections/ >>>>>>>>>> > > > sub-sections of the RFCs defining the protocol for which >>>>>>>>>> the >>>>>>>>>> > > > MIB is being designed. It will greatly improve the >>>>>>>>>> readability >>>>>>>>>> > > > of the document. >>>>>>>>>> > >>>>>>>>>> > Added. >>>>>>>>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>>>>>>>> improve on it. >>>>>>>>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>>>>>>>> clause move it to a separate REFERENCE clause. The addition of the >>>>>>>>>> section number is an improvement. It is friendlier to the reader. >>>>>>>>>> Note. Same comment for other OBJECTs too. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Oh I missed that. All fixed. >>>>>>>>> >>>>>>>>>> 7.1 >>>>>>>>>> > > > 7.1 CONTACT-INFO >>>>>>>>>> > > > Following the conventions (including indentation style) >>>>>>>>>> will >>>>>>>>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>>> > > > Will be good if it does not overflow into the next >>>>>>>>>> page. >>>>>>>>>> > >>>>>>>>>> > Fixed. >>>>>>>>>> The format is OK. The Postal address etc., need not have been >>>>>>>>>> deleted. Please put the complete contact information as in the >>>>>>>>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> 7.3 >>>>>>>>>> > I kept "experimental 99" so that I could continue to use mib >>>>>>>>>> tools >>>>>>>>>> > to validate; but I added notes for the editor to replace them as >>>>>>>>>> you >>>>>>>>>> > indicated. >>>>>>>>>> Use of "experimental 99" is not recommended. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Do you mean 99 is not a good number? What about 9999? As I >>>>>>>>> explained, >>>>>>>>> I >>>>>>>>> kept it so that we can use mib tools to validate, and I've added >>>>>>>>> detailed >>>>>>>>> notes for the editor. >>>>>>>>> >>>>>>>>>> 8 >>>>>>>>>> > > > 8. Specific MO and TC related comments. >>>>>>>>>> > Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>>> replace >>>>>>>>>> > with things like rsvpP2mp. >>>>>>>>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ok this is closed already then. >>>>>>>>> >>>>>>>>>> 8.2 >>>>>>>>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>>> > The intent is to simply return the octet value of the flags >>>>>>>>>> > field, w/o listing individual bits like "Leaf Information >>>>>>>>>> Required". >>>>>>>>>> > More bits could be defined in the future but the MIB would not >>>>>>>>>> change. >>>>>>>>>> > >>>>>>>>>> > Is that OK? >>>>>>>>>> As far as possible, the meaning of the objects must be made clear. >>>>>>>>>> That will help implementors and operators- users of the MIB. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I added the definition for one existing bit and reference to the >>>>>>>>> IANA >>>>>>>>> registry being created for this flag field. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 8.3 >>>>>>>>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>>> > Depending on the tunnel type, there could be different sizes. >>>>>>>>>> > Future tunnel types could have other sizes that not specified >>>>>>>>>> > today. I was thinking to just give a size >>>>>>>>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>>>>>>>>> > Is that ok? >>>>>>>>>> I see that you have changed the size upper limit to 50. >>>>>>>>>> If the size varies continuously from 0 to 50 the above description >>>>>>>>>> is correct. >>>>>>>>>> Please confirm, explain and cite appropriate reference. If the size >>>>>>>>>> may change in the future that must be stated too. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I changed to discrete sizes for currently defined tunnel types. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 8.4 >>>>>>>>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>>> > > > SYNTAX RowPointer >>>>>>>>>> > > > MAX-ACCESS read-only >>>>>>>>>> > > > STATUS current >>>>>>>>>> > > > DESCRIPTION >>>>>>>>>> > > > "If the tunnel has a corresponding interface, >>>>>>>>>> > > > this is the row pointer to the ifName table." >>>>>>>>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>>>>>>>> > > > want to say this object points to the corresponding >>>>>>>>>> > > > row in the ifTable? >>>>>>>>>> > >>>>>>>>>> > Yes. Fixed. >>>>>>>>>> Not quite. >>>>>>>>>> What is ifName table ? ifName is a columnar object in the >>>>>>>>>> ifXTable. >>>>>>>>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row >>>>>>>>>> in >>>>>>>>>> the >>>>>>>>>> ifXTable table ? Please fix accordingly. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> You're right. Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9. >>>>>>>>>> > > > 9. The Security Considerations section does not follow >>>>>>>>>> > > > the Security Guidelines for IETF MIB Modules >>>>>>>>>> > > > >>>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>>> > > > Please fix. >>>>>>>>>> > >>>>>>>>>> > I was really hoping that it would not have to be that >>>>>>>>>> > tedious. SNMP/MIB secur >>>>>>>>>> ity should be no different from the >>>>>>>>>> > CLI security - once you secure the infrastructure >>>>>>>>>> > then what's more to do? >>>>>>>>>> > >>>>>>>>>> > I'll need more time to work on this. Let me try to address >>>>>>>>>> > the issues in the other mib first and come back to this. >>>>>>>>>> >>>>>>>>>> Please take your time. Looking at examples will help. And let me >>>>>>>>>> know where I can help. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I will need to work on that later. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 10.1 >>>>>>>>>> > > > 10.1 Checking nits according to >>>>>>>>>> > > > http://www.ietf.org/id-info/checklist : >>>>>>>>>> > Should I break them into different lines or just keep them >>>>>>>>>> > as is? Any example of expected indentation if I break the >>>>>>>>>> > lines? >>>>>>>>>> No problems at all to break lines. >>>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>>>>>>>> ::= {l2L3VpnMcastConformance 1} >>>>>>>>>> Should do. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Done. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 10.2 >>>>>>>>>> > > > 10.2 Checking references for intended status: Proposed >>>>>>>>>> Standard >>>>>>>>>> > > > == Missing Reference: 'RFC 7117' is mentioned on line >>>>>>>>>> 76, >>>>>>>>>> > > > but not defined >>>>>>>>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and >>>>>>>>>> other >>>>>>>>>> > I hope I understood and fixed it (removing the space in "RFC >>>>>>>>>> 7117"). >>>>>>>>>> I would recommend that you put it as [RFC6513], [RFC6514], >>>>>>>>>> [RFC7117] >>>>>>>>>> That is simpler to parse. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I see some other documents do not have comma between multiple >>>>>>>>> references >>>>>>>>> so I followed that. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > > > 11. There is another WIP MVPN-MIB in >>>>>>>>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>>>>>>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>>>>>>> > > > Is there a good reason for not merging the 2 >>>>>>>>>> documents? >>>>>>>>>> > > > I have not seen any discussion or explanation on this. >>>>>>>>>> > > > I may have missed it. >>>>>>>>>> > > > Please clarify or, give some pointers. >>>>>>>>>> > >>>>>>>>>> > As mentioned in the introduction: >>>>>>>>>> > >>>>>>>>>> > this memo describes managed objects common to both VPLS >>>>>>>>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>>>>>>>> > in the work and both would reference common >>>>>>>>>> >>>>>>>>>> > objects defined in this MIB. >>>>>>>>>> >>>>>>>>>> OK. So you are saying that this MIB contains core objects that >>>>>>>>>> will be used to manage implementations of various multicast VPN >>>>>>>>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>>>>>>>> you spell it out at the beginning. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes. I thought I did it already: >>>>>>>>> >>>>>>>>> 1. Introduction >>>>>>>>> >>>>>>>>> ... and this memo describes managed objects common to both VPLS >>>>>>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Jeffrey >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Glenn, >>>>>>>>>>> >>>>>>>>>>> Thanks for your comments. I've addressed most of your comments in >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> new revision: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> URL: >>>>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> l2l3-vpn-mcast-mib-03.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Status: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> vpn-mcast-mib/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Htmlized: >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> mcast-mib-03 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Diff: >>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> vpn-mcast-mib-03 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please see below. >>>>>>>>>>> >>>>>>>>>>>> 1. Abstract: >>>>>>>>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>>>>>>>> applications for operations, monitoring and management >>>>>>>>>>>> would be good. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I had thought this would be standard/obvious for all MIB objects - >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> read-write ones are used to control how a device works, and the >>>>>>>>>> read-only >>>>>>>>>> ones are used for monitoring. Do I really need to say it >>>>>>>>>> explicitly? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see RFC 4382 has the following: >>>>>>>>>>> >>>>>>>>>>> This memo defines a portion of the Management Information Base >>>>>>>>>>> (MIB) >>>>>>>>>>> for use with network management protocols in the Internet >>>>>>>>>>> community. >>>>>>>>>>> In particular, it describes managed objects to configure and/or >>>>>>>>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>>>>>>>> Networks on a Multiprotocol Label Switching (MPLS) Label >>>>>>>>>>> Switching >>>>>>>>>>> Router (LSR) supporting this feature. >>>>>>>>>>> >>>>>>>>>>> Is it enough to say something similar? For example: >>>>>>>>>>> >>>>>>>>>>> In particular, it describes common managed objects used to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> configure >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2. Introduction >>>>>>>>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>>>>>>>> appearing for the first time. (PE, VPLS,..) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>>>>>>>> terms that are used, nicely with reference to the protocol >>>>>>>>>>>> documents will improve readability. >>>>>>>>>>>> e.g. >>>>>>>>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As the paragraph alluded to, this MIB needs to be understood in >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> general context of L2/L3 multicast VPN and providing good >>>>>>>>>> explanation >>>>>>>>>> of >>>>>>>>>> the terms is not attempted. The references for the terms are the >>>>>>>>>> the >>>>>>>>>> RFCs >>>>>>>>>> for the relevant technologies. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Having said that, I'll explain PMSI a bit further. >>>>>>>>>>> >>>>>>>>>>>> 2.3 Is there a difference between >>>>>>>>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>>>>>>>> RFC 7117 and RFC 6513/6514" >>>>>>>>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>>>>>>>> and >>>>>>>>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>>>>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>>>>>>>> If these are the same, it will be helpful to stick to the >>>>>>>>>>>> same expression. If these are not the same, the dictinction >>>>>>>>>>>> should be clarified. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>>>> out >>>>>>>>>>> that >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>>>>>>>>> advised to change it accordingly. Looks like I did not change all >>>>>>>>>> the >>>>>>>>>> cases. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" >>>>>>>>>>> so >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll change it back. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3. Summary of MIB Module. >>>>>>>>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>>>>> structure of the MIB, short descriptions of the table(s) >>>>>>>>>>>> including usage of the table(s) for management and/or by >>>>>>>>>>>> other MIB(s). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I had that, but have added one sentence about the only table. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> MIB definitions: >>>>>>>>>>>> 4. MIB syntax checking: >>>>>>>>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I used simpleweb's validation tool but looks like I did not use >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> strictest level of validation. I've now fixed the following issues >>>>>>>>>> and >>>>>>>>>> verified. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: >>>>>>>>>>>> named >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> See later question/comments below. >>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: >>>>>>>>>>>> current >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never >>>>>>>>>> used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is >>>>>>>>>> never >>>>>>>>>> used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>>> identifier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never >>>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Removed the above unused imports. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>>>>>>>> Wherever possible, provide references for objects used in >>>>>>>>>>>> the MIB. The references will point to specific sections/ >>>>>>>>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>>>>>>>> MIB is being designed. It will greatly improve the readability >>>>>>>>>>>> of the document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Added. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 6. IMPORTS clause >>>>>>>>>>>> MIB modules from which items are imported must be cited and >>>>>>>>>>>> included in the normative references. >>>>>>>>>>>> The conventional style is >>>>>>>>>>>> mplsStdMIB >>>>>>>>>>>> FROM MPLS-TC-STD-MIB -- >>>>>>>>>>>> [RFC3811] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Added. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic >>>>>>>>>>>> errors.) >>>>>>>>>>>> 7.1 CONTACT-INFO >>>>>>>>>>>> Following the conventions (including indentation style) will >>>>>>>>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>>>>> Will be good if it does not overflow into the next page. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>>>>>>>>> sec 4.5 >>>>>>>>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>>>>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>>>>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this >>>>>>>>>>>> note: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>>>>>>>>> sec 4.5 i >>>>>>>>>>>> replace >>>>>>>>>>>> ::= { experimental 99 } -- number to be assigned >>>>>>>>>>>> by >>>>>>>>>>>> ::= { XXX } >>>>>>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove >>>>>>>>>>>> this >>>>>>>>>>>> note >>>>>>>>>>>> will be the subtree under which the module will be >>>>>>>>>>>> registered. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I kept "experimental 99" so that I could continue to use mib tools >>>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> validate; but I added notes for the editor to replace them as you >>>>>>>>>> indicated. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8. Specific MO and TC related comments. >>>>>>>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>>>>>> BGP/MPLS L2 or IP VPN." >>>>>>>>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>>>>>>>> rsvp-p2mp (1), >>>>>>>>>>>> ldp-p2mp (2), >>>>>>>>>>>> pim-asm (3), >>>>>>>>>>>> pim-ssm (4), >>>>>>>>>>>> pim-bidir (5), >>>>>>>>>>>> ingress-replication (6), >>>>>>>>>>>> ldp-mp2mp (7) >>>>>>>>>>>> >>>>>>>>>>>> o Would be nice to align the enumeration labels with the >>>>>>>>>>>> labels in the protocol document RFC 6514 unless there is >>>>>>>>>>>> a good reason for not doing so. (You will have to take >>>>>>>>>>>> care of the smi compilation errors too; '-' is not allowed >>>>>>>>>>>> ). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>>>> replace >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> with things like rsvpP2mp. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Or could/should I just remove the definitions, so that if a new >>>>>>>>>>> type >>>>>>>>>>> is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> defined in the future there is no need to update the MIB? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "An entry in this table corresponds to an PMSI >>>>>>>>>>>> attribute >>>>>>>>>>>> that is advertised/received on this router. >>>>>>>>>>>> For BGP-based signaling (for I-PMSI via >>>>>>>>>>>> auto-discovery >>>>>>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>>>>>> they are just as signaled by BGP (RFC 6514 section >>>>>>>>>>>> 5, >>>>>>>>>>>> 'PMSI Tunnel attribute'). >>>>>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>>>>> they're derived from S-PMSI Join Message >>>>>>>>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>>>>>>>> >>>>>>>>>>>> Note that BGP-based signaling may be used for >>>>>>>>>>>> PIM-MVPN as well." >>>>>>>>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>>>>>>>> o Please give the reference for this Table. >>>>>>>>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>>>>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>>>>>>>> both? >>>>>>>>>>>> Any other pointers? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this >>>>>>>>>>>> is >>>>>>>>>>>> 0. >>>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>>>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>>>>>> I/S-PMSI A-D route." >>>>>>>>>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>>>>>>>> o Please confirm that the above is a complete enumeration of >>>>>>>>>>>> the >>>>>>>>>>>> types of signalling. >>>>>>>>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>>>>>>>> "Leaf Information Required". That is useful information. >>>>>>>>>>>> Please include in the description. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The intent is to simply return the octet value of the flags field, >>>>>>>>>>> w/o >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> listing individual bits like "Leaf Information Required". More bits >>>>>>>>>> could >>>>>>>>>> be defined in the future but the MIB would not change. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Is that OK? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the >>>>>>>>>>>> first >>>>>>>>>>>> four or sixteen octets of this attribute are filled >>>>>>>>>>>> with >>>>>>>>>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the >>>>>>>>>>>> Tunnel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Identifier >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Field in PMSI Tunnel Attribute of the corresponding >>>>>>>>>>>> I/S- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> PMSI >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A-D route." >>>>>>>>>>>> o Check the size specifications. The specs above say it can >>>>>>>>>>>> be >>>>>>>>>>>> all sizes 0..37. That is not clear from the DESCRIPTION >>>>>>>>>>>> clause. >>>>>>>>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>>>>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Identifiers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress >>>>>>>>>>>> Replication,MP2MP. >>>>>>>>>>>> It appears that the sizes (range) for each case will be >>>>>>>>>>>> different. >>>>>>>>>>>> Please clarify that, and if there are discrete sizes, >>>>>>>>>>>> specify >>>>>>>>>>>> accordingly. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Depending on the tunnel type, there could be different sizes. >>>>>>>>>>> Future >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> tunnel types could have other sizes that not specified today. I was >>>>>>>>>> thinking to just give a size range so that it is flexible. Is that >>>>>>>>>> ok? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "If the tunnel exists in some MIB table, this is the >>>>>>>>>>>> row pointer to it." >>>>>>>>>>>> o "some MIB table" : specify which MIB table. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could >>>>>>>>>>> be >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> whatever table that a tunnel may be put into. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> o In what case will the tunnel exist and in what case will it >>>>>>>>>>>> not? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If a device supports mplsTunnelTable and the tunnel is represented >>>>>>>>>>> there, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> then it exists. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> o What will be the behaviour if the above condition is not >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> satisfied? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A null pointer should be given. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>>> STATUS current >>>>>>>>>>>> DESCRIPTION >>>>>>>>>>>> "If the tunnel has a corresponding interface, this is >>>>>>>>>>>> the >>>>>>>>>>>> row pointer to the ifName table." >>>>>>>>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want to >>>>>>>>>>>> say >>>>>>>>>>>> this object points to the corresponding row in the >>>>>>>>>>>> ifTable? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes. Fixed. >>>>>>>>>>> >>>>>>>>>>>> o In what case does the TunnelIf exist and in what case will >>>>>>>>>>>> it >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> not? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Some tunnels may not have a corresponding interface. >>>>>>>>>>> >>>>>>>>>>>> o What will be expected if the tunnel does not have a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> corresponding >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> interface? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Null row pointer. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 9. The Security Considerations section does not follow the >>>>>>>>>>>> Security >>>>>>>>>>>> Guidelines for IETF MIB Modules >>>>>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>>>>> Please fix. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was really hoping that it would not have to be that tedious. >>>>>>>>>>> SNMP/MIB >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> security should be no different from the CLI security - once you >>>>>>>>>> secure >>>>>>>>>> the infrastructure then what's more to do? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll need more time to work on this. Let me try to address the >>>>>>>>>>> issues >>>>>>>>>>> in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the other mib first and come back to this. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 10.ID-nits >>>>>>>>>>>> 10.1 Checking nits according to >>>>>>>>>>>> http://www.ietf.org/id-info/checklist >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** There are 4 instances of too long lines in the document, >>>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> longest one >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> being 3 characters in excess of 72. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I fixed some but there still three too long lines: >>>>>>>>>>> >>>>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>>>>>>>> L2L3VpnMcastProviderTunnelType, >>>>>>>>>>> >>>>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= >>>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= >>>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> S >> >> ... >> >> [$B%/%j%C%W$7$?%a%C%;!<%8(B] > From nobody Sat Apr 15 00:49:39 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83811293E4; Sat, 15 Apr 2017 00:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=SXyY9jnV; dkim=pass (1024-bit key) header.d=verizon.com header.b=cdUCzzVU; dkim=pass (1024-bit key) header.d=verizon.com header.b=gUq5w+9o Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCLN38f03cta; Sat, 15 Apr 2017 00:49:28 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FCF1293E3; Sat, 15 Apr 2017 00:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1492242568; x=1523778568; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Jp9c+gXJSEDQeDENxzMsJ9+LAFuyLus3v9HXUeSXmNM=; b=SXyY9jnVHkEhEmi+Dq34LVTmzcu6fystgZ6rKRq79/TJbXcwuwM6BMR3 DlkkxEuKsJlpTJCqOQo2xwbprTlXwsHsI4mefw1NlX4PjR8lRt6poE4N5 oCLtMrqm7+Xv/YVQSUwYOLMVBdar4az2afdZ6wz6/lQ61LuWgYTwqLPlo k=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe02.verizonbusiness.com with ESMTP; 15 Apr 2017 07:49:17 +0000 X-IronPort-AV: E=Sophos;i="5.37,203,1488844800"; d="scan'208,217";a="1424730906" Received: from rogue-10-255-192-101.rogue.vzwcorp.com (HELO atlantis.verizonwireless.com) ([10.255.192.101]) by fldsmtpi02.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2017 07:48:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1492242531; x=1523778531; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Jp9c+gXJSEDQeDENxzMsJ9+LAFuyLus3v9HXUeSXmNM=; b=cdUCzzVUo4ziCyw2Ci4hw5F78PUVegKZMFypcOUGw9Ft7lUp6wIuaDN/ N/StwloLqtk7iOXo8xBuMZKpGB7emqWT+f3qVwVwxaXhuePsnJ8daWMlP dv0aEa4BbJgz+TNFsVzzUY2RMmi9XleEM86/W+k37RZsCrm8uHDtTz7he s=; Received: from ranger.odc.vzwcorp.com (HELO mercury.verizonwireless.com) ([10.255.240.27]) by atlantis.verizonwireless.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2017 03:48:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1492242530; x=1523778530; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=Jp9c+gXJSEDQeDENxzMsJ9+LAFuyLus3v9HXUeSXmNM=; b=gUq5w+9oDHqRE9+RWBBaVcgMW4gUv+YR9cLvXRwhYWeQjyBht1kN9eGV hwWRB3UO4G+QXSQFoeuIIUyh4w1SlrMnVYyW7mudXJX9AKw/KgbgHQ1oF nLf5CC1YVxgi5f6wxFJmzi8sAUfFk+xQZqHSmnWAKx7chKcJRYp7w1WcD M=; From: luay.jalil@verizon.com X-Host: ranger.odc.vzwcorp.com Received: from gaalpexhub2.uswin.ad.vzwcorp.com ([10.191.138.196]) by mercury.verizonwireless.com with ESMTP/TLS/AES256-SHA; 15 Apr 2017 07:48:50 +0000 Received: from OMZP1LUMXCA05.uswin.ad.vzwcorp.com (144.8.22.175) by GAALPEXHUB2.uswin.ad.vzwcorp.com (10.191.138.196) with Microsoft SMTP Server (TLS) id 8.3.406.0; Sat, 15 Apr 2017 03:48:49 -0400 Received: from OMZP1LUMXCA07.uswin.ad.vzwcorp.com (144.8.22.180) by OMZP1LUMXCA05.uswin.ad.vzwcorp.com (144.8.22.175) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 15 Apr 2017 02:48:48 -0500 Received: from OMZP1LUMXCA07.uswin.ad.vzwcorp.com ([144.8.22.180]) by OMZP1LUMXCA07.uswin.ad.vzwcorp.com ([144.8.22.180]) with mapi id 15.00.1263.000; Sat, 15 Apr 2017 02:48:48 -0500 To: BESS CC: "sfc@ietf.org" Thread-Topic: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure Thread-Index: AQHStby3034M0loOcUuHRBcU6IkGnQ== Date: Sat, 15 Apr 2017 07:48:48 +0000 Message-ID: <49EF93F5-4278-40CC-B5B8-276BF3038DF8@one.verizon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: multipart/alternative; boundary="_000_49EF93F5427840CCB5B8276BF3038DF8oneverizoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 07:49:31 -0000 --_000_49EF93F5427840CCB5B8276BF3038DF8oneverizoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydA0KDQoNCkx1YXkNCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIE1hcnRpbiBWaWdvdXJldXggPG1hcnRpbi52aWdvdXJldXhAbm9raWEuY29tPg0K UmVwbHktVG86IEJFU1MgPGJlc3NAaWV0Zi5vcmc+DQpEYXRlOiBUaHVyc2RheSwgQXByaWwgMTMs IDIwMTcgYXQgMTowNCBQTQ0KVG86IEJFU1MgPGJlc3NAaWV0Zi5vcmc+DQpDYzogInNmY0BpZXRm Lm9yZyIgPHNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzZmNdIEV4dHJhIHRpbWUgdG8gcmVmbGVj dCBvbiBkcmFmdC1tYWNraWUtYmVzcy1uc2gtYmdwLWNvbnRyb2wtcGxhbmUgYWRvcHRpb24gZm9s bG93aW5nIHRoZSBJUFIgZGlzY2xvc3VyZQ0KDQpXRw0KDQpHaXZlbiB0aGUgSVBSIGRpc2Nsb3Nl ZCBbMV0gYWdhaW5zdA0KZHJhZnQtbWFja2llLWJlc3MtbnNoLWJncC1jb250cm9sLXBsYW5lLCB3 ZSBhcmUgc3RhcnRpbmcgYSBjYWxsIGZvcg0KY29tbWVudCBzcGVjaWZpY2FsbHkgdG8gbGV0IHBl b3BsZSBleHByZXNzIGEgcmV2aXNlZCBvcGluaW9uIG9uIGhvdw0KZHJhZnQtaWV0Zi1iZXNzLW5z aC1iZ3AtY29udHJvbC1wbGFuZSBzaG91bGQgYmUgcHVyc3VlZCBpbiBCRVNTLg0KDQpUaGlzIGNh bGwgZm9yIGNvbW1lbnQgaXMgb3BlbiB1bnRpbCB0aGUgNXRoIG9mIE1heQ0KDQpUaGFua3MNCk0m VA0KDQpbMV0gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19pcHJfMjk4MF8mZD1Ed0lGQWcmYz11ZEJUUnZGdlhD NURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9N3lmRTdnOVpqcFJ6R2tOdVZUaWRq NWM3SDJiTUloQ0xmVXdsOFdjRUxTWSZtPXFOMlZ4QmZ1RFFUSGI5c3BVY09iNlUtMFFoTkFyaEg0 LVRxWF9hVGp5YXcmcz00VnVmbG1RaWJTWDZKR2NSSHNmdjRTZ3RJSU11TlV6VkZFZE1NY2NJdFA4 JmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz ZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fc2ZjJmQ9RHdJRkFnJmM9dWRCVFJ2RnZYQzVEaHFnN1VIcEps UHBzM21aM0xSeHBiNl9fMFBvbUJUUSZyPTd5ZkU3ZzlaanBSekdrTnVWVGlkajVjN0gyYk1JaENM ZlV3bDhXY0VMU1kmbT1xTjJWeEJmdURRVEhiOXNwVWNPYjZVLTBRaE5BcmhINC1UcVhfYVRqeWF3 JnM9dTNDM0gyR1Bmb2xOTDJPMXE3LVNvVWZaUk5GWEdHcVhiVW80NzF5R01rVSZlPQ0KDQo= --_000_49EF93F5427840CCB5B8276BF3038DF8oneverizoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6356D6507A9CA244B3AE8EB7A241C4AD@vzwcorp.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlN1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5MdWF5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPnNmYyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9u IGJlaGFsZiBvZiBNYXJ0aW4gVmlnb3VyZXV4ICZsdDttYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNv bSZndDs8YnI+DQo8Yj5SZXBseS1UbzogPC9iPkJFU1MgJmx0O2Jlc3NAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBBcHJpbCAxMywgMjAxNyBhdCAxOjA0IFBNPGJyPg0K PGI+VG86IDwvYj5CRVNTICZsdDtiZXNzQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1 b3Q7c2ZjQGlldGYub3JnJnF1b3Q7ICZsdDtzZmNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPltzZmNdIEV4dHJhIHRpbWUgdG8gcmVmbGVjdCBvbiBkcmFmdC1tYWNraWUtYmVzcy1u c2gtYmdwLWNvbnRyb2wtcGxhbmUgYWRvcHRpb24gZm9sbG93aW5nIHRoZSBJUFIgZGlzY2xvc3Vy ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V0c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+R2l2ZW4gdGhlIElQUiBkaXNjbG9zZWQgWzFdIGFnYWluc3QgPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1tYWNraWUtYmVzcy1u c2gtYmdwLWNvbnRyb2wtcGxhbmUsIHdlIGFyZSBzdGFydGluZyBhIGNhbGwgZm9yDQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbW1lbnQgc3Bl Y2lmaWNhbGx5IHRvIGxldCBwZW9wbGUgZXhwcmVzcyBhIHJldmlzZWQgb3BpbmlvbiBvbiBob3cN CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJh ZnQtaWV0Zi1iZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZSBzaG91bGQgYmUgcHVyc3VlZCBpbiBC RVNTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGNhbGwgZm9yIGNvbW1lbnQgaXMgb3BlbiB1bnRpbCB0aGUgNXRoIG9mIE1heTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk0mYW1w O1Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WzFdIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfaXByXzI5ODBfJmFtcDtkPUR3SUZBZyZhbXA7 Yz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJmFtcDtyPTd5ZkU3 ZzlaanBSekdrTnVWVGlkajVjN0gyYk1JaENMZlV3bDhXY0VMU1kmYW1wO209cU4yVnhCZnVEUVRI YjlzcFVjT2I2VS0wUWhOQXJoSDQtVHFYX2FUanlhdyZhbXA7cz00VnVmbG1RaWJTWDZKR2NSSHNm djRTZ3RJSU11TlV6VkZFZE1NY2NJdFA4JmFtcDtlPSI+DQpodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2lwcl8y OTgwXyZhbXA7ZD1Ed0lGQWcmYW1wO2M9dWRCVFJ2RnZYQzVEaHFnN1VIcEpsUHBzM21aM0xSeHBi Nl9fMFBvbUJUUSZhbXA7cj03eWZFN2c5WmpwUnpHa051VlRpZGo1YzdIMmJNSWhDTGZVd2w4V2NF TFNZJmFtcDttPXFOMlZ4QmZ1RFFUSGI5c3BVY09iNlUtMFFoTkFyaEg0LVRxWF9hVGp5YXcmYW1w O3M9NFZ1ZmxtUWliU1g2SkdjUkhzZnY0U2d0SUlNdU5VelZGRWRNTWNjSXRQOCZhbXA7ZT08L2E+ DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNmYyBtYWlsaW5nIGxp c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fc2ZjJmFtcDtkPUR3SUZBZyZhbXA7Yz11ZEJUUnZGdlhDNURocWc3 VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJmFtcDtyPTd5ZkU3ZzlaanBSekdrTnVWVGlkajVj N0gyYk1JaENMZlV3bDhXY0VMU1kmYW1wO209cU4yVnhCZnVEUVRIYjlzcFVjT2I2VS0wUWhOQXJo SDQtVHFYX2FUanlhdyZhbXA7cz11M0MzSDJHUGZvbE5MMk8xcTctU29VZlpSTkZYR0dxWGJVbzQ3 MXlHTWtVJmFtcDtlPSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zZmMmYW1wO2Q9RHdJRkFn JmFtcDtjPXVkQlRSdkZ2WEM1RGhxZzdVSHBKbFBwczNtWjNMUnhwYjZfXzBQb21CVFEmYW1wO3I9 N3lmRTdnOVpqcFJ6R2tOdVZUaWRqNWM3SDJiTUloQ0xmVXdsOFdjRUxTWSZhbXA7bT1xTjJWeEJm dURRVEhiOXNwVWNPYjZVLTBRaE5BcmhINC1UcVhfYVRqeWF3JmFtcDtzPXUzQzNIMkdQZm9sTkwy TzFxNy1Tb1VmWlJORlhHR3FYYlVvNDcxeUdNa1UmYW1wO2U9PC9hPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_49EF93F5427840CCB5B8276BF3038DF8oneverizoncom_-- From nobody Mon Apr 17 05:32:24 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63FF12EC70; Mon, 17 Apr 2017 05:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-htCHSPSmm1; Mon, 17 Apr 2017 05:32:15 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CAD12EC68; Mon, 17 Apr 2017 05:32:15 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3HCPNc2035727; Mon, 17 Apr 2017 08:32:12 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 29vs48jb5p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Apr 2017 08:32:12 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3HCWBw0029863; Mon, 17 Apr 2017 08:32:11 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3HCW2x1029702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Apr 2017 08:32:06 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 17 Apr 2017 12:31:43 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.178]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0319.002; Mon, 17 Apr 2017 08:31:42 -0400 From: "UTTARO, JAMES" To: "luay.jalil@verizon.com" , BESS CC: "sfc@ietf.org" Thread-Topic: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure Thread-Index: AQHStIBlap4pL42100eGu7Vh+MvBDKHGU3sAgAMwlVA= Date: Mon, 17 Apr 2017 12:31:41 +0000 Message-ID: References: <49EF93F5-4278-40CC-B5B8-276BF3038DF8@one.verizon.com> In-Reply-To: <49EF93F5-4278-40CC-B5B8-276BF3038DF8@one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.228] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F2B2FE1FBMISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-17_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704170115 Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 12:32:17 -0000 --_000_B17A6910EEDD1F45980687268941550F2B2FE1FBMISOUT7MSGUSRCD_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydA0KDQpKaW0gVXR0YXJvDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgbHVheS5qYWxpbEB2ZXJpem9uLmNvbQ0KU2VudDogU2F0dXJk YXksIEFwcmlsIDE1LCAyMDE3IDM6NDkgQU0NClRvOiBCRVNTIDxiZXNzQGlldGYub3JnPg0KQ2M6 IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIEV4dHJhIHRpbWUgdG8gcmVmbGVjdCBv biBkcmFmdC1tYWNraWUtYmVzcy1uc2gtYmdwLWNvbnRyb2wtcGxhbmUgYWRvcHRpb24gZm9sbG93 aW5nIHRoZSBJUFIgZGlzY2xvc3VyZQ0KDQpTdXBwb3J0DQoNCg0KTHVheQ0KDQpGcm9tOiBzZmMg PHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJl aGFsZiBvZiBNYXJ0aW4gVmlnb3VyZXV4IDxtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbTxtYWls dG86bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+Pg0KUmVwbHktVG86IEJFU1MgPGJlc3NAaWV0 Zi5vcmc8bWFpbHRvOmJlc3NAaWV0Zi5vcmc+Pg0KRGF0ZTogVGh1cnNkYXksIEFwcmlsIDEzLCAy MDE3IGF0IDE6MDQgUE0NClRvOiBCRVNTIDxiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYu b3JnPj4NCkNjOiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NmY10gRXh0cmEgdGltZSB0byBy ZWZsZWN0IG9uIGRyYWZ0LW1hY2tpZS1iZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZSBhZG9wdGlv biBmb2xsb3dpbmcgdGhlIElQUiBkaXNjbG9zdXJlDQoNCldHDQoNCkdpdmVuIHRoZSBJUFIgZGlz Y2xvc2VkIFsxXSBhZ2FpbnN0DQpkcmFmdC1tYWNraWUtYmVzcy1uc2gtYmdwLWNvbnRyb2wtcGxh bmUsIHdlIGFyZSBzdGFydGluZyBhIGNhbGwgZm9yDQpjb21tZW50IHNwZWNpZmljYWxseSB0byBs ZXQgcGVvcGxlIGV4cHJlc3MgYSByZXZpc2VkIG9waW5pb24gb24gaG93DQpkcmFmdC1pZXRmLWJl c3MtbnNoLWJncC1jb250cm9sLXBsYW5lIHNob3VsZCBiZSBwdXJzdWVkIGluIEJFU1MuDQoNClRo aXMgY2FsbCBmb3IgY29tbWVudCBpcyBvcGVuIHVudGlsIHRoZSA1dGggb2YgTWF5DQoNClRoYW5r cw0KTSZUDQoNClsxXSBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2lwcl8yOTgwXyZkPUR3SUZBZyZjPXVkQlRS dkZ2WEM1RGhxZzdVSHBKbFBwczNtWjNMUnhwYjZfXzBQb21CVFEmcj03eWZFN2c5WmpwUnpHa051 VlRpZGo1YzdIMmJNSWhDTGZVd2w4V2NFTFNZJm09cU4yVnhCZnVEUVRIYjlzcFVjT2I2VS0wUWhO QXJoSDQtVHFYX2FUanlhdyZzPTRWdWZsbVFpYlNYNkpHY1JIc2Z2NFNndElJTXVOVXpWRkVkTU1j Y0l0UDgmZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zZmMmZD1Ed0lGQWcmYz11ZEJUUnZGdlhDNURocWc3 VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9N3lmRTdnOVpqcFJ6R2tOdVZUaWRqNWM3SDJi TUloQ0xmVXdsOFdjRUxTWSZtPXFOMlZ4QmZ1RFFUSGI5c3BVY09iNlUtMFFoTkFyaEg0LVRxWF9h VGp5YXcmcz11M0MzSDJHUGZvbE5MMk8xcTctU29VZlpSTkZYR0dxWGJVbzQ3MXlHTWtVJmU9DQoN Cg== --_000_B17A6910EEDD1F45980687268941550F2B2FE1FBMISOUT7MSGUSRCD_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiM0NDU0NkE7DQoJZm9udC13ZWlnaHQ6Ym9sZDsNCglmb250LXN0eWxlOml0YWxp YzsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPlN1cHBvcnQNCjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0 NDU0NkEiPkppbSBVdHRhcm88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+bHVheS5qYWxpbEB2ZXJpem9uLmNvbTxicj4NCjxiPlNl bnQ6PC9iPiBTYXR1cmRheSwgQXByaWwgMTUsIDIwMTcgMzo0OSBBTTxicj4NCjxiPlRvOjwvYj4g QkVTUyAmbHQ7YmVzc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gRXh0cmEgdGltZSB0byByZWZsZWN0IG9uIGRy YWZ0LW1hY2tpZS1iZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZSBhZG9wdGlvbiBmb2xsb3dpbmcg dGhlIElQUiBkaXNjbG9zdXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+THVheTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+c2ZjICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9m IE1hcnRpbiBWaWdvdXJldXggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udmlnb3VyZXV4QG5v a2lhLmNvbSI+bWFydGluLnZpZ291cmV1eEBub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxiPlJlcGx5 LVRvOiA8L2I+QkVTUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgQXByaWwgMTMsIDIwMTcg YXQgMTowNCBQTTxicj4NCjxiPlRvOiA8L2I+QkVTUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3NA aWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+W3NmY10gRXh0cmEgdGltZSB0byByZWZsZWN0IG9uIGRyYWZ0LW1hY2tpZS1i ZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZSBhZG9wdGlvbiBmb2xsb3dpbmcgdGhlIElQUiBkaXNj bG9zdXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XRzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5HaXZlbiB0aGUgSVBSIGRpc2Nsb3NlZCBbMV0gYWdhaW5zdCA8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRyYWZ0LW1hY2tpZS1i ZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZSwgd2UgYXJlIHN0YXJ0aW5nIGEgY2FsbCBmb3INCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29tbWVu dCBzcGVjaWZpY2FsbHkgdG8gbGV0IHBlb3BsZSBleHByZXNzIGEgcmV2aXNlZCBvcGluaW9uIG9u IGhvdw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5kcmFmdC1pZXRmLWJlc3MtbnNoLWJncC1jb250cm9sLXBsYW5lIHNob3VsZCBiZSBwdXJzdWVk IGluIEJFU1MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgY2FsbCBmb3IgY29tbWVudCBpcyBvcGVuIHVudGlsIHRoZSA1dGggb2YgTWF5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TSZhbXA7VDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19pcHJfMjk4MF8mYW1wO2Q9RHdJRkFn JmFtcDtjPXVkQlRSdkZ2WEM1RGhxZzdVSHBKbFBwczNtWjNMUnhwYjZfXzBQb21CVFEmYW1wO3I9 N3lmRTdnOVpqcFJ6R2tOdVZUaWRqNWM3SDJiTUloQ0xmVXdsOFdjRUxTWSZhbXA7bT1xTjJWeEJm dURRVEhiOXNwVWNPYjZVLTBRaE5BcmhINC1UcVhfYVRqeWF3JmFtcDtzPTRWdWZsbVFpYlNYNkpH Y1JIc2Z2NFNndElJTXVOVXpWRkVkTU1jY0l0UDgmYW1wO2U9Ij4NCmh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdf aXByXzI5ODBfJmFtcDtkPUR3SUZBZyZhbXA7Yz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVoz TFJ4cGI2X18wUG9tQlRRJmFtcDtyPTd5ZkU3ZzlaanBSekdrTnVWVGlkajVjN0gyYk1JaENMZlV3 bDhXY0VMU1kmYW1wO209cU4yVnhCZnVEUVRIYjlzcFVjT2I2VS0wUWhOQXJoSDQtVHFYX2FUanlh dyZhbXA7cz00VnVmbG1RaWJTWDZKR2NSSHNmdjRTZ3RJSU11TlV6VkZFZE1NY2NJdFA4JmFtcDtl PTwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2ZjIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zZmMmYW1wO2Q9RHdJRkFnJmFtcDtjPXVkQlRSdkZ2WEM1 RGhxZzdVSHBKbFBwczNtWjNMUnhwYjZfXzBQb21CVFEmYW1wO3I9N3lmRTdnOVpqcFJ6R2tOdVZU aWRqNWM3SDJiTUloQ0xmVXdsOFdjRUxTWSZhbXA7bT1xTjJWeEJmdURRVEhiOXNwVWNPYjZVLTBR aE5BcmhINC1UcVhfYVRqeWF3JmFtcDtzPXUzQzNIMkdQZm9sTkwyTzFxNy1Tb1VmWlJORlhHR3FY YlVvNDcxeUdNa1UmYW1wO2U9Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NmYyZhbXA7ZD1E d0lGQWcmYW1wO2M9dWRCVFJ2RnZYQzVEaHFnN1VIcEpsUHBzM21aM0xSeHBiNl9fMFBvbUJUUSZh bXA7cj03eWZFN2c5WmpwUnpHa051VlRpZGo1YzdIMmJNSWhDTGZVd2w4V2NFTFNZJmFtcDttPXFO MlZ4QmZ1RFFUSGI5c3BVY09iNlUtMFFoTkFyaEg0LVRxWF9hVGp5YXcmYW1wO3M9dTNDM0gyR1Bm b2xOTDJPMXE3LVNvVWZaUk5GWEdHcVhiVW80NzF5R01rVSZhbXA7ZT08L2E+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B17A6910EEDD1F45980687268941550F2B2FE1FBMISOUT7MSGUSRCD_-- From nobody Tue Apr 18 13:22:36 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3738B128B8E; Tue, 18 Apr 2017 13:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCCVR8vhiOap; Tue, 18 Apr 2017 13:22:33 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E8B127876; Tue, 18 Apr 2017 13:22:33 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id r190so6415134wme.1; Tue, 18 Apr 2017 13:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hu4UHBDItxbY2zD0+oA/orqGvmit/sZzjmSH1FnePik=; b=Hat8sjnp1LktzDLgtTlAXq2Jz/vlkSVb7XoDXHu0Vt7fQAV+mcTlyiGUu82rNDPsSC LuZFwScLSUVFQvnrX8mKY2n5SfqWTinSvTKfoYfjBVY4hxvB3NUaLXdOFeexuRPx7sJ6 PWi3yhCj5Lce+GJLKCTHj9FpBaJXRsLNQ04w5EW69dgxrQvu1mmbGp3V2gWamm2Fb7pa LtgafdeAMzxogBtEuZCT/Yx49axZqihBosV5VLiwgqD1tCVMSeULjIx7uG4zPmtEoNas jTYI8R+K2prqQYtz8JD0sQiaM7AxJ8JmqtxpicLkr9VV5MGmyNt09GZyAV9h/hNm/c6O 2ugw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hu4UHBDItxbY2zD0+oA/orqGvmit/sZzjmSH1FnePik=; b=G4l9sevLimzyvSZif3viKtrUtC+m/d+zJIjfWHUUFcYSXgavYix0HZvb6GPZnxCxNW aWWFeQagfu+ydvwrx2p4l9i1F1mhIpG/XNUcvcwKUn+HR3xj2tXkXXTNqiHayeAwdtih SeMNUqw7HqpBDTYySvxFZ26SkPyn2X9nbd98Z+cX4X9NqAfnGrDQWW/NZ8CTVHBs55CO usTAZQG7EiWg138/8ACSvc2HCJ2V5QhDiW7fIpoZNGS59g/NlTFW69gQ7JkIwnH4Basl PYaSNngDZalC8+Z8hGJYdzQ/UFilM2twmkFvq6sLV3BYpL1QL4MtVD/lPy3LtT1M4OFj mwJg== X-Gm-Message-State: AN3rC/4W5xUw/gbNvVVBS0H1xa9uDuhgte4cS0ZVqwrnlCjG6D1c3PKP aG7MY7caW5S60r6TrkuuW+m1VIw7WA== X-Received: by 10.28.132.16 with SMTP id g16mr15262014wmd.87.1492546951663; Tue, 18 Apr 2017 13:22:31 -0700 (PDT) MIME-Version: 1.0 References: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> In-Reply-To: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> From: Jeff Tantsura Date: Tue, 18 Apr 2017 20:22:21 +0000 Message-ID: To: BESS , Loa Andersson , idr@ietf.org, "mpls@ietf.org" Cc: "" , bess-chairs@ietf.org, draft-ietf-mpls-rfc3107bis@ietf.org, idr-chairs@ietf.org, "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary=001a114428b8dd567b054d76aaa3 Archived-At: Subject: [bess] Yes/support, long time due update to 3107 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:22:35 -0000 --001a114428b8dd567b054d76aaa3 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 05:33 Loa Andersson wrote: > Working Groups, > > This is to initiate a two week working group last call in four working > groups on draft-ietf-mpls-rfc3107bis-01. > > According to agreement when we decided to host this document in the > MPLS working group, this last call is also copied to the IDR and BESS > working groups. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org), > if you are not subscribed to the mpls wg list, send to "your own" > working group mailing list, and we'll make sure they are posted to the > MPLS wg list. > > There are no IPR disclosures against this document. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any other IPRs that relates > to this document. > > This working group last call ends April 20, 2017. > > > /Loa > MPLS wg co-chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --001a114428b8dd567b054d76aaa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 4, 2017 at 05:33 Loa A= ndersson <loa@pi.nu> wrote:
Working Groups,

This is to initiate a two week working group last call in four working
groups on draft-ietf-mpls-rfc3107bis-01.

According to agreement when we decided to host this document in the
MPLS working group, this last call is also copied to the IDR and BESS
working groups.

Please send your comments to the mpls wg mailing list (mpls@ietf.org),
if you are not subscribed to the mpls wg list, send to "your own"=
working group mailing list, and we'll make sure they are posted to the<= br class=3D"gmail_msg"> MPLS wg list.

There are no IPR disclosures against this document.

All the authors and contributors have stated on the working group
mailing list that they are not aware of any other IPRs that relates
to this document.

This working group last call ends April 20, 2017.


/Loa
MPLS wg co-chairs
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=

_______________________________________________
BESS mailing list
BESS= @ietf.org
https://www.ietf.org/mailman/listinfo/= bess
--001a114428b8dd567b054d76aaa3-- From nobody Tue Apr 18 15:08:22 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC971131493; Tue, 18 Apr 2017 15:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKPEw1_gEwe2; Tue, 18 Apr 2017 15:08:14 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640211314A4; Tue, 18 Apr 2017 15:08:12 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id r203so7847768oib.3; Tue, 18 Apr 2017 15:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1FxHUbJYIr3g2FVo+95F84g1lz5bgyYlYL0ehKAh8jA=; b=FFVjaPw2QI+tUPWqOBizrDqwF5yV29I1VP9M65Dql1cie/FjJFm1MZJyP0nmypxCDU qK415P7PlybW2Yt6mZSYTWC9uClLK2C8sVlhP5y931F9hoORuBSBtCdCtOlFHszVCrJx sI/6XCjR1POQtOVLX67Z5oZqdu188YJRPJWqQtzuAYNi+iYFvJCmWFTyaULypD6lDZlZ LWdesw3osu7b1nMeelvXRAnRtnPEMkzy91+K0JlFhaHTmVCrvPEyyCDjFdeGDEFXk1EB YmbeSDshM3+KFlrA3KdsT042r4kl8S4tkLvK0Ft5fBBwN3h5FmTQgWat6Bff+PruVBIc RDoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1FxHUbJYIr3g2FVo+95F84g1lz5bgyYlYL0ehKAh8jA=; b=kjlCqlBoUXNlfiElgN5mtijXh/43o4ivEsm5xTyuPusc6npJEMfbDN6LeaNm4cByMC hEjsYnXmHWLkB1an1fk1gi5JwvUsdwtwoENsFHMsGtv6ufp5YwmmrDA6+lrzjjD4Y7Xk VvRMxOTNA6Qhd4Tko7g6rSIx5BH9tUYpuBgPBd4al8Eiut1AcYQVqBOL8b+KJp6RpOMR NdC6bykXN9DgzUPyG2xN2Dj2YG2hjz9u6dJNLzf4EE6tsbX1Hby/DU0zxnGgXErrKenQ U38DXzHJnrGKrNDgwn1OJy7gMtdMqzu5Dy+j4yztywkUC37ZhU7ZAam18ETqWqHOT8WD C9xQ== X-Gm-Message-State: AN3rC/4d8TMeks/xxymClrOwgu973ifonThKuYuyqwMm1jH2VtpqpaJ6 gCj6kpNTNl0MkbEJ2kGjC4Cm4ltTxQ== X-Received: by 10.157.60.145 with SMTP id z17mr6610655otc.252.1492553291499; Tue, 18 Apr 2017 15:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.201 with HTTP; Tue, 18 Apr 2017 15:07:51 -0700 (PDT) In-Reply-To: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> References: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> From: "Andrew G. Malis" Date: Tue, 18 Apr 2017 17:07:51 -0500 Message-ID: To: Loa Andersson Cc: "mpls@ietf.org" , idr@ietf.org, BESS , "" , idr-chairs@ietf.org, bess-chairs@ietf.org, "mpls-chairs@ietf.org" , draft-ietf-mpls-rfc3107bis@ietf.org Content-Type: multipart/alternative; boundary=94eb2c18fc54bf90cc054d78248c Archived-At: Subject: Re: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 22:08:16 -0000 --94eb2c18fc54bf90cc054d78248c Content-Type: text/plain; charset=UTF-8 This draft is very useful and IMHO is ready to be submitted for publication. Cheers, Andy On Tue, Apr 4, 2017 at 7:33 AM, Loa Andersson wrote: > Working Groups, > > This is to initiate a two week working group last call in four working > groups on draft-ietf-mpls-rfc3107bis-01. > > According to agreement when we decided to host this document in the > MPLS working group, this last call is also copied to the IDR and BESS > working groups. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org), > if you are not subscribed to the mpls wg list, send to "your own" > working group mailing list, and we'll make sure they are posted to the > MPLS wg list. > > There are no IPR disclosures against this document. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any other IPRs that relates > to this document. > > This working group last call ends April 20, 2017. > > > /Loa > MPLS wg co-chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --94eb2c18fc54bf90cc054d78248c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft is very useful and IMHO is ready to be submitte= d for publication.

Cheers,
Andy

=

On Tu= e, Apr 4, 2017 at 7:33 AM, Loa Andersson <loa@pi.nu> wrote:
Working Groups,

This is to initiate a two week working group last call in four working
groups on draft-ietf-mpls-rfc3107bis-01.

According to agreement when we decided to host this document in the
MPLS working group, this last call is also copied to the IDR and BESS
working groups.

Please send your comments to the mpls wg mailing list (mpls@ietf.org),
if you are not subscribed to the mpls wg list, send to "your own"=
working group mailing list, and we'll make sure they are posted to the<= br> MPLS wg list.

There are no IPR disclosures against this document.

All the authors and contributors have stated on the working group
mailing list that they are not aware of any other IPRs that relates
to this document.

This working group last call ends April 20, 2017.


/Loa
MPLS wg co-chairs
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

--94eb2c18fc54bf90cc054d78248c-- From nobody Wed Apr 19 07:47:39 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFA512778D; Wed, 19 Apr 2017 07:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMZv-c0L_ofv; Wed, 19 Apr 2017 07:47:36 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233CE12946D; Wed, 19 Apr 2017 07:47:32 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3JElUkJ005696; Wed, 19 Apr 2017 15:47:30 +0100 Received: from 950129200 (251.129.113.87.dyn.plus.net [87.113.129.251]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3JElBhR005528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Apr 2017 15:47:12 +0100 Reply-To: From: "Adrian Farrel" To: Cc: References: <149261292043.19325.8922821291757244074@ietfa.amsl.com> In-Reply-To: <149261292043.19325.8922821291757244074@ietfa.amsl.com> Date: Wed, 19 Apr 2017 15:47:08 +0100 Message-ID: <045c01d2b91b$dacf4d00$906de700$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHts1S7ksF5enWxUESUrZOB/LcZiaGW0LUg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23016.007 X-TM-AS-Result: No--3.639-10.0-31-10 X-imss-scan-details: No--3.639-10.0-31-10 X-TMASE-MatchedRID: g1rBkxBh5Q+rmmW6xY+ZmAbts0Qkqy42ghFkp5f+YPaObf10apLcScLm p4jPUF8tuenE8eLG9VTrYsNF9sNQLvnVY0DWsTq3ooGZd5+Ep8ZyawdArtww50Yx760ONDcW7+F HZ+jIPsltdji2bFs2rX7wZhseqbX08A4X1qvMzfXFlCgYxEaGE5GbOnngZyDNMacxaAmSlGhdga cerw5FIKXRmxv4jWq2GaPTprKXNzKuyr/sGF0bIM+ayFtEW0uYAuQDJRMogRJgOcGYycfRsEFvX wCiRuxTAzoMIMW+tMMxRRhxmVj8PbXAj35CMHKunhHKNOYbLL5ezmeoa8MJ84XPicOCzLXARbxU nI4S/BWjjGu/2S799ZGTpe1iiCJqtD9qpBlNF8pWdFebWIc3VsRB0bsfrpPInxMyeYT53RldN7F V6w3UAeUPDyRWUV82VD8HeTQw6TcESXwLmLlJrp1t3K32SzMkDV6DA7GniOWFbxXgRQBZyRvQcT hs494OEzhPwjrzXBDEKh5bR1PYFof8kK+K1APpIcrpoIxNunWiPKQz22GTEVZca9RSYo/b Archived-At: Subject: [bess] FW: I-D Action: draft-drake-bess-datacenter-gateway-03.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:47:38 -0000 Hi, This is just a refresh of the previous version. We do have some updates planned, but we ran out of road. Watch this space. Thanks, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 19 April 2017 15:42 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-drake-bess-datacenter-gateway-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Gateway Auto-Discovery and Route Advertisement for Segment > Routing Enabled Data Center Interconnection > Authors : John Drake > Adrian Farrel > Eric Rosen > Keyur Patel > Luay Jalil > Filename : draft-drake-bess-datacenter-gateway-03.txt > Pages : 9 > Date : 2017-04-19 > > Abstract: > Data centers have become critical components of the infrastructure > used by network operators to provide services to their customers. > Data centers are attached to the Internet or a backbone network by > gateway routers. One data center typically has more than one gateway > for commercial, load balancing, and resiliency reasons. > > Segment routing is a popular protocol mechanism for operating within > a data center, but also for steering traffic that flows between two > data center sites. In order that one data center site may load > balance the traffic it sends to another data center site it needs to > know the complete set of gateway routers at the remote data center, > the points of connection from those gateways to the backbone network, > and the connectivity across the backbone network. > > This document defines a mechanism using the BGP Tunnel Encapsulation > attribute to allow each gateway router to advertise the routes to the > prefixes in the data center site to which it provides access, and > also to advertise on behalf of each other gateway to the same data > center site. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ From nobody Wed Apr 19 08:09:02 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D53129AF7 for ; Wed, 19 Apr 2017 08:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1W2RBqPPqyt for ; Wed, 19 Apr 2017 08:08:54 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0107.outbound.protection.outlook.com [104.47.37.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87B4129ADD for ; Wed, 19 Apr 2017 08:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/V26tEN4a4QyukOwf47S0x7jdu3rpVfIX0Uv8Yd0t+g=; b=VKJUihmmofP4Oh4himg6yToCBPVfuK6vOS0neCufghumRQ5FmiMeUMlNZylsVWeOC3bjOJdJg/SLLMnynKXcQOxgkj0gsYGmLO7bs6jmgbNDGmFHZaRcdpwA6QIzCTBRMGJ9Mgcs3eANbdYh4wE59Q42jKqeqsc50FD4nkdm3K8= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.36] (66.129.241.12) by SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 15:08:51 +0000 To: "Rabadan, Jorge (Nokia - US/Mountain View)" , "Vigoureux, Martin (Nokia - FR/Nozay)" , BESS References: <3035f4d6-163e-2f90-8462-74fa8801540b@nokia.com> <9fa61e3a-50e6-2b27-86a8-f0988194f5a9@juniper.net> <6DD233B4-D233-44AD-96D0-6AFFA0B02731@on.nokia.com> From: Eric C Rosen Message-ID: Date: Wed, 19 Apr 2017 11:08:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6DD233B4-D233-44AD-96D0-6AFFA0B02731@on.nokia.com> Content-Type: multipart/mixed; boundary="------------A9BD5004DD6085E164C27775" X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR20CA0011.namprd20.prod.outlook.com (10.173.158.149) To SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 684a5577-c513-41b0-b5ae-08d48735fd96 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 3:fg/FC9hml/TydRQ5WVV5SNt2DZL4h5+h69U/hFB5W9z0KC03wjL+gdi/pXq5M4uaQAxAuBDWm1T//iMCqK3Fokbgtda8JdIJ2ooSvXm6656WpDLOu35jVsy02YYI+8psEEXbX9AwqDXjEdFT4t10mag4WWfjTVclHVggyfblPpNJqIu27mDYhu9pH++Jf3+BZ2Id2FBgDvFBhfQs7F5Fa99LRoSu+CFMU+awCFSyo6wXn4jblCz1d0c5bVi0nRAZvoxt0hMo/LbmDjztKX1VHg4rHtBdJtFPc9HY1TYx/2vmw7iqCg7pUlCOn7nCqsCZyaQGWI62DGNrfefuOThVs95FrG3uCo0RrNQRkSfjL+0=; 25:qR8gV6Oe7xgEuem4YF6qrWKrbvtwX5FDpdWmu0NplnCgPgMUXVFgx6fIxyYknY3EEaVIStcP7ZHmEHULSJa0tt5gfxNOcsE3lENhn6AQuatXyQnJEMgPNcV4fTytDrVaSEvo5pQ0mYicntKqsrkeOBMBEuO8uqaNrf+yMznbSJWfMmEsTzc3pqOpS+M0+K+7Q4Jeb3xaHMoMSVUGD+7XM8kT30Puam3yGiJGn1u9LW4cSXPoYbhJ4eTgRnIRew6d51CxdlAy411+O9aH/56en/yJO6kWZpY+90/YVpXvm0NJpDvQ0reiXh7oo+BwF9RYpJXkmfjIj6P5NufnQnnsTOqbo/MUZ0sAC5U21sXJYZud0BlI8YPZBGXQ9EEIUGy4SL3neoOVmJg8P7VKdqGfSqKPLSkeH6qx31Sf3iI+Lsklvmd9LOHg4g3HWRlyYWCciKdvF3uQomEVb4ajaI1qNaJ1EbdrqzxxGEtH9DCwBROG4ddBcK90eAJiR14ZjT+gRSXfVwEDPw+byh+4BXO5wA== X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 31:emkT82QRUMgQZMnIYK5Ew6nczgPT7ziunrS9jhE4jS5Z8pI2MQwasmQkf1PVy38odJqhXzZvTGO/suSEsb6kQGQqEGVvwpg9X5Mo6XtF/NXA+cnpvvc5oIJe/nU2ZP64pPOyRrGsuiNSOFqL28IBO9nP68n5Br6UQrWGuAQu8Bb8GiQ1KO9JSYhi56x+QHapY/u5JAtRpbVi+OFIWv4aLxJ/Q241mAMms4L3DVs2zEUftPzNUvlnyie2e+PV74NqsadZA4UnAzy4T2acx/vJ6Q==; 20:CE9srAeFFQ4PAivesmqN9YNLsj1+q13RLs9rov+j9r2ioMVnP5aI+9tzhwp3kCLsn6jAvZ297Crt8cLYZgaQiWLESDU3eDWdtYxqknFSApHmmfCNXkDn/waObYLPjjG3JdD1lGlYZPZi5CR+P1spZPOqSIkft6YvKwvOMaFfWg9eccZ0mwlj/W0jiq2o1aFZUwDYSO4bMOmfRdXkM9Q+CW0DRvVq6CeZxsxSHobHIX4Ce5t6jYNki267LMz6HiAA4S1QGvDhAh5nSkeW9el78wFT2nfuCqMb9KrS2hgLtZE2D48YYzEs++K+t7SPJQrp3E6kptupGf/OnKLE8Y1n6hHemZeFrOpYklf/WCrZLmodIRKn6ezp45wtOGujtMEEjRRimF7+FCLZCnlafl+ToGA53QY/KScDAhODif3CaHIj0eAK9gcpqXYglIFwzuFKona3Ke8dktrT+JiHspxERSgBDnUFQWXW/+bfjIr9JbF6IyCefB33RQyIHhMcQs/yIQtpDTeCD3DKNMxjkt0hqh4BtpsdoaX1RTAI/9/eq/7U/7zh0+eLvHRSdc9ydMggG7Bo6Bw9zrDCDNmX163/4cHPnvG7H4ERiUyUqtiL3GU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(6072148); SRVR:SN1PR05MB2189; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 4:Cs67ztVH//1u9Uctxi5+TOShMC5w5GEIdtjR9V72Ubsdm1jNyJLce0ZUlp7PYTs4d/NqFsgHLyN2HF+uINowpFOTjXDtBqIwE1RqqVmM+zEmw7/gFb7Ts3ngxD2WzStlc66/KMJ0P3rpP4BBtG43sQ6mCrG96/pSZSthAZl0UfVbfNqaV58NvbZzJ52jRJvFkTa0HX46qSzt2oKbYHBnvKFg+GxZNTEthOM9AQvkjrlb/p1OottbZx5V03TNLU2TAS2p9z68WXwX7JPFxzLA07OCSSozhaR8Lkdeh7EEo4WOd5YRBPBGQsu05mor1WC/3kDSt8OSt8o190WlwpWUPdo5zViHAdkQgd5r9E8KRm8FP5Z6900RwF0br7lqsnLJeXXhsoLHprJzx0tszuGUwvEb/idm7F70FASbwsyd2TLpP8IMcCep+YhVRNeeMZoCK+q43BFQb9MTBjmeryF2lWraA+qD65vdUSqFlWmKUK1Uof1oLsW0EAQDLBXVqVwcUwNMp8yIsdzk7kd5IvbcZWzanxJ6jFjr1F3ASien2EAv/mwefHj2tsIvCsuyRZQhXkazCzke4Ct/ClgTNYZB91EYqpDljXSWzx56zpP82ylS4duoZfQX0u8JmN0FSrp7XajIk9tXXBejTQlJJOKhQ4xU7AJc0cWiZTMGp9CzyX4AEWTjcte7pw/+M9Uh+y1F0S/ohwthm/HMSJB4se5t3qhX19XNou1m/Yi5rPn8FHPpmCd0cx6+DxRa2kxJFENpb7Mxfc9bdLaDT+xTP0kBdr0U1c47WRYn5XITP9TEDoE= X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39410400002)(39850400002)(39400400002)(39450400003)(39860400002)(39840400002)(51914003)(568964002)(8676002)(84326002)(5890100001)(31696002)(81166006)(65826007)(2476003)(36756003)(83506001)(189998001)(305945005)(4001350100001)(270700001)(2906002)(86362001)(21480400002)(54356999)(6246003)(38730400002)(66066001)(65956001)(53936002)(6116002)(25786009)(3260700006)(31686004)(42186005)(512874002)(90366009)(2950100002)(76176999)(3846002)(5000100001)(33646002)(65806001)(6486002)(5660300001)(50986999)(230783001)(77096006)(229853002)(4610100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2189; H:[172.29.35.36]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB2189; 23:+04dgnYdnsnWy3guB5SetzUkK2D+BK38a3oki0Xcc?= =?us-ascii?Q?9n+E9qPvIDPkaO5hi6TWGp5XGbEDwHO3F8gEJ3cgKDpQnumPMjckYbEYTTwK?= =?us-ascii?Q?DF0B2oc14pw+pP+Pt+F9kDC/PN5iiVD0ZauzUi45BlCQoGaj2Kzdi2dUaXb9?= =?us-ascii?Q?nlFcIe/usdNbZuymCI3Vh/AvzXGhUqsGf2Bwehog6xXhtZMEMbDhrTUfZs/P?= =?us-ascii?Q?r0BIbpc7mnE+fxELpOILrKXkgfn0OU1DMJcxRrRfdj+/iwSADKc6l+dYKKtf?= =?us-ascii?Q?d3CbKztbfcBJzJAyDJ9ruFsRp4yVGhzhXTe3UF5ZjMAvPIH5lwnarbaksAua?= =?us-ascii?Q?Sg88m3I8awNDaNlouD8b3RgXDtWlRvwwJgWH/OdAByPvZBTPBci5w4q7oN6m?= =?us-ascii?Q?YvGBVVdvXrUj4AP/2fzxsg7tjDU1UBkQ7bdYBVc+QRiT7kgGAOdJsFSqrd66?= =?us-ascii?Q?0V1jNC7mY1NaTF8veLryBjfE6nvImSIE4ShC8HwortDzKiuYqTIKu4MXBnnK?= =?us-ascii?Q?4qA4XI1rDGx0CN45G1Hgt3xKOfrZ0W4D4vuryM7IaGslNQTscxerCoDNl9pD?= =?us-ascii?Q?GRQq/4BqP5rdJX4asCfUh9/taDXeeKSmxqmLddoUslw2d/SMFE35uBHXka2J?= =?us-ascii?Q?HhRWzxtOjx4OxCiRjeLY/ck3G08s2KTRabT/HREjak4cnNwuTmDN0F6U7R0h?= =?us-ascii?Q?umPG/8Lsa0vFrEi7v+c9mIxmXjBnJ/oSsRlT2u4vUHWieEAdl+TUKoeRn+iW?= =?us-ascii?Q?RvqKv4s42K67lRmQAvoci2Xcoiy/WF745fpQ6zmqLvzAZrpRv/LbazUhB+tX?= =?us-ascii?Q?TNaKBReguslpiI6HMORlg12eo6I0Evp3Gwuo1/zcCjpP/dMUzVhZDnDEPCrn?= =?us-ascii?Q?pEMw8grvnPZtyokqvcsOvzBT0EMyQcs/klR72zzVq+cxLZ5a8cmjZbhlX4xq?= =?us-ascii?Q?pdkOTm8fUyf0tjXk2DUjujOWmhjwIoNYcyFS2vzALLdtO44F2kSSchx89eFU?= =?us-ascii?Q?7JEw1Xy7aYu5ULmvQN6/gCDte4wlPjnmNE1JBULOKwOht7s/JUrn9zVVA0EZ?= =?us-ascii?Q?VUsdDemt29uyCcGe+HNS5hzmBLf0Uef6b9Txo5phNwI4P8mTZShxlZLcwtxy?= =?us-ascii?Q?mubdZQhOB7X2pc/56WCQc3u1K59WYZKtXEYcvwkK2HDNei1HJJczY/MQ72g1?= =?us-ascii?Q?t86BGejZJ0byLKj6pbVBL0NvcOMGQocsxlfCtM2IqHIOqhgU5D3KwFpsv1ya?= =?us-ascii?Q?f4wPwEcat9FoQlrbIPY4VMRYGF08QH0/wCuxH1VwKfKCYLIYhIl51bIpzV/o?= =?us-ascii?Q?np/dMTkCz85DwA+UTbuFPcTEalVle4jAi/OJGpgepiKdWi/MwrvO4ds34cBo?= =?us-ascii?Q?XTcqQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 6:8BmBZIAB9YhmbseB/sYYF8tAqgNXKx8jKGuSVcz4+iKFcPsNaHiwY+N+ySaP1vWFc7OAdW/HfSnkA4XZaxfpFg+BzeGUVWJOZlXXx5vHdliF3b2XtDTLPY0YbwXFMpVTQcN7BxkcO5Jtp/aC/kIhRXlPWh+UYV4y/B89snzdQSl42uktz/WJTJ9rIglSL7WS98DrV6Cl68dYquxnMdtYMN4V6yWT+rq0kmarRDL0u420WenUXkxPZkRpqyK8RXbA+cPTnM38YeyjqkTvgusPk+0rQu3ljpJ15HL9QJciD4kWVH533cj8d4mVw5kC+npXDxDZ376+hdSZ0yM/2Do6+NEHu/pl27c5Km9sBoF6RcVXyCAqHmP85PYWDMrjaD8/Qp54u68zu/sozCuuyfufT+73Syt+FfFWTlRKZ6tBbiC6jDBfMSu/cP2rRISkhVQtbrdHkwdnsLrt0Zk19qlipSGKhy5e33OGjm5b9kQ4vTl/JIxnKBcIXlj59geMKMTaSwiuxw33kuuvdssc0DrbiHoL/V8KtI37aLb+9cGAzpM=; 5:SWNzhwejkEZwvliIAco8QVMpXuNMmBatBmn7O9LKcjszotH/QhNHjBEvhIlV63XAknbt2TUMFlEpccu4kYDL3mja/AmSXT6KV43JZYqWpWLkgppsr+ceRe1UumTfbR0vO8TxzfPje73XLIoL0b81Wg==; 24:gT7hiXv/cgaRpOWovOXnpYNw1BRbLJ0bdvFi/Hyp/S/GeVfY924SWXxKljVBdKsBkA19DcVrDqdUZmbB8DgpoNjzjQGxiJKv9px/eEFz4DE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 7:sNiGhikOOI+WJFTFjNx7bOjKA8rop7n7ZS4t6ybkMoBtu+gyvxJdOWDc12+RGfPotWLYnI7ahUJlEDoXLtAFd0Xt71xCIcejuORXpgOSrg0DrliaA0nBoHOZW61YCY5cl/xFHyZj0ZXcIiYHpOO3haB0+jg1ZlMRLqkR2HA+p3Z0HmUq6AhyzeJB4KEPP09SY/pWRbV+b3zr+vT93/Edupt47+ADx3opiQnpX110Q7iDzwSDpC5mSXLRCL1WJ0pVxMIAFHr2I0q12fPqTLrjiVnrkZiJ3HoCYPSspXbYIQa9P5aFLUq8dCxhOVJtU5jH/0bIsn0AeFe0jgX+QOTUcQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 15:08:51.7306 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2189 Archived-At: Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 15:09:01 -0000 --------------A9BD5004DD6085E164C27775 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Thanks for the preliminary -05 revision. It answers a lot of my questions. However, now that I better understand the "overlay index" concept, I have gone a bit deeper into the details of your use cases, and have some comments on them in-line in the attached document. Probably the biggest issue is that I'm not sure it is quite clear precisely how you tell whether an overlay index is present in an RT-5, or precisely how you determine which kind of overlay index is present. --------------A9BD5004DD6085E164C27775 Content-Type: text/plain; charset="UTF-8"; name="comments_draft-ietf-bess-evpn-prefix-advertisement-05.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="comments_draft-ietf-bess-evpn-prefix-advertisement-05.txt" VGhhbmtzIGZvciB0aGUgcHJlbGltaW5hcnkgLTA1IHJldmlzaW9uLiAgSXQgYW5zd2VycyBh IGxvdCBvZiBteSBxdWVzdGlvbnMuDQoNCkhvd2V2ZXIsIG5vdyB0aGF0IEkgYmV0dGVyIHVu ZGVyc3RhbmQgdGhlICJvdmVybGF5IGluZGV4IiBjb25jZXB0LCBJIGhhdmUNCmdvbmUgYSBi aXQgZGVlcGVyIGludG8gdGhlIGRldGFpbHMgb2YgeW91ciB1c2UgY2FzZXMsIGFuZCBoYXZl IHNvbWUgY29tbWVudHMNCm9uIHRoZW0gaW4tbGluZSBpbiB0aGUgYXR0YWNoZWQgZG9jdW1l bnQuDQoNClByb2JhYmx5IHRoZSBiaWdnZXN0IGlzc3VlIGlzIHRoYXQgSSdtIG5vdCBzdXJl IGl0IGlzIHF1aXRlIGNsZWFyIHByZWNpc2VseQ0KaG93IHlvdSB0ZWxsIHdoZXRoZXIgYW4g b3ZlcmxheSBpbmRleCBpcyBwcmVzZW50IGluIGFuIFJULTUsIG9yIHByZWNpc2VseQ0KaG93 IHlvdSBkZXRlcm1pbmUgd2hpY2gga2luZCBvZiBvdmVybGF5IGluZGV4IGlzIHByZXNlbnQu DQoNCg0KDQoNCg0KDQoNCkJFU1MgV29ya2dyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEouIFJhYmFkYW4sIEVkLg0KSW50ZXJuZXQgRHJhZnQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBIZW5kZXJpY2t4 DQpJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTm9raWENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIERyYWtlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBXLiBMaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSnVuaXBlcg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIFNhamFzc2kNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDaXNjbw0KDQoNCkV4cGlyZXM6IFNlcHRlbWJlciAyMywgMjAxNyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMiwgMjAxNw0KDQoNCg0KICAgICAg ICAgICAgICAgICAgICBJUCBQcmVmaXggQWR2ZXJ0aXNlbWVudCBpbiBFVlBODQogICAgICAg ICAgICAgIGRyYWZ0LWlldGYtYmVzcy1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50LTA1DQoN Cg0KQWJzdHJhY3QNCg0KICAgRVZQTiBwcm92aWRlcyBhIGZsZXhpYmxlIGNvbnRyb2wgcGxh bmUgdGhhdCBhbGxvd3MgaW50cmEtc3VibmV0DQogICBjb25uZWN0aXZpdHkgaW4gYW4gSVAv TVBMUyBhbmQvb3IgYW4gTlZPLWJhc2VkIG5ldHdvcmsuIEluIHNvbWUNCiAgIG5ldHdvcmtz LCB0aGVyZSBpcyBhbHNvIGEgbmVlZCBmb3IgYSBkeW5hbWljIGFuZCBlZmZpY2llbnQgaW50 ZXItDQogICBzdWJuZXQgY29ubmVjdGl2aXR5IGFjcm9zcyBUZW5hbnQgU3lzdGVtcyBhbmQg RW5kIERldmljZXMgdGhhdCBjYW4gYmUNCiAgIHBoeXNpY2FsIG9yIHZpcnR1YWwgYW5kIGRv IG5vdCBuZWNlc3NhcmlseSBwYXJ0aWNpcGF0ZSBpbiBkeW5hbWljDQogICByb3V0aW5nIHBy b3RvY29scy4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEVWUE4gcm91dGUgdHlwZSBm b3INCiAgIHRoZSBhZHZlcnRpc2VtZW50IG9mIElQIFByZWZpeGVzIGFuZCBleHBsYWlucyBz b21lIHVzZS1jYXNlIGV4YW1wbGVzDQogICB3aGVyZSB0aGlzIG5ldyByb3V0ZS10eXBlIGlz IHVzZWQuDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlz aW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sg Rm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9j dW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMN CiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0 ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dA0KIA0KDQoNClJhYmFk YW4gZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMTcgICAgICAgICAg ICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlBOIFByZWZpeCBB ZHZlcnRpc2VtZW50ICAgICAgICAgIE1hcmNoIDIyLCAyMDE3DQoNCg0KICAgVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KDQogICBUaGlzIEludGVy bmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciAyMiwgMjAxNy4NCg0KQ29weXJp Z2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIwMTcgSUVURiBUcnVzdCBhbmQgdGhl IHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3VtZW50IGF1dGhvcnMuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1Ag NzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcg dG8gSUVURiBEb2N1bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNl LWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhp cyBkb2N1bWVudC4gUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgg cmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gQ29kZSBDb21wb25lbnRzIGV4dHJhY3Rl ZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0KICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBM aWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mDQogICB0aGUgVHJ1 c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkg YXMNCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NCg0KVGFi bGUgb2YgQ29udGVudHMNCg0KICAgMS4gVGVybWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiBJbnRyb2R1Y3Rp b24gYW5kIHByb2JsZW0gc3RhdGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDMNCiAgICAgMi4xIEludGVyLXN1Ym5ldCBjb25uZWN0aXZpdHkgcmVxdWlyZW1lbnRzIGlu IERhdGEgQ2VudGVycyAuIC4gLiAgNA0KICAgICAyLjIgVGhlIHJlcXVpcmVtZW50IGZvciBh IG5ldyBFVlBOIHJvdXRlIHR5cGUgIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAzLiBUaGUg QkdQIEVWUE4gSVAgUHJlZml4IHJvdXRlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDcNCiAgICAgMy4xIElQIFByZWZpeCBSb3V0ZSBlbmNvZGluZyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAzLjIgT3ZlcmxheSBJbmRleGVz IGFuZCBSZWN1cnNpdmUgTG9va3VwIFJlc29sdXRpb24gIC4gLiAuIC4gLiAuIDEwDQogICA0 LiBJUCBQcmVmaXggT3ZlcmxheSBJbmRleCB1c2UtY2FzZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTENCiAgICAgNC4xIFRTIElQIGFkZHJlc3MgT3ZlcmxheSBJbmRleCB1 c2UtY2FzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICA0LjIgRmxvYXRpbmcg SVAgT3ZlcmxheSBJbmRleCB1c2UtY2FzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0 DQogICAgIDQuMyBCdW1wLWluLXRoZS13aXJlIHVzZS1jYXNlICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgNC40IElQLVZSRi10by1JUC1WUkYgbW9kZWwg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICAgIDQuNC4x IEludGVyZmFjZS1sZXNzIElQLVZSRi10by1JUC1WUkYgbW9kZWwgIC4gLiAuIC4gLiAuIC4g LiAuIDE5DQogICAgICAgNC40LjIgSW50ZXJmYWNlLWZ1bGwgSVAtVlJGLXRvLUlQLVZSRiB3 aXRoIGNvcmUtZmFjaW5nIElSQiAuIC4gMjINCiAgICAgICA0LjQuMyBJbnRlcmZhY2UtZnVs bCBJUC1WUkYtdG8tSVAtVlJGIHdpdGggdW5udW1iZXJlZCANCiAgICAgICAgICAgICBjb3Jl LWZhY2luZyBJUkIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAy NQ0KICAgNS4gQ29uY2x1c2lvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDI4DQogICA2LiBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMg ZG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjkNCiAgIDcuIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyOQ0KICAgOC4gSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5DQogICA5LiBSZWZlcmVuY2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjkNCiAgICAg OS4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyOQ0KICAgICA5LjIgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMwDQogICAxMC4gQWNrbm93bGVkZ21l bnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzAN CiAgIDExLiBDb250cmlidXRvcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzMA0KICAgMTIuIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMwDQogDQoNCg0KUmFiYWRh biBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAg ICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFk dmVydGlzZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQoxLiBUZXJtaW5vbG9n eQ0KDQogICBHVyBJUDogR2F0ZXdheSBJUCBBZGRyZXNzDQoNCiAgIElQTDogSVAgYWRkcmVz cyBsZW5ndGgNCg0KICAgSVJCOiBJbnRlZ3JhdGVkIFJvdXRpbmcgYW5kIEJyaWRnaW5nIGlu dGVyZmFjZQ0KDQoqKioqIE5pdDogSW4gdGhlIGRvY3VtZW50LCBJUkIgaXMgc29tZXRpbWVz IHVzZWQgdG8gbWVhbiAiSW50ZWdyYXRlZCBSb3V0aW5nDQoqKioqIGFuZCBCcmlkZ2luZyBp bnRlcmZhY2UiIGFuZCBzb21ldGltZXMgdG8gbWVhbiAiSW50ZWdyYXRlZCBSb3V0aW5nIGFu ZA0KKioqKiBCcmlkZ2luZyIuICANCg0KICAgTUw6IE1BQyBhZGRyZXNzIGxlbmd0aA0KDQog ICBOVkU6IE5ldHdvcmsgVmlydHVhbGl6YXRpb24gRWRnZQ0KDQogICBUUzogVGVuYW50IFN5 c3RlbQ0KDQogICBWQTogVmlydHVhbCBBcHBsaWFuY2UNCg0KICAgUlQtMjogRVZQTiByb3V0 ZSB0eXBlIDIsIGkuZS4gTUFDL0lQIGFkdmVydGlzZW1lbnQgcm91dGUNCg0KICAgUlQtNTog RVZQTiByb3V0ZSB0eXBlIDUsIGkuZS4gSVAgUHJlZml4IHJvdXRlDQoNCiAgIEFDOiBBdHRh Y2htZW50IENpcmN1aXQgIA0KDQogICBFdGhlcm5ldCBOVk8gdHVubmVsOiBpdCByZWZlcnMg dG8gTmV0d29yayBWaXJ0dWFsaXphdGlvbiBPdmVybGF5DQogICB0dW5uZWxzIHdpdGggRXRo ZXJuZXQgcGF5bG9hZC4gRXhhbXBsZXMgb2YgdGhpcyB0eXBlIG9mIHR1bm5lbHMgYXJlDQog ICBWWExBTiBvciBudkdSRS4NCg0KICAgSVAgTlZPIHR1bm5lbDogaXQgcmVmZXJzIHRvIE5l dHdvcmsgVmlydHVhbGl6YXRpb24gT3ZlcmxheSB0dW5uZWxzDQogICB3aXRoIElQIHBheWxv YWQgKG5vIE1BQyBoZWFkZXIgaW4gdGhlIHBheWxvYWQpLiAgDQoNCiAgIE1BQy1WUkY6IEEg VmlydHVhbCBSb3V0aW5nIGFuZCBGb3J3YXJkaW5nIHRhYmxlIGZvciBNZWRpYSBBY2Nlc3MN CiAgIENvbnRyb2wgKE1BQykgYWRkcmVzc2VzIG9uIGFuIE5WRS9QRSwgYXMgcGVyIFtSRkM3 NDMyXS4NCg0KICAgSVAtVlJGOiBBIFZQTiBSb3V0aW5nIGFuZCBGb3J3YXJkaW5nIHRhYmxl cyBmb3IgSVAgYWRkcmVzc2VzIG9uIGFuDQogICBOVkUvUEUsIHNpbWlsYXIgdG8gdGhlIFZS RiBjb25jZXB0IGRlZmluZWQgaW4gW1JGQzQzNjRdLCBob3dldmVyLCBpbg0KICAgdGhpcyBk b2N1bWVudCwgdGhlIElQIHJvdXRlcyBhcmUgYWx3YXlzIHBvcHVsYXRlZCBieSB0aGUgRVZQ TiBhZGRyZXNzDQogICBmYW1pbHkuDQoNCjIuIEludHJvZHVjdGlvbiBhbmQgcHJvYmxlbSBz dGF0ZW1lbnQNCg0KICAgSW50ZXItc3VibmV0IGNvbm5lY3Rpdml0eSBpcyByZXF1aXJlZCBm b3IgY2VydGFpbiB0ZW5hbnRzIHdpdGhpbiB0aGUNCiAgIERhdGEgQ2VudGVyLiBbRVZQTi1J TlRFUlNVQk5FVF0gZGVmaW5lcyBzb21lIGZhaXJseSBjb21tb24gaW50ZXItDQogICBzdWJu ZXQgZm9yd2FyZGluZyBzY2VuYXJpb3Mgd2hlcmUgVFNlcyBjYW4gZXhjaGFuZ2UgcGFja2V0 cyB3aXRoIFRTZXMNCiAgIGxvY2F0ZWQgaW4gcmVtb3RlIHN1Ym5ldHMuIEluIG9yZGVyIHRv IG1lZXQgdGhpcyByZXF1aXJlbWVudCwNCiAgIFtFVlBOLUlOVEVSU1VCTkVUXSBkZXNjcmli ZXMgaG93IE1BQy9JUHMgZW5jb2RlZCBpbiBUUyBSVC0yIHJvdXRlcw0KICAgYXJlIG5vdCBv bmx5IHVzZWQgdG8gcG9wdWxhdGUgTUFDLVZSRiBhbmQgb3ZlcmxheSBBUlAgdGFibGVzLCBi dXQNCiAgIGFsc28gSVAtVlJGIHRhYmxlcyB3aXRoIHRoZSBlbmNvZGVkIFRTIGhvc3Qgcm91 dGVzICgvMzIgb3IgLzEyOCkuIEluDQogICBzb21lIGNhc2VzLCBFVlBOIG1heSBhZHZlcnRp c2UgSVAgUHJlZml4ZXMgYW5kIHRoZXJlZm9yZSBwcm92aWRlDQogICBhZ2dyZWdhdGlvbiBp biB0aGUgSVAtVlJGIHRhYmxlcywgYXMgb3Bwb3NlZCB0byBwcm9ncmFtIGluZGl2aWR1YWwN CiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAy MDE3ICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg RVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJjaCAyMiwgMjAxNw0KDQoN CiAgIGhvc3Qgcm91dGVzLiBUaGlzIGRvY3VtZW50IGNvbXBsZW1lbnRzIHRoZSBzY2VuYXJp b3MgZGVzY3JpYmVkIGluDQogICBbRVZQTi1JTlRFUlNVQk5FVF0gYW5kIGRlZmluZXMgaG93 IEVWUE4gbWF5IGJlIHVzZWQgdG8gYWR2ZXJ0aXNlIElQDQogICBQcmVmaXhlcy4gSW50ZXJv cGVyYWJpbGl0eSBiZXR3ZWVuIEVWUE4gYW5kIEwzVlBOIFtSRkM0MzY0XSBJUCBQcmVmaXgN CiAgIHJvdXRlcyBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICANCg0K ICAgU2VjdGlvbiAyLjEgZGVzY3JpYmVzIHRoZSBpbnRlci1zdWJuZXQgY29ubmVjdGl2aXR5 IHJlcXVpcmVtZW50cyBpbg0KICAgRGF0YSBDZW50ZXJzLiBTZWN0aW9uIDIuMiBleHBsYWlu cyB3aHkgYSBuZXcgRVZQTiByb3V0ZSB0eXBlIGlzDQogICByZXF1aXJlZCBmb3IgSVAgUHJl Zml4IGFkdmVydGlzZW1lbnRzLiBPbmNlIHRoZSBuZWVkIGZvciBhIG5ldyBFVlBODQoNCioq KiogTml0OiBpZiB5b3Ugc2F5ICJ1c2VkIiBpbnN0ZWFkIG9mICJyZXF1aXJlZCIsIHlvdSds bCBhdm9pZCBhcmd1bWVudHMNCioqKiogd2l0aCBhbm5veWluZyByZXZpZXdlcnMgd2hvIHNh eSAiaXQncyBub3QgcmVhbGx5IHJlcXVpcmVkLCB5b3UgY291bGQNCioqKiogaGF2ZSBkb25l IGl0IGFub3RoZXIgd2F5IiA7LSkNCiAgIA0KICAgcm91dGUgdHlwZSBpcyBqdXN0aWZpZWQs IHNlY3Rpb25zIDMsIDQgYW5kIDUgd2lsbCBkZXNjcmliZSB0aGlzIHJvdXRlDQogICB0eXBl IGFuZCBob3cgaXQgaXMgdXNlZCBpbiBzb21lIHNwZWNpZmljIHVzZSBjYXNlcy4gIA0KDQoy LjEgSW50ZXItc3VibmV0IGNvbm5lY3Rpdml0eSByZXF1aXJlbWVudHMgaW4gRGF0YSBDZW50 ZXJzDQoNCiAgIFtSRkM3NDMyXSBpcyB1c2VkIGFzIHRoZSBjb250cm9sIHBsYW5lIGZvciBh IE5ldHdvcmsgVmlydHVhbGl6YXRpb24NCiAgIE92ZXJsYXkgKE5WTzMpIHNvbHV0aW9uIGlu IERhdGEgQ2VudGVycyAoREMpLCB3aGVyZSBOZXR3b3JrDQogICBWaXJ0dWFsaXphdGlvbiBF ZGdlIChOVkUpIGRldmljZXMgY2FuIGJlIGxvY2F0ZWQgaW4gSHlwZXJ2aXNvcnMgb3INCiAg IFRPUnMsIGFzIGRlc2NyaWJlZCBpbiBbRVZQTi1PVkVSTEFZXS4NCg0KICAgSWYgd2UgdXNl IHRoZSB0ZXJtIFRlbmFudCBTeXN0ZW0gKFRTKSB0byBkZXNpZ25hdGUgYSBwaHlzaWNhbCBv cg0KICAgdmlydHVhbCBzeXN0ZW0gaWRlbnRpZmllZCBieSBNQUMgYW5kIElQIGFkZHJlc3Nl cywgYW5kIGNvbm5lY3RlZCB0byBhDQogICBNQUMtVlJGIGJ5IGFuIEF0dGFjaG1lbnQgQ2ly Y3VpdCwgdGhlIGZvbGxvd2luZyBjb25zaWRlcmF0aW9ucyBhcHBseToNCg0KICAgbyBUaGUg VGVuYW50IFN5c3RlbXMgbWF5IGJlIFZpcnR1YWwgTWFjaGluZXMgKFZNcykgdGhhdCBnZW5l cmF0ZQ0KICAgICB0cmFmZmljIGZyb20gdGhlaXIgb3duIE1BQyBhbmQgSVAuDQoNCiAgIG8g VGhlIFRlbmFudCBTeXN0ZW1zIG1heSBiZSBWaXJ0dWFsIEFwcGxpYW5jZSBlbnRpdGllcyAo VkFzKSB0aGF0DQogICAgIGZvcndhcmQgdHJhZmZpYyB0by9mcm9tIElQIGFkZHJlc3NlcyBv ZiBkaWZmZXJlbnQgRW5kIERldmljZXMNCiAgICAgc2l0dGluZyBiZWhpbmQgdGhlbS4NCg0K ICAgICAgICBvIFRoZXNlIFZBcyBjYW4gYmUgZmlyZXdhbGxzLCBsb2FkIGJhbGFuY2Vycywg TkFUIGRldmljZXMsIG90aGVyDQogICAgICAgICAgYXBwbGlhbmNlcyBvciB2aXJ0dWFsIGdh dGV3YXlzIHdpdGggdmlydHVhbCByb3V0aW5nIGluc3RhbmNlcy4NCg0KICAgICAgICBvIFRo ZXNlIFZBcyBkbyBub3QgbmVjZXNzYXJpbHkgcGFydGljaXBhdGUgaW4gZHluYW1pYyByb3V0 aW5nDQogICAgICAgICAgcHJvdG9jb2xzIGFuZCBoZW5jZSByZWx5IG9uIHRoZSBFVlBOIE5W RXMgdG8gYWR2ZXJ0aXNlIHRoZQ0KICAgICAgICAgIHJvdXRlcyBvbiB0aGVpciBiZWhhbGYu DQoNCiAgICAgICAgbyBJbiBhbGwgdGhlc2UgY2FzZXMsIHRoZSBWQSB3aWxsIGZvcndhcmQg dHJhZmZpYyB0byBvdGhlciBUU2VzDQogICAgICAgICAgdXNpbmcgaXRzIG93biBzb3VyY2Ug TUFDIGJ1dCB0aGUgc291cmNlIElQIHdpbGwgYmUgdGhlIG9uZQ0KICAgICAgICAgIGFzc29j aWF0ZWQgdG8gdGhlIEVuZCBEZXZpY2Ugc2l0dGluZyBiZWhpbmQgb3IgYSB0cmFuc2xhdGVk IElQDQogICAgICAgICAgYWRkcmVzcyAocGFydCBvZiBhIHB1YmxpYyBOQVQgcG9vbCkgaWYg dGhlIFZBIGlzIHBlcmZvcm1pbmcNCiAgICAgICAgICBOQVQuDQoNCiAgICAgICAgbyBOb3Rl IHRoYXQgdGhlIHNhbWUgSVAgYWRkcmVzcyBjb3VsZCBleGlzdCBiZWhpbmQgdHdvIG9mIHRo ZXNlDQogICAgICAgICAgVFMuIE9uZSBleGFtcGxlIG9mIHRoaXMgd291bGQgYmUgY2VydGFp biBhcHBsaWFuY2UgcmVzaWxpZW5jeQ0KICAgICAgICAgIG1lY2hhbmlzbXMsIHdoZXJlIGEg dmlydHVhbCBJUCBvciBmbG9hdGluZyBJUCBjYW4gYmUgb3duZWQgYnkNCiAgICAgICAgICBv bmUgb2YgdGhlIHR3byBWQXMgcnVubmluZyB0aGUgcmVzaWxpZW5jeSBwcm90b2NvbCAodGhl IG1hc3Rlcg0KICAgICAgICAgIFZBKS4gVlJSUCBpcyBvbmUgcGFydGljdWxhciBleGFtcGxl IG9mIHRoaXMuIEFub3RoZXIgZXhhbXBsZQ0KDQoqKioqIE5pdDogQXQgbGVhc3QgZm91ciBB RHMgYW5kIHRoZSBSRkMgRWRpdG9yIHdpbGwgcG9pbnQgb3V0IHRoYXQgIlZSUlAiIGlzDQoq KioqIG5vdCBleHBhbmRlZCBhdCBmaXJzdCBvY2N1cnJlbmNlLCBub3IgaXMgYSByZWZlcmVu Y2UgZm9yIGl0IGdpdmVuIDstKQ0KDQogICAgICAgICAgDQogICAgICAgICAgaXMgbXVsdGkt aG9tZWQgc3VibmV0cywgaS5lLiB0aGUgc2FtZSBzdWJuZXQgaXMgY29ubmVjdGVkIHRvDQog DQoNCg0KUmFiYWRhbiBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAx NyAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVW UE4gUHJlZml4IEFkdmVydGlzZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQog ICAgICAgICAgdHdvIFZBcy4NCg0KICAgICAgICBvIEFsdGhvdWdoIHRoZXNlIFZBcyBwcm92 aWRlIElQIGNvbm5lY3Rpdml0eSB0byBWTXMgYW5kIHN1Ym5ldHMNCiAgICAgICAgICBiZWhp bmQgdGhlbSwgdGhleSBkbyBub3QgYWx3YXlzIGhhdmUgdGhlaXIgb3duIElQIGludGVyZmFj ZQ0KICAgICAgICAgIGNvbm5lY3RlZCB0byB0aGUgRVZQTiBOVkUsIGUuZy4gbGF5ZXItMiBm aXJld2FsbHMgYXJlIGV4YW1wbGVzDQogICAgICAgICAgb2YgVkFzIG5vdCBzdXBwb3J0aW5n IElQIGludGVyZmFjZXMuDQoNCiAgIFRoZSBGaWd1cmUgMSBpbGx1c3RyYXRlcyBzb21lIG9m IHRoZSBleGFtcGxlcyBkZXNjcmliZWQgYWJvdmUuDQogICAgICAgICAgICAgICAgICAgICAg IE5WRTEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICBUUzEoVk0pLS18KE1BQy1WUkYxMCl8LS0tLS0r ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIElQMS9NMSAr LS0tLS0tLS0tLS0rICAgICB8ICAgICAgICAgICAgICAgREdXMSAgICAgICAgICAgIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICstLS0tLS0t LS0tLS0tKyAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgfC0tLS18KE1BQy1WUkYxMCkgIHwgICAgICAgDQogICAgIFNOMS0tLSsgICAgICAg ICAgIE5WRTIgICAgICAgfCAgICAgICAgIHwgICAgfCAgICBJUkIxXCAgICB8ICAgICAgDQog ICAgICAgICAgIHwgICAgICAgICstLS0tLS0tLS0tLSsgfCAgICAgICAgIHwgICAgfCAgICAg KElQLVZSRil8LS0tKyAgIA0KICAgICBTTjItLS1UUzIoVkEpLS18KE1BQy1WUkYxMCl8LXwg ICAgICAgICB8ICAgICstLS0tLS0tLS0tLS0tKyAgX3xfICANCiAgICAgICAgICAgfCBJUDIv TTIgKy0tLS0tLS0tLS0tKyB8ICBWWExBTi8gfCAgICAgICAgICAgICAgICAgICAgKCAgICkg DQogICAgIElQNC0tLSsgIDwtKyAgICAgICAgICAgICAgICAgfCAgbnZHUkUgIHwgICAgICAg ICBER1cyICAgICAgKCBXQU4gKQ0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICstLS0tLS0tLS0tLS0tKyAoX19fKSANCiAgICAgICAgICAgICB2 SVAyMyAoZmxvYXRpbmcpICAgICB8ICAgICAgICAgfC0tLS18KE1BQy1WUkYxMCkgIHwgICB8 ICAgDQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgICAg fCAgICBJUkIyXCAgICB8ICAgfCAgDQogICAgIFNOMS0tLSsgIDwtKyAgICAgIE5WRTMgICAg ICAgICB8ICB8ICB8ICAgICAgfCAgICAgKElQLVZSRil8LS0tKyAgIA0KICAgICAgICAgICB8 IElQMy9NMyArLS0tLS0tLS0tLS0rICAgfCAgfCAgfCAgICAgICstLS0tLS0tLS0tLS0tKyAg ICAgICANCiAgICAgU04zLS0tVFMzKFZBKS0tfChNQUMtVlJGMTApfC0tLSsgIHwgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgIHwgICAgICAgICstLS0tLS0t LS0tLSsgICAgICB8ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBJUDUt LS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIE5WRTQg ICAgICAgICAgICAgICB8ICB8ICAgICAgTlZFNSAgICAgICAgICAgICstLVNONQ0KICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgfCAgfCArLS0tLS0tLS0tLS0rICAg ICAgICB8ICAgICANCiAgICAgSVA2LS0tLS0tfChNQUMtVlJGMSkgICAgICAgICAgIHwgIHwg ICstfChNQUMtVlJGMTApfC0tVFM0KFZBKS0tU042DQogICAgICAgICAgICAgIHwgICAgICAg XCAgICAgICAgICAgICB8ICB8ICAgICstLS0tLS0tLS0tLSsgICAgICAgIHwgICAgDQogICAg ICAgICAgICAgIHwgICAgKElQLVZSRikgICAgICAgICB8LS0rICAgICAgICAgICAgICAgIEVT STQgICAgICstLVNONw0KICAgICAgICAgICAgICB8ICAgICAgIC8gIFxJUkIzICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgIHwtLS18KE1BQy1W UkYyKShNQUMtVlJGMTApfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICBTTjR8ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEgREMgaW50 ZXItc3VibmV0IHVzZS1jYXNlcw0KDQogICBXaGVyZToNCg0KICAgTlZFMSwgTlZFMiwgTlZF MywgTlZFNCwgTlZFNSwgREdXMSBhbmQgREdXMiBzaGFyZSB0aGUgc2FtZSBFVkkgZm9yIGEN CiAgIHBhcnRpY3VsYXIgdGVuYW50LiBFVkktMTAgaXMgY29tcHJpc2VkIG9mIHRoZSBjb2xs ZWN0aW9uIG9mIE1BQy1WUkYxMA0KICAgaW5zdGFuY2VzIGRlZmluZWQgaW4gYWxsIHRoZSBO VkVzLiBBbGwgdGhlIGhvc3RzIGNvbm5lY3RlZCB0byBFVkktMTANCiAgIGJlbG9uZyB0byB0 aGUgc2FtZSBJUCBzdWJuZXQuIFRoZSBob3N0cyBjb25uZWN0ZWQgdG8gRVZJLTEwIGFyZQ0K ICAgbGlzdGVkIGJlbG93Og0KDQogICAgICAgIG8gVFMxIGlzIGEgVk0gdGhhdCBnZW5lcmF0 ZXMvcmVjZWl2ZXMgdHJhZmZpYyBmcm9tL3RvIElQMSwgd2hlcmUNCiANCg0KDQpSYWJhZGFu IGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAg ICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2 ZXJ0aXNlbWVudCAgICAgICAgICBNYXJjaCAyMiwgMjAxNw0KDQoNCiAgICAgICAgICBJUDEg YmVsb25ncyB0byB0aGUgRVZJLTEwIHN1Ym5ldC4NCg0KICAgICAgICBvIFRTMiBhbmQgVFMz IGFyZSBWaXJ0dWFsIEFwcGxpYW5jZXMgKFZBKSB0aGF0IGdlbmVyYXRlL3JlY2VpdmUNCiAg ICAgICAgICB0cmFmZmljIGZyb20vdG8gdGhlIHN1Ym5ldHMgYW5kIGhvc3RzIHNpdHRpbmcg YmVoaW5kIHRoZW0NCiAgICAgICAgICAoU04xLCBTTjIsIFNOMywgSVA0IGFuZCBJUDUpLiBU aGVpciBJUCBhZGRyZXNzZXMgKElQMiBhbmQgSVAzKQ0KICAgICAgICAgIGJlbG9uZyB0byB0 aGUgRVZJLTEwIHN1Ym5ldCBhbmQgdGhleSBjYW4gYWxzbyBnZW5lcmF0ZS9yZWNlaXZlDQog ICAgICAgICAgdHJhZmZpYy4gV2hlbiB0aGVzZSBWQXMgcmVjZWl2ZSBwYWNrZXRzIGRlc3Rp bmVkIHRvIHRoZWlyIG93bg0KICAgICAgICAgIE1BQyBhZGRyZXNzZXMgKE0yIGFuZCBNMykg dGhleSB3aWxsIHJvdXRlIHRoZSBwYWNrZXRzIHRvIHRoZQ0KICAgICAgICAgIHByb3BlciBz dWJuZXQgb3IgaG9zdC4gVGhlc2UgVkFzIGRvIG5vdCBzdXBwb3J0IHJvdXRpbmcNCiAgICAg ICAgICBwcm90b2NvbHMgdG8gYWR2ZXJ0aXNlIHRoZSBzdWJuZXRzIGNvbm5lY3RlZCB0byB0 aGVtIGFuZCBjYW4NCiAgICAgICAgICBtb3ZlIHRvIGEgZGlmZmVyZW50IHNlcnZlciBhbmQg TlZFIHdoZW4gdGhlIENsb3VkIE1hbmFnZW1lbnQNCiAgICAgICAgICBTeXN0ZW0gZGVjaWRl cyB0byBkbyBzby4gVGhlc2UgVkFzIG1heSBhbHNvIHN1cHBvcnQgcmVkdW5kYW5jeQ0KICAg ICAgICAgIG1lY2hhbmlzbXMgZm9yIHNvbWUgc3VibmV0cywgc2ltaWxhciB0byBWUlJQLCB3 aGVyZSBhIGZsb2F0aW5nDQogICAgICAgICAgSVAgaXMgb3duZWQgYnkgdGhlIG1hc3RlciBW QSBhbmQgb25seSB0aGUgbWFzdGVyIFZBIGZvcndhcmRzDQogICAgICAgICAgdHJhZmZpYyB0 byBhIGdpdmVuIHN1Ym5ldC4gRS5nLjogdklQMjMgaW4gZmlndXJlIDEgaXMgYQ0KICAgICAg ICAgIGZsb2F0aW5nIElQIHRoYXQgY2FuIGJlIG93bmVkIGJ5IFRTMiBvciBUUzMgZGVwZW5k aW5nIG9uIHdobw0KICAgICAgICAgIHRoZSBtYXN0ZXIgaXMuIE9ubHkgdGhlIG1hc3RlciB3 aWxsIGZvcndhcmQgdHJhZmZpYyB0byBTTjEuICANCg0KICAgICAgICBvIEludGVncmF0ZWQg Um91dGluZyBhbmQgQnJpZGdpbmcgaW50ZXJmYWNlcyBJUkIxLCBJUkIyIGFuZCBJUkIzDQog ICAgICAgICAgaGF2ZSB0aGVpciBvd24gSVAgYWRkcmVzc2VzIHRoYXQgYmVsb25nIHRvIHRo ZSBFVkktMTAgc3VibmV0DQogICAgICAgICAgdG9vLiBUaGVzZSBJUkIgaW50ZXJmYWNlcyBj b25uZWN0IHRoZSBFVkktMTAgc3VibmV0IHRvIFZpcnR1YWwNCiAgICAgICAgICBSb3V0aW5n IGFuZCBGb3J3YXJkaW5nIChJUC1WUkYpIGluc3RhbmNlcyB0aGF0IGNhbiByb3V0ZSB0aGUN CiAgICAgICAgICB0cmFmZmljIHRvIG90aGVyIGNvbm5lY3RlZCBzdWJuZXRzIGZvciB0aGUg c2FtZSB0ZW5hbnQgKHdpdGhpbg0KICAgICAgICAgIHRoZSBEQyBvciBhdCB0aGUgb3RoZXIg ZW5kIG9mIHRoZSBXQU4pLg0KDQogICAgICAgIG8gVFM0IGlzIGEgbGF5ZXItMiBWQSB0aGF0 IHByb3ZpZGVzIGNvbm5lY3Rpdml0eSB0byBzdWJuZXRzIFNONSwNCiAgICAgICAgICBTTjYg YW5kIFNONywgYnV0IGRvZXMgbm90IGhhdmUgYW4gSVAgYWRkcmVzcyBpdHNlbGYgaW4gdGhl DQogICAgICAgICAgRVZJLTEwLiBUUzQgaXMgY29ubmVjdGVkIHRvIGEgcGh5c2ljYWwgcG9y dCBvbiBOVkU1IGFzc2lnbmVkDQogICAgICAgICAgdG8gRXRoZXJuZXQgU2VnbWVudCBJZGVu dGlmaWVyIDQuDQoNCiAgIEFsbCB0aGUgYWJvdmUgREMgdXNlIGNhc2VzIHJlcXVpcmUgaW50 ZXItc3VibmV0IGZvcndhcmRpbmcgYW5kDQogICB0aGVyZWZvcmUgdGhlIGluZGl2aWR1YWwg aG9zdCByb3V0ZXMgYW5kIHN1Ym5ldHM6IA0KDQogICBhKSBNVVNUIGJlIGFkdmVydGlzZWQg ZnJvbSB0aGUgTlZFcyAoc2luY2UgVkFzIGFuZCBWTXMgZG8gbm90DQogICAgICBwYXJ0aWNp cGF0ZSBpbiBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2xzKSBhbmQNCiAgIGIpIE1BWSBiZSBh c3NvY2lhdGVkIHRvIGFuIE92ZXJsYXkgSW5kZXggdGhhdCBjYW4gYmUgYSBWQSBJUCBhZGRy ZXNzLA0KICAgICAgYSBmbG9hdGluZyBJUCBhZGRyZXNzIG9yIGFuIEVTSS4gQW4gT3Zlcmxh eSBJbmRleCBpcyBhIG5leHQtaG9wDQogICAgICB0aGF0IHJlcXVpcmVzIGEgcmVjdXJzaXZl IHJlc29sdXRpb24gYW5kIGl0IGlzIGRlc2NyaWJlZCBpbg0KICAgICAgc2VjdGlvbiAzLjIu DQoNCioqKiogU2VjdGlvbiAzLjIgc2VlbXMgdG8gYWxzbyBhbGxvdyB0aGUgT3ZlcmxheSBJ bmRleCB0byBiZSBhIE1BQw0KKioqKiBhZGRyZXNzLiBUaGF0IHBvc3NpYmlsaXR5IHNob3Vs ZCBiZSBtZW50aW9uZWQgaGVyZSBhcyB3ZWxsLg0KDQoNCjIuMiBUaGUgcmVxdWlyZW1lbnQg Zm9yIGEgbmV3IEVWUE4gcm91dGUgdHlwZSAgIA0KDQogICBbUkZDNzQzMl0gZGVmaW5lcyBh IE1BQy9JUCByb3V0ZSAoYWxzbyByZWZlcnJlZCBhcyBSVC0yKSB3aGVyZSBhIE1BQw0KICAg YWRkcmVzcyBjYW4gYmUgYWR2ZXJ0aXNlZCB0b2dldGhlciB3aXRoIGFuIElQIGFkZHJlc3Mg bGVuZ3RoIChJUEwpDQogICBhbmQgSVAgYWRkcmVzcyAoSVApLiBXaGlsZSBhIHZhcmlhYmxl IElQTCBtaWdodCBoYXZlIGJlZW4gdXNlZCB0bw0KICAgaW5kaWNhdGUgdGhlIHByZXNlbmNl IG9mIGFuIElQIHByZWZpeCBpbiBhIHJvdXRlIHR5cGUgMiwgdGhlcmUgYXJlDQogICBzZXZl cmFsIHNwZWNpZmljIHVzZSBjYXNlcyBpbiB3aGljaCB1c2luZyB0aGlzIHJvdXRlIHR5cGUg dG8gZGVsaXZlcg0KIA0KDQoNClJhYmFkYW4gZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0 ZW1iZXIgMjMsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICBFVlBOIFByZWZpeCBBZHZlcnRpc2VtZW50ICAgICAgICAgIE1hcmNoIDIy LCAyMDE3DQoNCg0KICAgSVAgUHJlZml4ZXMgaXMgbm90IHN1aXRhYmxlLg0KDQogICBPbmUg ZXhhbXBsZSBvZiBzdWNoIHVzZSBjYXNlcyBpcyB0aGUgImZsb2F0aW5nIElQIiBleGFtcGxl IGRlc2NyaWJlZA0KICAgaW4gc2VjdGlvbiAyLjEuIEluIHRoaXMgZXhhbXBsZSB3ZSBuZWVk IHRvIGRlY291cGxlIHRoZSBhZHZlcnRpc2VtZW50DQogICBvZiB0aGUgcHJlZml4ZXMgZnJv bSB0aGUgYWR2ZXJ0aXNlbWVudCBvZiB0aGUgZmxvYXRpbmcgSVAgKHZJUDIzIGluDQogICBG aWd1cmUgMSkgYW5kIE1BQyBhc3NvY2lhdGVkIHRvIGl0LCBvdGhlcndpc2UgdGhlIHNvbHV0 aW9uIGdldHMNCiAgIGhpZ2hseSBpbmVmZmljaWVudCBhbmQgZG9lcyBub3Qgc2NhbGUuIA0K DQogICBFLmcuOiBpZiB3ZSBhcmUgYWR2ZXJ0aXNpbmcgMWsgcHJlZml4ZXMgZnJvbSBNMiAo dXNpbmcgUlQtMikgYW5kIHRoZQ0KICAgZmxvYXRpbmcgSVAgb3duZXIgY2hhbmdlcyBmcm9t IE0yIHRvIE0zLCB3ZSB3b3VsZCBuZWVkIHRvIHdpdGhkcmF3IDFrDQogICByb3V0ZXMgZnJv bSBNMiBhbmQgcmUtYWR2ZXJ0aXNlIDFrIHJvdXRlcyBmcm9tIE0zLiBIb3dldmVyIGlmIHdl IHVzZQ0KICAgYSBzZXBhcmF0ZSByb3V0ZSB0eXBlLCB3ZSBjYW4gYWR2ZXJ0aXNlIHRoZSAx ayByb3V0ZXMgYXNzb2NpYXRlZCB0bw0KICAgdGhlIGZsb2F0aW5nIElQIGFkZHJlc3MgKHZJ UDIzKSBhbmQgb25seSBvbmUgUlQtMiBmb3IgYWR2ZXJ0aXNpbmcgdGhlDQogICBvd25lcnNo aXAgb2YgdGhlIGZsb2F0aW5nIElQLCBpLmUuIHZJUDIzIGFuZCBNMiBpbiB0aGUgcm91dGUg dHlwZSAyLg0KICAgV2hlbiB0aGUgZmxvYXRpbmcgSVAgb3duZXIgY2hhbmdlcyBmcm9tIE0y IHRvIE0zLCBhIHNpbmdsZSBSVC0yDQogICB3aXRoZHJhdy91cGRhdGUgaXMgcmVxdWlyZWQg dG8gaW5kaWNhdGUgdGhlIGNoYW5nZS4gVGhlIHJlbW90ZSBER1cNCiAgIHdpbGwgbm90IGNo YW5nZSBhbnkgb2YgdGhlIDFrIHByZWZpeGVzIGFzc29jaWF0ZWQgdG8gdklQMjMsIGJ1dCB3 aWxsDQogICBvbmx5IHVwZGF0ZSB0aGUgQVJQIHJlc29sdXRpb24gZW50cnkgZm9yIHZJUDIz IChub3cgcG9pbnRpbmcgYXQgTTMpLg0KDQogICBPdGhlciByZWFzb25zIHRvIGRlY291cGxl IHRoZSBJUCBQcmVmaXggYWR2ZXJ0aXNlbWVudCBmcm9tIHRoZSBNQUMvSVANCiAgIHJvdXRl IGFyZSBsaXN0ZWQgYmVsb3c6DQoNCiAgICAgICAgbyBDbGVhbiBpZGVudGlmaWNhdGlvbiwg b3BlcmF0aW9uIGFuZCB0cm91Ymxlc2hvb3Rpbmcgb2YgSVANCiAgICAgICAgICBQcmVmaXhl cywgaW5kZXBlbmRlbnQgb2YgYW5kIG5vdCBzdWJqZWN0IHRvIHRoZSBpbnRlcnByZXRhdGlv bg0KICAgICAgICAgIG9mIHRoZSBJUEwgYW5kIHRoZSBJUCB2YWx1ZS4gRS5nLjogYSBkZWZh dWx0IElQIHJvdXRlDQogICAgICAgICAgMC4wLjAuMC8wIG11c3QgYWx3YXlzIGJlIGVhc2ls eSBhbmQgY2xlYXJseSBkaXN0aW5ndWlzaGVkIGZyb20NCiAgICAgICAgICB0aGUgYWJzZW5j ZSBvZiBJUCBpbmZvcm1hdGlvbi4NCg0KICAgICAgICBvIE1BQyBhZGRyZXNzIGluZm9ybWF0 aW9uIG11c3Qgbm90IGJlIGNvbXBhcmVkIGJ5IEJHUCB3aGVuDQogICAgICAgICAgY2hvb3Np bmcgd2hpY2ggb2Ygc2V2ZXJhbCBJUCBQcmVmaXggcm91dGVzIHRvIGluc3RhbGwgaW4gYQ0K ICAgICAgICAgIGdpdmVuIElQLVZSRi4gSWYgSVAgUHJlZml4ZXMgd2VyZSB0byBiZSBhZHZl cnRpc2VkIHVzaW5nDQogICAgICAgICAgTUFDL0lQIHJvdXRlcywgdGhlIE1BQyBpbmZvcm1h dGlvbiB3b3VsZCBhbHdheXMgYmUgcHJlc2VudCBhbmQNCiAgICAgICAgICBwYXJ0IG9mIHRo ZSByb3V0ZSBrZXkuDQoNCioqKiogUGVyaGFwcyBiZWdpbiB0aGUgbGFzdCBzZW50ZW5jZSBh Ym92ZSB3aXRoICJJbiBNQUMvSVAgcm91dGVzLCB0aGUgTUFDDQoqKioqIGluZm9ybWF0aW9u IGlzIHBhcnQgb2YgdGhlIE5MUkksIHNvIGlmIElQIFByZWZpeGVzIHdlcmUgLi4uIg0KDQog ICBUaGUgZm9sbG93aW5nIHNlY3Rpb25zIGRlc2NyaWJlIGhvdyBFVlBOIGlzIGV4dGVuZGVk IHdpdGggYSBuZXcgcm91dGUNCiAgIHR5cGUgZm9yIHRoZSBhZHZlcnRpc2VtZW50IG9mIElQ IHByZWZpeGVzIGFuZCBob3cgdGhpcyByb3V0ZSBpcyB1c2VkDQogICB0byBhZGRyZXNzIHRo ZSBjdXJyZW50IGFuZCBmdXR1cmUgaW50ZXItc3VibmV0IGNvbm5lY3Rpdml0eQ0KICAgcmVx dWlyZW1lbnRzIGV4aXN0aW5nIGluIHRoZSBEYXRhIENlbnRlci4NCg0KMy4gVGhlIEJHUCBF VlBOIElQIFByZWZpeCByb3V0ZQ0KDQogICBUaGUgY3VycmVudCBCR1AgRVZQTiBOTFJJIGFz IGRlZmluZWQgaW4gW1JGQzc0MzJdIGlzIHNob3duIGJlbG93Og0KDQoNCg0KDQoNCg0KIA0K DQoNClJhYmFkYW4gZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMTcg ICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlBO IFByZWZpeCBBZHZlcnRpc2VtZW50ICAgICAgICAgIE1hcmNoIDIyLCAyMDE3DQoNCg0KICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICAgIFJvdXRl IFR5cGUgKDEgb2N0ZXQpICAgICAgICAgICB8DQogICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgIHwgICAgIExlbmd0aCAoMSBvY3RldCkgICAgICAgICAg ICAgIHwNCiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAg fCBSb3V0ZSBUeXBlIHNwZWNpZmljICh2YXJpYWJsZSkgICAgfA0KICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgV2hlcmUgdGhlIHJvdXRlIHR5cGUg ZmllbGQgY2FuIGNvbnRhaW4gb25lIG9mIHRoZSBmb2xsb3dpbmcgc3BlY2lmaWMNCiAgIHZh bHVlcyAocmVmZXIgdG8gdGhlIElBTkEgIkVWUE4gUm91dGUgVHlwZXMgcmVnaXN0cnkpOg0K DQogICArIDEgLSBFdGhlcm5ldCBBdXRvLURpc2NvdmVyeSAoQS1EKSByb3V0ZQ0KDQogICAr IDIgLSBNQUMvSVAgYWR2ZXJ0aXNlbWVudCByb3V0ZQ0KDQogICArIDMgLSBJbmNsdXNpdmUg TXVsdGljYXN0IFJvdXRlDQoNCiAgICsgNCAtIEV0aGVybmV0IFNlZ21lbnQgUm91dGUNCg0K ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGFkZGl0aW9uYWwgcm91dGUgdHlwZSB0aGF0 IElBTkEgaGFzIGFkZGVkIHRvDQogICB0aGUgcmVnaXN0cnksIGFuZCB3aWxsIGJlIHVzZWQg Zm9yIHRoZSBhZHZlcnRpc2VtZW50IG9mIElQIFByZWZpeGVzOg0KDQogICArIDUgLSBJUCBQ cmVmaXggUm91dGUNCg0KICAgVGhlIHN1cHBvcnQgZm9yIHRoaXMgbmV3IHJvdXRlIHR5cGUg aXMgT1BUSU9OQUwuIA0KDQogICBTaW5jZSB0aGlzIG5ldyByb3V0ZSB0eXBlIGlzIE9QVElP TkFMLCBhbiBpbXBsZW1lbnRhdGlvbiBub3QNCiAgIHN1cHBvcnRpbmcgaXQgTVVTVCBpZ25v cmUgdGhlIHJvdXRlLCBiYXNlZCBvbiB0aGUgdW5rbm93biByb3V0ZSB0eXBlDQogICB2YWx1 ZSwgYXMgc3BlY2lmaWVkIGJ5IFNlY3Rpb24gNS40IGluIFtSRkM3NjA2XS4gDQoNCiAgIFRo ZSBkZXRhaWxlZCBlbmNvZGluZyBvZiB0aGlzIHJvdXRlIGFuZCBhc3NvY2lhdGVkIHByb2Nl ZHVyZXMgYXJlDQogICBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4NCg0K DQozLjEgSVAgUHJlZml4IFJvdXRlIGVuY29kaW5nDQoNCiAgIEFuIElQIFByZWZpeCBhZHZl cnRpc2VtZW50IHJvdXRlIE5MUkkgY29uc2lzdHMgb2YgdGhlIGZvbGxvd2luZw0KICAgZmll bGRzOg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogDQoNCg0KUmFiYWRhbiBldCBhbC4gICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDhdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFkdmVydGlzZW1lbnQgICAg ICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQogICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICAgICAgUkQgICAoOCBvY3RldHMpICAgICAgICAg ICAgICAgICAgfA0KICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQogICAgfEV0aGVybmV0IFNlZ21lbnQgSWRlbnRpZmllciAoMTAgb2N0ZXRzKXwNCiAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgIHwgIEV0 aGVybmV0IFRhZyBJRCAoNCBvY3RldHMpICAgICAgICAgICB8DQogICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICBJUCBQcmVmaXggTGVuZ3Ro ICgxIG9jdGV0KSAgICAgICAgICAgfA0KICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rDQogICAgfCAgSVAgUHJlZml4ICg0IG9yIDE2IG9jdGV0cykgICAg ICAgICAgIHwNCiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgIHwgIEdXIElQIEFkZHJlc3MgKDQgb3IgMTYgb2N0ZXRzKSAgICAgICB8DQogICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICBNUExT IExhYmVsICgzIG9jdGV0cykgICAgICAgICAgICAgICAgfA0KICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgIFdoZXJlOg0KDQogICAgICAgIG8g UkQsIEV0aGVybmV0IFRhZyBJRCBhbmQgTVBMUyBMYWJlbCBmaWVsZHMgd2lsbCBiZSB1c2Vk IGFzDQogICAgICAgICAgZGVmaW5lZCBpbiBbUkZDNzQzMl0gYW5kIFtFVlBOLU9WRVJMQVld Lg0KDQogICAgICAgIG8gVGhlIEV0aGVybmV0IFNlZ21lbnQgSWRlbnRpZmllciB3aWxsIGJl IGEgbm9uLXplcm8gMTAtYnl0ZQ0KICAgICAgICAgIGlkZW50aWZpZXIgaWYgdGhlIEVTSSBp cyB1c2VkIGFzIGFuIG92ZXJsYXkgaW5kZXggKHNlZSB0aGUNCiAgICAgICAgICBkZWZpbml0 aW9uIG9mIG92ZXJsYXkgaW5kZXggaW4gc2VjdGlvbiAzLjIpLiBJdCB3aWxsIGJlIHplcm8N CiAgICAgICAgICBvdGhlcndpc2UuDQoNCiAgICAgICAgbyBUaGUgSVAgUHJlZml4IExlbmd0 aCBjYW4gYmUgc2V0IHRvIGEgdmFsdWUgYmV0d2VlbiAwIGFuZCAzMg0KICAgICAgICAgIChi aXRzKSBmb3IgaXB2NCBhbmQgYmV0d2VlbiAwIGFuZCAxMjggZm9yIGlwdjYsIGFuZCBzcGVj aWZpZXMNCiAgICAgICAgICB0aGUgbnVtYmVyIG9mIGJpdHMgaW4gdGhlIFByZWZpeC4NCg0K ICAgICAgICBvIFRoZSBJUCBQcmVmaXggd2lsbCBiZSBhIDMyIG9yIDEyOC1iaXQgZmllbGQg KGlwdjQgb3IgaXB2NikuDQogICAgICAgICAgVGhlIHNpemUgb2YgdGhpcyBmaWVsZCBkb2Vz IG5vdCBkZXBlbmQgb24gdGhlIHZhbHVlIG9mIHRoZSBJUA0KICAgICAgICAgIFByZWZpeCBM ZW5ndGggZmllbGQuDQoNCiAgICAgICAgbyBUaGUgR1cgSVAgKEdhdGV3YXkgSVAgQWRkcmVz cykgd2lsbCBiZSBhIDMyIG9yIDEyOC1iaXQgZmllbGQNCiAgICAgICAgICAoaXB2NCBvciBp cHY2KSwgYW5kIHdpbGwgZW5jb2RlIGFuIG92ZXJsYXkgSVAgaW5kZXggZm9yIHRoZSBJUA0K ICAgICAgICAgIFByZWZpeGVzLiBUaGUgR1cgSVAgZmllbGQgU0hPVUxEIGJlIHplcm8gaWYg aXQgaXMgbm90IHVzZWQgYXMNCiAgICAgICAgICBhbiBvdmVybGF5IGluZGV4LiBSZWZlciB0 byBzZWN0aW9uIDMuMiBmb3IgdGhlIGRlZmluaXRpb24gYW5kDQogICAgICAgICAgdXNlIG9m IHRoZSBPdmVybGF5IEluZGV4Lg0KDQogICAgICAgIG8gVGhlIE1QTFMgTGFiZWwgZmllbGQg aXMgZW5jb2RlZCBhcyAzIG9jdGV0cywgd2hlcmUgdGhlIGhpZ2gtDQogICAgICAgICAgb3Jk ZXIgMjAgYml0cyBjb250YWluIHRoZSBsYWJlbCB2YWx1ZS4gVGhlIHZhbHVlIFNIT1VMRCBi ZQ0KICAgICAgICAgIG51bGwgKHplcm8pIHdoZW4gdGhlIElQIFByZWZpeCByb3V0ZSBpcyB1 c2VkIGZvciBhIHJlY3Vyc2l2ZQ0KDQoqKioqIFRoZSByZWFzb24gSSBhc2tlZCB5b3UgdG8g c3BlY2lmeSB0aGF0ICJ6ZXJvIiBtZWFucyAibnVsbCIgaXMgdGhhdCBSRkNzDQoqKioqIDMw MzIgYW5kIDUwMzYgdXNlICIzIiB0byBtZWFuICJpbXBsaWNpdCBudWxsIiBhbmQgUkZDIDMw MzIgaGFzIG11bHRpcGxlDQoqKioqIGVuY29kaW5ncyAoMCBhbmQgMikgZm9yIChkaWZmZXJl bnQgZmxhdm9ycyBvZikgImV4cGxpY2l0IG51bGwiLg0KKioqKiBFVlBOL01WUE4gdGVuZCB0 byB1c2UgemVybyB0byBtZWFuICJubyBsYWJlbCB2YWx1ZSBzcGVjaWZpZWQiLiAgTWF5YmUN CioqKiogSSdtIHRoZSBvbmx5IG9uZSB3aG8gc3RpbGwgZ2V0cyBjb25mdXNlZCBieSBhbGwg dGhlc2UgZGlmZmVyZW50DQoqKioqIGVuY29kaW5ncyB0aGF0IGFyZSBuYW1lZCAibnVsbCIg Oy0pDQogICAgICAgICAgDQogICAgICAgICAgbG9va3VwIHJlc29sdXRpb24uIElmIHRoZSBy ZWNlaXZlZCBNUExTIExhYmVsIHZhbHVlIGlzIG5vdA0KICAgICAgICAgIG51bGwsIHRoZSBy b3V0ZSBNVVNUIHN0aWxsIGJlIHVzZWQgZm9yIHJlY3Vyc2l2ZSBsb29rdXANCiAgICAgICAg ICByZXNvbHV0aW9uIGlmIHRoZSBsb2NhbCBwb2xpY3kgaW5zdHJ1Y3RzIHRoZSBpbmdyZXNz IE5WRSB0byBkbw0KICAgICAgICAgIHNvLg0KDQoqKioqIFNvIGEgbnVsbCBsYWJlbCB2YWx1 ZSBpbmhpYml0cyB0aGUgcmVjdXJzaXZlIHJlc29sdXRpb24gdW5sZXNzIGxvY2FsDQoqKioq IHBvbGljeSBzYXlzIHRvIGRvIGl0IGFueXdheT8/IElzIHRoYXQgcmVhbGx5IHlvdXIgaW50 ZW50aW9uLCBvciBpcyB0aGlzDQoqKioqIGEgcmV0cm9maXQgZm9yIGEgYnVnZ3kgaW1wbGVt ZW50YXRpb24gOy0pDQoNCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJj aCAyMiwgMjAxNw0KDQoNCiAgICAgICAgbyBUaGUgdG90YWwgcm91dGUgbGVuZ3RoIHdpbGwg aW5kaWNhdGUgdGhlIHR5cGUgb2YgcHJlZml4IChpcHY0DQogICAgICAgICAgb3IgaXB2Nikg YW5kIHRoZSB0eXBlIG9mIEdXIElQIGFkZHJlc3MgKGlwdjQgb3IgaXB2NikuIE5vdGUNCiAg ICAgICAgICB0aGF0IHRoZSBJUCBQcmVmaXggKyB0aGUgR1cgSVAgc2hvdWxkIGhhdmUgYSBs ZW5ndGggb2YgZWl0aGVyDQogICAgICAgICAgNjQgb3IgMjU2IGJpdHMsIGJ1dCBuZXZlciAx NjAgYml0cyAoaXB2NCBhbmQgaXB2NiBtaXhlZCB2YWx1ZXMNCiAgICAgICAgICBhcmUgbm90 IGFsbG93ZWQpLg0KDQogICBUaGUgRXRoLVRhZyBJRCwgSVAgUHJlZml4IExlbmd0aCBhbmQg SVAgUHJlZml4IHdpbGwgYmUgcGFydCBvZiB0aGUNCiAgIHJvdXRlIGtleSB1c2VkIGJ5IEJH UCB0byBjb21wYXJlIHJvdXRlcy4gVGhlIHJlc3Qgb2YgdGhlIGZpZWxkcyB3aWxsDQogICBu b3QgYmUgcGFydCBvZiB0aGUgcm91dGUga2V5Lg0KDQoqKioqIEFzIHdyaXR0ZW4sIHRoaXMg dGV4dCByZXF1aXJlcyBhIFJvdXRlIFJlZmxlY3RvciB0byBpZ25vcmUgdGhlIFJEIHdoZW4N CioqKiogY29uc2lkZXJpbmcgd2hldGhlciB0d28gcm91dGVzIGFyZSBjb21wYXJhYmxlLiAg VGhhdCdzIGp1c3Qgbm90IHJpZ2h0Lg0KDQoqKioqIFlvdSByZXBsaWVkOg0KDQpbSk9SR0Vd IFRoaXMgaXMgY29uc2lzdGVudCB3aXRoIFJGQzc0MzIsIHNlY3Rpb24gNywgaW4gd2hpY2gg dGhlIFJEIGlzDQphc3N1bWVkIHRvIGJlIHBhcnQgb2YgdGhlIHJvdXRlIGtleSBidXQgbm90 IG1lbnRpb25lZC4gSWYgd2UgZG9uJ3QgbWFrZQ0KdGhlIGRlc2NyaXB0aW9uIGluY29uc2lz dGVudCwgaXQgbWF5IGJlIGNvbmZ1c2luZz8gIEkgbGVmdCB0aGUgdGV4dCBhcyBpdCBpcw0K Zm9yIHRoZSB0aW1lIGJlaW5nLg0KDQoqKioqIFlvdSBtZWFuICJpZiB3ZSBkb24ndCBtYWtl IHRoZSBkZXNjcmlwdGlvbiBjb25zaXN0ZW50IiwgSSB0aGluay4NCg0KKioqKiBJTUhPIGl0 J3MgYSByYXRoZXIgYmFkIHByYWN0aWNlIGZvciBhIHNwZWNpZmljYXRpb24gdG8gcmVseSBv biB0aGluZ3MNCioqKiogdGhhdCBhcmUgYXNzdW1lZCBidXQgbm90IG1lbnRpb25lZC4gIEkg aGF2ZSBub3RpY2VkIHRoaXMgbWlzdGFrZSBpbiBSRkMNCioqKiogNzQzMi4gSXQgc2hvdWxk IG5vdCBwcm9wYWd0ZSBpbnRvIG90aGVyIGRvY3VtZW50cy4gIEkgdGhpbmsgaXQgd291bGQg YmUNCioqKiogYmV0dGVyIHRvIG1lbnRpb24gdGhlIFJEIGhlcmUgYW5kIHRvIGFsc28gc2F5 IHRoYXQgbWVudGlvbiBvZiB0aGUgUkQNCioqKiogd2FzIGluYWR2ZXJ0ZW50bHkgb21pdHRl ZCBmcm9tIFJGQyA3NDMyLiAgUGVyaGFwcyBhbiBlcnJhdHVtIHNob3VsZCBiZQ0KKioqKiBv cGVuZWQgb24gUkZDIDc0MzIuDQoNCg0KMy4yIE92ZXJsYXkgSW5kZXhlcyBhbmQgUmVjdXJz aXZlIExvb2t1cCBSZXNvbHV0aW9uDQoNCiAgIFJULTUgcm91dGVzIHN1cHBvcnQgcmVjdXJz aXZlIGxvb2t1cCByZXNvbHV0aW9uIHRocm91Z2ggdGhlIHVzZSBvZg0KICAgT3ZlcmxheSBJ bmRleGVzIGFzIGZvbGxvd3M6IA0KDQogICAgICAgIG8gQW4gT3ZlcmxheSBJbmRleCBjYW4g YmUgYW4gRVNJLCBJUCBhZGRyZXNzIChpbiB0aGUgYWRkcmVzcw0KICAgICAgICAgIHNwYWNl IG9mIHRoZSB0ZW5hbnQpIG9yIE1BQyBhZGRyZXNzIGFuZCBpdCBpcyB1c2VkIGJ5IGFuIE5W RQ0KDQoqKioqIENvbnNpZGVyIHJlbW92aW5nIHRoZSBwYXJlbnRoZXNlcywgYXMgdGhlIGZh Y3QgdGhhdCB0aGUgSVAgYWRkcmVzcyBpcw0KKioqKiBpbiB0aGUgdGVuYW50J3MgSVAgYWRk cmVzcyBzcGFjZSBpcyBjcnVjaWFsLg0KDQoqKioqIFRoZSBlbmQgb2Ygc2VjdGlvbiAyLjEg c3VnZ2VzdHMgdGhhdCBhbiBPdmVybGF5IEluZGV4IGNhbiBvbmx5IGJlIGFuDQoqKioqIEVT SSBvciBJUCBhZGRyZXNzLg0KICAgICAgICAgIA0KICAgICAgICAgIGFzIHRoZSBuZXh0LWhv cCBmb3IgYSBnaXZlbiBJUCBQcmVmaXguIEFuIE92ZXJsYXkgSW5kZXggYWx3YXlzDQogICAg ICAgICAgbmVlZHMgYSByZWN1cnNpdmUgcm91dGUgcmVzb2x1dGlvbiBvbiB0aGUgTlZFIHJl Y2VpdmluZyB0aGUgSVANCiAgICAgICAgICBQcmVmaXggcm91dGUsDQoNCioqKiogTW9yZSBw cmVjaXNlbHksIHJlY3Vyc2l2ZSByZXNvbHV0aW9uIG9mIHRoZSBPdmVybGF5IEluZGV4IG5l ZWRzIHRvIGJlDQoqKioqIGRvbmUgYnkgYW4gTlZFIHRoYXQgaW5zdGFsbHMgdGhlIFJULTUg cm91dGUgaW50byBvbmUgb2YgaXRzIElQLVZSRnMuDQoqKioqIEJ1dCBub3QgYXQgaW50ZXJt ZWRpYXRlIG5vZGVzIHRoYXQgbWVyZWx5IHByb3BhZ2F0ZSB0aGUgcm91dGUuIE5vdGUNCioq KiogdGhhdCBhbiBpbnRlcm1lZGlhdGUgbm9kZSBjYW4gYWxzbyBiZSBhbiBOVkUsIHNvIGl0 J3MgaW1wb3J0YW50IHRvIG5vdGUNCioqKiogdGhhdCByZWN1cnNpdmUgcmVzb2x1dGlvbiBv ZiB0aGUgT3ZlcmxheSBJbmRleCBhcHBsaWVzIHVwb24NCioqKiogaW5zdGFsbGF0aW9uIGlu dG8gYW4gSVAtVlJGLCBidXQgbm90IHVwb24gcHJvcGFnYXRpb24uICAoVGhpcyBkaWZmZXJz DQoqKioqIGZyb20gdGhlIG9yZGluYXJ5IHJlY3Vyc2l2ZSByZXNvbHV0aW9uIG9mIEJHUCBu ZXh0IGhvcHMuKQ0KDQoqKioqIEZvcnR1bmF0ZWx5LCBJUFZQTi9FVlBOIGludGVyb3BlcmFi aWxpdHkgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0KKioqKiBkb2N1bWVudCwgYmVj YXVzZSB0aGVyZSBpcyBub3cgd2F5IHRvIHBhc3MgYW4gT3ZlcmxheSBJbmRleCB0byB0aGUN CioqKiogSVBWUE4gcm91dGluZy4gIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoYXQncyBhbiBp c3N1ZSBvciBub3QsIGJ1dCBpdCdzDQoqKioqIHNvbWV0aGluZyB0byBrZWVwIGluIG1pbmQg d2hlbiBJUFZQTi9FVlBOIGludGVyd29ya2luZyBpcyBkaXNjdXNzZWQuDQoNCiAgICAgICAg ICB0aGF0IHRoZSBOVkUga25vd3MgdG8gd2hpY2ggZWdyZXNzIE5WRSBpdA0KICAgICAgICAg IG5lZWRzIHRvIGZvcndhcmQgdGhlIHBhY2tldHMuIFRoZSBlZ3Jlc3MgTlZFIG1heSBub3Qg YmUgdGhlDQoNCioqKiogUGVyaGFwcyAibWF5IG5vdCIgLS0+ICJuZWVkIG5vdCIsIGFzICJt YXkgbm90IiBjb3VsZCBiZSBpbnRlcnByZXRlZCB0bw0KKioqKiBiZSBzeW5vbm9tb3VzIGJl ICJtdXN0IG5vdCIgaW4gZW5nbGlzaC4NCiAgICAgICAgICANCiAgICAgICAgICBzYW1lIE5W RSB0aGF0IG9yaWdpbmF0ZWQgdGhlIFJULTUuDQoNCiAgICAgICAgbyBUaGUgT3ZlcmxheSBJ bmRleCBpcyBpbmRpY2F0ZWQgYWxvbmcgd2l0aCB0aGUgUlQtNSBpbiB0aGUgRVNJDQogICAg ICAgICAgZmllbGQsIEdXIElQIGZpZWxkIG9yIFJvdXRlcidzIE1BQyBFeHRlbmRlZCBDb21t dW5pdHksDQogICAgICAgICAgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlIElQIFByZWZpeCBu ZXh0LWhvcCBpcyBhbiBFU0ksIElQDQogICAgICAgICAgYWRkcmVzcyBvciBNQUMgYWRkcmVz cyBpbiB0aGUgdGVuYW50IHNwYWNlLiBUaGUgT3ZlcmxheSBJbmRleA0KICAgICAgICAgIGZv ciBhIGdpdmVuIElQIFByZWZpeCBpcyBzZXQgYnkgbG9jYWwgcG9saWN5ICh0eXBpY2FsbHkN CiAgICAgICAgICBtYW5hZ2VkIGJ5IHRoZSBDbG91ZCBNYW5hZ2VtZW50IFN5c3RlbSkuDQoN CioqKiogU2V0IGJ5IGxvY2FsIHBvbGljeSBhdCB0aGUgTlZFIHRoYXQgb3JpZ2luYXRlcyBh biBSVC01IGZvciB0aGF0IElQDQoqKioqIHByZWZpeCwgbm90IGJ5IGxvY2FsIHBvbGljeSBh dCB0aGUgTlZFIGluc3RhbGxpbmcgdGhlIFJULTUuDQoNCiAgICAgICAgbyBJbiBvcmRlciB0 byBlbmFibGUgdGhlIHJlY3Vyc2l2ZSBsb29rdXAgcmVzb2x1dGlvbiBhdCB0aGUNCiAgICAg ICAgICBpbmdyZXNzIE5WRSwgdGhlIGVncmVzcyBOVkUgdGhhdCBvd25zIHRoZSBPdmVybGF5 IEluZGV4IG11c3QNCg0KKioqKiBQZXJoYXBzOiAidGhlIGVncmVzcyBOVkUgdGhhdCBvd25z IHRoZSBPdmVybGF5IEluZGV4IiAtLT4gImFuIE5WRSB0aGF0DQoqKioqIGlzIGEgcG9zc2li bGUgZWdyZXNzIE5WRSBmb3IgYSBnaXZlbiBPdmVybGF5IEluZGV4Ig0KICAgICAgICAgIA0K ICAgICAgICAgIGFkdmVydGlzZSB0aGUgbG9jYXRpb24gb2YgdGhlIE92ZXJsYXkgSW5kZXgu DQoNCioqKiogUGVyaGFwczogIm11c3QgYWR2ZXJ0aXNlIHRoZSBsb2NhdGlvbiBvZiIgLS0+ ICJtdXN0IG9yaWdpbmF0ZSBhIHJvdXRlDQoqKioqIGFkdmVydGlzaW5nIGl0c2VsZiBhcyB0 aGUgQkdQIG5leHQgaG9wIG9uIHRoZSBwYXRoIHRvIHRoZSBzeXN0ZW0NCioqKiogZGVub3Rl ZCBieSB0aGUgT3ZlcmxheSBJbmRleCIuDQoNCiAgICAgICAgICBGb3IgaW5zdGFuY2UsIGlm DQogICAgICAgICAgdGhlIElQIFByZWZpeCBvcmlnaW5hdGluZyBOVkUgc2VuZHMgYW4gUlQt NSB3aXRoIEVTSS0xIGFzDQogICAgICAgICAgT3ZlcmxheSBJbmRleCwgdGhlbiB0aGUgaW5n cmVzcyBOVkUgd2lsbCBleHBlY3QgYW4gUlQtMSAoQXV0by0NCiAgICAgICAgICBEaXNjb3Zl cnkgcGVyLUVWSSByb3V0ZSkgd2l0aCBFU0ktMSB0byBiZSByZWNlaXZlZCBmcm9tIHRoZQ0K ICAgICAgICAgIGVncmVzcyBOVkUuIElmIHRoZSBPdmVybGF5IEluZGV4IGlzIGVuY29kZWQg aW4gdGhlIEdXIElQIGZpZWxkDQogICAgICAgICAgb3IgdGhlIFJvdXRlcidzIE1BQyBFeHRl bmRlZCBDb21tdW5pdHksIHRoZSBpbmdyZXNzIE5WRSB3aWxsDQogICAgICAgICAgZXhwZWN0 IGFuIFJULTIgKE1BQy9JUCByb3V0ZSkgZnJvbSB0aGUgZWdyZXNzIE5WRSBzbyB0aGF0IHRo ZQ0KICAgICAgICAgIE92ZXJsYXkgSW5kZXggY2FuIGJlIHJlc29sdmVkLg0KDQoqKioqIEkg ZmluZCB0aGUgYWJvdmUgcGFyYWdyYXBoIGEgYml0IGhhcmQgdG8gdW5kZXJzdGFuZCwgYXMg dGhlIHBocmFzZSAidGhlDQoqKioqIGluZ3Jlc3MgTlZFIHdpbGwgZXhwZWN0IGFuIFJUIC4u LmZyb20gdGhlIGVncmVzcyBOVkUiIHNvcnQgb2Ygc3VnZ2VzdHMNCioqKiogdGhhdCB0aGUg aW5ncmVzcyBOVkUga25vd3MgaW4gYWR2YW5jZSB3aG8gdGhlIGVncmVzcyBOVkUgaXMuICBQ ZXJoYXBzDQoqKioqIGNvbnNpZGVyIHNvbWV0aGluZyBsaWtlOg0KDQogICAgICAgIkZvciBp bnN0YW5jZSwgaWYgYW4gTlZFIHJlY2VpdmVzIGFuIFJULTUgdGhhdCBzcGVjaWZpZXMgYW4g T3ZlcmxheQ0KICAgICAgIEluZGV4LCB0aGUgTlZFIGNhbm5vdCBpbnN0YWxsIHRoZSBSVC01 IGluIGl0cyBJUC1WUkYgdW5sZXNzIChvcg0KICAgICAgIHVudGlsKSBpdCBjYW4gcmVjdXJz aXZlbHkgcmVzb2x2ZSB0aGUgT3ZlcmxheSBJbmRleC4gIElmIHRoZSBSVC01DQogICAgICAg c3BlY2lmaWVzIGFuIEVTSSBhcyB0aGUgT3ZlcmxheSBJbmRleCwgcmVjdXJzaXZlIHJlc29s dXRpb24gY2FuIG9ubHkNCiAgICAgICBiZSBkb25lIGlmIHRoZSBOVkUgaGFzIHJlY2VpdmVk IGFuZCBpbnN0YWxsZWQgYW4gUlQtMSAoQXV0by1EaXNjb3ZlcnkNCiAgICAgICBwZXItRVZJ KSByb3V0ZSBzcGVjaWZ5aW5nIHRoYXQgRVNJLiAgSWYgdGhlIFJULTUgc3BlY2lmaWVzIGEg R1cgSVANCiAgICAgICBhZGRyZXNzIGFzIHRoZSBPdmVybGF5IEluZGV4LCByZWN1cnNpdmUg cmVzb2x1dGlvbiBjYW4gb25seSBiZSBkb25lDQogICAgICAgaWYgdGhlIE5WRSBoYXMgcmVj ZWl2ZWQgYW5kIGluc3RhbGxlZCBhbiBSVC0yIChNQUMvSVAgcm91dGUpDQogICAgICAgc3Bl Y2lmeWluZyB0aGF0IElQIGFkZHJlc3MgaW4gdGhlIElQIGFkZHJlc3MgZmllbGQgb2YgaXRz IE5MUkkuICBJZg0KICAgICAgIHRoZSBSVC01IHNwZWNpZmllcyBhIE1BQyBhZGRyZXNzIGFz IHRoZSBPdmVybGF5IEluZGV4LCByZWN1cnNpdmUNCiAgICAgICByZXNvbHV0aW9uIGNhbiBv bmx5IGJlIGRvbmUgaWYgdGhlIE5WRSBoYXMgcmVjZWl2ZWQgYW5kIGluc3RhbGxlZCBhbg0K ICAgICAgIFJULTIgKE1BQy9JUCByb3V0ZSkgc3BlY2lmeWluZyB0aGF0IE1BQyBhZGRyZXNz IGluIHRoZSBNQUMgYWRkcmVzcw0KICAgICAgIGZpZWxkIG9mIGl0cyBOTFJJLiINCg0KICAg ICAgIk5vdGUgdGhhdCB0aGUgUlQtMSBvciBSVC0yIHJvdXRlcyBuZWVkZWQgZm9yIHRoZSBy ZWN1cnNpdmUgcmVzb2x1dGlvbg0KICAgICAgbWF5IGFycml2ZSBiZWZvcmUgb3IgYWZ0ZXIg dGhlIGdpdmVuIFJULTUgcm91dGUuIg0KDQoqKioqIChJdCdzIGFsd2F5cyBhIGdvb2QgaWRl YSB0byBtZW50aW9uIHRoYXQgdGhpbmdzIGNhbiBjb21lIG91dCBvZiBvcmRlci4pDQoNCioq KiogT3JkaW5hcmlseSwgQkdQIHdpbGwgZG8gcmVjdXJzaXZlIG5leHQgaG9wIHJlc29sdXRp b24gaWYgdGhlcmUgaXMgYSBCR1ANCioqKiogcm91dGUgYnV0IG5vIElHUCBvciBzdGF0aWMg cm91dGUgdG8gdGhlIEJHUCBuZXh0IGhvcC4gIEhlcmUgeW91IGFyZQ0KKioqKiByZXF1aXJp bmcgcmVjdXJzaXZlIHJlc29sdXRpb24gKHVwb24gaW5zdGFsbGF0aW9uIG9mIGFuIFJULTUg aW50byBhbg0KKioqKiBJUC1WUkYpIHdoZW5ldmVyIHRoZXJlIGlzIGFuIE92ZXJsYXkgSW5k ZXgsIGluZGVwZW5kZW50IG9mIHdoYXQgc29ydCBvZg0KKioqKiByb3V0ZSB0aGVyZSBpcyB0 byB0aGUgQkdQIG5leHQgaG9wLiAgVGhpcyBoYXMgdG8gYmUgbWFkZSB2ZXJ5IGNsZWFyLg0K KioqKiBOb3RlIGFsc28gdGhhdCBpZiB0aGVyZSBpcyBubyBJR1Agcm91dGUgdG8gdGhlIEJH UCBuZXh0IGhvcCBvZiBhbiBSVC01LA0KKioqKiBCR1AgbWF5IGZhaWwgdG8gaW5zdGFsbCB0 aGUgUlQtNSBldmVuIGlmIHRoZSBPdmVybGF5IEluZGV4IGNhbiBiZQ0KKioqKiByZXNvbHZl ZC4gIFRoaXMgbWF5IGNhdXNlIHNvbWUgdW5leHBlY3RlZCBiZWhhdmlvciBpZiBhbiBlZ3Jl c3MgTlZFDQoqKioqIGdvZXMgZG93bi4NCg0KICAgICAgICBvIElmIHRoZSBFU0kgZmllbGQg aXMgZGlmZmVyZW50IHRoYW4gemVybywgdGhlIEdXIElQIGZpZWxkIHdpbGwNCiAgICAgICAg ICBiZSB6ZXJvLCBhbmQgdmljZSB2ZXJzYS4gQSByb3V0ZSBjb250YWluaW5nIGEgbm9uLXpl cm8gR1cgSVANCiAgICAgICAgICBhbmQgYSBub24temVybyBFU0kgd2lsbCBiZSB0cmVhdGVk IGFzLXdpdGhkcmF3Lg0KDQoqKioqIElzbid0IHRoZXJlIGEgdmFsaWQgY2FzZSB3aGVyZSB0 aGUgR1cgSVAgYW5kIEVTSSBmaWVsZHMgYXJlIHplcm8sIGJ1dA0KKioqKiB0aGUgb3Zlcmxh eSBpbmRleCBpcyBjYXJyaWVkIGluIHRoZSBSb3V0ZXIncyBNQUMgRUM/ICBBYm92ZSBzZWVt cyB0bw0KKioqKiBzYXkgdGhhdCB0aGV5IGNhbm5vdCBib3RoIGJlIHplcm8uDQoNCioqKiog SWYgYm90aCBmaWVsZHMgYXJlIHplcm8gYW5kIHRoZSBSb3V0ZXIncyBNQUMgRUMgaXMgbm90 IHByZXNlbnQsIGRvIHdlDQoqKioqIGFsc28gd2FudCB0byBkbyBhICJ0cmVhdC1hcy13aXRo ZHJhdyI/ICBJIHRoaW5rIGl0J3MgYSBiaXQgYXdrd2FyZCB0bw0KKioqKiBzb21ldGltZXMg aGF2ZSB0aGUgT3ZlcmxheSBJbmRleCBpbiB0aGUgTkxSSSBhbmQgc29tZXRpbWVzIGluIHRo ZSBFQw0KKioqKiBhdHRyaWJ1dGUsIGJ1dCBJIHN1cHBvc2UgaXQncyB3YXkgdG9vIGxhdGUg dG8gZml4IHRoYXQuDQoNCioqKiogRG9lcyBhbiBSVC01IGFsd2F5cyBoYXZlIHRvIGhhdmUg YW4gT3ZlcmxheSBJbmRleCByZXF1aXJpbmcgcmVjdXJzaXZlDQoqKioqIHJlc29sdXRpb24s IG9yIGlzIHRoZXJlIHNvbWUgd2F5IHRvIHNwZWNpZnkgaW4gYW4gUlQtNSB0aGF0IHRoZQ0K KioqKiBvcmRpbmFyeSBCR1AgbmV4dCBob3AgZmllbGQgaXMgdG8gYmUgdXNlZCBhcyB0aGUg bmV4dCBob3A/ICBJcyB0aGF0IHRoZQ0KKioqKiBjYXNlIHdoZXJlIGJvdGggR1cgSVAgYW5k IEVTSSBhcmUgemVybyBidXQgdGhlIFJvdXRlcidzIE1BQyBFQyBpcyBub3QNCioqKiogcHJl c2VudD8NCg0KKioqKiBMYXRlciBvbiB0aGVyZSBpcyBzb21lIHN1Z2dlc3Rpb24gdGhhdCBy ZWN1cnNpdmUgcmVzb2x1dGlvbiBjYW4gYmUNCioqKiogYXZvaWRlZCBpZiB0aGUgTVBMUyBs YWJlbCBmaWVsZCBpcyBub24temVyby4gIEl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZQ0KKioq KiBvbmUgcGxhY2UgdGhhdCBzYXlzLCBmb3IgZWFjaCBjb21iaW5hdGlvbiBvZiB6ZXJvL25v bi16ZXJvIGluIHRoZSBHVw0KKioqKiBJUCwgRVNJLCBhbmQgTGFiZWwgZmllbGRzLCBhbmQg aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiB0aGUgUm91dGUncw0KKioqKiBNQUMgRUMsIHdo YXQgd2UgY2FuIGNvbmNsdWRlIGFib3V0IHRoZSBPdmVybGF5IEluZGV4Lg0KDQogICBUaGUg dXNlIG9mIE92ZXJsYXkgSW5kZXhlcyBkZWNvdXBsZXMgdGhlIG9yaWdpbmF0aW9uIG9mIHRo ZSBSVC01IGZyb20NCiAgIHRoZSBkZXNpcmVkIGVncmVzcyBOVkUgZm9yIHRoZSBJUCBQcmVm aXguDQoNCioqKiogSSBmaW5kIHRoZSBhYm92ZSBzZW50ZW5jZSBjb25mdXNpbmcsIGJ1dCBJ IHRoaW5rIGl0IGNhbiBqdXN0IGJlDQoqKioqIG9taXR0ZWQuIA0KDQogICBUaGUgaW5kaXJl Y3Rpb24gcHJvdmlkZWQgYnkNCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBN YXJjaCAyMiwgMjAxNw0KDQoNCiAgIHRoZSBPdmVybGF5IEluZGV4IGFuZCBpdHMgcmVjdXJz aXZlIGxvb2t1cCByZXNvbHV0aW9uIGlzIHJlcXVpcmVkIHRvDQogICBhY2hpZXZlIGZhc3Qg Y29udmVyZ2VuY2UgaW4gY2FzZSBvZiBhIGZhaWx1cmUgb2YgdGhlIG9iamVjdA0KICAgcmVw cmVzZW50ZWQgYnkgdGhlIE92ZXJsYXkgSW5kZXguIEZvciBpbnN0YW5jZTogaW4gRmlndXJl IDEsIGxldCdzDQogICBhc3N1bWUgTlZFMi9OVkUzIGFkdmVydGlzZSAxayBSVC01IHJvdXRl cyBhc3NvY2lhdGVkIHRvIHRoZSBmbG9hdGluZw0KICAgSVAgYWRkcmVzcyAoR1dJUD12SVAy MykgYW5kIE5WRTIgYWR2ZXJ0aXNlcyBhbiBSVC0yIGNsYWltaW5nIHRoZQ0KICAgb3duZXJz aGlwIG9mIHRoZSBmbG9hdGluZyBJUCwgaS5lLiBOVkUyIGVuY29kZXMgdklQMjMgYW5kIE0y IGluIHRoZQ0KICAgUlQtMi4gV2hlbiB0aGUgZmxvYXRpbmcgSVAgb3duZXIgY2hhbmdlcyBm cm9tIE0yIHRvIE0zLCBhIHNpbmdsZSBSVC0yDQogICB3aXRoZHJhdy91cGRhdGUgaXMgcmVx dWlyZWQgdG8gaW5kaWNhdGUgdGhlIGNoYW5nZS4gVGhlIHJlbW90ZSBER1cNCiAgIHdpbGwg bm90IGNoYW5nZSBhbnkgb2YgdGhlIDFrIHByZWZpeGVzIGFzc29jaWF0ZWQgdG8gdklQMjMs IGJ1dCB3aWxsDQogICBvbmx5IHVwZGF0ZSB0aGUgQVJQIHJlc29sdXRpb24gZW50cnkgZm9y IHZJUDIzIChub3cgcG9pbnRpbmcgYXQgTTMpLg0KDQogICBUaGUgZm9sbG93aW5nIHRhYmxl IHNob3dzIHRoZSBkaWZmZXJlbnQgaW50ZXItc3VibmV0IHVzZS1jYXNlcw0KICAgZGVzY3Jp YmVkIGluIHRoaXMgZG9jdW1lbnQgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGNvZGluZyBvZiB0 aGUNCiAgIG92ZXJsYXkgaW5kZXggaW4gdGhlIHJvdXRlIHR5cGUgNSAoUlQtNSkuIFRoZSBJ UC1WUkYtdG8tSVAtVlJGIG9yIElSQg0KICAgZm9yd2FyZGluZyBvbiBOVkVzIGNhc2UgaXMg YSBzcGVjaWFsIHVzZS1jYXNlLCB3aGVyZSB0aGVyZSBtYXkgYmUgbm8NCiAgIG5lZWQgZm9y IE92ZXJsYXkgSW5kZXgsIHNpbmNlIHRoZSBhY3R1YWwgbmV4dC1ob3AgaXMgZ2l2ZW4gYnkg dGhlIEJHUA0KICAgbmV4dC1ob3AuDQoNCioqKiogVGhlbiB0aGUgdGFibGUgYmVsb3cgc2hv dWxkIGFsbG93ICJub25lIiBhcyBhIHBvc3NpYmxlIE92ZXJsYXkgSW5kZXgNCioqKiogaW4g dGhlIElQLVZSRi10by1JUC1WUkYgY2FzZS4gIEFsc28sIHRoZSBkcmFmdCBzaG91bGQgc2F5 IHZlcnkgY2xlYXJseQ0KKioqKiBob3cgeW91IGVuY29kZSB0aGUgZmFjdCB0aGF0IHRoZXJl IGlzIG5vIE92ZXJsYXkgSW5kZXguDQoNCiAgIFdoZW4gYW4gT3ZlcmxheSBJbmRleCBpcyBw cmVzZW50IGluIHRoZSBSVC01LCB0aGUgcmVjZWl2aW5nDQogICBOVkUgd2lsbCBuZWVkIHRv IHBlcmZvcm0gYSByZWN1cnNpdmUgcm91dGUgcmVzb2x1dGlvbiB0byBmaW5kIHRoZQ0KICAg ZWdyZXNzIE5WRSB0byBmb3J3YXJkIHRoZSBwYWNrZXRzLg0KDQoNCiAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgfCBVc2UtY2FzZSAgICAgICAgICAgICAgICAgICB8IE92ZXJsYXkgSW5kZXgg aW4gdGhlIFJULTUgQkdQIHVwZGF0ZSB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgVFMg SVAgYWRkcmVzcyAgICAgICAgICAgICAgfCBPdmVybGF5IEdXIElQIEFkZHJlc3MgICAgICAg ICAgICAgICAgfA0KICAgfCBGbG9hdGluZyBJUCBhZGRyZXNzICAgICAgICB8IE92ZXJsYXkg R1cgSVAgQWRkcmVzcyAgICAgICAgICAgICAgICB8DQogICB8ICJCdW1wIGluIHRoZSB3aXJl IiAgICAgICAgIHwgRVNJIG9yIE1BQyAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg IHwgSVAtVlJGLXRvLUlQLVZSRiAgICAgICAgICAgfCBPdmVybGF5IEdXIElQLCBNQUMgb3Ig Ti9BICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCioqKiogVGhpcyB0YWJs ZSBzYXlzIHdoYXQga2luZCBvZiBPdmVybGF5IEluZGV4IGlzIG5lZWRlZCBpbiBlYWNoIHVz ZSBjYXNlLA0KKioqKiBidXQgZG9lcyBub3Qgc2F5IGhvdyB5b3Uga25vdyBmcm9tIGEgcmVj ZWl2ZWQgUlQtNSB3aGF0IGtpbmQgb2YgT3ZlcmxheQ0KKioqKiBJbmRleCBpcyBiZWluZyBh ZHZlcnRpc2VkLg0KDQogICBUaGUgYWJvdmUgdXNlLWNhc2VzIGFyZSByZXByZXNlbnRhdGl2 ZSBvZiB0aGUgZGlmZmVyZW50IE92ZXJsYXkNCiAgIEluZGV4ZXMgc3VwcG9ydGVkIGJ5IFJU LTUgKEdXIElQLCBFU0ksIE1BQyBvciBOL0EpLiBBbnkgb3RoZXIgdXNlLQ0KICAgY2FzZSB1 c2luZyBhIGdpdmVuIE92ZXJsYXkgSW5kZXgsIFNIT1VMRCBmb2xsb3cgdGhlIHByb2NlZHVy ZXMNCiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGZvciB0aGUgc2FtZSBPdmVybGF5 IEluZGV4LiANCg0KDQo0LiBJUCBQcmVmaXggT3ZlcmxheSBJbmRleCB1c2UtY2FzZXMNCg0K ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBzb21lIHVzZS1jYXNlcyBmb3IgdGhlIE92ZXJs YXkgSW5kZXggdHlwZXMuDQoNCjQuMSBUUyBJUCBhZGRyZXNzIE92ZXJsYXkgSW5kZXggdXNl LWNhc2UgDQoNCiAgIFRoZSBmb2xsb3dpbmcgZmlndXJlIGlsbHVzdHJhdGVzIGFuIGV4YW1w bGUgb2YgaW50ZXItc3VibmV0DQogICBmb3J3YXJkaW5nIGZvciBzdWJuZXRzIHNpdHRpbmcg YmVoaW5kIFZpcnR1YWwgQXBwbGlhbmNlcyAob24gVFMyIGFuZA0KICAgVFMzKS4NCg0KDQoN CiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAy MDE3ICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg RVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJjaCAyMiwgMjAxNw0KDQoN CiAgIFNOMS0tLSsgICAgICAgICAgIE5WRTIgICAgICAgICAgICAgICAgICAgICAgICAgICAg REdXMQ0KICAgICAgICAgfCAgICAgICAgKy0tLS0tLS0tLS0tKyArLS0tLS0tLS0tKyAgICAr LS0tLS0tLS0tLS0tLSsNCiAgIFNOMi0tLVRTMihWQSktLXwoTUFDLVZSRjEwKXwtfCAgICAg ICAgIHwtLS0tfChNQUMtVlJGMTApICB8DQogICAgICAgICB8IElQMi9NMiArLS0tLS0tLS0t LS0rIHwgICAgICAgICB8ICAgIHwgICAgSVJCMVwgICAgfA0KICAgSVA0LS0tKyAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICB8ICAgICAoSVAtVlJGKXwtLS0rDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICstLS0tLS0tLS0t LS0tKyAgX3xfDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFZYTEFOLyB8 ICAgICAgICAgICAgICAgICAgICAoICAgKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICBudkdSRSAgfCAgICAgICAgIERHVzIgICAgICAoIFdBTiApDQogICBTTjEtLS0r ICAgICAgICAgICBOVkUzICAgICAgIHwgICAgICAgICB8ICAgICstLS0tLS0tLS0tLS0tKyAo X19fKQ0KICAgICAgICAgfCBJUDMvTTMgKy0tLS0tLS0tLS0tKyB8ICAgICAgICAgfC0tLS18 KE1BQy1WUkYxMCkgIHwgICB8DQogICBTTjMtLS1UUzMoVkEpLS18KE1BQy1WUkYxMCl8LXwg ICAgICAgICB8ICAgIHwgICAgSVJCMlwgICAgfCAgIHwNCiAgICAgICAgIHwgICAgICAgICst LS0tLS0tLS0tLSsgKy0tLS0tLS0tLSsgICAgfCAgICAgKElQLVZSRil8LS0tKw0KICAgSVA1 LS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LSsNCg0KICAgICAgICAgICAgICAgICAgRmlndXJlIDIgVFMgSVAgYWRkcmVzcyB1c2UtY2Fz ZQ0KDQogICBBbiBleGFtcGxlIG9mIGludGVyLXN1Ym5ldCBmb3J3YXJkaW5nIGJldHdlZW4g c3VibmV0IFNOMS8yNCBhbmQgYQ0KICAgc3VibmV0IHNpdHRpbmcgaW4gdGhlIFdBTiBpcyBk ZXNjcmliZWQgYmVsb3cuIE5WRTIsIE5WRTMsIERHVzEgYW5kDQogICBER1cyIGFyZSBydW5u aW5nIEJHUCBFVlBOLiBUUzIgYW5kIFRTMyBkbyBub3QgcGFydGljaXBhdGUgaW4gZHluYW1p Yw0KICAgcm91dGluZyBwcm90b2NvbHMsIGFuZCB0aGV5IG9ubHkgaGF2ZSBhIHN0YXRpYyBy b3V0ZSB0byBmb3J3YXJkIHRoZQ0KICAgdHJhZmZpYyB0byB0aGUgV0FOLiANCg0KICAgSW4g dGhpcyBjYXNlLCBhIEdXIElQIGlzIHVzZWQgYXMgYW4gT3ZlcmxheSBJbmRleC4gQWx0aG91 Z2ggYQ0KICAgZGlmZmVyZW50IE92ZXJsYXkgSW5kZXggdHlwZSBjb3VsZCBoYXZlIGJlZW4g dXNlZCwgdGhpcyB1c2UtY2FzZQ0KICAgYXNzdW1lcyB0aGF0IHRoZSBvcGVyYXRvciBrbm93 cyB0aGUgVkEncyBJUCBhZGRyZXNzZXMgYmVmb3JlaGFuZCwNCiAgIHdoZXJlYXMgdGhlIFZB J3MgTUFDIGFkZHJlc3MgaXMgdW5rbm93biBhbmQgdGhlIFZBJ3MgRVNJIGlzIHplcm8uDQog ICBCZWNhdXNlIG9mIHRoaXMsIHRoZSBHVyBJUCBpcyB0aGUgc3VpdGFibGUgT3ZlcmxheSBJ bmRleCB0byBiZSB1c2VkDQogICB3aXRoIHRoZSBSVC01cy4gVGhlIE5WRXMga25vdyB0aGUg R1cgSVAgdG8gYmUgdXNlZCBmb3IgYSBnaXZlbiBQcmVmaXgNCiAgIGJ5IHBvbGljeS4gIA0K DQogICAoMSkgTlZFMiBhZHZlcnRpc2VzIHRoZSBmb2xsb3dpbmcgQkdQIHJvdXRlcyBvbiBi ZWhhbGYgb2YgVFMyOg0KDQogICAgICAgIG8gUm91dGUgdHlwZSAyIChNQUMvSVAgcm91dGUp IGNvbnRhaW5pbmc6IE1MPTQ4LCBNPU0yLCBJUEw9MzIsDQogICAgICAgICAgSVA9SVAyIGFu ZCBbUkZDNTUxMl0gQkdQIEVuY2Fwc3VsYXRpb24gRXh0ZW5kZWQgQ29tbXVuaXR5IHdpdGgN CiAgICAgICAgICB0aGUgY29ycmVzcG9uZGluZyBUdW5uZWwtdHlwZS4gVGhlIE1BQyBhbmQg SVAgYWRkcmVzc2VzIG1heSBiZQ0KICAgICAgICAgIGxlYXJuZWQgdmlhIEFSUC1zbm9vcGlu ZyAoTkQtc25vb3BpbmcgaWYgSVB2NikuIA0KDQogICAgICAgIG8gUm91dGUgdHlwZSA1IChJ UCBQcmVmaXggcm91dGUpIGNvbnRhaW5pbmc6IElQTD0yNCwgSVA9U04xLA0KICAgICAgICAg IEVTST0wLCBHVyBJUCBhZGRyZXNzPUlQMi4gVGhlIHByZWZpeCBhbmQgR1cgSVAgYXJlIGxl YXJuZWQgYnkNCiAgICAgICAgICBwb2xpY3kuDQoNCiAgICgyKSBTaW1pbGFybHksIE5WRTMg YWR2ZXJ0aXNlcyB0aGUgZm9sbG93aW5nIEJHUCByb3V0ZXMgb24gYmVoYWxmIG9mDQogICAg ICAgICAgVFMzOg0KDQogICAgICAgIG8gUm91dGUgdHlwZSAyIChNQUMvSVAgcm91dGUpIGNv bnRhaW5pbmc6IE1MPTQ4LCBNPU0zLCBJUEw9MzIsDQogICAgICAgICAgSVA9SVAzIChhbmQg QkdQIEVuY2Fwc3VsYXRpb24gRXh0ZW5kZWQgQ29tbXVuaXR5KS4NCg0KICAgICAgICBvIFJv dXRlIHR5cGUgNSAoSVAgUHJlZml4IHJvdXRlKSBjb250YWluaW5nOiBJUEw9MjQsIElQPVNO MSwNCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIz LCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJjaCAyMiwgMjAxNw0K DQoNCiAgICAgICAgICBFU0k9MCwgR1cgSVAgYWRkcmVzcz1JUDMuDQoNCiAgICgzKSBER1cx IGFuZCBER1cyIGltcG9ydCBib3RoIHJlY2VpdmVkIHJvdXRlcyBiYXNlZCBvbiB0aGUNCiAg ICAgICByb3V0ZS10YXJnZXRzOg0KDQogICAgICAgIG8gQmFzZWQgb24gdGhlIE1BQy1WUkYx MCByb3V0ZS10YXJnZXQgaW4gREdXMSBhbmQgREdXMiwgdGhlDQogICAgICAgICAgTUFDL0lQ IHJvdXRlIGlzIGltcG9ydGVkIGFuZCBNMiBpcyBhZGRlZCB0byB0aGUgTUFDLVZSRjEwDQog ICAgICAgICAgYWxvbmcgd2l0aCBpdHMgY29ycmVzcG9uZGluZyB0dW5uZWwgaW5mb3JtYXRp b24uDQoNCioqKiogQWJvdmUgaXMgYWJvdXQgdGhlIFJULTIgZnJvbSBOVkUyLiAgRG9uJ3Qg dGhlIERHV3MgYWxzbyBpbXBvcnQgdGhlIFJULTINCioqKiogZnJvbSBOVkUzPyAgDQoNCiAg ICAgICAgICBGb3IgaW5zdGFuY2UsDQogICAgICAgICAgaWYgVlhMQU4gaXMgdXNlZCwgdGhl IFZURVAgd2lsbCBiZSBkZXJpdmVkIGZyb20gdGhlIE1BQy9JUA0KICAgICAgICAgIHJvdXRl IEJHUCBuZXh0LWhvcCBhbmQgVk5JIGZyb20gdGhlIE1QTFMgTGFiZWwxIGZpZWxkLiBJUDIg LQ0KICAgICAgICAgIE0yIGlzIGFkZGVkIHRvIHRoZSBBUlAgdGFibGUuDQoNCioqKiogQXMg d2VsbCBhcyBJUDMvTTMsIHJpZ2h0PyAgICAgICAgICANCg0KICAgICAgICBvIEJhc2VkIG9u IHRoZSBNQUMtVlJGMTAgcm91dGUtdGFyZ2V0IGluIERHVzEgYW5kIERHVzIsIHRoZSBJUA0K ICAgICAgICAgIFByZWZpeCByb3V0ZSBpcyBhbHNvIGltcG9ydGVkIGFuZCBTTjEvMjQgaXMg YWRkZWQgdG8gdGhlIElQLQ0KICAgICAgICAgIFZSRiB3aXRoIE92ZXJsYXkgSW5kZXggSVAy IHBvaW50aW5nIGF0IHRoZSBsb2NhbCBNQUMtVlJGMTAuDQogICAgICAgICAgU2hvdWxkIEVD TVAgYmUgZW5hYmxlZCBpbiB0aGUgSVAtVlJGLCBTTjEvMjQgd291bGQgYWxzbyBiZQ0KICAg ICAgICAgIGFkZGVkIHRvIHRoZSByb3V0aW5nIHRhYmxlIHdpdGggT3ZlcmxheSBJbmRleCBJ UDMuDQoNCioqKiogV2l0aCByZWdhcmQgdG8gdGhlIFJULTVzLCBpc24ndCBpdCB0cnVlIHRo YXQgQkdQIGJlc3RwYXRoIHNlbGVjdGlvbiBpcw0KKioqKiBhcHBsaWVkLCBhbmQgb25lIG9m IHRoZSBSVC01cyAoZWl0aGVyIGZyb20gTlZFMiBvciBOVkUzKSBpcyBzZWxlY3RlZCBhcw0K KioqKiB0aGUgYmVzdHBhdGg/ICBGcm9tIHRoZSBleGFtcGxlIHdlIGNhbid0IHRlbGwgd2hp Y2ggd291bGQgYmUNCioqKiogcHJlZmVycmVkLiAgSSB0aGluayBFQ01QIGFwcGxpZXMgb25s eSBpZiBib3RoIFJULTVzIGFyZSBlcXVhbGx5DQoqKioqIHByZWZlcmFibGUuIA0KDQogICAo NCkgV2hlbiBER1cxIHJlY2VpdmVzIGEgcGFja2V0IGZyb20gdGhlIFdBTiB3aXRoIGRlc3Rp bmF0aW9uIElQeCwNCiAgICAgICB3aGVyZSBJUHggYmVsb25ncyB0byBTTjEvMjQ6DQoNCiAg ICAgICAgbyBBIGRlc3RpbmF0aW9uIElQIGxvb2t1cCBpcyBwZXJmb3JtZWQgb24gdGhlIERH VzEgSVAtVlJGDQogICAgICAgICAgcm91dGluZyB0YWJsZSBhbmQgT3ZlcmxheSBJbmRleD1J UDIgaXMgZm91bmQuDQoNCioqKiogQXNzdW1pbmcgdGhhdCB0aGUgcm91dGUgZnJvbSBOVkUy IHdhcyBwcmVmZXJyZWQgZm9yIHNvbWUgcmVhc29uIHRvIHRoZQ0KKioqKiByb3V0ZSBmcm9t IE5WRTM/Pw0KICAgICAgICAgIA0KICAgICAgICAgIFNpbmNlIElQMiBpcyBhbg0KICAgICAg ICAgIE92ZXJsYXkgSW5kZXggYSByZWN1cnNpdmUgcm91dGUgcmVzb2x1dGlvbiBpcyByZXF1 aXJlZCBmb3INCiAgICAgICAgICBJUDIuDQoNCiAgICAgICAgbyBJUDIgaXMgcmVzb2x2ZWQg dG8gTTIgaW4gdGhlIEFSUCB0YWJsZSwgYW5kIE0yIGlzIHJlc29sdmVkIHRvDQogICAgICAg ICAgdGhlIHR1bm5lbCBpbmZvcm1hdGlvbiBnaXZlbiBieSB0aGUgTUFDLVZSRiBGSUIgKGUu Zy4gcmVtb3RlDQogICAgICAgICAgVlRFUCBhbmQgVk5JIGZvciB0aGUgVlhMQU4gY2FzZSku DQoNCiAgICAgICAgbyBUaGUgSVAgcGFja2V0IGRlc3RpbmVkIHRvIElQeCBpcyBlbmNhcHN1 bGF0ZWQgd2l0aDoNCg0KICAgICAgICAgICAgIC4gU291cmNlIGlubmVyIE1BQyA9IElSQjEg TUFDLg0KDQogICAgICAgICAgICAgLiBEZXN0aW5hdGlvbiBpbm5lciBNQUMgPSBNMi4NCg0K ICAgICAgICAgICAgIC4gVHVubmVsIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBNQUMt VlJGIChWTkksIFZURVAgSVBzDQogICAgICAgICAgICAgICBhbmQgTUFDcyBmb3IgdGhlIFZY TEFOIGNhc2UpLg0KDQogICAoNSkgV2hlbiB0aGUgcGFja2V0IGFycml2ZXMgYXQgTlZFMjoN Cg0KICAgICAgICBvIEJhc2VkIG9uIHRoZSB0dW5uZWwgaW5mb3JtYXRpb24gKFZOSSBmb3Ig dGhlIFZYTEFOIGNhc2UpLCB0aGUNCiAgICAgICAgICBNQUMtVlJGMTAgY29udGV4dCBpcyBp ZGVudGlmaWVkIGZvciBhIE1BQyBsb29rdXAuDQoNCiAgICAgICAgbyBFbmNhcHN1bGF0aW9u IGlzIHN0cmlwcGVkLW9mZiBhbmQgYmFzZWQgb24gYSBNQUMgbG9va3VwDQogICAgICAgICAg KGFzc3VtaW5nIE1BQyBmb3J3YXJkaW5nIG9uIHRoZSBlZ3Jlc3MgTlZFKSwgdGhlIHBhY2tl dCBpcw0KICAgICAgICAgIGZvcndhcmRlZCB0byBUUzIsIHdoZXJlIGl0IHdpbGwgYmUgcHJv cGVybHkgcm91dGVkLg0KDQogDQoNCg0KUmFiYWRhbiBldCBhbC4gICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFkdmVydGlzZW1lbnQgICAgICAgICAgTWFy Y2ggMjIsIDIwMTcNCg0KDQogICAoNikgU2hvdWxkIFRTMiBtb3ZlIGZyb20gTlZFMiB0byBO VkUzLCBNQUMgTW9iaWxpdHkgcHJvY2VkdXJlcyB3aWxsDQogICAgICAgYmUgYXBwbGllZCB0 byB0aGUgTUFDIHJvdXRlIElQMi9NMiwgYXMgZGVmaW5lZCBpbiBbUkZDNzQzMl0uDQogICAg ICAgUm91dGUgdHlwZSA1IHByZWZpeGVzIGFyZSBub3Qgc3ViamVjdCB0byBNQUMgbW9iaWxp dHkgcHJvY2VkdXJlcywNCiAgICAgICBoZW5jZSBubyBjaGFuZ2VzIGluIHRoZSBER1cgSVAt VlJGIHJvdXRpbmcgdGFibGUgd2lsbCBvY2N1ciBmb3INCiAgICAgICBUUzIgbW9iaWxpdHks IGkuZS4gYWxsIHRoZSBwcmVmaXhlcyB3aWxsIHN0aWxsIGJlIHBvaW50aW5nIGF0IElQMg0K ICAgICAgIGFzIE92ZXJsYXkgSW5kZXguIFRoZXJlIGlzIGFuIGluZGlyZWN0aW9uIGZvciBl LmcuIFNOMS8yNCwgd2hpY2gNCiAgICAgICBzdGlsbCBwb2ludHMgYXQgT3ZlcmxheSBJbmRl eCBJUDIgaW4gdGhlIHJvdXRpbmcgdGFibGUsIGJ1dCBJUDINCiAgICAgICB3aWxsIGJlIHNp bXBseSByZXNvbHZlZCB0byBhIGRpZmZlcmVudCB0dW5uZWwsIGJhc2VkIG9uIHRoZQ0KICAg ICAgIG91dGNvbWUgb2YgdGhlIE1BQyBtb2JpbGl0eSBwcm9jZWR1cmVzIGZvciB0aGUgTUFD L0lQIHJvdXRlDQogICAgICAgSVAyL00yLg0KDQogICBOb3RlIHRoYXQgaW4gdGhlIG9wcG9z aXRlIGRpcmVjdGlvbiwgVFMyIHdpbGwgc2VuZCB0cmFmZmljIGJhc2VkIG9uDQogICBpdHMg c3RhdGljLXJvdXRlIG5leHQtaG9wIGluZm9ybWF0aW9uIChJUkIxIGFuZC9vciBJUkIyKSwg YW5kIHJlZ3VsYXINCiAgIEVWUE4gcHJvY2VkdXJlcyB3aWxsIGJlIGFwcGxpZWQuDQoNCjQu MiBGbG9hdGluZyBJUCBPdmVybGF5IEluZGV4IHVzZS1jYXNlIA0KDQogICBTb21ldGltZXMg VGVuYW50IFN5c3RlbXMgKFRTKSB3b3JrIGluIGFjdGl2ZS9zdGFuZGJ5IG1vZGUgd2hlcmUg YW4NCiAgIHVwc3RyZWFtIGZsb2F0aW5nIElQIC0gb3duZWQgYnkgdGhlIGFjdGl2ZSBUUyAt IGlzIHVzZWQgYXMgdGhlDQogICBPdmVybGF5IEluZGV4IHRvIGdldCB0byBzb21lIHN1Ym5l dHMgYmVoaW5kLiBUaGlzIHJlZHVuZGFuY3kgbW9kZSwNCiAgIGFscmVhZHkgaW50cm9kdWNl ZCBpbiBzZWN0aW9uIDIuMSBhbmQgMi4yLCBpcyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUNCiAg IDMuDQoNCiAgICAgICAgICAgICAgICAgICAgTlZFMiAgICAgICAgICAgICAgICAgICAgICAg ICAgIERHVzENCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyArLS0tLS0tLS0tKyAg ICArLS0tLS0tLS0tLS0tLSsNCiAgICArLS0tVFMyKFZBKS0tfChNQUMtVlJGMTApfC18ICAg ICAgICAgfC0tLS18KE1BQy1WUkYxMCkgIHwNCiAgICB8ICAgICBJUDIvTTIgKy0tLS0tLS0t LS0tKyB8ICAgICAgICAgfCAgICB8ICAgIElSQjFcICAgIHwNCiAgICB8ICAgICAgPC0rICAg ICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICB8ICAgICAoSVAtVlJGKXwtLS0rDQogICAg fCAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgKy0tLS0tLS0tLS0t LS0rICBffF8NCiAgIFNOMSAgICB2SVAyMyAoZmxvYXRpbmcpICAgICB8ICBWWExBTi8gfCAg ICAgICAgICAgICAgICAgICAgKCAgICkNCiAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICBudkdSRSAgfCAgICAgICAgIERHVzIgICAgICAoIFdBTiApDQogICAgfCAgICAgIDwt KyAgICAgIE5WRTMgICAgICAgfCAgICAgICAgIHwgICAgKy0tLS0tLS0tLS0tLS0rIChfX18p DQogICAgfCAgICAgSVAzL00zICstLS0tLS0tLS0tLSsgfCAgICAgICAgIHwtLS0tfChNQUMt VlJGMTApICB8ICAgfA0KICAgICstLS1UUzMoVkEpLS18KE1BQy1WUkYxMCl8LXwgICAgICAg ICB8ICAgIHwgICAgSVJCMlwgICAgfCAgIHwNCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tKyArLS0tLS0tLS0tKyAgICB8ICAgICAoSVAtVlJGKXwtLS0rDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQoNCiAg ICAgICAgICAgIEZpZ3VyZSAzIEZsb2F0aW5nIElQIE92ZXJsYXkgSW5kZXggZm9yIHJlZHVu ZGFudCBUUw0KDQogICBJbiB0aGlzIHVzZS1jYXNlLCBhIEdXIElQIGlzIHVzZWQgYXMgYW4g T3ZlcmxheSBJbmRleCBmb3IgdGhlIHNhbWUNCiAgIHJlYXNvbnMgYXMgaW4gNC4xLiBIb3dl dmVyLCB0aGlzIEdXIElQIGlzIGEgZmxvYXRpbmcgSVAgdGhhdCBiZWxvbmdzDQogICB0byB0 aGUgYWN0aXZlIFRTLiBBc3N1bWluZyBUUzIgaXMgdGhlIGFjdGl2ZSBUUyBhbmQgb3ducyBJ UDIzOg0KDQogICAoMSkgTlZFMiBhZHZlcnRpc2VzIHRoZSBmb2xsb3dpbmcgQkdQIHJvdXRl cyBmb3IgVFMyOg0KDQogICAgICAgIG8gUm91dGUgdHlwZSAyIChNQUMvSVAgcm91dGUpIGNv bnRhaW5pbmc6IE1MPTQ4LCBNPU0yLCBJUEw9MzIsDQogICAgICAgICAgSVA9SVAyMyAoYW5k IEJHUCBFbmNhcHN1bGF0aW9uIEV4dGVuZGVkIENvbW11bml0eSkuIFRoZSBNQUMNCiAgICAg ICAgICBhbmQgSVAgYWRkcmVzc2VzIG1heSBiZSBsZWFybmVkIHZpYSBBUlAtc25vb3Bpbmcu DQogDQoNCg0KUmFiYWRhbiBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywg MjAxNyAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg IEVWUE4gUHJlZml4IEFkdmVydGlzZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0K DQogICAgICAgIG8gUm91dGUgdHlwZSA1IChJUCBQcmVmaXggcm91dGUpIGNvbnRhaW5pbmc6 IElQTD0yNCwgSVA9U04xLA0KICAgICAgICAgIEVTST0wLCBHVyBJUCBhZGRyZXNzPUlQMjMu IFRoZSBwcmVmaXggYW5kIEdXIElQIGFyZSBsZWFybmVkIGJ5DQogICAgICAgICAgcG9saWN5 Lg0KDQogICAoMikgTlZFMyBhZHZlcnRpc2VzIHRoZSBmb2xsb3dpbmcgQkdQIHJvdXRlcyBm b3IgVFMzOg0KDQogICAgICAgIG8gUm91dGUgdHlwZSA1IChJUCBQcmVmaXggcm91dGUpIGNv bnRhaW5pbmc6IElQTD0yNCwgSVA9U04xLA0KICAgICAgICAgIEVTST0wLCBHVyBJUCBhZGRy ZXNzPUlQMjMuIFRoZSBwcmVmaXggYW5kIEdXIElQIGFyZSBsZWFybmVkIGJ5DQogICAgICAg ICAgcG9saWN5Lg0KDQoqKioqIEl0IG1pZ2h0IGJlIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBO VkUzIGRvZXMgbm90IGFkdmVydGlzZSBhbiBSVC0yIGZvcg0KKioqKiBJUDIzL00zLiAgICAg ICAgICAgDQoNCiAgICgzKSBER1cxIGFuZCBER1cyIGltcG9ydCBib3RoIHJlY2VpdmVkIHJv dXRlcyBiYXNlZCBvbiB0aGUgcm91dGUtDQogICAgICAgdGFyZ2V0Og0KDQogICAgICAgIG8g TTIgaXMgYWRkZWQgdG8gdGhlIE1BQy1WUkYxMCBGSUIgYWxvbmcgd2l0aCBpdHMgY29ycmVz cG9uZGluZw0KICAgICAgICAgIHR1bm5lbCBpbmZvcm1hdGlvbi4gRm9yIHRoZSBWWExBTiB1 c2UgY2FzZSwgdGhlIFZURVAgd2lsbCBiZQ0KICAgICAgICAgIGRlcml2ZWQgZnJvbSB0aGUg TUFDL0lQIHJvdXRlIEJHUCBuZXh0LWhvcCBhbmQgVk5JIGZyb20gdGhlDQogICAgICAgICAg Vk5JL1ZTSUQgZmllbGQuIElQMjMgLSBNMiBpcyBhZGRlZCB0byB0aGUgQVJQIHRhYmxlLg0K DQogICAgICAgIG8gU04xLzI0IGlzIGFkZGVkIHRvIHRoZSBJUC1WUkYgaW4gREdXMSBhbmQg REdXMiB3aXRoIE92ZXJsYXkNCiAgICAgICAgICBpbmRleCBJUDIzIHBvaW50aW5nIGF0IHRo ZSBsb2NhbCBNQUMtVlJGMTAuDQoNCioqKiogU2hvdWxkIGl0IGJlICJwb2ludGluZyBhdCBN MiBpbiB0aGUgbG9jYWwgTUFDLVZSRjEwIj8gICAgICAgICAgDQoNCiAgICg0KSBXaGVuIERH VzEgcmVjZWl2ZXMgYSBwYWNrZXQgZnJvbSB0aGUgV0FOIHdpdGggZGVzdGluYXRpb24gSVB4 LA0KICAgICAgIHdoZXJlIElQeCBiZWxvbmdzIHRvIFNOMS8yNDoNCg0KICAgICAgICBvIEEg ZGVzdGluYXRpb24gSVAgbG9va3VwIGlzIHBlcmZvcm1lZCBvbiB0aGUgREdXMSBJUC1WUkYN CiAgICAgICAgICByb3V0aW5nIHRhYmxlIGFuZCBPdmVybGF5IEluZGV4PUlQMjMgaXMgZm91 bmQuIFNpbmNlIElQMjMgaXMNCiAgICAgICAgICBhbiBPdmVybGF5IEluZGV4LCBhIHJlY3Vy c2l2ZSByb3V0ZSByZXNvbHV0aW9uIGZvciBJUDIzIGlzDQogICAgICAgICAgcmVxdWlyZWQu DQoNCiAgICAgICAgbyBJUDIzIGlzIHJlc29sdmVkIHRvIE0yIGluIHRoZSBBUlAgdGFibGUs IGFuZCBNMiBpcyByZXNvbHZlZCB0bw0KICAgICAgICAgIHRoZSB0dW5uZWwgaW5mb3JtYXRp b24gZ2l2ZW4gYnkgdGhlIE1BQy1WUkYgKHJlbW90ZSBWVEVQIGFuZA0KICAgICAgICAgIFZO SSBmb3IgdGhlIFZYTEFOIGNhc2UpLg0KDQogICAgICAgIG8gVGhlIElQIHBhY2tldCBkZXN0 aW5lZCB0byBJUHggaXMgZW5jYXBzdWxhdGVkIHdpdGg6DQoNCiAgICAgICAgICAgICAuIFNv dXJjZSBpbm5lciBNQUMgPSBJUkIxIE1BQy4NCg0KICAgICAgICAgICAgIC4gRGVzdGluYXRp b24gaW5uZXIgTUFDID0gTTIuDQoNCiAgICAgICAgICAgICAuIFR1bm5lbCBpbmZvcm1hdGlv biBwcm92aWRlZCBieSB0aGUgTUFDLVZSRiBGSUIgKFZOSSwgVlRFUA0KICAgICAgICAgICAg ICAgSVBzIGFuZCBNQUNzIGZvciB0aGUgVlhMQU4gY2FzZSkuDQoNCiAgICg1KSBXaGVuIHRo ZSBwYWNrZXQgYXJyaXZlcyBhdCBOVkUyOg0KDQogICAgICAgIG8gQmFzZWQgb24gdGhlIHR1 bm5lbCBpbmZvcm1hdGlvbiAoVk5JIGZvciB0aGUgVlhMQU4gY2FzZSksIHRoZQ0KICAgICAg ICAgIE1BQy1WUkYxMCBjb250ZXh0IGlzIGlkZW50aWZpZWQgZm9yIGEgTUFDIGxvb2t1cC4N Cg0KICAgICAgICBvIEVuY2Fwc3VsYXRpb24gaXMgc3RyaXBwZWQtb2ZmIGFuZCBiYXNlZCBv biBhIE1BQyBsb29rdXANCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJj aCAyMiwgMjAxNw0KDQoNCiAgICAgICAgICAoYXNzdW1pbmcgTUFDIGZvcndhcmRpbmcgb24g dGhlIGVncmVzcyBOVkUpLCB0aGUgcGFja2V0IGlzDQogICAgICAgICAgZm9yd2FyZGVkIHRv IFRTMiwgd2hlcmUgaXQgd2lsbCBiZSBwcm9wZXJseSByb3V0ZWQuDQoNCiAgICg2KSBXaGVu IHRoZSByZWR1bmRhbmN5IHByb3RvY29sIHJ1bm5pbmcgYmV0d2VlbiBUUzIgYW5kIFRTMyBh cHBvaW50cw0KICAgICAgIFRTMyBhcyB0aGUgbmV3IGFjdGl2ZSBUUyBmb3IgU04xLCBUUzMg d2lsbCBub3cgb3duIHRoZSBmbG9hdGluZw0KICAgICAgIElQMjMgYW5kIHdpbGwgc2lnbmFs IHRoaXMgbmV3IG93bmVyc2hpcCAoR0FSUCBtZXNzYWdlIG9yDQogICAgICAgc2ltaWxhciku IFVwb24gcmVjZWl2aW5nIHRoZSBuZXcgb3duZXIncyBub3RpZmljYXRpb24sIE5WRTMgd2ls bA0KICAgICAgIGlzc3VlIGEgcm91dGUgdHlwZSAyIGZvciBNMy1JUDIzIChhbmQgTlZFMiB3 aWxsIHdpdGhkcmF3IHRoZSBSVC0yDQogICAgICAgZm9yIE0yLUlQMjMpLg0KDQoqKioqIEkn ZCByZW1vdmUgdGhlIHBhcmVudGhlc2VzIGluIHRoZSBsYXN0IHNlbnRlbmNlLCBhcyB0aGUg d2l0aGRyYXdhbCBieQ0KKioqKiBOVkUyIGlzIHByZXR0eSBpbXBvcnRhbnQgKHVubGVzcyBU UzIgYWN0dWFsbHkgZ29lcyBkb3duKS4gIEJUVywgaWYNCioqKiogTlZFMidzIHdpdGhkcmF3 YWwgaXMgcmVjZWl2ZWQgYmVmb3JlIE5WRTMncyB1cGRhdGUsIHlvdSBjYW4gZ2V0IGEgc2hv cnQNCioqKiogYmxhY2sgaG9sZSAoaS5lLiwgdGhlcmUgZG9lc24ndCBzZWVtIHRvIGJlIGFu eSAibWFrZSBiZWZvcmUgYnJlYWsiOw0KKioqKiBkb24ndCBrbm93IGlmIHRoYXQncyBhbiBp c3N1ZSBvciBub3QpLg0KDQogICAgICAgREdXMSBhbmQgREdXMiB3aWxsIHVwZGF0ZSB0aGVp ciBBUlAgdGFibGVzIHdpdGggdGhlDQogICAgICAgbmV3IE1BQyByZXNvbHZpbmcgdGhlIGZs b2F0aW5nIElQLiBObyBjaGFuZ2VzIGFyZSBtYWRlIGluIHRoZSBJUC0NCiAgICAgICBWUkYg cm91dGluZyB0YWJsZS4NCg0KNC4zIEJ1bXAtaW4tdGhlLXdpcmUgdXNlLWNhc2UNCg0KICAg RmlndXJlIDUgaWxsdXN0cmF0ZXMgYW4gZXhhbXBsZSBvZiBpbnRlci1zdWJuZXQgZm9yd2Fy ZGluZyBmb3IgYW4gSVANCiAgIFByZWZpeCByb3V0ZSB0aGF0IGNhcnJpZXMgYSBzdWJuZXQg U04xLiBJbiB0aGlzIHVzZS1jYXNlLCBUUzIgYW5kIFRTMw0KICAgYXJlIGxheWVyLTIgVkEg ZGV2aWNlcyB3aXRob3V0IGFueSBJUCBhZGRyZXNzIHRoYXQgY2FuIGJlIGluY2x1ZGVkIGFz DQogICBhbiBPdmVybGF5IEluZGV4IGluIHRoZSBHVyBJUCBmaWVsZCBvZiB0aGUgSVAgUHJl Zml4IHJvdXRlLiBUaGVpciBNQUMNCiAgIGFkZHJlc3NlcyBhcmUgTTIgYW5kIE0zIHJlc3Bl Y3RpdmVseSBhbmQgYXJlIGNvbm5lY3RlZCB0byBFVkktMTAuDQogICBOb3RlIHRoYXQgSVJC MSBhbmQgSVJCMiAoaW4gREdXMSBhbmQgREdXMiByZXNwZWN0aXZlbHkpIGhhdmUgSVANCiAg IGFkZHJlc3NlcyBpbiBhIHN1Ym5ldCBkaWZmZXJlbnQgdGhhbiBTTjEuIA0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICBOVkUyICAgICAgICAgICAgICAgICAgICAgICAgICAgREdXMQ0K ICAgICAgICAgICAgICAgTTIgKy0tLS0tLS0tLS0tKyArLS0tLS0tLS0tKyAgICArLS0tLS0t LS0tLS0tLSsNCiAgICAgKy0tLVRTMihWQSktLXwoTUFDLVZSRjEwKXwtfCAgICAgICAgIHwt LS0tfChNQUMtVlJGMTApICB8DQogICAgIHwgICAgICBFU0kyMyArLS0tLS0tLS0tLS0rIHwg ICAgICAgICB8ICAgIHwgICAgSVJCMVwgICAgfA0KICAgICB8ICAgICAgICArICAgICAgICAg ICAgICAgICB8ICAgICAgICAgfCAgICB8ICAgICAoSVAtVlJGKXwtLS0rDQogICAgIHwgICAg ICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICstLS0tLS0tLS0tLS0tKyAg X3xfDQogICAgU04xICAgICAgIHwgICAgICAgICAgICAgICAgIHwgIFZYTEFOLyB8ICAgICAg ICAgICAgICAgICAgICAoICAgKQ0KICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8 ICBudkdSRSAgfCAgICAgICAgIERHVzIgICAgICAoIFdBTiApDQogICAgIHwgICAgICAgICsg ICAgICBOVkUzICAgICAgIHwgICAgICAgICB8ICAgICstLS0tLS0tLS0tLS0tKyAoX19fKQ0K ICAgICB8ICAgICAgRVNJMjMgKy0tLS0tLS0tLS0tKyB8ICAgICAgICAgfC0tLS18KE1BQy1W UkYxMCkgIHwgICB8DQogICAgICstLS1UUzMoVkEpLS18KE1BQy1WUkYxMCl8LXwgICAgICAg ICB8ICAgIHwgICAgSVJCMlwgICAgfCAgIHwNCiAgICAgICAgICAgICAgIE0zICstLS0tLS0t LS0tLSsgKy0tLS0tLS0tLSsgICAgfCAgICAgKElQLVZSRil8LS0tKw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsNCg0K ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNSBCdW1wLWluLXRoZS13aXJlIHVzZS1jYXNl DQoNCiAgIFNpbmNlIG5laXRoZXIgVFMyIG5vciBUUzMgY2FuIHBhcnRpY2lwYXRlIGluIGFu eSBkeW5hbWljIHJvdXRpbmcNCiAgIHByb3RvY29sIGFuZCBoYXZlIG5vIElQIGFkZHJlc3Mg YXNzaWduZWQsIHRoZXJlIGFyZSB0d28gcG90ZW50aWFsDQogICBPdmVybGF5IEluZGV4IHR5 cGVzIHRoYXQgY2FuIGJlIHVzZWQgd2hlbiBhZHZlcnRpc2luZyBTTjE6IA0KDQogICBhKSBh biBFU0ksIGkuZS4gRVNJMjMsIHRoYXQgY2FuIGJlIHByb3Zpc2lvbmVkIG9uIHRoZSBhdHRh Y2htZW50DQogICAgICBwb3J0cyBvZiBOVkUyIGFuZCBOVkUzLCBhcyBzaG93biBpbiBGaWd1 cmUgNS4gDQogICBiKSBvciB0aGUgVkEncyBNQUMgYWRkcmVzcywgdGhhdCBjYW4gYmUgYWRk ZWQgdG8gTlZFMiBhbmQgTlZFMyBieQ0KICAgICAgcG9saWN5Lg0KDQogDQoNCg0KUmFiYWRh biBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAg ICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFk dmVydGlzZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQogICBUaGUgYWR2YW50 YWdlIG9mIHVzaW5nIGFuIEVTSSBhcyBPdmVybGF5IEluZGV4IGFzIG9wcG9zZWQgdG8gdGhl IFZBJ3MNCiAgIE1BQyBhZGRyZXNzLCBpcyB0aGF0IHRoZSBmb3J3YXJkaW5nIHRvIHRoZSBl Z3Jlc3MgTlZFIGNhbiBiZSBkb25lDQogICBwdXJlbHkgYmFzZWQgb24gdGhlIHN0YXRlIG9m IHRoZSBBQyBpbiB0aGUgRVMgKG5vdGlmaWVkIGJ5IHRoZSBBRA0KICAgcGVyLUVWSSByb3V0 ZSkgYW5kIGFsbCB0aGUgRVZQTiBtdWx0aS1ob21pbmcgcmVkdW5kYW5jeSBtZWNoYW5pc21z DQogICBjYW4gYmUgcmUtdXNlZC4gRm9yIGluc3RhbmNlLCB0aGUgW1JGQzc0MzJdIG1hc3Mt d2l0aGRyYXdhbCBtZWNoYW5pc20NCiAgIGZvciBmYXN0IGZhaWx1cmUgZGV0ZWN0aW9uIGFu ZCBwcm9wYWdhdGlvbiBjYW4gYmUgdXNlZC4gVGhpcyBzZWN0aW9uDQogICBhc3N1bWVzIHRo YXQgYW4gRVNJIE92ZXJsYXkgSW5kZXggaXMgdXNlZCBpbiB0aGlzIHVzZS1jYXNlIGJ1dCBp dA0KICAgZG9lcyBub3QgcHJldmVudCB0aGUgdXNlIG9mIHRoZSBWQSdzIE1BQyBhZGRyZXNz IGFzIGFuIE92ZXJsYXkgSW5kZXguDQogICBJZiBhIE1BQyBpcyB1c2VkIGFzIE92ZXJsYXkg SW5kZXgsIHRoZSBjb250cm9sIHBsYW5lIG11c3QgZm9sbG93IHRoZQ0KICAgcHJvY2VkdXJl cyBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjQuMy4gDQoNCiAgIFRoZSBtb2RlbCBzdXBwb3J0 cyBWQSByZWR1bmRhbmN5IGluIGEgc2ltaWxhciB3YXkgYXMgdGhlIG9uZQ0KICAgZGVzY3Jp YmVkIGluIHNlY3Rpb24gNC4yIGZvciB0aGUgZmxvYXRpbmcgSVAgT3ZlcmxheSBJbmRleCB1 c2UtY2FzZSwNCiAgIG9ubHkgdXNpbmcgdGhlIEVWUE4gRXRoZXJuZXQgQS1EIHBlci1FVkkg cm91dGUgaW5zdGVhZCBvZiB0aGUgTUFDDQoNCioqKiogUGVyaGFwcyAib25seSB1c2luZyIg LS0+ICJleGNlcHQgdGhhdCBpdCB1c2VzIg0KDQogICBhZHZlcnRpc2VtZW50IHJvdXRlIHRv IGFkdmVydGlzZSB0aGUgbG9jYXRpb24gb2YgdGhlIE92ZXJsYXkgSW5kZXguDQogICBUaGUg cHJvY2VkdXJlIGlzIGV4cGxhaW5lZCBiZWxvdzoNCg0KICAgKDEpIEFzc3VtaW5nIFRTMiBp cyB0aGUgYWN0aXZlIFRTIGluIEVTSTIzLCBOVkUyIGFkdmVydGlzZXMgdGhlDQogICBmb2xs b3dpbmcgQkdQIHJvdXRlczoNCg0KICAgICAgICBvIFJvdXRlIHR5cGUgMSAoRXRoZXJuZXQg QS1EIHJvdXRlIGZvciBFVkktMTApIGNvbnRhaW5pbmc6DQogICAgICAgICAgRVNJPUVTSTIz IGFuZCB0aGUgY29ycmVzcG9uZGluZyB0dW5uZWwgaW5mb3JtYXRpb24gKFZOSS9WU0lEDQog ICAgICAgICAgZmllbGQpLCBhcyB3ZWxsIGFzIHRoZSBCR1AgRW5jYXBzdWxhdGlvbiBFeHRl bmRlZCBDb21tdW5pdHkgYXMNCiAgICAgICAgICBwZXIgW0VWUE4tT1ZFUkxBWV0uIA0KDQog ICAgICAgIG8gUm91dGUgdHlwZSA1IChJUCBQcmVmaXggcm91dGUpIGNvbnRhaW5pbmc6IElQ TD0yNCwgSVA9U04xLA0KICAgICAgICAgIEVTST1FU0kyMywgR1cgSVAgYWRkcmVzcz0wLiBU aGUgUm91dGVyJ3MgTUFDIEV4dGVuZGVkDQogICAgICAgICAgQ29tbXVuaXR5IGRlZmluZWQg aW4gW0VWUE4tSU5URVJTVUJORVRdIGlzIGFkZGVkIGFuZCBjYXJyaWVzDQogICAgICAgICAg dGhlIE1BQyBhZGRyZXNzIChNMikgYXNzb2NpYXRlZCB0byB0aGUgVFMgYmVoaW5kIHdoaWNo IFNOMQ0KICAgICAgICAgIHNpdHMuIE0yIG1heSBiZSBsZWFybmVkIGJ5IHBvbGljeS4NCg0K KioqKiBJIGRvbid0IHRoaW5rIGl0J3MgYmVlbiBjbGVhciB1cCB0byBub3cgdGhhdCB3aGVu IHRoZSBFU0kgZmllbGQgaXMNCioqKiogbm9uLXplcm8gYW5kIHRoZSBHVyBJUCBmaWVsZCBp cyB6ZXJvLCB0aGUgUm91dGVyJ3MgTUFDIEVDIG11c3QgYmUNCioqKiogaW5jbHVkZWQuDQoN CiAgICgyKSBOVkUzIGFkdmVydGlzZXMgdGhlIGZvbGxvd2luZyBCR1Agcm91dGVzIGZvciBU UzM6IA0KDQogICAgICAgIG8gUm91dGUgdHlwZSA1IChJUCBQcmVmaXggcm91dGUpIGNvbnRh aW5pbmc6IElQTD0yNCwgSVA9U04xLA0KICAgICAgICAgIEVTST0yMywgR1cgSVAgYWRkcmVz cz0wLiBUaGUgUm91dGVyJ3MgTUFDIEV4dGVuZGVkIENvbW11bml0eQ0KICAgICAgICAgIGlz IGFkZGVkIGFuZCBjYXJyaWVzIHRoZSBNQUMgYWRkcmVzcyAoTTMpIGFzc29jaWF0ZWQgdG8g dGhlIFRTDQogICAgICAgICAgYmVoaW5kIHdoaWNoIFNOMSBzaXRzLiBNMyBtYXkgYmUgbGVh cm5lZCBieSBwb2xpY3kuDQoNCiAgICgzKSBER1cxIGFuZCBER1cyIGltcG9ydCB0aGUgcmVj ZWl2ZWQgcm91dGVzIGJhc2VkIG9uIHRoZSByb3V0ZS0NCiAgICAgICB0YXJnZXQ6DQoNCiAg ICAgICAgbyBUaGUgdHVubmVsIGluZm9ybWF0aW9uIHRvIGdldCB0byBFU0kyMyBpcyBpbnN0 YWxsZWQgaW4gREdXMQ0KICAgICAgICAgIGFuZCBER1cyLiBGb3IgdGhlIFZYTEFOIHVzZSBj YXNlLCB0aGUgVlRFUCB3aWxsIGJlIGRlcml2ZWQNCiAgICAgICAgICBmcm9tIHRoZSBFdGhl cm5ldCBBLUQgcm91dGUgQkdQIG5leHQtaG9wIGFuZCBWTkkgZnJvbSB0aGUNCiAgICAgICAg ICBWTkkvVlNJRCBmaWVsZCAoc2VlIFtFVlBOLU9WRVJMQVldKS4gDQoNCiAgICAgICAgbyBT TjEvMjQgaXMgYWRkZWQgdG8gdGhlIElQLVZSRiBpbiBER1cxIGFuZCBER1cyIHdpdGggT3Zl cmxheQ0KICAgICAgICAgIEluZGV4IEVTSTIzLg0KIA0KDQoNClJhYmFkYW4gZXQgYWwuICAg ICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMTcgICAgICAgICAgICAgIFtQYWdlIDE3 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlBOIFByZWZpeCBBZHZlcnRpc2VtZW50 ICAgICAgICAgIE1hcmNoIDIyLCAyMDE3DQoNCg0KICAgKDQpIFdoZW4gREdXMSByZWNlaXZl cyBhIHBhY2tldCBmcm9tIHRoZSBXQU4gd2l0aCBkZXN0aW5hdGlvbiBJUHgsDQogICAgICAg d2hlcmUgSVB4IGJlbG9uZ3MgdG8gU04xLzI0Og0KDQogICAgICAgIG8gQSBkZXN0aW5hdGlv biBJUCBsb29rdXAgaXMgcGVyZm9ybWVkIG9uIHRoZSBER1cxIElQLVZSRg0KICAgICAgICAg IHJvdXRpbmcgdGFibGUgYW5kIE92ZXJsYXkgSW5kZXg9RVNJMjMgaXMgZm91bmQuIFNpbmNl IEVTSTIzIGlzDQogICAgICAgICAgYW4gT3ZlcmxheSBJbmRleCwgYSByZWN1cnNpdmUgcm91 dGUgcmVzb2x1dGlvbiBpcyByZXF1aXJlZCB0bw0KICAgICAgICAgIGZpbmQgdGhlIGVncmVz cyBOVkUgd2hlcmUgRVNJMjMgcmVzaWRlcy4NCg0KICAgICAgICBvIFRoZSBJUCBwYWNrZXQg ZGVzdGluZWQgdG8gSVB4IGlzIGVuY2Fwc3VsYXRlZCB3aXRoOg0KDQogICAgICAgICAgICAg LiBTb3VyY2UgaW5uZXIgTUFDID0gSVJCMSBNQUMuDQoNCiAgICAgICAgICAgICAuIERlc3Rp bmF0aW9uIGlubmVyIE1BQyA9IE0yICh0aGlzIE1BQyB3aWxsIGJlIG9idGFpbmVkDQogICAg ICAgICAgICAgICBmcm9tIHRoZSBSb3V0ZXIncyBNQUMgRXh0ZW5kZWQgQ29tbXVuaXR5IHJl Y2VpdmVkIGFsb25nDQogICAgICAgICAgICAgICB3aXRoIHRoZSBSVC01IGZvciBTTjEpLg0K DQogICAgICAgICAgICAgLiBUdW5uZWwgaW5mb3JtYXRpb24gZm9yIHRoZSBOVk8gdHVubmVs IGlzIHByb3ZpZGVkIGJ5IHRoZQ0KICAgICAgICAgICAgICAgRXRoZXJuZXQgQS1EIHJvdXRl IHBlci1FVkkgZm9yIEVTSTIzIChWTkkgYW5kIFZURVAgSVAgZm9yDQogICAgICAgICAgICAg ICB0aGUgVlhMQU4gY2FzZSkuDQoNCioqKiogQnkgdGhpcyBwcm9jZWR1cmUsIGEgZ2l2ZW4g REdXIGNob29zZXMgYmV0d2VlbiBOVkUyIGFuZCBOVkUzIGJhc2VkIG9ubHkNCioqKiogb24g dGhlIFJULTVzLiAgRG9uJ3QgTlZFMiBhbmQgTlZFMyBlYWNoIG9yaWdpbmF0ZSBhbiAiRXRo ZXJuZXQtQUQNCioqKiogcGVyLUVWSSByb3V0ZSIgZm9yIEVTSTIzPyAgSWYgc28sIHdoYXQg c3RvcHMgREdXMSBmcm9tIHByZWZlcnJpbmcNCioqKiogTlZFMidzIFJULTUgd2hpbGUgYWxz byBwcmZlcnJpbmcgTlZFMydzICJFdGhlcm5ldC1BRCBwZXItRVZJIHJvdXRlIj8NCioqKiog V291bGRuJ3QgdGhlIHJlc3VsdCBiZSB0aGF0IERHVzEgdHVubmVscyBhIHBhY2tldCB0byBO VkUzIGJ1dCB1c2VzIHRoZQ0KKioqKiBNQUMgYWRkcmVzcyBNMj8gIElmIHNvLCB3aWxsIHRo YXQgc3RpbGwgd29yayBwcm9wZXJseT8gT3IgaGF2ZSBJDQoqKioqIG1pc3VuZGVyc3Rvb2Qg c29tZXRoaW5nPw0KDQogICAoNSkgV2hlbiB0aGUgcGFja2V0IGFycml2ZXMgYXQgTlZFMjoN Cg0KICAgICAgICBvIEJhc2VkIG9uIHRoZSB0dW5uZWwgZGVtdWx0aXBsZXhlciBpbmZvcm1h dGlvbiAoVk5JIGZvciB0aGUNCiAgICAgICAgICBWWExBTiBjYXNlKSwgdGhlIE1BQy1WUkYx MCBjb250ZXh0IGlzIGlkZW50aWZpZWQgZm9yIGEgTUFDDQogICAgICAgICAgbG9va3VwIChh c3N1bWluZyBNQUMgZGlzcG9zaXRpb24gbW9kZWwpIG9yIHRoZSBWTkkgTUFZDQogICAgICAg ICAgZGlyZWN0bHkgaWRlbnRpZnkgdGhlIGVncmVzcyBpbnRlcmZhY2UgKGZvciBhIGxhYmVs IG9yIFZOSQ0KICAgICAgICAgIGRpc3Bvc2l0aW9uIG1vZGVsKS4NCg0KICAgICAgICBvIEVu Y2Fwc3VsYXRpb24gaXMgc3RyaXBwZWQtb2ZmIGFuZCBiYXNlZCBvbiBhIE1BQyBsb29rdXAN CiAgICAgICAgICAoYXNzdW1pbmcgTUFDIGZvcndhcmRpbmcgb24gdGhlIGVncmVzcyBOVkUp IG9yIGEgVk5JIGxvb2t1cA0KICAgICAgICAgIChpbiBjYXNlIG9mIFZOSSBmb3J3YXJkaW5n KSwgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQgdG8gVFMyLA0KICAgICAgICAgIHdoZXJlIGl0 IHdpbGwgYmUgZm9yd2FyZGVkIHRvIFNOMS4NCg0KICAgKDYpIElmIHRoZSByZWR1bmRhbmN5 IHByb3RvY29sIHJ1bm5pbmcgYmV0d2VlbiBUUzIgYW5kIFRTMyBmb2xsb3dzIGFuDQogICAg ICAgYWN0aXZlL3N0YW5kYnkgbW9kZWwgYW5kIHRoZXJlIGlzIGEgZmFpbHVyZSwgYXBwb2lu dGluZyBUUzMgYXMNCiAgICAgICB0aGUgbmV3IGFjdGl2ZSBUUyBmb3IgU04xLCBUUzMgd2ls bCBub3cgb3duIHRoZSBjb25uZWN0aXZpdHkgdG8NCiAgICAgICBTTjEgYW5kIHdpbGwgc2ln bmFsIHRoaXMgbmV3IG93bmVyc2hpcC4gVXBvbiByZWNlaXZpbmcgdGhlIG5ldw0KICAgICAg IG93bmVyJ3Mgbm90aWZpY2F0aW9uLCBOVkUzJ3MgQUMgd2lsbCBiZWNvbWUgYWN0aXZlIGFu ZCBpc3N1ZSBhDQogICAgICAgcm91dGUgdHlwZSAxIGZvciBFU0kyMywgd2hlcmVhcyBOVkUy IHdpbGwgd2l0aGRyYXcgaXRzIEV0aGVybmV0DQogICAgICAgQS1EIHJvdXRlIGZvciBFU0ky My4gREdXMSBhbmQgREdXMiB3aWxsIHVwZGF0ZSB0aGVpciB0dW5uZWwNCiAgICAgICBpbmZv cm1hdGlvbiB0byByZXNvbHZlIEVTSTIzLiBUaGUgZGVzdGluYXRpb24gaW5uZXIgTUFDIHdp bGwgYmUNCiAgICAgICBjaGFuZ2VkIHRvIE0zLg0KDQo0LjQgSVAtVlJGLXRvLUlQLVZSRiBt b2RlbA0KDQogICBUaGlzIHVzZS1jYXNlIGlzIHNpbWlsYXIgdG8gdGhlIHNjZW5hcmlvIGRl c2NyaWJlZCBpbiAiSVJCIGZvcndhcmRpbmcNCiAgIG9uIE5WRXMgZm9yIFRlbmFudCBTeXN0 ZW1zIiBpbiBbRVZQTi1JTlRFUlNVQk5FVF0sIGhvd2V2ZXIgdGhlIG5ldw0KICAgcmVxdWly ZW1lbnQgaGVyZSBpcyB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBJUCBQcmVmaXhlcyBhcyBvcHBv c2VkIHRvDQogDQoNCg0KUmFiYWRhbiBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAyMywgMjAxNyAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgIEVWUE4gUHJlZml4IEFkdmVydGlzZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIw MTcNCg0KDQogICBvbmx5IGhvc3Qgcm91dGVzLiANCg0KICAgSW4gdGhlIGV4YW1wbGVzIGRl c2NyaWJlZCBpbiBzZWN0aW9ucyA0LjEsIDQuMiBhbmQgNC4zLCB0aGUgTUFDLVZSRg0KICAg aW5zdGFuY2UgY2FuIGNvbm5lY3QgSVJCIGludGVyZmFjZXMgYW5kIGFueSBvdGhlciBUZW5h bnQgU3lzdGVtcw0KICAgY29ubmVjdGVkIHRvIGl0LiBFVlBOIHByb3ZpZGVzIGNvbm5lY3Rp dml0eSBmb3I6DQoNCiAgIDEuIFRyYWZmaWMgZGVzdGluZWQgdG8gdGhlIElSQiBvciBUUyBJ UCBpbnRlcmZhY2VzIGFzIHdlbGwgYXMNCg0KICAgMi4gVHJhZmZpYyBkZXN0aW5lZCB0byBJ UCBzdWJuZXRzIHNpdHRpbmcgYmVoaW5kIHRoZSBUUywgZS5nLiBTTjEgb3INCiAgICAgIFNO Mi4NCg0KICAgSW4gb3JkZXIgdG8gcHJvdmlkZSBjb25uZWN0aXZpdHkgZm9yICgxKSwgTUFD L0lQIHJvdXRlcyAoUlQtMikgYXJlDQogICBuZWVkZWQgc28gdGhhdCBJUkIgb3IgVFMgTUFD cyBhbmQgSVBzIGNhbiBiZSBkaXN0cmlidXRlZC4NCiAgIENvbm5lY3Rpdml0eSB0eXBlICgy KSBpcyBhY2NvbXBsaXNoZWQgYnkgdGhlIGV4Y2hhbmdlIG9mIElQIFByZWZpeA0KICAgcm91 dGVzIChSVC01KSBmb3IgSVBzIGFuZCBzdWJuZXRzIHNpdHRpbmcgYmVoaW5kIGNlcnRhaW4g T3ZlcmxheQ0KICAgSW5kZXhlcywgZS5nLiBHVyBJUCBvciBFU0kuDQoNCiAgIEluIHNvbWUg Y2FzZXMsIElQIFByZWZpeCByb3V0ZXMgbWF5IGJlIGFkdmVydGlzZWQgZm9yIHN1Ym5ldHMg YW5kIElQcw0KICAgc2l0dGluZyBiZWhpbmQgYW4gSVJCLCBhbmQgRVZQTiBpcyB0aGUgb25s eSBlbmFibGVkIFNBRkkgaW4gdGhlDQogICBuZXR3b3JrLg0KDQoqKioqIEluIHRoaXMgcmV2 aXNpb24sIHlvdSd2ZSBzdGF0ZWQgYWxyZWFkeSB0aGF0IHRoZSBJUC1WUkZzIGFyZSBwb3B1 bGF0ZWQNCioqKiogb25seSBieSBFVlBOIHJvdXRlcywgc28gSSBkb24ndCB0aGluayB0aGUg IkVWUE4gaXMgdGhlIG9ubHkgZW5hYmxlZA0KKioqKiBTQUZJIiBpcyBuZWVkZWQuDQoNCiAg IFdlIHJlZmVyIHRvIHRoaXMgdXNlLWNhc2UgYXMgdGhlICJJUC1WUkYtdG8tSVAtVlJGIiBt b2RlbC4NCg0KICAgW0VWUE4tSU5URVJTVUJORVRdIGRlZmluZXMgYW4gYXN5bW1ldHJpYyBJ UkIgbW9kZWwgYW5kIGEgc3ltbWV0cmljDQogICBJUkIgbW9kZWwsIGJhc2VkIG9uIHRoZSBy ZXF1aXJlZCBsb29rdXBzIGF0IHRoZSBpbmdyZXNzIGFuZCBlZ3Jlc3MNCiAgIE5WRTogdGhl IGFzeW1tZXRyaWMgbW9kZWwgcmVxdWlyZXMgYW4gaXAtbG9va3VwIGFuZCBhIG1hYy1sb29r dXAgYXQNCiAgIHRoZSBpbmdyZXNzIE5WRSwgd2hlcmVhcyBvbmx5IGEgbWFjLWxvb2t1cCBp cyBuZWVkZWQgYXQgdGhlIGVncmVzcw0KICAgTlZFOyB0aGUgc3ltbWV0cmljIG1vZGVsIHJl cXVpcmVzIGlwIGFuZCBtYWMgbG9va3VwcyBhdCBib3RoLCBpbmdyZXNzDQogICBhbmQgZWdy ZXNzIE5WRS4gRnJvbSB0aGF0IHBlcnNwZWN0aXZlLCB0aGUgSVAtVlJGLXRvLUlQLVZSRiB1 c2UtY2FzZQ0KICAgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBpcyBhIHN5bW1ldHJpYyBJ UkIgbW9kZWwuIA0KDQogICBOb3RlIHRoYXQsIGluIGFuIElQLVZSRi10by1JUC1WUkYgc2Nl bmFyaW8sIG91dCBvZiB0aGUgbWFueSBzdWJuZXRzDQogICB0aGF0IGEgdGVuYW50IG1heSBo YXZlLCBvbmx5IGEgZmV3IGFyZSBhdHRhY2hlZCB0byBhIGdpdmVuIE5WRS9QRSdzDQoNCioq KiogUGVyaGFwcyAib25seSBhIGZldyBhcmUgYXR0YWNoZWQiIC0tPiAiaXQgbWF5IGJlIHRo ZSBjYXNlIHRoYXQgb25seSBhDQoqKioqIGZldyBhcmUgYXR0YWNoZWQiDQogICANCiAgIElQ LVZSRi4gSW4gb3JkZXIgdG8gcHJvdmlkZSBpbnRlci1zdWJuZXQgY29ubmVjdGl2aXR5IGFj cm9zcyBtdWx0aXBsZQ0KICAgTlZFL1BFcywgYSBzaGFyZWQgY29yZSBFVkkgbWF5IGJlIGNv bmZpZ3VyZWQgaW4gYWxsIHRoZSB0ZW5hbnQNCiAgIE5WRS9QRXMuIFRoaXMgY29yZSBFVkkg aGFzIGEgY29yZS1mYWNpbmcgSVJCIGludGVyZmFjZSB0aGF0IGNvbm5lY3RzDQogICB0aGUg Y29yZSBNQUMtVlJGIHRvIHRoZSBJUC1WUkYgb24gZWFjaCBOVkUvUEUuDQoNCioqKiogSSBn ZXQgKEkgdGhpbmspIHRoYXQgdGhlICJjb3JlIEVWSSIgaGFzIG5vIEFDcywgYW5kIGlzIG9u bHkgdXNlZCB0bw0KKioqKiBjYXJyeSBJUCB0cmFmaWMgYWNyb3NzIHRoZSBjb3JlLiAgSSdt IG5vdCBzdXJlIHdoYXQgImNvcmUtZmFjaW5nIElSQg0KKioqKiBpbnRlcmZhY2UiIG1lYW5z IG9yIHdoYXQgImNvcmUgTUFDLVZSRiIgbWVhbnMuICBBbHNvLCB0aGUgbGFzdCBzZW50ZW5j ZQ0KKioqKiBhYm92ZSBzZWVtcyB0byBleGNsdWRlIHRoZSBpbnRlcmZhY2UtbGVzcyBtb2Rl bC4NCg0KICAgQmFzZWQgb24gdGhlDQogICBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhpcyBjb3Jl LWZhY2luZyBJUkIgaW50ZXJmYWNlLCB0aGVyZSBhcmUgdGhyZWUNCiAgIGRpZmZlcmVudCBJ UC1WUkYtdG8tSVAtVlJGIHNjZW5hcmlvcyBpZGVudGlmaWVkIGFuZCBkZXNjcmliZWQgaW4g dGhpcw0KICAgZG9jdW1lbnQ6DQoNCiAgIDEpIEludGVyZmFjZS1sZXNzIG1vZGVsDQoNCioq KiogU28gImJhc2VkIG9uIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIGNvcmUtZmFjaW5n IElSQiBpbnRlZmFjZSIsIHdlDQoqKioqIG1pZ2h0IGhhdmUgYW4gImludGVyZmFjZS1sZXNz IiBtb2RlbC4gIElzIHRoYXQgYmVjYXVzZSBvbmUgb2YgdGhlDQoqKioqIGNoYXJhY3Rlcmlz dGljcyBtaWdodCBiZSAibm9uLWV4aXN0ZW5jZSI/IDstKQ0KDQogICAyKSBJbnRlcmZhY2Ut ZnVsbCB3aXRoIGNvcmUtZmFjaW5nIElSQiBtb2RlbA0KDQoqKioqIElmIHlvdSBsb29rIGF0 IHRlcm1zIGxpa2UgImNhcmVmdWwvY2FyZWxlc3MiLCAic3RhdGVmdWwvc3RhdGVsZXNzIiwN CioqKiogInRob3VnaHRmdWwvdGhvdWdodGxlc3MiLCBJIHRoaW5rIHlvdSdsbCByZWFsaXpl IHRoYXQgImludGVyZmFjZS1mdWxsIg0KKioqKiBzaG91bGQgYmUgImludGVyZmFjZS1mdWwi LiAgQnV0IEknbGwgbGVhdmUgdGhhdCBmb3IgeW91IHRvIGRpc2N1c3Mgd2l0aA0KKioqKiB0 aGUgUkZDIEVkaXRvciA7LSkNCg0KICAgDQogICAzKSBJbnRlcmZhY2UtZnVsbCB3aXRoIHVu bnVtYmVyZWQgY29yZS1mYWNpbmcgSVJCIG1vZGVsDQoNCioqKiogT2theSwgSSB0aGluayBJ IHNlZSB3aGF0J3MgZ29pbmcgb24gaGVyZSBub3cuICBUbyBzdXBwb3J0IGludGVyLXN1Ym5l dA0KKioqKiBmb3J3YXJkaW5nIGFtb25nIGEgc2V0IG9mIE5WRXMvUEVzLCB5b3UgcHJvcG9z ZSB0byBjcmVhdGUgYSBuZXcNCioqKiogImludGVyLXN1Ym5ldCIgRVZJIG9uIGFsbCB0aG9z ZSBOVkUvUEVzLCBhbmQgdGhlbiB0byB1c2UgdGhlIHR1bm5lbHMgb2YNCioqKiogdGhhdCBF VkkgdG8gY2FycnkgdGhlIGludGVyLXN1Ym5ldCB0cmFmZmljLiAgSWYgdGhlIHR1bm5lbHMg YXJlIE5WTw0KKioqKiBldGhlcm5ldCB0dW5uZWxzLCB0aGlzIGlzIGFuYWxvZ291cyB0byB0 aGUgIlN1cHBsZW1lbnRhcnkgQnJvYWRjYXN0DQoqKioqIERvbWFpbiIgZnJvbSBkcmFmdC1s aW4uICBJZiB0aGUgdHVubmVscyBhcmUgTlZPIElQIHR1bm5lbHMsIHRoZW4gdGhpcw0KKioq KiBuZXcgRVZJIGlzIG1vcmUgb2YgYSAiU3VwcGxlbWVudGFyeSBJUCBTdWJuZXQiIHRoYXQg ZXhpc3RzIG9uIGFsbCB0aGUNCioqKiogTlZFcy9QRXMuICBUaGlzIHBhcnQgc2VlbXMgdG8g YmUgY29tbW9uIHRvIGFsbCB0aHJlZSBtb2RlbHMuDQoNCioqKiogSXQncyBoYXJkIHRvIHNh eSBob3cgdGhpcyBtb2RlbCBpcyBnb2luZyB0byBpbnRlcmFjdCB3aXRoIHRoZQ0KKioqKiBk ZXZlbG9waW5nIHByb2NlZHVyZXMgZm9yIHN1cHBvcnQgb2YgRVZQTiBtdWx0aWNhc3QuICBQ bGVhc2UgbWFrZSBpdA0KKioqKiBjbGVhciB0aGF0IHN1cHBvcnQgZm9yIGludGVyLXN1Ym5l dCBJUCBtdWx0aWNhc3QgaXMgb3V0c2lkZSB0aGUgc2NvcGUNCioqKiogb2YgdGhpcyBkb2N1 bWVudC4NCg0KNC40LjEgSW50ZXJmYWNlLWxlc3MgSVAtVlJGLXRvLUlQLVZSRiBtb2RlbA0K DQogICBGaWd1cmUgNiB3aWxsIGJlIHVzZWQgZm9yIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGlz IG1vZGVsLiANCg0KIA0KDQoNClJhYmFkYW4gZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0 ZW1iZXIgMjMsIDIwMTcgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICBFVlBOIFByZWZpeCBBZHZlcnRpc2VtZW50ICAgICAgICAgIE1hcmNoIDIy LCAyMDE3DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgIE5WRTEoTTEpDQogICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgSVAxKy0tLS18KE1BQy1WUkYxKSAg fCAgICAgICAgICAgICAgICBER1cxKE0zKQ0KICAgICAgICAgICAgICAgIHwgICAgICBcICAg ICB8ICAgICstLS0tLS0tLS0rICstLS0tLS0tLSsNCiAgICAgICAgICAgICAgICB8ICAgIChJ UC1WUkYpfC0tLS18ICAgICAgICAgfC18KElQLVZSRil8LS0tLSsNCiAgICAgICAgICAgICAg ICB8ICAgICAgLyAgICAgfCAgICB8ICAgICAgICAgfCArLS0tLS0tLS0rICAgIHwNCiAgICAg ICAgICAgICstLS18KE1BQy1WUkYyKSAgfCAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAg XytfDQogICAgICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLSsgICAgfCAgICAgICAgIHwgICAg ICAgICAgICAgKCAgICkNCiAgICAgICAgIFNOMXwgICAgICAgICAgICAgICAgICAgICB8ICBW WExBTi8gfCAgICAgICAgICAgICggV0FOICkNCiAgICAgICAgICAgIHwgICAgICAgICAgICBO VkUyKE0yKSB8ICBudkdSRS8gfCAgICAgICAgICAgICAoX19fKQ0KICAgICAgICAgICAgfCAg ICstLS0tLS0tLS0tLS0rICAgIHwgIE1QTFMgICB8ICAgICAgICAgICAgICAgKw0KICAgICAg ICAgICAgKy0tLXwoTUFDLVZSRjIpICB8ICAgIHwgICAgICAgICB8IERHVzIoTTQpICAgICAg fA0KICAgICAgICAgICAgICAgIHwgICAgICAgXCAgICB8ICAgIHwgICAgICAgICB8ICstLS0t LS0tLSsgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgKElQLVZSRil8LS0tLXwgICAgICAg ICB8LXwoSVAtVlJGKXwtLS0tKw0KICAgICAgICAgICAgICAgIHwgICAgICAgLyAgICB8ICAg ICstLS0tLS0tLS0rICstLS0tLS0tLSsNCiAgICAgICAgU04yKy0tLS18KE1BQy1WUkYzKSAg fA0KICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0rDQoNCg0KDQoNCiAgICAgICAgIEZp Z3VyZSA2IEludGVyZmFjZS1sZXNzIElQLVZSRi10by1JUC1WUkYgbW9kZWwNCg0KICAgSW4g dGhpcyBjYXNlOg0KDQogICBhKSBUaGUgTlZFcyBhbmQgREdXcyBtdXN0IHByb3ZpZGUgY29u bmVjdGl2aXR5IGJldHdlZW4gaG9zdHMgaW4gU04xLA0KICAgICAgU04yLCBJUDEgYW5kIGhv c3RzIHNpdHRpbmcgYXQgdGhlIG90aGVyIGVuZCBvZiB0aGUgV0FOLg0KDQoqKioqIEl0IHdv dWxkIGJlIGdvb2QgdG8gc2hvdyBzb21lIGhvc3RzICJzaXR0aW5nIGF0IHRoZSBvdGhlciBl bmQgb2YgdGhlDQoqKioqIFdBTiIuIFRoZSBleGlzdGVuY2Ugb2Ygc3VjaCBob3N0cyBzdWdn ZXN0cyB0aGF0IHRoZSBER1dzIGFyZSBpbXBvcnRpbmcNCioqKiogSVAgYW5kL29yIFZQTi1J UCByb3V0ZXMgaW50byB0aGVpciBJUC1WUkZzLiAgSG93ZXZlciwgdGhpcyBkb2N1bWVudCBo YXMNCioqKiogZGVjbGFyZWQgc3VjaCBhIHNpdHVhdGlvbiB0byBiZSBvdXQgb2Ygc2NvcGUs IGFuZCB0aGUgYmVnaW5uaW5nIG9mDQoqKioqIHNlY3Rpb24gNC40IHNheXMgdGhhdCBFVlBO IGlzIHRoZSBvbmx5IGVuYWJsZWQgU0FGSS4gIFNvIEknbSBhIGJpdA0KKioqKiBjb25mdXNl ZCBhYm91dCB0aGlzIHBhcnQgb2YgdGhlIHNjZW5hcmlvLg0KDQogICBiKSBUaGUgSVAtVlJG IGluc3RhbmNlcyBpbiB0aGUgTlZFL0RHV3MgYXJlIGRpcmVjdGx5IGNvbm5lY3RlZA0KICAg ICAgdGhyb3VnaCBOVk8gdHVubmVscywgYW5kIG5vIElSQnMgYW5kL29yIE1BQy1WUkYgaW5z dGFuY2VzIGFyZQ0KICAgICAgaW5zdGFudGlhdGVkIHRvIGNvbm5lY3QgdGhlIElQLVZSRnMu DQoNCiAgIGMpIFRoZSBzb2x1dGlvbiBtdXN0IHByb3ZpZGUgbGF5ZXItMyBjb25uZWN0aXZp dHkgYW1vbmcgdGhlIElQLVZSRnMNCiAgICAgIGZvciBFdGhlcm5ldCBOVk8gdHVubmVscywg Zm9yIGluc3RhbmNlLCBWWExBTiBvciBudkdSRS4NCg0KKioqKiBJZiBldGhlcm5ldCBOVk8g dHVubmVscyBhcmUgdXNlZCwgdGhlbiB3aGVuIHRoZSBER1cgcmVjZWl2ZXMgYSBmcmFtZQ0K KioqKiBmcm9tIG9uZSBvZiB0aG9zZSB0dW5uZWxzIGl0IHJlbW92ZXMgdGhlIGV0aGVybmV0 IGhlYWRlciwgZG9lcyBhbiBJUA0KKioqKiBsb29rdXAsIGFuZCBhZGp1c3RzIFRUTCBhbmQg Y2hlY2tzdW0uIFRoYXQgY2VydGFpbmx5IHNvdW5kcyBsaWtlIHdoYXQNCioqKiogdGhlIERH VyB3b3VsZCBkbyB3aGVuIHJlY2VpdmluZyBhIHBhY2tldCBvdmVyIGFuIElSQiBpbnRlcmZh Y2UuICBUaGUNCioqKiogc2FsaWVudCBmZWF0dXJlIGlzIHJlYWxseSB0aGF0IHRoZSBER1cg ZG9lcyBub3QgbmVlZCB0byBkbyBhIE1BQw0KKioqKiBhZGRyZXNzIGxvb2t1cCwgYW5kIHNv IHRoZXJlIGlzIG5vIG5lZWQgdG8gcG9wdWxhdGUgYSBNQUMtVlJGIHdpdGgNCioqKiogUlQt MnMuDQoNCg0KICAgZCkgVGhlIHNvbHV0aW9uIG1heSBwcm92aWRlIGxheWVyLTMgY29ubmVj dGl2aXR5IGFtb25nIHRoZSBJUC1WUkZzDQogICAgICBmb3IgSVAgTlZPIHR1bm5lbHMsIGZv ciBleGFtcGxlLCBWWExBTiBHUEUgKHdpdGggSVAgcGF5bG9hZCkuDQoNCiAgIEluIG9yZGVy IHRvIG1lZXQgdGhlIGFib3ZlIHJlcXVpcmVtZW50cywgdGhlIEVWUE4gcm91dGUgdHlwZSA1 IHdpbGwNCiAgIGJlIHVzZWQgdG8gYWR2ZXJ0aXNlIHRoZSBJUCBQcmVmaXhlcywgYWxvbmcg d2l0aCB0aGUgUm91dGVyJ3MgTUFDDQogICBFeHRlbmRlZCBDb21tdW5pdHkgYXMgZGVmaW5l ZCBpbiBbRVZQTi1JTlRFUlNVQk5FVF0gaWYgdGhlDQogICBhZHZlcnRpc2luZyBOVkUvREdX IHVzZXMgRXRoZXJuZXQgTlZPIHR1bm5lbHMuIEVhY2ggTlZFL0RHVyB3aWxsDQogICBhZHZl cnRpc2UgYW4gUlQtNSBmb3IgZWFjaCBvZiBpdHMgcHJlZml4ZXMgd2l0aCB0aGUgZm9sbG93 aW5nIGZpZWxkczoNCg0KICAgICAgICBvIFJEIGFzIHBlciBbUkZDNzQzMl0uDQoNCiAgICAg ICAgbyBFdGgtVGFnIElEPTAuDQoNCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAg ICBNYXJjaCAyMiwgMjAxNw0KDQoNCiAgICAgICAgbyBJUCBhZGRyZXNzIGxlbmd0aCBhbmQg SVAgYWRkcmVzcywgYXMgZXhwbGFpbmVkIGluIHRoZSBwcmV2aW91cw0KICAgICAgICAgIHNl Y3Rpb25zLg0KDQogICAgICAgIG8gR1cgSVAgYWRkcmVzcz0wLg0KDQogICAgICAgIG8gRVNJ PTANCg0KICAgICAgICBvIE1QTFMgbGFiZWwgb3IgVk5JIGNvcnJlc3BvbmRpbmcgdG8gdGhl IElQLVZSRi4NCg0KICAgRWFjaCBSVC01IHdpbGwgYmUgc2VudCB3aXRoIGEgcm91dGUtdGFy Z2V0IGlkZW50aWZ5aW5nIHRoZSB0ZW5hbnQNCiAgIChJUC1WUkYpIGFuZCB0d28gQkdQIGV4 dGVuZGVkIGNvbW11bml0aWVzOg0KDQogICAgICAgIG8gVGhlIGZpcnN0IG9uZSBpcyB0aGUg QkdQIEVuY2Fwc3VsYXRpb24gRXh0ZW5kZWQgQ29tbXVuaXR5LCBhcw0KICAgICAgICAgIHBl ciBbUkZDNTUxMl0sIGlkZW50aWZ5aW5nIHRoZSB0dW5uZWwgdHlwZS4NCg0KICAgICAgICBv IFRoZSBzZWNvbmQgb25lIGlzIHRoZSBSb3V0ZXIncyBNQUMgRXh0ZW5kZWQgQ29tbXVuaXR5 IGFzIHBlcg0KICAgICAgICAgIFtFVlBOLUlOVEVSU1VCTkVUXSBjb250YWluaW5nIHRoZSBN QUMgYWRkcmVzcyBhc3NvY2lhdGVkIHRvDQogICAgICAgICAgdGhlIE5WRSBhZHZlcnRpc2lu ZyB0aGUgcm91dGUuIFRoaXMgTUFDIGFkZHJlc3MgaWRlbnRpZmllcyB0aGUNCiAgICAgICAg ICBOVkUvREdXIGFuZCBNQVkgYmUgcmUtdXNlZCBmb3IgYWxsIHRoZSBJUC1WUkZzIGluIHRo ZSBOVkUuIFRoZQ0KICAgICAgICAgIFJvdXRlcidzIE1BQyBFeHRlbmRlZCBDb21tdW5pdHkg TVVTVCBiZSBzZW50IGlmIHRoZSByb3V0ZSBpcw0KICAgICAgICAgIGFzc29jaWF0ZWQgdG8g YW4gRXRoZXJuZXQgTlZPIHR1bm5lbCwgZm9yIGluc3RhbmNlLCBWWExBTi4gSWYNCiAgICAg ICAgICB0aGUgcm91dGUgaXMgYXNzb2NpYXRlZCB0byBhbiBJUCBOVk8gdHVubmVsLCBmb3Ig aW5zdGFuY2UNCiAgICAgICAgICBWWExBTiBHUEUgd2l0aCBJUCBwYXlsb2FkLCB0aGUgUm91 dGVyJ3MgTUFDIEV4dGVuZGVkIENvbW11bml0eQ0KICAgICAgICAgIFNIT1VMRCBOT1QgYmUg c2VudC4NCg0KICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIHRoZSBwcm9j ZWR1cmUgdG8gYWR2ZXJ0aXNlIGFuZA0KICAgZm9yd2FyZCBwYWNrZXRzIHRvIFNOMS8yNCAo aXB2NCBwcmVmaXggYWR2ZXJ0aXNlZCBmcm9tIE5WRTEpOg0KDQogICAoMSkgTlZFMSBhZHZl cnRpc2VzIHRoZSBmb2xsb3dpbmcgQkdQIHJvdXRlOg0KDQogICAgICAgIG8gUm91dGUgdHlw ZSA1IChJUCBQcmVmaXggcm91dGUpIGNvbnRhaW5pbmc6DQoNCiAgICAgICAgICAuIElQTD0y NCwgSVA9U04xLCBMYWJlbD0xMC4NCg0KICAgICAgICAgIC4gR1cgSVA9IFNIT1VMRCBiZSBz ZXQgdG8gMC4NCg0KICAgICAgICAgIC4gW1JGQzU1MTJdIEJHUCBFbmNhcHN1bGF0aW9uIEV4 dGVuZGVkIENvbW11bml0eS4NCg0KKioqKiBJbiB0aGlzIGV4YW1wbGUsIHRoYXQgRUMgd291 bGQgaWRlbnRpZnkgIlZYTEFOIj8gICAgICAgICAgDQoNCiAgICAgICAgICAuIFJvdXRlcidz IE1BQyBFeHRlbmRlZCBDb21tdW5pdHkgdGhhdCBjb250YWlucyBNMS4NCg0KICAgICAgICAg IC4gUm91dGUtdGFyZ2V0IGlkZW50aWZ5aW5nIHRoZSB0ZW5hbnQgKElQLVZSRikuDQoNCiAg ICgyKSBER1cxIGltcG9ydHMgdGhlIHJlY2VpdmVkIHJvdXRlcyBmcm9tIE5WRTE6DQoNCiAg ICAgICAgbyBER1cxIGluc3RhbGxzIFNOMS8yNCBpbiB0aGUgSVAtVlJGIGlkZW50aWZpZWQg YnkgdGhlIFJULTUNCiAgICAgICAgICByb3V0ZS10YXJnZXQuDQoNCiAgICAgICAgbyBTaW5j ZSBHVyBJUD0wIGFuZCB0aGUgTGFiZWwgaXMgYSB2YWxpZCB2YWx1ZSwgREdXMSB3aWxsIHVz ZQ0KDQoqKioqIFBsZWFzZSBkZWZpbmUgInZhbGlkIHZhbHVlIi4gIEkgdGhpbmsgeW91IGp1 c3QgbWVhbiAibm9uLXplcm8gdmFsdWUiLiAgICAgICAgDQogDQoNCg0KUmFiYWRhbiBldCBh bC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAgICAgW1Bh Z2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFkdmVydGlz ZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQogICAgICAgICAgdGhlIExhYmVs IGFuZCBuZXh0LWhvcCBvZiB0aGUgUlQtNSwgYXMgd2VsbCBhcyB0aGUgTUFDIGFkZHJlc3MN CiAgICAgICAgICBjb252ZXllZCBpbiB0aGUgUm91dGVyJ3MgTUFDIEV4dGVuZGVkIENvbW11 bml0eSAoYXMgaW5uZXINCiAgICAgICAgICBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzcykgdG8g c2V0IHVwIHRoZSBmb3J3YXJkaW5nIHN0YXRlIGFuZA0KICAgICAgICAgIGxhdGVyIGVuY2Fw c3VsYXRlIHRoZSByb3V0ZWQgSVAgcGFja2V0cy4NCg0KKioqKiBUaGlzIG1lYW5zIHRoYXQg aWYgYSBCR1Agc3BlYWtlciBwcm9wYWdhdGVzIHRoZSBSVC01IHJvdXRlLCBhbmQgaWYgdGhh dA0KKioqKiBzcGVha2VyIGNoYW5nZXMgdGhlIEJHUCBuZXh0IGhvcCwgaXQgYWxzbyBuZWVk cyB0byBjaGFuZ2UgdGhlIGxhYmVsDQoqKioqIHZhbHVlLiAgT3IgaW4gb3RoZXIgd29yZHMs IHRoaXMgcHJvYmFibHkgd29uJ3Qgd29yayBhcyBzdGF0ZWQgaW4gYW4NCioqKiogT3B0aW9u IEIgaW50ZXJjb25uZWN0IHNjZW5hcmlvLiAgVW5sZXNzIEknbSBtaXNzaW5nIHNvbWV0aGlu ZywgeW91IG5lZWQNCioqKiogdG8gc3RhdGUgY2xlYXJseSB0aGF0IHRoaXMgcHJvY2VkdXJl IGRvZXNuJ3Qgd29yayBhcyBkZXNjcmliZWQgaWYgdGhlDQoqKioqIEJHUCBuZXh0IGhvcCBj aGFuZ2VzLiAgICAgICAgICAgIA0KDQogICAoMykgV2hlbiBER1cxIHJlY2VpdmVzIGEgcGFj a2V0IGZyb20gdGhlIFdBTiB3aXRoIGRlc3RpbmF0aW9uIElQeCwNCg0KKioqKiBJIG5vdGlj ZSB5b3UgZG9uJ3QgbWVudGlvbiB0aGUgY2FzZSB3aGVyZSBER1cxIHJlY2VpdmVzIGEgcGFj a2V0IGZyb20NCioqKiogTlZFMSBvciBOVkUyIHRoYXQgaXMgYWRkcmVzc2VkIHRvIGEgaG9z dCB0aGF0IGlzIHNvbWV3aGVyZSBvdXQgb24gdGhlDQoqKioqIFdBTi4gIEJ1dCB5b3UgZG8g bWVudGlvbiB0aGF0IHRoYXQgaXMgcGFydCBvZiB0aGUgc2NlbmFyaW8uICBTaG91bGQNCioq KiogdGhpcyBjYXNlIGJlIGNvdmVyZWQ/DQogICANCiAgICAgICB3aGVyZSBJUHggYmVsb25n cyB0byBTTjEvMjQ6DQoNCiAgICAgICAgbyBBIGRlc3RpbmF0aW9uIElQIGxvb2t1cCBpcyBw ZXJmb3JtZWQgb24gdGhlIERHVzEgSVAtVlJGDQogICAgICAgICAgcm91dGluZyB0YWJsZS4g VGhlIGxvb2t1cCB5aWVsZHMgU04xLzI0Lg0KDQogICAgICAgIG8gU2luY2UgdGhlIFJULTUg Zm9yIFNOMS8yNCBoYWQgYSBHVyBJUD0wIGFuZCBhIHZhbGlkIExhYmVsIGFuZA0KICAgICAg ICAgIG5leHQtaG9wLCBER1cxIHdpbGwgbm90IG5lZWQgYSByZWN1cnNpdmUgbG9va3VwIHRv IHJlc29sdmUgdGhlDQogICAgICAgICAgcm91dGUuDQoNCiAgICAgICAgbyBUaGUgSVAgcGFj a2V0IGRlc3RpbmVkIHRvIElQeCBpcyBlbmNhcHN1bGF0ZWQgd2l0aDogU291cmNlDQogICAg ICAgICAgaW5uZXIgTUFDID0gREdXMSBNQUMsIERlc3RpbmF0aW9uIGlubmVyIE1BQyA9IE0x LCBTb3VyY2Ugb3V0ZXINCiAgICAgICAgICBJUCAoc291cmNlIFZURVApID0gREdXMSBJUCwg RGVzdGluYXRpb24gb3V0ZXIgSVAgKGRlc3RpbmF0aW9uDQogICAgICAgICAgVlRFUCkgPSBO VkUxIElQLiBUaGUgU291cmNlIGFuZCBEZXN0aW5hdGlvbiBpbm5lciBNQUMNCiAgICAgICAg ICBhZGRyZXNzZXMgYXJlIG5vdCBuZWVkZWQgaWYgSVAgTlZPIHR1bm5lbHMgYXJlIHVzZWQu DQoNCiAgICg0KSBXaGVuIHRoZSBwYWNrZXQgYXJyaXZlcyBhdCBOVkUxOg0KDQogICAgICAg IG8gTlZFMSB3aWxsIGlkZW50aWZ5IHRoZSBJUC1WUkYgZm9yIGFuIElQLWxvb2t1cCBiYXNl ZCBvbiB0aGUNCiAgICAgICAgICBMYWJlbCAodGhlIERlc3RpbmF0aW9uIGlubmVyIE1BQyBp cyBub3QgbmVlZGVkIHRvIGlkZW50aWZ5IHRoZQ0KICAgICAgICAgIElQLVZSRikuDQoNCioq KiogV2h5IGRvZXMgTlZFMSBoYXZlIHRvIHNpZ25hbCB0aGUgZGVzdGluYXRpb24gaW5uZXIg TUFDIHRvIERHVzEgaWYgTlZFMQ0KKioqKiBpcyBub3QgZ29pbmcgdG8gbG9vayBhdCB0aGUg ZGVzdGluYXRpb24gaW5uZXIgTUFDIGZpZWxkIHdoZW4gaXQNCioqKiogcmVjZWl2ZXMgZnJh bWVzIGZyb20gTlZFMT8gICAgICAgICAgIA0KDQogICAgICAgIG8gQW4gSVAgbG9va3VwIGlz IHBlcmZvcm1lZCBpbiB0aGUgcm91dGluZyBjb250ZXh0LCB3aGVyZSBTTjENCiAgICAgICAg ICB0dXJucyBvdXQgdG8gYmUgYSBsb2NhbCBzdWJuZXQgYXNzb2NpYXRlZCB0byBNQUMtVlJG Mi4gQQ0KICAgICAgICAgIHN1YnNlcXVlbnQgbG9va3VwIGluIHRoZSBBUlAgdGFibGUgYW5k IHRoZSBNQUMtVlJGIEZJQiB3aWxsDQogICAgICAgICAgcHJvdmlkZSB0aGUgZm9yd2FyZGlu ZyBpbmZvcm1hdGlvbiBmb3IgdGhlIHBhY2tldCBpbiBNQUMtVlJGMi4NCg0KICAgVGhlIG1v ZGVsIGRlc2NyaWJlZCBhYm92ZSBpcyBjYWxsZWQgSW50ZXJmYWNlLWxlc3MgbW9kZWwgc2lu Y2UgdGhlDQogICBJUC1WUkZzIGFyZSBjb25uZWN0ZWQgZGlyZWN0bHkgdGhyb3VnaCB0dW5u ZWxzIGFuZCB0aGV5IGRvbid0IHJlcXVpcmUNCiAgIHRob3NlIHR1bm5lbHMgdG8gYmUgdGVy bWluYXRlZCBpbiBjb3JlIE1BQy1WUkZzIGluc3RlYWQsIGxpa2UgaW4NCiAgIHNlY3Rpb25z IDQuNC4yIG9yIDQuNC4zLiBBbiBFVlBOIElQLVZSRi10by1JUC1WUkYgaW1wbGVtZW50YXRp b24gaXMNCiAgIFJFUVVJUkVEIHRvIHN1cHBvcnQgdGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBw cm9jZWR1cmVzIGRlc2NyaWJlZCBpbg0KICAgdGhpcyBzZWN0aW9uLg0KDQoqKioqIEkga25v dyB5b3UgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgdGhlIG5hbWVzIG9mIHRoZSBzY2hlbWVzLCBi dXQgSSB0aGluaw0KKioqKiB0aGlzIGlzIHJlYWxseSB0aGUgIk5vIE92ZXJsYXkgSW5kZXgi IChvciAiaW5kZXhsZXNzIiA7LSkpIG1vZGVsLiAgVGhlDQoqKioqIGNydWNpYWwgZmVhdHVy ZSBvZiB0aGlzIHVzZSBjYXNlLCBJIHRoaW5rLCBpcyB0aGF0IHNpbmNlIHRoZXJlIGlzIG5v DQoqKioqIE92ZXJsYXkgSW5kZXgsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIEVWUE4gcmVjdXJz aXZlIHJlc29sdXRpb24sIGhlbmNlIG5vDQoqKioqIG5lZWQgZm9yIGEgTUFDLVZSRiBvbiB0 aGUgREdXcy4NCg0KKioqKiBPZiBjb3Vyc2UsIG9uZSBjb3VsZCBpbWFnaW5lIGEgREdXIHRo YXQgYWxzbyBmdW5jdGlvbmVkIGFzIGFuIE5WRSAod2l0aA0KKioqKiBBQ3MgdG8gYSBwYXJ0 aWN1bGFyIEJEKSwgYnV0IGRpZCBpbnRlci1zdWJuZXQgdW5pY2FzdCByb3V0aW5nIHdpdGhv dXQNCioqKiogdXNlIG9mIGFuIE92ZXJsYXkgSW5kZXguIFdvdWxkIHRoYXQgYmUgY29uc2lk ZXJlZCB0byBiZSB0aGUNCioqKiogaW50ZXJmYWNlLWxlc3MgbW9kZWwsIGV2ZW4gdGhvdWdo IHRoZXJlIGhhcyB0byBiZSBhIE1BQy1WUkYgZm9yIHRoZQ0KKioqKiBhdHRhY2hlZCBCRD8N Cg0KDQoNCg0KNC40LjIgSW50ZXJmYWNlLWZ1bGwgSVAtVlJGLXRvLUlQLVZSRiB3aXRoIGNv cmUtZmFjaW5nIElSQiANCg0KICAgRmlndXJlIDcgd2lsbCBiZSB1c2VkIGZvciB0aGUgZGVz Y3JpcHRpb24gb2YgdGhpcyBtb2RlbC4NCg0KDQoNCg0KDQogDQoNCg0KUmFiYWRhbiBldCBh bC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAgICAgW1Bh Z2UgMjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFkdmVydGlz ZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQogICAgICAgICAgICAgICAgICAg ICAgIE5WRTENCiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICAgIERHVzENCiAgICAgIElQMSstLS0tKyhNQUMtVlJGMSkgIHwgKy0tLS0tLS0tLS0t LS0tLSsgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgfCAgXCAgICAgIChjb3JlKSAg ICAgICAgICAgICAgKGNvcmUpICAgICAgICAgIHwNCiAgICAgICAgICAgICAgfChJUC1WUkYp KE1BQy1WUkYpICAgICAgICAgICAoTUFDLVZSRikoSVAtVlJGKXwtLS0tLSsNCiAgICAgICAg ICAgICAgfCAgLyAgICBJUkIoSVAxL00xKSAgICAgICAgIElSQihJUDMvTTMpICAgICAgIHwg ICAgIHwNCiAgICAgICAgICArLS0tKyhNQUMtVlJGMikgIHwgfCAgICAgICAgICAgICAgIHwg Ky0tLS0tLS0tLS0tLSsgICAgXytfDQogICAgICAgICAgfCAgICstLS0tLS0tLS0tLS0rIHwg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgKCAgICkNCiAgICAgICBTTjF8ICAg ICAgICAgICAgICAgICAgfCAgICAgVlhMQU4vICAgIHwgICAgICAgICAgICAgICAgICggV0FO ICkNCiAgICAgICAgICB8ICAgICAgICAgICAgTlZFMiAgfCAgICAgbnZHUkUvICAgIHwgICAg ICAgICAgICAgICAgICAoX19fKQ0KICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0tKyB8ICAg ICBNUExTICAgICAgfCAgICAgREdXMiAgICAgICAgICAgKw0KICAgICAgICAgICstLS0rKE1B Qy1WUkYyKSAgfCB8ICAgICAgICAgICAgICAgfCArLS0tLS0tLS0tLS0tKyAgICAgfA0KICAg ICAgICAgICAgICB8ICBcICAgICAgKGNvcmUpICAgICAgICAgICAgICAoY29yZSkgICAgICAg ICAgfCAgICAgfA0KICAgICAgICAgICAgICB8KElQLVZSRikoTUFDLVZSRikgICAgICAgICAg IChNQUMtVlJGKShJUC1WUkYpfC0tLS0tKw0KICAgICAgICAgICAgICB8ICAvICAgSVJCKElQ Mi9NMikgICAgICAgICAgSVJCKElQNC9NNCkgICAgICAgfA0KICAgICAgU04yKy0tLS0rKE1B Qy1WUkYzKSAgfCArLS0tLS0tLS0tLS0tLS0tKyArLS0tLS0tLS0tLS0tKw0KICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tKw0KDQoNCiAgICAgICAgIEZpZ3VyZSA3IEludGVyZmFjZS1m dWxsIHdpdGggY29yZS1mYWNpbmcgSVJCIG1vZGVsDQoNCiAgIEluIHRoaXMgbW9kZWw6IA0K DQogICBhKSBBcyBpbiBzZWN0aW9uIDQuNC4xLCB0aGUgTlZFcyBhbmQgREdXcyBtdXN0IHBy b3ZpZGUgY29ubmVjdGl2aXR5DQogICAgICBiZXR3ZWVuIGhvc3RzIGluIFNOMSwgU04yLCBJ UDEgYW5kIGhvc3RzIHNpdHRpbmcgYXQgdGhlIG90aGVyIGVuZA0KICAgICAgb2YgdGhlIFdB Ti4NCg0KICAgYikgSG93ZXZlciwgdGhlIE5WRS9ER1dzIGFyZSBub3cgY29ubmVjdGVkIHRo cm91Z2ggRXRoZXJuZXQgTlZPDQogICAgICB0dW5uZWxzIHRlcm1pbmF0ZWQgaW4gY29yZS1N QUMtVlJGIGluc3RhbmNlcy4gVGhlIElQLVZSRnMgdXNlIElSQg0KICAgICAgaW50ZXJmYWNl cyBmb3IgdGhlaXIgY29ubmVjdGl2aXR5IHRvIHRoZSBjb3JlIE1BQy1WUkZzLg0KDQogICBj KSBFYWNoIGNvcmUtZmFjaW5nIElSQiBoYXMgYW4gSVAgYW5kIGEgTUFDIGFkZHJlc3MsIHdo ZXJlIHRoZSBJUA0KICAgICAgYWRkcmVzcyBtdXN0IGJlIHJlYWNoYWJsZSBmcm9tIG90aGVy IE5WRXMgb3IgREdXcy4gDQoNCiAgIGQpIFRoZSBjb3JlIEVWSSBpcyBjb21wb3NlZCBvZiB0 aGUgTlZFL0RHVyBNQUMtVlJGcyBhbmQgbWF5IGNvbnRhaW4NCiAgICAgIG90aGVyIE1BQy1W UkZzIHdpdGhvdXQgSVJCIGludGVyZmFjZXMuIFRob3NlIG5vbi1JUkIgTUFDLVZSRnMgd2ls bA0KICAgICAgdHlwaWNhbGx5IGNvbm5lY3QgVFNlcyB0aGF0IG5lZWQgbGF5ZXItMyBjb25u ZWN0aXZpdHkgdG8gcmVtb3RlDQogICAgICBzdWJuZXRzLg0KDQogICBlKSBUaGUgc29sdXRp b24gbXVzdCBwcm92aWRlIGxheWVyLTMgY29ubmVjdGl2aXR5IGZvciBFdGhlcm5ldCBOVk8N CiAgICAgIHR1bm5lbHMsIGZvciBpbnN0YW5jZSwgVlhMQU4gb3IgbnZHUkUuDQoNCiAgIEVW UE4gdHlwZSA1IHJvdXRlcyB3aWxsIGJlIHVzZWQgdG8gYWR2ZXJ0aXNlIHRoZSBJUCBQcmVm aXhlcywgd2hlcmVhcw0KICAgRVZQTiBSVC0yIHJvdXRlcyB3aWxsIGFkdmVydGlzZSB0aGUg TUFDL0lQIGFkZHJlc3NlcyBvZiBlYWNoIGNvcmUtDQogICBmYWNpbmcgSVJCIGludGVyZmFj ZS4gRWFjaCBOVkUvREdXIHdpbGwgYWR2ZXJ0aXNlIGFuIFJULTUgZm9yIGVhY2ggb2YNCiAg IGl0cyBwcmVmaXhlcyB3aXRoIHRoZSBmb2xsb3dpbmcgZmllbGRzOg0KDQogICAgICAgIG8g UkQgYXMgcGVyIFtSRkM3NDMyXS4NCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAg ICBNYXJjaCAyMiwgMjAxNw0KDQoNCiAgICAgICAgbyBFdGgtVGFnIElEPTAuDQoNCiAgICAg ICAgbyBJUCBhZGRyZXNzIGxlbmd0aCBhbmQgSVAgYWRkcmVzcywgYXMgZXhwbGFpbmVkIGlu IHRoZSBwcmV2aW91cw0KICAgICAgICAgIHNlY3Rpb25zLg0KDQogICAgICAgIG8gR1cgSVAg YWRkcmVzcz1JUkItSVAgKHRoaXMgaXMgdGhlIE92ZXJsYXkgSW5kZXggdGhhdCB3aWxsIGJl DQogICAgICAgICAgdXNlZCBmb3IgdGhlIHJlY3Vyc2l2ZSByb3V0ZSByZXNvbHV0aW9uKS4N Cg0KICAgICAgICBvIEVTST0wDQoNCiAgICAgICAgbyBMYWJlbCB2YWx1ZSBTSE9VTEQgYmUg emVybyBzaW5jZSB0aGUgUlQtNSByb3V0ZSByZXF1aXJlcyBhDQogICAgICAgICAgcmVjdXJz aXZlIGxvb2t1cCByZXNvbHV0aW9uIHRvIGFuIFJULTIgcm91dGUuIFRoZSBNUExTIGxhYmVs DQogICAgICAgICAgb3IgVk5JIHRvIGJlIHVzZWQgd2hlbiBmb3J3YXJkaW5nIHBhY2tldHMg d2lsbCBiZSBkZXJpdmVkIGZyb20NCiAgICAgICAgICB0aGUgUlQtMidzIE1QTFMgTGFiZWwx IGZpZWxkLiBUaGUgUlQtNSdzIExhYmVsIGZpZWxkIHdpbGwgYmUNCiAgICAgICAgICBpZ25v cmVkIG9uIHJlY2VwdGlvbi4NCg0KKioqKiBJZiB0aGUgUlQtNSdzIGxhYmVsIGZpZWxkIGlz IG5vdCB6ZXJvLCBob3cgZG8geW91IGtub3cgdGhhdCB5b3UncmUNCioqKiogc3VwcG9zZWQg dG8gaWdub3JlIGl0PyAgQmVjYXVzZSB0aGUgR1cgSVAgZmllbGQgaXMgbm9uLXplcm8/ICBU aGlzIGdvZXMNCioqKiogYmFjayB0byBhIHByZXZpb3VzIGNvbW1lbnQsIHRoYXQgaXQgd291 bGQgYmUgZ3JlYXQgdG8gaGF2ZSBhIHRhYmxlIHRoYXQNCioqKiogdGVsbHMsIHlvdSBmb3Ig ZWFjaCBjb21iaW5hdGlvbiBvZiBHVyBJUCwgRVNJLCBMYWJlbCwgYW5kDQoqKioqIHByZXNl bmNlL2Fic2VuY2Ugb2YgUm91dGVyJ3MgTUFDIEVDLCB3aGV0aGVyIHlvdSBoYXZlIGFuIE92 ZXJsYXkgSW5kZXgNCioqKiogYW5kIGlmIHNvLCB3aGljaCBzb3J0IHlvdSBoYXZlLg0KDQog ICBFYWNoIFJULTUgd2lsbCBiZSBzZW50IHdpdGggYSByb3V0ZS10YXJnZXQgaWRlbnRpZnlp bmcgdGhlIHRlbmFudA0KICAgKElQLVZSRikuIFRoZSBSb3V0ZXIncyBNQUMgRXh0ZW5kZWQg Q29tbXVuaXR5IFNIT1VMRCBOT1QgYmUgc2VudCBpbg0KICAgdGhpcyBjYXNlLg0KDQogICBU aGUgZm9sbG93aW5nIGV4YW1wbGUgaWxsdXN0cmF0ZXMgdGhlIHByb2NlZHVyZSB0byBhZHZl cnRpc2UgYW5kDQogICBmb3J3YXJkIHBhY2tldHMgdG8gU04xLzI0IChpcHY0IHByZWZpeCBh ZHZlcnRpc2VkIGZyb20gTlZFMSk6DQoNCiAgICgxKSBOVkUxIGFkdmVydGlzZXMgdGhlIGZv bGxvd2luZyBCR1Agcm91dGVzOg0KDQogICAgICAgIG8gUm91dGUgdHlwZSA1IChJUCBQcmVm aXggcm91dGUpIGNvbnRhaW5pbmc6DQoNCiAgICAgICAgICAuIElQTD0yNCwgSVA9U04xLCBM YWJlbD0gU0hPVUxEIGJlIHNldCB0byAwLg0KDQogICAgICAgICAgLiBHVyBJUD1JUDEgKGNv cmUtZmFjaW5nIElSQidzIElQKQ0KDQoqKioqIEZpZ3VyZSA3IGFsc28gc2hvd3MgSVAxIGFz IGFuIGV4dGVybmFsIHN5c3RlbS4gIFBlcmhhcHMgYSBjdXQtYW5kLXBhc3RlDQoqKioqIGVy cm9yIGZyb20gRmlndXJlIDY/ICAgICAgICAgIA0KDQogICAgICAgICAgLiBSb3V0ZS10YXJn ZXQgaWRlbnRpZnlpbmcgdGhlIHRlbmFudCAoSVAtVlJGKS4NCg0KICAgICAgICBvIFJvdXRl IHR5cGUgMiAoTUFDL0lQIHJvdXRlIGZvciB0aGUgY29yZS1mYWNpbmcgSVJCKQ0KICAgICAg ICAgIGNvbnRhaW5pbmc6DQoNCiAgICAgICAgICAuIE1MPTQ4LCBNPU0xLCBJUEw9MzIsIElQ PUlQMSwgTGFiZWw9MTAuDQoNCiAgICAgICAgICAuIEEgW1JGQzU1MTJdIEJHUCBFbmNhcHN1 bGF0aW9uIEV4dGVuZGVkIENvbW11bml0eS4NCg0KICAgICAgICAgIC4gUm91dGUtdGFyZ2V0 IGlkZW50aWZ5aW5nIHRoZSBjb3JlIE1BQy1WUkYuIFRoaXMgcm91dGUtdGFyZ2V0DQogICAg ICAgICAgICBNQVkgYmUgdGhlIHNhbWUgYXMgdGhlIG9uZSB1c2VkIHdpdGggdGhlIFJULTUu DQoNCiAgICgyKSBER1cxIGltcG9ydHMgdGhlIHJlY2VpdmVkIHJvdXRlcyBmcm9tIE5WRTE6 DQoNCiAgICAgICAgbyBER1cxIGluc3RhbGxzIFNOMS8yNCBpbiB0aGUgSVAtVlJGIGlkZW50 aWZpZWQgYnkgdGhlIFJULTUNCiAgICAgICAgICByb3V0ZS10YXJnZXQuDQoNCiANCg0KDQpS YWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDE3ICAgICAg ICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZQTiBQcmVm aXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJjaCAyMiwgMjAxNw0KDQoNCiAgICAgICAg ICAuIFNpbmNlIEdXIElQIGlzIGRpZmZlcmVudCBmcm9tIHplcm8sIHRoZSBHVyBJUCAoSVAx KSB3aWxsIGJlDQogICAgICAgICAgICB1c2VkIGFzIHRoZSBPdmVybGF5IEluZGV4IGZvciB0 aGUgcmVjdXJzaXZlIHJvdXRlIHJlc29sdXRpb24NCiAgICAgICAgICAgIHRvIHRoZSBSVC0y IGNhcnJ5aW5nIElQMS4NCg0KICAgKDMpIFdoZW4gREdXMSByZWNlaXZlcyBhIHBhY2tldCBm cm9tIHRoZSBXQU4gd2l0aCBkZXN0aW5hdGlvbiBJUHgsDQogICAgICAgd2hlcmUgSVB4IGJl bG9uZ3MgdG8gU04xLzI0Og0KDQogICAgICAgIG8gQSBkZXN0aW5hdGlvbiBJUCBsb29rdXAg aXMgcGVyZm9ybWVkIG9uIHRoZSBER1cxIElQLVZSRg0KICAgICAgICAgIHJvdXRpbmcgdGFi bGUuIFRoZSBsb29rdXAgeWllbGRzIFNOMS8yNCwgd2hpY2ggaXMgYXNzb2NpYXRlZA0KICAg ICAgICAgIHRvIHRoZSBPdmVybGF5IEluZGV4IElQMS4gVGhlIGZvcndhcmRpbmcgaW5mb3Jt YXRpb24gaXMNCiAgICAgICAgICBkZXJpdmVkIGZyb20gdGhlIFJULTIgcmVjZWl2ZWQgZm9y IElQMS4NCg0KICAgICAgICBvIFRoZSBJUCBwYWNrZXQgZGVzdGluZWQgdG8gSVB4IGlzIGVu Y2Fwc3VsYXRlZCB3aXRoOiBTb3VyY2UNCiAgICAgICAgICBpbm5lciBNQUMgPSBNMywgRGVz dGluYXRpb24gaW5uZXIgTUFDID0gTTEsIFNvdXJjZSBvdXRlciBJUA0KICAgICAgICAgIChz b3VyY2UgVlRFUCkgPSBER1cxIElQLCBEZXN0aW5hdGlvbiBvdXRlciBJUCAoZGVzdGluYXRp b24NCiAgICAgICAgICBWVEVQKSA9IE5WRTEgSVAuDQoNCiAgICg0KSBXaGVuIHRoZSBwYWNr ZXQgYXJyaXZlcyBhdCBOVkUxOg0KDQogICAgICAgIG8gTlZFMSB3aWxsIGlkZW50aWZ5IHRo ZSBJUC1WUkYgZm9yIGFuIElQLWxvb2t1cCBiYXNlZCBvbiB0aGUNCiAgICAgICAgICBMYWJl bCBhbmQgdGhlIGlubmVyIE1BQyBEQS4NCg0KICAgICAgICBvIEFuIElQIGxvb2t1cCBpcyBw ZXJmb3JtZWQgaW4gdGhlIHJvdXRpbmcgY29udGV4dCwgd2hlcmUgU04xDQogICAgICAgICAg dHVybnMgb3V0IHRvIGJlIGEgbG9jYWwgc3VibmV0IGFzc29jaWF0ZWQgdG8gTUFDLVZSRjIu IEENCiAgICAgICAgICBzdWJzZXF1ZW50IGxvb2t1cCBpbiB0aGUgQVJQIHRhYmxlIGFuZCB0 aGUgTUFDLVZSRiBGSUIgd2lsbA0KICAgICAgICAgIHByb3ZpZGUgdGhlIGZvcndhcmRpbmcg aW5mb3JtYXRpb24gZm9yIHRoZSBwYWNrZXQgaW4gTUFDLVZSRjIuDQoNCiAgIFRoZSBtb2Rl bCBkZXNjcmliZWQgYWJvdmUgaXMgY2FsbGVkIEludGVyZmFjZS1mdWxsIHdpdGggY29yZS1m YWNpbmcNCiAgIElSQiBtb2RlbCBzaW5jZSB0aGUgdHVubmVscyBjb25uZWN0aW5nIHRoZSBE R1dzIGFuZCBOVkVzIG5lZWQgdG8gYmUNCiAgIHRlcm1pbmF0ZWQgaW50byB0aGUgY29yZSBN QUMtVlJGcy4gVGhvc2UgTUFDLVZSRnMgYXJlIGNvbm5lY3RlZCB0bw0KICAgdGhlIElQLVZS RnMgdmlhIGNvcmUtZmFjaW5nIElSQiBpbnRlcmZhY2VzLiBBbiBFVlBOIElQLVZSRi10by1J UC1WUkYNCiAgIGltcGxlbWVudGF0aW9uIGlzIFJFUVVJUkVEIHRvIHN1cHBvcnQgdGhlIGlu Z3Jlc3MgYW5kIGVncmVzcw0KICAgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0 aW9uLg0KDQoqKioqIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGNydWNpYWwgZmVhdHVyZSBv ZiB0aGlzIGV4YW1wbGUgaXMgdGhhdCBpbg0KKioqKiBvcmRlciBmb3IgREdXMSB0byByZWFj aCBTTjEsIGl0IHVzZXMgSVAxIGFzIGFuIG92ZXJsYXkgaW5kZXgsIGhlbmNlDQoqKioqIG5l ZWRzIHRvIGhhdmUgYW4gUlQyIGZvciByZWN1cnNpdmUgcmVzb2x1dGlvbiwgaGVuY2UgbmVl ZHMgYSBNQUMtVlJGLiAgDQoNCjQuNC4zIEludGVyZmFjZS1mdWxsIElQLVZSRi10by1JUC1W UkYgd2l0aCB1bm51bWJlcmVkIGNvcmUtZmFjaW5nIElSQg0KDQogICBGaWd1cmUgOCB3aWxs IGJlIHVzZWQgZm9yIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGlzIG1vZGVsLiBOb3RlIHRoYXQN CiAgIHRoaXMgbW9kZWwgaXMgc2ltaWxhciB0byB0aGUgb25lIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDQuNC4yLCBvbmx5DQogICB3aXRob3V0IElQIGFkZHJlc3NlcyBvbiB0aGUgY29yZS1m YWNpbmcgSVJCIGludGVyZmFjZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQogDQoNCg0KUmFiYWRh biBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAg ICAgW1BhZ2UgMjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFk dmVydGlzZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQogICAgICAgICAgICAg ICAgICAgICAgIE5WRTENCiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgIERHVzENCiAgICAgIElQMSstLS0tKyhNQUMtVlJGMSkgIHwgKy0tLS0t LS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgfCAgXCAgICAgIChj b3JlKSAgICAgICAgICAgICAgKGNvcmUpICAgICAgICAgIHwNCiAgICAgICAgICAgICAgfChJ UC1WUkYpKE1BQy1WUkYpICAgICAgICAgICAoTUFDLVZSRikoSVAtVlJGKXwtLS0tLSsNCiAg ICAgICAgICAgICAgfCAgLyAgICBJUkIoTTEpfCAgICAgICAgICAgICAgIHwgSVJCKE0zKSAg ICAgIHwgICAgIHwNCiAgICAgICAgICArLS0tKyhNQUMtVlJGMikgIHwgfCAgICAgICAgICAg ICAgIHwgKy0tLS0tLS0tLS0tLSsgICAgXytfDQogICAgICAgICAgfCAgICstLS0tLS0tLS0t LS0rIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgKCAgICkNCiAgICAgICBT TjF8ICAgICAgICAgICAgICAgICAgfCAgICAgVlhMQU4vICAgIHwgICAgICAgICAgICAgICAg ICggV0FOICkNCiAgICAgICAgICB8ICAgICAgICAgICAgTlZFMiAgfCAgICAgbnZHUkUvICAg IHwgICAgICAgICAgICAgICAgICAoX19fKQ0KICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0t KyB8ICAgICBNUExTICAgICAgfCAgICAgREdXMiAgICAgICAgICAgKw0KICAgICAgICAgICst LS0rKE1BQy1WUkYyKSAgfCB8ICAgICAgICAgICAgICAgfCArLS0tLS0tLS0tLS0tKyAgICAg fA0KICAgICAgICAgICAgICB8ICBcICAgICAgKGNvcmUpICAgICAgICAgICAgICAoY29yZSkg ICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICB8KElQLVZSRikoTUFDLVZSRikgICAg ICAgICAgIChNQUMtVlJGKShJUC1WUkYpfC0tLS0tKw0KICAgICAgICAgICAgICB8ICAvICAg IElSQihNMil8ICAgICAgICAgICAgICAgfCBJUkIoTTQpICAgICAgfA0KICAgICAgU04yKy0t LS0rKE1BQy1WUkYzKSAgfCArLS0tLS0tLS0tLS0tLS0tKyArLS0tLS0tLS0tLS0tKw0KICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tKw0KDQoNCiAgICAgICAgIEZpZ3VyZSA4IEludGVy ZmFjZS1mdWxsIHdpdGggdW5udW1iZXJlZCBjb3JlLWZhY2luZyBJUkIgbW9kZWwNCg0KICAg SW4gdGhpcyBtb2RlbDogDQoNCiAgIGEpIEFzIGluIHNlY3Rpb24gNC40LjEgYW5kIDQuNC4y LCB0aGUgTlZFcyBhbmQgREdXcyBtdXN0IHByb3ZpZGUNCiAgICAgIGNvbm5lY3Rpdml0eSBi ZXR3ZWVuIGhvc3RzIGluIFNOMSwgU04yLCBJUDEgYW5kIGhvc3RzIHNpdHRpbmcgYXQNCiAg ICAgIHRoZSBvdGhlciBlbmQgb2YgdGhlIFdBTi4NCg0KICAgYikgQXMgaW4gc2VjdGlvbiA0 LjQuMiwgdGhlIE5WRS9ER1dzIGFyZSBjb25uZWN0ZWQgdGhyb3VnaCBFdGhlcm5ldA0KICAg ICAgTlZPIHR1bm5lbHMgdGVybWluYXRlZCBpbiBjb3JlLU1BQy1WUkYgaW5zdGFuY2VzLiBU aGUgSVAtVlJGcyB1c2UNCiAgICAgIElSQiBpbnRlcmZhY2VzIGZvciB0aGVpciBjb25uZWN0 aXZpdHkgdG8gdGhlIGNvcmUgTUFDLVZSRnMuDQoNCiAgIGMpIEhvd2V2ZXIsIGVhY2ggY29y ZS1mYWNpbmcgSVJCIGhhcyBhIE1BQyBhZGRyZXNzIG9ubHksIGFuZCBubyBJUA0KICAgICAg YWRkcmVzcyAodGhhdCBpcyB3aHkgdGhlIG1vZGVsIHJlZmVycyB0byBhbiAndW5udW1iZXJl ZCcgY29yZS0NCiAgICAgIGZhY2luZyBJUkIpLiBJbiB0aGlzIG1vZGVsLCB0aGVyZSBpcyBu byBuZWVkIHRvIGhhdmUgSVANCiAgICAgIHJlYWNoYWJpbGl0eSB0byB0aGUgY29yZS1mYWNp bmcgSVJCIGludGVyZmFjZXMgdGhlbXNlbHZlcyBhbmQNCiAgICAgIHRoZXJlIGlzIGEgcmVx dWlyZW1lbnQgdG8gc2F2ZSBJUCBhZGRyZXNzZXMgb24gdGhvc2UgaW50ZXJmYWNlcy4NCg0K ICAgZCkgQXMgaW4gc2VjdGlvbiA0LjQuMiwgdGhlIGNvcmUgRVZJIGlzIGNvbXBvc2VkIG9m IHRoZSBOVkUvREdXIE1BQy0NCiAgICAgIFZSRnMgYW5kIG1heSBjb250YWluIG90aGVyIE1B Qy1WUkZzLiANCg0KICAgZSkgQXMgaW4gc2VjdGlvbiA0LjQuMiwgdGhlIHNvbHV0aW9uIG11 c3QgcHJvdmlkZSBsYXllci0zDQogICAgICBjb25uZWN0aXZpdHkgZm9yIEV0aGVybmV0IE5W TyB0dW5uZWxzLCBmb3IgaW5zdGFuY2UsIFZYTEFOIG9yDQogICAgICBudkdSRS4NCg0KICAg VGhpcyBtb2RlbCB3aWxsIGFsc28gbWFrZSB1c2Ugb2YgdGhlIFJULTUgcmVjdXJzaXZlIHJl c29sdXRpb24uIEVWUE4NCiAgIHR5cGUgNSByb3V0ZXMgd2lsbCBhZHZlcnRpc2UgdGhlIElQ IFByZWZpeGVzIGFsb25nIHdpdGggdGhlIFJvdXRlcidzDQogICBNQUMgRXh0ZW5kZWQgQ29t bXVuaXR5IHVzZWQgZm9yIHRoZSByZWN1cnNpdmUgbG9va3VwLCB3aGVyZWFzIEVWUE4NCiAg IFJULTIgcm91dGVzIHdpbGwgYWR2ZXJ0aXNlIHRoZSBNQUMgYWRkcmVzc2VzIG9mIGVhY2gg Y29yZS1mYWNpbmcgSVJCDQogDQoNCg0KUmFiYWRhbiBldCBhbC4gICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAyMywgMjAxNyAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIEVWUE4gUHJlZml4IEFkdmVydGlzZW1lbnQgICAgICAgICAgTWFy Y2ggMjIsIDIwMTcNCg0KDQogICBpbnRlcmZhY2UgKHRoaXMgdGltZSB3aXRob3V0IGFuIElQ KS4gDQoNCiAgIEVhY2ggTlZFL0RHVyB3aWxsIGFkdmVydGlzZSBhbiBSVC01IGZvciBlYWNo IG9mIGl0cyBwcmVmaXhlcyB3aXRoIHRoZQ0KICAgc2FtZSBmaWVsZHMgYXMgZGVzY3JpYmVk IGluIDQuNC4yIGV4Y2VwdCBmb3I6DQoNCiAgICAgICAgbyBHVyBJUCBhZGRyZXNzPSBTSE9V TEQgYmUgc2V0IHRvIDAuDQoNCiAgIEVhY2ggUlQtNSB3aWxsIGJlIHNlbnQgd2l0aCBhIHJv dXRlLXRhcmdldCBpZGVudGlmeWluZyB0aGUgdGVuYW50DQogICAoSVAtVlJGKSBhbmQgdGhl IFJvdXRlcidzIE1BQyBFeHRlbmRlZCBDb21tdW5pdHkgY29udGFpbmluZyB0aGUgTUFDDQog ICBhZGRyZXNzIGFzc29jaWF0ZWQgdG8gY29yZS1mYWNpbmcgSVJCIGludGVyZmFjZS4gVGhp cyBNQUMgYWRkcmVzcyBNQVkNCiAgIGJlIHJlLXVzZWQgZm9yIGFsbCB0aGUgSVAtVlJGcyBp biB0aGUgTlZFLg0KDQogICBUaGUgZXhhbXBsZSBpcyBzaW1pbGFyIHRvIHRoZSBvbmUgaW4g c2VjdGlvbiA0LjQuMjoNCg0KICAgKDEpIE5WRTEgYWR2ZXJ0aXNlcyB0aGUgZm9sbG93aW5n IEJHUCByb3V0ZXM6DQoNCiAgICAgICAgbyBSb3V0ZSB0eXBlIDUgKElQIFByZWZpeCByb3V0 ZSkgY29udGFpbmluZyB0aGUgc2FtZSB2YWx1ZXMgYXMNCiAgICAgICAgICBpbiB0aGUgZXhh bXBsZSBpbiBzZWN0aW9uIDQuNC4yLCBleGNlcHQgZm9yOg0KDQogICAgICAgICAgLiBHVyBJ UD0gU0hPVUxEIGJlIHNldCB0byAwLg0KDQogICAgICAgICAgLiBSb3V0ZXIncyBNQUMgRXh0 ZW5kZWQgQ29tbXVuaXR5IGNvbnRhaW5pbmcgTTEgKHRoaXMgd2lsbCBiZQ0KICAgICAgICAg ICAgdXNlZCBmb3IgdGhlIHJlY3Vyc2l2ZSBsb29rdXAgdG8gYSBSVC0yKS4NCg0KICAgICAg ICBvIFJvdXRlIHR5cGUgMiAoTUFDIHJvdXRlIGZvciB0aGUgY29yZS1mYWNpbmcgSVJCKSB3 aXRoIHRoZSBzYW1lDQogICAgICAgICAgdmFsdWVzIGFzIGluIHNlY3Rpb24gNC40LjIgZXhj ZXB0IGZvcjogDQoNCiAgICAgICAgICAuIE1MPTQ4LCBNPU0xLCBJUEw9MCwgTGFiZWw9MTAu DQoNCiAgICgyKSBER1cxIGltcG9ydHMgdGhlIHJlY2VpdmVkIHJvdXRlcyBmcm9tIE5WRTE6 DQoNCiAgICAgICAgbyBER1cxIGluc3RhbGxzIFNOMS8yNCBpbiB0aGUgSVAtVlJGIGlkZW50 aWZpZWQgYnkgdGhlIFJULTUNCiAgICAgICAgICByb3V0ZS10YXJnZXQuDQoNCiAgICAgICAg ICAuIFRoZSBNQUMgY29udGFpbmVkIGluIHRoZSBSb3V0ZXIncyBNQUMgRXh0ZW5kZWQgQ29t bXVuaXR5DQogICAgICAgICAgICBzZW50IGFsb25nIHdpdGggdGhlIFJULTUgKE0xKSB3aWxs IGJlIHVzZWQgYXMgdGhlIE92ZXJsYXkNCiAgICAgICAgICAgIEluZGV4IGZvciB0aGUgcmVj dXJzaXZlIHJvdXRlIHJlc29sdXRpb24gdG8gdGhlIFJULTINCiAgICAgICAgICAgIGNhcnJ5 aW5nIE0xLg0KDQogICAoMykgV2hlbiBER1cxIHJlY2VpdmVzIGEgcGFja2V0IGZyb20gdGhl IFdBTiB3aXRoIGRlc3RpbmF0aW9uIElQeCwNCiAgICAgICB3aGVyZSBJUHggYmVsb25ncyB0 byBTTjEvMjQ6DQoNCiAgICAgICAgbyBBIGRlc3RpbmF0aW9uIElQIGxvb2t1cCBpcyBwZXJm b3JtZWQgb24gdGhlIERHVzEgSVAtVlJGDQogICAgICAgICAgcm91dGluZyB0YWJsZS4gVGhl IGxvb2t1cCB5aWVsZHMgU04xLzI0LCB3aGljaCBpcyBhc3NvY2lhdGVkDQogICAgICAgICAg dG8gdGhlIE92ZXJsYXkgSW5kZXggTTEuIFRoZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGlz IGRlcml2ZWQNCiAgICAgICAgICBmcm9tIHRoZSBSVC0yIHJlY2VpdmVkIGZvciBNMS4NCg0K ICAgICAgICBvIFRoZSBJUCBwYWNrZXQgZGVzdGluZWQgdG8gSVB4IGlzIGVuY2Fwc3VsYXRl ZCB3aXRoOiBTb3VyY2UNCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAyN10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJj aCAyMiwgMjAxNw0KDQoNCiAgICAgICAgICBpbm5lciBNQUMgPSBNMywgRGVzdGluYXRpb24g aW5uZXIgTUFDID0gTTEsIFNvdXJjZSBvdXRlciBJUA0KICAgICAgICAgIChzb3VyY2UgVlRF UCkgPSBER1cxIElQLCBEZXN0aW5hdGlvbiBvdXRlciBJUCAoZGVzdGluYXRpb24NCiAgICAg ICAgICBWVEVQKSA9IE5WRTEgSVAuDQoNCiAgICg0KSBXaGVuIHRoZSBwYWNrZXQgYXJyaXZl cyBhdCBOVkUxOg0KDQogICAgICAgIG8gTlZFMSB3aWxsIGlkZW50aWZ5IHRoZSBJUC1WUkYg Zm9yIGFuIElQLWxvb2t1cCBiYXNlZCBvbiB0aGUNCiAgICAgICAgICBMYWJlbCBhbmQgdGhl IGlubmVyIE1BQyBEQS4NCg0KICAgICAgICBvIEFuIElQIGxvb2t1cCBpcyBwZXJmb3JtZWQg aW4gdGhlIHJvdXRpbmcgY29udGV4dCwgd2hlcmUgU04xDQogICAgICAgICAgdHVybnMgb3V0 IHRvIGJlIGEgbG9jYWwgc3VibmV0IGFzc29jaWF0ZWQgdG8gTUFDLVZSRjIuIEENCiAgICAg ICAgICBzdWJzZXF1ZW50IGxvb2t1cCBpbiB0aGUgQVJQIHRhYmxlIGFuZCB0aGUgTUFDLVZS RiBGSUIgd2lsbA0KICAgICAgICAgIHByb3ZpZGUgdGhlIGZvcndhcmRpbmcgaW5mb3JtYXRp b24gZm9yIHRoZSBwYWNrZXQgaW4gTUFDLVZSRjIuDQoNCiAgIFRoZSBtb2RlbCBkZXNjcmli ZWQgYWJvdmUgaXMgY2FsbGVkIEludGVyZmFjZS1mdWxsIHdpdGggY29yZS1mYWNpbmcNCiAg IElSQiBtb2RlbCAoYXMgaW4gc2VjdGlvbiA0LjQuMiksIG9ubHkgdGhpcyB0aW1lIHRoZSBj b3JlLWZhY2luZyBJUkINCiAgIGRvZXMgbm90IGhhdmUgYW4gSVAgYWRkcmVzcy4gVGhpcyBt b2RlbCBpcyBPUFRJT05BTCBmb3IgYW4gRVZQTiBJUC0NCiAgIFZSRi10by1JUC1WUkYgaW1w bGVtZW50YXRpb24uDQoNCioqKiogU28gdGhpcyBpcyByZWFsbHkgdGhlIHNhbWUgYXMgdGhl IHByZXZpb3VzIGNhc2UsIGV4Y2VwdDogKGEpIGluc3RlYWQgb2YNCioqKiogdGhlIFJULTUg aGF2aW5nIGFuIElQIGFkZHJlc3MgYXMgb3ZlcmxheSBpbmRleCwgaXQgaGFzIGEgUm91dGVy J3MgTUFDDQoqKioqIEVDIGFzIG92ZXJsYXkgaW5kZXgsIChiKSB0aGUgUlQyIGFkdmVydGlz aW5nIHRoZSBOVkUxJ3MgTUFDIGFkZHJlc3MNCioqKiogZG9lc24ndCBhZHZlcnRpc2UgYSBj b3JyZXNwb25kaW5nIElQIGFkZHJlc3MuDQoNCioqKiogU28gdGhlIHRocmVlIGNhc2VzIGlu IHNlY3Rpb24gNC40IGFyZSByZWFsbHkgKGEpIG5vIE92ZXJsYXkgSW5kZXgsIChiKQ0KKioq KiBPdmVybGF5IEluZGV4IGlzIElQIGFkZHJlc3MsIGFuZCAoYykgT3ZlcmxheSBJbmRleCBp cyBNQUMgYWRkcmVzcy4gIE9mDQoqKioqIGNvdXJzZSwgb25lIG1pZ2h0IHNheSB0aGF0IHRo aXMgaXMgdGhyZWUgc29sdXRpb25zIHRvIG9uZSBwcm9ibGVtLCBhbmQNCioqKiogYXNrIHdo eSB3ZSBuZWVkIHRocmVlIHNvbHV0aW9ucy4gIEJ1dCBzaW5jZSB0aGlzIGRvY3VtZW50J3Mg YmVlbiBhcm91bmQNCioqKiogZm9yIGF3aGlsZSwgSSB3b24ndCBhc2sgdGhhdCBxdWVzdGlv bi4NCg0KNS4gQ29uY2x1c2lvbnMNCg0KICAgQW4gRVZQTiByb3V0ZSAodHlwZSA1KSBmb3Ig dGhlIGFkdmVydGlzZW1lbnQgb2YgSVAgUHJlZml4ZXMgaXMNCiAgIGRlc2NyaWJlZCBpbiB0 aGlzIGRvY3VtZW50LiBUaGlzIG5ldyByb3V0ZSB0eXBlIGhhcyBhIGRpZmZlcmVudGlhdGVk DQogICByb2xlIGZyb20gdGhlIFJULTIgcm91dGUgYW5kIGFkZHJlc3NlcyB0aGUgRGF0YSBD ZW50ZXIgKG9yIE5WTy1iYXNlZA0KICAgbmV0d29ya3MgaW4gZ2VuZXJhbCkgaW50ZXItc3Vi bmV0IGNvbm5lY3Rpdml0eSBzY2VuYXJpb3MgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3Vt ZW50LiBVc2luZyB0aGlzIG5ldyBSVC01LCBhbiBJUCBQcmVmaXggbWF5IGJlIGFkdmVydGlz ZWQNCiAgIGFsb25nIHdpdGggYW4gT3ZlcmxheSBJbmRleCB0aGF0IGNhbiBiZSBhIEdXIElQ IGFkZHJlc3MsIGEgTUFDIG9yIGFuDQogICBFU0ksIG9yIHdpdGhvdXQgYW4gT3ZlcmxheSBJ bmRleCwgaW4gd2hpY2ggY2FzZSB0aGUgQkdQIG5leHQtaG9wIHdpbGwNCiAgIHBvaW50IGF0 IHRoZSBlZ3Jlc3MgTlZFL0FTQlIvQUJSIGFuZCB0aGUgTUFDIGluIHRoZSBSb3V0ZXIncyBN QUMNCiAgIEV4dGVuZGVkIENvbW11bml0eSB3aWxsIHByb3ZpZGUgdGhlIGlubmVyIE1BQyBk ZXN0aW5hdGlvbiBhZGRyZXNzIHRvDQogICBiZSB1c2VkLiBBcyBkaXNjdXNzZWQgdGhyb3Vn aG91dCB0aGUgZG9jdW1lbnQsIHRoZSBFVlBOIFJULTIgZG9lcyBub3QNCiAgIG1lZXQgdGhl IHJlcXVpcmVtZW50cyBmb3IgYWxsIHRoZSBEQyB1c2UgY2FzZXMsIHRoZXJlZm9yZSB0aGlz IEVWUE4NCiAgIHJvdXRlIHR5cGUgNSBpcyByZXF1aXJlZC4NCg0KICAgVGhlIEVWUE4gcm91 dGUgdHlwZSA1IGRlY291cGxlcyB0aGUgSVAgUHJlZml4IGFkdmVydGlzZW1lbnRzIGZyb20g dGhlDQogICBNQUMvSVAgcm91dGUgYWR2ZXJ0aXNlbWVudHMgaW4gRVZQTiwgaGVuY2U6DQoN CiAgIGEpIEFsbG93cyB0aGUgY2xlYW4gYW5kIGNsZWFyIGFkdmVydGlzZW1lbnRzIG9mIGlw djQgb3IgaXB2NiBwcmVmaXhlcw0KICAgICAgaW4gYW4gTkxSSSB3aXRoIG5vIE1BQyBhZGRy ZXNzZXMuDQoNCiAgIGIpIFNpbmNlIHRoZSByb3V0ZSB0eXBlIGlzIGRpZmZlcmVudCBmcm9t IHRoZSBNQUMvSVAgQWR2ZXJ0aXNlbWVudA0KICAgICAgcm91dGUsIHRoZSBjdXJyZW50IFtS RkM3NDMyXSBwcm9jZWR1cmVzIGRvIG5vdCBuZWVkIHRvIGJlDQogICAgICBtb2RpZmllZC4N Cg0KICAgYykgQWxsb3dzIGEgZmxleGlibGUgaW1wbGVtZW50YXRpb24gd2hlcmUgdGhlIHBy ZWZpeCBjYW4gYmUgbGlua2VkIHRvDQogICAgICBkaWZmZXJlbnQgdHlwZXMgb2YgT3Zlcmxh eSBJbmRleGVzOiBvdmVybGF5IElQIGFkZHJlc3MsIG92ZXJsYXkNCiAgICAgIE1BQyBhZGRy ZXNzZXMsIG92ZXJsYXkgRVNJLCB1bmRlcmxheSBCR1AgbmV4dC1ob3BzLCBldGMuIA0KDQog DQoNCg0KUmFiYWRhbiBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAx NyAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVW UE4gUHJlZml4IEFkdmVydGlzZW1lbnQgICAgICAgICAgTWFyY2ggMjIsIDIwMTcNCg0KDQog ICBkKSBBbiBFVlBOIGltcGxlbWVudGF0aW9uIG5vdCByZXF1aXJpbmcgSVAgUHJlZml4ZXMg Y2FuIHNpbXBseQ0KICAgICAgZGlzY2FyZCB0aGVtIGJ5IGxvb2tpbmcgYXQgdGhlIHJvdXRl IHR5cGUgdmFsdWUuIA0KDQoNCjYuIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVu dA0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwg IlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVD T01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQg YXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMtMjExOSBbUkZDMjEx OV0uDQoNCjcuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBkaXNjdXNzZWQgaW4gW1JGQzc0MzJdIGFwcGx5IHRvIHRoaXMNCiAg IGRvY3VtZW50Lg0KDQo4LiBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1l bnQgcmVxdWVzdHMgdGhlIGFsbG9jYXRpb24gb2YgdmFsdWUgNSBpbiB0aGUgIkVWUE4gUm91 dGUNCiAgIFR5cGVzIiByZWdpc3RyeSBkZWZpbmVkIGJ5IFtSRkM3NDMyXToNCg0KICAgVmFs dWUgICAgIERlc2NyaXB0aW9uICAgICAgICAgUmVmZXJlbmNlDQogICA1ICAgICAgICAgSVAg UHJlZml4IHJvdXRlICAgICBbdGhpcyBkb2N1bWVudF0NCg0KDQoNCjkuIFJlZmVyZW5jZXMN Cg0KOS4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkM0MzY0XVJvc2VuLCBFLiBh bmQgWS4gUmVraHRlciwgIkJHUC9NUExTIElQIFZpcnR1YWwgUHJpdmF0ZQ0KICAgTmV0d29y a3MgKFZQTnMpIiwgUkZDIDQzNjQsIERPSSAxMC4xNzQ4Ny9SRkM0MzY0LCBGZWJydWFyeSAy MDA2LA0KICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0MzY0Pi4NCg0K ICAgW1JGQzc0MzJdU2FqYXNzaSwgQS4sIEVkLiwgQWdnYXJ3YWwsIFIuLCBCaXRhciwgTi4s IElzYWFjLCBBLiwNCiAgIFV0dGFybywgSi4sIERyYWtlLCBKLiwgYW5kIFcuIEhlbmRlcmlj a3gsICJCR1AgTVBMUy1CYXNlZCBFdGhlcm5ldA0KICAgVlBOIiwgUkZDIDc0MzIsIERPSSAx MC4xNzQ4Ny9SRkM3NDMyLCBGZWJydWFyeSAyMDE1LCA8aHR0cDovL3d3dy5yZmMtDQogICBl ZGl0b3Iub3JnL2luZm8vcmZjNzQzMj4uDQoNCiAgIFtSRkM3NjA2XUNoZW4sIEUuLCBTY3Vk ZGVyLCBKLiwgTW9oYXBhdHJhLCBQLiwgYW5kIEsuIFBhdGVsLCAiUmV2aXNlZA0KICAgRXJy b3IgSGFuZGxpbmcgZm9yIEJHUCBVUERBVEUgTWVzc2FnZXMiLCBSRkMgNzYwNiwgQXVndXN0 IDIwMTUsDQogICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2MDY+LiAg IA0KDQogICBbRVZQTi1JTlRFUlNVQk5FVF0gU2FqYXNzaSBldCBhbC4sICJJUCBJbnRlci1T dWJuZXQgRm9yd2FyZGluZyBpbg0KICAgRVZQTiIsIGRyYWZ0LWlldGYtYmVzcy1ldnBuLWlu dGVyLXN1Ym5ldC1mb3J3YXJkaW5nLTAzLnR4dCwgd29yayBpbg0KICAgcHJvZ3Jlc3MsIEZl YnJ1YXJ5LCAyMDE3DQoNCiAgIFtFVlBOLU9WRVJMQVldIFNhamFzc2ktRHJha2UgZXQgYWwu LCAiQSBOZXR3b3JrIFZpcnR1YWxpemF0aW9uDQogICBPdmVybGF5IFNvbHV0aW9uIHVzaW5n IEVWUE4iLCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LTA3LnR4dCwNCiANCioqKiog VGhpbmsgY2FyZWZ1bGx5IGFib3V0IHdoZXRoZXIgdGhlIHJlZmVyZW5jZXMgdG8gdGhlIGFi b3ZlIHR3byBkcmFmdHMNCioqKiogYXJlIHJlYWxseSBub3JtYXRpdmUuICBJJ20gbm90IHN1 cmUgYWJvdXQgW0VWUE4tSU5URVJTVUJORVRdLCBidXQgSQ0KKioqKiBkb24ndCB0aGluayB0 aGUgcmVmZXJuZWNlIHRvIFtFVlBOLU9WRVJMQVldIGlzIHJlYWxseSBub3JtYXRpdmUuDQoq KioqIE5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGludGVybmV0LWRyYWZ0cyBjYW4gcmVzdWx0 IGluIGFuIFJGQy10by1iZQ0KKioqKiByZW1haW5pbmcgb24gdGhlIHB1YmxpY2F0aW9uIHF1 ZXVlIGZvciB5ZWFycyBhbmQgeWVhcnMuICAoRG9uJ3QgYXNrIG1lDQoqKioqIGhvdyBJIGtu b3cgOy0pKQ0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIz LCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAyOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJjaCAyMiwgMjAxNw0K DQoNCiAgIHdvcmsgaW4gcHJvZ3Jlc3MsIE5vdmVtYmVyLCAyMDE2DQoNCg0KOS4yIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMNCg0KDQoNCjEwLiBBY2tub3dsZWRnbWVudHMNCg0KICAgVGhl IGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBNdWt1bCBLYXRpeWFyLCBFcmljIFJvc2Vu IGFuZCBKZWZmcmV5DQogICBaaGFuZyBmb3IgdGhlaXIgdmFsdWFibGUgZmVlZGJhY2sgYW5k IGNvbnRyaWJ1dGlvbnMuIFRoZSBmb2xsb3dpbmcNCiAgIHBlb3BsZSBhbHNvIGhlbHBlZCBp bXByb3ZpbmcgdGhpcyBkb2N1bWVudCB3aXRoIHRoZWlyIGZlZWRiYWNrOiBUb255DQogICBQ cnp5Z2llbmRhIGFuZCBUaG9tYXMgTW9yaW4uICANCg0KMTEuIENvbnRyaWJ1dG9ycw0KDQog ICBJbiBhZGRpdGlvbiB0byB0aGUgYXV0aG9ycyBsaXN0ZWQgb24gdGhlIGZyb250IHBhZ2Us IHRoZSBmb2xsb3dpbmcNCiAgIGNvLWF1dGhvcnMgaGF2ZSBhbHNvIGNvbnRyaWJ1dGVkIHRv IHRoaXMgZG9jdW1lbnQ6DQoNCiAgIFNlbnRoaWwgU2F0aGFwcGFuDQogICBGbG9yaW4gQmFs dXMNCiAgIEFsZHJpbiBJc2FhYw0KICAgU2VuYWQgUGFsaXNsYW1vdmljDQoNCg0KMTIuIEF1 dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBKb3JnZSBSYWJhZGFuIChFZGl0b3IpDQogICBOb2tp YQ0KICAgNzc3IEUuIE1pZGRsZWZpZWxkIFJvYWQNCiAgIE1vdW50YWluIFZpZXcsIENBIDk0 MDQzIFVTQQ0KICAgRW1haWw6IGpvcmdlLnJhYmFkYW5Abm9raWEuY29tDQoNCiAgIFdpbSBI ZW5kZXJpY2t4DQogICBOb2tpYQ0KICAgRW1haWw6IHdpbS5oZW5kZXJpY2t4QG5va2lhLmNv bQ0KDQogICBKb2huIEUuIERyYWtlDQogICBKdW5pcGVyIA0KICAgRW1haWw6IGpkcmFrZUBq dW5pcGVyLm5ldA0KDQogICBBbGkgU2FqYXNzaQ0KICAgQ2lzY28NCiAgIEVtYWlsOiBzYWph c3NpQGNpc2NvLmNvbQ0KDQogICBXZW4gTGluDQogICBKdW5pcGVyIA0KICAgRW1haWw6IHds aW5AanVuaXBlci5uZXQNCiANCg0KDQpSYWJhZGFuIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDIzLCAyMDE3ICAgICAgICAgICAgICBbUGFnZSAzMF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgRVZQTiBQcmVmaXggQWR2ZXJ0aXNlbWVudCAgICAgICAgICBNYXJj aCAyMiwgMjAxNw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNClJhYmFkYW4gZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMs IDIwMTcgICAgICAgICAgICAgIFtQYWdlIDMxXQ0K --------------A9BD5004DD6085E164C27775-- From nobody Wed Apr 19 12:54:47 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFF1128C83; Wed, 19 Apr 2017 12:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piAhVzrmYj9A; Wed, 19 Apr 2017 12:54:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43C0126CF9; Wed, 19 Apr 2017 12:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2062; q=dns/txt; s=iport; t=1492631672; x=1493841272; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Eh18pn4A8GTnM5yZR5kL1CgpPUfTjX1EndHXxNZtxxY=; b=A94gniVdaJufF8jns13UEwX5dajYX8egzvd2ZA9CCFPTUKu5YCYo8r50 5FYB1Z74eMHfLrmnwBKWWew1VIRFFPZ+JkOZCv+vRleCi6BotiEZZOXmk NLjBpwxnyt28JhuBzNT5Pnq1QEXZFIeFT4PaJ/BKrraefjhYfb9ojCILV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQBXv/dY/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg2CKFadFgg8hC4V4AhqDaj8YAQIBAQEBAQEBayiFFgI?= =?us-ascii?q?BAwEBIRE3AwsOAgIBCBoCJgICAhkMCxUQAgQBDQWKGQ6qRIImiyMBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBQWBBoclgxmEKREBHBeCb4JfBZ0vAZJ7ggCFMYoblBA?= =?us-ascii?q?BHzh9CGMVRIZldYY9gSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,222,1488844800"; d="scan'208";a="224581688" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2017 19:54:30 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3JJsUYD011453 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 19:54:30 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 15:54:30 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 19 Apr 2017 15:54:29 -0400 From: "Acee Lindem (acee)" To: Loa Andersson , "mpls@ietf.org" , "idr@ietf.org" , BESS CC: "" , "idr-chairs@ietf.org" , "bess-chairs@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-rfc3107bis@ietf.org" Thread-Topic: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis Thread-Index: AQHSrT+0pZ+pKED8tkaO8CVLK3IlrKHNMv8A Date: Wed, 19 Apr 2017 19:54:29 +0000 Message-ID: References: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> In-Reply-To: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <06BBB64166965B469585A7202AC419F8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:54:33 -0000 SGkgTG9hLCBldCBhbCwgDQoNCkkgc3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0IGFz IGEgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50LiBJdCBpcw0Kd2VsbC13cml0dGVuIGFuZCBoYW5k bGVzIHByZXZpb3VzbHkgdW5zcGVjaWZpZWQgZGV0YWlscyBvZiBzaW5nbGUgYW5kDQptdWx0aXBs ZSBsYWJlbCBCR1AgYWR2ZXJ0aXNlbWVudC4NCg0KVGhhbmtzLA0KQWNlZSANCg0KT24gNC80LzE3 LCA4OjMzIEFNLCAiQkVTUyBvbiBiZWhhbGYgb2YgTG9hIEFuZGVyc3NvbiINCjxiZXNzLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxvYUBwaS5udT4gd3JvdGU6DQoNCj5Xb3JraW5nIEdy b3VwcywNCj4NCj5UaGlzIGlzIHRvIGluaXRpYXRlIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBs YXN0IGNhbGwgaW4gZm91ciB3b3JraW5nDQo+Z3JvdXBzIG9uIGRyYWZ0LWlldGYtbXBscy1yZmMz MTA3YmlzLTAxLg0KPg0KPkFjY29yZGluZyB0byBhZ3JlZW1lbnQgd2hlbiB3ZSBkZWNpZGVkIHRv IGhvc3QgdGhpcyBkb2N1bWVudCBpbiB0aGUNCj5NUExTIHdvcmtpbmcgZ3JvdXAsIHRoaXMgbGFz dCBjYWxsIGlzIGFsc28gY29waWVkIHRvIHRoZSBJRFIgYW5kIEJFU1MNCj53b3JraW5nIGdyb3Vw cy4NCj4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcg bGlzdCAobXBsc0BpZXRmLm9yZyksDQo+aWYgeW91IGFyZSBub3Qgc3Vic2NyaWJlZCB0byB0aGUg bXBscyB3ZyBsaXN0LCBzZW5kIHRvICJ5b3VyIG93biINCj53b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdCwgYW5kIHdlJ2xsIG1ha2Ugc3VyZSB0aGV5IGFyZSBwb3N0ZWQgdG8gdGhlDQo+TVBMUyB3 ZyBsaXN0Lg0KPg0KPlRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCB0aGlzIGRv Y3VtZW50Lg0KPg0KPkFsbCB0aGUgYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIGhhdmUgc3RhdGVk IG9uIHRoZSB3b3JraW5nIGdyb3VwDQo+bWFpbGluZyBsaXN0IHRoYXQgdGhleSBhcmUgbm90IGF3 YXJlIG9mIGFueSBvdGhlciBJUFJzIHRoYXQgcmVsYXRlcw0KPnRvIHRoaXMgZG9jdW1lbnQuDQo+ DQo+VGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIEFwcmlsIDIwLCAyMDE3Lg0KPg0K Pg0KPi9Mb2ENCj5NUExTIHdnIGNvLWNoYWlycw0KPi0tIA0KPg0KPg0KPkxvYSBBbmRlcnNzb24g ICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+U2Vu aW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj5IdWF3 ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQN Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkJF U1MgbWFpbGluZyBsaXN0DQo+QkVTU0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYmVzcw0KDQo= From nobody Wed Apr 19 14:05:15 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B48412E852 for ; Wed, 19 Apr 2017 14:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJzC7ZNSdvoV for ; Wed, 19 Apr 2017 14:05:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEB0129400 for ; Wed, 19 Apr 2017 14:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1693; q=dns/txt; s=iport; t=1492635911; x=1493845511; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rHUvmiLacvSplIe/KYpuXviFTRFTFlWP2tSEPQSctaM=; b=DsyGboKkz9xtulAx01El9OTZk9xgWSIXuF+VKRntYyWEN52vmU6VVBT9 8FCO/31P4oI8LkzqhFbdWbx9sTDo56B+RqvEUm3quIE26Nx1AMQYIghnO D68Rg1mlzLiOpTsc/sG89t4bHNpAZSyZfkTHVAXN2fsDX7NVDIeaXyf/W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAAC80PdY/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjXWRY5Vigg8hC4V4AoQFPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMBATgxAxcCAgIBCBEEAQEfCQcbDAsUCQgCBAESCIoRDqxtiyQBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBQWGToFdgxmEKREBhgEFlj6GcQGScoIJhTGKG5QQAR8?= =?us-ascii?q?4fQhjFUSGZXWGPYEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,222,1488844800"; d="scan'208";a="233156251" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 21:04:54 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3JL4soC017144 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 21:04:54 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 16:04:53 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 19 Apr 2017 16:04:53 -0500 From: "Jakob Heitz (jheitz)" To: Loa Andersson , BESS Thread-Topic: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis Thread-Index: AQHSrT+1lLpEyIz6cku6ZbjTjy+Mu6HNRohQ Date: Wed, 19 Apr 2017 21:04:53 +0000 Message-ID: <9fc98a390d6d4f22942e820bf4df90f8@XCH-ALN-014.cisco.com> References: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> In-Reply-To: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.162.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:05:13 -0000 Support. Thanks, Jakob. > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, April 04, 2017 5:33 AM > To: mpls@ietf.org; idr@ietf.org; BESS > Cc: ; idr-chairs@ietf.org; bess-chai= rs@ietf.org; mpls-chairs@ietf.org; draft- > ietf-mpls-rfc3107bis@ietf.org > Subject: [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis >=20 > Working Groups, >=20 > This is to initiate a two week working group last call in four working > groups on draft-ietf-mpls-rfc3107bis-01. >=20 > According to agreement when we decided to host this document in the > MPLS working group, this last call is also copied to the IDR and BESS > working groups. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org), > if you are not subscribed to the mpls wg list, send to "your own" > working group mailing list, and we'll make sure they are posted to the > MPLS wg list. >=20 > There are no IPR disclosures against this document. >=20 > All the authors and contributors have stated on the working group > mailing list that they are not aware of any other IPRs that relates > to this document. >=20 > This working group last call ends April 20, 2017. >=20 >=20 > /Loa > MPLS wg co-chairs > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Apr 20 07:12:38 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F294412D0C3; Wed, 19 Apr 2017 13:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOtEBCnYG9l2; Wed, 19 Apr 2017 13:47:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF46129BCC; Wed, 19 Apr 2017 13:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2768; q=dns/txt; s=iport; t=1492634871; x=1493844471; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9D3UCdXkf5Tz+PWvMIoUzgbmzCwYZxSmllEPZ7wmk2Y=; b=aSmtOj5UJx7kZIa0JxdgmWSkDqOPwo/89icoYbYwiMX0xZq7G2Iq6j8x 02C+LfB3Mt/Eb+kbRKbPkfHgqx7ofivDDoL9ysQbmkAAq1wERAyr37CBH tPqne5YrZo8sg6qCXWk40h8Ob/qr5J0AK3tIM9Hk2KZtks8ncuCpeBcQM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgDGzPdY/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg2CKFZFClgOCDyELhXgcg2s/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?CAQMBASERNwMLDgQBCBoCJgIEGQwLFRIEAQ0FihkOqkOCJoskAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAUFgQaFSIFdKwuCY4QpEQEcF4JvLoIxBZY+hnEBknuCAIU?= =?us-ascii?q?xihuUEAEfOH0IYxVEEQGGU3WGPYEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,222,1488844800"; d="scan'208";a="412620727" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 20:47:30 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3JKlUjQ000958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 20:47:30 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 16:47:29 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Wed, 19 Apr 2017 16:47:29 -0400 From: "Gaurav Dawra (gdawra)" To: "Acee Lindem (acee)" , Loa Andersson , "mpls@ietf.org" , "idr@ietf.org" , BESS CC: "" , "idr-chairs@ietf.org" , "bess-chairs@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-rfc3107bis@ietf.org" Thread-Topic: [Idr] [bess] Working Group Last Call on draft-ietf-mpls-rfc3107bis Thread-Index: AQHSuU4oZy7oQxkWrEWxCTKxQwoEPg== Date: Wed, 19 Apr 2017 20:47:29 +0000 Message-ID: <5398C64D-3794-43FD-8118-B63202F67958@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.210] Content-Type: text/plain; charset="utf-8" Content-ID: <7EB1E9DEE5094042A6B289FEAC3C4FE0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 20 Apr 2017 07:12:37 -0700 Subject: Re: [bess] [Idr] Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:47:53 -0000 U3VwcG9ydCB0aGUgcHVibGljYXRpb24uDQoNClJlZ2FyZHMsDQogDQpHYXVyYXYNCg0KT24gNC8x OS8xNywgMTI6NTQgUE0sICJJZHIgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIChhY2VlKSIgPGlk ci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoN CiAgICBIaSBMb2EsIGV0IGFsLCANCiAgICANCiAgICBJIHN1cHBvcnQgcHVibGljYXRpb24gb2Yg dGhpcyBkcmFmdCBhcyBhIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudC4gSXQgaXMNCiAgICB3ZWxs LXdyaXR0ZW4gYW5kIGhhbmRsZXMgcHJldmlvdXNseSB1bnNwZWNpZmllZCBkZXRhaWxzIG9mIHNp bmdsZSBhbmQNCiAgICBtdWx0aXBsZSBsYWJlbCBCR1AgYWR2ZXJ0aXNlbWVudC4NCiAgICANCiAg ICBUaGFua3MsDQogICAgQWNlZSANCiAgICANCiAgICBPbiA0LzQvMTcsIDg6MzMgQU0sICJCRVNT IG9uIGJlaGFsZiBvZiBMb2EgQW5kZXJzc29uIg0KICAgIDxiZXNzLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGxvYUBwaS5udT4gd3JvdGU6DQogICAgDQogICAgPldvcmtpbmcgR3JvdXBz LA0KICAgID4NCiAgICA+VGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGluIGZvdXIgd29ya2luZw0KICAgID5ncm91cHMgb24gZHJhZnQtaWV0Zi1t cGxzLXJmYzMxMDdiaXMtMDEuDQogICAgPg0KICAgID5BY2NvcmRpbmcgdG8gYWdyZWVtZW50IHdo ZW4gd2UgZGVjaWRlZCB0byBob3N0IHRoaXMgZG9jdW1lbnQgaW4gdGhlDQogICAgPk1QTFMgd29y a2luZyBncm91cCwgdGhpcyBsYXN0IGNhbGwgaXMgYWxzbyBjb3BpZWQgdG8gdGhlIElEUiBhbmQg QkVTUw0KICAgID53b3JraW5nIGdyb3Vwcy4NCiAgICA+DQogICAgPlBsZWFzZSBzZW5kIHlvdXIg Y29tbWVudHMgdG8gdGhlIG1wbHMgd2cgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKSwNCiAg ICA+aWYgeW91IGFyZSBub3Qgc3Vic2NyaWJlZCB0byB0aGUgbXBscyB3ZyBsaXN0LCBzZW5kIHRv ICJ5b3VyIG93biINCiAgICA+d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QsIGFuZCB3ZSdsbCBt YWtlIHN1cmUgdGhleSBhcmUgcG9zdGVkIHRvIHRoZQ0KICAgID5NUExTIHdnIGxpc3QuDQogICAg Pg0KICAgID5UaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhpcyBkb2N1bWVu dC4NCiAgICA+DQogICAgPkFsbCB0aGUgYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIGhhdmUgc3Rh dGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwDQogICAgPm1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJl IG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBScyB0aGF0IHJlbGF0ZXMNCiAgICA+dG8gdGhpcyBk b2N1bWVudC4NCiAgICA+DQogICAgPlRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBB cHJpbCAyMCwgMjAxNy4NCiAgICA+DQogICAgPg0KICAgID4vTG9hDQogICAgPk1QTFMgd2cgY28t Y2hhaXJzDQogICAgPi0tIA0KICAgID4NCiAgICA+DQogICAgPkxvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQogICAgPlNlbmlv ciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQogICAgPkh1 YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2 NA0KICAgID4NCiAgICA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICA+QkVTUyBtYWlsaW5nIGxpc3QNCiAgICA+QkVTU0BpZXRmLm9yZw0KICAgID5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCiAgICANCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIElkciBtYWls aW5nIGxpc3QNCiAgICBJZHJAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KICAgIA0KDQo= From nobody Thu Apr 20 09:42:08 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B9C1293DF; Thu, 20 Apr 2017 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngOjrzrqTwsK; Thu, 20 Apr 2017 08:31:46 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0092.outbound.protection.outlook.com [104.47.41.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F3A129AAF; Thu, 20 Apr 2017 08:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HS4LRViKML3QesZ3LS/RemEh7FuatDs6hFj0c47A4Ik=; b=HfRgfE5Rag4bTQJf/yGKV6I6FiH5BQ7R8jQHrtWH7SzYvza9DF/YfkDYt69SRB+OCPf90QfHrbZZ1BOKdIA2GPm43fa7GTfR3rk4+05xLMWvi6uIuu9NFLOAncDotP3JeQdBQTLOPLc5l/V+zFNSxypa4NAk2NOY9shH98j/E5E= Received: from MWHPR05MB3151.namprd05.prod.outlook.com (10.173.229.17) by MWHPR05MB3149.namprd05.prod.outlook.com (10.173.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 20 Apr 2017 15:31:44 +0000 Received: from MWHPR05MB3151.namprd05.prod.outlook.com ([10.173.229.17]) by MWHPR05MB3151.namprd05.prod.outlook.com ([10.173.229.17]) with mapi id 15.01.1047.008; Thu, 20 Apr 2017 15:31:44 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Acee Lindem (acee)" , Loa Andersson , "mpls@ietf.org" , "idr@ietf.org" , BESS CC: "" , "idr-chairs@ietf.org" , "bess-chairs@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-rfc3107bis@ietf.org" Thread-Topic: [bess] [Idr] Working Group Last Call on draft-ietf-mpls-rfc3107bis Thread-Index: AQHSuU4oZy7oQxkWrEWxCTKxQwoEPqHOY4Kg Date: Thu, 20 Apr 2017 15:31:44 +0000 Message-ID: References: <5398C64D-3794-43FD-8118-B63202F67958@cisco.com> In-Reply-To: <5398C64D-3794-43FD-8118-B63202F67958@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3149; 7:JCT1TGvH8CWeOEIbmMZcaqcfVWYlgBvUI1NMFk9Jk+md1DGKX+pRLQ0R8m5YzTkQ6rtl7OH60g7a6lwSQf6mwm1uoMNxzolJfT9VXJsPYHawR8h7Djx0TJajlLY2yFhTCPjhfW2sacfTcyjeT8iQQhJJGTcxa60KCcDtA9DWrb3HQvWJ9XMkSEZ1BRnsxeSuHlfo1qJ72ZkrVBCQOZcXJSTV6EE0Tzf/Q/GDPEVAC9k349DCCtw9wUZQ/GIckgC+HrhO5OjOuRMZ4We1KsibUXyKQGyQmiVplbIOTqYcqSQqRPgZS/GJWZafv+9ZZcRRCBoQ+DoQUaMNbbAxKMBsyw== x-ms-office365-filtering-correlation-id: 1ddc48ec-0af3-42d1-138d-08d4880259e1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR05MB3149; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR05MB3149; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3149; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39400400002)(39860400002)(39450400003)(39850400002)(377454003)(24454002)(252514010)(55016002)(2501003)(6506006)(305945005)(6306002)(50986999)(9686003)(7736002)(8936002)(2900100001)(66066001)(99286003)(122556002)(54356999)(3660700001)(76176999)(74316002)(81166006)(3280700002)(229853002)(2906002)(4326008)(77096006)(2950100002)(53546009)(7696004)(33656002)(189998001)(6116002)(2201001)(5660300001)(86362001)(6246003)(25786009)(8676002)(3846002)(102836003)(53936002)(230783001)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3149; H:MWHPR05MB3151.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 15:31:44.3616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3149 Archived-At: X-Mailman-Approved-At: Thu, 20 Apr 2017 09:42:08 -0700 Subject: Re: [bess] [Idr] Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 15:31:48 -0000 I support as well. > On 4/19/17, 12:54 PM, "Idr on behalf of Acee Lindem (acee)" bounces@ietf.org on behalf of acee@cisco.com> wrote: >=20 > Hi Loa, et al, >=20 > I support publication of this draft as a standards track document. It= is > well-written and handles previously unspecified details of single and > multiple label BGP advertisement. >=20 > Thanks, > Acee >=20 > On 4/4/17, 8:33 AM, "BESS on behalf of Loa Andersson" > wrote: >=20 > >Working Groups, > > > >This is to initiate a two week working group last call in four worki= ng > >groups on draft-ietf-mpls-rfc3107bis-01. > > > >According to agreement when we decided to host this document in the > >MPLS working group, this last call is also copied to the IDR and BES= S > >working groups. > > > >Please send your comments to the mpls wg mailing list (mpls@ietf.org= ), > >if you are not subscribed to the mpls wg list, send to "your own" > >working group mailing list, and we'll make sure they are posted to t= he > >MPLS wg list. > > > >There are no IPR disclosures against this document. > > > >All the authors and contributors have stated on the working group > >mailing list that they are not aware of any other IPRs that relates > >to this document. > > > >This working group last call ends April 20, 2017. > > > > > >/Loa > >MPLS wg co-chairs > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > >_______________________________________________ > >BESS mailing list > >BESS@ietf.org > >https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Apr 20 10:21:20 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7A2129B39; Thu, 20 Apr 2017 10:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4ND39ZERdSy; Thu, 20 Apr 2017 10:21:09 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D91129B2D; Thu, 20 Apr 2017 10:21:08 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id 11so30046052ybw.1; Thu, 20 Apr 2017 10:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DhIe0UKbyfrRna1j4Vglex3CmapPdFh5lc27AHuL2Hw=; b=Ljo1XswsxNUYP9tW5c2Qp5CCZ77rsX7dwSehP67Llrdw1YQuJ89gbYCtQzkyPQ08Xk KsnHmtr8kOVpugz5ezFWQFxyyLEbYTn9UOCB3eb+nl2krJv0IthqEPz6B1Syk43vW/Zu bP+wJKuRjT9vbnLST/g6uQKx63RT7xx9wGPMKuYQWUFo+7qhlkonapBqXUaPAjjozSu3 WOPmbFI2g5hGY2ejVsc501rRXRCRoe7pavF+3GaqK7hANJbWDcg1w2VUWLrA69VTsGAK z+OnU1jzJNKZxP2WKIKhSrHt31xSkdXSByqIUNGDQnv4eK4OEJnQTmvg8wDIRUd3Dbrn LU3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DhIe0UKbyfrRna1j4Vglex3CmapPdFh5lc27AHuL2Hw=; b=QqUOVJNU3Hnar0IKgsQ5GnaEly/PxifgmOe/CKlnQkFnQstiUmnjlrqrpOVa75azcU 1Fi2Ji4BSBaU+QzCRCPcb1qz8foel8BMcO1LQ/c2tV30BPO7fc7K+2pNl6kRYxrLkV4I 8X4jrPHvQgTkgzUOZ0HTXEs6QVmcOFEXk0BnloJ7Xgi4H3zHjgSoLfk5dnBNK7U/gjVL GRXwZNM5hSiI3pNp4D4F0546ZtqB5ILFAlQf4RW62/qiDXV8VHlGj7aL3yAlguKoojBQ W1qbqjXQdh7nFqM44tlNgk7fvEgW/Lb4FH0XeOkdpJV37ZTEfn2M//7bxl3oJYbtAQDX iLuw== X-Gm-Message-State: AN3rC/4cI+T8hK5ESD8C2Ehxymtxs60baP3XuvsmOleJcFpZmGtwBvmw lrhcyguEAIzFZA== X-Received: by 10.84.139.67 with SMTP id 61mr11259463plq.106.1492708868070; Thu, 20 Apr 2017 10:21:08 -0700 (PDT) Received: from ?IPv6:2607:fb90:2700:f6fb:d482:6d93:8e0e:ed94? ([2607:fb90:2700:f6fb:d482:6d93:8e0e:ed94]) by smtp.gmail.com with ESMTPSA id x21sm11616533pfa.71.2017.04.20.10.21.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 10:21:07 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-165DF1D2-2690-41CA-A62E-1E919927CACF Mime-Version: 1.0 (1.0) From: Sami Boutros X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Thu, 20 Apr 2017 10:21:06 -0700 Cc: "luay.jalil@verizon.com" , BESS , "sfc@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <49EF93F5-4278-40CC-B5B8-276BF3038DF8@one.verizon.com> To: "UTTARO, JAMES" Archived-At: Subject: Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:21:12 -0000 --Apple-Mail-165DF1D2-2690-41CA-A62E-1E919927CACF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support . Thanks, Sami > On Apr 17, 2017, at 5:31 AM, UTTARO, JAMES wrote: >=20 > Support > =20 > Jim Uttaro > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of luay.jalil@verizon.co= m > Sent: Saturday, April 15, 2017 3:49 AM > To: BESS > Cc: sfc@ietf.org > Subject: Re: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-cont= rol-plane adoption following the IPR disclosure > =20 > Support > =20 > =20 > Luay > =20 > From: sfc on behalf of Martin Vigoureux > Reply-To: BESS > Date: Thursday, April 13, 2017 at 1:04 PM > To: BESS > Cc: "sfc@ietf.org" > Subject: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-= plane adoption following the IPR disclosure > =20 > WG > =20 > Given the IPR disclosed [1] against > draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for > comment specifically to let people express a revised opinion on how > draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS. > =20 > This call for comment is open until the 5th of May > =20 > Thanks > M&T > =20 > [1] https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet= f.org_ipr_2980_&d=3DDwIFAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3D7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=3DqN2VxBfuDQTHb9spUcOb6U-0Q= hNArhH4-TqX_aTjyaw&s=3D4VuflmQibSX6JGcRHsfv4SgtIIMuNUzVFEdMMccItP8&e=3D > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_sfc&d=3DDwIFAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3D= 7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY&m=3DqN2VxBfuDQTHb9spUcOb6U-0QhNA= rhH4-TqX_aTjyaw&s=3Du3C3H2GPfolNL2O1q7-SoUfZRNFXGGqXbUo471yGMkU&e=3D > =20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --Apple-Mail-165DF1D2-2690-41CA-A62E-1E919927CACF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Support .

Thanks,

Sami

On Apr 17, 2017, at 5:31 AM, UTTARO, JAMES <ju1738@att.com> wrote:

Support

 

Jim Uttaro

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of luay.jalil@verizon.com
Sent: Saturday, April 15, 2017 3:49 AM
To: BESS <bess@ietf.org>
Cc: sfc@ietf.org
Subject: Re: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure

 

Support

 

 

Luay

 

From: sfc <sfc-bounces@ietf.org> on behalf of Martin Vigoureux <martin.vigoureux@nokia.com>
Reply-To: BESS <bess@ietf.org>
Date: Thursday, April 13, 2017 at 1:04 PM
To: BESS <bess@ietf.org>
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure

 

WG

 

Given the IPR disclosed [1] against

draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for

comment specifically to let people express a revised opinion on how

draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS.

 

This call for comment is open until the 5th of May

 

Thanks

M&T

 

 

_______________________________________________

sfc mailing list

 

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--Apple-Mail-165DF1D2-2690-41CA-A62E-1E919927CACF-- From nobody Tue Apr 25 21:03:25 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1725126C7A; Tue, 25 Apr 2017 21:03:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149317940379.3830.15301755819163543474@ietfa.amsl.com> Date: Tue, 25 Apr 2017 21:03:23 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-l3vpn-yang-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 04:03:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Yang Data Model for BGP/MPLS L3 VPNs Authors : Dhanendra Jain Keyur Patel Patrice Brissette Zhenbin Li Shunwan Zhuang Xufeng Liu Jeffrey Haas Santosh Esale Bin Wen Filename : draft-ietf-bess-l3vpn-yang-01.txt Pages : 28 Date : 2017-04-25 Abstract: This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-l3vpn-yang-01 https://datatracker.ietf.org/doc/html/draft-ietf-bess-l3vpn-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l3vpn-yang-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 27 21:49:22 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2F5129C0B; Thu, 27 Apr 2017 21:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCDYkUTjNolz; Thu, 27 Apr 2017 21:49:19 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A83129B53; Thu, 27 Apr 2017 21:46:42 -0700 (PDT) Received: from [192.168.1.10] (unknown [49.150.112.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CA7A0180156A; Fri, 28 Apr 2017 06:46:37 +0200 (CEST) To: "mpls@ietf.org" , idr@ietf.org, BESS References: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> Cc: "mpls-chairs@ietf.org" , bess-chairs@ietf.org, idr-chairs@ietf.org, "" , draft-ietf-mpls-rfc3107bis@ietf.org From: Loa Andersson Message-ID: <61e452c6-80eb-ff94-878d-3152270fc032@pi.nu> Date: Fri, 28 Apr 2017 12:46:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [bess] Closed -- Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 04:49:21 -0000 Working Groups, authors, This working group last call is closed. We have a some comments, can the authors please address those and make sure that the reviewers are comfortable with how they been addressed. And continue to post a new version of the draft. /Loa On 2017-04-04 20:33, Loa Andersson wrote: > Working Groups, > > This is to initiate a two week working group last call in four working > groups on draft-ietf-mpls-rfc3107bis-01. > > According to agreement when we decided to host this document in the > MPLS working group, this last call is also copied to the IDR and BESS > working groups. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org), > if you are not subscribed to the mpls wg list, send to "your own" > working group mailing list, and we'll make sure they are posted to the > MPLS wg list. > > There are no IPR disclosures against this document. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any other IPRs that relates > to this document. > > This working group last call ends April 20, 2017. > > > /Loa > MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64