From mailnull@www1.ietf.org Fri Nov 1 14:00:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29032 for ; Fri, 1 Nov 2002 14:00:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1J2iA28647 for ipcdn-archive@odin.ietf.org; Fri, 1 Nov 2002 14:02:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1J2Pv28636; Fri, 1 Nov 2002 14:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1J11v28535 for ; Fri, 1 Nov 2002 14:01:01 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28893 for ; Fri, 1 Nov 2002 13:58:29 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Fri, 1 Nov 2002 14:00:31 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 11/01/2002 02:00:34 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE6F7DFF51CBD8f9e8a93df938690918c0ABBE6F7DFF51CBD" Content-Disposition: inline Subject: [ipcdn] draft-ietf-ipcdn-subscriber-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --0__=0ABBE6F7DFF51CBD8f9e8a93df938690918c0ABBE6F7DFF51CBD Content-type: text/plain; charset=us-ascii Colleagues, Attached is the -07 draft of the Docsis Subscriber Management MIB. It was revised to incorporate a number of changes suggested by Bert Wijnen as part of the "MIB Doctor" review. Please see Bert's mail of October 1 for reference. Please review this carefully, particularly if you are a vendor or operator of CMTSs. The draft has changed substantially since -06. In responding to Bert's requests for clarification, I have made choices which need to be ratified or corrected by this group. Note that this draft uses an unspecified root. This means that it cannot be used for DOCSIS compliance testing. If it progresses to RFC then it will be assigned a root at that time. Respectfully submitted, Wilson Sawyer (See attached file: draft-ietf-ipcdn-subscriber-mib-07.txt) --0__=0ABBE6F7DFF51CBD8f9e8a93df938690918c0ABBE6F7DFF51CBD Content-type: application/octet-stream; name="draft-ietf-ipcdn-subscriber-mib-07.txt" Content-Disposition: attachment; filename="draft-ietf-ipcdn-subscriber-mib-07.txt" Content-Transfer-Encoding: base64 CklOVEVSTkVULURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAg ICAgTm92ZW1iZXIgMjAwMgoKICAgICAgICAgICAgICAgICAgICAgIE1hbmFnZW1lbnQgSW5mb3Jt YXRpb24gQmFzZQogICAgICBmb3IgRGF0YSBPdmVyIENhYmxlIFNlcnZpY2UgSW50ZXJmYWNlIFNw ZWNpZmljYXRpb24gKERPQ1NJUykKICAgICAgICAgICAgICAgICAgICBDYWJsZSBNb2RlbSBUZXJt aW5hdGlvbiBTeXN0ZW1zCiAgICAgICAgICAgICAgICAgICAgICAgZm9yIFN1YnNjcmliZXIgTWFu YWdlbWVudAogICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXBjZG4tc3Vic2NyaWJlci1taWIt MDcudHh0CgogICAgICAgICAgICAgICAgICAgICAgRnJpIE5vdiAwMSAxMTowMDowMCBFU1QgMjAw MgoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2lsc29uIFNhd3llcgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBUlJJUwogICAgICAgICAgICAgICAgICAgICAgICAgICAg d3Nhd3llckBpZWVlLm9yZwoKCgoKICAgICAgICAgICAgICAgICAgICAgICAgICBTdGF0dXMgb2Yg dGhpcyBNZW1vCgogICAgICAgICAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQg YW5kIGlzIHN1YmplY3QgdG8KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMy MDI2LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nCiAgIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywKICAgYW5kIGl0 cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0OgogICBodHRwOi8vd3d3LmlldGYu b3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQKCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQ6CiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvc2hhZG93Lmh0bWwuCgpBYnN0cmFjdAoKICAgVGhpcyBtZW1vIGRlZmluZXMgYSBwb3J0 aW9uIG9mIHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQikKICAgZm9yIHVzZSB3 aXRoIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMgaW4gdGhlIEludGVybmV0IGNvbW11bml0 eS4KICAgSW4gcGFydGljdWxhciwgaXQgZGVmaW5lcyBhIHNldCBvZiBtYW5hZ2VkIG9iamVjdHMg Zm9yIFNOTVAtYmFzZWQKICAgbWFuYWdlbWVudCBvZiBEYXRhLW92ZXItQ2FibGUgU2VydmljZSBJ bnRlcmZhY2UgU3BlY2lmaWNhdGlvbgogICAoRE9DU0lTKS1jb21wbGlhbnQgQ2FibGUgTW9kZW0g VGVybWluYXRpb24gU3lzdGVtcy4gVGhlc2UgbWFuYWdlZAogICBvYmplY3RzIGZhY2lsaXRhdGUg cHJvdGVjdGlvbiBvZiB0aGUgY2FibGUgbmV0d29yayBmcm9tIG1pc3VzZSBieQogICBzdWJzY3Jp YmVycy4KCiAgIFRoaXMgbWVtbyBpcyBhIHByb2R1Y3Qgb2YgdGhlIElQQ0ROIHdvcmtpbmcgZ3Jv dXAgd2l0aGluIHRoZSBJbnRlcm5ldAogICBFbmdpbmVlcmluZyBUYXNrIEZvcmNlLiAgQ29tbWVu dHMgYXJlIHNvbGljaXRlZCBhbmQgc2hvdWxkIGJlCiAgIGFkZHJlc3NlZCB0byB0aGUgd29ya2lu ZyBncm91cCdzIG1haWxpbmcgbGlzdCBhdCBpcGNkbkBpZXRmLm9yZwogICBhbmQvb3IgdGhlIGF1 dGhvci4KCgoKCkV4cGlyZXMgIE1heSAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSU5URVJORVQtRFJBRlQgICAgICBET0NTSVMgU3Vi c2NyaWJlciBNYW5hZ2VtZW50IE1JQiAgICAgICBOb3ZlbWJlciAyMDAyCgpUYWJsZSBvZiBDb250 ZW50cwoKMS4gVGhlIFNOTVAgTmV0d29yayBNYW5hZ2VtZW50IEZyYW1ld29yay4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjIKMi4gT3ZlcnZpZXcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMKMi4xLiBTdHJ1Y3R1cmUgb2YgdGhl IE1JQi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQKMi4yLiBN YW5hZ2VtZW50IHJlcXVpcmVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjQKMi4yLjEuIEludGVyYWN0aW9uIHdpdGggRE9DU0lTIHByb3Zpc2lvbmluZyBmb3Ig Q1BFIGFkZHJlc3MgY29udHJvbC4uLjUKMi4yLjIuIEludGVyYWN0aW9uIHdpdGggRE9DU0lTIHBy b3Zpc2lvbmluZyBmb3IgZmlsdGVyaW5nLi4uLi4uLi4uLi4uLjUKMi4yLjMuIERpc3Rpbmd1aXNo aW5nIE1vZGVtIGZyb20gU3Vic2NyaWJlciBUcmFmZmljLi4uLi4uLi4uLi4uLi4uLi4uLjYKMi4y LjQuIFJvdyBFeGlzdGVuY2Ugb2YgZG9jc1N1Yk1ndFRjcFVkcEZpbHRlclRhYmxlLi4uLi4uLi4u Li4uLi4uLi4uLjYKMi4yLjUuIEZpbHRlcmluZyBhbmQgdGhlIFRpbnkgRnJhZ21lbnQgQXR0YWNr Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcKMy4gRGVmaW5pdGlvbnMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcKNC4gQWNrbm93bGVkZ21l bnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjQK NS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMjQKNi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjYKNy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjYKOC4gQXV0aG9yJ3Mg QWRkcmVzcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MjgKOS4gSW50ZWxsZWN0dWFsIFByb3BlcnR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjgKMTAuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjgKCjEuIFRoZSBTTk1QIE5ldHdvcmsgTWFu YWdlbWVudCBGcmFtZXdvcmsKCiAgIFRoZSBTTk1QIE1hbmFnZW1lbnQgRnJhbWV3b3JrIHByZXNl bnRseSBjb25zaXN0cyBvZiBmaXZlIG1ham9yCiAgIGNvbXBvbmVudHM6CgogICBvICAgQW4gb3Zl cmFsbCBhcmNoaXRlY3R1cmUsIGRlc2NyaWJlZCBpbiBSRkMgMjU3MSBbUkZDMjU3MV0uCgogICBv ICAgTWVjaGFuaXNtcyBmb3IgZGVzY3JpYmluZyBhbmQgbmFtaW5nIG9iamVjdHMgYW5kIGV2ZW50 cyBmb3IgdGhlCiAgICAgICBwdXJwb3NlIG9mIG1hbmFnZW1lbnQuIFRoZSBmaXJzdCB2ZXJzaW9u IG9mIHRoaXMgU3RydWN0dXJlIG9mCiAgICAgICBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIChTTUkp IGlzIGNhbGxlZCBTTUl2MSBhbmQgZGVzY3JpYmVkIGluIFNURAogICAgICAgMTYsIFJGQyAxMTU1 IFtSRkMxMTU1XSwgU1REIDE2LCBSRkMgMTIxMiBbUkZDMTIxMl0gYW5kIFJGQyAxMjE1CiAgICAg ICBbUkZDMTIxNV0uIFRoZSBzZWNvbmQgdmVyc2lvbiwgY2FsbGVkIFNNSXYyLCBpcyBkZXNjcmli ZWQgaW4KICAgICAgIFNURCA1OCwgUkZDIDI1NzggW1JGQzI1NzhdLCBTVEQgNTgsIFJGQyAyNTc5 IFtSRkMyNTc5XSBhbmQKICAgICAgIFNURCA1OCwgUkZDIDI1ODAgW1JGQzI1ODBdLgoKICAgbyAg IE1lc3NhZ2UgcHJvdG9jb2xzIGZvciB0cmFuc2ZlcnJpbmcgbWFuYWdlbWVudCBpbmZvcm1hdGlv bi4gVGhlCiAgICAgICBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBTTk1QIG1lc3NhZ2UgcHJvdG9jb2wg aXMgY2FsbGVkIFNOTVB2MSBhbmQKICAgICAgIGRlc2NyaWJlZCBpbiBSRkMgMTE1NyBbUkZDMTE1 N10uIEEgc2Vjb25kIHZlcnNpb24gb2YgdGhlIFNOTVAKICAgICAgIG1lc3NhZ2UgcHJvdG9jb2ws IHdoaWNoIGlzIG5vdCBhbiBJbnRlcm5ldCBzdGFuZGFyZHMgdHJhY2sKICAgICAgIHByb3RvY29s LCBpcyBjYWxsZWQgU05NUHYyYyBhbmQgZGVzY3JpYmVkIGluIFJGQyAxOTAxIFtSRkMxOTAxXQog ICAgICAgYW5kIFJGQyAxOTA2IFtSRkMxOTA2XS4gVGhlIHRoaXJkIHZlcnNpb24gb2YgdGhlIG1l c3NhZ2UgcHJvdG9jb2wKICAgICAgIGlzIGNhbGxlZCBTTk1QdjMgYW5kIGRlc2NyaWJlZCBpbiBS RkMgMTkwNiBbUkZDMTkwNl0sIFJGQyAyNTcyCiAgICAgICBbUkZDMjU3Ml0gYW5kIFJGQyAyNTc0 IFtSRkMyNTc0XS4KCiAgIG8gICBQcm90b2NvbCBvcGVyYXRpb25zIGZvciBhY2Nlc3NpbmcgbWFu YWdlbWVudCBpbmZvcm1hdGlvbi4gVGhlCiAgICAgICBmaXJzdCBzZXQgb2YgcHJvdG9jb2wgb3Bl cmF0aW9ucyBhbmQgYXNzb2NpYXRlZCBQRFUgZm9ybWF0cyBpcwogICAgICAgZGVzY3JpYmVkIGlu IFNURCAxNSwgUkZDIDExNTcgW1JGQzExNTddLiBBIHNlY29uZCBzZXQgb2YgcHJvdG9jb2wKICAg ICAgIG9wZXJhdGlvbnMgYW5kIGFzc29jaWF0ZWQgUERVIGZvcm1hdHMgaXMgZGVzY3JpYmVkIGlu IFJGQyAxOTA1CiAgICAgICBbUkZDMTkwNV0uCgogICBvICAgQSBzZXQgb2YgZnVuZGFtZW50YWwg YXBwbGljYXRpb25zIGRlc2NyaWJlZCBpbiBSRkMgMjU3MyBbUkZDMjU3M10KICAgICAgIGFuZCB0 aGUgdmlldy1iYXNlZCBhY2Nlc3MgY29udHJvbCBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFJGQyAy NTc1CiAgICAgICBbUkZDMjU3NV0uCgpFeHBpcmVzICBNYXkgMjAwMyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCklOVEVSTkVULURSQUZUICAg ICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAgICAgTm92ZW1iZXIgMjAwMgoK ICAgQSBtb3JlIGRldGFpbGVkIGludHJvZHVjdGlvbiB0byB0aGUgY3VycmVudCBTTk1QIE1hbmFn ZW1lbnQgRnJhbWV3b3JrCiAgIGNhbiBiZSBmb3VuZCBpbiBSRkMgMjU3MCBbUkZDMjU3MF0uCgog ICBNYW5hZ2VkIG9iamVjdHMgYXJlIGFjY2Vzc2VkIHZpYSBhIHZpcnR1YWwgaW5mb3JtYXRpb24g c3RvcmUsIHRlcm1lZAogICB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIG9yIE1JQi4g IE9iamVjdHMgaW4gdGhlIE1JQiBhcmUKICAgZGVmaW5lZCB1c2luZyB0aGUgbWVjaGFuaXNtcyBk ZWZpbmVkIGluIHRoZSBTTUkuCgogICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgTUlCIG1vZHVsZSB0 aGF0IGlzIGNvbXBsaWFudCB0byB0aGUgU01JdjIKICAgW1JGQzI1NzhdW1JGQzI1NzldW1JGQzI1 ODBdLiBBIE1JQiBjb25mb3JtaW5nIHRvIHRoZSBTTUl2MSBjYW4gYmUKICAgcHJvZHVjZWQgdGhy b3VnaCB0aGUgYXBwcm9wcmlhdGUgdHJhbnNsYXRpb25zLiBUaGUgcmVzdWx0aW5nCiAgIHRyYW5z bGF0ZWQgTUlCIE1VU1QgYmUgc2VtYW50aWNhbGx5IGVxdWl2YWxlbnQsIGV4Y2VwdCB3aGVyZSBv YmplY3RzCiAgIG9yIGV2ZW50cyBhcmUgb21pdHRlZCBiZWNhdXNlIG5vIHRyYW5zbGF0aW9uIGlz IHBvc3NpYmxlICh1c2Ugb2YKICAgQ291bnRlcjY0KS4gU29tZSBtYWNoaW5lIHJlYWRhYmxlIGlu Zm9ybWF0aW9uIGluIFNNSXYyIHdpbGwgYmUKICAgY29udmVydGVkIGludG8gdGV4dHVhbCBkZXNj cmlwdGlvbnMgaW4gU01JdjEgZHVyaW5nIHRoZSB0cmFuc2xhdGlvbgogICBwcm9jZXNzLiBIb3dl dmVyLCB0aGlzIGxvc3Mgb2YgbWFjaGluZSByZWFkYWJsZSBpbmZvcm1hdGlvbiBpcyBub3QKICAg Y29uc2lkZXJlZCB0byBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgTUlCLgoKMi4gT3ZlcnZp ZXcKCiAgIFRoaXMgTUlCIHByb3ZpZGVzIGEgc2V0IG9mIG9iamVjdHMgcmVxdWlyZWQgZm9yIHRo ZSBtYW5hZ2VtZW50IG9mCiAgIERPQ1NJUyBDYWJsZSBNb2RlbSBUZXJtaW5hdGlvbiBTeXN0ZW1z IChDTVRTKS4gVGhlIHNwZWNpZmljYXRpb24gaXMKICAgZGVyaXZlZCBpbiBwYXJ0IGZyb20gdGhl IG9wZXJhdGlvbmFsIG1vZGVsIGRlc2NyaWJlZCBpbiB0aGUgRE9DU0lTCiAgIFJhZGlvIEZyZXF1 ZW5jeSBJbnRlcmZhY2UgU3BlY2lmaWNhdGlvbiBbRE9DU1JGSV0uIFRoZXNlIG1hbmFnZWQKICAg b2JqZWN0cyBmYWNpbGl0YXRlIHByb3RlY3Rpb24gb2YgdGhlIGNhYmxlIG5ldHdvcmsgZnJvbSBt aXN1c2UgYnkKICAgc3Vic2NyaWJlcnMuCgogICBUaGUgZm9sbG93aW5nIGZpZ3VyZSBpbGx1c3Ry YXRlcyB0aGUgb3BlcmF0aW9uYWwgYW5kIHBoeXNpY2FsCiAgIGRlcGxveW1lbnQgcmVsYXRpb25z aGlwcyBiZXR3ZWVuIGVsZW1lbnRzIGluIGEgY2FibGUgbW9kZW0gbmV0d29yay4KICAgVGhpcyBN SUIgcmVzaWRlcyBhdCB0aGUgQ01UUywgd2hpY2ggaXMgdGhlIGZpcnN0IHBvaW50IGluIHRoZSBw dWJsaWMKICAgZGF0YSBuZXR3b3JrIGF0IHdoaWNoIHRoZSBjYWJsZSBvcGVyYXRvciBjb250cm9s cyBwaHlzaWNhbCBhY2Nlc3MuCiAgIFRoZSBDTVRTIChwb3NzaWJseSBhc3Npc3RlZCBieSBvdGhl ciBJUCBzZXJ2aWNlcyBkZXZpY2VzKSBhY3RzIGFzIGEKICAgbmV0d29yayBlZGdlLCBzZXBhcmF0 aW5nIHRoZSBwaHlzaWNhbCBvdXRzaWRlLXBsYW50IGNhYmxlIHRlbGV2aXNpb24KICAgbmV0d29y ayBmcm9tIHRoZSBvcGVyYXRvcidzIElQIG5ldHdvcmsuCgoKICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICBvcGVyYXRvcidzIElQIG5ldHdvcmsKICAgICAgICAgICAgICAgICArLS0t LS0tKyAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgICAgICAgICAgICAgICB8IENN VFMgfCAgICAgICAgICBvcGVyYXRvcidzIGNhYmxlIGhlYWQtZW5kCiAgICAgICAgICAgICAgICAg Ky0tLS0tLSsgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICAgICAgICAg ICAgfAogICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLSsgICAgIENBVFYgcGh5c2ljYWwgbmV0 d29yawogICAgICAgICAgIHwgICAgICAgIHwgICAgICAgIHwKICAgICAgICAgKy0tLS0rICAgKy0t LS0rICAgKy0tLS0rICAtLS0tLS0tLS0tLS0tLS0tLS0KICAgICAgICAgfCBDTSB8ICAgfCBDTSB8 ICAgfCBDTSB8ICBzdWJzY3JpYmVyIHByZW1pc2VzCiAgICAgICAgICstLS0tKyAgICstLS0tKyAg ICstLS0tKyAgLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAg fCAgICAgc3Vic2NyaWJlciBob3N0IG9yIG5ldHdvcmsKCgogICBUaGlzIE1JQiBjb250cm9scyBJ UCBwYWNrZXQgZm9yd2FyZGluZyB0byBhbmQgZnJvbSBlYWNoIGNhYmxlIG1vZGVtLAogICBhdCB0 aGUgQ01UUy4gRGlmZmVyZW50IG1vZGVtcyBtYXkgYmUgYWNjb3JkZWQgZGlmZmVyZW50IHRyZWF0 bWVudC4KCiAgIE11Y2ggb2YgdGhpcyBNSUIgZHVwbGljYXRlcyBjYXBhYmlsaXRpZXMgZm91bmQg aW4gdGhlIERPQ1NJUyBDYWJsZQogICBEZXZpY2UgTUlCIFtSRkMyNjY5XS4gV2hpbGUgaXQgaXMg ZXhwZWN0ZWQgdGhhdCB0aGUgQ2FibGUgRGV2aWNlIE1JQgoKRXhwaXJlcyAgTWF5IDIwMDMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJTlRF Uk5FVC1EUkFGVCAgICAgIERPQ1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgTUlCICAgICAgIE5v dmVtYmVyIDIwMDIKCiAgIHdpbGwgYmUgdXNlZCB0byBwcmV2ZW50IHVud2FudGVkIHRyYWZmaWMg ZnJvbSBlbnRlcmluZyB0aGUgY2FibGUKICAgbmV0d29yaywgaXQgaXMgYWxzbyBwb3NzaWJsZSB0 aGF0IGEgbWFsaWNpb3VzIHVzZXIgbWlnaHQgdGFtcGVyIHdpdGgKICAgY2FibGUgbW9kZW0gc29m dHdhcmUsIGRpc2FibGluZyBpdHMgZmlsdGVyaW5nIHBvbGljaWVzLiBUaGlzIE1JQgogICBwcm92 aWRlcyBhIG1vcmUgc2VjdXJlIG1lY2hhbmlzbSwgc2luY2UgcGh5c2ljYWwgYWNjZXNzIHRvIHRo ZSBDTVRTCiAgIGlzIGNvbnRyb2xsZWQgYnkgdGhlIG5ldHdvcmsgb3BlcmF0b3IuCgogICBJbiBw YXJ0aWN1bGFyLCB0aGlzIE1JQiBwcm92aWRlcyB0d28gY2FwYWJpbGl0aWVzOiBmaXJzdCwgdG8g bGltaXQKICAgdGhlIElQIGFkZHJlc3NlcyBiZWhpbmQgYSBtb2RlbSwgYW5kLCBzZWNvbmQsIHRv IHByb3ZpZGUgcHJvdG9jb2wKICAgZmlsdGVyaW5nIHRvIGFuZCBmcm9tIGEgbW9kZW0uIFRoZSBm aXJzdCBkdXBsaWNhdGVzIHRoZSBjYXBhYmlsaXRpZXMKICAgb2YgdGhlIGRvY3NEZXZDcGUgZ3Jv dXAgW1JGQzI2NjldLiBUaGlzIHByb3ZpZGVzIGZvciBlaXRoZXIgbGVhcm5lZAogICBvciBwcm92 aXNpb25lZCBzdWJzY3JpYmVyIHByZW1pc2VzIGhvc3QgSVAgYWRkcmVzc2VzIGJlaGluZCBhIGNh YmxlCiAgIG1vZGVtLgoKICAgVGhlIGZpbHRlcmluZyBjYXBhYmlsaXR5IGlzIHNpbWlsYXIgdG8g dGhhdCBwcm92aWRlZCBpbiBkb2NzRGV2RmlsdGVyCiAgIFtSRkMyNjY5XS4gIFJhdGhlciB0aGFu IG1haW50YWluaW5nIGEgc2VwYXJhdGUgbGlzdCBvZiBmaWx0ZXJzIGZvcgogICBlYWNoIG1vZGVt IGF0IHRoZSBDTVRTLCBob3dldmVyLCBpdCBpcyBhc3N1bWVkIHRoYXQgbGFyZ2UgbnVtYmVycyBv ZgogICBtb2RlbXMgd2lsbCBzaGFyZSBmaWx0ZXJpbmcgY2hhcmFjdGVyaXN0aWNzLiBUaGVyZWZv cmUsIG1vZGVtcyBhcmUKICAgZ3JvdXBlZCBzbyBhcyB0byBzaGFyZSBjb21tb24gZmlsdGVyIGxp c3RzLgoKMi4xLiBTdHJ1Y3R1cmUgb2YgdGhlIE1JQgoKICAgVGhpcyBNSUIgaXMgc3RydWN0dXJl ZCBpbiBmaXZlIHRhYmxlczoKCiAgIG8gICAgVGhlIGRvY3NTdWJNZ3RDcGVDb250cm9sVGFibGUg Y29udHJvbHMgdGhlIGFjY2VwdGFuY2Ugb2YKICAgICAgICBzdWJzY3JpYmVyIGhvc3QgYWRkcmVz c2VzIGJlaGluZCBhIGNhYmxlIG1vZGVtLgoKICAgbyAgICBUaGUgZG9jc1N1Yk1ndENwZUlwVGFi bGUgbW9uaXRvcnMgdGhlIHN1YnNjcmliZXIgaG9zdCBhZGRyZXNzZXMKICAgICAgICB3aGljaCB0 aGUgQ01UUyBiZWxpZXZlcyB0byBleGlzdCBiZWhpbmQgdGhlIGNhYmxlIG1vZGVtLgoKICAgbyAg ICBUaGUgZG9jc1N1Yk1ndFBrdEZpbHRlclRhYmxlIHNwZWNpZmllcyBmaWx0ZXJpbmcgY3JpdGVy aWEgd2hpY2gKICAgICAgICBjYW4gYmUgYXBwbGllZCB0byBwYWNrZXRzIGRlc3RpbmVkIHRvIG9y IG9yaWdpbmF0aW5nIGZyb20gYQogICAgICAgIGNhYmxlIG1vZGVtLgoKICAgbyAgICBUaGUgZG9j c1N1Yk1ndFRjcFVkcEZpbHRlclRhYmxlIGF1Z21lbnRzCiAgICAgICAgZG9jc1N1Yk1ndFBrdEZp bHRlclRhYmxlIHdpdGggb3B0aW9uYWwgVENQIG9yIFVEUCBwb3J0IGZpbHRlcmluZwogICAgICAg IGNyaXRlcmlhLgoKICAgbyAgICBUaGUgZG9jc1N1Yk1ndENtRmlsdGVyVGFibGUgYmluZHMgYSBj YWJsZSBtb2RlbSB0byBhbiBvcmRlcmVkCiAgICAgICAgbGlzdCBvZiBmaWx0ZXJzIGZyb20gZG9j c1N1Yk1ndFBrdEZpbHRlclRhYmxlLgoKICAgVGhlIGRvY3NTdWJNZ3RDcGVDb250cm9sVGFibGUs IGRvY3NTdWJNZ3RDcGVJcFRhYmxlLCBhbmQKICAgZG9jc1N1Yk1ndENtRmlsdGVyVGFibGUgYXVn bWVudCB0aGUgZG9jc0lmQ210c0NtU3RhdHVzVGFibGUgZnJvbQogICBbUkZDMjY3MF0uICBBcyBz dWNoLCBlYWNoIGVudHJ5IGluIHRoZXNlIHRhYmxlcyBpcyBib3VuZCB0byBhCiAgIHJlZ2lzdGVy ZWQgY2FibGUgbW9kZW0sIGFzIHBlcmNlaXZlZCBieSB0aGUgQ01UUy4KCiAgIFRoZSBkb2NzU3Vi TWd0UGt0RmlsdGVyVGFibGUgdXNlcyB0d28gaW5kaWNlcy4gVGhlIGZpcnN0IGlkZW50aWZpZXMK ICAgdGhlIGdyb3VwIHRvIHdoaWNoIGEgY2FibGUgbW9kZW0gbWF5IGJlIGJvdW5kLiBUaGUgc2Vj b25kIGlzIHRoZQogICBvcmRlcmluZyBvZiBmaWx0ZXIgY3JpdGVyaWEgd2l0aGluIGVhY2ggZ3Jv dXAuIEFueSBudW1iZXIgb2YgbW9kZW1zCiAgIG1heSBiZSBib3VuZCB0byB0aGUgc2FtZSBncm91 cC4KCjIuMi4gTWFuYWdlbWVudCByZXF1aXJlbWVudHMKCiAgIFRoZSBET0NTSVMgY2FibGUgbW9k ZW0gcHJvdmlzaW9uaW5nIG1vZGVsIFtET0NTUkZJXSByZXF1aXJlcyB0aGF0CgpFeHBpcmVzICBN YXkgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA0XQoMCklOVEVSTkVULURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBN SUIgICAgICAgTm92ZW1iZXIgMjAwMgoKICAgY2FibGUgbW9kZW1zIHVzZSBURlRQIHRvIGFjcXVp cmUgYSBsaXN0IG9mIHBhcmFtZXRlcnMuIFRoZSBtb2RlbSB0aGVuCiAgIHBhc3NlcyBtYW55IG9m IHRoZXNlIHBhcmFtZXRlcnMgdG8gdGhlIENNVFMgaW4gdGhlIERPQ1NJUwogICBSZWdpc3RyYXRp b24gbWVzc2FnZS4gVGhlIHBhcmFtZXRlciB2YWx1ZXMgYXJlIGRpZ2l0YWxseSBzaWduZWQgYnkK ICAgdGhlIGNyZWF0b3Igb2YgdGhlIFRGVFAgY29udGVudHMsIGFuZCB0aGUgc2lnbmF0dXJlIGlz IHZlcmlmaWVkIGJ5CiAgIHRoZSBDTVRTLiBJbiBnZW5lcmFsLCB0aGVuLCB0aGUgQ01UUyBuZWVk IG5vdCBpdHNlbGYgYmUgY29uZmlndXJlZAogICB3aXRoIHRoZSBhdHRyaWJ1dGVzIG9mIGl0cyBj YWJsZSBtb2RlbXMuIEl0IHdpbGwgYWNxdWlyZSB0aGVzZSB2YWx1ZXMKICAgdGhyb3VnaCB0aGUg UmVnaXN0cmF0aW9uIHByb2Nlc3MgdGhhdCBpcyBzZWN1cmVkIGJ5IHRoZSBkaWdpdGFsCiAgIHNp Z25hdHVyZS4KCiAgIENhYmxlIG1vZGVtIHN1YnNjcmliZXIgbWFuYWdlbWVudCwgYXMgZGVzY3Jp YmVkIGhlcmUsIG1vZGlmaWVzIHRoaXMKICAgcHJvY2VzcyBzbGlnaHRseSBmb3IgcmVhc29ucyBv ZiBkYXRhIHJlZHVjdGlvbiBhbmQgZWFzZSBvZgogICBhZG1pbmlzdHJhdGl2ZSBjb250cm9sLiAg SW4gdGhlIGNhc2Ugb2YgZmlsdGVyaW5nIG1hbmFnZW1lbnQsIGZvcgogICBleGFtcGxlLCB0aGUg dGFibGVzIGFyZSBtYWludGFpbmVkIHRocm91Z2ggU05NUCBhdCB0aGUgQ01UUywgYW5kIHRoZQog ICBtb2RlbSByZWdpc3RyYXRpb24gbWVyZWx5IHNpZ25hbHMgdGhlIGluZGV4IHZhbHVlcyBmb3Ig dGhlIHJvd3MgdGhhdAogICBhcHBseSB0byB0aGF0IG1vZGVtLgoKMi4yLjEuIEludGVyYWN0aW9u IHdpdGggRE9DU0lTIHByb3Zpc2lvbmluZyBmb3IgQ1BFIGFkZHJlc3MgY29udHJvbAoKICAgUm93 cyBpbiBkb2NzU3ViTWd0Q3BlQ29udHJvbFRhYmxlIGFyZSBjcmVhdGVkIGJ5IHRoZSBDTVRTIGZv ciBlYWNoCiAgIG1vZGVtIGFzIGEgcmVzdWx0IG9mIHRoZSBET0NTSVMgcmVnaXN0cmF0aW9uIHBy b2Nlc3MuIFRoZSBET0NTSVMKICAgcmVnaXN0cmF0aW9uIGF0dHJpYnV0ZXMgbWF5IGluY2x1ZGUg aXRlbXMgc2VtYW50aWNhbGx5IGVxdWl2YWxlbnQgdG8KICAgdGhvc2UgaW4gdGhlIERvY3NEZXZD cGUgYnJhbmNoIG9mIHRoZSBET0NTSVMgQ2FibGUgRGV2aWNlIE1JQgogICBbUkZDMjY2OV06Cgog ICBvICAgIGRvY3NEZXZDcGVFbnJvbGwKICAgbyAgICBkb2NzRGV2Q3BlSXBNYXgKICAgbyAgICBk b2NzRGV2Q3BlSXAKCiAgIFN1Y2Nlc3NmdWwgRE9DU0lTIHJlZ2lzdHJhdGlvbiBzaGFsbCBoYXZl IHRoZSBlZmZlY3Qgb2Ygc2V0dGluZyB0aGUKICAgY29ycmVzcG9uZGluZyBmaWVsZHMgaW4gdGhl IGRvY3NTdWJNZ3RDcGVDb250cm9sVGFibGUgYW5kIHRoZQogICBkb2NzU3ViTWd0Q3BlSXBUYWJs ZS4gSWYgbm90IHByZXNlbnQsIHRoZSBkZWZhdWx0IGF0IHJlZ2lzdHJhdGlvbgogICBzaGFsbCBi ZSB0byBzZXQgZG9jc1N1Yk1ndENwZUNvbnRyb2xBY3RpdmUgdG8gZmFsc2UuCgogICBSb3dzIGlu IGRvY3NTdWJNZ3RDcGVJcFRhYmxlIGFyZSBjcmVhdGVkIHRocm91Z2ggYW55IG9mIHRocmVlIHdh eXM6CiAgIERPQ1NJUyByZWdpc3RyYXRpb24gKGFzIGRlc2NyaWJlZCBhYm92ZSksIGxlYXJuaW5n IGJ5IHRoZSBDTVRTLCBvcgogICB0aHJvdWdoIHNvbWUgdW5zcGVjaWZpZWQgYWRtaW5pc3RyYXRp dmUgbWVjaGFuaXNtIG9uIHRoZSBDTVRTLiBUaGUKICAgZG9jc0RldkNwZUlwTWF4IHRhYmxlIGJv dW5kIGFwcGxpZXMgb25seSB0byB0aGUgZmlyc3QgdHdvLgoKICAgVGhlIENNVFMgbWF5IGxlYXJu IGFkZHJlc3NlcyBieSBzaW1wbHkgc25vb3Bpbmcgc291cmNlIElQIGFkZHJlc3NlcwogICBmcm9t IGVhY2ggY2FibGUgbW9kZW0uIE90aGVyIGxlYXJuaW5nIG1lY2hhbmlzbXMgKGZvciBleGFtcGxl LCBBUlAKICAgc25vb3BpbmcpIG1heSBiZSB1c2VkLiBUaGUgbGVhcm5pbmcgbWVjaGFuaXNtIGlz IG5vdCBkZWZpbmVkIGJ5IHRoaXMKICAgZG9jdW1lbnQuCgoyLjIuMi4gSW50ZXJhY3Rpb24gd2l0 aCBET0NTSVMgcHJvdmlzaW9uaW5nIGZvciBmaWx0ZXJpbmcKCiAgIFJvd3MgaW4gZG9jc1N1Yk1n dENtRmlsdGVyVGFibGUgYXJlIGNyZWF0ZWQgYnkgdGhlIENNVFMgZm9yIGVhY2gKICAgbW9kZW0g YXMgYSByZXN1bHQgb2YgdGhlIERPQ1NJUyByZWdpc3RyYXRpb24gcHJvY2Vzcy4gVGhlIERPQ1NJ UwogICByZWdpc3RyYXRpb24gYXR0cmlidXRlcyBtYXkgaW5jbHVkZSBmb3VyIGluZGljZXM6Cgog ICBvICAgb25lIGlkZW50aWZ5aW5nIHRoZSB1cHN0cmVhbSBmaWx0ZXIgZ3JvdXAgZm9yIHBhY2tl dHMKICAgICAgIG9yaWdpbmF0aW5nIGZyb20gdGhlIGNhYmxlIG1vZGVtIChpLmUuLCB0aG9zZSBw YWNrZXRzIHdob3NlCiAgICAgICBzb3VyY2UgTUFDIGFkZHJlc3MgbWF0Y2hlcyB0aGF0IG9mIHRo ZSBjYWJsZSBtb2RlbSkuCiAgIG8gICBvbmUgaWRlbnRpZnlpbmcgdGhlIHVwc3RyZWFtIGZpbHRl ciBncm91cCBmb3IgcGFja2V0cwoKRXhwaXJlcyAgTWF5IDIwMDMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJTlRFUk5FVC1EUkFGVCAgICAg IERPQ1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgTUlCICAgICAgIE5vdmVtYmVyIDIwMDIKCiAg ICAgICBvcmlnaW5hdGluZyBmcm9tIHN1YnNjcmliZXJzIGF0dGFjaGVkIHRvIHRoZSBjYWJsZSBt b2RlbSAoaS5lLiwKICAgICAgIHRob3NlIHBhY2tldHMgd2hvc2Ugc291cmNlIE1BQyBhZGRyZXNz IGRvZXMgbm90IG1hdGNoIHRoYXQgb2YKICAgICAgIHRoZSBjYWJsZSBtb2RlbSkuCiAgIG8gICBv bmUgaWRlbnRpZnlpbmcgdGhlIGRvd25zdHJlYW0gZmlsdGVyIGdyb3VwIGZvciBwYWNrZXRzCiAg ICAgICBkZXN0aW5lZCB0byB0aGUgY2FibGUgbW9kZW0gKGkuZS4sIHRob3NlIHBhY2tldHMgd2hv c2UKICAgICAgIGRlc3RpbmF0aW9uIE1BQyBhZGRyZXNzIG1hdGNoZXMgdGhhdCBvZiB0aGUgY2Fi bGUgbW9kZW0pLgogICBvICAgb25lIGlkZW50aWZ5aW5nIHRoZSBkb3duc3RyZWFtIGZpbHRlciBn cm91cCBmb3IgcGFja2V0cwogICAgICAgZGVzdGluZWQgdG8gc3Vic2NyaWJlcnMgYXR0YWNoZWQg dG8gdGhlIGNhYmxlIG1vZGVtIChpLmUuLAogICAgICAgdGhvc2UgcGFja2V0cyB3aG9zZSBkZXN0 aW5hdGlvbiBNQUMgYWRkcmVzcyBkb2VzIG5vdCBtYXRjaAogICAgICAgdGhhdCBvZiB0aGUgY2Fi bGUgbW9kZW0pLgoKICAgU3VjY2Vzc2Z1bCByZWdpc3RyYXRpb24gc2hhbGwgaGF2ZSB0aGUgZWZm ZWN0IG9mIHNldHRpbmcKICAgZG9jc1N1Yk1ndENtRmlsdGVyRG93bnN0cmVhbSwgZG9jc1N1Yk1n dENtRmlsdGVyVXBzdHJlYW0sCiAgIGRvY3NTdWJNZ3RTdWJGaWx0ZXJEb3duc3RyZWFtLCBhbmQg ZG9jc1N1Yk1ndFN1YkZpbHRlclVwc3RyZWFtLCBmb3IKICAgdGhhdCBtb2RlbSAoanVzdCBhcyBp ZiBzZXQgdGhyb3VnaCB0aGUgU05NUCBwcm90b2NvbCkuIElmIHRoZSBET0NTSVMKICAgYXR0cmli dXRlcyBhcmUgbm90IHByZXNlbnQsIHRoZSBlZmZlY3Qgc2hhbGwgYmUgdG8gc2V0IHRoZSBtb2Rl bSdzCiAgIGZpbHRlciBncm91cHMgdG8gdGhlIHZhbHVlcyBvZiBkb2NzU3ViTWd0Q21GaWx0ZXJV cERlZmF1bHQsCiAgIGRvY3NTdWJNZ3RDbUZpbHRlckRvd25EZWZhdWx0LCBkb2NzU3ViTWd0U3Vi RmlsdGVyVXBEZWZhdWx0LCBhbmQKICAgZG9jc1N1Yk1ndFN1YkZpbHRlckRvd25EZWZhdWx0LgoK Mi4yLjMuIERpc3Rpbmd1aXNoaW5nIE1vZGVtIGZyb20gU3Vic2NyaWJlciBUcmFmZmljCgogICBB bGwgdHJhZmZpYyBvcmlnaW5hdGluZyBmcm9tIG9yIGRlc3RpbmVkIHRvIGEgc3Vic2NyaWJlciBz aXRlIGlzCiAgIHBvdGVudGlhbGx5IHN1c3BlY3QsIGFuZCBzdWJqZWN0IHRvIHN1cHByZXNzaW9u IGJ5IHRoZSBuZXR3b3JrCiAgIG9wZXJhdG9yLiAgVGhpcyBpcyB0cnVlIGV2ZW4gaWYgdGhlIHRy YWZmaWMgaXMgb3N0ZW5zaWJseSBzb3VyY2VkIG9yCiAgIHN1bmsgYnkgdGhlIGNhYmxlIG1vZGVt IGl0c2VsZiwgcmF0aGVyIHRoYW4gdGhlIHN1YnNjcmliZXIgaG9zdHMKICAgYmVoaW5kIHRoZSBt b2RlbS4gVG8gcHJvdmlkZSBtb3JlIG51YW5jZWQgYWRtaW5pc3RyYXRpdmUgY29udHJvbCwKICAg dGhpcyBkb2N1bWVudCBhbGxvd3Mgc2VwYXJhdGUgZmlsdGVyIHBvbGljaWVzIGZvciBtb2RlbXMg YW5kIGhvc3RzLgogICBGb3IgZXhhbXBsZSwgbW9kZW0gcG9saWNpZXMgbWF5IGxpbWl0IG1vZGVt cyB0byBzZXJ2ZXItc3VibmV0LW9ubHkKICAgYWNjZXNzLCB3aGlsZSBhbGxvd2luZyBhIGRpZmZl cmVudCBzY29wZSB0byBzdWJzY3JpYmVycy4KCiAgIFRoZSBDTVRTIGNob29zZXMgdGhlIGZpbHRl ciBzZXQgdG8gYXBwbHkgYmFzZWQgc29sZWx5IG9uIHRoZSBNQUMKICAgYWRkcmVzcyAoc291cmNl IE1BQyB1cHN0cmVhbSwgZGVzdGluYXRpb24gTUFDIGRvd25zdHJlYW0pLiBJZiB0aGUgTUFDCiAg IGFkZHJlc3MgbWF0Y2hlcyB0aGF0IG9mIHRoZSBtb2RlbSwgdGhlbiB0aGUKICAgZG9jc1N1Yk1n dENtRmlsdGVyVXAvRG93bnN0cmVhbSBwYWlyIGlzIHVzZWQ7IG90aGVyd2lzZSB0aGUKICAgZG9j c1N1Yk1ndFN1YkZpbHRlclVwL0Rvd25zdHJlYW0gcGFpciBpcyBhcHBsaWVkLgoKICAgSWYgdGhl IENNIGFjdHMgYXMgYSByb3V0ZXIgcmF0aGVyIHRoYW4gYXMgYSBET0NTSVMgYnJpZGdpbmcKICAg Zm9yd2FyZGVyLCB0aGVuIHRoZSBuZXR3b3JrIG9wZXJhdG9yIHdpbGwgb25seSB1c2UgdGhlCiAg IGRvY3NTdWJNZ3RDbUZpbHRlclVwL0Rvd25zdHJlYW0gcGFpci4KCjIuMi40LiBSb3cgRXhpc3Rl bmNlIG9mIGRvY3NTdWJNZ3RUY3BVZHBGaWx0ZXJUYWJsZQoKICAgVGhlIGRvY3NTdWJNZ3RUY3BV ZHBGaWx0ZXJUYWJsZSBleGlzdHMgYXBhcnQgZnJvbSB0aGUKICAgZG9jc1N1Yk1ndFBrdEZpbHRl clRhYmxlIGJlY2F1c2UgaXRzIGZpbHRlcmluZyBjcml0ZXJpYSBpcyBleHBlY3RlZAogICB0byBi ZSBhcHBsaWVkIHRvIGEgbWlub3JpdHkgb2YgbW9kZW1zIHJlbGF0aXZlIHRvCiAgIGRvY3NTdWJN Z3RQa3RGaWx0ZXJUYWJsZS4gSXQgaXMgc2VwYXJhdGUgaW4gb3JkZXIgdG8gZW1waGFzaXplIHRo aXMKICAgZXhwZWN0YXRpb24gdG8gYm90aCBDTVRTIHZlbmRvcnMgYW5kIG5ldHdvcmsgb3BlcmF0 b3JzLiBUaGUgcnVsZXMgZm9yCiAgIHJvdyBjcmVhdGlvbiBhcmU6CgogICBvICAgIFJvdyBjcmVh dGlvbiBpbiBkb2NzU3ViTWd0VGNwVWRwRmlsdGVyVGFibGUgaXMgZGlzYWxsb3dlZCB1bmxlc3MK ICAgICAgICB0aGUgY29ycmVzcG9uZGluZyByb3cgaW4gZG9jc1N1Yk1ndFBrdEZpbHRlclRhYmxl IGFscmVhZHkKICAgICAgICBleGlzdHMgKG9yIHRoYXQgcm93IGlzIGJlaW5nIGNyZWF0ZWQgc2lt dWx0YW5lb3VzbHkgaW4gdGhlIHNhbWUKCkV4cGlyZXMgIE1heSAyMDAzICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSU5URVJORVQtRFJBRlQg ICAgICBET0NTSVMgU3Vic2NyaWJlciBNYW5hZ2VtZW50IE1JQiAgICAgICBOb3ZlbWJlciAyMDAy CgogICAgICAgIFNOTVAgU0VUIG1lc3NhZ2UpLgoKICAgbyAgICBEZWxldGlvbiBvZiB0aGUgcm93 IGluIGRvY3NTdWJNZ3RQa3RGaWx0ZXJUYWJsZSBkZWxldGVzIHRoZQogICAgICAgIGNvcnJlc3Bv bmRpbmcgcm93IGluIGRvY3NTdWJNZ3RUY3BVZHBGaWx0ZXJUYWJsZS4KCiAgIG8gICAgUm93IGNy ZWF0aW9uIGZvciBkb2NzU3ViTWd0UGt0RmlsdGVyVGFibGUgZG9lcyBub3QgY3JlYXRlIHRoZQog ICAgICAgIGNvcnJlc3BvbmRpbmcgcm93IGluIGRvY3NTdWJNZ3RUY3BVZHBGaWx0ZXJUYWJsZS4K CiAgIG8gICAgUm93IGRlbGV0aW9uIG9mIGRvY3NTdWJNZ3RUY3BVZHBGaWx0ZXJUYWJsZSBkb2Vz IG5vdCBkZWxldGUgdGhlCiAgICAgICAgY29ycmVzcG9uZGluZyByb3cgaW4gZG9jc1N1Yk1ndFBr dEZpbHRlclRhYmxlLgoKMi4yLjUuIEZpbHRlcmluZyBhbmQgdGhlIFRpbnkgRnJhZ21lbnQgQXR0 YWNrCgogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBpbXBsZW1lbnRlcnMgcHJldmVudCB0 aGUgInRpbnkgZnJhZ21lbnQiCiAgIGFuZCAib3ZlcmxhcHBpbmcgZnJhZ21lbnQiIGF0dGFja3Mg Zm9yIHRoZSBUQ1AgZmlsdGVyaW5nIHRhYmxlcyBpbgogICB0aGlzIE1JQiwgYXMgZGlzY3Vzc2Vk IGluIFJGQyAxODU4IFtSRkMxODU4XSBhbmQgUkZDIDMxMjggW1JGQzIxMzhdLgoKICAgUHJldmVu dGlvbiBvZiB0aGVzZSBhdHRhY2tzIGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRoIHRoZSBmb2xsb3dp bmcKICAgcnVsZXMsIHdoZW4gZmlsdGVyaW5nIGlzIGVuYWJsZWQ6CgogICBvICAgIGFkbWl0IGFs bCBwYWNrZXRzIHdpdGggZnJhZ21lbnQgb2Zmc2V0ID49IDIKCiAgIG8gICAgZGlzY2FyZCBhbGwg cGFja2V0cyB3aXRoIGZyYWdtZW50IG9mZnNldCA9IDEsIG9yIHdpdGggZnJhZ21lbnQKICAgICAg ICBvZmZzZXQgPSAwIEFORCBmcmFnbWVudCBwYXlsb2FkIGxlbmd0aCA8IDE2LgoKICAgbyAgICBh cHBseSBmaWx0ZXJpbmcgcnVsZXMgdG8gYWxsIHBhY2tldHMgd2l0aCBmcmFnbWVudCBvZmZzZXQg PSAwLgoKMy4gRGVmaW5pdGlvbnMKCiAgIERPQ1MtU1VCTUdULU1JQiAgREVGSU5JVElPTlMgOjo9 IEJFR0lOCgogICBJTVBPUlRTCiAgICAgICAgICAgTU9EVUxFLUlERU5USVRZLAogICAgICAgICAg IE9CSkVDVC1UWVBFLAogICAgICAgICAgIENvdW50ZXIzMiwKICAgICAgICAgICBJbnRlZ2VyMzIs CiAgICAgICAgICAgbWliLTIKICAgICAgICAgICAtLSAsIEJJVFMKICAgICAgICAgICAgICAgICAg IEZST00gU05NUHYyLVNNSQogICAgICAgICAgIFJvd1N0YXR1cywKICAgICAgICAgICBUcnV0aFZh bHVlLAogICAgICAgICAgIFN0b3JhZ2VUeXBlCiAgICAgICAgICAgICAgICAgICBGUk9NIFNOTVB2 Mi1UQwogICAgICAgICAgIE9CSkVDVC1HUk9VUCwKICAgICAgICAgICBNT0RVTEUtQ09NUExJQU5D RQogICAgICAgICAgICAgICAgICAgRlJPTSBTTk1QdjItQ09ORgogICAgICAgICAgIEluZXRBZGRy ZXNzVHlwZSwKICAgICAgICAgICBJbmV0QWRkcmVzcywKICAgICAgICAgICBJbmV0QWRkcmVzc1By ZWZpeExlbmd0aCwKICAgICAgICAgICBJbmV0UG9ydE51bWJlcgogICAgICAgICAgICAgICAgICAg RlJPTSBJTkVULUFERFJFU1MtTUlCCiAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzSW5kZXgs CiAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRW50cnkKCkV4cGlyZXMgIE1heSAyMDAzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSU5U RVJORVQtRFJBRlQgICAgICBET0NTSVMgU3Vic2NyaWJlciBNYW5hZ2VtZW50IE1JQiAgICAgICBO b3ZlbWJlciAyMDAyCgogICAgICAgICAgICAgICAgICAgRlJPTSBET0NTLUlGLU1JQjsgIC0tIFJG QzI2NzAKCiAgIGRvY3NTdWJNZ3QgTU9EVUxFLUlERU5USVRZCiAgICAgICAgICAgTEFTVC1VUERB VEVEICAgICIyMDAyMTEwMTAwMDBaIiAtLSBOb3ZlbWJlciAxLCAyMDAyCiAgICAgICAgICAgT1JH QU5JWkFUSU9OICAgICJJRVRGIElQQ0ROIFdvcmtpbmcgR3JvdXAiCiAgICAgICAgICAgQ09OVEFD VC1JTkZPCiAgICAgICAgICAgICAgICIgICAgICAgIFdpbHNvbiBTYXd5ZXIKICAgICAgICAgICAg ICAgIFBvc3RhbDogQVJSSVMKICAgICAgICAgICAgICAgICAgICAgICAgNiBSaXZlcnNpZGUgRHJp dmUKICAgICAgICAgICAgICAgICAgICAgICAgQW5kb3ZlciwgTUEgMDE4MTAKICAgICAgICAgICAg ICAgICAgICAgICAgVS5TLkEuCiAgICAgICAgICAgICAgICBQaG9uZTogICsxIDk3OCA5NDYgNDcx MQogICAgICAgICAgICAgICAgRS1tYWlsOiB3c2F3eWVyQGllZWUub3JnCgogICAgICAgICAgICAg ICAgSUVURiBJUENETiBXb3JraW5nIEdyb3VwCiAgICAgICAgICAgICAgICBHZW5lcmFsIERpc2N1 c3Npb246IGlwY2RuQGlldGYub3JnCiAgICAgICAgICAgICAgICBTdWJzY3JpYmU6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGNkbgogICAgICAgICAgICAgICAgQXJjaGl2 ZTogZnRwOi8vZnRwLmlldGYub3JnL2lldGYtbWFpbC1hcmNoaXZlL2lwY2RuCiAgICAgICAgICAg ICAgICBDby1jaGFpcnM6IFJpY2hhcmQgV291bmR5LCByd291bmR5QGJyb2FkYmFuZC5hdHQuY29t CiAgICAgICAgICAgICAgICAgICAgICAgICAgIEplYW4tRnJhbmNvaXMgTXVsZSwgamYubXVsZUBj YWJsZWxhYnMuY29tIgogICAgICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgICAgICJUaGlz IGlzIHRoZSBDTVRTIGNlbnRyaWMgc3Vic2NyaWJlciBtYW5hZ2VtZW50IE1JQiBmb3IKICAgICAg ICAgICBET0NTSVMgY29tcGxpYW50IENNVFMuIgogICAgICAgIFJFVklTSU9OICIyMDAyMTEwMTAw MDBaIiAtLSBOb3ZlbWJlciAxLCAyMDAyCiAgICAgICAgICAgREVTQ1JJUFRJT04KICAgICAgICAg ICAgICAiSW5pdGlhbCB2ZXJzaW9uLCBwdWJsaXNoZWQgYXMgUkZDIHh4eHguIgogICAgICAgICAg ICAgIC0tIFJGQyBlZGl0b3IgdG8gYXNzaWduIHh4eHgKICAgICAgICAgICA6Oj0geyBtaWItMiB4 eCB9ICAgLS0geHggdG8gYmUgYXNzaWduZWQgYnkgSUFOQQoKCiAgIGRvY3NTdWJNZ3RPYmplY3Rz IE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IGRvY3NTdWJNZ3QgMSB9CgogICBkb2NzU3ViTWd0Q3Bl Q29udHJvbFRhYmxlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggIFNFUVVFTkNFIE9GIERvY3NT dWJNZ3RDcGVDb250cm9sRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAg ICAgIFNUQVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhpcyB0 YWJsZSBBVUdNRU5UcyB0aGUgZG9jc0lmQ210c0NtU3RhdHVzVGFibGUgYW5kIGFkZHMKICAgICAg IGZvdXIgV1JJVEVhYmxlIG9iamVjdHMgd2hpY2ggcmVmbGVjdCB0aGUgc3RhdGUgb2Ygc3Vic2Ny aWJlcgogICAgICAgbWFuYWdlbWVudCBvbiBhIHBhcnRpY3VsYXIgQ00uIgogICAgICAgOjo9IHsg ZG9jc1N1Yk1ndE9iamVjdHMgMSB9CgogICBkb2NzU3ViTWd0Q3BlQ29udHJvbEVudHJ5IE9CSkVD VC1UWVBFCiAgICAgICBTWU5UQVggIERvY3NTdWJNZ3RDcGVDb250cm9sRW50cnkKICAgICAgIE1B WC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgY3VycmVudAogICAgICAgREVT Q1JJUFRJT04KICAgICAgICAgICAiQSByb3cgaW4gdGhlIGRvY3NTdWJNZ3RDcGVDb250cm9sVGFi bGUuICBBbGwgdmFsdWVzIGFyZSBzZXQKICAgICAgIGF0IHN1Y2Nlc3NmdWwgbW9kZW0gcmVnaXN0 cmF0aW9uLCBlaXRoZXIgZnJvbSB0aGUgc3lzdGVtIGRlZmF1bHQsCiAgICAgICBvciBmcm9tIG9i amVjdHMgaW5jbHVkZWQgaW4gdGhlIERPQ1NJUyByZWdpc3RyYXRpb24gcmVxdWVzdCBzZW50CiAg ICAgICB1cHN0cmVhbSB0byB0aGUgQ01UUyBmcm9tIHRoZSBDTS4gVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW50cnkgYXJlCiAgICAgICBtZWFuaW5nbGVzcyB1bmxlc3MgdGhlIGNvcnJlc3BvbmRpbmcg ZG9jc0lmQ210c0NtU3RhdHVzVmFsdWUgaXMKICAgICAgIHJlZ2lzdHJhdGlvbkNvbXBsZXRlKDYp LiBUaGUgcGVyc2lzdGVuY2Ugb2YgdGhpcyByb3cgaXMKCkV4cGlyZXMgIE1heSAyMDAzICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSU5URVJO RVQtRFJBRlQgICAgICBET0NTSVMgU3Vic2NyaWJlciBNYW5hZ2VtZW50IE1JQiAgICAgICBOb3Zl bWJlciAyMDAyCgogICAgICAgZGV0ZXJtaW5lZCBzb2xlbHkgYnkgdGhlIGxpZmVzcGFuIG9mIHRo ZSBjb3JyZXNwb25kaW5nCiAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNFbnRyeSAobm9ybWFsbHkg U3RvcmFnZVR5cGU9dm9sYXRpbGUpLiIKICAgICAgIEFVR01FTlRTIHsgZG9jc0lmQ210c0NtU3Rh dHVzRW50cnkgfQogICAgICAgOjo9IHtkb2NzU3ViTWd0Q3BlQ29udHJvbFRhYmxlIDEgfQoKICAg RG9jc1N1Yk1ndENwZUNvbnRyb2xFbnRyeSA6Oj0gU0VRVUVOQ0UKICAgICAgIHsKICAgICAgIGRv Y3NTdWJNZ3RDcGVDb250cm9sTWF4Q3BlSXAgICAgICAgIEludGVnZXIzMiwKICAgICAgIGRvY3NT dWJNZ3RDcGVDb250cm9sQWN0aXZlICAgICAgICAgIFRydXRoVmFsdWUsCiAgICAgICBkb2NzU3Vi TWd0Q3BlQ29udHJvbExlYXJuYWJsZSAgICAgICBUcnV0aFZhbHVlLAogICAgICAgZG9jc1N1Yk1n dENwZUNvbnRyb2xSZXNldCAgICAgICAgICAgVHJ1dGhWYWx1ZQogICAgICAgfQoKICAgZG9jc1N1 Yk1ndENwZUNvbnRyb2xNYXhDcGVJcCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICBJbnRlZ2Vy MzIoMC4uMjE0NzQ4MzY0NykKICAgICAgIE1BWC1BQ0NFU1MgcmVhZC13cml0ZQogICAgICAgU1RB VFVTICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgbnVtYmVyIG9m IHNpbXVsdGFuZW91cyBJUCBhZGRyZXNzZXMgcGVybWl0dGVkIGJlaGluZAogICAgICAgdGhlIENN LiBJZiB0aGlzIGlzIHNldCB0byB6ZXJvLCBhbGwgQ1BFIHRyYWZmaWMgZnJvbSB0aGUgQ00gaXMK ICAgICAgIGRyb3BwZWQuICBJZiB0aGUgcHJvdmlzaW9uaW5nIG9iamVjdCBjb3JyZXNwb25kaW5n IHRvCiAgICAgICBkb2NzU3ViTWd0Q3BlSXBUYWJsZSBpbmNsdWRlcyBtb3JlIENQRSBJUCBhZGRy ZXNzIGVudHJpZXMgZm9yCiAgICAgICB0aGlzIG1vZGVtIHRoYW4gdGhlIHZhbHVlIG9mIHRoaXMg b2JqZWN0LCB0aGVuIHRoaXMgb2JqZWN0IGlzCiAgICAgICBzZXQgdG8gdGhlIGNvdW50IG9mIHRo ZSBudW1iZXIgb2Ygcm93cyBpbiBkb2NzU3ViTWd0Q3BlSXBUYWJsZQogICAgICAgdGhhdCBoYXZl IHRoZSBzYW1lIGRvY3NJZkNtdHNDbVN0YXR1c0luZGV4IHZhbHVlLiAoRS5nLiBpZiB0aGUKICAg ICAgIENNIGhhcyA1IElQIGFkZHJlc3NlcyBzcGVjaWZpZWQgZm9yIGl0LCB0aGlzIHZhbHVlIGlz IDUpLiBUaGlzCiAgICAgICBsaW1pdCBhcHBsaWVzIHRvIGxlYXJuZWQgYW5kIGRvY3Npcy1wcm92 aXNpb25lZCBlbnRyaWVzLCBidXQKICAgICAgIGRvZXMgbm90IGxpbWl0IGVudHJpZXMgYWRkZWQg dGhyb3VnaCBzb21lIGFkbWluaXN0cmF0aXZlCiAgICAgICBwcm9jZXNzIGF0IHRoZSBDTVRTLiBJ ZiBub3Qgc2V0IHRocm91Z2ggRE9DU0lTIHByb3Zpc2lvbmluZywKICAgICAgIHRoaXMgb2JqZWN0 IGRlZmF1bHRzIHRvIGRvY3NTdWJNZ3RDcGVNYXhJcERlZmF1bHQuIE5vdGUgdGhhdAogICAgICAg dGhpcyBvYmplY3QgaXMgb25seSBtZWFuaW5nZnVsIGlmIGRvY3NTdWJNZ3RDcGVDb250cm9sQWN0 aXZlCiAgICAgICBpcyB0cnVlLiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RDcGVDb250cm9sRW50 cnkgMSB9CgogICBkb2NzU3ViTWd0Q3BlQ29udHJvbEFjdGl2ZSBPQkpFQ1QtVFlQRQogICAgICAg U1lOVEFYICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNTIHJlYWQtd3JpdGUKICAgICAgIFNU QVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiSWYgdGhpcyBpcyBz ZXQgdG8gdHJ1ZSwgQ01UUyBiYXNlZCBDUEUgY29udHJvbCBpcyBhY3RpdmUgYW5kCiAgICAgICBh bGwgdGhlIGFjdGlvbnMgcmVxdWlyZWQgYnkgdGhlIHZhcmlvdXMgZmlsdGVyIHRhYmxlcyBhbmQK ICAgICAgIGNvbnRyb2xzIGFwcGx5IGF0IHRoZSBDTVRTLiAgSWYgdGhpcyBpcyBzZXQgdG8gZmFs c2UsIG5vCiAgICAgICBzdWJzY3JpYmVyIG1hbmFnZW1lbnQgZmlsdGVyaW5nIGlzIGRvbmUgYXQg dGhlIENNVFMgKGJ1dCBvdGhlcgogICAgICAgZmlsdGVycyBtYXkgYXBwbHkpLiBJZiBub3Qgc2V0 IHRocm91Z2ggRE9DU0lTIHByb3Zpc2lvbmluZywKICAgICAgIHRoaXMgb2JqZWN0IGRlZmF1bHRz IHRvIGRvY3NTdWJNZ3RDcGVBY3RpdmVEZWZhdWx0LiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RD cGVDb250cm9sRW50cnkgMiB9CgogICBkb2NzU3ViTWd0Q3BlQ29udHJvbExlYXJuYWJsZSBPQkpF Q1QtVFlQRQogICAgICAgU1lOVEFYICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNTIHJlYWQt d3JpdGUKICAgICAgIFNUQVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAg ICAiSWYgdGhpcyBpcyBzZXQgdG8gdHJ1ZSwgdGhlIENNVFMgbWF5IGxlYXJuIHVwIHRvCgpFeHBp cmVzICBNYXkgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSA5XQoMCklOVEVSTkVULURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdl bWVudCBNSUIgICAgICAgTm92ZW1iZXIgMjAwMgoKICAgICAgIGRvY3NTdWJNZ3RNYXhDcGVJcCBh ZGRyZXNzZXMgKGxlc3MgYW55IERPQ1NJUy1wcm92aXNpb25lZAogICAgICAgZW50cmllcykgcmVs YXRlZCB0byB0aGlzIENNLiAgVGhvc2UgSVAgYWRkcmVzc2VzIGFyZSBhZGRlZCAoYnkKICAgICAg IGludGVybmFsIHByb2Nlc3MpIHRvIHRoZSBkb2NzU3ViTWd0Q3BlSXBUYWJsZS4gVGhlIG5hdHVy ZSBvZiB0aGUKICAgICAgIGxlYXJuaW5nIG1lY2hhbmlzbSBpcyBub3Qgc3BlY2lmaWVkIGhlcmUu IElmIG5vdCBzZXQgdGhyb3VnaAogICAgICAgRE9DU0lTIHByb3Zpc2lvbmluZywgdGhpcyBvYmpl Y3QgZGVmYXVsdHMgdG8KICAgICAgIGRvY3NTdWJNZ3RDcGVMZWFybmFibGVEZWZhdWx0LiBOb3Rl IHRoYXQgdGhpcyBvYmplY3QgaXMgb25seQogICAgICAgbWVhbmluZ2Z1bCBpZiBkb2NzU3ViTWd0 Q3BlQ29udHJvbEFjdGl2ZSBpcyB0cnVlLiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RDcGVDb250 cm9sRW50cnkgMyB9CgogICBkb2NzU3ViTWd0Q3BlQ29udHJvbFJlc2V0IE9CSkVDVC1UWVBFCiAg ICAgICBTWU5UQVggIFRydXRoVmFsdWUKICAgICAgIE1BWC1BQ0NFU1MgcmVhZC13cml0ZQogICAg ICAgU1RBVFVTICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGlzIG9i amVjdCBhbHdheXMgcmV0dXJucyBmYWxzZSBvbiByZWFkLiAgSWYgdGhpcyBvYmplY3QgaXMKICAg ICAgIHNldCB0byB0cnVlLCB0aGUgcm93cyB3aXRoICAnbGVhcm5lZCcgYWRkcmVzc2VzIGluCiAg ICAgICBkb2NzU3ViTWd0Q3BlSXBUYWJsZSBmb3IgdGhpcyBDTSBhcmUgZGVsZXRlZCBmcm9tIHRo YXQgdGFibGUuIgogICAgICAgOjo9IHsgZG9jc1N1Yk1ndENwZUNvbnRyb2xFbnRyeSA0IH0KCiAg IGRvY3NTdWJNZ3RDcGVNYXhJcERlZmF1bHQgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgSW50 ZWdlcjMyKDAuLjIxNDc0ODM2NDcpCiAgICAgICBNQVgtQUNDRVNTIHJlYWQtd3JpdGUKICAgICAg IFNUQVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIGRlZmF1 bHQgdmFsdWUgZm9yIGRvY3NTdWJNZ3RDcGVDb250cm9sTWF4Q3BlSXAgaWYgbm90CiAgICAgICBz aWduYWxlZCBpbiB0aGUgRE9DU0lTIFJlZ2lzdHJhdGlvbiByZXF1ZXN0LiBVcG9uIGluaXRpYWwg Q01UUwogICAgICAgaW5pdGlhbGl6YXRpb24sIHRoaXMgZGVmYXVsdHMgdG8gMTYuIgogICAgICAg Ojo9IHsgZG9jc1N1Yk1ndE9iamVjdHMgMiB9CgogICBkb2NzU3ViTWd0Q3BlQWN0aXZlRGVmYXVs dCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNT IHJlYWQtd3JpdGUKICAgICAgIFNUQVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAg ICAgICAgICAiVGhlIGRlZmF1bHQgdmFsdWUgZm9yIGRvY3NTdWJNZ3RDcGVDb250cm9sQWN0aXZl IGlmIG5vdAogICAgICAgc2lnbmFsZWQgaW4gdGhlIERPQ1NJUyBSZWdpc3RyYXRpb24gcmVxdWVz dC4gVXBvbiBpbml0aWFsIENNVFMKICAgICAgIGluaXRpYWxpemF0aW9uLCB0aGlzIGRlZmF1bHRz IHRvIGZhbHNlLiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RPYmplY3RzIDMgfQoKICAgZG9jc1N1 Yk1ndENwZUxlYXJuYWJsZURlZmF1bHQgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgVHJ1dGhW YWx1ZQogICAgICAgTUFYLUFDQ0VTUyByZWFkLXdyaXRlCiAgICAgICBTVEFUVVMgIGN1cnJlbnQK ICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBkZWZhdWx0IHZhbHVlIGZvciBkb2Nz U3ViTWd0Q3BlQ29udHJvbExlYXJuYWJsZSBpZiBub3QKICAgICAgIHNpZ25hbGVkIGluIHRoZSBE T0NTSVMgUmVnaXN0cmF0aW9uIHJlcXVlc3QuIFVwb24gaW5pdGlhbCBDTVRTCiAgICAgICBpbml0 aWFsaXphdGlvbiwgdGhpcyBkZWZhdWx0cyB0byB0cnVlLiIKICAgICAgIDo6PSB7IGRvY3NTdWJN Z3RPYmplY3RzIDQgfQoKICAgZG9jc1N1Yk1ndENwZUlwVGFibGUgT0JKRUNULVRZUEUKICAgICAg IFNZTlRBWCAgICAgIFNFUVVFTkNFIE9GIERvY3NTdWJNZ3RDcGVJcEVudHJ5CiAgICAgICBNQVgt QUNDRVNTICBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVTICAgICAgY3VycmVudAoKRXhwaXJl cyAgTWF5IDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAxMF0KDApJTlRFUk5FVC1EUkFGVCAgICAgIERPQ1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1l bnQgTUlCICAgICAgIE5vdmVtYmVyIDIwMDIKCiAgICAgICBERVNDUklQVElPTgogICAgICAgICAg ICJBIHRhYmxlIG9mIENQRSBJUCBhZGRyZXNzZXMga25vd24gb24gYSBwZXIgQ00gYmFzaXMuIgog ICAgICAgOjo9IHsgZG9jc1N1Yk1ndE9iamVjdHMgNSB9CgogICBkb2NzU3ViTWd0Q3BlSXBFbnRy eSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICAgRG9jc1N1Yk1ndENwZUlwRW50cnkKICAg ICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50 CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJBbiBlbnRyeSBpbiB0aGUgZG9jc1N1Yk1n dENwZUlwVGFibGUuICBUaGUgZmlyc3QgaW5kZXggaXMKICAgICAgIHRoZSBzcGVjaWZpYyBtb2Rl bSB3ZSdyZSByZWZlcnJpbmcgdG8sIHRoZSBzZWNvbmQgaW5kZXggaXMgdGhlCiAgICAgICBzcGVj aWZpYyBDUEUgSVAgZW50cnkuIgogICAgICAgSU5ERVggICB7IGRvY3NJZkNtdHNDbVN0YXR1c0lu ZGV4LAogICAgICAgICAgICAgICAgIGRvY3NTdWJNZ3RDcGVJcEluZGV4IH0KICAgICAgIDo6PSB7 ZG9jc1N1Yk1ndENwZUlwVGFibGUgMSB9CgogICBEb2NzU3ViTWd0Q3BlSXBFbnRyeSA6Oj0gU0VR VUVOQ0UKICAgICAgIHsKICAgICAgIGRvY3NTdWJNZ3RDcGVJcEluZGV4ICAgICAgICBJbnRlZ2Vy MzIsCiAgICAgICBkb2NzU3ViTWd0Q3BlSXBBZGRyZXNzVHlwZSAgSW5ldEFkZHJlc3NUeXBlLAog ICAgICAgZG9jc1N1Yk1ndENwZUlwQWRkciAgICAgICAgIEluZXRBZGRyZXNzLAogICAgICAgZG9j c1N1Yk1ndENwZUlwTGVhcm5lZCAgICAgIFRydXRoVmFsdWUKICAgICAgIH0KCgogICBkb2NzU3Vi TWd0Q3BlSXBJbmRleCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICAgSW50ZWdlcjMyKDEu LjIxNDc0ODM2NDcpCiAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZQogICAgICAgU1RB VFVTICAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIGluZGV4 IG9mIHRoaXMgQ1BFIElQIGFkZHJlc3MgcmVsYXRpdmUgdG8gdGhlIGluZGV4ZWQgQ00uCiAgICAg ICBBbiBlbnRyeSBpcyBjcmVhdGVkIGVpdGhlciB0aHJvdWdoIHRoZSBpbmNsdWRlZCBDUEUgSVAg YWRkcmVzc2VzCiAgICAgICBpbiB0aGUgcHJvdmlzaW9uaW5nIG9iamVjdCwgb3IgdmlhIGxlYXJu aW5nLiAgSWYgYSBDTVRTIHJlY2VpdmVzCiAgICAgICBhbiBJUCBwYWNrZXQgZnJvbSBhIENNIHRo YXQgY29udGFpbnMgYSBzb3VyY2UgSVAgYWRkcmVzcyB3aGljaAogICAgICAgZG9lcyBub3QgbWF0 Y2ggb25lIG9mIHRoZSBkb2NzU3ViTWd0Q3BlSXBBZGRyIGVudHJpZXMgZm9yIHRoaXMKICAgICAg IENNLCBvbmUgb2YgdHdvIHRoaW5ncyBvY2N1cnMuICBJZiB0aGUgbnVtYmVyIG9mIGVudHJpZXMg aXMgbGVzcwogICAgICAgdGhhbiBkb2NzU3ViTWd0Q3BlQ29udHJvbE1heENwZUlwLCB0aGUgc291 cmNlIGFkZHJlc3MgaXMgYWRkZWQgdG8KICAgICAgIHRoZSB0YWJsZSBhbmQgdGhlIHBhY2tldCBp cyBmb3J3YXJkZWQuICBJZiB0aGUgbnVtYmVyIG9mIGVudHJpZXMKICAgICAgIGVxdWFscyB0aGUg ZG9jc1N1Yk1ndENwZUNvbnRyb2xNYXhDcGVJcCwgQU5ECiAgICAgICBkb2NzU3ViTWd0Q3BlQ29u dHJvbEFjdGl2ZSBpcyB0cnVlLCB0aGVuIHRoZSBwYWNrZXQgaXMgZHJvcHBlZC4KICAgICAgIE90 aGVyd2lzZSB0aGUgcGFja2V0IGlzIGZvcndhcmRlZC4gIgogICAgICAgOjo9IHsgZG9jc1N1Yk1n dENwZUlwRW50cnkgMSB9CgogICBkb2NzU3ViTWd0Q3BlSXBBZGRyZXNzVHlwZSBPQkpFQ1QtVFlQ RQogICAgICAgU1lOVEFYICAgICAgSW5ldEFkZHJlc3NUeXBlCiAgICAgICBNQVgtQUNDRVNTICBy ZWFkLW9ubHkKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIlRoZSB0eXBlIG9mIGludGVybmV0IGFkZHJlc3Mgb2YgZG9jc1N1Yk1ndENwZUlw QWRkci4iCiAgICAgICA6Oj0geyBkb2NzU3ViTWd0Q3BlSXBFbnRyeSAyIH0KCiAgIGRvY3NTdWJN Z3RDcGVJcEFkZHIgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgIEluZXRBZGRyZXNzCgpF eHBpcmVzICBNYXkgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDExXQoMCklOVEVSTkVULURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFu YWdlbWVudCBNSUIgICAgICAgTm92ZW1iZXIgMjAwMgoKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQt b25seQogICAgICAgU1RBVFVTICAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiVGhlIElQIGFkZHJlc3MgZWl0aGVyIHNldCBmcm9tIHByb3Zpc2lvbmluZyBvciBsZWFy bmVkIHZpYQogICAgICAgYWRkcmVzcyBnbGVhbmluZyBvciBvdGhlciBmb3J3YXJkaW5nIG1lYW5z LiBTZWUKICAgICAgIGRvY3NTdWJNZ3RDcGVJcEluZGV4IGZvciB0aGUgbWVjaGFuaXNtLiIKICAg ICAgIDo6PSB7IGRvY3NTdWJNZ3RDcGVJcEVudHJ5IDMgfQoKICAgZG9jc1N1Yk1ndENwZUlwTGVh cm5lZCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUND RVNTIHJlYWQtb25seQogICAgICAgU1RBVFVTICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgog ICAgICAgICAgICJJZiB0cnVlLCB0aGlzIGVudHJ5IHdhcyBsZWFybmVkIGZyb20gSVAgcGFja2V0 cyBzZW50CiAgICAgICB1cHN0cmVhbSByYXRoZXIgdGhhbiBmcm9tIHRoZSBwcm92aXNpb25pbmcg b2JqZWN0cy4iCiAgICAgICA6Oj0geyBkb2NzU3ViTWd0Q3BlSXBFbnRyeSA0IH0KCgogICAtLSBU aGUgZ2VuZXJpYyBwYWNrZXQgZmlsdGVyIHRhYmxlLiAgTm90ZSB0aGF0IHRoaXMganVzdCBkZWZp bmVzIHRoZQogICAtLSBtYXRjaCBjcml0ZXJpYS4gIFRoZSBkb2NzU3ViTWd0Q21GaWx0ZXJUYWJs ZSBsaW5rcyB0aGlzIHRhYmxlIHRvCiAgIC0tIHRoZSBzcGVjaWZpYyBtb2RlbXMuCgogICBkb2Nz U3ViTWd0UGt0RmlsdGVyVGFibGUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgIFNFUVVF TkNFIE9GIERvY3NTdWJNZ3RQa3RGaWx0ZXJFbnRyeQogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFj Y2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIkEgdGFibGUgb2YgZmlsdGVyIG9yIGNsYXNzaWZpZXIgY3JpdGVyaWEuIENsYXNz aWZpZXJzIGFyZQogICAgICAgYXNzaWduZWQgYnkgZ3JvdXAgdG8gdGhlIGluZGl2aWR1YWwgQ01z LiAgVGhhdCBhc3NpZ25tZW50IGlzIG1hZGUKICAgICAgIHZpYSB0aGUgY29uZmlndXJhdGlvbiBv YmplY3RzIHNlbnQgdXBzdHJlYW0gZnJvbSB0aGUgQ00gdG8gdGhlCiAgICAgICBDTVRTIGR1cmlu ZyByZWdpc3RyYXRpb24uIgogICAgICAgOjo9IHsgZG9jc1N1Yk1ndE9iamVjdHMgNiB9CgogICBk b2NzU3ViTWd0UGt0RmlsdGVyRW50cnkgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgIERv Y3NTdWJNZ3RQa3RGaWx0ZXJFbnRyeQogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUK ICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAg IkFuIGVudHJ5IGluIHRoZSBkb2NzU3ViTWd0UGt0RmlsdGVyVGFibGUuIgogICAgICAgSU5ERVgg ICB7IGRvY3NTdWJNZ3RQa3RGaWx0ZXJHcm91cCwKICAgICAgICAgICAgICAgICBkb2NzU3ViTWd0 UGt0RmlsdGVySW5kZXggfQogICAgICAgOjo9IHtkb2NzU3ViTWd0UGt0RmlsdGVyVGFibGUgMSB9 CgogICBEb2NzU3ViTWd0UGt0RmlsdGVyRW50cnkgOjo9IFNFUVVFTkNFCiAgICAgICB7CiAgICAg ICBkb2NzU3ViTWd0UGt0RmlsdGVyR3JvdXAgICAgICAgIEludGVnZXIzMiwKICAgICAgIGRvY3NT dWJNZ3RQa3RGaWx0ZXJJbmRleCAgICAgICAgSW50ZWdlcjMyLAogICAgICAgZG9jc1N1Yk1ndFBr dEZpbHRlckFkZHJUeXBlICAgICBJbmV0QWRkcmVzc1R5cGUsCiAgICAgICBkb2NzU3ViTWd0UGt0 RmlsdGVyU3JjQWRkciAgICAgIEluZXRBZGRyZXNzLAogICAgICAgZG9jc1N1Yk1ndFBrdEZpbHRl clNyY01hc2sgICAgICBJbmV0QWRkcmVzc1ByZWZpeExlbmd0aCwKICAgICAgIGRvY3NTdWJNZ3RQ a3RGaWx0ZXJEc3RBZGRyICAgICAgSW5ldEFkZHJlc3MsCiAgICAgICBkb2NzU3ViTWd0UGt0Rmls dGVyRHN0TWFzayAgICAgIEluZXRBZGRyZXNzUHJlZml4TGVuZ3RoLAogICAgICAgZG9jc1N1Yk1n dFBrdEZpbHRlclVscCAgICAgICAgICBJbnRlZ2VyMzIsCgpFeHBpcmVzICBNYXkgMjAwMyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQoMCklOVEVS TkVULURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAgICAgTm92 ZW1iZXIgMjAwMgoKICAgICAgIGRvY3NTdWJNZ3RQa3RGaWx0ZXJUb3NWYWx1ZSAgICAgT0NURVQg U1RSSU5HLAogICAgICAgZG9jc1N1Yk1ndFBrdEZpbHRlclRvc01hc2sgICAgICBPQ1RFVCBTVFJJ TkcsCiAgICAgICBkb2NzU3ViTWd0UGt0RmlsdGVyQWN0aW9uICAgICAgIElOVEVHRVIsCiAgICAg ICBkb2NzU3ViTWd0UGt0RmlsdGVyTWF0Y2hlcyAgICAgIENvdW50ZXIzMiwKICAgICAgIGRvY3NT dWJNZ3RQa3RGaWx0ZXJTdGF0dXMgICAgICAgUm93U3RhdHVzLAogICAgICAgZG9jc1N1Yk1ndFBr dEZpbHRlclN0b3JhZ2VUeXBlICBTdG9yYWdlVHlwZQogICAgICAgfQoKICAgZG9jc1N1Yk1ndFBr dEZpbHRlckdyb3VwIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgICBJbnRlZ2VyMzIoMS4u MjE0NzQ4MzY0NykKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFU VVMgICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJJZGVudGlmaWVz IGFuIG9yZGVyZWQgZ3JvdXAgb2YgZmlsdGVycy4gRWFjaCBtb2RlbSBtYXkgYmUKICAgICAgIGFz c29jaWF0ZWQgd2l0aCBhIGZpbHRlciBncm91cCBmb3IgaXRzIHVwc3RyZWFtIHRyYWZmaWMKICAg ICAgIChkb2NzU3ViTWd0Q21GaWx0ZXJVcHN0cmVhbSkgYW5kIGEgZmlsdGVyIGdyb3VwIGZvciBp dHMKICAgICAgIGRvd25zdHJlYW0gdHJhZmZpYyAoZG9jc1N1Yk1ndENtRmlsdGVyRG93bnN0cmVh bSkuIFR5cGljYWxseSwKICAgICAgIG1hbnkgbW9kZW1zIHdpbGwgdXNlIHRoZSBzYW1lIGZpbHRl ciBncm91cC4iCiAgICAgICA6Oj0geyBkb2NzU3ViTWd0UGt0RmlsdGVyRW50cnkgMSB9CgogICBk b2NzU3ViTWd0UGt0RmlsdGVySW5kZXggT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgIElu dGVnZXIzMigxLi4yMTQ3NDgzNjQ3KQogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUK ICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAg IkFuIGluZGV4IHdoaWNoIGRlc2NyaWJlcyB0aGUgb3JkZXJpbmcgb2YgYSBzZXQgb2YgZmlsdGVy CiAgICAgICBzcGVjaWZpY2F0aW9ucyB3aXRoaW4gdGhlIGdyb3VwLiAgRmlsdGVycyBhcmUgYXBw bGllZCBpbiBpbmRleAogICAgICAgb3JkZXIuIgogICAgICAgOjo9IHsgZG9jc1N1Yk1ndFBrdEZp bHRlckVudHJ5IDIgfQoKICAgZG9jc1N1Yk1ndFBrdEZpbHRlckFkZHJUeXBlIE9CSkVDVC1UWVBF CiAgICAgICBTWU5UQVggICAgICBJbmV0QWRkcmVzc1R5cGUKICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtY3JlYXRlCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgog ICAgICAgICAgICJUaGUgdHlwZSBvZiBpbnRlcm5ldCBhZGRyZXNzIG9mIGRvY3NTdWJNZ3RQa3RG aWx0ZXJTcmNBZGRyLAogICAgICAgZG9jc1N1Yk1ndFBrdEZpbHRlclNyY01hc2ssIGRvY3NTdWJN Z3RQa3RGaWx0ZXJEc3RBZGRyLCBhbmQKICAgICAgIGRvY3NTdWJNZ3RQa3RGaWx0ZXJEc3RNYXNr LiIKICAgICAgIERFRlZBTCB7IGlwdjQgfQogICAgICAgOjo9IHsgZG9jc1N1Yk1ndFBrdEZpbHRl ckVudHJ5IDMgfQoKICAgZG9jc1N1Yk1ndFBrdEZpbHRlclNyY0FkZHIgT0JKRUNULVRZUEUKICAg ICAgIFNZTlRBWCAgICAgIEluZXRBZGRyZXNzCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0 ZQogICAgICAgU1RBVFVTICAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAg ICAiVGhlIHNvdXJjZSBJUCBhZGRyZXNzIHRvIG1hdGNoIGluIHRoZSBwYWNrZXQgdG8gYmUKICAg ICAgIGNsYXNzaWZpZWQuICBCeSBkZWZhdWx0LCB0aGlzIGlzIHRoZSBhbGwtemVybydzIElQIHY0 IGFuZCB2NgogICAgICAgYWRkcmVzcy4gQSBwYWNrZXQgbWF0Y2hlcyB0aGUgU3JjQWRkciBmaWx0 ZXIgaWYgdGhlIGZvbGxvd2luZyBpcwogICAgICAgdHJ1ZToKICAgICAgICAgICAgQU5EIChGaWx0 ZXJTcmNBZGRyLCBGaWx0ZXJTcmNNYXNrKSA9PQogICAgICAgICAgICBBTkQgKFBhY2tldCBTcmNB ZGRyLCBGaWx0ZXJTcmNNYXNrKS4KICAgICAgIFRoZSBtYXNrIHZhbHVlIGlzIGFwcGxpZWQgdG8g Ym90aCB0aGUgbWF0Y2ggdmFsdWUgaW4gdGhpcyB0YWJsZQoKRXhwaXJlcyAgTWF5IDIwMDMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJTlRF Uk5FVC1EUkFGVCAgICAgIERPQ1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgTUlCICAgICAgIE5v dmVtYmVyIDIwMDIKCiAgICAgICBhbmQgdG8gdGhlIHBhY2tldCBJUCBhZGRyZXNzLiBUaGUgYWRk cmVzcyB0eXBlIG9mIHRoaXMgb2JqZWN0IGlzCiAgICAgICBzcGVjaWZpZWQgYnkgZG9jc1N1Yk1n dFBrdEZpbHRlckFkZHJUeXBlLiIKICAgICAgIERFRlZBTCB7ICcwNDAwMDAwMDAwJ0ggfSAgICAt LSAwLjAuMC4wCiAgICAgICA6Oj0geyBkb2NzU3ViTWd0UGt0RmlsdGVyRW50cnkgNCB9CgogICBk b2NzU3ViTWd0UGt0RmlsdGVyU3JjTWFzayBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICAg SW5ldEFkZHJlc3NQcmVmaXhMZW5ndGgKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlCiAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJT cGVjaWZpZXMgdGhlIG51bWJlciBvZiBsZWZ0bW9zdCAxJ3MgYml0cyBpbiBhbiBhZGRyZXNzCiAg ICAgICBiaXQgbWFzay4gVGhlIGJpdCBtYXNrIHRoYXQgaXMgYXBwbGllZCB0byB0aGUgc291cmNl IGFkZHJlc3MKICAgICAgIHByaW9yIHRvIG1hdGNoaW5nLiBUaGlzLCB0YWtlbiB3aXRoIHRoZSBT cmNBZGRyIHNwZWNpZmllcyBhCiAgICAgICBtYXRjaGluZyBjcml0ZXJpYS4gIEJ5IGRlZmF1bHQs IHRoZSBwYWlyIHNwZWNpZmllcyBhIGZpbHRlcgogICAgICAgd2hpY2ggbWF0Y2hlcyBhbGwgc291 cmNlIGFkZHJlc3Nlcy4gVGhlIGFkZHJlc3MgdHlwZSBvZiB0aGlzCiAgICAgICBvYmplY3QgaXMg c3BlY2lmaWVkIGJ5IGRvY3NTdWJNZ3RQa3RGaWx0ZXJBZGRyVHlwZS4iCiAgICAgICBERUZWQUwg eyAwICB9CiAgICAgICA6Oj0geyBkb2NzU3ViTWd0UGt0RmlsdGVyRW50cnkgNSB9CgogICBkb2Nz U3ViTWd0UGt0RmlsdGVyRHN0QWRkciBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICAgSW5l dEFkZHJlc3MKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlCiAgICAgICBTVEFUVVMgICAg ICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgZGVzdGluYXRpb24g SVAgYWRkcmVzcyB0byBtYXRjaCBpbiB0aGUgcGFja2V0IHRvIGJlCiAgICAgICBjbGFzc2lmaWVk LiAgQnkgZGVmYXVsdCwgdGhpcyBpcyB0aGUgYWxsLXplcm8ncyBJUCB2NCBhbmQgdjYKICAgICAg IGFkZHJlc3MuIEEgcGFja2V0IG1hdGNoZXMgdGhlIERzdEFkZHIgZmlsdGVyIGlmIHRoZSBmb2xs b3dpbmcgaXMKICAgICAgIHRydWU6CiAgICAgICAgICAgIEFORCAoRmlsdGVyRHN0QWRkciwgRmls dGVyRHN0TWFzaykgPT0KICAgICAgICAgICAgQU5EIChQYWNrZXQgRHN0QWRkciwgRmlsdGVyRHN0 TWFzaykuCiAgICAgICBUaGUgbWFzayB2YWx1ZSBpcyBhcHBsaWVkIHRvIGJvdGggdGhlIG1hdGNo IHZhbHVlIGluIHRoaXMgdGFibGUKICAgICAgIGFuZCB0byB0aGUgcGFja2V0IElQIGFkZHJlc3Mu IFRoZSBhZGRyZXNzIHR5cGUgb2YgdGhpcyBvYmplY3QgaXMKICAgICAgIHNwZWNpZmllZCBieSBk b2NzU3ViTWd0UGt0RmlsdGVyQWRkclR5cGUuIgogICAgICAgREVGVkFMIHsgJzA0MDAwMDAwMDAn SCB9ICAgIC0tIDAuMC4wLjAKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RQa3RGaWx0ZXJFbnRyeSA2 IH0KCiAgIGRvY3NTdWJNZ3RQa3RGaWx0ZXJEc3RNYXNrIE9CSkVDVC1UWVBFCiAgICAgICBTWU5U QVggICAgICBJbmV0QWRkcmVzc1ByZWZpeExlbmd0aAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1j cmVhdGUKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAg ICAgICAgIlNwZWNpZmllcyB0aGUgbnVtYmVyIG9mIGxlZnRtb3N0IDEncyBiaXRzIGluIGFuIGFk ZHJlc3MKICAgICAgIGJpdCBtYXNrLiBUaGUgYml0IG1hc2sgdGhhdCBpcyBhcHBsaWVkIHRvIHRo ZSBkZXN0aW5hdGlvbgogICAgICAgYWRkcmVzcyBwcmlvciB0byBtYXRjaGluZy4gVGhpcywgdGFr ZW4gd2l0aCB0aGUgRHN0QWRkciBzcGVjaWZpZXMKICAgICAgIGEgbWF0Y2hpbmcgY3JpdGVyaWEu ICBCeSBkZWZhdWx0LCB0aGUgcGFpciBzcGVjaWZpZXMgYSBmaWx0ZXIKICAgICAgIHdoaWNoIG1h dGNoZXMgYWxsIGRlc3RpbmF0aW9uIGFkZHJlc3Nlcy4gVGhlIGFkZHJlc3MgdHlwZSBvZiB0aGlz CiAgICAgICBvYmplY3QgaXMgc3BlY2lmaWVkIGJ5IGRvY3NTdWJNZ3RQa3RGaWx0ZXJBZGRyVHlw ZS4iCiAgICAgICBERUZWQUwgeyAwICB9CiAgICAgICA6Oj0geyBkb2NzU3ViTWd0UGt0RmlsdGVy RW50cnkgNyB9CgogICBkb2NzU3ViTWd0UGt0RmlsdGVyVWxwIE9CSkVDVC1UWVBFCiAgICAgICBT WU5UQVggICAgICBJbnRlZ2VyMzIgKDAuLjI1NikKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3Jl YXRlCgpFeHBpcmVzICBNYXkgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDE0XQoMCklOVEVSTkVULURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmli ZXIgTWFuYWdlbWVudCBNSUIgICAgICAgTm92ZW1iZXIgMjAwMgoKICAgICAgIFNUQVRVUyAgICAg IGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlVwcGVyIGxldmVsIHByb3Rv Y29sIHRvIG1hdGNoLiAgSWYgdGhpcyB2YWx1ZSBpcyAyNTYsCiAgICAgICBtYXRjaGVzIEFMTCBV TFAgdmFsdWVzLiAgT3RoZXJ3aXNlLCB0aGlzIG1hdGNoZXMgdGhlIHNwZWNpZmljCiAgICAgICBw cm90b2NvbCB2YWx1ZS4gIE5vdGUgdGhhdCBpZiB0aGUgcGFja2V0IFVMUCBpcyBlaXRoZXIgNiAo dGNwKSBvcgogICAgICAgMTcgKHVkcCksIHRoZW4gZG9jc1N1Yk1ndFBrdFRjcFVkcEZpbHRlclRh YmxlIG11c3QgYWxzbyBiZQogICAgICAgY29uc3VsdGVkIChpZiBpdHMgZW50cnkgZXhpc3RzKSB0 byBzZWUgaWYgdGhpcyBlbnRyeSBtYXRjaGVzLgogICAgICAgSWYgdGhpcyB2YWx1ZSBpcyBuZWl0 aGVyIHRjcCg2KSBub3IgdWRwKDE3KSwgdGhlbiB0aGF0CiAgICAgICB0YWJsZSBpcyBub3QgY29u c3VsdGVkLiIKICAgICAgIERFRlZBTCB7IDI1NiB9CiAgICAgICA6Oj0geyBkb2NzU3ViTWd0UGt0 RmlsdGVyRW50cnkgOCB9CgogICBkb2NzU3ViTWd0UGt0RmlsdGVyVG9zVmFsdWUgT0JKRUNULVRZ UEUKICAgICAgIFNZTlRBWCAgICAgIE9DVEVUIFNUUklORyAoU0laRSgxKSkKICAgICAgIE1BWC1B Q0NFU1MgIHJlYWQtY3JlYXRlCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50CiAgICAgICBERVND UklQVElPTgogICAgICAgICAgICJUaGUgVE9TIHZhbHVlIHRvIG1hdGNoIGluIHRoZSBJUCBwYWNr ZXQuIgogICAgICAgREVGVkFMIHsgJzAwJ2ggfQogICAgICAgOjo9IHsgZG9jc1N1Yk1ndFBrdEZp bHRlckVudHJ5IDkgfQoKICAgZG9jc1N1Yk1ndFBrdEZpbHRlclRvc01hc2sgT0JKRUNULVRZUEUK ICAgICAgIFNZTlRBWCAgICAgIE9DVEVUIFNUUklORyhTSVpFKDEpKQogICAgICAgTUFYLUFDQ0VT UyAgcmVhZC1jcmVhdGUKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBU SU9OCiAgICAgICAgICAgIlRoZSBtYXNrIHRvIGFwcGx5IGFnYWluc3QgdGhlIFRPUyB2YWx1ZSB0 byBiZSBtYXRjaGVkIGluIHRoZQogICAgICAgSVAgcGFja2V0LiAgVGhlIGRlZmF1bHQgZm9yIGJv dGggdGhlc2Ugb2JqZWN0cyB0YWtlbiB0b2dldGhlcgogICAgICAgbWF0Y2hlcyBhbGwgVE9TIHZh bHVlcy4gQSBwYWNrZXQgbWF0Y2hlcyB0aGlzIGZpbHRlciBpZiB0aGUKICAgICAgIGZvbGxvd2lu ZyBpcyB0cnVlOgogICAgICAgICAgIEFORCAoRmlsdGVyVG9zVmFsdWUsIEZpbHRlclRvc01hc2sp ID09CiAgICAgICAgICAgQU5EIChQYWNrZXQgVE9TIFZhbHVlLCBGaWx0ZXJUb3NNYXNrKS4iCiAg ICAgICBERUZWQUwgeyAnMDAnaCB9CiAgICAgICA6Oj0geyBkb2NzU3ViTWd0UGt0RmlsdGVyRW50 cnkgMTAgfQoKICAgZG9jc1N1Yk1ndFBrdEZpbHRlckFjdGlvbiBPQkpFQ1QtVFlQRQogICAgICAg U1lOVEFYICAgICAgSU5URUdFUgogICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAg ICAgICAgICAgYWNjZXB0KDEpLAogICAgICAgICAgICAgICAgICAgICAgZHJvcCgyKQogICAgICAg ICAgICAgICAgICAgICAgfQogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUKICAgICAgIFNU QVRVUyAgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBhY3Rp b24gdG8gdGFrZSB1cG9uIHRoaXMgZmlsdGVyIG1hdGNoaW5nLiAgQWNjZXB0IG1lYW5zCiAgICAg ICB0byBlbmQgZmlsdGVyIG1hdGNoaW5nIGFuZCB0byBhY2NlcHQgdGhlIHBhY2tldCBmb3IgZnVy dGhlcgogICAgICAgcHJvY2Vzc2luZy4gRHJvcCBtZWFucyB0byBkcm9wIHRoZSBwYWNrZXQuIgog ICAgICAgREVGVkFMIHsgYWNjZXB0IH0KICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RQa3RGaWx0ZXJF bnRyeSAxMSB9CgogICBkb2NzU3ViTWd0UGt0RmlsdGVyTWF0Y2hlcyBPQkpFQ1QtVFlQRQogICAg ICAgU1lOVEFYICAgICAgQ291bnRlcjMyCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkKCkV4 cGlyZXMgIE1heSAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMTVdCgwKSU5URVJORVQtRFJBRlQgICAgICBET0NTSVMgU3Vic2NyaWJlciBNYW5h Z2VtZW50IE1JQiAgICAgICBOb3ZlbWJlciAyMDAyCgogICAgICAgU1RBVFVTICAgICAgY3VycmVu dAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhpcyBvYmplY3QgY291bnRzIHRoZSBu dW1iZXIgb2YgdGltZXMgdGhpcyBzcGVjaWZpYyBydWxlCiAgICAgICBoYXMgYmVlbiBtYXRjaGVk LiAgVGhpcyBpcyBpbmNyZW1lbnRlZCBhbnkgdGltZSB0aGlzIHJ1bGUgaXMKICAgICAgIGVuY291 bnRlcmVkIGFuZCBhbGwgY29tcG9uZW50cyBtYXRjaC4gSXQgaXMgb25seSBpbmNyZW1lbnRlZCBm b3IKICAgICAgIHRoZSBmaXJzdCAobG93ZXN0LWluZGV4ZWQpIGZpbHRlciBtYXRjaGluZyBhIHBh Y2tldC4iCiAgICAgICA6Oj0geyBkb2NzU3ViTWd0UGt0RmlsdGVyRW50cnkgMTIgfQoKICAgZG9j c1N1Yk1ndFBrdEZpbHRlclN0YXR1cyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICAgUm93 U3RhdHVzCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQogICAgICAgU1RBVFVTICAgICAg Y3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiU3RhbmRhcmQgcm93U3RhdHVz IG9iamVjdCBmb3IgY3JlYXRpbmcgdGhpcyByb3cuICBBbnkgb2JqZWN0CiAgICAgICBpbiB0aGlz IHJvdyB3aGljaCBpcyB3cml0YWJsZSBtYXkgYmUgY2hhbmdlZCBhdCBhbnkgdGltZSB3aGlsZQog ICAgICAgdGhlIHJvdyBpcyBhY3RpdmUuIFNpbmNlIGFsbCB3cml0YWJsZSBvYmplY3RzIGluIHRo ZSBlbnRyeSBoYXZlCiAgICAgICBERUZWQUxzLCBhIHJvdyBtYXkgYmUgbWFkZSBhY3RpdmUgd2l0 aG91dCBzcGVjaWZ5aW5nIGFueSBvdGhlcgogICAgICAgdmFsdWVzLiIKICAgICAgIDo6PSB7IGRv Y3NTdWJNZ3RQa3RGaWx0ZXJFbnRyeSAxMyB9CgogICBkb2NzU3ViTWd0UGt0RmlsdGVyU3RvcmFn ZVR5cGUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgU3RvcmFnZVR5cGUKICAgICAgIE1B WC1BQ0NFU1MgcmVhZC1jcmVhdGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVT Q1JJUFRJT04KICAgICAgICAgICAiVGhpcyBvYmplY3QgZGVmaW5lcyB3aGV0aGVyIHRoaXMgZmls dGVyIGlzIGtlcHQgaW4gdm9sYXRpbGUKICAgICAgIHN0b3JhZ2UgYW5kIGxvc3QgdXBvbiByZWJv b3Qgb3IgaWYgdGhpcyByb3cgaXMgYmFja2VkIHVwIGJ5CiAgICAgICBub24tdm9sYXRpbGUgb3Ig cGVybWFuZW50IHN0b3JhZ2UuICdwZXJtYW5lbnQnIGVudHJpZXMgbmVlZCBub3QKICAgICAgIGFs bG93IHdyaXRhYmxlIGFjY2VzcyB0byBhbnkgb2JqZWN0LiIKICAgICAgIERFRlZBTCB7IG5vblZv bGF0aWxlIH0KICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RQa3RGaWx0ZXJFbnRyeSAxNCB9CgogICBk b2NzU3ViTWd0VGNwVWRwRmlsdGVyVGFibGUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgU0VR VUVOQ0UgT0YgRG9jc1N1Yk1ndFRjcFVkcEZpbHRlckVudHJ5CiAgICAgICBNQVgtQUNDRVNTIG5v dC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIlRoaXMgaXMgYW4gYWRqdW5jdCB0byBkb2NzU3ViTWd0UGt0RmlsdGVyVGFibGUu IEl0IHByb3ZpZGVzCiAgICAgICAgICAgIG9wdGlvbmFsIGZpbHRlcmluZyBiYXNlZCBvbiBlbGVt ZW50cyBpbiBUQ1Agb3IgVURQIGhlYWRlcnMuCiAgICAgICAgICAgIFRoaXMgdGFibGUgaXMgc2Vw YXJhdGUgZnJvbSBkb2NzU3ViTWd0UGt0RmlsdGVyVGFibGUgb25seQogICAgICAgICAgICBiZWNh dXNlIGl0IGlzIGV4cGVjdGVkIHRvIGJlIHVzZWQgbW9yZSByYXJlbHkuIFRoaXMgdGFibGUKICAg ICAgICAgICAgaXMgbm90IGNvbnN1bHRlZCB1bmxlc3MgdGhlIHVwcGVyLWxheWVyIHByb3RvY29s IGlzIFRDUCBvcgogICAgICAgICAgICBVRFAuIgogICAgICAgOjo9IHsgZG9jc1N1Yk1ndE9iamVj dHMgNyB9CgogICBkb2NzU3ViTWd0VGNwVWRwRmlsdGVyRW50cnkgT0JKRUNULVRZUEUKICAgICAg IFNZTlRBWCAgRG9jc1N1Yk1ndFRjcFVkcEZpbHRlckVudHJ5CiAgICAgICBNQVgtQUNDRVNTIG5v dC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIkRlZmluZXMgZmlsdGVyaW5nIGNyaXRlcmlhIGZvciBUQ1AgYW5kIFVEUCBoZWFk ZXJzLgogICAgICAgIFBlcnNpc3RlbmNlIG9mIHRoaXMgcm93IGlzIGNvbnRyb2xsZWQgYnkKICAg ICAgICBkb2NzU3ViTWd0UGt0RmlsdGVyU3RvcmFnZVR5cGUuIgoKRXhwaXJlcyAgTWF5IDIwMDMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJ TlRFUk5FVC1EUkFGVCAgICAgIERPQ1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgTUlCICAgICAg IE5vdmVtYmVyIDIwMDIKCiAgICAgICBJTkRFWCAgIHsgZG9jc1N1Yk1ndFBrdEZpbHRlckdyb3Vw LCBkb2NzU3ViTWd0UGt0RmlsdGVySW5kZXggfQogICAgICAgOjo9IHtkb2NzU3ViTWd0VGNwVWRw RmlsdGVyVGFibGUgMSB9CgogICBEb2NzU3ViTWd0VGNwVWRwRmlsdGVyRW50cnkgOjo9IFNFUVVF TkNFCiAgICAgICB7CiAgICAgICBkb2NzU3ViTWd0VGNwVWRwU3JjUG9ydCAgICAgSW5ldFBvcnRO dW1iZXIsCiAgICAgICBkb2NzU3ViTWd0VGNwVWRwRHN0UG9ydCAgICAgSW5ldFBvcnROdW1iZXIs CiAgICAgICBkb2NzU3ViTWd0VGNwRmxhZ1ZhbHVlcyAgICAgQklUUywKICAgICAgIGRvY3NTdWJN Z3RUY3BGbGFnTWFzayAgICAgICBCSVRTLAogICAgICAgZG9jc1N1Yk1ndFRjcFVkcFN0YXR1cyAg ICAgIFJvd1N0YXR1cwogICAgICAgfQoKICAgZG9jc1N1Yk1ndFRjcFVkcFNyY1BvcnQgT0JKRUNU LVRZUEUKICAgICAgIFNZTlRBWCAgSW5ldFBvcnROdW1iZXIKICAgICAgIE1BWC1BQ0NFU1MgcmVh ZC1jcmVhdGUKICAgICAgIFNUQVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiVGhlIHNvdXJjZSBwb3J0IHRvIG1hdGNoLiAgWmVybyBtYXRjaGVzIGFueSB2YWx1ZSBp biB0aGUKICAgICAgIFRDUCBvciBVRFAgc291cmNlIHBvcnQgZmllbGQuIgogICAgICAgREVGVkFM IHsgMCB9CiAgICAgICA6Oj0geyBkb2NzU3ViTWd0VGNwVWRwRmlsdGVyRW50cnkgMSB9CgogICBk b2NzU3ViTWd0VGNwVWRwRHN0UG9ydCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICBJbmV0UG9y dE51bWJlcgogICAgICAgTUFYLUFDQ0VTUyByZWFkLWNyZWF0ZQogICAgICAgU1RBVFVTICBjdXJy ZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgZGVzdGluYXRpb24gcG9ydCB0 byBtYXRjaC4gIFplcm8gbWF0Y2hlcyBhbnkgdmFsdWUgaW4KICAgICAgIHRoZSBUQ1Agb3IgVURQ IGRlc3RpbmF0aW9uIHBvcnQgZmllbGQuIgogICAgICAgREVGVkFMIHsgMCB9CiAgICAgICA6Oj0g eyBkb2NzU3ViTWd0VGNwVWRwRmlsdGVyRW50cnkgMiB9CgogICBkb2NzU3ViTWd0VGNwRmxhZ1Zh bHVlcyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICBCSVRTCiAgICAgICAgICAgICAgICAgICB7 CiAgICAgICAgICAgICAgICAgICB1cmdlbnQoMCksCiAgICAgICAgICAgICAgICAgICBhY2soMSks CiAgICAgICAgICAgICAgICAgICBwdXNoKDIpLAogICAgICAgICAgICAgICAgICAgcmVzZXQoMyks CiAgICAgICAgICAgICAgICAgICBzeW4oNCksCiAgICAgICAgICAgICAgICAgICBmaW4oNSkKICAg ICAgICAgICAgICAgICAgIH0KICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1jcmVhdGUKICAgICAgIFNU QVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIHZhbHVlIG9m IHRoZSBmbGFncyBvZiBpbnRlcmVzdC4gIFRoZSB2YWx1ZSBvZiB0aGlzCiAgICAgICBvYmplY3Qg TVVTVCBhbHdheXMgYmUgYSBzdWJzZXQgKHByb3BlciBvciBvdGhlcndpc2UpIG9mCiAgICAgICBk b2NzU3ViTWd0VGNwRmxhZ01hc2suICBBbiBhdHRlbXB0IHRvIHZpb2xhdGUgdGhpcyBjb25zdHJh aW50CiAgICAgICByZXR1cm5zIGFuIGluY29uc2lzdGVudFZhbHVlLiIKICAgICAgIERFRlZBTCB7 IHt9IH0KICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RUY3BVZHBGaWx0ZXJFbnRyeSAzIH0KCiAgIGRv Y3NTdWJNZ3RUY3BGbGFnTWFzayBPQkpFQ1QtVFlQRQoKRXhwaXJlcyAgTWF5IDIwMDMgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxN10KDApJTlRFUk5F VC1EUkFGVCAgICAgIERPQ1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgTUlCICAgICAgIE5vdmVt YmVyIDIwMDIKCiAgICAgICBTWU5UQVggIEJJVFMKICAgICAgICAgICAgICAgICAgIHsKICAgICAg ICAgICAgICAgICAgIHVyZ2VudCgwKSwKICAgICAgICAgICAgICAgICAgIGFjaygxKSwKICAgICAg ICAgICAgICAgICAgIHB1c2goMiksCiAgICAgICAgICAgICAgICAgICByZXNldCgzKSwKICAgICAg ICAgICAgICAgICAgIHN5big0KSwKICAgICAgICAgICAgICAgICAgIGZpbig1KQogICAgICAgICAg ICAgICAgICAgfQogICAgICAgTUFYLUFDQ0VTUyByZWFkLWNyZWF0ZQogICAgICAgU1RBVFVTICBj dXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGlzIGJpdCBzZXQgaW5kaWNh dGVzIHRoZSBmbGFncyBvZiBpbnRlcmVzdCBpbiB0aGUgVENQCiAgICAgICBoZWFkZXIgZm9yIHRo ZSBwYWNrZXQgdG8gYmUgbWF0Y2hlZC4gIEZvciBleGFtcGxlIHRvIG1hdGNoIGFsbAogICAgICAg cGFja2V0cyB3aGVyZSB0aGUgdXJnZW50IGJpdCBpcyBzZXQsIGJ1dCB0aGF0IGFyZSBub3QgZWl0 aGVyIHN5bgogICAgICAgb3IgZmluLCB0aGUgdmFsdWUgb2YgZG9jc1N1Yk1ndFRjcEZsYWdWYWx1 ZXMgd291bGQgYmUgeyB1cmdlbnQgfSwKICAgICAgIGFuZCB0aGUgdmFsdWUgb2YgdGhpcyBvYmpl Y3Qgd291bGQgYmUgeyB1cmdlbnQsIHN5biwgZmluIH0iCiAgICAgICBERUZWQUwgeyB7fSB9CiAg ICAgICA6Oj0geyBkb2NzU3ViTWd0VGNwVWRwRmlsdGVyRW50cnkgNCB9CgogICBkb2NzU3ViTWd0 VGNwVWRwU3RhdHVzIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggIFJvd1N0YXR1cwogICAgICAg TUFYLUFDQ0VTUyByZWFkLWNyZWF0ZQogICAgICAgU1RBVFVTICBjdXJyZW50CiAgICAgICBERVND UklQVElPTgogICAgICAgICAgICJTdGFuZGFyZCByb3cgb2JqZWN0IGZvciB0aGlzIHRhYmxlLiAg QW55IG9iamVjdCBpbiB0aGUKICAgICAgIGNvbmNlcHR1YWwgcm93IG1heSBiZSBtb2RpZmllZCBy ZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhpcyByb3cgaXMKICAgICAgIGFjdGl2ZSBvciBub3QuIFNp bmNlIGFsbCB3cml0YWJsZSBvYmplY3RzIGluIHRoZSBlbnRyeSBoYXZlCiAgICAgICBERUZWQUxz LCBhIHJvdyBtYXkgYmUgbWFkZSBhY3RpdmUgd2l0aG91dCBzcGVjaWZ5aW5nIGFueSBvdGhlcgog ICAgICAgdmFsdWVzLiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RUY3BVZHBGaWx0ZXJFbnRyeSA1 IH0KCiAgIGRvY3NTdWJNZ3RDbUZpbHRlclRhYmxlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVgg IFNFUVVFTkNFIE9GIERvY3NTdWJNZ3RDbUZpbHRlckVudHJ5CiAgICAgICBNQVgtQUNDRVNTIG5v dC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIkJpbmRzIGZpbHRlciBncm91cHMgdG8gbW9kZW1zLiBUaGlzIHRhYmxlIGlkZW50 aWZpZXMgZm9yCiAgICAgICBlYWNoIG1vZGVtIHRoZSB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBm aWx0ZXIgZ3JvdXBzIHRoYXQgYXBwbHkKICAgICAgIHRvIHBhY2tldHMgZm9yIHRoYXQgbW9kZW0u IFplcm8gaXMgdXNlZCBhcyBhIGRpc3Rpbmd1aXNoZWQgdmFsdWUKICAgICAgIHRvIG1lYW4gbm8g ZmlsdGVyIGdyb3VwLiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RPYmplY3RzIDggfQoKICAgZG9j c1N1Yk1ndENtRmlsdGVyRW50cnkgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgRG9jc1N1Yk1n dENtRmlsdGVyRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNU QVRVUyAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiQmluZHMgYSBmaWx0 ZXIgZ3JvdXAgdG8gZWFjaCBkaXJlY3Rpb24gb2YgdHJhZmZpYyBmb3IgYQogICAgICAgbW9kZW0u IFRoZSBmaWx0ZXJzIGluIHRoaXMgZW50cnkgYXBwbHkgaWYKICAgICAgIGRvY3NTdWJNZ3RDcGVD b250cm9sQWN0aXZlIGlzIHRydWUuIFRoZSBjb250ZW50cyBvZiB0aGlzIGVudHJ5CiAgICAgICBh cmUgbWVhbmluZ2xlc3MgdW5sZXNzIHRoZSBjb3JyZXNwb25kaW5nIGRvY3NJZkNtdHNDbVN0YXR1 c1ZhbHVlCiAgICAgICBpcyByZWdpc3RyYXRpb25Db21wbGV0ZSg2KS4gVGhlIHBlcnNpc3RlbmNl IG9mIHRoaXMgcm93IGlzCgpFeHBpcmVzICBNYXkgMjAwMyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCklOVEVSTkVULURSQUZUICAgICAgRE9D U0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAgICAgTm92ZW1iZXIgMjAwMgoKICAgICAg IGRldGVybWluZWQgc29sZWx5IGJ5IHRoZSBsaWZlc3BhbiBvZiB0aGUgY29ycmVzcG9uZGluZwog ICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRW50cnkgKG5vcm1hbGx5IFN0b3JhZ2VUeXBlPXZvbGF0 aWxlKS4iCiAgICAgICBBVUdNRU5UUyB7IGRvY3NJZkNtdHNDbVN0YXR1c0VudHJ5IH0KICAgICAg IDo6PSB7ZG9jc1N1Yk1ndENtRmlsdGVyVGFibGUgMSB9CgogICBEb2NzU3ViTWd0Q21GaWx0ZXJF bnRyeSA6Oj0gU0VRVUVOQ0UKICAgICAgIHsKICAgICAgIGRvY3NTdWJNZ3RTdWJGaWx0ZXJEb3du c3RyZWFtICAgICAgICBJbnRlZ2VyMzIsCiAgICAgICBkb2NzU3ViTWd0U3ViRmlsdGVyVXBzdHJl YW0gICAgICAgICAgSW50ZWdlcjMyLAogICAgICAgZG9jc1N1Yk1ndENtRmlsdGVyRG93bnN0cmVh bSAgICAgICAgIEludGVnZXIzMiwKICAgICAgIGRvY3NTdWJNZ3RDbUZpbHRlclVwc3RyZWFtICAg ICAgICAgICBJbnRlZ2VyMzIKICAgfQoKICAgZG9jc1N1Yk1ndFN1YkZpbHRlckRvd25zdHJlYW0g T0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgSW50ZWdlcjMyKDAuLjIxNDc0ODM2NDcpCiAgICAg ICBNQVgtQUNDRVNTIHJlYWQtd3JpdGUKICAgICAgIFNUQVRVUyAgY3VycmVudAogICAgICAgREVT Q1JJUFRJT04KICAgICAgICAgICAiVGhlIGZpbHRlciBncm91cCBhcHBsaWVkIHRvIHRyYWZmaWMg ZGVzdGluZWQgZm9yIHN1YnNjcmliZXJzCiAgICAgICBhdHRhY2hlZCB0byB0aGUgcmVmZXJlbmNl ZCBDTS4gIFRoaXMgaXMgc2V0IHVwb24gcm93IGNyZWF0aW9uIHRvCiAgICAgICBlaXRoZXIgdGhl IGRlZmF1bHQgKGRvY3NTdWJNZ3RTdWJGaWx0ZXJEb3duRGVmYXVsdCksIG9yIHRvIHRoZQogICAg ICAgdmFsdWUgaW4gdGhlIHByb3Zpc2lvbmluZyBvYmplY3Qgc2VudCB1cHN0cmVhbSBmcm9tIHRo ZSBDTSB0byB0aGUKICAgICAgIENNVFMgZHVyaW5nIHJlZ2lzdHJhdGlvbi4gVGhlIHZhbHVlIG9m IHRoaXMgb2JqZWN0IGlzIGEgcG9pbnRlcgogICAgICAgaW50byB0aGUgZG9jc1N1Yk1ndFBrdEZp bHRlclRhYmxlIGFuZCByZWZlcnMgdG8gYWxsIGZpbHRlciByb3dzCiAgICAgICB3aXRoIG1hdGNo aW5nIGRvY3NTdWJNZ3RQa3RGaWx0ZXJHcm91cCBpbmRpY2VzLiBJZiB0aGVyZSBhcmUgbm8KICAg ICAgIG1hdGNoaW5nIGZpbHRlciByb3dzIGluIHRoYXQgdGFibGUsIG9yIGlmIHRoaXMgb2JqZWN0 IGlzIHNldCB0bwogICAgICAgemVybywgbm8gZmlsdGVyaW5nIGlzIGFwcGxpZWQgdG8gdHJhZmZp YyBkZXN0aW5lZCB0byBob3N0cwogICAgICAgYXR0YWNoZWQgdG8gdGhpcyBDTS4iCiAgICAgICA6 Oj0geyBkb2NzU3ViTWd0Q21GaWx0ZXJFbnRyeSAxIH0KCiAgIGRvY3NTdWJNZ3RTdWJGaWx0ZXJV cHN0cmVhbSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICBJbnRlZ2VyMzIoMC4uMjE0NzQ4MzY0 NykKICAgICAgIE1BWC1BQ0NFU1MgcmVhZC13cml0ZQogICAgICAgU1RBVFVTICBjdXJyZW50CiAg ICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgZmlsdGVyIGdyb3VwIGFwcGxpZWQgdG8g dHJhZmZpYyBvcmlnaW5hdGluZyBmcm9tCiAgICAgICBzdWJzY3JpYmVycyBhdHRhY2hlZCB0byB0 aGUgcmVmZXJlbmNlZCBDTS4gIFRoaXMgaXMgc2V0IHVwb24gcm93CiAgICAgICBjcmVhdGlvbiB0 byBlaXRoZXIgdGhlIGRlZmF1bHQgKGRvY3NTdWJNZ3RTdWJGaWx0ZXJVcERlZmF1bHQpLCBvcgog ICAgICAgdG8gdGhlIHZhbHVlIGluIHRoZSBwcm92aXNpb25pbmcgb2JqZWN0IHNlbnQgdXBzdHJl YW0gZnJvbSB0aGUgQ00KICAgICAgIHRvIHRoZSBDTVRTLiBUaGUgdmFsdWUgb2YgdGhpcyBvYmpl Y3QgaXMgYSBwb2ludGVyIGludG8gdGhlCiAgICAgICBkb2NzU3ViTWd0UGt0RmlsdGVyVGFibGUg YW5kIHJlZmVycyB0byBhbGwgZmlsdGVyIHJvd3Mgd2l0aAogICAgICAgbWF0Y2hpbmcgZG9jc1N1 Yk1ndFBrdEZpbHRlckdyb3VwIGluZGljZXMuIElmIHRoZXJlIGFyZSBubwogICAgICAgbWF0Y2hp bmcgZmlsdGVyIHJvd3MgaW4gdGhhdCB0YWJsZSwgb3IgaWYgdGhpcyBvYmplY3QgaXMgc2V0IHRv CiAgICAgICB6ZXJvLCBubyBmaWx0ZXJpbmcgaXMgYXBwbGllZCB0byB0cmFmZmljIG9yaWdpbmF0 aW5nIGZyb20KICAgICAgIGhvc3RzIGF0dGFjaGVkIHRvIHRoaXMgQ00uIgogICAgICAgOjo9IHsg ZG9jc1N1Yk1ndENtRmlsdGVyRW50cnkgMiB9CgogICBkb2NzU3ViTWd0Q21GaWx0ZXJEb3duc3Ry ZWFtIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggIEludGVnZXIzMigwLi4yMTQ3NDgzNjQ3KQog ICAgICAgTUFYLUFDQ0VTUyByZWFkLXdyaXRlCiAgICAgICBTVEFUVVMgIGN1cnJlbnQKICAgICAg IERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBmaWx0ZXIgZ3JvdXAgYXBwbGllZCB0byB0cmFm ZmljIGRlc3RpbmVkIGZvciB0aGUKCkV4cGlyZXMgIE1heSAyMDAzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTldCgwKSU5URVJORVQtRFJBRlQgICAg ICBET0NTSVMgU3Vic2NyaWJlciBNYW5hZ2VtZW50IE1JQiAgICAgICBOb3ZlbWJlciAyMDAyCgog ICAgICAgcmVmZXJlbmNlZCBDTSBpdHNlbGYuICBUaGlzIGlzIHNldCB1cG9uIHJvdyBjcmVhdGlv biB0byBlaXRoZXIKICAgICAgIHRoZSBkZWZhdWx0IChkb2NzU3ViTWd0Q21GaWx0ZXJEb3duRGVm YXVsdCksIG9yIHRvIHRoZSB2YWx1ZSBpbgogICAgICAgdGhlIHByb3Zpc2lvbmluZyBvYmplY3Qg c2VudCB1cHN0cmVhbSBmcm9tIHRoZSBDTSB0byB0aGUgQ01UUwogICAgICAgZHVyaW5nIHJlZ2lz dHJhdGlvbi4gVGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGlzIGEgcG9pbnRlciBpbnRvCiAgICAg ICB0aGUgZG9jc1N1Yk1ndFBrdEZpbHRlclRhYmxlIGFuZCByZWZlcnMgdG8gYWxsIGZpbHRlciBy b3dzIHdpdGgKICAgICAgIG1hdGNoaW5nIGRvY3NTdWJNZ3RQa3RGaWx0ZXJHcm91cCBpbmRpY2Vz LiBJZiB0aGVyZSBhcmUgbm8KICAgICAgIG1hdGNoaW5nIGZpbHRlciByb3dzIGluIHRoYXQgdGFi bGUsIG9yIGlmIHRoaXMgb2JqZWN0IGlzIHNldCB0bwogICAgICAgemVybywgbm8gZmlsdGVyaW5n IGlzIGFwcGxpZWQgdG8gdHJhZmZpYyBkZXN0aW5lZCB0byB0aGlzIENNLiIKICAgICAgIDo6PSB7 IGRvY3NTdWJNZ3RDbUZpbHRlckVudHJ5IDMgfQoKICAgZG9jc1N1Yk1ndENtRmlsdGVyVXBzdHJl YW0gT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgSW50ZWdlcjMyKDAuLjIxNDc0ODM2NDcpCiAg ICAgICBNQVgtQUNDRVNTIHJlYWQtd3JpdGUKICAgICAgIFNUQVRVUyAgY3VycmVudAogICAgICAg REVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIGZpbHRlciBncm91cCBhcHBsaWVkIHRvIHRyYWZm aWMgb3JpZ2luYXRpbmcgZnJvbSB0aGUKICAgICAgIHJlZmVyZW5jZWQgQ00gaXRzZWxmLiAgVGhp cyBpcyBzZXQgdXBvbiByb3cgY3JlYXRpb24gdG8gZWl0aGVyCiAgICAgICB0aGUgZGVmYXVsdCAo ZG9jc1N1Yk1ndENtRmlsdGVyVXBEZWZhdWx0KSwgb3IgdG8gdGhlIHZhbHVlIGluCiAgICAgICB0 aGUgcHJvdmlzaW9uaW5nIG9iamVjdCBzZW50IHVwc3RyZWFtIGZyb20gdGhlIENNIHRvIHRoZSBD TVRTLgogICAgICAgVGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGlzIGEgcG9pbnRlciBpbnRvIHRo ZQogICAgICAgZG9jc1N1Yk1ndFBrdEZpbHRlclRhYmxlIGFuZCByZWZlcnMgdG8gYWxsIGZpbHRl ciByb3dzIHdpdGgKICAgICAgIG1hdGNoaW5nIGRvY3NTdWJNZ3RQa3RGaWx0ZXJHcm91cCBpbmRp Y2VzLiBJZiB0aGVyZSBhcmUgbm8KICAgICAgIG1hdGNoaW5nIGZpbHRlciByb3dzIGluIHRoYXQg dGFibGUsIG9yIGlmIHRoaXMgb2JqZWN0IGlzIHNldAogICAgICAgdG8gemVybywgbm8gZmlsdGVy aW5nIGlzIGFwcGxpZWQgdG8gdHJhZmZpYyBvcmlnaW5hdGluZyBmcm9tCiAgICAgICB0aGlzIENN LiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RDbUZpbHRlckVudHJ5IDQgfQoKICAgZG9jc1N1Yk1n dFN1YkZpbHRlckRvd25EZWZhdWx0IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggIEludGVnZXIz MigwLi4yMTQ3NDgzNjQ3KQogICAgICAgTUFYLUFDQ0VTUyByZWFkLXdyaXRlCiAgICAgICBTVEFU VVMgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlVwb24gYSByb3cgY3Jl YXRpb24gaW4gZG9jc1N1Yk1ndENtRmlsdGVyVGFibGUsCiAgICAgICBkb2NzU3ViTWd0U3ViRmls dGVyRG93bnN0cmVhbSBpcyBzZXQgdG8gdGhpcyB2YWx1ZSBpZiBubwogICAgICAgcHJvdmlzaW9u aW5nIG9iamVjdCBpcyBwcmVzZW50IHRvIG92ZXJyaWRlIGl0LiAgVGhpcyBvYmplY3QgaXMKICAg ICAgIHBlcnNpc3RlbnQgYWNyb3NzIENNVFMgcmVib290cy4gIFVwb24gaW5pdGlhbCBDTVRTCiAg ICAgICBpbml0aWFsaXphdGlvbiwgdGhpcyBkZWZhdWx0cyB0byAwLiIKICAgICAgIDo6PSB7IGRv Y3NTdWJNZ3RPYmplY3RzIDkgfQoKICAgZG9jc1N1Yk1ndFN1YkZpbHRlclVwRGVmYXVsdCBPQkpF Q1QtVFlQRQogICAgICAgU1lOVEFYICBJbnRlZ2VyMzIoMC4uMjE0NzQ4MzY0NykKICAgICAgIE1B WC1BQ0NFU1MgcmVhZC13cml0ZQogICAgICAgU1RBVFVTICBjdXJyZW50CiAgICAgICBERVNDUklQ VElPTgogICAgICAgICAgICJVcG9uIGEgcm93IGNyZWF0aW9uIGluIGRvY3NTdWJNZ3RDbUZpbHRl clRhYmxlLAogICAgICAgZG9jc1N1Yk1ndFN1YkZpbHRlclVwc3RyZWFtIGlzIHNldCB0byB0aGlz IHZhbHVlIGlmIG5vCiAgICAgICBwcm92aXNpb25pbmcgb2JqZWN0IGlzIHByZXNlbnQgdG8gb3Zl cnJpZGUgaXQuICBUaGlzIG9iamVjdCBpcwogICAgICAgcGVyc2lzdGVudCBhY3Jvc3MgQ01UUyBy ZWJvb3RzLiAgVXBvbiBpbml0aWFsIENNVFMKICAgICAgIGluaXRpYWxpemF0aW9uLCB0aGlzIGRl ZmF1bHRzIHRvIDAuIgogICAgICAgOjo9IHsgZG9jc1N1Yk1ndE9iamVjdHMgMTAgfQoKICAgZG9j c1N1Yk1ndENtRmlsdGVyRG93bkRlZmF1bHQgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgSW50 ZWdlcjMyKDAuLjIxNDc0ODM2NDcpCgpFeHBpcmVzICBNYXkgMjAwMyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCklOVEVSTkVULURSQUZUICAg ICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAgICAgTm92ZW1iZXIgMjAwMgoK ICAgICAgIE1BWC1BQ0NFU1MgcmVhZC13cml0ZQogICAgICAgU1RBVFVTICBjdXJyZW50CiAgICAg ICBERVNDUklQVElPTgogICAgICAgICAgICJVcG9uIGEgcm93IGNyZWF0aW9uIGluIGRvY3NTdWJN Z3RDbUZpbHRlclRhYmxlLAogICAgICAgZG9jc1N1Yk1ndENtRmlsdGVyRG93bnN0cmVhbSBpcyBz ZXQgdG8gdGhpcyB2YWx1ZSBpZiBubwogICAgICAgcHJvdmlzaW9uaW5nIG9iamVjdCBpcyBwcmVz ZW50IHRvIG92ZXJyaWRlIGl0LiAgVGhpcyBvYmplY3QgaXMKICAgICAgIHBlcnNpc3RlbnQgYWNy b3NzIENNVFMgcmVib290cy4gIFVwb24gaW5pdGlhbCBDTVRTCiAgICAgICBpbml0aWFsaXphdGlv biwgdGhpcyBkZWZhdWx0cyB0byAwLiIKICAgICAgIDo6PSB7IGRvY3NTdWJNZ3RPYmplY3RzIDEx IH0KCiAgIGRvY3NTdWJNZ3RDbUZpbHRlclVwRGVmYXVsdCBPQkpFQ1QtVFlQRQogICAgICAgU1lO VEFYICBJbnRlZ2VyMzIoMC4uMjE0NzQ4MzY0NykKICAgICAgIE1BWC1BQ0NFU1MgcmVhZC13cml0 ZQogICAgICAgU1RBVFVTICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJV cG9uIGEgcm93IGNyZWF0aW9uIGluIGRvY3NTdWJNZ3RDbUZpbHRlclRhYmxlLAogICAgICAgZG9j c1N1Yk1ndENtRmlsdGVyVXBzdHJlYW0gaXMgc2V0IHRvIHRoaXMgdmFsdWUgaWYgbm8KICAgICAg IHByb3Zpc2lvbmluZyBvYmplY3QgaXMgcHJlc2VudCB0byBvdmVycmlkZSBpdC4gIFRoaXMgb2Jq ZWN0IGlzCiAgICAgICBwZXJzaXN0ZW50IGFjcm9zcyBDTVRTIHJlYm9vdHMuICBVcG9uIGluaXRp YWwgQ01UUwogICAgICAgaW5pdGlhbGl6YXRpb24sIHRoaXMgZGVmYXVsdHMgdG8gMC4iCiAgICAg ICA6Oj0geyBkb2NzU3ViTWd0T2JqZWN0cyAxMiB9CgoKICAgZG9jc1N1Yk1ndENvbmZvcm1hbmNl IE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IGRvY3NTdWJNZ3QgMiB9CiAgIGRvY3NTdWJNZ3RDb21w bGlhbmNlcyBPQkpFQ1QgSURFTlRJRklFUiA6Oj0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHsgZG9jc1N1Yk1ndENvbmZvcm1hbmNlIDEgfQogICBkb2NzU3ViTWd0 R3JvdXBzIE9CSkVDVCBJREVOVElGSUVSICAgICAgOjo9CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB7IGRvY3NTdWJNZ3RDb25mb3JtYW5jZSAyIH0KCiAgIGRvY3NT dWJNZ3RCYXNpY0NvbXBsaWFuY2UgTU9EVUxFLUNPTVBMSUFOQ0UKICAgICAgIFNUQVRVUyAgICAg IGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBjb21wbGlhbmNlIHN0 YXRlbWVudCBmb3IgQ01UUyBkZXZpY2VzIHRoYXQgaW1wbGVtZW50CiAgICAgICBDTVRTIGNlbnRy aWMgc3Vic2NyaWJlciBtYW5hZ2VtZW50LiIKCiAgIE1PRFVMRQoKICAgTUFOREFUT1JZLUdST1VQ UyB7CiAgICAgICAgICAgZG9jc1N1Yk1ndEdyb3VwCiAgICAgICAgICAgfQoKICAgT0JKRUNUIGRv Y3NTdWJNZ3RDcGVDb250cm9sTWF4Q3BlSXAKICAgICAgIFNZTlRBWCBJbnRlZ2VyMzIoMC4uMTYp CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5 IHJlcXVpcmVkIHRvIHN1cHBvcnQgdXAgdG8KICAgICAgICAgICAgc2l4dGVlbiBhZGRyZXNzZXMg cGVyIG1vZGVtLiIKCiAgIE9CSkVDVCBkb2NzU3ViTWd0Q3BlTWF4SXBEZWZhdWx0CiAgICAgICBT WU5UQVggSW50ZWdlcjMyKDAuLjE2KQogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiQW4g aW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IHVwIHRvCiAgICAgICAg ICAgIHNpeHRlZW4gYWRkcmVzc2VzIHBlciBtb2RlbS4iCgoKRXhwaXJlcyAgTWF5IDIwMDMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJTlRF Uk5FVC1EUkFGVCAgICAgIERPQ1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgTUlCICAgICAgIE5v dmVtYmVyIDIwMDIKCiAgIE9CSkVDVCBkb2NzU3ViTWd0Q3BlSXBBZGRyZXNzVHlwZQogICAgICAg U1lOVEFYIEluZXRBZGRyZXNzVHlwZSB7IGlwdjQoMSkgfQogICAgICAgREVTQ1JJUFRJT04KICAg ICAgICAgICAiQW4gaW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IElQ djQKICAgICAgICAgICAgYWRkcmVzc2VzLiIKCiAgIE9CSkVDVCBkb2NzU3ViTWd0Q3BlSXBBZGRy CiAgICAgICBTWU5UQVggIEluZXRBZGRyZXNzIChTSVpFKDUpKQogICAgICAgREVTQ1JJUFRJT04K ICAgICAgICAgICAiQW4gaW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0 IElQdjQKICAgICAgICAgICAgYWRkcmVzc2VzLiIKCiAgIE9CSkVDVCBkb2NzU3ViTWd0UGt0Rmls dGVyQWRkclR5cGUKICAgICAgIFNZTlRBWCBJbmV0QWRkcmVzc1R5cGUgeyBpcHY0KDEpIH0KICAg ICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVx dWlyZWQgdG8gc3VwcG9ydCBJUHY0CiAgICAgICAgICAgIGFkZHJlc3Nlcy4iCgogICBPQkpFQ1Qg ZG9jc1N1Yk1ndFBrdEZpbHRlclNyY0FkZHIKICAgICAgIFNZTlRBWCBJbmV0QWRkcmVzcyAoU0la RSg1KSkKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlz IG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0CiAgICAgICAgICAgIGFkZHJlc3Nlcy4iCgog ICBPQkpFQ1QgZG9jc1N1Yk1ndFBrdEZpbHRlclNyY01hc2sKICAgICAgIFNZTlRBWCBJbmV0QWRk cmVzc1ByZWZpeExlbmd0aCgwLi4zMikKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFu IGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0CiAgICAgICAg ICAgIGFkZHJlc3Nlcy4iCgogICBPQkpFQ1QgZG9jc1N1Yk1ndFBrdEZpbHRlckRzdEFkZHIKICAg ICAgIFNZTlRBWCBJbmV0QWRkcmVzcyAoU0laRSg1KSkKICAgICAgIERFU0NSSVBUSU9OCiAgICAg ICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0 CiAgICAgICAgICAgIGFkZHJlc3Nlcy4iCgogICBPQkpFQ1QgZG9jc1N1Yk1ndFBrdEZpbHRlckRz dE1hc2sKICAgICAgIFNZTlRBWCBJbmV0QWRkcmVzc1ByZWZpeExlbmd0aCgwLi4zMikKICAgICAg IERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWly ZWQgdG8gc3VwcG9ydCBJUHY0CiAgICAgICAgICAgIGFkZHJlc3Nlcy4iCgogICBPQkpFQ1QgZG9j c1N1Yk1ndFBrdEZpbHRlclN0b3JhZ2VUeXBlCiAgICAgICBTWU5UQVggU3RvcmFnZVR5cGUgeyBu b25Wb2xhdGlsZSgzKSB9CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJBbiBpbXBsZW1l bnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgbm9udm9sYXRpbGUKICAgICAgICAg ICAgc3RvcmFnZSBvZiBmaWx0ZXIgZW50cmllcy4iCgogICBPQkpFQ1QgZG9jc1N1Yk1ndFN1YkZp bHRlckRvd25zdHJlYW0KICAgICAgIFNZTlRBWCAgSW50ZWdlcjMyKDAuLjMwKQogICAgICAgREVT Q1JJUFRJT04KICAgICAgICAgICAiQW4gaW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0 byBzdXBwb3J0IHRoaXJ0eQogICAgICAgZmlsdGVyIGdyb3Vwcy4iCgpFeHBpcmVzICBNYXkgMjAw MyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDIyXQoM CklOVEVSTkVULURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAg ICAgTm92ZW1iZXIgMjAwMgoKICAgT0JKRUNUIGRvY3NTdWJNZ3RTdWJGaWx0ZXJVcHN0cmVhbQog ICAgICAgU1lOVEFYICBJbnRlZ2VyMzIoMC4uMzApCiAgICAgICBERVNDUklQVElPTgogICAgICAg ICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhpcnR5 CiAgICAgICBmaWx0ZXIgZ3JvdXBzLiIKCiAgIE9CSkVDVCBkb2NzU3ViTWd0Q21GaWx0ZXJEb3du c3RyZWFtCiAgICAgICBTWU5UQVggIEludGVnZXIzMigwLi4zMCkKICAgICAgIERFU0NSSVBUSU9O CiAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9y dCB0aGlydHkKICAgICAgIGZpbHRlciBncm91cHMuIgoKICAgT0JKRUNUIGRvY3NTdWJNZ3RDbUZp bHRlclVwc3RyZWFtCiAgICAgICBTWU5UQVggIEludGVnZXIzMigwLi4zMCkKICAgICAgIERFU0NS SVBUSU9OCiAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8g c3VwcG9ydCB0aGlydHkKICAgICAgIGZpbHRlciBncm91cHMuIgoKICAgT0JKRUNUIGRvY3NTdWJN Z3RTdWJGaWx0ZXJEb3duRGVmYXVsdAogICAgICAgU1lOVEFYICBJbnRlZ2VyMzIoMC4uMzApCiAg ICAgICBERVNDUklQVElPTgogICAgICAgICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJl cXVpcmVkIHRvIHN1cHBvcnQgdGhpcnR5CiAgICAgICBmaWx0ZXIgZ3JvdXBzLiIKCiAgIE9CSkVD VCBkb2NzU3ViTWd0U3ViRmlsdGVyVXBEZWZhdWx0CiAgICAgICBTWU5UQVggIEludGVnZXIzMigw Li4zMCkKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlz IG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGlydHkKICAgICAgIGZpbHRlciBncm91cHMuIgoK ICAgT0JKRUNUIGRvY3NTdWJNZ3RDbUZpbHRlckRvd25EZWZhdWx0CiAgICAgICBTWU5UQVggIElu dGVnZXIzMigwLi4zMCkKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGltcGxlbWVu dGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGlydHkKICAgICAgIGZpbHRlciBn cm91cHMuIgoKICAgT0JKRUNUIGRvY3NTdWJNZ3RDbUZpbHRlclVwRGVmYXVsdAogICAgICAgU1lO VEFYICBJbnRlZ2VyMzIoMC4uMzApCiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJBbiBp bXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhpcnR5CiAgICAgICBm aWx0ZXIgZ3JvdXBzLiIKCiAgICAgICAgICAgOjo9IHsgZG9jc1N1Yk1ndENvbXBsaWFuY2VzIDEg fQoKICAgZG9jc1N1Yk1ndEdyb3VwIE9CSkVDVC1HUk9VUAogICAgICAgICAgIE9CSkVDVFMgewog ICAgICAgICAgICAgICBkb2NzU3ViTWd0Q3BlQ29udHJvbE1heENwZUlwLAogICAgICAgICAgICAg ICBkb2NzU3ViTWd0Q3BlQ29udHJvbEFjdGl2ZSwKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndENw ZUNvbnRyb2xMZWFybmFibGUsCiAgICAgICAgICAgICAgIGRvY3NTdWJNZ3RDcGVDb250cm9sUmVz ZXQsCiAgICAgICAgICAgICAgIGRvY3NTdWJNZ3RDcGVNYXhJcERlZmF1bHQsCiAgICAgICAgICAg ICAgIGRvY3NTdWJNZ3RDcGVBY3RpdmVEZWZhdWx0LAogICAgICAgICAgICAgICBkb2NzU3ViTWd0 Q3BlTGVhcm5hYmxlRGVmYXVsdCwKCkV4cGlyZXMgIE1heSAyMDAzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwKSU5URVJORVQtRFJBRlQgICAg ICBET0NTSVMgU3Vic2NyaWJlciBNYW5hZ2VtZW50IE1JQiAgICAgICBOb3ZlbWJlciAyMDAyCgog ICAgICAgICAgICAgICBkb2NzU3ViTWd0Q3BlSXBBZGRyZXNzVHlwZSwKICAgICAgICAgICAgICAg ZG9jc1N1Yk1ndENwZUlwQWRkciwKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndENwZUlwTGVhcm5l ZCwKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndFBrdEZpbHRlckFkZHJUeXBlLAogICAgICAgICAg ICAgICBkb2NzU3ViTWd0UGt0RmlsdGVyU3JjQWRkciwKICAgICAgICAgICAgICAgZG9jc1N1Yk1n dFBrdEZpbHRlclNyY01hc2ssCiAgICAgICAgICAgICAgIGRvY3NTdWJNZ3RQa3RGaWx0ZXJEc3RB ZGRyLAogICAgICAgICAgICAgICBkb2NzU3ViTWd0UGt0RmlsdGVyRHN0TWFzaywKICAgICAgICAg ICAgICAgZG9jc1N1Yk1ndFBrdEZpbHRlclVscCwKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndFBr dEZpbHRlclRvc1ZhbHVlLAogICAgICAgICAgICAgICBkb2NzU3ViTWd0UGt0RmlsdGVyVG9zTWFz aywKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndFBrdEZpbHRlckFjdGlvbiwKICAgICAgICAgICAg ICAgZG9jc1N1Yk1ndFBrdEZpbHRlck1hdGNoZXMsCiAgICAgICAgICAgICAgIGRvY3NTdWJNZ3RQ a3RGaWx0ZXJTdGF0dXMsCiAgICAgICAgICAgICAgIGRvY3NTdWJNZ3RQa3RGaWx0ZXJTdG9yYWdl VHlwZSwKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndFRjcFVkcFNyY1BvcnQsCiAgICAgICAgICAg ICAgIGRvY3NTdWJNZ3RUY3BVZHBEc3RQb3J0LAogICAgICAgICAgICAgICBkb2NzU3ViTWd0VGNw RmxhZ1ZhbHVlcywKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndFRjcEZsYWdNYXNrLAogICAgICAg ICAgICAgICBkb2NzU3ViTWd0VGNwVWRwU3RhdHVzLAogICAgICAgICAgICAgICBkb2NzU3ViTWd0 U3ViRmlsdGVyRG93bnN0cmVhbSwKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndFN1YkZpbHRlclVw c3RyZWFtLAogICAgICAgICAgICAgICBkb2NzU3ViTWd0Q21GaWx0ZXJEb3duc3RyZWFtLAogICAg ICAgICAgICAgICBkb2NzU3ViTWd0Q21GaWx0ZXJVcHN0cmVhbSwKICAgICAgICAgICAgICAgZG9j c1N1Yk1ndFN1YkZpbHRlckRvd25EZWZhdWx0LAogICAgICAgICAgICAgICBkb2NzU3ViTWd0U3Vi RmlsdGVyVXBEZWZhdWx0LAogICAgICAgICAgICAgICBkb2NzU3ViTWd0Q21GaWx0ZXJEb3duRGVm YXVsdCwKICAgICAgICAgICAgICAgZG9jc1N1Yk1ndENtRmlsdGVyVXBEZWZhdWx0CiAgICAgICAg ICAgICAgIH0KICAgICAgICAgICAgICAgU1RBVFVTICAgICAgY3VycmVudAogICAgICAgICAgICAg ICBERVNDUklQVElPTgogICAgICAgICAgICAgICAgICAgIlRoZSBvYmplY3RzIHVzZSB0byBtYW5h Z2VkIGhvc3QtYmFzZWQgY2FibGUgbW9kZW1zCiAgICAgICAgICAgICAgICAgICB2aWEgYSBzZXQg b2YgQ01UUyBlbmZvcmNlZCBjb250cm9scy4iCiAgICAgICAgICAgICAgIDo6PSB7ICBkb2NzU3Vi TWd0R3JvdXBzIDEgfQoKICAgRU5ECgo0LiBBY2tub3dsZWRnbWVudHMKCiAgIFRoaXMgZG9jdW1l bnQgaXMgYmFzZWQgb24gd29yayBieSBNaWNoYWVsIFN0LkpvaG5zLCB0aGVuIGF0CiAgIEV4Y2l0 ZUBIb21lLiAgVGhhbmtzIHRvIEd1ZW50ZXIgUm9lY2sgYW5kIEp1bGllIE1jR3JheSBmb3IgcmV2 aWV3aW5nCiAgIGVhcmx5IGRyYWZ0cy4gIFRoaXMgZHJhZnQgYmVuZWZpdHRlZCBmcm9tIGV4dGVu c2l2ZSByZXZpZXcgYnkgQmVydAogICBXaWpuZW4uCgo1LiBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgW1JGQzE5MDVdCiAgICAgICAgQ2FzZSwgSi4sIE1jQ2xvZ2hyaWUsIEsuLCBSb3NlLCBNLiBh bmQgUy4gV2FsZGJ1c3NlciwgIlByb3RvY29sCiAgICAgICAgT3BlcmF0aW9ucyBmb3IgVmVyc2lv biAyIG9mIHRoZSBTaW1wbGUgTmV0d29yayBNYW5hZ2VtZW50CiAgICAgICAgUHJvdG9jb2wgKFNO TVB2MikiLCBSRkMgMTkwNSwgSmFudWFyeSAxOTk2LgoKICAgW1JGQzE5MDZdCiAgICAgICAgQ2Fz ZSwgSi4sIE1jQ2xvZ2hyaWUsIEsuLCBSb3NlLCBNLiBhbmQgUy4gV2FsZGJ1c3NlciwgIlRyYW5z cG9ydAoKRXhwaXJlcyAgTWF5IDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSAyNF0KDApJTlRFUk5FVC1EUkFGVCAgICAgIERPQ1NJUyBTdWJzY3Jp YmVyIE1hbmFnZW1lbnQgTUlCICAgICAgIE5vdmVtYmVyIDIwMDIKCiAgICAgICAgTWFwcGluZ3Mg Zm9yIFZlcnNpb24gMiBvZiB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbAog ICAgICAgIChTTk1QdjIpIiwgUkZDIDE5MDYsIEphbnVhcnkgMTk5Ni4KCiAgIFtSRkMyNTcxXQog ICAgICAgIEhhcnJpbmd0b24sIEQuLCBQcmVzdWhuLCBSLiBhbmQgQi4gV2lqbmVuLCAiQW4gQXJj aGl0ZWN0dXJlCiAgICAgICAgZm9yIERlc2NyaWJpbmcgU05NUCBNYW5hZ2VtZW50IEZyYW1ld29y a3MiLCBSRkMgMjU3MSwgQXByaWwKICAgICAgICAxOTk5LgoKICAgW1JGQzI1NzJdCiAgICAgICAg Q2FzZSwgSi4sIEhhcnJpbmd0b24gRC4sIFByZXN1aG4gUi4gYW5kIEIuIFdpam5lbiwgIk1lc3Nh Z2UKICAgICAgICBQcm9jZXNzaW5nIGFuZCBEaXNwYXRjaGluZyBmb3IgdGhlIFNpbXBsZSBOZXR3 b3JrIE1hbmFnZW1lbnQKICAgICAgICBQcm90b2NvbCAoU05NUCkiLCBSRkMgMjU3MiwgQXByaWwg MTk5OS4KCiAgIFtSRkMyNTczXQogICAgICAgIExldmksIEQuLCBNZXllciwgUC4gYW5kIEIuIFN0 ZXdhcnQsICJTTk1QIEFwcGxpY2F0aW9ucyIsIFJGQwogICAgICAgIDI1NzMsIEFwcmlsIDE5OTku CgogICBbUkZDMjU3NF0KICAgICAgICBCbHVtZW50aGFsLCBVLiBhbmQgQi4gV2lqbmVuLCAiVXNl ci1iYXNlZCBTZWN1cml0eSBNb2RlbCAoVVNNKQogICAgICAgIGZvciB2ZXJzaW9uIDMgb2YgdGhl IFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQgUHJvdG9jb2wKICAgICAgICAoU05NUHYzKSIsIFJG QyAyNTc0LCBBcHJpbCAxOTk5LgoKICAgW1JGQzI1NzVdCiAgICAgICAgV2lqbmVuLCBCLiwgUHJl c3VobiwgUi4gYW5kIEsuIE1jQ2xvZ2hyaWUsICJWaWV3LWJhc2VkIEFjY2VzcwogICAgICAgIENv bnRyb2wgTW9kZWwgKFZBQ00pIGZvciB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90 b2NvbAogICAgICAgIChTTk1QKSIsIFJGQyAyNTc1LCBBcHJpbCAxOTk5LgoKICAgW1JGQzI1Nzhd CiAgICAgICAgTWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuIGFuZCBKLiBTY2hvZW53YWVsZGVy LCAiU3RydWN0dXJlIG9mCiAgICAgICAgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBmb3IgVmVyc2lv biAyIChTTUl2MikiLCBTVEQgNTgsIFJGQyAyNTc4LAogICAgICAgIEFwcmlsIDE5OTkuCgogICBb UkZDMjU3OV0KICAgICAgICBNY0Nsb2docmllLCBLLiwgUGVya2lucywgRC4gYW5kIEouIFNjaG9l bndhZWxkZXIsICJUZXh0dWFsCiAgICAgICAgQ29udmVudGlvbnMgZm9yIFNNSXYyIiwgU1REIDU4 LCBSRkMgMjU3OSwgQXByaWwgMTk5OS4KCiAgIFtSRkMyNTgwXQogICAgICAgIE1jQ2xvZ2hyaWUs IEsuLCBQZXJraW5zLCBELiBhbmQgSi4gU2Nob2Vud2FlbGRlciwgIkNvbmZvcm1hbmNlCiAgICAg ICAgU3RhdGVtZW50cyBmb3IgU01JdjIiLCBTVEQgNTgsIFJGQyAyNTgwLCBBcHJpbCAxOTk5LgoK ICAgW0RPQ1NSRkldCiAgICAgICAgIkRhdGEtT3Zlci1DYWJsZSBTZXJ2aWNlIEludGVyZmFjZSBT cGVjaWZpY2F0aW9uczogQ2FibGUgTW9kZW0KICAgICAgICBSYWRpbyBGcmVxdWVuY3kgSW50ZXJm YWNlIFNwZWNpZmljYXRpb24gU1AtUkZJdjIuMC1JMDItMDIwNjE3IiwKICAgICAgICBET0NTSVMs IEp1bmUgMjAwMiwgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuY2FibGVtb2RlbS5jb20vLgoKICAg W1JGQzI2NjldCiAgICAgICAgU3RKb2hucywgTS4gLCAiQ2FibGUgRGV2aWNlIE1hbmFnZW1lbnQg SW5mb3JtYXRpb24gQmFzZSBmb3IKICAgICAgICBET0NTSVMgQ29tcGxpYW50IENhYmxlIE1vZGVt cyBhbmQgQ2FibGUgTW9kZW0gVGVybWluYXRpb24KICAgICAgICBTeXN0ZW1zIiwgUkZDMjY2OSwg QXVndXN0IDE5OTkuCgogICBbUkZDMjY3MF0KICAgICAgICBTdEpvaG5zLCBNLiAsICJSYWRpbyBG cmVxdWVuY3kgKFJGKSBJbnRlcmZhY2UgTWFuYWdlbWVudAogICAgICAgIEluZm9ybWF0aW9uIEJh c2UgZm9yIE1DTlMvRE9DU0lTIGNvbXBsaWFudCBSRiBpbnRlcmZhY2VzIiwKCkV4cGlyZXMgIE1h eSAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MjVdCgwKSU5URVJORVQtRFJBRlQgICAgICBET0NTSVMgU3Vic2NyaWJlciBNYW5hZ2VtZW50IE1J QiAgICAgICBOb3ZlbWJlciAyMDAyCgogICAgICAgIFJGQzI2NzAsIEF1Z3VzdCAxOTk5LgoKNi4g SW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzExNTVdCiAgICAgICAgUm9zZSwgTS4gYW5k IEsuIE1jQ2xvZ2hyaWUsICJTdHJ1Y3R1cmUgYW5kIElkZW50aWZpY2F0aW9uIG9mCiAgICAgICAg TWFuYWdlbWVudCBJbmZvcm1hdGlvbiBmb3IgVENQL0lQLWJhc2VkIEludGVybmV0cyIsIFNURCAx NiwgUkZDCiAgICAgICAgMTE1NSwgTWF5IDE5OTAuCgogICBbUkZDMTE1N10KICAgICAgICBDYXNl LCBKLiwgRmVkb3IsIE0uLCBTY2hvZmZzdGFsbCwgTS4gYW5kIEouIERhdmluLCAiU2ltcGxlCiAg ICAgICAgTWFuYWdlbWVudCBQcm90b2NvbCIsIFNURCAxNSwgUkZDIDExNTcsIE1heSAxOTkwLgoK ICAgW1JGQzEyMTJdCiAgICAgICAgUm9zZSwgTS4gYW5kIEsuIE1jQ2xvZ2hyaWUsICJDb25jaXNl IE1JQiBEZWZpbml0aW9ucyIsIFNURCAxNiwKICAgICAgICBSRkMgMTIxMiwgTWFyY2ggMTk5MS4K CiAgIFtSRkMxMjE1XQogICAgICAgIFJvc2UsIE0uLCAiQSBDb252ZW50aW9uIGZvciBEZWZpbmlu ZyBUcmFwcyBmb3IgdXNlIHdpdGggdGhlCiAgICAgICAgU05NUCIsIFJGQyAxMjE1LCBNYXJjaCAx OTkxLgoKICAgW1JGQzE5MDFdCiAgICAgICAgQ2FzZSwgSi4sIE1jQ2xvZ2hyaWUsIEsuLCBSb3Nl LCBNLiBhbmQgUy4gV2FsZGJ1c3NlciwKICAgICAgICAiSW50cm9kdWN0aW9uIHRvIENvbW11bml0 eS1iYXNlZCBTTk1QdjIiLCBSRkMgMTkwMSwgSmFudWFyeQogICAgICAgIDE5OTYuCgogICBbUkZD MjU3MF0KICAgICAgICBDYXNlLCBKLiwgTXVuZHksIFIuLCBQYXJ0YWluLCBELiwgYW5kIEIuIFN0 ZXdhcnQsCiAgICAgICAgIkludHJvZHVjdGlvbiB0byBWZXJzaW9uIDMgb2YgdGhlIEludGVybmV0 LXN0YW5kYXJkIE5ldHdvcmsKICAgICAgICBNYW5hZ2VtZW50IEZyYW1ld29yayIsIFJGQzI1NzAs IEFwcmlsIDE5OTkuCgogICBbUkZDMTg1OF0KICAgICAgICBaaWVtYmEsIEcuLCBSZWVkLCBELiwg YW5kIFAuIFRyYWluYSwgIlNlY3VyaXR5IENvbnNpZGVyYXRpb25zCiAgICAgICAgZm9yIElQIEZy YWdtZW50IEZpbHRlcmluZyIsIFJGQzE4NTgsIE9jdG9iZXIgMTk5NS4KCiAgIFtSRkMyMTM4XQog ICAgICAgIE1pbGxlciwgSS4sICJQcm90ZWN0aW9uIGFnYWluc3QgYSBWYXJpYW50IG9mIHRoZSBU aW55IEZyYWdtZW50CiAgICAgICAgQXR0YWNrIi4gUkZDMzEyOCwgSnVuZSAyMDAxLgoKICAgW0RP Q1NCUEldCiAgICAgICAgIkRhdGEtT3Zlci1DYWJsZSBTZXJ2aWNlIEludGVyZmFjZSBTcGVjaWZp Y2F0aW9uczogQmFzZWxpbmUKICAgICAgICBQcml2YWN5IFBsdXMgSW50ZXJmYWNlIFNwZWNpZmlj YXRpb24gU1AtQlBJKy1JMDktMDIwODMwIiwKICAgICAgICBET0NTSVMsIEF1Z3VzdCAyMDAyLCBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5jYWJsZW1vZGVtLmNvbS8uCgo3LiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucwoKICAgVGhpcyBNSUIgaXMgaW50ZW5kZWQgdG8gbGltaXQgY2VydGFpbiBraW5k cyBvZiBuZXR3b3JrIGJlaGF2aW9yIGJ5CiAgIHN1YnNjcmliZXIgaG9zdHMgYXR0YWNoZWQgdG8g Y2FibGUgbW9kZW1zLCBpbmNsdWRpbmcsIGZvciBleGFtcGxlLCBJUAogICBzcG9vZmluZy4gVGhl c2UgbGltaXRhdGlvbnMgbWF5IGJlIGNvbXByb21pc2VkLCBob3dldmVyLCBpZiB0aGUgY2FibGUK ICAgbW9kZW0ncyBpZGVudGl0eSBvciByZWdpc3RyYXRpb24gcHJvY2VzcyBpcyBzcG9vZmVkLiBU aGUgRE9DU0lTIFJGSQogICBhbmQgcHJpdmFjeSBzcGVjaWZpY2F0aW9ucyBbRE9DU1JGSV0gYW5k IFtET0NTQlBJXSBkZWZpbmUgYSBudW1iZXIgb2YKICAgbWVjaGFuaXNtcyBmb3IgYXNzdXJpbmcg bW9kZW0gaWRlbnRpdHkuCgoKRXhwaXJlcyAgTWF5IDIwMDMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyNl0KDApJTlRFUk5FVC1EUkFGVCAgICAgIERP Q1NJUyBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgTUlCICAgICAgIE5vdmVtYmVyIDIwMDIKCiAgIFRo ZSBmaWx0ZXJpbmcgbWVjaGFuaXNtIGRlZmluZWQgaGVyZSBjYW4gYmUgZGVmZWF0ZWQgdGhyb3Vn aCB0aGUKICAgInRpbnkgZnJhZ21lbnQiIGFuZCAib3ZlcmxhcHBpbmcgZnJhZ21lbnQiIGF0dGFj a3MgaWYgdGhlCiAgIHJlY29tbWVuZGF0aW9ucyBpbiBzZWN0aW9uIDIuMi42IGFyZSBvbWl0dGVk LiBTZWUgW1JGQzE4NThdIGFuZAogICBbUkZDMjEzOF0gZm9yIGRpc2N1c3Npb24gb2YgdGhlc2Ug YXR0YWNrcy4KCiAgIFRoZXJlIGFyZSBhIG51bWJlciBvZiBtYW5hZ2VtZW50IG9iamVjdHMgZGVm aW5lZCBpbiB0aGlzIE1JQiB0aGF0CiAgIGhhdmUgYSBNQVgtQUNDRVNTIGNsYXVzZSBvZiByZWFk LXdyaXRlIGFuZC9vciByZWFkLWNyZWF0ZS4gIFN1Y2gKICAgb2JqZWN0cyBtYXkgYmUgY29uc2lk ZXJlZCBzZW5zaXRpdmUgb3IgdnVsbmVyYWJsZSBpbiBzb21lIG5ldHdvcmsKICAgZW52aXJvbm1l bnRzLiAgVGhlIHN1cHBvcnQgZm9yIFNFVCBvcGVyYXRpb25zIGluIGEgbm9uLXNlY3VyZQogICBl bnZpcm9ubWVudCB3aXRob3V0IHByb3BlciBwcm90ZWN0aW9uIGNhbiBoYXZlIGEgbmVnYXRpdmUg ZWZmZWN0IG9uCiAgIG5ldHdvcmsgb3BlcmF0aW9ucy4KCiAgIFVuYXV0aG9yaXplZCBTRVRzIHRv IHRoaXMgTUlCIGNhbiBwZXJtaXQgdHdvIG1ham9yIHNlY3VyaXR5IHByb2JsZW1zCiAgIHdpdGgg cHVibGljIGNhYmxlIG5ldHdvcmsgb3BlcmF0aW9uOiBJUCBhZGRyZXNzIHNwb29maW5nLCBhbmQg ZGVmZWF0CiAgIG9mIG9wZXJhdG9yLWRlZmluZWQgcGFja2V0IGZpbHRlcmluZy4KCiAgIFRoZSBm b2xsb3dpbmcgb2JqZWN0cywgaWYgU0VUIG1hbGljaW91c2x5LCB3b3VsZCBldmFkZSBjb250cm9s cyBvbgogICBhZGRyZXNzIHNwb29maW5nOgoKICAgICAgIGRvY3NTdWJNZ3RDcGVDb250cm9sTWF4 Q3BlSXAKICAgICAgIGRvY3NTdWJNZ3RDcGVDb250cm9sQWN0aXZlCiAgICAgICBkb2NzU3ViTWd0 Q3BlQ29udHJvbExlYXJuYWJsZQogICAgICAgZG9jc1N1Yk1ndENwZUNvbnRyb2xSZXNldAogICAg ICAgZG9jc1N1Yk1ndENwZU1heElwRGVmYXVsdAogICAgICAgZG9jc1N1Yk1ndENwZUFjdGl2ZURl ZmF1bHQKICAgICAgIGRvY3NTdWJNZ3RDcGVMZWFybmFibGVEZWZhdWx0CgogICBBbGwgd3JpdGFi bGUgb2JqZWN0cyBpbiBkb2NzU3ViTWd0UGt0RmlsdGVyVGFibGUgYW5kCiAgIGRvY3NTdWJNZ3RU Y3BVZHBGaWx0ZXJUYWJsZSBzaGFyZSB0aGUgcG90ZW50aWFsLCBpZiBTRVQgbWFsaWNpb3VzbHks CiAgIHRvIHBlcm1pdCB1bndhbnRlZCBhbmQgZGlzcnVwdGl2ZSB0cmFmZmljIHRvIGVudGVyIHRo ZSBwdWJsaWMgZGF0YQogICBuZXR3b3JrLCBhcyB3ZWxsIGFzIHRvIGJlIHRyYW5zbWl0dGVkIHRv IHN1YnNjcmliZXJzLiBUaGUgZm9sbG93aW5nCiAgIG9iamVjdHMgY291bGQgYWxzbyBwZXJtaXQg cGFja2V0IGZpbHRlcmluZyB0byBiZSBkZWZlYXRlZDoKCiAgICAgICBkb2NzU3ViTWd0U3ViRmls dGVyRG93bnN0cmVhbQogICAgICAgZG9jc1N1Yk1ndFN1YkZpbHRlclVwc3RyZWFtCiAgICAgICBk b2NzU3ViTWd0Q21GaWx0ZXJEb3duc3RyZWFtCiAgICAgICBkb2NzU3ViTWd0Q21GaWx0ZXJVcHN0 cmVhbQogICAgICAgZG9jc1N1Yk1ndFN1YkZpbHRlckRvd25EZWZhdWx0CiAgICAgICBkb2NzU3Vi TWd0U3ViRmlsdGVyVXBEZWZhdWx0CiAgICAgICBkb2NzU3ViTWd0Q21GaWx0ZXJEb3duRGVmYXVs dAogICAgICAgZG9jc1N1Yk1ndENtRmlsdGVyVXBEZWZhdWx0CgogICBTTk1QdjEgYnkgaXRzZWxm IGlzIG5vdCBhIHNlY3VyZSBlbnZpcm9ubWVudC4gIEV2ZW4gaWYgdGhlIG5ldHdvcmsKICAgaXRz ZWxmIGlzIHNlY3VyZSAoZm9yIGV4YW1wbGUgYnkgdXNpbmcgSVBTZWMpLCBldmVuIHRoZW4sIHRo ZXJlIGlzIG5vCiAgIGNvbnRyb2wgYXMgdG8gd2hvIG9uIHRoZSBzZWN1cmUgbmV0d29yayBpcyBh bGxvd2VkIHRvIGFjY2VzcyBhbmQKICAgR0VUL1NFVCAocmVhZC9jaGFuZ2UvY3JlYXRlL2RlbGV0 ZSkgdGhlIG9iamVjdHMgaW4gdGhpcyBNSUIuCgogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRo ZSBpbXBsZW1lbnRlcnMgY29uc2lkZXIgdGhlIHNlY3VyaXR5CiAgIGZlYXR1cmVzIGFzIHByb3Zp ZGVkIGJ5IHRoZSBTTk1QdjMgZnJhbWV3b3JrLiAgU3BlY2lmaWNhbGx5LCB0aGUgdXNlCiAgIG9m IHRoZSBVc2VyLWJhc2VkIFNlY3VyaXR5IE1vZGVsIFJGQyAyNTc0IFtSRkMyNTc0XSBhbmQgdGhl IFZpZXctCiAgIGJhc2VkIEFjY2VzcyBDb250cm9sIE1vZGVsIFJGQyAyNTc1IFtSRkMyNTc1XSBp cyByZWNvbW1lbmRlZC4KCiAgIEl0IGlzIHRoZW4gYSBjdXN0b21lci91c2VyIHJlc3BvbnNpYmls aXR5IHRvIGVuc3VyZSB0aGF0IHRoZSBTTk1QCgpFeHBpcmVzICBNYXkgMjAwMyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDI3XQoMCklOVEVSTkVULURS QUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAgICAgTm92ZW1iZXIg MjAwMgoKICAgZW50aXR5IGdpdmluZyBhY2Nlc3MgdG8gYW4gaW5zdGFuY2Ugb2YgdGhpcyBNSUIs IGlzIHByb3Blcmx5CiAgIGNvbmZpZ3VyZWQgdG8gZ2l2ZSBhY2Nlc3MgdG8gdGhlIG9iamVjdHMg b25seSB0byB0aG9zZSBwcmluY2lwYWxzCiAgICh1c2VycykgdGhhdCBoYXZlIGxlZ2l0aW1hdGUg cmlnaHRzIHRvIGluZGVlZCBHRVQgb3IgU0VUCiAgIChjaGFuZ2UvY3JlYXRlL2RlbGV0ZSkgdGhl bS4KCjguIEF1dGhvcidzIEFkZHJlc3MKCiAgICAgICAgV2lsc29uIFNhd3llcgogICAgICAgIEFS UklTCiAgICAgICAgNiBSaXZlcnNpZGUgRHJpdmUKICAgICAgICBBbmRvdmVyLCBNQSAwMTgxMAog ICAgICAgIFVTQQoKICAgICAgICBQaG9uZTogKzEgOTc4IDk0NiA0NzExCiAgICAgICAgRW1haWw6 IHdzYXd5ZXJAaWVlZS5vcmcKCjkuIEludGVsbGVjdHVhbCBQcm9wZXJ0eQoKICAgVGhlIElFVEYg dGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkK ICAgaW50ZWxsZWN0dWFsIHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNs YWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0 ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8g d2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMKICAgbWlnaHQgb3IgbWlnaHQgbm90 IGJlIGF2YWlsYWJsZTsgbmVpdGhlciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0CiAgIGhhcyBt YWRlIGFueSBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24g b24gdGhlCiAgIElFVEYncyBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3Rh bmRhcmRzLXRyYWNrIGFuZAogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBi ZSBmb3VuZCBpbiBCQ1AtMTEuICBDb3BpZXMgb2YKICAgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2 YWlsYWJsZSBmb3IgcHVibGljYXRpb24gYW5kIGFueSBhc3N1cmFuY2VzIG9mCiAgIGxpY2Vuc2Vz IHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIGF0dGVtcHQgbWFkZSB0 bwogICBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBv ZiBzdWNoCiAgIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uIGNhbgogICBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIFNlY3Jl dGFyaWF0LgoKCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJp bmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQg YXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQogICByaWdodHMgd2hpY2ggbWF5IGNv dmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gcHJhY3RpY2UKICAgdGhpcyBz dGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBFeGVj dXRpdmUKICAgRGlyZWN0b3IuCgoKCgoxMC4gRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBD b3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIFJpZ2h0cyBSZXNl cnZlZC4KCgogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv cGllZCBhbmQgZnVybmlzaGVkIHRvCiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhh dCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBleHBsYWluIGl0CiAgIG9yIGFzc2lzdCBpbiBpdHMg aW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZAogICBhbmQg ZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2Yg YW55CiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5k IHRoaXMgcGFyYWdyYXBoIGFyZQogICBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRl cml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0aGlzCgpFeHBpcmVzICBNYXkgMjAwMyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDI4XQoMCklOVEVSTkVU LURSQUZUICAgICAgRE9DU0lTIFN1YnNjcmliZXIgTWFuYWdlbWVudCBNSUIgICAgICAgTm92ZW1i ZXIgMjAwMgoKICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdh eSwgc3VjaCBhcyBieSByZW1vdmluZwogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVu Y2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyCiAgIEludGVybmV0IG9yZ2FuaXph dGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSAgcHVycG9zZSBvZgogICBkZXZlbG9waW5n IEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvcgogICBj b3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11c3Qg YmUKICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1 YWdlcyBvdGhlciB0aGFuCiAgIEVuZ2xpc2guCgogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBn cmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlCiAgIHJldm9rZWQgYnkg dGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4KCgogICBU aGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92 aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQg VEhFIElOVEVSTkVUIEVOR0lORUVSSU5HCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJS QU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORwogICBCVVQgTk9UIExJTUlURUQg VE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04KICAgSEVSRUlO IFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBP RgogICBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Uu CgogICBBY2tub3dsZWRnZW1lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0 aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUKICAgSW50ZXJuZXQgU29jaWV0eS4KCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkV4cGlyZXMgIE1heSAyMDAzICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjldCgoKCgo= --0__=0ABBE6F7DFF51CBD8f9e8a93df938690918c0ABBE6F7DFF51CBD-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Nov 1 16:20:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04722 for ; Fri, 1 Nov 2002 16:20:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1LMNe04955 for ipcdn-archive@odin.ietf.org; Fri, 1 Nov 2002 16:22:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1LM6v04921; Fri, 1 Nov 2002 16:22:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1LLBv04892 for ; Fri, 1 Nov 2002 16:21:11 -0500 Received: from mail2.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04618 for ; Fri, 1 Nov 2002 16:18:40 -0500 (EST) Received: from rssrgesnxd.rogers.com (rssrgesnxd.rss.rogers.com [142.146.14.101]) by mail2.rogers.com (8.10.2+Sun/8.10.2) with ESMTP id gA1LNQl02783; Fri, 1 Nov 2002 16:23:27 -0500 (EST) Received: by rssrgesnxd.rogers.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 16:20:52 -0500 Message-ID: From: George Hart To: "'Greg White'" , Greg.Gohman@arrisi.com Cc: "Raftus, David" , "DOCSIS 2.0 Majordomo List" , DOCSIS OSS Majordomo List , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" , Tom.Cloonan@arrisi.com Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Date: Fri, 1 Nov 2002 16:20:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , The upstream counters make sense to me, and will be useful in helping operators determine the utilization of the upstream path. I think I understand the concept for downstream, although the description for the object docsIfDownChannelTotalBytes may be confusing. It seems to me this should represent the downstream capacity available, not the number of bytes transported which is enumerated by docsIfDownChannelUsedBytes. One refinement to consider for the upstream is to count minislots available vs used in the contention region separately from the MAP region. These two regions are subject to very different access mechanisms and having separate indications of utilization on these regions could prove helpful. Thanks to all for the hard work in moving this along so aggressively. It will be extremely useful to us. George -----Original Message----- From: Greg White [mailto:g.white@cablelabs.com] Sent: Thursday, October 31, 2002 2:32 PM To: Greg.Gohman@arrisi.com Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@arrisi.com Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Does anyone else have an opinion on this? I will try to flesh out the proposal: Leave the utilization table as is (with the clarification that Margo proposed IMO), and add the following objects: docsIfUpChannelTotalMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots defined for this upstream (logical) channel. This count includes all minislots, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 20 } docsIfUpChannelUsedMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots utilized on the upstream (logical) channel, regardless of burst type. For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the upstream (logical) channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the logical channel. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 21 } docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes in the DOCSIS Payload portion of DOCSIS MPEG Packets (i.e. not including MPEG Header or pointer_field, nor including any non-DOCSIS MPEG packets) transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } docsIfDownChannelUsedBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of DOCSIS data bytes transported by this downstream channel since CMTS initialization. The number of data bytes is defined as the total number of bytes transported in DOCSIS Payloads minus the number of stuff_bytes transported in DOCSIS Payloads. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 9 } -----Original Message----- From: Greg.Gohman@ARRISI.COM [mailto:Greg.Gohman@ARRISI.COM] Sent: Wednesday, October 30, 2002 10:30 AM To: Greg White Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 We are agreeable with your suggestion. And we can compromise for the utilization table if still desired by the MSOs. Regards, Greg & Tom C. "Greg White" 10/28/02 01:05 PM To: "Raftus, David" , cc: "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Greg.Gohman@ARRISI.COM" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 All, Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments. Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB. If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell. Just thinking out-loud here.... If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization. 1) 64bit counter for raw minislots, per logical channel 2) 64bit counter for minislots used, per logical channel I don't think that either of these counters, or anything close, is available now. In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval. In the case of two (or more) logical channels, the calculation is not as straightforward. Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result. The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel. So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above. It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up. A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable. Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead. Something similar would have to be added to the docsIfDownChannelTable as well. Thoughts? -Greg -----Original Message----- From: Raftus, David [mailto:david.raftus@imedia.com] Sent: Monday, October 28, 2002 8:21 AM To: 'Tom.Cloonan@arrisi.com'; Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Hi Tom, Thanks for your well-considered comments. I need to state initially though that the MSOs have already told us what they want - the channel utilization mib design originated with them, not with me. I simply structured their needs into the mib design. I fear that your proposed changes may be seen as an attempt to 'tell the customer what they want', when they already have expressed their desires. Please see individual responses inline. Regards, Dave Dave, Thanks for the quick response on Greg's email. Greg and I were discussing this topic earlier, and we agreed that the basic premise behind your proposal (allowing MSOs to view statistics on a physical interface) is very sound and quite desirable. We were even discussing how many MSOs already acquired and displayed a lot of these statistical measurements via MRTG calculations of SNMP-acquired counts, so we acknowledge the value of the statistical measurements. We also like the idea of "displaying one line per physical channel summary of utilization stats in displays", but the manner in which the data is displayed seems not to be related to how the data is stored in the MIB. We think that the goal of displaying one line per physical channel can be accomplished in many ways without affecting the manner in which the data is stored or sampled. There are a few fundamental areas of concern within the draft, so we wanted to discuss alternatives to the specific approach that was described in the draft. Our biggest concern with the existing proposal was the requirement that there be a fixed sampling interval. We believe several problems can occur as a result of that approach. 1) Consider the case where multiple SNMP managers are accessing the CMTS. The biggest problem with the proposal in the draft seems to be the fact that it precludes multiple SNMP managers from simultaneously accessing the statistical data if they have different desired sampling intervals. In that case, the last SNMP manager to set the sampling interval wins and destroys the resolution of the accesses for all of the other SNMP managers that were already accessing the CMTS data. In addition, the other SNMP managers are not even aware that their data collection was corrupted without checking. If this situation occurs, I believe it would be an MSO management problem. Multiple snmp managers with write access to the CMTS would seem to be an undesirable dangerous situation. Writable parameters in any table could conceivably be changed by one manager without being known by the others. I could see the merit in adding an object to record when either when the most recent interval started, or when it would end. 2) The problem also shows up if you have a single SNMP manager that is trying to collect data with high-resolution (short sampling intervals) and with low-resolution (long sampling intervals) for the same window of time. Unless I am missing something, the proposed approach seems not to support this requirement, which we have seen to be desired by MSOs that display their statistics with MRTG. This is desirable, because the low-resolution sampling is useful for displaying long-term average measurements whereas the high-resolution sampling is useful for displaying short-term (burst) measurements. I do not see that the new utilization table precludes an MSO from doing this. They are certainly free to use existing counters to setup sampling intervals, etc as they wish for more complicated statistical scenarios. The new utilization table is there for their convenience and at their suggestion. It provides an easy method of measuring simple physical channel utilization. 3) If stored in the fashion that you described and if the sampling interval is set up to collect high resolution statistics (with a short sampling interval), then collecting an approximate low resolution statistic (with a long sampling interval) will require the SNMP manager to store ALL of the samples that the agent creates with the short sampling intervals and "averaging the averages". However, to do this averaging of averages, the SNMP manager's collection process must be synchronized to the sampling window on the CMTS to sample ALL of the sampling intervals. Otherwise, it may miss some of the samples or over-sample a window more than once. Since it is not likely that the SNMP manager will be synchronized with the CMTS sampling interval, this approximation (using an average of averages) is unlikely to be correct in a real-world implementation. Similar reply as to 2). Please view the utilization table as a quick fairly accurate summary of activity. This doesn't stop the MSO from gathering statistics and garnering the more detailed information they want through other methods available to them. Because of these deficiencies within the proposed draft, we believe that MSOs may find the resulting MIB objects to be less useful than you had originally intended. We believe that you can accomplish your goal (of providing MSOs with the data they need to create the statistics) and circumvent the three problems listed above if you slightly modify your approach. We think the modified approach should be based on counters. All of the data required for the statistical measurements (raw bandwidth, data passed, etc.) can be passed up as counters. The counters can be sampled from each SNMP manager with sampling rates that correspond to their desired resolutions. Thus, an SNMP manager can take a first counter sample at the beginning of the desired window and a second counter sample at the end of the window, and it can then subtract the two counter values and divide by the window size to create the average. As a result of this approach, multiple SNMP managers can access the counters and not interfere with one another. In addition, a single SNMP manager can maintain both long-term and short-term statistics by taking samples with both short and long windows that are overlapping one another. We believe that this approach provides more flexibility in displaying the statistical data that MSOs want. Using this counter approach may permit more flexibility and may accommod! ate the needs of more MSOs. Thanks, Tom Tom Cloonan CTO- Broadband Division ARRIS Phone: 630-281-3050 Fax: 630-955-9870 e-mail: tom.cloonan@arrisi.com ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com] Sent: Friday, October 25, 2002 7:04 PM To: Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 << Message: >> << File: image001.png >> << File: image002.jpg >> _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Nov 1 18:45:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09013 for ; Fri, 1 Nov 2002 18:45:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1Nl9n13796 for ipcdn-archive@odin.ietf.org; Fri, 1 Nov 2002 18:47:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1Ng8v13446; Fri, 1 Nov 2002 18:42:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1NfQv13407 for ; Fri, 1 Nov 2002 18:41:26 -0500 Received: from smtp.adc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08685 for ; Fri, 1 Nov 2002 18:38:53 -0500 (EST) Received: from smtp.adc.com (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id gA1NfI217014 for ; Fri, 1 Nov 2002 17:41:18 -0600 (CST) Received: from mplsgtwy01.adc.com (mplsgtwy01.adc.com [155.226.11.222]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id gA1NfGr16997; Fri, 1 Nov 2002 17:41:16 -0600 (CST) Received: by mplsgtwy01.adc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 17:41:16 -0600 Message-ID: From: "Abramson, Howard" To: "'Dave Thaler (E-mail)'" , "'Bill Fenner (E-mail)'" Cc: "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" , "Jean-Francois Mule (E-mail)" , "'Greg Nakanishi (E-mail)'" Date: Fri, 1 Nov 2002 17:41:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: draft-itef-ipcdn-igmp-mib-04 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Dave / Bill, I am working with Rich and Jean-Francois to address the comments provided on this draft by Dave and the MIB Doctor. Before we get to far on the changes, we would appreciate your consideration of the following proposal. This is greatly appreciated. Regards, Howard Abramson Goals: . provide flexibility of implementation (e.g., not restrict vendors' creativity) . RFC-2933 and RFC-2236 compliance for Operator ease of use . DOCSIS 1.1 compliance Proposal: . define "Interface Specific" compliance statements to describe the minimum set of RFC-2933 objects that must be supported by a DOCSIS 1.1 device. Discussion: . there is some confusion as to the correctness of this approach. Specifically, can a device apply different compliance statements to different interfaces. . the number of different types of DOCSIS 1.1 IGMP capable interfaces is derived from the device type (CM or CMTS), mode of DOCSIS 1.1 defined IGMP operation (active or passive), and DOCSIS 1.1 interface (CMTS:NSI, CMTS:HFC, CM:HFC, CM:CMCI). . the compliance of a DOCSIS 1.1 IGMP capable interface is also based on the 'implementation'. For example, the device may be implemented as a Multicast Router or IGMP Proxy. . modifications to Section 3 and 4 of version 4 of this draft follows. The tables shown in section 4, below, will replace the existing section of this draft (v4). in some cases the compliance statements come directly from RFC-2933. This is true, as shown below, for both an Active and a Passive CM HFC-side IGMP interface. Excerpts from working copy of version 5 of this draft. ----------------------------------------------------- 3. Overview The goal of this informational note is to provide DOCSIS vendors and operators with a standard interface to the management of IP Multicast. More specifically, this note describes the application of Internet Group Management Protocol (IGMP), [22], and its associated MIB, [20], through applicable MIB compliance statements. The DOCSIS protocol and network is described in [23]. In general, the network is composed of Cable Modems (CMs) connected to a Cable Modem Termination System (CMTS) via a broadcast downstream and shared upstream channel. Subscriber access is provided via CM to CPE over a Local Area Network. Downstream transmissions are received by all CMs and bridged according to subscriber-side CPE ethernet addressing and other DOCSIS link layer identification. Upstream transmissions from CPE are bridged through the CM to the CMTS via a reservation based Media Access Control protocol. Network-side connections (i.e., to the Internet) are provided by the CMTS via typical bridge or router interfaces. CPE to CPE connections on different CMs are provided via upstream transmission to the CMTS and forwarding back downstream. Providing IP Multicast services in a residential broadband or DOCSIS network poses several challenges that are uncommon to a typical broadcast Local Area Network. One example is that the CM is specified to be a bridge. This is a special consideration because the downstream bandwidth between the CMTS and CM is three to four times greater than that between the CM and the subscriber-side CPE. Similarly, the number of CPE connected to the network is typically an order of magnitude or more than on a typical LAN. This creates the potential of more active IP Multicast sessions and associated downstream data than bandwidth available on the CM's subscriber-side LAN. As such, special provisions are required to prevent unnecessary or undesireable IP Multicast data from being forwarded from the HFC-side of the CM onto the subscriber-side LAN. Another consideration is the bi-directional nature of transmissions. CPE that are connected to different Cable Modems (CMs) do not directly receive each other's transmissions. This complicates optimizations added to IGMPv2 to conserve bandwidth during General and Group Specific Query intervals. It is necessary for the CMTS to forward upstream IGMP Membership Reports onto the downstream in order to take advantage of this feature of IGMPv2. Another consideration is the DOCSIS operator's ability to manage IGMP on a network of several thousand CMs. For example, if non-default values are desired for the Query Interval it is necessary to make a change to every CM on the network. This is simplified by specifying CMs that derive their timers based on the reception of downstream IGMP. It is expected that the root of each IP Multicast session tree originate from the NSI interface(s). Although not strictly prohibited by the RFI, a more symmetrical model, where the root of a Multicast group may be on the HFC/Subscriber-side, is discouraged. In either case, Querying in a DOCSIS network MUST only be in the downstream direction (initiated by an NSI Querier or the CMTS itself). This is to provide the operator with more control of available bandwidth. Host Membership Reporting is expected to be in the upstream direction (from CPE or active IGMP CM devices). 3.1 Modelling IGMP Interface Capaiblities for DOCSIS To address the challenges imposed on IGMP by DOCSIS, the DOCSIS 1.1 IP Multicast interconnect specification for Cable Modems and Cable Modem Termination Systems is modeled (or described) by 'splitting' the traditional IGMP interfaces into Host and Querier side interfaces. That is, to provide basic DOCSIS 1.1 IP Multicast capabilities, all NSI-facing interfaces (NSI on the CMTS and HFC-side on CM) need only present an IGMP Host interface to the external multicast network. All Subscriber-facing interfaces (HFC-side on CMTS and CPE-side on CM) need only present a Querier interface to CPE. This is in contrast to a Multicast Router model where each interface has both Host and Querier capabilities. One application of this approach is described as an IGMP Proxy in [21]. 3.1 IGMP Capabilities: Active and Passive Mode To address operator concerns for managing IGMP, the DOCSIS IGMP model is further expanded to define devices that 'passively' and 'actively' implement the Host and Querier state machines. There are two basic modes of IGMP capability defined by the DOCSIS 1.1 RFI specification that are applicable to a DOCSIS 1.1 device. o Passive IGMP Devices - The first mode is a passive operation in which the device selectively forwards IGMP based upon the known state of multicast session activity on the subscriber side (an example of this is described in Appendix L of [23]). In passive mode, the device derives its IGMP timers based on the rules specified in section 3.3.1 of the RFI. o Active IGMP Devices - The second mode is an active operation in which the device terminates and initiates IGMP based upon the known state of multicast session activity on the subscriber side. One example of the latter, active, mode is commonly referred to as an IGMP-Proxy implementation (as described in [21]). A more complete example of an active IGMP device is that of a Multicast Router. Passive IGMP devices do not initiate IGMP PDUs (i.e., report or queries). Passive devices rely on an (upstream) device to transmit IGMP Queries and a (downstream) device to transmit IGMP Membership Reports and Leaves to manage session activity, e.g., a Multicast Router and Multicast Host, respectively. In contrast, an active IGMP device initiates IGMP PDUs (queries and/or reports) to manage session activity. Although a specific implementation is not imposed, a DOCSIS 1.1 device MUST meet the requirements stated in section 3.3.1 of [23] and MUST support the IDMR IGMP MIB, [20], with the compliance statements described herein. DOCSIS devices MUST also comply with the changes to the Cable Device MIB, [25], described in this note. As specified in the DOCSIS 1.1 RFI, active CMs are explicitly prohibited from transmitting IGMP Queries upstream onto the HFC. However, an active CMTS may transmit IGMP Queries on any of its interfaces. 3.2 IGMP Timers The IGMP standard, [22], defines several timers that are applicable to the management of Multicast session activity on a given interface. Timers for DOCSIS 1.1 passive IGMP devices are derived based on the requirements specified in section 3.3.1 of [23]. As such, MIB objects that apply to these timers must be considered read only values. IGMP timers in active devices should be considered values that may be managed within the device. 4. DOCSIS 1.1 Interfaces and the IGMP MIB The following sections describe the application of RFC-2933 to DOCSIS 1.1 devices. The IDMR IGMP MIB is organized into two distinct tables, the interface and cache tables. The IGMP Interface Table contains entries for each interface that supports IGMP on a device. For DOCSIS 1.1 this includes the NSI and HFC for the CMTS and the HFC and CMCI on the CM. The IGMP Cache Table contains one row for each IP Multicast Group for which there are active members on a given interface. Active membership MUST only exist on the CMCI of a Cable Modem. However, active membership MAY exist on both the NSI and HFC side interfaces of the CMTS. This is because a CMTS may be implemented as a Multicast Router on which other network side devices are actively participating in a multicast session. Support of the IDMR IGMP MIB by DOCSIS 1.1 devices is presented in terms of IGMP capabilities, the device type (CM or CMTS), and the interface on which IGMP is supported. This is followed by a set of new IGMP MIB conformance, compliance and group statements for DOCSIS 1.1 devices. The following tables identify the combinations of IGMP capabilities that are applicable to DOCSIS 1.1 devices and the relevant MIB Groups for each. Active DOCSIS IGMP interfaces more closely resemble traditional IGMPv2 interfaces. IGMP messaging is terminated and initiated on an active device. As such the following MIB compliance matrix applies applies to these devices. ----------------------------------------------------- | Active DOCSIS IGMP Interfaces | |---------------|-----------------------------------| | | | igmpBaseMIBGroup | | | HFC |Host Only igmpV2HostMIBGroup | <- No Querying |CM |--------------------------------------------| | | |Router Only | | <- a PROXY | | CMCI ------------------------------------| | | |Host&Router | | | | | | | <- an M-Router |---------------------------------------------------| | | |Host Only | | <- a PROXY | | NSI -------------|----------------------| | | |Host&Router | | <-an M-Router | | | | | |CMTS ---------------------------------------------| | | |Router Only | | <-a PROXY | | HFC ------------------------------------| | | |Host&Router | | <- an M-Router | | | | | ----------------------------------------------------- ** - need to add igmpCacheTable object groups supported Passive DOCSIS IGMP interfaces are different from active devices in that they i) derive their timers based on the reception of IGMP from network-side devices and ii) selectively forward IGMP messages from one interface to the other. As such, the following MIB compliance matrix applies to these devices. ----------------------------------------------------- | Passive DOCSIS IGMP nterfaces | |---------------|-----------------------------------| | | | igmpBaseMIBGroup | | | HFC |Host Only igmpV2HostMIBGroup | <- No Querying |CM |--------------------------------------------| | | CMCI |Router Only | docsIgmpV2...MIBGroup| |---------------------------------------------------| | | NSI |Host Only | docsIgmpV2...MIBGroup| | |--------------------------------------------| |CMTS | HFC |Router Only | docsIgmpV2...MIBGroup| ----------------------------------------------------- ** - need to add igmpCacheTable object groups supported Note: The subscriber-side interface of the CM is referred to as Cable Modem Customer Interface or CMCI. _____________________________________________________________ _/ _/ _/_/_/ _/_/_/ Howard D. Abramson _/ _/ _/ _/ _/ _/ ADC Telecommunications* _/_/_/_/ _/ _/ _/_/_/_/ 8 Technology Drive _/ _/ _/ _/ _/ _/ Westborough, MA 01581 _/ _/ _/_/_/ _/ _/ howard_abramson@adc.com _____________________________________________________________ * formerly Broadband Access Systems, Inc. ADC Broadband Access and Transport Group Learn about ADC - The Broadband Company at www.adc.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Nov 1 19:55:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10692 for ; Fri, 1 Nov 2002 19:55:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA20v6R17349 for ipcdn-archive@odin.ietf.org; Fri, 1 Nov 2002 19:57:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA20v6v17338; Fri, 1 Nov 2002 19:57:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA20upv17311 for ; Fri, 1 Nov 2002 19:56:51 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10643 for ; Fri, 1 Nov 2002 19:54:17 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gA20uVGv008068; Fri, 1 Nov 2002 17:56:31 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 1 Nov 2002 17:56:31 -0700 Message-ID: Thread-Topic: draft-itef-ipcdn-igmp-mib-04 Thread-Index: AcKCAC8i3moX9SZXRj6XrGesEtsi0wABKW7w From: "Jean-Francois Mule" To: "Howard Abramson at ADC" , "Dave Thaler (E-mail)" , "Bill Fenner (E-mail)" Cc: "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" , "Greg Nakanishi (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA20upv17312 Subject: [ipcdn] RE: draft-itef-ipcdn-igmp-mib-04 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit To add to Howard's email, we are seeking input from the ipcdn list and some additional guidance from MIB experts on how to best draft the MODULE-COMPLIANCE statements based on igmp mib. To be specific, a CMTS device may have active/passive interfaces (NSI or HFC interfaces) and depending on the configuration and the mode of operation (active/passive), those interfaces can act as IGMP proxies only or routers. As a consequence, if I read the way docsis defines this correctly, in the igmpInterfaceTable for a CMTS, we have several entries (conceptual rows) with some columnar objects that do or do not apply depending on the configuration of the device. So how do we best create logical groups to include the objects that must be supported by docsis devices? To build on Howard's email, we've got a couple of options, 2 of which are listed here to start the discussion: 1. Specify the object groups by cmts: the issue here is it does not seem right to me to have compliance statements that vary depending on the interface type on the device; 2. Specify the object groups by cmts and select objects independently of the interface: issue here is depending on the interface & configuration, it can play a host or router (see below). Any thoughts? Jean-Francois. > ----------------------------------------------------- > | Active DOCSIS IGMP Interfaces | > |---------------|-----------------------------------| ... snip > |---------------------------------------------------| > | | |Host Only | | <- a PROXY > | | NSI -------------|----------------------| > | | |Host&Router | | <-an M-Router > | | | | | > |CMTS ---------------------------------------------| > | | |Router Only | | <-a PROXY > | | HFC ------------------------------------| > | | |Host&Router | | <- an M-Router > | | | | | > ----------------------------------------------------- > -----Original Message----- > From: Abramson, Howard [mailto:Howard_Abramson@adc.com] > Sent: Friday, November 01, 2002 4:41 PM > To: 'Dave Thaler (E-mail)'; 'Bill Fenner (E-mail)' > Cc: Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); > Jean-Francois Mule > (E-mail); 'Greg Nakanishi (E-mail)' > Subject: RE: draft-itef-ipcdn-igmp-mib-04 > > > > Dave / Bill, > > I am working with Rich and Jean-Francois to address the > comments provided on > this draft by Dave and the MIB Doctor. Before we get to far > on the changes, > we would appreciate your consideration of the following proposal. > > This is greatly appreciated. > > Regards, > > Howard Abramson > > Goals: > . provide flexibility of implementation (e.g., not restrict > vendors' creativity) > . RFC-2933 and RFC-2236 compliance for Operator ease of use > . DOCSIS 1.1 compliance > > Proposal: > . define "Interface Specific" compliance statements to describe > the minimum set of RFC-2933 objects that must be supported > by a DOCSIS 1.1 device. > > Discussion: > . there is some confusion as to the correctness of this approach. > Specifically, can a device apply different compliance statements > to different interfaces. > > . the number of different types of DOCSIS 1.1 IGMP capable > interfaces is derived from the device type (CM or CMTS), > mode of DOCSIS 1.1 defined IGMP operation (active or passive), > and DOCSIS 1.1 interface (CMTS:NSI, CMTS:HFC, CM:HFC, CM:CMCI). > > . the compliance of a DOCSIS 1.1 IGMP capable interface is > also based on the 'implementation'. For example, the device > may be implemented as a Multicast Router or IGMP Proxy. > > . modifications to Section 3 and 4 of version 4 of this > draft follows. > The tables shown in section 4, below, will replace the existing > section of this draft (v4). > > in some cases the compliance statements come directly from > RFC-2933. This is true, as shown below, for both an Active and > a Passive CM HFC-side IGMP interface. ... snip _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Nov 4 18:48:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15003 for ; Mon, 4 Nov 2002 18:48:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4NocF15893 for ipcdn-archive@odin.ietf.org; Mon, 4 Nov 2002 18:50:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NoWv15888; Mon, 4 Nov 2002 18:50:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Nlfv15767 for ; Mon, 4 Nov 2002 18:47:41 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14860 for ; Mon, 4 Nov 2002 18:45:07 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gA4NlTGx005709 for ; Mon, 4 Nov 2002 16:47:32 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 4 Nov 2002 16:47:31 -0700 Message-ID: Thread-Topic: Copyright statement in MIB Modules Thread-Index: AcKEWN3A9fBuq1rOQ6q+VIpXz9YqfAAA5z8Q From: "Jean-Francois Mule" To: "Ipcdn List (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA4Nlfv15768 Subject: [ipcdn] FYI: Copyright statement in MIB Modules Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Monday, November 04, 2002 3:14 PM > Cc: RFC Editor > Subject: Copyright statement in MIB Modules > > > Copyright statement in MIB Modules > > Many people/tools extract the MIB modules out of our RFCs that > contain a MIB module. In most cases they remove the copyright > information that is part of the RFC. This is against the IETF > copyright claim. > > People/tools do this not with bad intentions. The reason they > do not extract the copyright info is because it is not in machine > readable/parsable form, and they want the MIB modules to feed > them into their agents, network management platforms, or other > MIB tools. > > In order to ensure that the copyright statement is properly > preserved and included in extracted MIB modules, and in order > to make it easier for people/tools to keep the proper copyright > when extracting MIB modules, the IESG has agreed with the > the RFC-Editor that: > > The RFC-Editor, during the editing process of an RFC that > contains a MIB Module, copies a short copyright statement > into the DESCRIPTION clause of the MODULE-IDENTITY macro > of each MIB Module in the RFC-to-be. > > The copyright statement to be added is as follows: > > "Copyright (C) The Internet Society (year). This version of > this MIB module is part of RFC xxxx, see the RFC itself for > full legal notices." > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Nov 6 06:32:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12915 for ; Wed, 6 Nov 2002 06:32:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6BYTw04080 for ipcdn-archive@odin.ietf.org; Wed, 6 Nov 2002 06:34:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BYFv04055; Wed, 6 Nov 2002 06:34:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BWVv03828 for ; Wed, 6 Nov 2002 06:32:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12281; Wed, 6 Nov 2002 06:30:00 -0500 (EST) Message-Id: <200211061130.GAA12281@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Nov 2002 06:30:00 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-07.txt Pages : 29 Date : 2002-11-5 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-subscriber-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-5193233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193233.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Nov 6 19:18:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17967 for ; Wed, 6 Nov 2002 19:18:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA70KOn23715 for ipcdn-archive@odin.ietf.org; Wed, 6 Nov 2002 19:20:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA70KDv23678; Wed, 6 Nov 2002 19:20:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA70Jqv23625 for ; Wed, 6 Nov 2002 19:19:52 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17909 for ; Wed, 6 Nov 2002 19:17:14 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id gA70JeAR016922; Wed, 6 Nov 2002 17:19:40 -0700 (MST) Received: from 147.191.90.11 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 06 Nov 2002 17:19:28 -0700 X-Server-Uuid: 327424A5-C000-4071-A863-154BD49E0E91 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 6 Nov 2002 17:19:23 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBCED6@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN (E-mail)" cc: "Jean-Francois Mule (E-mail)" , "Woundy, Richard" Date: Wed, 6 Nov 2002 17:19:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11D76E1A369758-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Preliminary agenda for the IPCDN meeting in Atlanta Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here's the preliminary agenda for the IPCDN WG meeting in Atlanta. IP over Cable Data Network WG (ipcdn) Wednesday, November 20, at 1300-1500 ==================================== CHAIRS: Richard Woundy Jean-Francois Mule AGENDA: I. Agenda Bashing II. Administration/Re-chartering Re-charter progress Dropping DVB/Euromodem MIB efforts Adding CableHome MIB efforts Determining new WG item milestones WG handling of expired internet-drafts? III. DOCSIS Submissions DOCSIS IGMP MIB Developing compliance statements: CM versus CMTS, active versus passive modes Responding to other MIB doctor issues Subscriber Management MIB and Open Issues Using the Subscriber Management MIB in place of the Cable Device MIB? Responding to other MIB doctor issues DOCSIS 2.0 RFI MIB Channel utilization: percentages versus counters Ready to start WG last call? draft-ietf-ipcdn-docs-rfmibv2-05.txt (submitted?) Cable Device MIB Incorporation of DOCSIS modifications Deprecate IP filters, CPE controls in favor of Subscriber Management MIB on CM? Ready to start WG last call? draft-ietf-ipcdn-device-mibv2-03.txt (submitted) BPI+ MIB New draft editor Ready to start WG last call? draft-ietf-ipcdn-bpiplus-mib-07 (submitted) IV. PacketCable/IPCablecom Submissions Beginning of formal WG review of drafts Management Event MIB MTA MIB Network Control Signaling MIB V. CableHome Submissions (Individual) Consideration of drafts for WG charter Security MIB Configuration MIB Device Management MIB Address Mapping MIB Remote Diagnostic Tools MIB VI. Status of other WG drafts DOCSIS QoS MIB Expired -- do we need a new editor? DOCSIS Event Notification Expired -- do we need a new editor? DVB/Euromodem MIBs Expired -- no interest in continuing from the Euromodem/ECCA community VII. WG next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Nov 7 07:24:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17451 for ; Thu, 7 Nov 2002 07:24:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7CQWm12596 for ipcdn-archive@odin.ietf.org; Thu, 7 Nov 2002 07:26:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7CQLv12583; Thu, 7 Nov 2002 07:26:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7CPuv12559 for ; Thu, 7 Nov 2002 07:25:56 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17335 for ; Thu, 7 Nov 2002 07:23:23 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id <4QQHPY06>; Thu, 7 Nov 2002 04:25:52 -0800 Message-ID: From: "Raftus, David" To: "'Woundy, Richard'" , "IPCDN (E-mail)" Cc: "Jean-Francois Mule (E-mail)" , "Raftus, David" Subject: RE: [ipcdn] Preliminary agenda for the IPCDN meeting in Atlanta Date: Thu, 7 Nov 2002 04:25:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Regarding: DOCSIS 2.0 RFI MIB Channel utilization: percentages versus counters Ready to start WG last call? draft-ietf-ipcdn-docs-rfmibv2-05.txt (submitted?) Not ready for last call, v2-05 not submitted. Cablelabs/vendor community has not yet settled on appropriate wording/meaning for selected objects. Dave ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Woundy, Richard [mailto:RWoundy@broadband.att.com] Sent: Wednesday, November 06, 2002 7:19 PM To: IPCDN (E-mail) Cc: Jean-Francois Mule (E-mail); Woundy, Richard Subject: [ipcdn] Preliminary agenda for the IPCDN meeting in Atlanta Here's the preliminary agenda for the IPCDN WG meeting in Atlanta. IP over Cable Data Network WG (ipcdn) Wednesday, November 20, at 1300-1500 ==================================== CHAIRS: Richard Woundy Jean-Francois Mule AGENDA: I. Agenda Bashing II. Administration/Re-chartering Re-charter progress Dropping DVB/Euromodem MIB efforts Adding CableHome MIB efforts Determining new WG item milestones WG handling of expired internet-drafts? III. DOCSIS Submissions DOCSIS IGMP MIB Developing compliance statements: CM versus CMTS, active versus passive modes Responding to other MIB doctor issues Subscriber Management MIB and Open Issues Using the Subscriber Management MIB in place of the Cable Device MIB? Responding to other MIB doctor issues DOCSIS 2.0 RFI MIB Channel utilization: percentages versus counters Ready to start WG last call? draft-ietf-ipcdn-docs-rfmibv2-05.txt (submitted?) Cable Device MIB Incorporation of DOCSIS modifications Deprecate IP filters, CPE controls in favor of Subscriber Management MIB on CM? Ready to start WG last call? draft-ietf-ipcdn-device-mibv2-03.txt (submitted) BPI+ MIB New draft editor Ready to start WG last call? draft-ietf-ipcdn-bpiplus-mib-07 (submitted) IV. PacketCable/IPCablecom Submissions Beginning of formal WG review of drafts Management Event MIB MTA MIB Network Control Signaling MIB V. CableHome Submissions (Individual) Consideration of drafts for WG charter Security MIB Configuration MIB Device Management MIB Address Mapping MIB Remote Diagnostic Tools MIB VI. Status of other WG drafts DOCSIS QoS MIB Expired -- do we need a new editor? DOCSIS Event Notification Expired -- do we need a new editor? DVB/Euromodem MIBs Expired -- no interest in continuing from the Euromodem/ECCA community VII. WG next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Nov 7 12:19:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02829 for ; Thu, 7 Nov 2002 12:19:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7HLnw01034 for ipcdn-archive@odin.ietf.org; Thu, 7 Nov 2002 12:21:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7HLBv01005; Thu, 7 Nov 2002 12:21:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7HKZv00936 for ; Thu, 7 Nov 2002 12:20:35 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02752 for ; Thu, 7 Nov 2002 12:18:00 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gA7HKRGv018769; Thu, 7 Nov 2002 10:20:27 -0700 (MST) content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 7 Nov 2002 10:20:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Thread-Index: AcKBM0oXCmPbszb0RR2ZzAcW7E9ztAFTPkmQ From: "Greg White" To: "Victor Hou" , "Raftus, David" , "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Ipcdn List (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA7HKZv00937 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Victor, To summarize, your suggestion is the following? Upstream Channel Utilization Index: The upstream channel utilization index is expressed as a percentage of minislots utilized on the physical channel, regardless of burst type. For an Initial Maintenance region, the minislots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel. For contention REQ and REQ/DATA regions, the minislots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the physical channel. If that is what you intended, then I'm fine with that language. Regarding your question 2, I guess that only applies to contention regions, so I would think that the most common causes of a burst being received and not properly demodulated/decoded would be either initial RNG-REQs that are either too faint or too strong, or collisions. In either case, I don't have a strong opinion, but counting all bursts, even those that fail HCS or CRC would seem to match the philosophy used for UGS. In other words, if it is preventing another CM from using those minislots, it should be counted. -Greg -----Original Message----- From: Victor Hou [mailto:vhou@juniper.net] Sent: Thursday, October 31, 2002 4:15 PM To: Greg White; Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Just to tighten things a little further, two minor items need to be addressed with previously suggested wording: 1. Initial Maintenance regions typically encompass a large number of mini-slots while the the number of mini-slots actually required to send the RNG-REQ is small. Margo's suggested wording was as follows: "For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the physical channel." First, it should be stated that the term "regions" as used in the RFI spec refers to a number of contiguous mini-slots defined by an Information Element in the MAP. So, it is understood that a contention "region" can have multiple transmission opportunities. However, it is possible that an informational note would be helpful in the MIB object description. But back to the main topic... For Initial Maintenance regions, the wording above would suggest to count only the minislots used for the RNG-REQ. It is not clear what the original intent was, but since minislots that are allocated for Initial Maintenance cannot be used for anything else, it appears that the duration of the complete region, translated into minislots, should be counted as "utilized slots." If that is the case, a specific sentence like the following should be added: "For an Initial Maintenance region, the minislots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel." There is, of course, another alternative--which is to count all mini-slots allocated to Initial Maintenance as utilized, whether used or not. In most normal scenarios, the difference between the two approaches will be negligible with respect to the reported utilization, but not necessarily for all. As for contention REQ and REQ/DATA regions, there may be multiple opportunities within the region. And in that case, we should alter the above to: "For contention REQ and REQ/DATA regions, the minislots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel." 2. What does it mean to "receive a burst"? Does this mean a burst of some sort was detected or the burst was received correctly? In low Packet Error Rate scenarios, the difference is completely negligible, but in other cases, that would not be true. I believe the intent is to count only correctly received bursts after forward error correction is performed. Victor -----Original Message----- From: Greg White [mailto:g.white@cablelabs.com] Sent: Thursday, October 31, 2002 11:32 AM To: Greg.Gohman@ARRISI.COM Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Does anyone else have an opinion on this? I will try to flesh out the proposal: Leave the utilization table as is (with the clarification that Margo proposed IMO), and add the following objects: docsIfUpChannelTotalMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots defined for this upstream (logical) channel. This count includes all minislots, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 20 } docsIfUpChannelUsedMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots utilized on the upstream (logical) channel, regardless of burst type. For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the upstream (logical) channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the logical channel. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 21 } docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes in the DOCSIS Payload portion of DOCSIS MPEG Packets (i.e. not including MPEG Header or pointer_field, nor including any non-DOCSIS MPEG packets) transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } docsIfDownChannelUsedBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of DOCSIS data bytes transported by this downstream channel since CMTS initialization. The number of data bytes is defined as the total number of bytes transported in DOCSIS Payloads minus the number of stuff_bytes transported in DOCSIS Payloads. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 9 } -----Original Message----- From: Greg.Gohman@ARRISI.COM [mailto:Greg.Gohman@ARRISI.COM] Sent: Wednesday, October 30, 2002 10:30 AM To: Greg White Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 We are agreeable with your suggestion. And we can compromise for the utilization table if still desired by the MSOs. Regards, Greg & Tom C. "Greg White" 10/28/02 01:05 PM To: "Raftus, David" , cc: "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Greg.Gohman@ARRISI.COM" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 All, Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments. Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB. If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell. Just thinking out-loud here.... If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization. 1) 64bit counter for raw minislots, per logical channel 2) 64bit counter for minislots used, per logical channel I don't think that either of these counters, or anything close, is available now. In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval. In the case of two (or more) logical channels, the calculation is not as straightforward. Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result. The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel. So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above. It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up. A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable. Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead. Something similar would have to be added to the docsIfDownChannelTable as well. Thoughts? -Greg -----Original Message----- From: Raftus, David [mailto:david.raftus@imedia.com] Sent: Monday, October 28, 2002 8:21 AM To: 'Tom.Cloonan@arrisi.com'; Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Hi Tom, Thanks for your well-considered comments. I need to state initially though that the MSOs have already told us what they want - the channel utilization mib design originated with them, not with me. I simply structured their needs into the mib design. I fear that your proposed changes may be seen as an attempt to 'tell the customer what they want', when they already have expressed their desires. Please see individual responses inline. Regards, Dave Dave, Thanks for the quick response on Greg's email. Greg and I were discussing this topic earlier, and we agreed that the basic premise behind your proposal (allowing MSOs to view statistics on a physical interface) is very sound and quite desirable. We were even discussing how many MSOs already acquired and displayed a lot of these statistical measurements via MRTG calculations of SNMP-acquired counts, so we acknowledge the value of the statistical measurements. We also like the idea of "displaying one line per physical channel summary of utilization stats in displays", but the manner in which the data is displayed seems not to be related to how the data is stored in the MIB. We think that the goal of displaying one line per physical channel can be accomplished in many ways without affecting the manner in which the data is stored or sampled. There are a few fundamental areas of concern within the draft, so we wanted to discuss alternatives to the specific approach that was described in the draft. Our biggest concern with the existing proposal was the requirement that there be a fixed sampling interval. We believe several problems can occur as a result of that approach. 1) Consider the case where multiple SNMP managers are accessing the CMTS. The biggest problem with the proposal in the draft seems to be the fact that it precludes multiple SNMP managers from simultaneously accessing the statistical data if they have different desired sampling intervals. In that case, the last SNMP manager to set the sampling interval wins and destroys the resolution of the accesses for all of the other SNMP managers that were already accessing the CMTS data. In addition, the other SNMP managers are not even aware that their data collection was corrupted without checking. If this situation occurs, I believe it would be an MSO management problem. Multiple snmp managers with write access to the CMTS would seem to be an undesirable dangerous situation. Writable parameters in any table could conceivably be changed by one manager without being known by the others. I could see the merit in adding an object to record when either when the most recent interval started, or when it would end. 2) The problem also shows up if you have a single SNMP manager that is trying to collect data with high-resolution (short sampling intervals) and with low-resolution (long sampling intervals) for the same window of time. Unless I am missing something, the proposed approach seems not to support this requirement, which we have seen to be desired by MSOs that display their statistics with MRTG. This is desirable, because the low-resolution sampling is useful for displaying long-term average measurements whereas the high-resolution sampling is useful for displaying short-term (burst) measurements. I do not see that the new utilization table precludes an MSO from doing this. They are certainly free to use existing counters to setup sampling intervals, etc as they wish for more complicated statistical scenarios. The new utilization table is there for their convenience and at their suggestion. It provides an easy method of measuring simple physical channel utilization. 3) If stored in the fashion that you described and if the sampling interval is set up to collect high resolution statistics (with a short sampling interval), then collecting an approximate low resolution statistic (with a long sampling interval) will require the SNMP manager to store ALL of the samples that the agent creates with the short sampling intervals and "averaging the averages". However, to do this averaging of averages, the SNMP manager's collection process must be synchronized to the sampling window on the CMTS to sample ALL of the sampling intervals. Otherwise, it may miss some of the samples or over-sample a window more than once. Since it is not likely that the SNMP manager will be synchronized with the CMTS sampling interval, this approximation (using an average of averages) is unlikely to be correct in a real-world implementation. Similar reply as to 2). Please view the utilization table as a quick fairly accurate summary of activity. This doesn't stop the MSO from gathering statistics and garnering the more detailed information they want through other methods available to them. Because of these deficiencies within the proposed draft, we believe that MSOs may find the resulting MIB objects to be less useful than you had originally intended. We believe that you can accomplish your goal (of providing MSOs with the data they need to create the statistics) and circumvent the three problems listed above if you slightly modify your approach. We think the modified approach should be based on counters. All of the data required for the statistical measurements (raw bandwidth, data passed, etc.) can be passed up as counters. The counters can be sampled from each SNMP manager with sampling rates that correspond to their desired resolutions. Thus, an SNMP manager can take a first counter sample at the beginning of the desired window and a second counter sample at the end of the window, and it can then subtract the two counter values and divide by the window size to create the average. As a result of this approach, multiple SNMP managers can access the counters and not interfere with one another. In addition, a single SNMP manager can maintain both long-term and short-term statistics by taking samples with both short and long windows that are overlapping one another. We believe that this approach provides more flexibility in displaying the statistical data that MSOs want. Using this counter approach may permit more flexibility and may accommod! ate the needs of more MSOs. Thanks, Tom Tom Cloonan CTO- Broadband Division ARRIS Phone: 630-281-3050 Fax: 630-955-9870 e-mail: tom.cloonan@arrisi.com ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com] Sent: Friday, October 25, 2002 7:04 PM To: Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 << Message: >> << File: image001.png >> << File: image002.jpg >> _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Nov 7 12:30:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03254 for ; Thu, 7 Nov 2002 12:30:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7HWLi01687 for ipcdn-archive@odin.ietf.org; Thu, 7 Nov 2002 12:32:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7HW3v01672; Thu, 7 Nov 2002 12:32:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7HVXv01638 for ; Thu, 7 Nov 2002 12:31:33 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03175 for ; Thu, 7 Nov 2002 12:28:54 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gA7HVIGv019210; Thu, 7 Nov 2002 10:31:19 -0700 (MST) content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 7 Nov 2002 10:31:18 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Thread-Index: AcKCCsiRwzokTT3hSOCare03DW4qGAEd13MA From: "Greg White" To: "Kirk Friedman" , "George Hart at RCI Rogers" , "Greg White" , Cc: "Raftus, David" , "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA7HVYv01639 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit That text sounds fine to me. Regarding George's suggestion to separate the upstream minislot counters to count granted minislots separate from contention minislots, I haven't heard any comments. This would mean four new objects in the docsIfUpChannelTable (e.g. docsIfUpChannelTotalGrantedMinislots, docsIfUpChannelUsedGrantedMinislots, docsIfUpChannelTotalContentionMinislots, docsIfUpChannelUsedContentionMinislots). Does anyone have any opinion or suggestions? -Greg -----Original Message----- From: Kirk Friedman [mailto:kfriedman@correlant.com] Sent: Friday, November 01, 2002 5:57 PM To: 'George Hart'; 'Greg White'; Greg.Gohman@arrisi.com Cc: 'Raftus, David'; 'DOCSIS 2.0 Majordomo List'; 'DOCSIS OSS Majordomo List'; 'Ipcdn List (E-mail)'; 'Rich Woundy (Work) (E-mail)'; Tom.Cloonan@arrisi.com Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 I think George is right. The description should be simpler for docsIfDownChannelTotalBytes. Otherwise it could get very confusing For example, the MPEG header/pointer fields are factored out, but not the Reed-Soloman encoding on the downstream. I'm also not sure how it applies to NULL vs. DOCSIS PIDs. Finally the OSS spec uses the raw downstream rates for the ifTable (RFC 2233) ifSpeed MIB object. Simplify it to docsIfDownChannelTotalBytes. Suggest: docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } Thanks, Kirk Friedman Correlant Communications 15110 Avenue Of Science San Diego, CA., 92128 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of George Hart Sent: Friday, November 01, 2002 1:20 PM To: 'Greg White'; Greg.Gohman@arrisi.com Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@arrisi.com Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 The upstream counters make sense to me, and will be useful in helping operators determine the utilization of the upstream path. I think I understand the concept for downstream, although the description for the object docsIfDownChannelTotalBytes may be confusing. It seems to me this should represent the downstream capacity available, not the number of bytes transported which is enumerated by docsIfDownChannelUsedBytes. One refinement to consider for the upstream is to count minislots available vs used in the contention region separately from the MAP region. These two regions are subject to very different access mechanisms and having separate indications of utilization on these regions could prove helpful. Thanks to all for the hard work in moving this along so aggressively. It will be extremely useful to us. George -----Original Message----- From: Greg White [mailto:g.white@cablelabs.com] Sent: Thursday, October 31, 2002 2:32 PM To: Greg.Gohman@arrisi.com Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@arrisi.com Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Does anyone else have an opinion on this? I will try to flesh out the proposal: Leave the utilization table as is (with the clarification that Margo proposed IMO), and add the following objects: docsIfUpChannelTotalMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots defined for this upstream (logical) channel. This count includes all minislots, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 20 } docsIfUpChannelUsedMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots utilized on the upstream (logical) channel, regardless of burst type. For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the upstream (logical) channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the logical channel. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 21 } docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes in the DOCSIS Payload portion of DOCSIS MPEG Packets (i.e. not including MPEG Header or pointer_field, nor including any non-DOCSIS MPEG packets) transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } docsIfDownChannelUsedBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of DOCSIS data bytes transported by this downstream channel since CMTS initialization. The number of data bytes is defined as the total number of bytes transported in DOCSIS Payloads minus the number of stuff_bytes transported in DOCSIS Payloads. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 9 } -----Original Message----- From: Greg.Gohman@ARRISI.COM [mailto:Greg.Gohman@ARRISI.COM] Sent: Wednesday, October 30, 2002 10:30 AM To: Greg White Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 We are agreeable with your suggestion. And we can compromise for the utilization table if still desired by the MSOs. Regards, Greg & Tom C. "Greg White" 10/28/02 01:05 PM To: "Raftus, David" , cc: "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Greg.Gohman@ARRISI.COM" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 All, Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments. Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB. If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell. Just thinking out-loud here.... If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization. 1) 64bit counter for raw minislots, per logical channel 2) 64bit counter for minislots used, per logical channel I don't think that either of these counters, or anything close, is available now. In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval. In the case of two (or more) logical channels, the calculation is not as straightforward. Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result. The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel. So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above. It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up. A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable. Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead. Something similar would have to be added to the docsIfDownChannelTable as well. Thoughts? -Greg -----Original Message----- From: Raftus, David [mailto:david.raftus@imedia.com] Sent: Monday, October 28, 2002 8:21 AM To: 'Tom.Cloonan@arrisi.com'; Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Hi Tom, Thanks for your well-considered comments. I need to state initially though that the MSOs have already told us what they want - the channel utilization mib design originated with them, not with me. I simply structured their needs into the mib design. I fear that your proposed changes may be seen as an attempt to 'tell the customer what they want', when they already have expressed their desires. Please see individual responses inline. Regards, Dave Dave, Thanks for the quick response on Greg's email. Greg and I were discussing this topic earlier, and we agreed that the basic premise behind your proposal (allowing MSOs to view statistics on a physical interface) is very sound and quite desirable. We were even discussing how many MSOs already acquired and displayed a lot of these statistical measurements via MRTG calculations of SNMP-acquired counts, so we acknowledge the value of the statistical measurements. We also like the idea of "displaying one line per physical channel summary of utilization stats in displays", but the manner in which the data is displayed seems not to be related to how the data is stored in the MIB. We think that the goal of displaying one line per physical channel can be accomplished in many ways without affecting the manner in which the data is stored or sampled. There are a few fundamental areas of concern within the draft, so we wanted to discuss alternatives to the specific approach that was described in the draft. Our biggest concern with the existing proposal was the requirement that there be a fixed sampling interval. We believe several problems can occur as a result of that approach. 1) Consider the case where multiple SNMP managers are accessing the CMTS. The biggest problem with the proposal in the draft seems to be the fact that it precludes multiple SNMP managers from simultaneously accessing the statistical data if they have different desired sampling intervals. In that case, the last SNMP manager to set the sampling interval wins and destroys the resolution of the accesses for all of the other SNMP managers that were already accessing the CMTS data. In addition, the other SNMP managers are not even aware that their data collection was corrupted without checking. If this situation occurs, I believe it would be an MSO management problem. Multiple snmp managers with write access to the CMTS would seem to be an undesirable dangerous situation. Writable parameters in any table could conceivably be changed by one manager without being known by the others. I could see the merit in adding an object to record when either when the most recent interval started, or when it would end. 2) The problem also shows up if you have a single SNMP manager that is trying to collect data with high-resolution (short sampling intervals) and with low-resolution (long sampling intervals) for the same window of time. Unless I am missing something, the proposed approach seems not to support this requirement, which we have seen to be desired by MSOs that display their statistics with MRTG. This is desirable, because the low-resolution sampling is useful for displaying long-term average measurements whereas the high-resolution sampling is useful for displaying short-term (burst) measurements. I do not see that the new utilization table precludes an MSO from doing this. They are certainly free to use existing counters to setup sampling intervals, etc as they wish for more complicated statistical scenarios. The new utilization table is there for their convenience and at their suggestion. It provides an easy method of measuring simple physical channel utilization. 3) If stored in the fashion that you described and if the sampling interval is set up to collect high resolution statistics (with a short sampling interval), then collecting an approximate low resolution statistic (with a long sampling interval) will require the SNMP manager to store ALL of the samples that the agent creates with the short sampling intervals and "averaging the averages". However, to do this averaging of averages, the SNMP manager's collection process must be synchronized to the sampling window on the CMTS to sample ALL of the sampling intervals. Otherwise, it may miss some of the samples or over-sample a window more than once. Since it is not likely that the SNMP manager will be synchronized with the CMTS sampling interval, this approximation (using an average of averages) is unlikely to be correct in a real-world implementation. Similar reply as to 2). Please view the utilization table as a quick fairly accurate summary of activity. This doesn't stop the MSO from gathering statistics and garnering the more detailed information they want through other methods available to them. Because of these deficiencies within the proposed draft, we believe that MSOs may find the resulting MIB objects to be less useful than you had originally intended. We believe that you can accomplish your goal (of providing MSOs with the data they need to create the statistics) and circumvent the three problems listed above if you slightly modify your approach. We think the modified approach should be based on counters. All of the data required for the statistical measurements (raw bandwidth, data passed, etc.) can be passed up as counters. The counters can be sampled from each SNMP manager with sampling rates that correspond to their desired resolutions. Thus, an SNMP manager can take a first counter sample at the beginning of the desired window and a second counter sample at the end of the window, and it can then subtract the two counter values and divide by the window size to create the average. As a result of this approach, multiple SNMP managers can access the counters and not interfere with one another. In addition, a single SNMP manager can maintain both long-term and short-term statistics by taking samples with both short and long windows that are overlapping one another. We believe that this approach provides more flexibility in displaying the statistical data that MSOs want. Using this counter approach may permit more flexibility and may accommod! ate the needs of more MSOs. Thanks, Tom Tom Cloonan CTO- Broadband Division ARRIS Phone: 630-281-3050 Fax: 630-955-9870 e-mail: tom.cloonan@arrisi.com ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com] Sent: Friday, October 25, 2002 7:04 PM To: Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 << Message: >> << File: image001.png >> << File: image002.jpg >> _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Nov 8 07:37:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16180 for ; Fri, 8 Nov 2002 07:37:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8CdjQ20658 for ipcdn-archive@odin.ietf.org; Fri, 8 Nov 2002 07:39:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CdYv20646; Fri, 8 Nov 2002 07:39:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Carv19808 for ; Fri, 8 Nov 2002 07:36:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15492; Fri, 8 Nov 2002 07:34:20 -0500 (EST) Message-Id: <200211081234.HAA15492@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Nov 2002 07:34:20 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus Author(s) : S. Green, A. Katsnelson Filename : draft-ietf-ipcdn-bpiplus-mib-07.txt Pages : 73 Date : 2002-11-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of the Baseline Privacy Plus features [17] of DOCSIS1.1-compliant[16] Cable Modems and Cable Modem Termination Systems. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-bpiplus-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-bpiplus-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160026.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Nov 8 07:37:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16193 for ; Fri, 8 Nov 2002 07:37:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8CduH20674 for ipcdn-archive@odin.ietf.org; Fri, 8 Nov 2002 07:39:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CdUv20631; Fri, 8 Nov 2002 07:39:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Camv19803 for ; Fri, 8 Nov 2002 07:36:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15479; Fri, 8 Nov 2002 07:34:16 -0500 (EST) Message-Id: <200211081234.HAA15479@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Nov 2002 07:34:15 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-device-mibv2-03.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy Filename : draft-ietf-ipcdn-device-mibv2-03.txt Pages : 74 Date : 2002-11-7 This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document or its successor will obsolete RFC-2669 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-device-mibv2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-device-mibv2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160018.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sat Nov 9 20:12:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28043 for ; Sat, 9 Nov 2002 20:12:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAA1Et225320 for ipcdn-archive@odin.ietf.org; Sat, 9 Nov 2002 20:14:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAA1Esv25311; Sat, 9 Nov 2002 20:14:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SIrsv09591 for ; Mon, 28 Oct 2002 13:53:54 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24325 for ; Mon, 28 Oct 2002 13:51:28 -0500 (EST) Received: from mira-sjc5-1.cisco.com (IDENT:mirapoint@mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9SIrjot024154; Mon, 28 Oct 2002 10:53:45 -0800 (PST) Received: from milu-nt.cisco.com (dhcp-171-71-51-39.cisco.com [171.71.51.39]) by mira-sjc5-1.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAU54088; Mon, 28 Oct 2002 10:48:06 -0800 (PST) Message-Id: <4.3.2.7.2.20021028105011.00de32d0@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Oct 2002 10:52:21 -0800 To: "Raftus, David" From: Minnie Lu Cc: "'Minnie Lu'" , "Docsis 20 Reflector (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Raftus, Thanks a lot for fixing the conflicts. By the way, before v5 is accepted by CableLabs, I think that we need an ECR for v4 for OSSI spec.. Thanks! Minnie At 06:36 AM 10/28/2002 -0800, Raftus, David wrote: >Hi Minnie, > >Thanks for your suggestion. I don't have an issue with increasing the upper >range of this object from 1522 to 65535. The limit of 1522 was chosen when >the object was created since it seemed to be an accurate value that would >not require change. This has proven to be short-sighted. > >Thanks, >Raftus (:)) > > >************************************ >David Raftus >Imedia Semiconductor >340 Terry Fox Drive, Suite 202 >Ottawa Canada K2K 3A2 > >david.raftus@imedia.com >613.592.1052 ext 222 >************************************ > > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Friday, October 25, 2002 3:04 PM >To: Raftus, David >Cc: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List >(E-mail); milu@cisco.com >Subject: Re: rf mib draft v5 - comment period end Friday Oct 25 > >Hi, Raftus, > > There is conflict between RFI spec. and the following MIB object range > > docsIfQosProfMaxTransmitBurst OBJECT-TYPE > SYNTAX Integer32 (0..1522) <=========== > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The maximum number of bytes that may be requested for a > single upstream transmission. A value of zero means there > is no limit. Note: This value does not include any > physical layer overhead. > MUST NOT be changed while this row is active." > REFERENCE > "Document [25] from References, Appendix C.1.1.4." > DEFVAL { 0 } > ::= { docsIfQosProfileEntry 9 } > >In RFIv1.1 (C1.1.4.6) and RFIv2.0 (C1.1.4.6), it defined 2 bytes and does >not have upper limit to 1522. This conflict exists in v4 version which >is in use by OSSI spec. (1.1, and 2.0). > > Any reason for MIB to have such upper limit ? If not, would you please >correct this error in the MIB file ? > > > >Thanks a lot ! >Minnie > > >At 12:55 PM 10/18/2002 -0700, Raftus, David wrote: > > >Hi everyone, > > > > > > > >Please find attached a draft of the Docsis RF Interface mib v5. The TOC > >and compliance statements have not been updated, but suggestions received > >since v4 regarding new mib objects have been incorporated after > >appropriate massaging. > > > > > > > >Comments are welcome on this draft until 5pm EST Friday October 25. At > >that time an official version of the draft will be prepared for submission > >to the IETF last call process, leading to RFC designation. > > > > > > > >Thanks very much, > > > >Dave > > > > > > > >************************************ > > > >David Raftus > > > >Imedia Semiconductor > > > >340 Terry Fox Drive, Suite 202 > > > >Ottawa Canada > > > >david.raftus@imedia.com613.592.1052************************************ > >58147a.jpg581498.jpg > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sat Nov 9 20:12:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28057 for ; Sat, 9 Nov 2002 20:12:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAA1Ewj25395 for ipcdn-archive@odin.ietf.org; Sat, 9 Nov 2002 20:14:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAA1Euv25353; Sat, 9 Nov 2002 20:14:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNEiv05632 for ; Thu, 31 Oct 2002 18:14:44 -0500 Received: from alpha.jnpr.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19691 for ; Thu, 31 Oct 2002 18:12:12 -0500 (EST) Received: from antineutron.jnpr.net ([172.24.18.197]) by alpha.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Oct 2002 15:14:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Date: Thu, 31 Oct 2002 15:14:34 -0800 Message-ID: Thread-Topic: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Thread-Index: AcKAOj3u8rjU2UQtTtCAqtCCSdNStgA0HuSQAAlxI9A= From: "Victor Hou" To: "Greg White" , "Raftus, David" , "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Ipcdn List (E-mail)" X-OriginalArrivalTime: 31 Oct 2002 23:14:35.0140 (UTC) FILETIME=[46D3DC40:01C28133] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VNEiv05633 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Just to tighten things a little further, two minor items need to be addressed with previously suggested wording: 1. Initial Maintenance regions typically encompass a large number of mini-slots while the the number of mini-slots actually required to send the RNG-REQ is small. Margo's suggested wording was as follows: "For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the physical channel." First, it should be stated that the term "regions" as used in the RFI spec refers to a number of contiguous mini-slots defined by an Information Element in the MAP. So, it is understood that a contention "region" can have multiple transmission opportunities. However, it is possible that an informational note would be helpful in the MIB object description. But back to the main topic... For Initial Maintenance regions, the wording above would suggest to count only the minislots used for the RNG-REQ. It is not clear what the original intent was, but since minislots that are allocated for Initial Maintenance cannot be used for anything else, it appears that the duration of the complete region, translated into minislots, should be counted as "utilized slots." If that is the case, a specific sentence like the following should be added: "For an Initial Maintenance region, the minislots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel." There is, of course, another alternative--which is to count all mini-slots allocated to Initial Maintenance as utilized, whether used or not. In most normal scenarios, the difference between the two approaches will be negligible with respect to the reported utilization, but not necessarily for all. As for contention REQ and REQ/DATA regions, there may be multiple opportunities within the region. And in that case, we should alter the above to: "For contention REQ and REQ/DATA regions, the minislots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel." 2. What does it mean to "receive a burst"? Does this mean a burst of some sort was detected or the burst was received correctly? In low Packet Error Rate scenarios, the difference is completely negligible, but in other cases, that would not be true. I believe the intent is to count only correctly received bursts after forward error correction is performed. Victor -----Original Message----- From: Greg White [mailto:g.white@cablelabs.com] Sent: Thursday, October 31, 2002 11:32 AM To: Greg.Gohman@ARRISI.COM Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Does anyone else have an opinion on this? I will try to flesh out the proposal: Leave the utilization table as is (with the clarification that Margo proposed IMO), and add the following objects: docsIfUpChannelTotalMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots defined for this upstream (logical) channel. This count includes all minislots, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 20 } docsIfUpChannelUsedMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots utilized on the upstream (logical) channel, regardless of burst type. For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the upstream (logical) channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the logical channel. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 21 } docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes in the DOCSIS Payload portion of DOCSIS MPEG Packets (i.e. not including MPEG Header or pointer_field, nor including any non-DOCSIS MPEG packets) transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } docsIfDownChannelUsedBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of DOCSIS data bytes transported by this downstream channel since CMTS initialization. The number of data bytes is defined as the total number of bytes transported in DOCSIS Payloads minus the number of stuff_bytes transported in DOCSIS Payloads. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 9 } -----Original Message----- From: Greg.Gohman@ARRISI.COM [mailto:Greg.Gohman@ARRISI.COM] Sent: Wednesday, October 30, 2002 10:30 AM To: Greg White Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 We are agreeable with your suggestion. And we can compromise for the utilization table if still desired by the MSOs. Regards, Greg & Tom C. "Greg White" 10/28/02 01:05 PM To: "Raftus, David" , cc: "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Greg.Gohman@ARRISI.COM" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 All, Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments. Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB. If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell. Just thinking out-loud here.... If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization. 1) 64bit counter for raw minislots, per logical channel 2) 64bit counter for minislots used, per logical channel I don't think that either of these counters, or anything close, is available now. In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval. In the case of two (or more) logical channels, the calculation is not as straightforward. Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result. The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel. So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above. It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up. A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable. Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead. Something similar would have to be added to the docsIfDownChannelTable as well. Thoughts? -Greg -----Original Message----- From: Raftus, David [mailto:david.raftus@imedia.com] Sent: Monday, October 28, 2002 8:21 AM To: 'Tom.Cloonan@arrisi.com'; Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Hi Tom, Thanks for your well-considered comments. I need to state initially though that the MSOs have already told us what they want - the channel utilization mib design originated with them, not with me. I simply structured their needs into the mib design. I fear that your proposed changes may be seen as an attempt to 'tell the customer what they want', when they already have expressed their desires. Please see individual responses inline. Regards, Dave Dave, Thanks for the quick response on Greg's email. Greg and I were discussing this topic earlier, and we agreed that the basic premise behind your proposal (allowing MSOs to view statistics on a physical interface) is very sound and quite desirable. We were even discussing how many MSOs already acquired and displayed a lot of these statistical measurements via MRTG calculations of SNMP-acquired counts, so we acknowledge the value of the statistical measurements. We also like the idea of "displaying one line per physical channel summary of utilization stats in displays", but the manner in which the data is displayed seems not to be related to how the data is stored in the MIB. We think that the goal of displaying one line per physical channel can be accomplished in many ways without affecting the manner in which the data is stored or sampled. There are a few fundamental areas of concern within the draft, so we wanted to discuss alternatives to the specific approach that was described in the draft. Our biggest concern with the existing proposal was the requirement that there be a fixed sampling interval. We believe several problems can occur as a result of that approach. 1) Consider the case where multiple SNMP managers are accessing the CMTS. The biggest problem with the proposal in the draft seems to be the fact that it precludes multiple SNMP managers from simultaneously accessing the statistical data if they have different desired sampling intervals. In that case, the last SNMP manager to set the sampling interval wins and destroys the resolution of the accesses for all of the other SNMP managers that were already accessing the CMTS data. In addition, the other SNMP managers are not even aware that their data collection was corrupted without checking. If this situation occurs, I believe it would be an MSO management problem. Multiple snmp managers with write access to the CMTS would seem to be an undesirable dangerous situation. Writable parameters in any table could conceivably be changed by one manager without being known by the others. I could see the merit in adding an object to record when either when the most recent interval started, or when it would end. 2) The problem also shows up if you have a single SNMP manager that is trying to collect data with high-resolution (short sampling intervals) and with low-resolution (long sampling intervals) for the same window of time. Unless I am missing something, the proposed approach seems not to support this requirement, which we have seen to be desired by MSOs that display their statistics with MRTG. This is desirable, because the low-resolution sampling is useful for displaying long-term average measurements whereas the high-resolution sampling is useful for displaying short-term (burst) measurements. I do not see that the new utilization table precludes an MSO from doing this. They are certainly free to use existing counters to setup sampling intervals, etc as they wish for more complicated statistical scenarios. The new utilization table is there for their convenience and at their suggestion. It provides an easy method of measuring simple physical channel utilization. 3) If stored in the fashion that you described and if the sampling interval is set up to collect high resolution statistics (with a short sampling interval), then collecting an approximate low resolution statistic (with a long sampling interval) will require the SNMP manager to store ALL of the samples that the agent creates with the short sampling intervals and "averaging the averages". However, to do this averaging of averages, the SNMP manager's collection process must be synchronized to the sampling window on the CMTS to sample ALL of the sampling intervals. Otherwise, it may miss some of the samples or over-sample a window more than once. Since it is not likely that the SNMP manager will be synchronized with the CMTS sampling interval, this approximation (using an average of averages) is unlikely to be correct in a real-world implementation. Similar reply as to 2). Please view the utilization table as a quick fairly accurate summary of activity. This doesn't stop the MSO from gathering statistics and garnering the more detailed information they want through other methods available to them. Because of these deficiencies within the proposed draft, we believe that MSOs may find the resulting MIB objects to be less useful than you had originally intended. We believe that you can accomplish your goal (of providing MSOs with the data they need to create the statistics) and circumvent the three problems listed above if you slightly modify your approach. We think the modified approach should be based on counters. All of the data required for the statistical measurements (raw bandwidth, data passed, etc.) can be passed up as counters. The counters can be sampled from each SNMP manager with sampling rates that correspond to their desired resolutions. Thus, an SNMP manager can take a first counter sample at the beginning of the desired window and a second counter sample at the end of the window, and it can then subtract the two counter values and divide by the window size to create the average. As a result of this approach, multiple SNMP managers can access the counters and not interfere with one another. In addition, a single SNMP manager can maintain both long-term and short-term statistics by taking samples with both short and long windows that are overlapping one another. We believe that this approach provides more flexibility in displaying the statistical data that MSOs want. Using this counter approach may permit more flexibility and may accommod! ate the needs of more MSOs. Thanks, Tom Tom Cloonan CTO- Broadband Division ARRIS Phone: 630-281-3050 Fax: 630-955-9870 e-mail: tom.cloonan@arrisi.com ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com] Sent: Friday, October 25, 2002 7:04 PM To: Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 << Message: >> << File: image001.png >> << File: image002.jpg >> _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sat Nov 9 20:12:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28061 for ; Sat, 9 Nov 2002 20:12:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAA1Ew425436 for ipcdn-archive@odin.ietf.org; Sat, 9 Nov 2002 20:14:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAA1Evv25368; Sat, 9 Nov 2002 20:14:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA20vHv17362 for ; Fri, 1 Nov 2002 19:57:17 -0500 Received: from mail.correlant.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10658 for ; Fri, 1 Nov 2002 19:54:43 -0500 (EST) Received: from kfriedman (35.82.218.209.transedge.com [209.218.82.35]) by mail.correlant.com (Postfix) with SMTP id 88A12BC0DE; Fri, 1 Nov 2002 17:57:10 -0800 (PST) From: "Kirk Friedman" To: "'George Hart'" , "'Greg White'" , Cc: "'Raftus, David'" , "'DOCSIS 2.0 Majordomo List'" , "'DOCSIS OSS Majordomo List'" , "'Ipcdn List (E-mail)'" , "'Rich Woundy (Work) (E-mail)'" , Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Date: Fri, 1 Nov 2002 16:57:04 -0800 Message-ID: <000401c2820a$c2e274e0$2352dad1@correlant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think George is right. The description should be simpler for docsIfDownChannelTotalBytes. Otherwise it could get very confusing For example, the MPEG header/pointer fields are factored out, but not the Reed-Soloman encoding on the downstream. I'm also not sure how it applies to NULL vs. DOCSIS PIDs. Finally the OSS spec uses the raw downstream rates for the ifTable (RFC 2233) ifSpeed MIB object. Simplify it to docsIfDownChannelTotalBytes. Suggest: docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } Thanks, Kirk Friedman Correlant Communications 15110 Avenue Of Science San Diego, CA., 92128 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of George Hart Sent: Friday, November 01, 2002 1:20 PM To: 'Greg White'; Greg.Gohman@arrisi.com Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@arrisi.com Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 The upstream counters make sense to me, and will be useful in helping operators determine the utilization of the upstream path. I think I understand the concept for downstream, although the description for the object docsIfDownChannelTotalBytes may be confusing. It seems to me this should represent the downstream capacity available, not the number of bytes transported which is enumerated by docsIfDownChannelUsedBytes. One refinement to consider for the upstream is to count minislots available vs used in the contention region separately from the MAP region. These two regions are subject to very different access mechanisms and having separate indications of utilization on these regions could prove helpful. Thanks to all for the hard work in moving this along so aggressively. It will be extremely useful to us. George -----Original Message----- From: Greg White [mailto:g.white@cablelabs.com] Sent: Thursday, October 31, 2002 2:32 PM To: Greg.Gohman@arrisi.com Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@arrisi.com Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Does anyone else have an opinion on this? I will try to flesh out the proposal: Leave the utilization table as is (with the clarification that Margo proposed IMO), and add the following objects: docsIfUpChannelTotalMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots defined for this upstream (logical) channel. This count includes all minislots, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 20 } docsIfUpChannelUsedMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots utilized on the upstream (logical) channel, regardless of burst type. For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the upstream (logical) channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the logical channel. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 21 } docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes in the DOCSIS Payload portion of DOCSIS MPEG Packets (i.e. not including MPEG Header or pointer_field, nor including any non-DOCSIS MPEG packets) transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } docsIfDownChannelUsedBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of DOCSIS data bytes transported by this downstream channel since CMTS initialization. The number of data bytes is defined as the total number of bytes transported in DOCSIS Payloads minus the number of stuff_bytes transported in DOCSIS Payloads. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 9 } -----Original Message----- From: Greg.Gohman@ARRISI.COM [mailto:Greg.Gohman@ARRISI.COM] Sent: Wednesday, October 30, 2002 10:30 AM To: Greg White Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 We are agreeable with your suggestion. And we can compromise for the utilization table if still desired by the MSOs. Regards, Greg & Tom C. "Greg White" 10/28/02 01:05 PM To: "Raftus, David" , cc: "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Greg.Gohman@ARRISI.COM" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 All, Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments. Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB. If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell. Just thinking out-loud here.... If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization. 1) 64bit counter for raw minislots, per logical channel 2) 64bit counter for minislots used, per logical channel I don't think that either of these counters, or anything close, is available now. In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval. In the case of two (or more) logical channels, the calculation is not as straightforward. Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result. The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel. So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above. It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up. A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable. Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead. Something similar would have to be added to the docsIfDownChannelTable as well. Thoughts? -Greg -----Original Message----- From: Raftus, David [mailto:david.raftus@imedia.com] Sent: Monday, October 28, 2002 8:21 AM To: 'Tom.Cloonan@arrisi.com'; Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Hi Tom, Thanks for your well-considered comments. I need to state initially though that the MSOs have already told us what they want - the channel utilization mib design originated with them, not with me. I simply structured their needs into the mib design. I fear that your proposed changes may be seen as an attempt to 'tell the customer what they want', when they already have expressed their desires. Please see individual responses inline. Regards, Dave Dave, Thanks for the quick response on Greg's email. Greg and I were discussing this topic earlier, and we agreed that the basic premise behind your proposal (allowing MSOs to view statistics on a physical interface) is very sound and quite desirable. We were even discussing how many MSOs already acquired and displayed a lot of these statistical measurements via MRTG calculations of SNMP-acquired counts, so we acknowledge the value of the statistical measurements. We also like the idea of "displaying one line per physical channel summary of utilization stats in displays", but the manner in which the data is displayed seems not to be related to how the data is stored in the MIB. We think that the goal of displaying one line per physical channel can be accomplished in many ways without affecting the manner in which the data is stored or sampled. There are a few fundamental areas of concern within the draft, so we wanted to discuss alternatives to the specific approach that was described in the draft. Our biggest concern with the existing proposal was the requirement that there be a fixed sampling interval. We believe several problems can occur as a result of that approach. 1) Consider the case where multiple SNMP managers are accessing the CMTS. The biggest problem with the proposal in the draft seems to be the fact that it precludes multiple SNMP managers from simultaneously accessing the statistical data if they have different desired sampling intervals. In that case, the last SNMP manager to set the sampling interval wins and destroys the resolution of the accesses for all of the other SNMP managers that were already accessing the CMTS data. In addition, the other SNMP managers are not even aware that their data collection was corrupted without checking. If this situation occurs, I believe it would be an MSO management problem. Multiple snmp managers with write access to the CMTS would seem to be an undesirable dangerous situation. Writable parameters in any table could conceivably be changed by one manager without being known by the others. I could see the merit in adding an object to record when either when the most recent interval started, or when it would end. 2) The problem also shows up if you have a single SNMP manager that is trying to collect data with high-resolution (short sampling intervals) and with low-resolution (long sampling intervals) for the same window of time. Unless I am missing something, the proposed approach seems not to support this requirement, which we have seen to be desired by MSOs that display their statistics with MRTG. This is desirable, because the low-resolution sampling is useful for displaying long-term average measurements whereas the high-resolution sampling is useful for displaying short-term (burst) measurements. I do not see that the new utilization table precludes an MSO from doing this. They are certainly free to use existing counters to setup sampling intervals, etc as they wish for more complicated statistical scenarios. The new utilization table is there for their convenience and at their suggestion. It provides an easy method of measuring simple physical channel utilization. 3) If stored in the fashion that you described and if the sampling interval is set up to collect high resolution statistics (with a short sampling interval), then collecting an approximate low resolution statistic (with a long sampling interval) will require the SNMP manager to store ALL of the samples that the agent creates with the short sampling intervals and "averaging the averages". However, to do this averaging of averages, the SNMP manager's collection process must be synchronized to the sampling window on the CMTS to sample ALL of the sampling intervals. Otherwise, it may miss some of the samples or over-sample a window more than once. Since it is not likely that the SNMP manager will be synchronized with the CMTS sampling interval, this approximation (using an average of averages) is unlikely to be correct in a real-world implementation. Similar reply as to 2). Please view the utilization table as a quick fairly accurate summary of activity. This doesn't stop the MSO from gathering statistics and garnering the more detailed information they want through other methods available to them. Because of these deficiencies within the proposed draft, we believe that MSOs may find the resulting MIB objects to be less useful than you had originally intended. We believe that you can accomplish your goal (of providing MSOs with the data they need to create the statistics) and circumvent the three problems listed above if you slightly modify your approach. We think the modified approach should be based on counters. All of the data required for the statistical measurements (raw bandwidth, data passed, etc.) can be passed up as counters. The counters can be sampled from each SNMP manager with sampling rates that correspond to their desired resolutions. Thus, an SNMP manager can take a first counter sample at the beginning of the desired window and a second counter sample at the end of the window, and it can then subtract the two counter values and divide by the window size to create the average. As a result of this approach, multiple SNMP managers can access the counters and not interfere with one another. In addition, a single SNMP manager can maintain both long-term and short-term statistics by taking samples with both short and long windows that are overlapping one another. We believe that this approach provides more flexibility in displaying the statistical data that MSOs want. Using this counter approach may permit more flexibility and may accommod! ate the needs of more MSOs. Thanks, Tom Tom Cloonan CTO- Broadband Division ARRIS Phone: 630-281-3050 Fax: 630-955-9870 e-mail: tom.cloonan@arrisi.com ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com] Sent: Friday, October 25, 2002 7:04 PM To: Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 << Message: >> << File: image001.png >> << File: image002.jpg >> _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sat Nov 9 20:12:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28102 for ; Sat, 9 Nov 2002 20:12:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAA1F0a25453 for ipcdn-archive@odin.ietf.org; Sat, 9 Nov 2002 20:15:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAA1Ewv25434; Sat, 9 Nov 2002 20:14:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MFnv25459 for ; Thu, 7 Nov 2002 17:15:49 -0500 Received: from alpha.jnpr.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15413 for ; Thu, 7 Nov 2002 17:13:13 -0500 (EST) Received: from electron.jnpr.net ([172.24.15.21]) by alpha.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 14:15:41 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 7 Nov 2002 14:15:40 -0800 Message-ID: <5EB31780BD297F46812C8F495FA08F6201E6E1@electron.jnpr.net> Thread-Topic: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Thread-Index: AcKBM0oXCmPbszb0RR2ZzAcW7E9ztAFTPkmQAAj6KgA= From: "Victor Hou" To: "Greg White" , "Raftus, David" , "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Ipcdn List (E-mail)" X-OriginalArrivalTime: 07 Nov 2002 22:15:41.0678 (UTC) FILETIME=[359C98E0:01C286AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA7MFov25460 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Greg, In general, that is what I intended regarding my previous point 1. The only point I was debating (with myself) was whether to consider all IM regions as utilized bytes regardless of whether a burst was received or not. I am open to this as an alternative for IM. On the issue of received bursts in contention regions, I would favor considering a received burst as one that was received correctly. Thus, I suggest wording to be added: "A received burst means that the burst was correctly received such that the HCS and CRC checks on the DOCSIS frames are correct." Victor -----Original Message----- From: Greg White [mailto:g.white@CableLabs.com] Sent: Thursday, November 07, 2002 9:20 AM To: Victor Hou; Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Victor, To summarize, your suggestion is the following? Upstream Channel Utilization Index: The upstream channel utilization index is expressed as a percentage of minislots utilized on the physical channel, regardless of burst type. For an Initial Maintenance region, the minislots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel. For contention REQ and REQ/DATA regions, the minislots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the physical channel. If that is what you intended, then I'm fine with that language. Regarding your question 2, I guess that only applies to contention regions, so I would think that the most common causes of a burst being received and not properly demodulated/decoded would be either initial RNG-REQs that are either too faint or too strong, or collisions. In either case, I don't have a strong opinion, but counting all bursts, even those that fail HCS or CRC would seem to match the philosophy used for UGS. In other words, if it is preventing another CM from using those minislots, it should be counted. -Greg -----Original Message----- From: Victor Hou [mailto:vhou@juniper.net] Sent: Thursday, October 31, 2002 4:15 PM To: Greg White; Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Just to tighten things a little further, two minor items need to be addressed with previously suggested wording: 1. Initial Maintenance regions typically encompass a large number of mini-slots while the the number of mini-slots actually required to send the RNG-REQ is small. Margo's suggested wording was as follows: "For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the physical channel." First, it should be stated that the term "regions" as used in the RFI spec refers to a number of contiguous mini-slots defined by an Information Element in the MAP. So, it is understood that a contention "region" can have multiple transmission opportunities. However, it is possible that an informational note would be helpful in the MIB object description. But back to the main topic... For Initial Maintenance regions, the wording above would suggest to count only the minislots used for the RNG-REQ. It is not clear what the original intent was, but since minislots that are allocated for Initial Maintenance cannot be used for anything else, it appears that the duration of the complete region, translated into minislots, should be counted as "utilized slots." If that is the case, a specific sentence like the following should be added: "For an Initial Maintenance region, the minislots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel." There is, of course, another alternative--which is to count all mini-slots allocated to Initial Maintenance as utilized, whether used or not. In most normal scenarios, the difference between the two approaches will be negligible with respect to the reported utilization, but not necessarily for all. As for contention REQ and REQ/DATA regions, there may be multiple opportunities within the region. And in that case, we should alter the above to: "For contention REQ and REQ/DATA regions, the minislots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel." 2. What does it mean to "receive a burst"? Does this mean a burst of some sort was detected or the burst was received correctly? In low Packet Error Rate scenarios, the difference is completely negligible, but in other cases, that would not be true. I believe the intent is to count only correctly received bursts after forward error correction is performed. Victor -----Original Message----- From: Greg White [mailto:g.white@cablelabs.com] Sent: Thursday, October 31, 2002 11:32 AM To: Greg.Gohman@ARRISI.COM Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Does anyone else have an opinion on this? I will try to flesh out the proposal: Leave the utilization table as is (with the clarification that Margo proposed IMO), and add the following objects: docsIfUpChannelTotalMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots defined for this upstream (logical) channel. This count includes all minislots, even those allocated to the NULL SID for a 2.0 logical channel which is inactive. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 20 } docsIfUpChannelUsedMinislots OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of minislots utilized on the upstream (logical) channel, regardless of burst type. For contention regions, utilized minislots are those in which the CMTS received an upstream burst from any CM on the upstream (logical) channel. For all other regions, utilized minislots are those in which the CMTS granted bandwidth to any unicast SID on the logical channel. For the CM this object is reported as 0." ::= { docsIfUpstreamChannelEntry 21 } docsIfDownChannelTotalBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bytes in the DOCSIS Payload portion of DOCSIS MPEG Packets (i.e. not including MPEG Header or pointer_field, nor including any non-DOCSIS MPEG packets) transported by this downstream channel since CMTS initialization. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 8 } docsIfDownChannelUsedBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of DOCSIS data bytes transported by this downstream channel since CMTS initialization. The number of data bytes is defined as the total number of bytes transported in DOCSIS Payloads minus the number of stuff_bytes transported in DOCSIS Payloads. For the CM this object is reported as 0." ::= { docsIfDownstreamChannelEntry 9 } -----Original Message----- From: Greg.Gohman@ARRISI.COM [mailto:Greg.Gohman@ARRISI.COM] Sent: Wednesday, October 30, 2002 10:30 AM To: Greg White Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 We are agreeable with your suggestion. And we can compromise for the utilization table if still desired by the MSOs. Regards, Greg & Tom C. "Greg White" 10/28/02 01:05 PM To: "Raftus, David" , cc: "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Greg.Gohman@ARRISI.COM" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 All, Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments. Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB. If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell. Just thinking out-loud here.... If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization. 1) 64bit counter for raw minislots, per logical channel 2) 64bit counter for minislots used, per logical channel I don't think that either of these counters, or anything close, is available now. In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval. In the case of two (or more) logical channels, the calculation is not as straightforward. Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result. The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel. So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above. It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up. A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable. Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead. Something similar would have to be added to the docsIfDownChannelTable as well. Thoughts? -Greg -----Original Message----- From: Raftus, David [mailto:david.raftus@imedia.com] Sent: Monday, October 28, 2002 8:21 AM To: 'Tom.Cloonan@arrisi.com'; Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Hi Tom, Thanks for your well-considered comments. I need to state initially though that the MSOs have already told us what they want - the channel utilization mib design originated with them, not with me. I simply structured their needs into the mib design. I fear that your proposed changes may be seen as an attempt to 'tell the customer what they want', when they already have expressed their desires. Please see individual responses inline. Regards, Dave Dave, Thanks for the quick response on Greg's email. Greg and I were discussing this topic earlier, and we agreed that the basic premise behind your proposal (allowing MSOs to view statistics on a physical interface) is very sound and quite desirable. We were even discussing how many MSOs already acquired and displayed a lot of these statistical measurements via MRTG calculations of SNMP-acquired counts, so we acknowledge the value of the statistical measurements. We also like the idea of "displaying one line per physical channel summary of utilization stats in displays", but the manner in which the data is displayed seems not to be related to how the data is stored in the MIB. We think that the goal of displaying one line per physical channel can be accomplished in many ways without affecting the manner in which the data is stored or sampled. There are a few fundamental areas of concern within the draft, so we wanted to discuss alternatives to the specific approach that was described in the draft. Our biggest concern with the existing proposal was the requirement that there be a fixed sampling interval. We believe several problems can occur as a result of that approach. 1) Consider the case where multiple SNMP managers are accessing the CMTS. The biggest problem with the proposal in the draft seems to be the fact that it precludes multiple SNMP managers from simultaneously accessing the statistical data if they have different desired sampling intervals. In that case, the last SNMP manager to set the sampling interval wins and destroys the resolution of the accesses for all of the other SNMP managers that were already accessing the CMTS data. In addition, the other SNMP managers are not even aware that their data collection was corrupted without checking. If this situation occurs, I believe it would be an MSO management problem. Multiple snmp managers with write access to the CMTS would seem to be an undesirable dangerous situation. Writable parameters in any table could conceivably be changed by one manager without being known by the others. I could see the merit in adding an object to record when either when the most recent interval started, or when it would end. 2) The problem also shows up if you have a single SNMP manager that is trying to collect data with high-resolution (short sampling intervals) and with low-resolution (long sampling intervals) for the same window of time. Unless I am missing something, the proposed approach seems not to support this requirement, which we have seen to be desired by MSOs that display their statistics with MRTG. This is desirable, because the low-resolution sampling is useful for displaying long-term average measurements whereas the high-resolution sampling is useful for displaying short-term (burst) measurements. I do not see that the new utilization table precludes an MSO from doing this. They are certainly free to use existing counters to setup sampling intervals, etc as they wish for more complicated statistical scenarios. The new utilization table is there for their convenience and at their suggestion. It provides an easy method of measuring simple physical channel utilization. 3) If stored in the fashion that you described and if the sampling interval is set up to collect high resolution statistics (with a short sampling interval), then collecting an approximate low resolution statistic (with a long sampling interval) will require the SNMP manager to store ALL of the samples that the agent creates with the short sampling intervals and "averaging the averages". However, to do this averaging of averages, the SNMP manager's collection process must be synchronized to the sampling window on the CMTS to sample ALL of the sampling intervals. Otherwise, it may miss some of the samples or over-sample a window more than once. Since it is not likely that the SNMP manager will be synchronized with the CMTS sampling interval, this approximation (using an average of averages) is unlikely to be correct in a real-world implementation. Similar reply as to 2). Please view the utilization table as a quick fairly accurate summary of activity. This doesn't stop the MSO from gathering statistics and garnering the more detailed information they want through other methods available to them. Because of these deficiencies within the proposed draft, we believe that MSOs may find the resulting MIB objects to be less useful than you had originally intended. We believe that you can accomplish your goal (of providing MSOs with the data they need to create the statistics) and circumvent the three problems listed above if you slightly modify your approach. We think the modified approach should be based on counters. All of the data required for the statistical measurements (raw bandwidth, data passed, etc.) can be passed up as counters. The counters can be sampled from each SNMP manager with sampling rates that correspond to their desired resolutions. Thus, an SNMP manager can take a first counter sample at the beginning of the desired window and a second counter sample at the end of the window, and it can then subtract the two counter values and divide by the window size to create the average. As a result of this approach, multiple SNMP managers can access the counters and not interfere with one another. In addition, a single SNMP manager can maintain both long-term and short-term statistics by taking samples with both short and long windows that are overlapping one another. We believe that this approach provides more flexibility in displaying the statistical data that MSOs want. Using this counter approach may permit more flexibility and may accommod! ate the needs of more MSOs. Thanks, Tom Tom Cloonan CTO- Broadband Division ARRIS Phone: 630-281-3050 Fax: 630-955-9870 e-mail: tom.cloonan@arrisi.com ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com] Sent: Friday, October 25, 2002 7:04 PM To: Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 << Message: >> << File: image001.png >> << File: image002.jpg >> _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sat Nov 9 21:10:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28058 for ; Sat, 9 Nov 2002 20:12:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAA1Ewx25420 for ipcdn-archive@odin.ietf.org; Sat, 9 Nov 2002 20:14:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAA1Ewv25383; Sat, 9 Nov 2002 20:14:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KZ2v15436 for ; Thu, 7 Nov 2002 15:35:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [ipcdn] Note Well Statement Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sat Nov 9 21:10:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28056 for ; Sat, 9 Nov 2002 20:12:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAA1EwV25393 for ipcdn-archive@odin.ietf.org; Sat, 9 Nov 2002 20:14:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAA1Euv25338; Sat, 9 Nov 2002 20:14:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UHVuv19916 for ; Wed, 30 Oct 2002 12:31:56 -0500 Received: from thor.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27392 for ; Wed, 30 Oct 2002 12:29:27 -0500 (EST) From: Greg.Gohman@ARRISI.COM To: "Greg White" Cc: "Raftus, David" , "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" , Tom.Cloonan@ARRISI.COM Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 30 Oct 2002 11:29:59 -0600 X-MIMETrack: Serialize by Router on Thor/Arris(Release 5.0.9a |January 7, 2002) at 10/30/2002 11:29:54 AM, Serialize complete at 10/30/2002 11:29:54 AM Content-Type: multipart/alternative; boundary="=_alternative 00604E5986256C62_=" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00604E5986256C62_= Content-Type: text/plain; charset="us-ascii" We are agreeable with your suggestion. And we can compromise for the utilization table if still desired by the MSOs. Regards, Greg & Tom C. "Greg White" 10/28/02 01:05 PM To: "Raftus, David" , cc: "DOCSIS 2.0 Majordomo List" , "DOCSIS OSS Majordomo List" , "Greg.Gohman@ARRISI.COM" , "Ipcdn List (E-mail)" , "Rich Woundy (Work) (E-mail)" Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 All, Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments. Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB. If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell. Just thinking out-loud here.... If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization. 1) 64bit counter for raw minislots, per logical channel 2) 64bit counter for minislots used, per logical channel I don't think that either of these counters, or anything close, is available now. In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval. In the case of two (or more) logical channels, the calculation is not as straightforward. Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result. The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel. So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above. It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up. A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable. Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead. Something similar would have to be added to the docsIfDownChannelTable as well. Thoughts? -Greg -----Original Message----- From: Raftus, David [mailto:david.raftus@imedia.com] Sent: Monday, October 28, 2002 8:21 AM To: 'Tom.Cloonan@arrisi.com'; Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail) Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5 Hi Tom, Thanks for your well-considered comments. I need to state initially though that the MSOs have already told us what they want - the channel utilization mib design originated with them, not with me. I simply structured their needs into the mib design. I fear that your proposed changes may be seen as an attempt to 'tell the customer what they want', when they already have expressed their desires. Please see individual responses inline. Regards, Dave Dave, Thanks for the quick response on Greg's email. Greg and I were discussing this topic earlier, and we agreed that the basic premise behind your proposal (allowing MSOs to view statistics on a physical interface) is very sound and quite desirable. We were even discussing how many MSOs already acquired and displayed a lot of these statistical measurements via MRTG calculations of SNMP-acquired counts, so we acknowledge the value of the statistical measurements. We also like the idea of "displaying one line per physical channel summary of utilization stats in displays", but the manner in which the data is displayed seems not to be related to how the data is stored in the MIB. We think that the goal of displaying one line per physical channel can be accomplished in many ways without affecting the manner in which the data is stored or sampled. There are a few fundamental areas of concern within the draft, so we wanted to discuss alternatives to the specific approach that was described in the draft. Our biggest concern with the existing proposal was the requirement that there be a fixed sampling interval. We believe several problems can occur as a result of that approach. 1) Consider the case where multiple SNMP managers are accessing the CMTS. The biggest problem with the proposal in the draft seems to be the fact that it precludes multiple SNMP managers from simultaneously accessing the statistical data if they have different desired sampling intervals. In that case, the last SNMP manager to set the sampling interval wins and destroys the resolution of the accesses for all of the other SNMP managers that were already accessing the CMTS data. In addition, the other SNMP managers are not even aware that their data collection was corrupted without checking. If this situation occurs, I believe it would be an MSO management problem. Multiple snmp managers with write access to the CMTS would seem to be an undesirable dangerous situation. Writable parameters in any table could conceivably be changed by one manager without being known by the others. I could see the merit in adding an object to record when either when the most recent interval started, or when it would end. 2) The problem also shows up if you have a single SNMP manager that is trying to collect data with high-resolution (short sampling intervals) and with low-resolution (long sampling intervals) for the same window of time. Unless I am missing something, the proposed approach seems not to support this requirement, which we have seen to be desired by MSOs that display their statistics with MRTG. This is desirable, because the low-resolution sampling is useful for displaying long-term average measurements whereas the high-resolution sampling is useful for displaying short-term (burst) measurements. I do not see that the new utilization table precludes an MSO from doing this. They are certainly free to use existing counters to setup sampling intervals, etc as they wish for more complicated statistical scenarios. The new utilization table is there for their convenience and at their suggestion. It provides an easy method of measuring simple physical channel utilization. 3) If stored in the fashion that you described and if the sampling interval is set up to collect high resolution statistics (with a short sampling interval), then collecting an approximate low resolution statistic (with a long sampling interval) will require the SNMP manager to store ALL of the samples that the agent creates with the short sampling intervals and "averaging the averages". However, to do this averaging of averages, the SNMP manager's collection process must be synchronized to the sampling window on the CMTS to sample ALL of the sampling intervals. Otherwise, it may miss some of the samples or over-sample a window more than once. Since it is not likely that the SNMP manager will be synchronized with the CMTS sampling interval, this approximation (using an average of averages) is unlikely to be correct in a real-world implementation. Similar reply as to 2). Please view the utilization table as a quick fairly accurate summary of activity. This doesn't stop the MSO from gathering statistics and garnering the more detailed information they want through other methods available to them. Because of these deficiencies within the proposed draft, we believe that MSOs may find the resulting MIB objects to be less useful than you had originally intended. We believe that you can accomplish your goal (of providing MSOs with the data they need to create the statistics) and circumvent the three problems listed above if you slightly modify your approach. We think the modified approach should be based on counters. All of the data required for the statistical measurements (raw bandwidth, data passed, etc.) can be passed up as counters. The counters can be sampled from each SNMP manager with sampling rates that correspond to their desired resolutions. Thus, an SNMP manager can take a first counter sample at the beginning of the desired window and a second counter sample at the end of the window, and it can then subtract the two counter values and divide by the window size to create the average. As a result of this approach, multiple SNMP managers can access the counters and not interfere with one another. In addition, a single SNMP manager can maintain both long-term and short-term statistics by taking samples with both short and long windows that are overlapping one another. We believe that this approach provides more flexibility in displaying the statistical data that MSOs want. Using this counter approach may permit more flexibility and may accommod! ate the needs of more MSOs. Thanks, Tom Tom Cloonan CTO- Broadband Division ARRIS Phone: 630-281-3050 Fax: 630-955-9870 e-mail: tom.cloonan@arrisi.com ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com] Sent: Friday, October 25, 2002 7:04 PM To: Raftus, David Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail); owner-docsis-20@cablelabs.com Subject: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 25 << Message: >> << File: image001.png >> << File: image002.jpg >> --=_alternative 00604E5986256C62_= Content-Type: text/html; charset="us-ascii"
We are agreeable with your suggestion.
And we can compromise for the utilization table if still desired by the MSOs.

Regards,
Greg & Tom C.




"Greg White" <g.white@CableLabs.com>

10/28/02 01:05 PM

       
        To:        "Raftus, David" <david.raftus@imedia.com>, <Tom.Cloonan@arrisi.com>
        cc:        "DOCSIS 2.0 Majordomo List" <docsis-20@CableLabs.com>, "DOCSIS OSS Majordomo List" <docsis-oss@CableLabs.com>, "Greg.Gohman@ARRISI.COM" <Greg.Gohman@arrisi.com>, "Ipcdn List (E-mail)" <ipcdn@ietf.org>, "Rich Woundy (Work) (E-mail)" <rwoundy@broadband.att.com>
        Subject:        RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct 2 5



All,

Since I originally presented to this group the desire of MSOs to have channel utilization information, I thought I'd chime in with some comments.

Dave's comments notwithstanding, I think Tom did raise some interesting points about the side-effects of making a very simple snapshot view of channel utilization available via the MIB.  If we can come up with an alternative that still meets the operators' needs and does not have these side-effects, then I think it would not be a difficult sell.

Just thinking out-loud here....

If running counters were used, I think the following would be all that is absolutely necessary for calculating upstream utilization.

1) 64bit counter for raw minislots, per logical channel
2) 64bit counter for minislots used, per logical channel

I don't think that either of these counters, or anything close, is available now.

In the case of a single logical channel, the calculation is clear: query both objects at the start of the interval, then at the end, take the ratio of the two deltas and you get the utilization, in percent, over the interval.

In the case of two (or more) logical channels, the calculation is not as straightforward.  Assuming that counter 1 includes minislots allocated to the null SID (while the logical channel is idle), then the operator could calculate % utilization for each logical channel, and sum them to get the total utilization for the physical channel. There is some ambiguity in the case where initial maintenance slots are shared between the logical channels, but that exists regardless of how utilization is reported, and even if not resolved would probably have a negligible impact on the end result.

The operator would have to use the ifStackTable to associate the logical channels, since I don't see a simple way of reporting these counters in aggregate for the physical channel.


So rather than a single MIB object to query to get a snapshot of the utilization, the operator would (in general) have to identify the ifIndex of the physical channel in question, query the ifStackTable to identify all logical channels associated with that physical channel, then query the two counters on each logical channel at the start and end of the interval and do the math above.  It certainly isn't as straightforward as a single MIB object for utilization percentage, but also doesn't have the side-effects that Tom brought up.

A possible compromise would be to leave the utilization table as is, and add the two counters above to the docsIfUpstreamChannelTable.  Since the CMTS probably has to maintain these counters anyway in order to report utilization, maybe this would not add much overhead.  Something similar would have to be added to the docsIfDownChannelTable as well.

Thoughts?

-Greg






-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, October 28, 2002 8:21 AM
To: 'Tom.Cloonan@arrisi.com'; Raftus, David
Cc: Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector
(E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail);
owner-docsis-20@cablelabs.com; Rich Woundy (Work) (E-mail)
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5


Hi Tom,

Thanks for your well-considered comments. I need to state initially though
that the MSOs have already told us what they want - the channel utilization
mib design originated with them, not with me. I simply structured their
needs into the mib design. I fear that your proposed changes may be seen as
an attempt to 'tell the customer what they want', when they already have
expressed their desires.

Please see individual responses inline.

Regards,
Dave



Dave,

Thanks for the quick response on Greg's email.

Greg and I were discussing this topic earlier, and we agreed that the basic
premise behind your proposal (allowing MSOs to view statistics on a physical
interface) is very sound and quite desirable. We were even discussing how
many MSOs already acquired and displayed a lot of these statistical
measurements via MRTG calculations of SNMP-acquired counts, so we
acknowledge the value of the statistical measurements.

We also like the idea of "displaying one line per physical channel summary
of utilization stats in displays", but the manner in which the data is
displayed seems not to be related to how the data is stored in the MIB. We
think that the goal of displaying one line per physical channel can be
accomplished in many ways without affecting the manner in which the data is
stored or sampled.

There are a few fundamental areas of concern within the draft, so we wanted
to discuss alternatives to the specific approach that was described in the
draft.

Our biggest concern with the existing proposal was the requirement that
there be a fixed sampling interval. We believe several problems can occur as
a result of that approach.

1) Consider the case where multiple SNMP managers are accessing the CMTS.
The biggest problem with the proposal in the draft seems to be the fact that
it precludes multiple SNMP managers from simultaneously accessing the
statistical data if they have different desired sampling intervals. In that
case, the last SNMP manager to set the sampling interval wins and destroys
the resolution of the accesses for all of the other SNMP managers that were
already accessing the CMTS data. In addition, the other SNMP managers are
not even aware that their data collection was corrupted without checking.

<dave>
If this situation occurs, I believe it would be an MSO management problem.
Multiple snmp managers with write access to the CMTS would seem to be an
undesirable dangerous situation. Writable parameters in any table could
conceivably be changed by one manager without being known by the others.
I could see the merit in adding an object to record when either when the
most recent interval started, or when it would end.  
<end dave>


2) The problem also shows up if you have a single SNMP manager that is
trying to collect data with high-resolution (short sampling intervals) and
with low-resolution (long sampling intervals) for the same window of time.
Unless I am missing something, the proposed approach seems not to support
this requirement, which we have seen to be desired by MSOs that display
their statistics with MRTG. This is desirable, because the low-resolution
sampling is useful for displaying long-term average measurements whereas the
high-resolution sampling is useful for displaying short-term (burst)
measurements.

<dave>
I do not see that the new utilization table precludes an MSO from doing
this. They are certainly free to use existing counters to setup sampling
intervals, etc as they wish for more complicated statistical scenarios. The
new utilization table is there for their convenience and at their
suggestion. It provides an easy method of measuring simple physical channel
utilization.
<end dave>

3) If stored in the fashion that you described and if the sampling interval
is set up to collect high resolution statistics (with a short sampling
interval), then collecting an approximate low resolution statistic (with a
long sampling interval) will require the SNMP manager to store ALL of the
samples that the agent creates with the short sampling intervals and
"averaging the averages". However, to do this averaging of averages, the
SNMP manager's collection process must be synchronized to the sampling
window on the CMTS to sample ALL of the sampling intervals. Otherwise,  it
may miss some of the samples or over-sample a window more than once. Since
it is not likely that the SNMP manager will be synchronized with the CMTS
sampling interval, this approximation (using an average of averages) is
unlikely to be correct in a real-world implementation.

<dave>
Similar reply as to 2). Please view the utilization table as a quick fairly
accurate summary of activity. This doesn't stop the MSO from gathering
statistics and garnering the more detailed information they want through
other methods available to them.
<end dave>

Because of these deficiencies within the proposed draft, we believe that
MSOs may find the resulting MIB objects to be less useful than you had
originally intended.

We believe that you can accomplish your goal (of providing MSOs with the
data they need to create the statistics) and circumvent the three problems
listed above if you slightly modify your approach. We think the modified
approach should be based on counters.

All of the data required for the statistical measurements (raw bandwidth,
data passed, etc.) can be passed up as counters. The counters can be sampled
from each SNMP manager with sampling rates that correspond to their desired
resolutions. Thus, an SNMP manager can take a first counter sample at the
beginning of the desired window and a second counter sample at the end of
the window, and it can then subtract the two counter values and divide by
the window size to create the average. As a result of this approach,
multiple SNMP managers can access the counters and not interfere with one
another. In addition, a single SNMP manager can maintain both long-term and
short-term statistics by taking samples with both short and long windows
that are overlapping one another. We believe that this approach provides
more flexibility in displaying the statistical data that MSOs want. Using
this counter approach may permit more flexibility and may accommod! ate the
needs of more MSOs.

Thanks,
Tom


Tom Cloonan
CTO- Broadband Division
ARRIS

Phone:  630-281-3050
Fax:       630-955-9870
e-mail:    tom.cloonan@arrisi.com

************************************
David Raftus
Imedia Semiconductor
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2

david.raftus@imedia.com          
613.592.1052  ext 222
************************************              


-----Original Message-----
From:                  Tom.Cloonan@arrisi.com [mailto:Tom.Cloonan@arrisi.com]
Sent:                 Friday, October 25, 2002 7:04 PM
To:                 Raftus, David
Cc:                 Raftus, David; Docsis 20 Reflector (E-mail); Docsis Oss Reflector
(E-mail); 'Greg.Gohman@ARRISI.COM'; Ipcdn List (E-mail);
owner-docsis-20@cablelabs.com
Subject:                 [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
25

<< Message:  >>  << File: image001.png >>  << File: image002.jpg >>


--=_alternative 00604E5986256C62_=-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Nov 20 14:19:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28092 for ; Wed, 20 Nov 2002 14:19:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKJLct06575 for ipcdn-archive@odin.ietf.org; Wed, 20 Nov 2002 14:21:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKJLbv06569; Wed, 20 Nov 2002 14:21:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKJGXv06305 for ; Wed, 20 Nov 2002 14:16:33 -0500 Received: from puffin.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27945 for ; Wed, 20 Nov 2002 14:13:48 -0500 (EST) Received: from stjohns-laptop.ietf55.ops.ietf.org ([204.42.73.225] helo=STJOHNS-LAPTOP.mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:DES-CBC3-SHA:168) (Exim 3.33 #1) id 18EaKX-0006oW-00; Wed, 20 Nov 2002 11:16:09 -0800 Message-Id: <5.1.0.14.2.20021120133501.03ba2008@pop.mindspring.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Nov 2002 14:14:32 -0500 To: "Wijnen, Bert (Bert)" , wsawyer@ieee.org, ipcdn@ietf.org From: Michael StJohns Subject: Re: [ipcdn] MIB Doctor review of: draft-ietf-ipcdn-subscriber-mib-06.txt Cc: "Thomas Narten (E-mail)" , "Erik Nordmark (E-mail)" , "Bert Wijnen (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d0c5f5075e081e846626cb54163c86bcb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , At 05:27 PM 10/1/2002 +0200, Wijnen, Bert (Bert) wrote: >Took a bit longer than I had hoped. Oh well, here we go > >More or less serious issues/concerns: >- 2nd para in Section 2 starts off with: > "Much of this MIB duplicates capabilities found in > the DOCSIS Cable Device MIB [17]." > So I immediately wonder why we need to duplicate any of > that other stuff, even without looking at the details. > Pls explain/justify. > The other praragraphs in this section try to explain some > of it I think. But what is not clear is: will this MIB > then obsolete the one in reference [17]. > If it only partially obsoletes/replaces it, then maybe > that should be made clear and the [17] may need a > revision to deprecate the objects being replaced. These objects were added to permit policy control to occur two places - in the CMTS and in the cable modem. The original model (that described in the cable device mib) assumed that CMs were owned and controlled by the cable operator and that it would be pretty hard to hack them. The new model makes the assumption that some cable modems might be the equivalent of WINMODEMS - e.g. a little bit of hardware to do modulation, with software to do all the rest of the functions - like filtering. Since a filtering capability is critical for operator control of the service, this MIB was created to describe the functionality required in the CMTS where it wouldn't be subject to customer hacking of a software modem. This is a seperate MIB from the other MIB, it mostly applies to a different device (the CMTS) - the other MIB will not necessarily be deprecated and you shouldn't consider whether it will or not in your comments. >- In sect 2.1 you write: > "The docsSubMgtCpeControlTable, docsSubMgtCpeIpTable, > and docsSubMgtCmFilterTable augment the > docsIfCmtsCmStatusTable from [18]." > I do see this is true for docsSubMgtCpeControlTable but > for docsSubMgtCmFilterTable you are not using the AUGMENTS > clause. So maybe it is only a sparse augmentation? If so, > the better say so. If it is a real AUGMENT then use the > AUGMENTS clause. >- Mmm... sect 2.2 starts to talk about the use of TFTTTP... > what does that have to do with the MIB? Maybe explain that > a bit (better). FOr example, why such is needed. And maybe > you can add a reference where people can find info about it. > The good news is that you do mention possible security aspects > (with references) in the Security Considerations section. Hope > it is acceptable to Security ADs. >- Sect 2.3 > I really wonder if this is smart. Why not give a much larger range > to the index objects and then specify via the MODULE COMPLIANCE > that they only need to support up to 1024. That way you do not > have to change the MIB in the future if you ever need more > than 1024. You then add another compliance statement (which > can actually be done in a different module/document) >- The MIB MODULE-IDENTITY also talks about experimental. > You want to removethat if you go for STDs track >- In the MIB you must use 4-digit year notation, so > change > LAST-UPDATED "0202280000Z" -- February 28, 2002 > into > LAST-UPDATED "200202280000Z" -- February 28, 2002 > and also > REVISION "0202280000Z" -- February 28, 2002 > into > REVISION "200202280000Z" -- February 28, 2002 >- Normally, for a new RFC, we only have one REVISION clause. Whatever > changes were made during the WG process are not recorded in revision > clauses, so you can remove the 2nd revision clause. > In fact the one and only revision clause should say something like: > > REVISION "200202280000Z" -- February 28, 2002 > DESCRIPTION "Initial version, published as RFC xxxx." > -- RFC Editor to assign xxxx >- I am not comfortable with you putting this MIB under { docsDev 5 } > How does DCOSIS keep track as to hwo makes assignments under > the docsDev OID subtree? > Why can this not be another assignment under mib-2 ?? > Certainly it should not have been docsDev 5 while you were making > all sorts of changes during the WG process or while it was so > called "experimental" ... >- I see: > docsSubMgtCpeControlReset OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object always returns false on read. If this object is > set to true, the rows with 'learned' addresses in > docsSubMgtCpeIpTable for this CM are deleted from that table." > Mmm.. so if I SET the object to true and do a GET afterwards then it is > back in false? I need to check if SNMP/MIB people are really happy with > this. Bert - This is the appropriate IDIOM for a "push to reset" toggle since the first mib was written and has been used in a number of books as an example of using a mib to control things. What would you expect it to return? "true if it was ever manually reset"? >- I am kind of wondering about the AUGEMENTS for > AUGMENTS { docsIfCmtsCmStatusEntry } > Are all the WG members and potential implementers aware that you are > adding read-write objects to an otherwise read-only table? > I guess it would be good to spell out in the DESCRIPTION clause > of this table: > - that it AUGEMENTS (instead of extends) the docsIfCmtsCmStatusTable Bert - directly from the SMIv2 - this needs no further description here about the meaning of AUGMENTS - this applies to the item above as well: 7.8.1. Relation between INDEX and AUGMENTS clauses When defining instance identification information for a conceptual table: (1) If there is a one-to-one correspondence between the conceptual rows of this table and an existing table, then the AUGMENTS clause should be used. (2) Otherwise, if there is a sparse relationship between the conceptual rows of this table and an existing table, then an INDEX clause should be used which is identical to that in the existing table. For example, the relationship between RFC 2233's ifTable and a media-specific MIB which extends the ifTable for a specific media (e.g., the dot3Table in RFC 2358), is a sparse relationship. (3) Otherwise, if no existing objects have the required syntax and semantics, then auxiliary objects should be defined within the conceptual row for the new table, and those objects should be used within the INDEX clause for the conceptual row. > - that it adds 4 WRITEable objects. >- the following 3 objects that define defaults. Can you explain how > that works and when they come into play. I see that hey do when the > registration fails. So is it that when a cable modem registers, then > this MIB-table (at a device in the provider premises?) gets populated > with whatever the user registers? And if he does not register you still > add entries to this MIB-table and the defaults get picked up in that case? > I may be confused, because neither in this document > nor in RFC2669/2670 did I find where this MIB and the others reside. > Would be good to have a picture of the devices involved, where they > are located adn what their function is. >- table docsSubMgtPktFilterTable is a read-create table. > I see no StorageType object and no words at all about the persistency > of that table. We need to understand the behaviour for persistency. > This comment applies to all your read-create tables. In fact it also > applies (I think) to read-write values of other objects and other > tables as well. >- I see: > docsSubMgtPktFilterGroup Integer32, > docsSubMgtPktFilterIndex Integer32, > docsSubMgtPktFilterSrcAddrType InetAddressType, > docsSubMgtPktFilterSrcAddr InetAddress, > docsSubMgtPktFilterSrcMaskType InetAddressType, > docsSubMgtPktFilterSrcMask InetAddress, > docsSubMgtPktFilterDstAddrType InetAddressType, > docsSubMgtPktFilterDstAddr InetAddress, > docsSubMgtPktFilterDstMaskType InetAddressType, > docsSubMgtPktFilterDstMask InetAddress, > A few remarks/questions > - that would give me the impression that the addressType for > address and mask could be different. > - it also gives me the impression that addressType for source > and destination can be different. > - From your COMPLIANCE section that seems not to be the case > for current implementers of this MIB. > Not clear if it will never be the case in the future. > - Anyway, if addressType is the same, then only one such object > is needed. Maybe an old version of the INET-ADDRESS-MIB did > suggest that you needed multiple. But the current version > as per RFC 3291. > - This new version also suggest to use InetAddressPrefixLength > instead of a mask. Pls take a look at that. >- if the DEFVAL for docsSubMgtPktFilterSrcAddrType is ipv4, > then why is the DEFVAL for docsSubMgtPktFilterSrcAddr not 0.0.0.0? >- same for Destination address >- object docsSubMgtPktFilterUlp says: > DESCRIPTION > "Upper level protocol to match. If this value is 256, > matches ALL ULP values. Otherwise, this matches the specific > protocol value. Note that if the packet ULP is either 6 (tcp) or > 17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be > consulted (if its entry exists) to see if this entry matches. > If this value is neither tcp(6) nor udp(17), then that > table is not consulted." > while object docsSubMgtTcpUdpFilterTable says: > DESCRIPTION ".... This table > is not consulted unless the upper-layer protocol is TCP, > UDP, or 'any'." > So that seems to conflict with each other. (I would also add (256) > after 'any' so it is easier to make the connection. > In the first object you say it is onlu consulted for tcp and udp > and in the table itself you say that it is also consulted for 'any' >- I see: > docsSubMgtPktFilterAction OBJECT-TYPE > SYNTAX INTEGER > { > accept(1), > drop(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The action to take upon this filter matching. Accept means > to accept the packet for further processing. Drop means to drop > the packet." > And I wonder: what does "further processing" mean? Will it be checked > against the next filter... or will it be forwarded, or what. > "drop" seems clear in that the packet gets dropped. >- I see: > docsSubMgtTcpUdpSrcPort Integer32, > docsSubMgtTcpUdpDstPort Integer32, > These probably should be of type InetPortNumber instead, see RFC3291 >- object docsSubMgtTcpFlagValues > says: ..................... An attempt to violate this constraint > returns an inconsistentValue error for an SNMPv2 or v3 agent > and a badValue error for an SNMPv1 agent. > We prefer that you just talk about the inconsistentValue error and > not mention SNMPvx at all. RFC2576 has common procedures to translate > such errors between different versions of SNMP. >- For rowStatus objects, you MUST also indicate which objects must have > proper values before the row can be made active. See RowStatus TC > in RFC2579. SO this comment applies to all your rowStatus objects. >- you have no Notifications, so there seems to be no need to define > docsSubMgtNotification OBJECT IDENTIFIER ::= { docsSubMgt 2 } >- Why have you commented out (in the MODULE COMPLIANCE) > -- SYNTAX InetAddressType { ipv4(1) } > because if you only requite support for IPv4, then that is > exactly how you specify it in the MIB. I know that some older > version of SMICng complians about it... but you can ignore that > error/warning. See for example RFC3289 that uses it too. > Now ... are cable modems not supporting IPv6 and will they not > do so in the (near) future? > Cuase. what might be a problem though is that in principle the > IETF requires support for IPv4 and IPv6 these days. > Thomas or Erik, any comment on that? >- In the security section, you MUST list the objects that are > sensitive (read or read-write or read-create) and then for > each of them explain why they are sensitive and need protection. > >Administrative/editorial nits: >- In the abstract, it talks about "experimental portion". > Should be just "portion" if you're heading for PS. >- the RFC-Editor does not want unfamiliar acronyms in the > title. See http://www.rfc-editor.org/policy.html > I think MIB is OK, but DOSCIS is probably not OK. > Same comment for abstract. >- 2nd para in abstract is not needed. That is already part > of the MIB boiler plate as you have it in sect 1. >- references need to be split in normative and informative. > Again see: http://www.rfc-editor.org/policy.html > For the references in the MIB boiler-plate, a good sample > of the split is in draft-ietf-rmonmib-hc-alarm-mib-02.txt >- object docsSubMgtCpeIpAddr has a decription clause that > talks about "wiretapping". Not sure you want to use that term. > >Thanks, >Bert >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Nov 21 09:55:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04708 for ; Thu, 21 Nov 2002 09:55:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALEvGa19584 for ipcdn-archive@odin.ietf.org; Thu, 21 Nov 2002 09:57:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALEvFv19579; Thu, 21 Nov 2002 09:57:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKGkev28185 for ; Wed, 20 Nov 2002 11:46:40 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24417 for ; Wed, 20 Nov 2002 11:43:56 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id gAKGkUAR014138; Wed, 20 Nov 2002 09:46:30 -0700 (MST) Received: from 147.191.90.11 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 20 Nov 2002 09:46:19 -0700 X-Server-Uuid: 327424A5-C000-4071-A863-154BD49E0E91 Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by entexchimc04.broadband.att.com with SMTP ( Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XF8MASXK; Wed, 20 Nov 2002 09:46:10 -0700 Received: from 147.191.90.11 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 20 Nov 2002 09:46:11 -0700 X-Server-Uuid: 4520D425-5A30-451F-8662-E5DDF307F3B1 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 20 Nov 2002 09:46:01 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBCF20@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'ipcdn@ietf.org '" cc: "'jfm@cablelabs.com '" , "Woundy, Richard" Date: Wed, 20 Nov 2002 09:45:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11C563D9152716-01-01 X-WSS-ID: 11C563D1403698-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] IPCDN WG session presentations Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I have uploaded the IPCDN session presentations (most current versions) to a web server for public retrieval -- at least until they are posted as part of the IETF proceedings website. See: Note that the contents may be subject to change in the future. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Nov 25 09:39:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00435 for ; Mon, 25 Nov 2002 09:39:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPEfNB05068 for ipcdn-archive@odin.ietf.org; Mon, 25 Nov 2002 09:41:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPEfLv05063; Mon, 25 Nov 2002 09:41:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPEeav05034 for ; Mon, 25 Nov 2002 09:40:36 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00387 for ; Mon, 25 Nov 2002 09:37:51 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gAPEeZri000019 for ; Mon, 25 Nov 2002 07:40:35 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA27206 for ; Mon, 25 Nov 2002 07:40:33 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 25 Nov 2002 09:40:33 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C0848A4@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "Docsis-Oss (E-mail)" , "Ipcdn List (E-mail)" Date: Mon, 25 Nov 2002 09:40:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Docs QoS MIB Updates Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Michael Patrick and Myself are in the process of updating the QoS MIB for version 7. At this point this version will include changes to the description of Row Status Objects, as well as the docsQosServiceFlowPkts object. If there are any other proposed changes please send them ASAP. Thanks, Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Nov 27 11:03:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16381 for ; Wed, 27 Nov 2002 11:03:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARG5lG03490 for ipcdn-archive@odin.ietf.org; Wed, 27 Nov 2002 11:05:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARG4fv03445; Wed, 27 Nov 2002 11:04:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARG3sv03373 for ; Wed, 27 Nov 2002 11:03:54 -0500 Received: from com21.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16318 for ; Wed, 27 Nov 2002 11:01:06 -0500 (EST) Received: from com21.ie (dhcp-250-34.ie.com21.com [192.168.250.34]) by com21.ie (8.11.0/8.11.0) with ESMTP id gARFqB700705 for ; Wed, 27 Nov 2002 15:52:11 GMT Message-ID: <3DE4EBF2.4040004@com21.ie> Date: Wed, 27 Nov 2002 15:59:46 +0000 From: Ian Wheelock User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, is there any decision on whether this version of the mib will be required for the next certwave ? there seems to have been extensive changes made to the mib compared to -06, but i did not see much of this debated on the ipcdn reflector. is there another reflector/list that discussions have been ongoing on ? thanks Ian _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Nov 27 11:54:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18893 for ; Wed, 27 Nov 2002 11:54:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGvES07968 for ipcdn-archive@odin.ietf.org; Wed, 27 Nov 2002 11:57:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARGvBv07961; Wed, 27 Nov 2002 11:57:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARGuMv07921 for ; Wed, 27 Nov 2002 11:56:22 -0500 Received: from pyramid.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18850 for ; Wed, 27 Nov 2002 11:53:34 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by pyramid.tci.com (8.12.2/8.12.2) with ESMTP id gARGlvlI012758; Wed, 27 Nov 2002 09:48:24 -0700 (MST) Received: from 147.191.90.11 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 27 Nov 2002 09:48:19 -0700 X-Server-Uuid: 4520D425-5A30-451F-8662-E5DDF307F3B1 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 27 Nov 2002 09:48:07 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBCF45@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Ian Wheelock'" cc: ipcdn@ietf.org, "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt Date: Wed, 27 Nov 2002 09:47:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11FA28D926186-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The latest internet-draft version of the Subscriber Management MIB is: . The recent changes were responses to comments by our IETF MIB doctor. This version of the MIB cannot be implemented nor required by a CableLabs cert wave, because the root of the MIB is "{ mib-2 xx }", where "xx" is to be assigned after IESG approval of the MIB. However, the ultimate intent is to require the RFC version of this MIB in a future certification wave. If there are problems with this MIB, they should be discussed on the ipcdn mailing list. -- Rich -----Original Message----- From: Ian Wheelock [mailto:ianw@com21.ie] Sent: Wednesday, November 27, 2002 11:00 AM To: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt Hi, is there any decision on whether this version of the mib will be required for the next certwave ? there seems to have been extensive changes made to the mib compared to -06, but i did not see much of this debated on the ipcdn reflector. is there another reflector/list that discussions have been ongoing on ? thanks Ian _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Nov 27 12:12:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19707 for ; Wed, 27 Nov 2002 12:12:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARHEm109989 for ipcdn-archive@odin.ietf.org; Wed, 27 Nov 2002 12:14:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARHElv09982; Wed, 27 Nov 2002 12:14:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARHCAv09459 for ; Wed, 27 Nov 2002 12:12:10 -0500 Received: from sunlight.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19423 for ; Wed, 27 Nov 2002 12:09:22 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by sunlight.tci.com (8.12.2/8.12.2) with ESMTP id gARH42As009436; Wed, 27 Nov 2002 10:04:59 -0700 (MST) Received: from 147.191.90.10 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 27 Nov 2002 10:04:56 -0700 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 27 Nov 2002 10:04:25 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBCF47@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "Docsis-Oss (E-mail)" , "Ipcdn List (E-mail)" cc: "Jean-Francois Mule (E-mail)" Date: Wed, 27 Nov 2002 10:04:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11FA24B234347-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: Docs QoS MIB Updates Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please support William in this request, as we want the QoS MIB to be an IETF approved RFC as soon as reasonably possible. -- Rich -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, November 25, 2002 9:41 AM To: Docsis-Oss (E-mail); Ipcdn List (E-mail) Subject: Docs QoS MIB Updates Michael Patrick and Myself are in the process of updating the QoS MIB for version 7. At this point this version will include changes to the description of Row Status Objects, as well as the docsQosServiceFlowPkts object. If there are any other proposed changes please send them ASAP. Thanks, Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Nov 27 17:46:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01107 for ; Wed, 27 Nov 2002 17:46:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARMn8E31372 for ipcdn-archive@odin.ietf.org; Wed, 27 Nov 2002 17:49:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARMn7v31365; Wed, 27 Nov 2002 17:49:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARMmvv31334 for ; Wed, 27 Nov 2002 17:48:57 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01075 for ; Wed, 27 Nov 2002 17:46:06 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gARMmroP010066 for ; Wed, 27 Nov 2002 15:48:53 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA20947 for ; Wed, 27 Nov 2002 15:44:26 -0700 (MST)] Received: by ca25exm01.gi.com with Internet Mail Service (5.5.2656.59) id ; Wed, 27 Nov 2002 14:48:48 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'ipcdn@ietf.org'" Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt Date: Wed, 27 Nov 2002 14:48:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I believe the -02 version is currently required for cert wave. greg > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, November 27, 2002 8:48 AM > To: 'Ian Wheelock' > Cc: ipcdn@ietf.org; DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt > > > The latest internet-draft version of the Subscriber Management MIB is: > er-mib-07.txt> > . The recent changes were responses to comments by our IETF > MIB doctor. > > This version of the MIB cannot be implemented nor required by > a CableLabs > cert wave, because the root of the MIB is "{ mib-2 xx }", > where "xx" is to > be assigned after IESG approval of the MIB. > > However, the ultimate intent is to require the RFC version of > this MIB in a > future certification wave. If there are problems with this > MIB, they should > be discussed on the ipcdn mailing list. > > -- Rich > > -----Original Message----- > From: Ian Wheelock [mailto:ianw@com21.ie] > Sent: Wednesday, November 27, 2002 11:00 AM > To: ipcdn@ietf.org > Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt > > > Hi, > > is there any decision on whether this version of the mib will > be required > for the next certwave ? > > there seems to have been extensive changes made to the mib > compared to -06, > but i did not see much of this debated on the ipcdn reflector. > > is there another reflector/list that discussions have been > ongoing on ? > > thanks > Ian > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Nov 28 23:10:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10447 for ; Thu, 28 Nov 2002 23:10:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAT4D9s26835 for ipcdn-archive@odin.ietf.org; Thu, 28 Nov 2002 23:13:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAT4Civ26806; Thu, 28 Nov 2002 23:12:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAT4BGv26771 for ; Thu, 28 Nov 2002 23:11:16 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10404 for ; Thu, 28 Nov 2002 23:08:21 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gAT4B36A015943; Thu, 28 Nov 2002 21:11:04 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2975D.55251FE2" Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 28 Nov 2002 21:11:03 -0700 Message-ID: Thread-Topic: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt Thread-Index: AcKWZzbjgTtFKDBcRQ+K9+QlStpSPAA9fD4c From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" , X-Approved: ondar Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2975D.55251FE2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBkcmFmdCAwMiBpcyB0aGUgY3VycmVudCBvbmUgaW4gT1NTSSBzcGVjIHJlcXVpcmVtZW50 cy4NCiANCkVkdWFyZG8NCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IE5h a2FuaXNoaSBHcmVnLU1HSTgxNzkgW21haWx0bzpnbmFrYW5pc2hpQG1vdG9yb2xhLmNvbV0gDQoJ U2VudDogV2VkIDExLzI3LzIwMDIgMzo0OCBQTSANCglUbzogJ2lwY2RuQGlldGYub3JnJyANCglD YzogDQoJU3ViamVjdDogUkU6IFtpcGNkbl0gSS1EIEFDVElPTjpkcmFmdC1pZXRmLWlwY2RuLXN1 YnNjcmliZXItbWliLTA3LnR4dA0KCQ0KCQ0KDQoJSSBiZWxpZXZlIHRoZSAtMDIgdmVyc2lvbiBp cyBjdXJyZW50bHkgcmVxdWlyZWQgZm9yIGNlcnQgd2F2ZS4NCgkNCglncmVnDQoJDQoJPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogV291bmR5LCBSaWNoYXJkIFttYWlsdG86 UmljaGFyZF9Xb3VuZHlAY2FibGUuY29tY2FzdC5jb21dDQoJPiBTZW50OiBXZWRuZXNkYXksIE5v dmVtYmVyIDI3LCAyMDAyIDg6NDggQU0NCgk+IFRvOiAnSWFuIFdoZWVsb2NrJw0KCT4gQ2M6IGlw Y2RuQGlldGYub3JnOyBET0NTSVMgT1NTIChFLW1haWwpDQoJPiBTdWJqZWN0OiBSRTogW2lwY2Ru XSBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtaXBjZG4tc3Vic2NyaWJlci1taWItMDcudHh0DQoJPg0K CT4NCgk+IFRoZSBsYXRlc3QgaW50ZXJuZXQtZHJhZnQgdmVyc2lvbiBvZiB0aGUgU3Vic2NyaWJl ciBNYW5hZ2VtZW50IE1JQiBpczoNCgk+IDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLWlwY2RuLXN1YnNjcmliDQoJPiBlci1taWItMDcudHh0Pg0KCT4gLiBU aGUgcmVjZW50IGNoYW5nZXMgd2VyZSByZXNwb25zZXMgdG8gY29tbWVudHMgYnkgb3VyIElFVEYN Cgk+IE1JQiBkb2N0b3IuDQoJPg0KCT4gVGhpcyB2ZXJzaW9uIG9mIHRoZSBNSUIgY2Fubm90IGJl IGltcGxlbWVudGVkIG5vciByZXF1aXJlZCBieQ0KCT4gYSBDYWJsZUxhYnMNCgk+IGNlcnQgd2F2 ZSwgYmVjYXVzZSB0aGUgcm9vdCBvZiB0aGUgTUlCIGlzICJ7IG1pYi0yIHh4IH0iLA0KCT4gd2hl cmUgInh4IiBpcyB0bw0KCT4gYmUgYXNzaWduZWQgYWZ0ZXIgSUVTRyBhcHByb3ZhbCBvZiB0aGUg TUlCLg0KCT4NCgk+IEhvd2V2ZXIsIHRoZSB1bHRpbWF0ZSBpbnRlbnQgaXMgdG8gcmVxdWlyZSB0 aGUgUkZDIHZlcnNpb24gb2YNCgk+IHRoaXMgTUlCIGluIGENCgk+IGZ1dHVyZSBjZXJ0aWZpY2F0 aW9uIHdhdmUuIElmIHRoZXJlIGFyZSBwcm9ibGVtcyB3aXRoIHRoaXMNCgk+IE1JQiwgdGhleSBz aG91bGQNCgk+IGJlIGRpc2N1c3NlZCBvbiB0aGUgaXBjZG4gbWFpbGluZyBsaXN0Lg0KCT4NCgk+ IC0tIFJpY2gNCgk+DQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogSWFu IFdoZWVsb2NrIFttYWlsdG86aWFud0Bjb20yMS5pZV0NCgk+IFNlbnQ6IFdlZG5lc2RheSwgTm92 ZW1iZXIgMjcsIDIwMDIgMTE6MDAgQU0NCgk+IFRvOiBpcGNkbkBpZXRmLm9yZw0KCT4gU3ViamVj dDogW2lwY2RuXSBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtaXBjZG4tc3Vic2NyaWJlci1taWItMDcu dHh0DQoJPg0KCT4NCgk+IEhpLA0KCT4NCgk+IGlzIHRoZXJlIGFueSBkZWNpc2lvbiBvbiB3aGV0 aGVyIHRoaXMgdmVyc2lvbiBvZiB0aGUgbWliIHdpbGwNCgk+IGJlIHJlcXVpcmVkDQoJPiBmb3Ig dGhlIG5leHQgY2VydHdhdmUgPw0KCT4NCgk+IHRoZXJlIHNlZW1zIHRvIGhhdmUgYmVlbiBleHRl bnNpdmUgY2hhbmdlcyBtYWRlIHRvIHRoZSBtaWINCgk+IGNvbXBhcmVkIHRvIC0wNiwNCgk+IGJ1 dCBpIGRpZCBub3Qgc2VlIG11Y2ggb2YgdGhpcyBkZWJhdGVkIG9uIHRoZSBpcGNkbiByZWZsZWN0 b3IuDQoJPg0KCT4gaXMgdGhlcmUgYW5vdGhlciByZWZsZWN0b3IvbGlzdCB0aGF0IGRpc2N1c3Np b25zIGhhdmUgYmVlbg0KCT4gb25nb2luZyBvbiA/DQoJPg0KCT4gdGhhbmtzDQoJPiBJYW4NCgk+ DQoJPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4g SVBDRE4gbWFpbGluZyBsaXN0DQoJPiBJUENETkBpZXRmLm9yZw0KCT4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBjZG4NCgk+DQoJX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCglJUENETiBtYWlsaW5nIGxpc3QNCglJUENETkBp ZXRmLm9yZw0KCWh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwY2RuDQoJ DQoNCg== ------_=_NextPart_001_01C2975D.55251FE2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjU3NzAuOTEiPgo8VElUTEU+UkU6IFtpcGNkbl0gSS1E IEFDVElPTjpkcmFmdC1pZXRmLWlwY2RuLXN1YnNjcmliZXItbWliLTA3LnR4dDwvVElUTEU+Cjwv SEVBRD4KPEJPRFkgZGlyPWx0cj4KPERJVj5ZZXMsIGRyYWZ0IDAyIGlzIHRoZSBjdXJyZW50IG9u ZSBpbiBPU1NJIHNwZWMgcmVxdWlyZW1lbnRzLjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW PkVkdWFyZG88L0RJVj4KPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAw cHgiPgogIDxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxCUj48 Qj5Gcm9tOjwvQj4gTmFrYW5pc2hpIAogIEdyZWctTUdJODE3OSBbbWFpbHRvOmduYWthbmlzaGlA bW90b3JvbGEuY29tXSA8QlI+PEI+U2VudDo8L0I+IFdlZCAxMS8yNy8yMDAyIAogIDM6NDggUE0g PEJSPjxCPlRvOjwvQj4gJ2lwY2RuQGlldGYub3JnJyA8QlI+PEI+Q2M6PC9CPiA8QlI+PEI+U3Vi amVjdDo8L0I+IFJFOiAKICBbaXBjZG5dIEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1pcGNkbi1zdWJz Y3JpYmVyLW1pYi0wNy50eHQ8QlI+PEJSPjwvRk9OVD48L0RJVj4KICA8UD48Rk9OVCBzaXplPTI+ SSBiZWxpZXZlIHRoZSAtMDIgdmVyc2lvbiBpcyBjdXJyZW50bHkgcmVxdWlyZWQgZm9yIGNlcnQg CiAgd2F2ZS48QlI+PEJSPmdyZWc8QlI+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08QlI+Jmd0OyBGcm9tOiBXb3VuZHksIAogIFJpY2hhcmQgWzxBIAogIGhyZWY9Im1haWx0bzpS aWNoYXJkX1dvdW5keUBjYWJsZS5jb21jYXN0LmNvbSI+bWFpbHRvOlJpY2hhcmRfV291bmR5QGNh YmxlLmNvbWNhc3QuY29tPC9BPl08QlI+Jmd0OyAKICBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVy IDI3LCAyMDAyIDg6NDggQU08QlI+Jmd0OyBUbzogJ0lhbiBXaGVlbG9jayc8QlI+Jmd0OyAKICBD YzogaXBjZG5AaWV0Zi5vcmc7IERPQ1NJUyBPU1MgKEUtbWFpbCk8QlI+Jmd0OyBTdWJqZWN0OiBS RTogW2lwY2RuXSBJLUQgCiAgQUNUSU9OOmRyYWZ0LWlldGYtaXBjZG4tc3Vic2NyaWJlci1taWIt MDcudHh0PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IFRoZSAKICBsYXRlc3QgaW50ZXJuZXQtZHJh ZnQgdmVyc2lvbiBvZiB0aGUgU3Vic2NyaWJlciBNYW5hZ2VtZW50IE1JQiBpczo8QlI+Jmd0OyAK ICAmbHQ7aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1pcGNk bi1zdWJzY3JpYjxCUj4mZ3Q7IAogIGVyLW1pYi0wNy50eHQmZ3Q7PEJSPiZndDsgLiBUaGUgcmVj ZW50IGNoYW5nZXMgd2VyZSByZXNwb25zZXMgdG8gY29tbWVudHMgYnkgCiAgb3VyIElFVEY8QlI+ Jmd0OyBNSUIgZG9jdG9yLjxCUj4mZ3Q7PEJSPiZndDsgVGhpcyB2ZXJzaW9uIG9mIHRoZSBNSUIg Y2Fubm90IGJlIAogIGltcGxlbWVudGVkIG5vciByZXF1aXJlZCBieTxCUj4mZ3Q7IGEgQ2FibGVM YWJzPEJSPiZndDsgY2VydCB3YXZlLCBiZWNhdXNlIHRoZSAKICByb290IG9mIHRoZSBNSUIgaXMg InsgbWliLTIgeHggfSIsPEJSPiZndDsgd2hlcmUgInh4IiBpcyB0bzxCUj4mZ3Q7IGJlIAogIGFz c2lnbmVkIGFmdGVyIElFU0cgYXBwcm92YWwgb2YgdGhlIE1JQi48QlI+Jmd0OzxCUj4mZ3Q7IEhv d2V2ZXIsIHRoZSB1bHRpbWF0ZSAKICBpbnRlbnQgaXMgdG8gcmVxdWlyZSB0aGUgUkZDIHZlcnNp b24gb2Y8QlI+Jmd0OyB0aGlzIE1JQiBpbiBhPEJSPiZndDsgZnV0dXJlIAogIGNlcnRpZmljYXRp b24gd2F2ZS4gSWYgdGhlcmUgYXJlIHByb2JsZW1zIHdpdGggdGhpczxCUj4mZ3Q7IE1JQiwgdGhl eSAKICBzaG91bGQ8QlI+Jmd0OyBiZSBkaXNjdXNzZWQgb24gdGhlIGlwY2RuIG1haWxpbmcgbGlz dC48QlI+Jmd0OzxCUj4mZ3Q7IC0tIAogIFJpY2g8QlI+Jmd0OzxCUj4mZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgRnJvbTogSWFuIFdoZWVsb2NrIFs8QSAKICBocmVmPSJt YWlsdG86aWFud0Bjb20yMS5pZSI+bWFpbHRvOmlhbndAY29tMjEuaWU8L0E+XTxCUj4mZ3Q7IFNl bnQ6IFdlZG5lc2RheSwgCiAgTm92ZW1iZXIgMjcsIDIwMDIgMTE6MDAgQU08QlI+Jmd0OyBUbzog aXBjZG5AaWV0Zi5vcmc8QlI+Jmd0OyBTdWJqZWN0OiBbaXBjZG5dIAogIEktRCBBQ1RJT046ZHJh ZnQtaWV0Zi1pcGNkbi1zdWJzY3JpYmVyLW1pYi0wNy50eHQ8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZn dDsgCiAgSGksPEJSPiZndDs8QlI+Jmd0OyBpcyB0aGVyZSBhbnkgZGVjaXNpb24gb24gd2hldGhl ciB0aGlzIHZlcnNpb24gb2YgdGhlIG1pYiAKICB3aWxsPEJSPiZndDsgYmUgcmVxdWlyZWQ8QlI+ Jmd0OyBmb3IgdGhlIG5leHQgY2VydHdhdmUgPzxCUj4mZ3Q7PEJSPiZndDsgdGhlcmUgCiAgc2Vl bXMgdG8gaGF2ZSBiZWVuIGV4dGVuc2l2ZSBjaGFuZ2VzIG1hZGUgdG8gdGhlIG1pYjxCUj4mZ3Q7 IGNvbXBhcmVkIHRvIAogIC0wNiw8QlI+Jmd0OyBidXQgaSBkaWQgbm90IHNlZSBtdWNoIG9mIHRo aXMgZGViYXRlZCBvbiB0aGUgaXBjZG4gCiAgcmVmbGVjdG9yLjxCUj4mZ3Q7PEJSPiZndDsgaXMg dGhlcmUgYW5vdGhlciByZWZsZWN0b3IvbGlzdCB0aGF0IGRpc2N1c3Npb25zIAogIGhhdmUgYmVl bjxCUj4mZ3Q7IG9uZ29pbmcgb24gPzxCUj4mZ3Q7PEJSPiZndDsgdGhhbmtzPEJSPiZndDsgCiAg SWFuPEJSPiZndDs8QlI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxCUj4mZ3Q7IAogIElQQ0ROIG1haWxpbmcgbGlzdDxCUj4mZ3Q7IElQQ0ROQGll dGYub3JnPEJSPiZndDsgPEEgCiAgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBjZG4iPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw Y2RuPC9BPjxCUj4mZ3Q7PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPEJSPklQQ0ROIAogIG1haWxpbmcgbGlzdDxCUj5JUENETkBpZXRmLm9yZzxCUj48 QSAKICBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGNkbiI+ aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBjZG48L0E+PEJSPjwvRk9O VD48L1A+PC9CTE9DS1FVT1RFPgoKPC9CT0RZPgo8L0hUTUw+ ------_=_NextPart_001_01C2975D.55251FE2-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn