From mailman-owner@ietf.org Wed Nov 1 05:09:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15007 for ; Wed, 1 Nov 2000 05:09:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27184 for ; Wed, 1 Nov 2000 05:10:01 -0500 (EST) Date: Wed, 1 Nov 2000 05:10:01 -0500 (EST) Message-Id: <200011011010.FAA27184@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ipcdn-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ipcdn-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipcdn-archive@lists.ietf.org: List Password // URL ---- -------- ipcdn@ietf.org BtQa http://www1.ietf.org/mailman/options/ipcdn/ipcdn-archive@lists.ietf.org From mailman-owner@ietf.org Wed Nov 1 05:16:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17743 for ; Wed, 1 Nov 2000 05:16:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02625 for ; Wed, 1 Nov 2000 05:16:11 -0500 (EST) Date: Wed, 1 Nov 2000 05:16:11 -0500 (EST) Message-Id: <200011011016.FAA02625@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ipcdn-web-archive@ns.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ipcdn-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipcdn-web-archive@optimus.ietf.org: List Password // URL ---- -------- ipcdn@ietf.org WHxL http://www1.ietf.org/mailman/options/ipcdn/ipcdn-web-archive@optimus.ietf.org From ipcdn-admin@ietf.org Mon Nov 6 06:33:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13211; Mon, 6 Nov 2000 06:33:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18896; Mon, 6 Nov 2000 06:32:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18868 for ; Mon, 6 Nov 2000 06:31:59 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12743; Mon, 6 Nov 2000 06:31:58 -0500 (EST) Message-Id: <200011061131.GAA12743@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: Mon, 06 Nov 2000 06:31:58 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-dvbnetint-mib-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org --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 : DVB Cable Network Interface Unit MIB for EuroModem compliant Cable Modems Author(s) : A. Valentine Filename : draft-ietf-ipcdn-dvbnetint-mib-01.txt Pages : 59 Date : 03-Nov-00 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 EuroModem v1.0 compliant Cable Network Interface Units. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[RFC2578][RFC2579][RFC2580]. The set of objects is consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-dvbnetint-mib-01.txt 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-dvbnetint-mib-01.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-dvbnetint-mib-01.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: <20001103120251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-dvbnetint-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-dvbnetint-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001103120251.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Mon Nov 6 14:01:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25882; Mon, 6 Nov 2000 14:01:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23440; Mon, 6 Nov 2000 13:53:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01670 for ; Fri, 3 Nov 2000 11:51:52 -0500 (EST) Received: from huksweep.eu.hns.com (mail.eu.hns.com [193.129.245.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03678; Fri, 3 Nov 2000 11:51:46 -0500 (EST) Received: from pegasus.eu.hns.com (unverified) by huksweep.eu.hns.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Fri, 3 Nov 2000 16:54:53 +0000 Received: from EUROWEB ([139.85.104.6]) by pegasus.eu.hns.com (Lotus Domino Release 5.0.5) with ESMTP id 2000110316553595:12266 ; Fri, 3 Nov 2000 16:55:35 +0000 To: internet-drafts@ietf.org Cc: ipcdn@ietf.org, Jens Mose Pedersen , dvb-rccl@list.dvb.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: From: A.Valentine@eu.hns.com Date: Fri, 3 Nov 2000 16:54:51 +0000 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on HNSUK1/HNSEU(Release 5.0.2c (Intl)|2 February 2000) at 03/11/2000 16:54:52, Itemize by SMTP Server on PEGASUS/HNSEU(Release 5.0.5 |September 22, 2000) at 03/11/2000 16:55:36, MIME-CD by Notes Server on PEGASUS/HNSEU(Release 5.0.5 |September 22, 2000) at 03/11/2000 16:55:39, MIME-CD complete at 03/11/2000 16:55:39, Serialize by Router on PEGASUS/HNSEU(Release 5.0.5 |September 22, 2000) at 03/11/2000 16:55:40 Content-type: multipart/mixed ; Boundary="0__=0025698C005CFB4E8f9e8a93df938690918c0025698C005CFB4E" Content-Disposition: inline Subject: [ipcdn] draft-ietf-ipcdn-dvbnetint-mib-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org --0__=0025698C005CFB4E8f9e8a93df938690918c0025698C005CFB4E Content-type: text/plain; charset=us-ascii Hi, Please can you publish the attached I-D for the IPCDN WG. This is the latest version of the DVB Euromodem MIB. Many thanks Andrew (See attached file: draft-ietf-ipcdn-dvbnetint-mib-01.txt) -- Andrew Valentine Systems Engineer UK Engineering Design Centre Hughes Network Systems Ltd. Linford Wood , Saxon Street, Milton Keynes MK14 6LD, United Kingdom Tel : Direct +44 1908 326 233 Tel Main +44 1908 221122 x 233 Fax : +44 1908 221127 Email: A.Valentine@eu.hns.com (See attached file: draft-ietf-ipcdn-dvbnetint-mib-01.txt) #********************************************************************** This message is intended solely for the use of the individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Hughes Network Systems Limited, including its European subsidiaries and affiliates. Hughes Network Systems Limited, including its European subsidiaries and affiliates accepts no responsibility for loss or damage arising from its use, including damage from virus. #********************************************************************** --0__=0025698C005CFB4E8f9e8a93df938690918c0025698C005CFB4E Content-type: application/octet-stream; name="draft-ietf-ipcdn-dvbnetint-mib-01.txt" Content-Disposition: attachment; filename="draft-ietf-ipcdn-dvbnetint-mib-01.txt" Content-Transfer-Encoding: base64 CgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBWYWxlbnRpbmUgCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEh1Z2hlcyBOZXR3b3JrIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTeXN0ZW1zIEx0ZCAKRG9jdW1l bnQ6IGRyYWZ0LWlldGYtaXBjZG4tZHZibmV0aW50LW1pYi0wMS50eHQgICAgICAgICAgIE5vdmVt YmVyIDIwMDAgCkNhdGVnb3J5OiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogCiAKICAgICAgICAgICAgICAgICAgRFZCIENhYmxl IE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCIAogICAgICAgICAgICAgICAgICBmb3IgRXVyb01v ZGVtIGNvbXBsaWFudCBDYWJsZSBNb2RlbXMgCiAgICAKICAgIApTdGF0dXMgb2YgdGhpcyBNZW1v IAogICAgCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1 bGwgY29uZm9ybWFuY2Ugd2l0aCAKICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBS RkMyMDI2LiAKIAogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZyAKICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywg YW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0IAogICBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IAogICBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl ZCBieSBvdGhlciAKICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC0gRHJhZnRzIAogICBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gCiAgIHByb2dyZXNzLiIgCiAgICAgCiAg IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCAK ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0ICAKICAgIAogICBU aGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz c2VkIGF0IAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiAKICAgIAogICAgCkFi c3RyYWN0IAogICAgCiAgIFRoaXMgbWVtbyBkZWZpbmVzIGEgcG9ydGlvbiBvZiB0aGUgTWFuYWdl bWVudCBJbmZvcm1hdGlvbiBCYXNlIChNSUIpIAogICBmb3IgdXNlIHdpdGggbmV0d29yayBtYW5h Z2VtZW50IHByb3RvY29scyBpbiB0aGUgSW50ZXJuZXQgY29tbXVuaXR5LiAgCiAgIEluIHBhcnRp Y3VsYXIsIGl0IGRlZmluZXMgYSBiYXNpYyBzZXQgb2YgbWFuYWdlZCBvYmplY3RzIGZvciBTTk1Q LQogICBiYXNlZCBtYW5hZ2VtZW50IG9mIEV1cm9Nb2RlbSB2MS4wIGNvbXBsaWFudCBDYWJsZSBO ZXR3b3JrIEludGVyZmFjZSAKICAgVW5pdHMuIAogICAgCiAgIFRoaXMgbWVtbyBzcGVjaWZpZXMg YSBNSUIgbW9kdWxlIGluIGEgbWFubmVyIHRoYXQgaXMgY29tcGxpYW50IHRvIAogICB0aGUgU05N UCBTTUl2MltSRkMyNTc4XVtSRkMyNTc5XVtSRkMyNTgwXS4gIFRoZSBzZXQgb2Ygb2JqZWN0cyBp cyAKICAgY29uc2lzdGVudCB3aXRoIHRoZSBTTk1QIGZyYW1ld29yayBhbmQgZXhpc3RpbmcgU05N UCBzdGFuZGFyZHMuIAogICAgCiAgIFRoaXMgbWVtbyBpcyBhIHByb2R1Y3Qgb2YgdGhlIERWQi9E QVZJQyBpbnRlcm9wZXJhYmlsaXR5IGNvbnNvcnRpdW0gCiAgIHdoaWNoIGhhcyBiZWVuIGFkb3B0 ZWQgYXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQQ0ROIFdHLiAgQ29tbWVudHMgYXJlIAogICBzb2xp Y2l0ZWQgYW5kIHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gdGhlIGF1dGhvciAKIAogICAgCjEuIFRo ZSBTTk1QIE1hbmFnZW1lbnQgRnJhbWV3b3JrIAogICAgCiAgIFRoZSBTTk1QIE1hbmFnZW1lbnQg RnJhbWV3b3JrIHByZXNlbnRseSBjb25zaXN0cyBvZiBmaXZlIG1ham9yIAogICBjb21wb25lbnRz OiAKICAKVmFsZW50aW5lICAgICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIE1heSAyMDAx IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSAMCiAgICAgICAgICAgICAgICAg RFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAK IAogICAgCiAgIG8gICAgQW4gb3ZlcmFsbCBhcmNoaXRlY3R1cmUsIGRlc2NyaWJlZCBpbiBSRkMg MjU3MSBbUkZDMjU3MV0uICAKICAgIAogICBvICAgIE1lY2hhbmlzbXMgZm9yIGRlc2NyaWJpbmcg YW5kIG5hbWluZyBvYmplY3RzIGFuZCBldmVudHMgZm9yIHRoZSAKICAgICAgICBwdXJwb3NlIG9m IG1hbmFnZW1lbnQuIFRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoaXMgU3RydWN0dXJlIG9mIAogICAg ICAgIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gKFNNSSkgaXMgY2FsbGVkIFNNSXYxIGFuZCBkZXNj cmliZWQgaW4gCiAgICAgICAgU1REIDE2LCBSRkMgMTE1NSBbUkZDMTE1NV0sIFNURCAxNiwgUkZD IDEyMTIgW1JGQzEyMTJdIGFuZCBSRkMgCiAgICAgICAgMTIxNSBbUkZDMTIxNV0uIFRoZSBzZWNv bmQgdmVyc2lvbiwgY2FsbGVkIFNNSXYyLCBpcyBkZXNjcmliZWQgCiAgICAgICAgaW4gU1REIDU4 LCBSRkMgMjU3OCBbUkZDMjU3OF0sIFNURCA1OCwgUkZDIDI1NzkgW1JGQzI1NzldIGFuZCAKICAg ICAgICBTVEQgNTgsIFJGQyAyNTgwIFtSRkMyNTgwXS4gIAogICAgCiAgIG8gICAgTWVzc2FnZSBw cm90b2NvbHMgZm9yIHRyYW5zZmVycmluZyBtYW5hZ2VtZW50IGluZm9ybWF0aW9uLiBUaGUgCiAg ICAgICAgZmlyc3QgdmVyc2lvbiBvZiB0aGUgU05NUCBtZXNzYWdlIHByb3RvY29sIGlzIGNhbGxl ZCBTTk1QdjEgYW5kIAogICAgICAgIGRlc2NyaWJlZCBpbiBTVEQgMTUsIFJGQyAxMTU3IFtSRkMx MTU3XS4gQSBzZWNvbmQgdmVyc2lvbiBvZiAKICAgICAgICB0aGUgU05NUCBtZXNzYWdlIHByb3Rv Y29sLCB3aGljaCBpcyBub3QgYW4gSW50ZXJuZXQgc3RhbmRhcmRzIAogICAgICAgIHRyYWNrIHBy b3RvY29sLCBpcyBjYWxsZWQgU05NUHYyYyBhbmQgZGVzY3JpYmVkIGluIFJGQyAxOTAxIAogICAg ICAgIFtSRkMxOTAxXSBhbmQgUkZDIDE5MDYgW1JGQzE5MDZdLiBUaGUgdGhpcmQgdmVyc2lvbiBv ZiB0aGUgCiAgICAgICAgbWVzc2FnZSBwcm90b2NvbCBpcyBjYWxsZWQgU05NUHYzIGFuZCBkZXNj cmliZWQgaW4gUkZDIDE5MDYgCiAgICAgICAgW1JGQzE5MDZdLCBSRkMgMjU3MiBbUkZDMjU3Ml0g YW5kIFJGQyAyNTc0IFtSRkMyNTc0XS4gIAogICAgCiAgIG8gICAgUHJvdG9jb2wgb3BlcmF0aW9u cyBmb3IgYWNjZXNzaW5nIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24uIFRoZSAKICAgICAgICBmaXJz dCBzZXQgb2YgcHJvdG9jb2wgb3BlcmF0aW9ucyBhbmQgYXNzb2NpYXRlZCBQRFUgZm9ybWF0cyBp cyAKICAgICAgICBkZXNjcmliZWQgaW4gU1REIDE1LCBSRkMgMTE1NyBbUkZDMTE1N10uIEEgc2Vj b25kIHNldCBvZiAKICAgICAgICBwcm90b2NvbCBvcGVyYXRpb25zIGFuZCBhc3NvY2lhdGVkIFBE VSBmb3JtYXRzIGlzIGRlc2NyaWJlZCBpbiAKICAgICAgICBSRkMgMTkwNSBbUkZDMTkwNV0uICAK ICAgIAogICBvICAgIEEgc2V0IG9mIGZ1bmRhbWVudGFsIGFwcGxpY2F0aW9ucyBkZXNjcmliZWQg aW4gUkZDIDI1NzMgCiAgICAgICAgW1JGQzI1NzNdIGFuZCB0aGUgdmlldy1iYXNlZCBhY2Nlc3Mg Y29udHJvbCBtZWNoYW5pc20gZGVzY3JpYmVkIAogICAgICAgIGluIFJGQyAyNTc1IFtSRkMyNTc1 XS4gCiAgICAKICAgQSBtb3JlIGRldGFpbGVkIGludHJvZHVjdGlvbiB0byB0aGUgY3VycmVudCBT Tk1QIE1hbmFnZW1lbnQgCiAgIEZyYW1ld29yayBjYW4gYmUgZm91bmQgaW4gUkZDIDI1NzAgW1JG QzI1NzBdLiAKICAgIAogICBNYW5hZ2VkIG9iamVjdHMgYXJlIGFjY2Vzc2VkIHZpYSBhIHZpcnR1 YWwgaW5mb3JtYXRpb24gc3RvcmUsIHRlcm1lZCAKICAgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRp b24gQmFzZSBvciBNSUIuIE9iamVjdHMgaW4gdGhlIE1JQiBhcmUgCiAgIGRlZmluZWQgdXNpbmcg dGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbiB0aGUgU01JLiAgCiAgICAKICAgVGhpcyBtZW1vIHNw ZWNpZmllcyBhIE1JQiBtb2R1bGUgdGhhdCBpcyBjb21wbGlhbnQgdG8gdGhlIFNNSXYyLiBBIAog ICBNSUIgY29uZm9ybWluZyB0byB0aGUgU01JdjEgY2FuIGJlIHByb2R1Y2VkIHRocm91Z2ggdGhl IGFwcHJvcHJpYXRlIAogICB0cmFuc2xhdGlvbnMuIFRoZSByZXN1bHRpbmcgdHJhbnNsYXRlZCBN SUIgbXVzdCBiZSBzZW1hbnRpY2FsbHkgCiAgIGVxdWl2YWxlbnQsIGV4Y2VwdCB3aGVyZSBvYmpl Y3RzIG9yIGV2ZW50cyBhcmUgb21pdHRlZCBiZWNhdXNlIG5vIAogICB0cmFuc2xhdGlvbiBpcyBw b3NzaWJsZSAodXNlIG9mIENvdW50ZXI2NCkuIFNvbWUgbWFjaGluZSByZWFkYWJsZSAKICAgaW5m b3JtYXRpb24gaW4gU01JdjIgd2lsbCBiZSBjb252ZXJ0ZWQgaW50byB0ZXh0dWFsIGRlc2NyaXB0 aW9ucyBpbiAKICAgU01JdjEgZHVyaW5nIHRoZSB0cmFuc2xhdGlvbiBwcm9jZXNzLiBIb3dldmVy LCB0aGlzIGxvc3Mgb2YgbWFjaGluZSAKICAgcmVhZGFibGUgaW5mb3JtYXRpb24gaXMgbm90IGNv bnNpZGVyZWQgdG8gY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgCiAgIHRoZSBNSUIuICAKICAgIAog ICAgCjIuIEdsb3NzYXJ5IAogICAgCiAgIDIuMS4gQ0FUViAKICAgIAogICBPcmlnaW5hbGx5ICJD b21tdW5pdHkgQW50ZW5uYSBUZWxldmlzaW9uIiwgbm93IHVzZWQgdG8gcmVmZXIgdG8gYW55IAog IApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAg ICAgICAgICAgICAgICAyIAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRl cmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgIGNhYmxlIG9yIGh5YnJpZCBm aWJlciBhbmQgY2FibGUgc3lzdGVtIHVzZWQgdG8gZGVsaXZlciB2aWRlbyBzaWduYWxzIAogICB0 byBhIGNvbW11bml0eS4gCiAgICAKICAgMi4yLiBEQVZJQyAKICAgIAogICBEaWdpdGFsIEF1ZGlv dmlzdWFsIENvdW5jaWwuIEludGVybmF0aW9uYWwgY291bmNpbCBmb3IgCiAgIGludGVybmV0d29y a2luZyBhdWRpbyBhbmQgdmlkZW8gc3lzdGVtcy4gCiAgICAKICAgMi4zLiBEb3duc3RyZWFtIAog ICAgCiAgIFRoZSBkaXJlY3Rpb24gZnJvbSB0aGUgaGVhZC1lbmQgdG93YXJkcyB0aGUgc3Vic2Ny aWJlci4gCiAgICAKICAgMi40LiBEVkIgCiAgICAKICAgRGlnaXRhbCBWaWRlbyBCcm9hZGNhc3Rp bmcuIFRoZSBEVkIgcHJvamVjdHMgcHJvZHVjZSBvcGVuIGFuZCAKICAgaW50ZXJvcGVyYWJsZSBn bG9iYWwgc3RhbmRhcmRzIGZvciBkaWdpdGFsIGF1ZGlvIGFuZCB2aWRlbyAKICAgZGlzdHJpYnV0 aW9uLiAKICAgIAogICAyLjUuIEV1cm9Nb2RlbS4gCiAgICAKICAgRXVyb01vZGVtLiAgQSBzcGVj aWZpY2F0aW9uIGZvciBhbiBpbnRlcm9wZXJhYmxlIEV1cm9wZWFuIENhYmxlIAogICBNb2RlbSBb RVVST01dLiAKICAgIAogICAyLjYuIEhlYWQtZW5kIAogICAgCiAgIFRoZSBvcmlnaW5hdGlvbiBw b2ludCBpbiBtb3N0IGNhYmxlIHN5c3RlbXMgb2YgdGhlIHN1YnNjcmliZXIgdmlkZW8gCiAgIHNp Z25hbHMuIEdlbmVyYWxseSBhbHNvIHRoZSBsb2NhdGlvbiBvZiB0aGUgSU5BIGVxdWlwbWVudC4g CiAgICAKICAgMi43LiBJTkEgCiAgICAKICAgSW50ZXJhY3RpdmUgTmV0d29yayBBZGFwdGVyLiAg VGhpcyBjYW4gYWN0IGFzIGEgYnJpZGdlIG9yIHJvdXRlciBpbiAKICAgdGhlIGNhYmxlIGhlYWQt ZW5kLiBJdCBpcyByZXNwb25zaWJsZSBmb3IgY29udHJvbGxpbmcgdGhlIGJhbmR3aWR0aCAKICAg YXZhaWxhYmxlIHRvIGVhY2ggTklVLiAKICAgIAogICAyLjguIE5JVSAKICAgIAogICBOZXR3b3Jr IEludGVyZmFjZSBVbml0LiAgVGhlIHVuaXQgaXMgbG9jYXRlZCBhdCB0aGUgc3Vic2NyaWJlciAK ICAgcHJlbWlzZXMgYW5kIHByb3ZpZGVzIGludGVyYWN0aXZlIHNlcnZpY2VzIHZpYSB0aGUgY2Fi bGUgbmV0d29yay4gICAKICAgVGhlIE5JVSBpcyB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgSU5B LCBidXQgbWF5IHJlcXVlc3QgYWRkaXRpb25hbCAKICAgYmFuZHdpZHRoL2Nvbm5lY3Rpb25zIHdo ZW4gcmVxdWlyZWQuICBUaGUgTklVIGNhbiBhY3QgYXMgYSBicmlkZ2Ugb3IgCiAgIHJvdXRlci4g CiAgICAKICAgMi45LiBSRiAKICAgIAogICBSYWRpbyBGcmVxdWVuY3kuIAogICAgCiAgIDIuMTAu IFVwc3RyZWFtIAogICAgCiAgIFRoZSBkaXJlY3Rpb24gZnJvbSB0aGUgc3Vic2NyaWJlciB0b3dh cmRzIHRoZSBoZWFkLWVuZC4gCiAgICAKICAgIAozLiBPdmVydmlldyAKICAgIAogIApWYWxlbnRp bmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAg ICAgICAzIAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5p dCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgIFRoaXMgTUlCIHByb3ZpZGVzIGEgc2V0IG9m IG9iamVjdHMgcmVxdWlyZWQgZm9yIHRoZSBtYW5hZ2VtZW50IG9mIAogICBFdXJvTW9kZW0gdjEu MCBjb21wbGlhbnQgTklVcy4gVGhlIE1JQiBzcGVjaWZpY2F0aW9uIGlzIGRlcml2ZWQgZnJvbSAK ICAgdGhlIEV1cm9Nb2RlbSB2MS4wIHNwZWNpZmljYXRpb24gW0VVUk9NXS4gCiAgICAKICAgRXVy b01vZGVtIE5JVXMgYXJlIGN1cnJlbnRseSBJUHY0IG9ubHkgZGV2aWNlcyBhbmQgbWF5IGltcGxl bWVudCAKICAgZWl0aGVyIFNOTVB2MSBvciBTTk1QdjMuICBUaGlzIE1JQiBpcyBpbnRlbmRlZCBm b3IgTklVcyB0aGF0IAogICBpbXBsZW1lbnQgU05OTVB2MyBhbmQgSVB2NCwgaG93ZXZlciBhbGwg SVAgYWRkcmVzc2VzIGhhdmUgYmVlbiAKICAgcmVwcmVzZW50ZWQgYXMgZGVzY3JpYmVkIGluIFtS RkN4eF0gdG8gYWlkIGZ1dHVyZSBtaWdyYXRpb24gdG8gSVB2Ni4gICAKICAgIAogICBUaGUga2V5 IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5P VCIsIAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFu ZCAiT1BUSU9OQUwiIGluIAogICB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh cyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLiAKICAgIAogICAzLjEuICBTdHJ1Y3R1cmUgb2YgdGhl IE1JQiAKICAgIAogICBUaGlzIE1JQiBpcyBzdHJ1Y3R1cmVkIGludG8gbmluZSBncm91cHM6IAog ICAgCiAgIG8gICAgVGhlIGR2Yk5pdVN5c3RlbSBncm91cCBleHRlbmRzIHRoZSBNSUItSUkgJ3N5 c3RlbScgZ3JvdXAgd2l0aCAKICAgICAgICBvYmplY3RzIG5lZWRlZCBmb3IgY2FibGUgZGV2aWNl IHN5c3RlbSBtYW5hZ2VtZW50LiAKICAgIAogICBvICAgIFRoZSBkdmJOaXVTb2Z0d2FyZSBncm91 cCBwcm92aWRlcyBvYmplY3RzIG5lY2Vzc2FyeSBmb3IgCiAgICAgICAgbWFuYWdpbmcgc29mdHdh cmUgaW1hZ2VzIGFuZCB1cGdyYWRlcyB2aWEgZG93bmxvYWQuICBTZWUgMy4yLjEgCiAgICAKICAg byAgICBUaGUgZHZiTml1RGhjcCBncm91cCBjb25maWd1cmVzIERIQ1AvQk9PVFAgZnVuY3Rpb25h bGl0eSAKICAgICAgICBwcm92aWRlZCBieSB0aGUgTklVLiAgVGhpcyBncm91cCBpcyBvcHRpb25h bC4gIFNlZSAzLjIuMiAKICAgIAogICBvICAgIFRoZSBkdmJOaXVFdmVudCBncm91cCBwcm92aWRl cyBjb250cm9sIGFuZCBsb2dnaW5nIGZvciBldmVudCAKICAgICAgICByZXBvcnRpbmcuICBTZWUg My4yLjMgCiAgICAKICAgbyAgICBUaGUgZHZiTml1SXBGaWx0ZXIgZ3JvdXAgY29uZmlndXJlcyBm aWx0ZXJzIGF0IHRoZSBJUCBsYXllci4gIAogICAgICAgIFRoZSBJUCBmaWx0ZXIgdGFibGUgaXMg YWxzbyB1c2VkIHRvIHByb3ZpZGUgc3VwcG9ydCBmb3IgYW50aSAKICAgICAgICBzcG9vZmluZywg TkFULCBOQVBUIGFuZCBUT1MgbWFwcGluZy4gVGhpcyBncm91cCBpcyBvcHRpb25hbC4gCiAgICAg ICAgU2VlIDMuMyAKICAgIAogICBvICAgIFRoZSBkdmJOaXVOYXQgZ3JvdXAgcHJvdmlkZXMgYmFz aWMgY29uZmlndXJhdGlvbiBmb3IgdGhlIE5JVSAKICAgICAgICBOQVQgY2FwYWJpbGl0eS4gVGhp cyBncm91cCBpcyBvcHRpb25hbC4gCiAKICAgbyAgICBUaGUgZHZiTml1TmFwdCBncm91cCBwcm92 aWRlcyBiYXNpYyBjb25maWd1cmF0aW9uIGZvciB0aGUgTklVIAogICAgICAgIE5BUFQgY2FwYWJp bGl0eS4gVGhpcyBncm91cCBpcyBvcHRpb25hbC4gCiAgICAKICAgbyAgICBUaGUgZHZiTml1RXRo RmlsdGVyIGdyb3VwIGNvbmZpZ3VyZXMgZmlsdGVycyBhdCB0aGUgbGluayBsYXllci4gIAogICAg ICAgIFRoaXMgaXMgcHJpbWFyaWx5IGludGVuZGVkIGZvciB1c2Ugd2hlbiB0aGUgTklVIGlzIHBl cmZvcm1pbmcgCiAgICAgICAgRXRoZXJuZXQgTUFDIGJyaWRnaW5nLiBUaGlzIGdyb3VwIGlzIG9w dGlvbmFsLiBTZWUgMy4zIAogICAgCiAgIG8gICAgVGhlIGR2Yk5pdUNwZSBncm91cCBwcm92aWRl cyBjb250cm9sIG92ZXIgd2hpY2ggSVAgYWRkcmVzc2VzIAogICAgICAgIG1heSBiZSB1c2VkIGJ5 IGN1c3RvbWVyIHByZW1pc2VzIGVxdWlwbWVudCAoZS5nLiBQQ3MpIHNlcnZpY2VkIAogICAgICAg IGJ5IGEgZ2l2ZW4gTklVLiAgVGhpcyBwcm92aWRlcyBhbnRpLXNwb29maW5nIGNvbnRyb2wgYXQg dGhlIAogICAgICAgIHBvaW50IG9mIG9yaWdpbiBmb3IgYSBsYXJnZSBjYWJsZSBtb2RlbSBzeXN0 ZW0uICBUaGlzIGdyb3VwIGlzIAogICAgICAgIG9wdGlvbmFsLiAKICAgIAogICAzLjIuICBNYW5h Z2VtZW50IHJlcXVpcmVtZW50cyAKICAgIAogICAzLjIuMS4gU29mdHdhcmUgTWFuYWdlbWVudCAK ICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAw ICAgICAgICAgICAgICAgNCAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50 ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgCiAgIFRoZSBOSVUgbWF5 IGRvd25sb2FkIGFuZCBzdG9yZSBtdWx0aXBsZSBzb2Z0d2FyZSBpbWFnZXMuICBUaGUgbWV0aG9k IAogICBmb3IgcGVyZm9ybWluZyB0aGUgZG93bmxvYWQgYW5kIHVzaW5nIHRoZSBpbWFnZSBpcyBh cyBmb2xsb3dzOiAKICAgIAogICAgCiAgIG8gICAgc2V0IGR2Yk5pdVN3U2VydmVyIHRvIHRoZSBh ZGRyZXNzIG9mIHRoZSBURlRQIHNlcnZlciBmb3IgCiAgICAgICAgc29mdHdhcmUgdXBncmFkZXMu IAogICAgCiAgIG8gICAgc2V0IGR2Yk5pdVN3RmlsZW5hbWUgdG8gdGhlIGZpbGVuYW1lIGluY2x1 ZGluZyBwYXRoIG9mIHRoZSAKICAgICAgICBpbWFnZSB0byBkb3dubG9hZCB0byB0aGUgTklVLiAK ICAgIAogICBvICAgIHNldCBkdmJOaXVEb3dubG9hZFNsb3QgdG8gdGhlIGltYWdlIHNsb3Qgb24g dGhlIE5JVSBpbiB3aGljaCB0byAKICAgICAgICBwbGFjZSB0aGUgZG93bmxvYWRlZCBpbWFnZS4g IEJ5IGRlZmF1bHQgdGhpcyB3aWxsIGJlIHNldCB0byB0aGUgCiAgICAgICAgbmV4dCBmcmVlIHNs b3Qgb3IgdGhlIGZpcnN0IHNsb3QgZGVzaWduYXRlZCBhcyAnYmFja3VwJy4gCiAgICAKICAgbyAg ICBzZXQgZHZiTml1U3dBZG1pblN0YXR1cyB0byAnaW5pdFVwZ3JkJy4gCiAgICAKICAgVGhlIHN0 YXR1cyBvZiB0aGUgc29mdHdhcmUgZG93bmxvYWQgaXMgb2J0YWluZWQgYnkgcmVhZGluZyAKICAg ZHZiTml1U3dBZG1pblN0YXR1cy4gIElmIHRoZSBOSVUgd2FzIHVuYWJsZSB0byBzdWNjZXNzZnVs bHkgcGVyZm9ybSAKICAgdGhlIGRvd25sb2FkLCB0aGUgc3RhdHVzIHJldHVybmVkIHdpbGwgcmVm bGVjdCB0aGUgY2F1c2UuICBVcG9uIAogICBzdWNjZXNzZnVsIGRvd25sb2FkIHRoZSBvcGVyYXRv ciBtdXN0IGNvbmZpZ3VyZSBkdmJOaXVTd1ZlclRhYmxlIGlmIAogICB0aGV5IHdpc2ggdG8gdXNl IHRoZSBpbWFnZSBhcyB0aGUgYm9vdCBvciBiYWNrdXAgdmVyc2lvbi4gIE5vdGUgb25seSAKICAg b25lIGltYWdlIG1heSBiZSBtYXJrZWQgYXMgYm9vdGFibGUuIAogCiAgIDMuMi4zLiAgSVAgQWRk cmVzcyBBc3NpZ25tZW50IAogICAgCiAgIElQIGFkZHJlc3NlcyBtYXkgYmUgYXNzaWduZWQgdG8g TklVIGludGVyZmFjZXMgdXNpbmcgc3RhdGljIGFuZCAKICAgZHluYW1pYyBhc3NpZ25tZW50cy4g IE9iamVjdHMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBNSUIgdG8gc3VwcG9ydCAKICAgYm90aCBtZXRo b2RzLiAgZHZiTml1U3RhdGljSXBUYWJsZSBwcm92aWRlcyBvYmplY3RzIHRvIGFzc2lnbiBzdGF0 aWMgCiAgIElQIGFkZHJlc3NlcyB0byBOSVUgaW50ZXJmYWNlcywgd2hlcmUgZWFjaCBpbnRlcmZh Y2UgbWF5IGhhdmUgCiAgIG11bHRpcGxlIElQIGFkZHJlc3Nlcy4gIEFuIElQIGFkZHJlc3MgYXNz aWdubWVudCBpbiB0aGUgdGFibGUgTVVTVCAKICAgTk9UIGJlIHJlbW92ZWQgZnJvbSB0aGUgdGFi bGUgaWYgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIFNOTVAgCiAgIHBhY2tldCByZW1v dmluZyBpdCBpcyB1c2luZyB0aGF0IElQIGFkZHJlc3MuIAogICAgCiAgIGR2Yk5pdURoY3BUYWJs ZSBwcm92aWRlcyBvYmplY3RzIGZvciBtYW5hZ2luZyBkeW5hbWljYWxseSBhc3NpZ25lZCAKICAg SVAgYWRkcmVzc2VzIHZpYSBESENQIGFuZCBCT09UUC4gIERIQ1AvQk9PVFAgcmVxdWVzdHMgbWF5 IGJlIGZvciBOSVUgCiAgIGludGVyZmFjZXMgYW5kIHJlbGF5ZWQgcmVxdWVzdHMgZnJvbSB0aGUg c3Vic2NyaWJlci4gIElmIGFuIE5JVSAKICAgaW50ZXJmYWNlIGRvZXMgbm90IGhhdmUgZHluYW1p YyBJUCBhZGRyZXNzIGFsbG9jYXRpb24gZW5hYmxlZCB0aGVuIAogICB0aGUgSVAgYWRkcmVzcyBv ZiB0aGUgaW50ZXJmYWNlIE1VU1QgYmUgc3BlY2lmaWVkIGluIAogICBkdmJOaXVTdGF0aWNJcFRh YmxlLiAKICAgIAogICBOb3RlOiAgVGhlIGR2Yk5pdVN0YXRpY0lwVGFibGUgc2hvdWxkIGJlIHVz ZWQgd2l0aCBjYXJlLiAgV2hlcmUgCiAgIHBvc3NpYmxlIGR2Yk5pdURoY3BUYWJsZSBTSE9VTEQg YmUgdXNlZCBpbiBwcmVmZXJlbmNlLiAgV2hlbiBhbiAKICAgaW50ZXJmYWNlIGhhcyBib3RoIGEg c3RhdGljIElQIGFkZHJlc3MgYXNzaWduZWQgYW5kIGR5bmFtaWMgCiAgIGFkZHJlc3NlcyBhc3Np Z25tZW50IGVuYWJsZWQsIHRoZSBhc3NpZ25lZCBkeW5hbWljIGFkZHJlc3Mgb3ZlcnJpZGVzIAog ICBhbGwgYXNzaWdubWVudHMgZm9yIHRoYXQgaW50ZXJmYWNlIGluIHRoZSBkdmJOaXVTdGF0aWNJ cFRhYmxlIHRhYmxlLiAKIAogICAzLjIuMy4gIEV2ZW50cyBhbmQgVHJhcHMgCiAgICAKICAgVGhp cyBNSUIgcHJvdmlkZXMgY29udHJvbCBmYWNpbGl0aWVzIGZvciByZXBvcnRpbmcgZXZlbnRzIHRo cm91Z2ggIAogICB0cmFwcyBhbmQgbm9uLXZvbGF0aWxlIGxvZ2dpbmcuICBJZiBldmVudHMgYXJl IHJlcG9ydGVkIHRocm91Z2ggCiAgIHRyYXBzLCB0aGUgc3BlY2lmaWVkIGNvbnZlbnRpb25zIG11 c3QgYmUgZm9sbG93ZWQuICBPdGhlciBtZWFucyBvZiAKICAgZXZlbnQgcmVwb3J0aW5nIGFyZSBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAKICAKVmFsZW50aW5lICAgICAgIElu Zm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAgICAgNSAMCiAg ICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5v dmVtYmVyIDIwMDAgCiAKIAogICAgCiAgIFZlbmRvcnMgU0hPVUxEIHByb3ZpZGUgdGltZS1vZi1k YXkgY2xvY2tzIGluIE5JVXMgdG8gcHJvdmlkZSB1c2VmdWwgCiAgIHRpbWUgc3RhbXBpbmcgb2Yg ZXZlbnRzLiAgV2hlcmUgcG9zc2libGUgdGhpcyBTSE9VTEQgYmUgc3luY2hyb25pc2VkIAogICB3 aXRoIGEgY2VudHJhbCB0aW1lIHNvdXJjZSwgdGhpcyB3aWxsIGFpZCBmYXVsdCBmaW5kaW5nIHdo ZW4gCiAgIG11bHRpcGxlIGVxdWlwbWVudCBsb2dzIGFyZSBiZWluZyBpbnZlc3RpZ2F0ZWQuIAog ICAgCiAgIFdoZW4gZHZiTml1RXZlbnRQb2xpY3kgaXMgc2V0IHRvIGNsZWFyTm93KDQpLCB0aGUg Zmlyc3QgZW50cnkgaW4gdGhlIAogICBsb2cgTVVTVCBiZSB0aGUgZGF0ZSBhbmQgdGltZSB0aGUg bG9nIHdhcyBjbGVhcmVkIGFuZCB0aGUgc291cmNlIElQIAogICBhZGRyZXNzIG9mIHRoZSBTTk1Q IFNFVCByZXF1ZXN0IHdoaWNoIGNhdXNlZCB0aGUgbG9nIHRvIGJlIGNsZWFyZWQuIAogICAgCiAg IEZvciBlYWNoIHZlbmRvci1zcGVjaWZpYyBldmVudCB0aGF0IGlzIHJlcG9ydGFibGUgdmlhIFRS QVAsIHRoZSAKICAgdmVuZG9yIG11c3QgY3JlYXRlIGFuIGVudGVycHJpc2Utc3BlY2lmaWMgdHJh cCBkZWZpbml0aW9uLiAgVHJhcCAKICAgZGVmaW5pdGlvbnMgTVVTVCBpbmNsdWRlIHRoZSBldmVu dCByZWFzb24gZW5jb2RlZCBhcyBEaXNwbGF5U3RyaW5nIAogICBhbmQgc2hvdWxkIGJlIGRlZmlu ZWQgYXM6IAogICAgCiAgIHRyYXBOYW1lIE5PVElGSUNBVElPTi1UWVBFIAogICAgICAgICAgIE9C SkVDVFMgeyAKICAgICAgICAgICAgICAgaWZJbmRleCwgCiAgICAgICAgICAgICAgIGV2ZW50UmVh c29uLCAKICAgICAgICAgICAgICAgb3RoZXIgdXNlZnVsIG9iamVjdHMgCiAgICAgICAgICAgfSAK ICAgICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgICAgIERFU0NSSVBUSU9OIAog ICAgICAgICAgICAgICAidHJhcCBkZXNjcmlwdGlvbiIgCiAgICAgICAgICAgOjo9IE9iamVjdCBJ ZCAKICAgIAogICBOb3RlIHRoYXQgaWZJbmRleCBpcyBvbmx5IGluY2x1ZGVkIGlmIHRoZSBldmVu dCBvciB0cmFwIGlzIGludGVyZmFjZSAKICAgcmVsYXRlZC4gCiAgICAKICAgQW4gZXhhbXBsZSAo ZmFrZSkgdmVuZG9yIGRlZmluZWQgdHJhcCBtaWdodCBiZTogCiAgICAKICAgeHl6VmVuZG9yUnNV bmNvcnJIaWdoTWFyayBOT1RJRklDQVRJT04tVFlQRSAKICAgICAgICAgICBPQkpFQ1RTIHsgCiAg ICAgICAgICAgICAgIGV2ZW50UmVhc29uLCAKICAgICAgICAgICAgICAgeHl6UnNVbmNvcnJDb3Vu dCAKICAgICAgICAgICB9IAogICAgICAgICAgIFNUQVRVUyAgY3VycmVudCAKICAgICAgICAgICBE RVNDUklQVElPTiAKICAgICAgICAgICAgICAgICJTZW50IGJ5IGEgTklVIHdoZW4gYSBjb25maWd1 cmFibGUgbnVtYmVyIG9mIHJlZWQgCiAgICAgICAgICAgICAgICBzb2xvbW9uIHVuY29ycmVjdGFi bGUgZXJyb3JzIG9jY3VyIGR1cmluZyB0aGUgc2FtcGxpbmcgCiAgICAgICAgICAgICAgICBwZXJp b2QgKDUgbWludXRlcykuICBVc2VkIHRvIHdhcm4gYSBtYW5hZ2VtZW50IHN0YXRpb24gCiAgICAg ICAgICAgICAgICBvZiBwb3RlbnRpYWwgZGVncmFkYXRpb24gb2YgdGhlIEhGQy4iIAogICAgICAg ICAgIDo6PSB7IHh5elRyYXBzIDIzIH0gCiAgICAKICAgSW4gdGhpcyBleGFtcGxlIGV2ZW50UmVh c29uIGlzIGEgRGlzcGxheVN0cmluZyBwcm92aWRpbmcgYSBodW1hbiAKICAgcmVhZGFibGUgZXJy b3IgbWVzc2FnZSBhbmQgeHl6UnNVbmNvcnJDb3VudCBpcyBhIEludGVnZXIzMiB3aGljaCAKICAg aW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgcmVlZCBzb2xvbW9uIHVuY29ycmVjdGFibGUgZXJyb3Jz IGR1cmluZyB0aGUgCiAgIGVwb2NoLiAKIAogICAzLjIuNC4gIFRyYXAgVGhyb3R0bGluZyAKICAg IAogICBUaGUgTklVIE1VU1QgcHJvdmlkZSBzdXBwb3J0IGZvciB0cmFwIG1lc3NhZ2UgdGhyb3R0 bGluZyBhcyAKICAgZGVzY3JpYmVkIGJlbG93LiAgVGhlIG5ldHdvcmsgb3BlcmF0b3IgY2FuIGVt cGxveSBtZXNzYWdlIHJhdGUgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhw aXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgIDYgDAogICAgICAgICAgICAgICAgIERW QiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAK ICAgdGhyb3R0bGluZyBvciB0cmFwIGxpbWl0aW5nIGJ5IG1hbmlwdWxhdGluZyB0aGUgYXBwcm9w cmlhdGUgTUlCIAogICB2YXJpYWJsZXMuIAogCiAgIDMuMi40LjEuICBUcmFwIHJhdGUgdGhyb3R0 bGluZyAKICAgIAogICBOZXR3b3JrIG9wZXJhdG9ycyBtYXkgZW1wbG95IGVpdGhlciBvZiB0d28g cmF0ZSBjb250cm9sIG1ldGhvZHMuICBJbiAKICAgdGhlIGZpcnN0IG1ldGhvZCwgdGhlIGRldmlj ZSBjZWFzZXMgdG8gc2VuZCB0cmFwcyB3aGVuIHRoZSByYXRlIAogICBleGNlZWRzIHRoZSBzcGVj aWZpZWQgbWF4aW11bSBtZXNzYWdlIHJhdGUuICBJdCByZXN1bWVzIHNlbmRpbmcgCiAgIHRyYXBz IG9ubHkgaWYgcmVhY3RpdmF0ZWQgYnkgYSBuZXR3b3JrIG1hbmFnZW1lbnQgc3RhdGlvbiByZXF1 ZXN0LiAKICAgIAogICBJbiB0aGUgc2Vjb25kIG1ldGhvZCwgdGhlIGRldmljZSByZXN1bWVzIHNl bmRpbmcgdHJhcHMgd2hlbiB0aGUgcmF0ZSAKICAgZmFsbHMgYmVsb3cgdGhlIHNwZWNpZmllZCBt YXhpbXVtIG1lc3NhZ2UgcmF0ZS4gCiAgICAKICAgVGhlIG5ldHdvcmsgb3BlcmF0b3IgY29uZmln dXJlcyB0aGUgc3BlY2lmaWVkIG1heGltdW0gbWVzc2FnZSByYXRlIAogICBieSBzZXR0aW5nIHRo ZSBtZWFzdXJlbWVudCBpbnRlcnZhbCAoaW4gc2Vjb25kcyksIGFuZCB0aGUgbWF4aW11bSAKICAg bnVtYmVyIG9mIHRyYXBzIHRvIGJlIHRyYW5zbWl0dGVkIHdpdGhpbiB0aGUgbWVhc3VyZW1lbnQg aW50ZXJ2YWwuIAogICBUaGUgb3BlcmF0b3IgY2FuIHF1ZXJ5IHRoZSBvcGVyYXRpb25hbCB0aHJv dHRsaW5nIHN0YXRlICh0byAKICAgZGV0ZXJtaW5lIHdoZXRoZXIgdHJhcHMgYXJlIGVuYWJsZWQg b3IgYmxvY2tlZCBieSB0aHJvdHRsaW5nKSBvZiB0aGUgCiAgIGRldmljZSwgYXMgd2VsbCBhcyBx dWVyeSBhbmQgc2V0IHRoZSBhZG1pbmlzdHJhdGl2ZSB0aHJvdHRsaW5nIHN0YXRlIAogICAodG8g bWFuYWdlIHRoZSByYXRlIGNvbnRyb2wgbWV0aG9kKSBvZiB0aGUgZGV2aWNlLiAKICAgIAogICAz LjIuNC4yLiAgTGltaXRpbmcgdGhlIHRyYXAgcmF0ZSAKICAgIAogICBOZXR3b3JrIG9wZXJhdG9y cyBtYXkgd2lzaCB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIHRyYXBzIHNlbnQgYnkgYSAKICAgZGV2 aWNlIG92ZXIgYSBzcGVjaWZpZWQgdGltZSBwZXJpb2QuICBUaGUgZGV2aWNlIGNlYXNlcyB0byBz ZW5kIAogICB0cmFwcyB3aGVuIHRoZSBudW1iZXIgb2YgdHJhcHMgZXhjZWVkcyB0aGUgc3BlY2lm aWVkIHRocmVzaG9sZC4gIEl0IAogICByZXN1bWVzIHNlbmRpbmcgdHJhcHMgb25seSB3aGVuIHRo ZSBtZWFzdXJlbWVudCBpbnRlcnZhbCBoYXMgcGFzc2VkLiAKICAgIAogICBUaGUgbmV0d29yayBv cGVyYXRvciBkZWZpbmVzIHRoZSBtYXhpbXVtIG51bWJlciBvZiB0cmFwcyBoZSBpcyAKICAgd2ls bGluZyB0byBoYW5kbGUgYW5kIHNldHMgdGhlIG1lYXN1cmVtZW50IGludGVydmFsIHRvIGEgbGFy Z2UgCiAgIG51bWJlciAoaW4gaHVuZHJlZHRocyBvZiBhIHNlY29uZCkuICBGb3IgdGhpcyBjYXNl LCB0aGUgCiAgIGFkbWluaXN0cmF0aXZlIHRocm90dGxpbmcgc3RhdGUgaXMgc2V0IHRvIHN0b3Ag YXQgdGhyZXNob2xkIHdoaWNoIGlzIAogICB0aGUgbWF4aW11bSBudW1iZXIgb2YgdHJhcHMuIAog ICAgCiAgIFNlZSAiVGVjaG5pcXVlcyBmb3IgTWFuYWdpbmcgQXN5bmNocm9ub3VzbHkgR2VuZXJh dGVkIEFsZXJ0cyIgCiAgIFtSRkMxMjI0XSBmb3IgZnVydGhlciBpbmZvcm1hdGlvbi4gCiAgICAK ICAgIAogICAzLjMuICBQcm90b2NvbCBGaWx0ZXJzIAogICAgCiAgIFRoZSBOSVUgTUlCIHByb3Zp ZGVzIG9iamVjdHMgZm9yIGJvdGggRXRoZXJuZXQgYW5kIElQIHByb3RvY29sIAogICBmaWx0ZXJz LiAgVGhlIEV0aGVybmV0IHByb3RvY29sIGZpbHRlciBlbnRyaWVzIGNhbiBiZSB1c2VkIHRvIGxp bWl0IAogICBOSVUgZm9yd2FyZGluZyB0byBhIHJlc3RyaWN0ZWQgc2V0IG9mIG5ldHdvcmstbGF5 ZXIgcHJvdG9jb2xzIChzdWNoIAogICBhcyBJUCwgSVBYLCBOZXRCSU9TLCBhbmQgQXBwbGV0YWxr KS4gCiAgICAKICAgVGhlIElQIHByb3RvY29sIGZpbHRlciBlbnRyaWVzIGNhbiBiZSB1c2VkIHRv IHJlc3RyaWN0IHVwc3RyZWFtIG9yIAogICBkb3duc3RyZWFtIHRyYWZmaWMgYmFzZWQgb24gc291 cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMsIAogICB0cmFuc3BvcnQtbGF5ZXIgcHJv dG9jb2xzIChzdWNoIGFzIFRDUCwgVURQLCBhbmQgSUNNUCksIGFuZCBzb3VyY2UgCiAgIGFuZCBk ZXN0aW5hdGlvbiBUQ1AvVURQIHBvcnQgbnVtYmVycy4gCiAgICAKICAgSW4gZ2VuZXJhbCwgYSBO SVUgYXBwbGllcyBmaWx0ZXJzIChvciBtb3JlIHByb3Blcmx5LCBjbGFzc2lmaWVycykgaW4gCiAg IGFuIG9yZGVyIGFwcHJvcHJpYXRlIHRvIHRoZSBsYXllcmluZyBtb2RlbC4gU3BlY2lmaWNhbGx5 LCB0aGUgCgogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVt YmVyIDIwMDAgICAgICAgICAgICAgICA3IAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0 d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgIEV0aGVybmV0 IGxheWVyIGZpbHRlcnMgYXJlIGFwcGxpZWQgZmlyc3QsIHRoZW4gdGhlIElQIGxheWVyIGluYm91 bmQgCiAgIGZpbHRlciBhbmQgZmluYWxseSB0aGUgSVAgbGF5ZXIgb3V0Ym91bmQgCiAgICAKICAg IAogICAgICAgICAgICAgICAqKioqKioqKioqKioqKioqKioqIAogICAgICAgICAgICAgICAqIEV0 aGVybmV0IEZpbHRlciAqIAogICAgICAgICAgICAgICAqKioqKioqKioqKioqKioqKioqIAogICAg ICAgICAgICAgICAgICAgICAgICB8IAogICAgICAgICAgICAgICAgICAgICAgICB2IAogICAgICAg ICAgICAgICAqKioqKioqKioqKioqKioqKioqKiAKICAgICAgICAgICAgICAgKiBJUCBBbnRpLVNw b29maW5nICogCiAgICAgICAgICAgICAgICoqKioqKioqKioqKioqKioqKioqIAogICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgdiAgICAgICAg CiAgICAgICAgICAgICAgICAqKioqKioqKioqKioqKioqIAogICAgICAgICAgICAgICAgKiBJUCBG aWx0ZXIgSW4gKiAKICAgICAgICAgICAgICAgICoqKioqKioqKioqKioqKiogCiAgICAgICAgICAg ICAgICAgICAgICAgIHwgCiAgICAgICAgICAgICAgICAgICAgICAgIHYgCiAgICAgICAgICAgICAg ICAqKioqKioqKioqKioqKioqKiAKICAgICAgICAgICAgICAgICogSVAgRmlsdGVyIE91dCAqIAog ICAgICAgICAgICAgICAgKioqKioqKioqKioqKioqKiogCiAgICAgICAgICAgICAgICAgICAgICAg ICAKIAogICAzLjMuMS4gIEV0aGVybmV0IEV0aGVyVHlwZS9TTkFQL0xMQyBGaWx0ZXJzICAgCiAg IGR2Yk5pdUV0aGVybmV0RmlsdGVyVGFibGUgCiAgICAKICAgVGhlIEV0aGVybmV0IChsZXZlbC0y KSBmaWx0ZXJzIGFyZSBjb250YWluZWQgaW4gdGhlIAogICBkdmJOaXVFdGhlcm5ldEZpbHRlclRh YmxlIGFuZCBhcmUgYXBwbGllZCB0byBsZXZlbC0yIGZyYW1lcyBlbnRlcmluZyAKICAgdGhlIGNh YmxlIG1vZGVtIGZyb20gZWl0aGVyIHRoZSBEVkIgTUFDIGludGVyZmFjZSBvciBmcm9tIG9uZSBv ZiB0aGUgCiAgIENQRSAoRXRoZXJuZXQgb3Igb3RoZXIgRXRoZXJuZXQgbGlrZSkgaW50ZXJmYWNl cy4gIFRoZXNlIGZpbHRlcnMgYXJlIAogICB1c2VkIHRvIHByb2hpYml0IHRoZSBwcm9jZXNzaW5n IGFuZCBmb3J3YXJkaW5nIG9mIGNlcnRhaW4gdHlwZXMgb2YgCiAgIGxldmVsLTIgdHJhZmZpYyB0 aGF0IG1heSBiZSBkaXNydXB0aXZlIHRvIHRoZSBuZXR3b3JrLiAgVGhlIGZpbHRlcnMsIAogICBh cyBjdXJyZW50bHkgc3BlY2lmaWVkLCBjYW4gYmUgc2V0IHRvIGNhdXNlIHRoZSBOSVUgdG8gZWl0 aGVyIGRyb3AgCiAgIGZyYW1lcyB3aGljaCBtYXRjaCBhdCBsZWFzdCBvbmUgZmlsdGVyLCBvciB0 byBwcm9jZXNzIGEgZnJhbWUgd2hpY2ggCiAgIG1hdGNoZXMgYXQgbGVhc3QgZmlsdGVyLiAgU29t ZSBleGFtcGxlcyBvZiBwb3NzaWJsZSBjb25maWd1cmF0aW9ucyAKICAgd291bGQgYmUgdG8gb25s eSBwZXJtaXQgSVAgKGFuZCBBUlApIHRyYWZmaWMsIG9yIHRvIGRyb3AgTkVUQlVFSSAKICAgdHJh ZmZpYy4gCiAgICAKICAgMy4zLjIgIElQIEFudGktU3Bvb2ZpbmcgRmlsdGVycyAtIGR2Yk5pdUNw ZVRhYmxlIAogICAgCiAgIElQIEFudGktc3Bvb2ZpbmcgZmlsdGVycyBhcmUgYXBwbGllZCB0byBw YWNrZXRzIGVudGVyaW5nIHRoZSBOSVUgCiAgIGZyb20gb25lIG9mIHRoZSBDUEUgaW50ZXJmYWNl cyBhbmQgYXJlIGludGVuZGVkIHRvIHByZXZlbnQgYSAKICAgc3Vic2NyaWJlciBmcm9tIHN0ZWFs aW5nIG9yIG1pcy11c2luZyBJUCBhZGRyZXNzZXMgdGhhdCB3ZXJlIG5vdCAKICAgYXNzaWduZWQg dG8gdGhlIHN1YnNjcmliZXIuICBJZiB0aGUgZmlsdGVycyBhcmUgYWN0aXZlIChlbmFibGVkKSwg CiAgIHRoZSBzb3VyY2UgYWRkcmVzcyAgICBvZiB0aGUgSVAgcGFja2V0IG11c3QgbWF0Y2ggYXQg bGVhc3Qgb25lIElQIAogICBhZGRyZXNzL3JhbmdlIGluIHRoaXMgdGFibGUgb3IgaXQgaXMgZGlz Y2FyZGVkIHdpdGhvdXQgZnVydGhlciAKICAgcHJvY2Vzc2luZy4gCiAgICAKICAgVGhlIHRhYmxl IGNhbiBiZSBhdXRvbWF0aWNhbGx5IHBvcHVsYXRlZCB3aGVyZSB0aGUgZmlyc3QgTiBkaWZmZXJl bnQgCiAgIElQIGFkZHJlc3NlcyBzZWVuIGZyb20gdGhlIENQRSBzaWRlIG9mIHRoZSBOSVUgYXJl IHVzZWQgdG8gCiAgIGF1dG9tYXRpY2FsbHkgcG9wdWxhdGUgdGhlIHRhYmxlLiAgVGhlIGFudGkt c3Bvb2ZpbmcgZmlsdGVycyBhcmUgCgogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAt IEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgICA4IAwKICAgICAgICAgICAgICAg ICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAK IAogCiAgIHNwZWNpZmllZCBpbiB0aGUgZHZiTml1Q3BlVGFibGUgYW5kIHRoZSBwb2xpY3kgZm9y IGF1dG9tYXRpY2FsbHkgCiAgIGNyZWF0aW5nIGZpbHRlcnMgaW4gdGhhdCB0YWJsZSBpcyBjb250 cm9sbGVkIGJ5IGRvY3NEZXZDcGVFbnJvbGwgYW5kIAogICBEdmJOaXVDcGVNYXggYXMgd2VsbCBh cyB0aGUgbmV0d29yayBtYW5hZ2VtZW50IGFnZW50LiAKIAogICAzLjMuMy4gIElQIEZpbHRlcmlu ZyAtIGR2Yk5pdUlwRmlsdGVyVGFibGUgCiAgICAKICAgVGhlIElQIEZpbHRlcmluZyB0YWJsZSBh Y3RzIGFzIGEgY2xhc3NpZmllciB0YWJsZS4gIEVhY2ggcm93IGluIHRoZSAKICAgdGFibGUgZGVz Y3JpYmVzIGEgdGVtcGxhdGUgYWdhaW5zdCB3aGljaCBJUCBwYWNrZXRzIGFyZSBjb21wYXJlZC4g CiAgIFRoZSB0ZW1wbGF0ZSBpbmNsdWRlcyBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3Nl cyAoYW5kIHRoZWlyIAogICBhc3NvY2lhdGVkIG1hc2tzKSwgdXBwZXIgbGV2ZWwgcHJvdG9jb2wg KGUuZy4gVENQLCBVRFApLCBzb3VyY2UgYW5kIAogICBkZXN0aW5hdGlvbiBwb3J0IHJhbmdlcywg VE9TIGFuZCBUT1MgbWFzay4gQSByb3cgYWxzbyBjb250YWlucyAKICAgaW50ZXJmYWNlIGFuZCB0 cmFmZmljIGRpcmVjdGlvbiBtYXRjaCB2YWx1ZXMgd2hpY2ggaGF2ZSB0byBiZSAKICAgY29uc2lk ZXJlZCBpbiBjb21iaW5hdGlvbi4gIEFsbCBjb2x1bW5zIG9mIGEgcGFydGljdWxhciByb3cgbXVz dCAKICAgbWF0Y2ggdGhlIGFwcHJvcHJpYXRlIGZpZWxkcyBpbiB0aGUgcGFja2V0LCBhbmQgbXVz dCBtYXRjaCB0aGUgCiAgIGludGVyZmFjZSBhbmQgZGlyZWN0aW9uIGl0ZW1zIGZvciB0aGUgcGFj a2V0IHRvIHJlc3VsdCBpbiBhIG1hdGNoIHRvIAogICB0aGUgcGFja2V0LiAKICAgIAogICBXaGVu IGNsYXNzaWZ5aW5nIGEgcGFja2V0LCB0aGUgdGFibGUgaXMgc2Nhbm5lZCBiZWdpbm5pbmcgd2l0 aCB0aGUgCiAgIGxvd2VzdCBudW1iZXIgZmlsdGVyLiAgSWYgdGhlIGFnZW50IGZpbmRzIGEgbWF0 Y2gsIGl0IHBlcmZvcm1zIHRoZSAKICAgc3BlY2lmaWVkIGFjdGlvbi4gIElmIHRoZSBtYXRjaGVk IGZpbHRlciBoYXMgdGhlIGNvbnRpbnVlIGJpdCBzZXQsIAogICB0aGUgYWdlbnQgY29udGludWVz IHRoZSBzY2FuIHBvc3NpYmx5IG1hdGNoaW5nIGFkZGl0aW9uYWwgZmlsdGVycyAKICAgYW5kIHBl cmZvcm1pbmcgdGhlIHNwZWNpZmllZCBhY3Rpb25zLiAgVGhpcyBhbGxvd3MgdGhlIGFnZW50IHRv IHRha2UgCiAgIG9uZSBzZXQgb2YgYWN0aW9ucyBmb3IgdGhlIDI0LjAuMTYvMjU1LjI1NS4yNTUu MCBncm91cCBhbmQgb25lIHNldCAKICAgb2YgYWN0aW9ucyBmb3IgdGVsbmV0IHBhY2tldHMgdG8v ZnJvbSAyNC4wLjE2LjMwIGFuZCB0aGVzZSBzZXRzIG9mIAogICBhY3Rpb25zIG1heSBub3QgYmUg bXV0dWFsbHkgZXhjbHVzaXZlLiAKICAgIAogICBPbmNlIGEgcGFja2V0IGlzIG1hdGNoZWQsIG9u ZSBvZiBmaXZlIGFjdGlvbnMgaGFwcGVuIGJhc2VkIG9uIHRoZSAKICAgc2V0dGluZyBvZiBkdmJO aXVGaWx0ZXJBY3Rpb24gaW4gdGhlIHJvdy4gIFRoZSBhY3Rpb25zIGFyZTogCiAgIG8gICAgRGlz Y2FyZGVkLiAgVGhlIHBhY2tldCBpcyBkcm9wcGVkLCBhbmQgbm8gZnVydGhlciBwcm9jZXNzaW5n IGlzIAogICAgICAgIHJlcXVpcmVkLiAKICAgbyAgICBBY2NlcHQuICBUaGUgcGFja2V0IGlzIGFj Y2VwdGVkIGFuZCBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQgCiAgICAgICAgY29udGludWVzLiAK ICAgbyAgICBOQVQuICBUaGUgcGFja2V0IGlzIHRvIGJlIGFjY2VwdGVkIGFuZCBoYXZlIE5BVCBh cHBsaWVkLiAgCiAgICAgICAgUHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IGNvbnRpbnVlcyB1c2lu ZyBpdHMgbmV3IElQIGFkZHJlc3MuIAogICBvICAgIE5BUFQuIFRoZSBwYWNrZXQgaXMgdG8gYmUg YWNjZXB0ZWQgYW5kIGhhdmUgTkFUIGFwcGxpZWQuICAKICAgICAgICBQcm9jZXNzaW5nIG9mIHRo ZSBwYWNrZXQgY29udGludWVzIHVzaW5nIGl0cyBuZXcgSVAgYWRkcmVzcyBhbmQgCiAgICAgICAg cG9ydCBudW1iZXIuIAogICBvICAgIFRvc01hcC4gIEludm9rZXMgdGhlIGFjdGlvbiBvZiByZXdy aXRpbmcgdGhlIFRPUyBiaXRzIGluIHRoZSBJUCAKICAgICAgICBoZWFkZXIgYmFzZWQgdXAgdGhl IGVudHJ5IGluIGR2Yk5pdUlwVE9TTWFwVGFibGUgaWRlbnRpZmllZCBieSAKICAgICAgICBkdmJO aXVJcEZpbHRlckFjdGlvblB0ci4gICAgCiAgICAKICAgSWYgZHZiTml1SXBGaWx0ZXJDb250aW51 ZSBpcyBzZXQgdG8gdHJ1ZSwgc2Nhbm5pbmcgb2YgdGhlIHRhYmxlICAKICAgY29udGludWVzICh1 bmxlc3MgdGhlIHBhY2tldCB3YXMgZGlzY2FyZGVkKSBhbmQgYWRkaXRpb25hbCBtYXRjaGVzIAog ICBtYXkgcmVzdWx0LiAKIAogCjQuIERlZmluaXRpb25zIAogICAgCiAgIERWQi1DQUJMRS1OSVUt TUlCIERFRklOSVRJT05TIDo6PSBCRUdJTiAKICAgIAogICAgCiAgIElNUE9SVFMgCiAgICAgICBN T0RVTEUtSURFTlRJVFksIAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGly ZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgICA5IAwKICAgICAgICAgICAgICAgICBEVkIg Q2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAg ICAgICBPQkpFQ1QtVFlQRSwgCiAgICAgICBDb3VudGVyMzIsIAogICAgICAgSW50ZWdlcjMyLCAK ICAgICAgIFVuc2lnbmVkMzIsIAogICAgICAgZXhwZXJpbWVudGFsIAogICAgICAgICAgIEZST00g U05NUHYyLVNNSSAKICAgICAgIEluZXRBZGRyZXNzLCAKICAgICAgIEluZXRBZGRyZXNzVHlwZSAK ICAgICAgICAgICBGUk9NIElORVQtQUREUkVTUy1NSUIgCiAgICAgICBSb3dTdGF0dXMsIAogICAg ICAgRGF0ZUFuZFRpbWUsIAogICAgICAgVHJ1dGhWYWx1ZSwgCiAgICAgICBURVhUVUFMLUNPTlZF TlRJT04gCiAgICAgICAgICAgRlJPTSBTTk1QdjItVEMgCiAgICAgICBTbm1wQWRtaW5TdHJpbmcg CiAgICAgICAgICAgRlJPTSBTTk1QLUZSQU1FV09SSy1NSUIgCiAgICAgICBPQkpFQ1QtR1JPVVAs IAogICAgICAgTU9EVUxFLUNPTVBMSUFOQ0UgCiAgICAgICAgICAgRlJPTSBTTk1QdjItQ09ORiAK ICAgICAgIEludGVyZmFjZUluZGV4T3JaZXJvLCAKICAgICAgIEludGVyZmFjZUluZGV4LCAKICAg ICAgIGlmSW5kZXgsIAogICAgICAgICAgIEZST00gSUYtTUlCOyAKICAgIAogICAgCiAgIC0tIFRo aXMgTUlCIGlzIGF3YWl0aW5nIGFuIGV4cGVyaW1lbnQgT0lELiAKICAgIAogICBkdmJEZXZpY2Ug T0JKRUNUIElERU5USUZJRVIgOjo9IHsgZXhwZXJpbWVudGFsIHh4IH0gLS0gU2VlIEFib3ZlIAog ICAgCiAgIGR2Yk5pdSBNT0RVTEUtSURFTlRJVFkgCiAgICAgICBMQVNULVVQREFURUQgICAgIjAw MTEwMTAwMDBaIiAKICAgICAgIE9SR0FOSVpBVElPTiAgICAiRFZCL0RBVklDIEludGVyb3BlcmFi aWxpdHkgQ29uc29ydGl1bSBUZWNobmljYWwgCiAgICAgICAgICAgICAgICAgICAgICAgIFdvcmtp bmcgR3JvdXAiIAogICAgICAgQ09OVEFDVC1JTkZPIAogICAgICAgICAgICAgICIgICAgICAgIEFu ZHJldyBWYWxlbnRpbmUgCiAgICAgICAgICAgICAgIFBvc3RhbDogSHVnaGVzIE5ldHdvcmsgU3lz dGVtcyBMdGQgCiAgICAgICAgICAgICAgICAgICAgICAgU2F4b24gU3RyZWV0LCAKICAgICAgICAg ICAgICAgICAgICAgICBMaW5mb3JkIFdvb2QsIAogICAgICAgICAgICAgICAgICAgICAgIE1pbHRv biBLZXluZXMuIAogICAgICAgICAgICAgICAgICAgICAgIE1LMTQgNkxEIAogICAgICAgICAgICAg ICAgICAgICAgIEVOR0xBTkQgCiAgICAKICAgICAgICAgICAgICAgICAgVGVsOiArNDQgMTkwOCAy MjExMjIgCiAgICAgICAgICAgICAgICAgIEZheDogKzQ0IDE5MDggMjIxMTI3IAogICAgICAgICAg ICAgICBFLW1haWw6IGEudmFsZW50aW5lQGV1Lmhucy5jb20iIAogICAgCiAgICAgICBERVNDUklQ VElPTiAgICAgIlRoZSBNSUIgbW9kdWxlcyBmb3IgTklVcyB0aGF0IAogICAgICAgICAgICAgICAg ICAgICAgICBjb25mb3JtIHRvIHRoZSBFdXJvTW9kZW0gc3BlY2lmaWNhdGlvbi4gIFRoaXMgCiAg ICAgICAgICAgICAgICAgICAgICAgIE1JQiBhc3N1bWVzIHRoZSBOSVUgaW1wbGVtZW50cyBNSUIt SUkgUkZDIDEyMTMiIAogICAgCiAgICAgICBSRVZJU0lPTiAgICAgICAgIjAwMTEwMTAwMDBaIiAK ICAgICAgIERFU0NSSVBUSU9OICAgICAiTmV3IGR2Yk5pdU11bHRpY2FzdCBvYmplY3QuICBOQVQg ZGVzY3JpcHRpb25zIAogICAgICAgICAgICAgICAgICAgICAgICB1cGRhdGVkLiAgTmV3IGFuZCBz aW1wbGVyIHRvIGltcGxlbWVudCAgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0g RXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMTAgDAogICAgICAgICAgICAgICAg IERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAog CiAKICAgICAgICAgICAgICAgICAgICAgICAgQW50aS1zcG9vZmluZyB0YWJsZSBkdmJOaXVDcGUs ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgYW5kIElQIGZpbHRlciB0YWJsZSBtb2RpZmll ZCB0byBzdXBwb3J0IHRoaXMuIiAKICAgIAogICAgICAgUkVWSVNJT04gICAgICAgICIwMDA1MTUw MDAwWiIgCiAgICAgICBERVNDUklQVElPTiAgICAgIkFsbCBvYmplY3RzIG9mIHR5cGUgSXBBZGRy ZXNzIG5vdyBjb25zaXN0IG9mIAogICAgICAgICAgICAgICAgICAgICAgICB0d28gb2JqZWN0cyAo U2VlIFJGQzI4NTEpLiAgRGVzY3JpcHRpb25zIGZvciAKICAgICAgICAgICAgICAgICAgICAgICAg REhDUCByZWxhdGVkIG9iamVjdHMgaGF2ZSBiZWVuIGZpeGVkLiAgSW5kaWNlcyAgCiAgICAgICAg ICAgICAgICAgICAgICAgIGZvciBzb21lIHRoZSB0YWJsZXMgaGF2ZSBiZWVuIG1vZGlmaWVkIHRv ICAKICAgICAgICAgICAgICAgICAgICAgICAgaW1wcm92ZSB1c2UuIiAKICAgIAogICAgICAgUkVW SVNJT04gICAgICAgICIwMDAzMDUwMDAwWiIgCiAgICAgICBERVNDUklQVElPTiAgICAgImR2Yk5p dU5tQWNjZXNzVGFibGUgaGFzIGJlZW4gcmVtb3ZlZCBhcyB0aGlzIAogICAgICAgICAgICAgICAg ICAgICAgICBNSUIgaXMgaW50ZW5kZWQgZm9yIFNOTVB2MyIgCiAKICAgICAgIFJFVklTSU9OICAg ICAgICAiOTkxMjAzMDAwMFoiIAogICAgICAgREVTQ1JJUFRJT04gICAgICJBbGwgcmVmZXJlbmNl cyB0byBtb2RlbS9DZG0gaGF2ZSBiZWVuIHJlcGxhY2VkIAogICAgICAgICAgICAgICAgICAgICAg ICB3aXRoIE5JVS4gIEZpeGVkIGdyb3VwIHJlZmVyZW5jZXMgaW4gdGhlICAKICAgICAgICAgICAg ICAgICAgICAgICAgY29tcGxpYW5jZSBzZWN0aW9uLiAgUmVtb3ZlZCBERUZWQUwgY2xhdXNlIGZy b20gCiAgICAgICAgICAgICAgICAgICAgICAgIHNjYWxhciBvYmplY3RzLiAgQ29ycmVjdGVkIGRl c2NyaXB0aW9uIG9mIAogICAgICAgICAgICAgICAgICAgICAgICBkdmJOaXVFdmVudFRhYmxlLiAg ZHZiTml1RGhjcFRhYmxlIGhhcyBiZWVuIAogICAgICAgICAgICAgICAgICAgICAgICBtb2RpZmll ZCB0byBzdXBwb3J0IGJhY2t1cCBESENQIHNlcnZlcnMuICAgCiAgICAgICAgICAgICAgICAgICAg ICAgIGR2Yk5pdUV1cm9sb2FkZXIgb2JqZWN0IGhhcyBiZWVuIGFkZGVkIHRvIAogICAgICAgICAg ICAgICAgICAgICAgICBlbmFibGUgb3IgZGlzYWJsZSB0aGUgRXVyb0xvYWRlci4gCiAgICAgICAg ICAgICAgICAgICAgICAgIGR2Yk5pdU9wZXJTdGF0dXMgbm93IG9ubHkgcmVmbGVjdHMgdGhlIE5J VSAgCiAgICAgICAgICAgICAgICAgICAgICAgIHN0YXR1cywgTUFDIHN0YXR1cyBoYXMgYmVlbiBt b3ZlZCB0byB0aGUgCiAgICAgICAgICAgICAgICAgICAgICAgIGludGVyZmFjZSBNSUIuIiAKICAg IAogICAgICAgUkVWSVNJT04gICAgICAgICI5OTEwMDEwMDAwWiIgCiAgICAgICBERVNDUklQVElP TiAgICAgIlRoZSBtaWIgaGFzIGJlZW4gbW9kaWZpZWQgdG8gaW5jb3Jwb3JhdGUgdGhlICAKICAg ICAgICAgICAgICAgICAgICAgICAgY29tbWVudHMgbWFkZSBieSB0aGUgV0dUIGR1cmluZyB0aGUg IAogICAgICAgICAgICAgICAgICAgICAgICAyNy8yOCBTZXAgMTk5OSBtZWV0aW5nLiAgVGhlIG1v c3Qgc2lnbmlmaWNhbnQgCiAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5nZXMgd2VyZSB0byB0 aGUgREhDUCBncm91cCBhbmQgdG8gdGhlICAKICAgICAgICAgICAgICAgICAgICAgICAgbWFuYWdl bWVudCBvZiB0cmFwcy4gIEFsc28gc29tZSBncm91cHMgYXJlIG5vdyAKICAgICAgICAgICAgICAg ICAgICAgICAgb3B0aW9uYWwuIiAKICAgIAogICAgICAgUkVWSVNJT04gICAgICAgICI5OTA3MDcx NTAwWiIgCiAgICAgICBERVNDUklQVElPTiAgICAgIlRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhl IE1JQiIgCiAgIDo6PSB7ZHZiRGV2aWNlIDF9IAogICAgCiAgIC0tIFN1YiBkaXZpZGVkIGR2Yk5p dSBpbnRvIE1JQiBvYmplY3RzIGFuZCBjb25mb3JtYW5jZSAKICAgIAogICBkdmJOaXVNSUJvYmpl Y3RzIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7ZHZiTml1IDF9IAogICBkdmJOaXVNSUJDb25mb3Jt IE9CSkVDVCBJREVOVElGSUVSIDo6PSB7ZHZiTml1IDJ9IAogICAgCiAgIC0tIERlZmluZSBncm91 cHMgdW5kZXIgZHZiTml1TUlCb2JqZWN0cyAKICAgIAogICBkdmJOaXVTeXN0ZW0gICAgIE9CSkVD VCBJREVOVElGSUVSIDo6PSB7ZHZiTml1TUlCb2JqZWN0cyAxfSAKICAgZHZiTml1U29mdHdhcmUg ICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0ge2R2Yk5pdU1JQm9iamVjdHMgMn0gCiAgIGR2Yk5pdURo Y3AgICAgICAgT0JKRUNUIElERU5USUZJRVIgOjo9IHtkdmJOaXVNSUJvYmplY3RzIDN9IAogICBk dmJOaXVFdmVudCAgICAgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7ZHZiTml1TUlCb2JqZWN0cyA0 fSAKICAgZHZiTml1SXBGaWx0ZXIgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0ge2R2Yk5pdU1JQm9i amVjdHMgNX0gCiAgIGR2Yk5pdU5hdCAgICAgICAgT0JKRUNUIElERU5USUZJRVIgOjo9IHtkdmJO aXVNSUJvYmplY3RzIDZ9IAogICBkdmJOaXVOYXB0ICAgICAgIE9CSkVDVCBJREVOVElGSUVSIDo6 PSB7ZHZiTml1TUlCb2JqZWN0cyA3fSAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwg LSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAgICAxMSAMCiAgICAgICAgICAgICAg ICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAg CiAKIAogICBkdmROaXVFdGhGaWx0ZXIgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7ZHZiTml1TUlC b2JqZWN0cyA4fSAKICAgZHZiTml1Q3BlICAgICAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0ge2R2 Yk5pdU1JQm9iamVjdHMgOX0gCiAgICAKICAgLS1EZWZpbmUgaWRlbnRpZmllcnMgdW5kZXIgZHZi Tml1TUlCQ29uZm9ybSAKICAgIAogICBkdmJOaXVDb21wbGlhbmNlcyAgT0JKRUNUIElERU5USUZJ RVIgOjo9IHtkdmJOaXVNSUJDb25mb3JtIDF9IAogICBkdmJOaXVHcm91cHMgICAgICAgT0JKRUNU IElERU5USUZJRVIgOjo9IHtkdmJOaXVNSUJDb25mb3JtIDJ9IAogICAgCiAgICAgCiAgIC0tIERl ZmluaXRpb24gb2YgdGV4dHVhbCBjb252ZW50aW9ucyAKICAgIAogICBEdmJFdmVudFByaW9yaXR5 IDo6PSBURVhUVUFMLUNPTlZFTlRJT04gCiAgICAgICBTVEFUVVMgICAgICAgICBjdXJyZW50IAog ICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgICAgIlRoaXMgcmVwcmVzZW50cyBwb3NzaWJs ZSBldmVudCBwcmlvcml0aWVzLiAgVGhlc2UgYXJlICAKICAgICAgICAgICAgICAgb3JkZXJlZCBm cm9tIG1vc3QgKGVtZXJnZW5jeSkgY3JpdGljYWwgdG8gbGVhc3QgCiAgICAgICAgICAgICAgIChk ZWJ1Zyljcml0aWNhbC4iIAogICAgICAgU1lOVEFYICAgICAgIElOVEVHRVIgeyAKICAgICAgICAg ICAgICAgICAgICAgICAgZW1lcmdlbmN5KDEpLCAKICAgICAgICAgICAgICAgICAgICAgICAgYWxl cnQoMiksIAogICAgICAgICAgICAgICAgICAgICAgICBjcml0aWNhbCgzKSwgCiAgICAgICAgICAg ICAgICAgICAgICAgIGVycm9yKDQpLCAKICAgICAgICAgICAgICAgICAgICAgICAgd2FybmluZyg1 KSwgCiAgICAgICAgICAgICAgICAgICAgICAgIG5vdGljZSg2KSwgCiAgICAgICAgICAgICAgICAg ICAgICAgIGluZm9ybWF0aW9uKDcpLCAKICAgICAgICAgICAgICAgICAgICAgICAgZGVidWcoOCkg CiAgICAgICAgICAgICAgICAgICAgfSAKICAgIAogICAtLSBEZWZpbml0aW9uIG9mIE1JQiBvYmpl Y3RzIAogICAgCiAgIC0tID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PSAKICAgLS0gPSAgTklVIFN5c3RlbSBHcm91cCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAKICAgLS0gPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IAogICAgCiAg IGR2Yk5pdU1pYlZlcnNpb24gT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBTbm1wQWRt aW5TdHJpbmcgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAgICAgICBTVEFUVVMgICAg ICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSBNSUIgdmVyc2lv biBudW1iZXIuIiAKICAgLS0gIERFRlZBTCB7ICcxLjAnIH0gCiAgIDo6PSB7IGR2Yk5pdVN5c3Rl bSAxfSAKICAgIAogICBkdmJOaXVTZXJpYWxOdW0gT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVgg ICAgICBTbm1wQWRtaW5TdHJpbmcgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAgICAg ICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRo aXMgaXMgdGhlIHNlcmlhbCBudW1iZXIgb2YgdGhlIGVxdWlwbWVudC4gIEl0IHNob3VsZCAKICAg ICAgICAgICAgaWRlbnRpZnkgdGhlIG1hbnVmYWN0dXJlciwgbW9kZWwgYW5kIHJldnNpb24gb2Yg dGhlICAKICAgICAgICAgICAgZXF1aW1lbnQiIAogICA6Oj0geyBkdmJOaXVTeXN0ZW0gMiB9IAog ICAgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIg MjAwMCAgICAgICAgICAgICAgMTIgDAogICAgICAgICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3Jr IEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAKICAgZHZiTml1UmVzZXRO b3cgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJTlRFR0VSIHsgCiAgICAgICAgICAg ICAgICAgICAgICAgcmVzZXROb3coMSksIAogICAgICAgICAgICAgICAgICAgICAgIHJlYWR5KDIp IAogICAgICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUgCiAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAg IldoZW4gdGhpcyBvYmplY3QgaXMgc2V0IHRvIHJlc2V0Tm93IGl0IHdpbGwgY2F1c2UgYSAKICAg ICAgICAgICAgaGFyZHdhcmUgcmVzZXQgZm9sbG93ZWQgYnkgc2lnbiBvbi4gIFdoZW4gcmVhZCB0 aGlzIG9iamVjdCAKICAgICAgICAgICAgcmV0dXJucyByZWFkeS4iIAogICA6Oj0geyBkdmJOaXVT eXN0ZW0gMyB9IAogICAgCiAgIGR2Yk5pdVJlc2V0Q291bnRzIE9CSkVDVC1UWVBFIAogICAgICAg U1lOVEFYICAgICAgQ291bnRlcjMyIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5IAogICAg ICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJU aGlzIGNvdW50cyB0aGUgbnVtYmVyIG9mIHN5c3RlbSByZXNldHMgc2luY2UgbGFzdCBwb3dlciAK ICAgICAgICAgICAgb24uIiAKICAgOjo9IHsgZHZiTml1U3lzdGVtIDR9IAogICAgCiAgIGR2Yk5p dURhdGVBbmRUaW1lIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgRGF0ZUFuZFRpbWUg CiAgICAgICBNQVgtQUNDRVNTICByZWFkLXdyaXRlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVu dCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgZGF0ZSBhbmQgdGltZS4gIFNl ZSBSRkMxOTAzIiAKICAgOjo9IHsgZHZiTml1U3lzdGVtIDV9IAogICAgCiAgIGR2Yk5pdU9wZXJT dGF0dXMgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJTlRFR0VSIHsgCiAgICAgICAg ICAgICAgICAgICAgICAgcHJvdmlzaW9uaW5nKDEpLCAKICAgICAgICAgICAgICAgICAgICAgICBy dW5uaW5nKDIpLCAKICAgICAgICAgICAgICAgICAgICAgICBzdG9wcGVkKDMpLCAKICAgICAgICAg ICAgICAgICAgICAgICBmYWlsZWQoNCksIAogICAgICAgICAgICAgICAgICAgICAgIG90aGVyKDUp IAogICAgICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seSAKICAg ICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAi VGhlIG9wZXJhdGlvbmFsIHN0YXR1cyBvZiB0aGUgTklVLiAKICAgICAgICAgICAgcHJvdmlzaW9u aW5nIC0gVGhlIE5JVSBpcyBjdXJyZW50bHkgcHJvdmlzaW9uaW5nLiAKICAgICAgICAgICAgcnVu bmluZyAtIFRoZSBOSVUgaGFzIGF0IGxlYXN0IG9uZSBvcGVyYXRpbmcgY29ubmVjdGlvbi4gCiAg ICAgICAgICAgIHN0b3BwZWQgLSBUaGUgTklVIGhhcyBubyBvcGVyYXRpbmcgY29ubmVjdGlvbi4g CiAgICAgICAgICAgIGZhaWxlZCAgLSBUaGUgTklVIGhhcyBleHBlcmllbmNlZCBhIGZhaWx1cmUg d2hpY2ggcHJldmVudHMgCiAgICAgICAgICAgICAgICAgICAgICBmdXJ0aGVyIG9wZXJhdGlvbi4g CiAgICAgICAgICAgIG90aGVyICAgLSB1c2VkIGZvciBhbnkgY2FzZSB0aGF0IGlzIG5vdCBleHBs aWNpdGx5ICAKICAgICAgICAgICAgICAgICAgICAgIGlkZW50aWZpZWQiICAgICAKICAgOjo9IHsg ZHZiTml1U3lzdGVtIDYgfSAKICAgIAogICBkdmJOaXVNb2RlbXR5cGUgT0JKRUNULVRZUEUgCiAg ICAgICBTWU5UQVggICAgICBJTlRFR0VSIHsgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlv bmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMTMgDAogICAgICAgICAg ICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAy MDAwIAogCiAKICAgICAgICAgICAgICAgICAgICAgICBjbGFzc0EoMSksIAogICAgICAgICAgICAg ICAgICAgICAgIGNsYXNzQigyKSwgCiAgICAgICAgICAgICAgICAgICAgICAgb3RoZXIoMykgCiAg ICAgICAgICAgICAgICAgICB9IAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5IAogICAgICAg U1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUg RXVyb01vZGVtIGNsYXNzIHRvIHdoaWNoIHRoZSBOSVUgYmVsb25ncyBhcyBzcGVjaWZpZWQgIAog ICAgICAgICAgICBpbiBFQ0NBIEV1cm9Nb2RlbSBTcGVjaWZpY2F0aW9uIHZlcnNpb24gMS4wIiAK ICAgOjo9IHsgZHZiTml1U3lzdGVtIDcgfSAKICAgIAogICAtLSBTdGF0aWMgSVAgYWRkcmVzcyBh c3NpZ25tZW50IHRhYmxlIAogICAgCiAgIGR2Yk5pdVN0YXRpY0lwVGFibGUgT0JKRUNULVRZUEUg CiAgICAgICBTWU5UQVggICAgICBTRVFVRU5DRSBPRiBEdmJOaXVTdGF0aWNJcEVudHJ5IAogICAg ICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50 IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoaXMgdGFibGUgaXMgdXNlZCB0byBh c3NpZ24gc3RhdGljIElQIGFkZHJlc3NlcyB0byBOSVUgCiAgICAgICAgICAgIGludGVyZmFjZXMu ICBJdCBuZWVkcyB0byBiZSB1c2VkIHdpdGggY2FyZSEgREhDUC9CT09UUCAKICAgICAgICAgICAg YXNzaWduZWQgYWRkcmVzc2VzIG92ZXJpZGUgZW50cmllcyBpbiB0aGlzIHRhYmxlLiAgIAogICAg ICAgICAgICBUaGUgdGFibGUgaXMgcmVsYXRlZCB0byBpZlRhYmxlIGluIHRoZSBJRi1NSUIuIiAK ICAgOjo9IHsgZHZiTml1U3lzdGVtIDggfSAKICAgIAogICBkdmJOaXVTdGF0aWNJcEVudHJ5IE9C SkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgRHZiTml1U3RhdGljSXBFbnRyeSAKICAgICAg IE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAK ICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJBIHJvdyBjYW4gb25seSBiZSBjcmVhdGVk IGlmIHRoZXJlIGlzIGEgY29ycmVzcG9uZGluZyByb3cgCiAgICAgICAgICAgIGluIGlmVGFibGUu ICBUaGUgSVAgYWRkcmVzcyB0byBiZSBhc3NpZ25lZCBtdXN0IGJlIHVuaXF1ZSAKICAgICAgICAg ICAgd2l0aGluIHRoZSBOSVUgZm9yIHRoZSBhZGRyZXNzIHR5cGUuICBUaGUgaW50ZXJmYWNlIGlz ICAKICAgICAgICAgICAgaWRlbnRpZmllZCBieSBpZkluZGV4LiAKICAgICAgICAgICAgRm9yIHRo ZSBIRkMgaW50ZXJmYWNlIHdoaWNoIGlzIGlkZW50aWZpZWQgYnkgMyBpbnRlcmZhY2VzLCAKICAg ICAgICAgICAgdGhlIGR2YlJjY01hY0xheWVyIEkvRiBzaGFsbCBiZSB1c2VkIHRvIGlkZW50aWZ5 IGl0LiAKICAgICAgICAgICAgUm93cyBhcmUgY3JlYXRlZC9kZWxldGUgdXNpbmcgZHZiTml1U3Rh dGljSXBTdGF0dXMuIiAKICAgICAgIElOREVYIHsgaWZJbmRleCwgZHZiTml1U3RhdGljSXBBZGRy VHlwZSwgZHZiTml1U3RhdGljSXBBZGRyIH0gCiAgIDo6PSB7IGR2Yk5pdVN0YXRpY0lwVGFibGUg MSB9IAogICAgCiAgIER2Yk5pdVN0YXRpY0lwRW50cnkgOjo9IFNFUVVFTkNFIHsgCiAgICAgICBk dmJOaXVTdGF0aWNJcEFkZHJUeXBlIEluZXRBZGRyZXNzVHlwZSwgIAogICAgICAgZHZiTml1U3Rh dGljSXBBZGRyICAgICBJbmV0QWRkcmVzcywgCiAgICAgICBkdmJOaXVTdGF0aWNJcE1hc2tUeXBl IEluZXRBZGRyZXNzVHlwZSwgCiAgICAgICBkdmJOaXVTdGF0aWNJcE1hc2sgICAgIEluZXRBZGRy ZXNzLCAKICAgICAgIGR2Yk5pdVN0YXRpY0lwU3RhdHVzICAgUm93U3RhdHVzIAogICB9IAogICAg CiAgIGR2Yk5pdVN0YXRpY0lwQWRkclR5cGUgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAg ICBJbmV0QWRkcmVzc1R5cGUgCiAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZSAKICAg ICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAi VGhlIHR5cGUgb2YgSVAgYWRkcmVzcyBhc3NpZ25lZCB0byB0aGUgaW50ZXJmYWNlLiIgCiAgClZh bGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAg ICAgICAgICAgMTQgDAogICAgICAgICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFj ZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAKICAgOjo9IHsgZHZiTml1U3RhdGljSXBF bnRyeSAxIH0gCiAgICAKICAgZHZiTml1U3RhdGljSXBBZGRyIE9CSkVDVC1UWVBFIAogICAgICAg U1lOVEFYICAgICAgSW5ldEFkZHJlc3MgKFNJWkUgKDEuLjY0KSkgCiAgICAgICBNQVgtQUNDRVNT ICBub3QtYWNjZXNzaWJsZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVND UklQVElPTiAKICAgICAgICAgICAiVGhlIElQIGFkZHJlc3MgYXNzaWduZWQgdG8gdGhlIGludGVy ZmFjZS4iIAogICA6Oj0geyBkdmJOaXVTdGF0aWNJcEVudHJ5IDIgfSAKICAgIAogICBkdmJOaXVT dGF0aWNJcE1hc2tUeXBlIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW5ldEFkZHJl c3NUeXBlIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgICAg ICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSB0eXBlIG9mIElQ IGFkZHJlc3MgZXhwcmVzc2VkIGJ5IHRoZSBtYXNrLiIgCiAgIDo6PSB7IGR2Yk5pdVN0YXRpY0lw RW50cnkgMyB9IAogICAgCiAgIGR2Yk5pdVN0YXRpY0lwTWFzayBPQkpFQ1QtVFlQRSAKICAgICAg IFNZTlRBWCAgICAgIEluZXRBZGRyZXNzIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUg CiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAg ICAgIlRoZSBJUCBzdWJuZXQgbWFzayBmb3IgdGhlIGludGVyZmFjZS4iIAogICA6Oj0geyBkdmJO aXVTdGF0aWNJcEVudHJ5IDQgfSAKICAgIAogICBkdmJOaXVTdGF0aWNJcFN0YXR1cyBPQkpFQ1Qt VFlQRSAKICAgICAgIFNZTlRBWCAgICAgIFJvd1N0YXR1cyAKICAgICAgIE1BWC1BQ0NFU1MgIHJl YWQtY3JlYXRlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9O IAogICAgICAgICAgICJUaGlzIGNvbnRyb2xzIGFuZCByZWZsZWN0cyB0aGUgc3RhdHVzIG9mIHRo ZSByb3cuIAogICAgICAgICAgICBSb3dzIGNhbiBiZSBjcmVhdGVkIGJ5IHVzaW5nIGJvdGggY3Jl YXRlQW5kR28gYW5kIAogICAgICAgICAgICBjcmVhdGVBbmRXYWl0LiAgUm93cyBjYW4gYmUgbW9k aWZpZWQvZGVsZXRlZCBPTkxZIGlmIHRoZSAgCiAgICAgICAgICAgIFNOTVAgc2V0IHJlcXVlc3Qg ZGVzdGluYXRpb24gSVAgYWRkcmVzcyBpcyBOT1QgYXNzaWduZWQgYnkgCiAgICAgICAgICAgIHRo ZSByb3cgYmVpbmcgbW9kaWZpZWQvZGVsZXRlZCB1bmxlc3MuIiAKICAgOjo9IHsgZHZiTml1U3Rh dGljSXBFbnRyeSA1IH0gCiAgICAKICAgIAogICAtLSBSZW1vdmVkIGFuZCBmdW5jdGlvbmFsaXR5 IHJlcGxhY2VkIGJ5IFJGQzI1NzMgCiAgIC0tIGR2Yk5pdU5tQWNjZXNzVGFibGUgT0JKRUNULVRZ UEUgCiAgIC0tICAgIFNZTlRBWCAgICAgIFNFUVVFTkNFIE9GIER2Yk5pdU5tQWNjZXNzRW50cnkg CiAgIC0tICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUgCiAgIC0tICAgIFNUQVRVUyAgICAg IGN1cnJlbnQgCiAgIC0tICAgIERFU0NSSVBUSU9OIAogICAtLSAgICAgICAgIlRoaXMgdGFibGUg Y29udHJvbHMgYWNjZXNzIHRvIFNOTVAgb2JqZWN0cyBieSBuZXR3b3JrIAogICAtLSAgICAgICAg IG1hbmFnZW1lbnQgc3RhdGlvbnMuIElmIHRoZSB0YWJsZSBpcyBlbXB0eSwgYWNjZXNzIAogICAt LSAgICAgICAgIHRvIFNOTVAgb2JqZWN0cyBpcyB1bnJlc3RyaWN0ZWQuICBUaGlzIHRhYmxlIGV4 aXN0cyBvbmx5IAogICAtLSAgICAgICAgIG9uIFNOTVB2MSBvciB2MmMgYWdlbnRzIGFuZCBkb2Vz IG5vdCBleGlzdCBvbiBTTk1QdjMgCiAgIC0tICAgICAgICAgYWdlbnRzLiBTZWUgdGhlIGNvbmZv cm1hbmNlIHNlY3Rpb24gZm9yIGRldGFpbHMuIAogICAtLSAgICAgICAgIFNwZWNpZmljYWxseSwg Zm9yIHYzIGFnZW50cywgdGhlIGFwcHJvcHJpYXRlIE1JQnMgYW5kIAogICAtLSAgICAgICAgIHNl Y3VyaXR5IG1vZGVscyBhcHBseSBpbiBsaWV1IG9mIHRoaXMgdGFibGUuIAogICAtLSAgICAgICAg IEFuIGVtcHR5IHRhYmxlIHdpbGwgT05MWSBhbGxvdyBuZXR3b3JrIG1hbmFnZW1lbnQgYWNjZXNz IAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIw MDAgICAgICAgICAgICAgIDE1IAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJ bnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgIC0tICAgICAgICAgZnJv bSB0aGUgSEZDIG5ldHdvcmssIGFueSBJUCBhZGRyZXNzIGlzIGFjY2VwdGVkLiAKICAgLS0gICAg ICAgICBTaW11bHRhbmVvdXMgd3JpdGUgYWNjZXNzIHRvIHRoaXMgTUlCIGlzIG5vdCByZWNvbW1l bmRlZCIgCiAgIC0tIDo9IHsgZHZiTml1U3lzdGVtIDkgfSAKIAogICAgCiAgIGR2Yk5pdUNvbmZp Z1NldCBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIElOVEVHRVIgeyAKICAgICAgICAg ICAgICAgICAgICAgICBzdG9yZUNvbmZpZygxKSwgCiAgICAgICAgICAgICAgICAgICAgICAgcmVh ZENvbmZpZygyKSwgCiAgICAgICAgICAgICAgICAgICAgICAgc2V0RmFjdG9yeSgzKSwgCiAgICAg ICAgICAgICAgICAgICAgICAgbG9jYWwoNCksIAogICAgICAgICAgICAgICAgICAgICAgIGxvY2Fs VW5zYXZlZCg1KSwgCiAgICAgICAgICAgICAgICAgICAgICAgbG9jYWxTYXZlZCg2KSwgCiAgICAg ICAgICAgICAgICAgICAgICAgZmFjdG9yeURlZmF1bHQoNykgCiAgICAgICAgICAgICAgICAgICB9 IAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJl bnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyBvYmplY3QgaXMgdXNlZCB0 byBtYW5hZ2UgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIAogICAgICAgICAgICBOSVUuICBUaGUg Zm9sbG93aW5nIGNhbiBiZSB1c2VkIHRvIHNldCB0aGUgb2JqZWN0LiAKICAgIAogICAgICAgICAg ICBzdG9yZUNvbmZpZyAtIHN0b3JlcyB0aGUgY3VycmVudCBjb25maWd1cmF0aW9uIHRvIG5vbiAK ICAgICAgICAgICAgICAgICAgICAgICAgICB2b2xhdGlsZSBzdG9yYWdlLiAgVGhpcyBhY3Rpb24g Y2hhbmdlcyAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbiBzdGF0dXMg dG8gbG9jYWxTYXZlZCAKICAgICAgICAgICAgcmVhZENvbmZpZyAgLSByZXRyaWV2ZXMgdGhlIGNv bmZpZ3VyYXRpb24gaGVsZCBpbiBub24gCiAgICAgICAgICAgICAgICAgICAgICAgICAgdm9sYXRp bGUgc3RvcmFnZS4gIFRoaXMgYWN0aW9uIGNoYW5nZXMgIAogICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbmZpZ3VyYXRpb24gc3RhdHVzIHRvIGxvY2FsIAogICAgICAgICAgICBzZXRGYWN0b3J5 ICAtIHNldHMgdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbiB0byBmYWN0b3J5IAogICAgICAgICAg ICAgICAgICAgICAgICAgIGRlZmF1bHQuICBUaGlzIGV4Y2x1ZGVzIHN0YXRpYyBhc3NpZ25lZCBJ UCAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgYWRkcmVzc2VzLiAgVGhpcyBhY3Rpb24gY2hh bmdlcyBjb25maWd1cmF0aW9uIAogICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXR1cyB0byBm YWN0b3J5RGVmYXVsdCAKICAgICAgICAgICAgIAogICAgICAgICAgICBXaGVuIHRoZSBvYmplY3Qg aXMgcmVhZCBpdCByZXBvcnRzIHRoZSBjb25maWd1cmF0aW9uIGJlaW5nIAogICAgICAgICAgICB1 c2VkLiAgCiAgICAgICAKICAgICAgICAgICAgbG9jYWwgICAgICAgICAgLSB0aGUgY29uZmlndXJh dGlvbiBpcyB1bmNoYW5nZWQgc2luY2UgYmVpbmcgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgcmV0cmlldmVkIGZyb20gbm9uIHZvbGF0aWxlIHN0b3JhZ2UuIFdoZW4gIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNoYW5nZWQgaXQgYmVjb21lcyBsb2NhbFVuc2F2ZWQgCiAgICAg ICAgICAgIGxvY2FsVW5zYXZlZCAgIC0gdGhlIGNvbmZpZ3VyYXRpb24gaGFzIGNoYW5nZWQgYW5k IHJlcXVpcmVzIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0b3JpbmcuICBXaGVuIHN0 b3JlZCBpdCBiZWNvbWVzICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2NhbFNhdmVk IAogICAgICAgICAgICBsb2NhbFNhdmVkICAgICAtIHRoZSBjdXJyZW50IGNvbmZpZ3VyYXRpb24g aGFzIGJlZW4gc2F2ZWQgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2luY2UgYmVpbmcg cmV0cmlldmVkIGZyb20gbm9uIHZvbGF0aWxlICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzdG9yYWdlIAogICAgICAgICAgICBmYWN0b3J5RGVmYXVsdCAtIHRoZSBjdXJyZW50IGNvbmZp Z3VyYXRpb24gaXMgdGhlIGZhY3RvcnkgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVm YXVsdCBhbmQgcmVxdWlyZXMgc2F2aW5nLiAgT25jZSBzYXZlZCAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpdCBiZWNvbWVzIGxvY2FsU2F2ZWQuIElmIG1vZGlmaWVkIGl0IAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGJlY29tZXMgbG9jYWxVbnNhdmVkIiAKICAgOjo9IHsgZHZi Tml1U3lzdGVtIDEwIH0gCiAgICAKICAgZHZiTml1RXVyb2xvYWRlciBPQkpFQ1QtVFlQRSAKICAg ICAgIFNZTlRBWCAgICAgIElOVEVHRVIgeyAKICAgICAgICAgICAgICAgICAgICAgICBlbmFibGVk KDEpLCAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJl ciAyMDAwICAgICAgICAgICAgICAxNiAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdv cmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgICAgICAg ICAgICAgICAgIGRpc2FibGVkKDIpIAogICAgICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVND UklQVElPTiAKICAgICAgICAgICAiRW5hYmxlcyBhbmQgZGlzYWJsZXMgdGhlIEV1cm9Mb2FkZXIu IiAKICAgOjo9IHsgZHZiTml1U3lzdGVtIDExIH0gCiAgICAKICAgZHZiTml1SW1wbFNldCBPQkpF Q1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIEJJVFMgeyAKICAgICAgICAgICAgICAgICAgICAg ICBkaGNwKDApLCAKICAgICAgICAgICAgICAgICAgICAgICBpcEZpbHRlcnMoMSksIAogICAgICAg ICAgICAgICAgICAgICAgIGV0aEZpbHRlcnMoMiksIAogICAgICAgICAgICAgICAgICAgICAgIGFk ZHJUcmFuc05hdCgzKSwgCiAgICAgICAgICAgICAgICAgICAgICAgYWRkclRyYW5zTmFwdCg0KSwg CiAgICAgICAgICAgICAgICAgICAgICAgY3BlSXBDb250cm9sKDUpIAogICAgICAgICAgICAgICAg ICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seSAKICAgICAgIFNUQVRVUyAgICAgIGN1 cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyBvYmplY3Qgd2hlbiBy ZWFkIGlkZW50aWZpZXMgd2hpY2ggb3B0aW9uYWwgZ3JvdXBzIGhhdmUgCiAgICAgICAgICAgIGJl ZW4gaW1wbGVtZW50ZWQuICBJbXBsZW1lbnRlZCBncm91cHMgaGF2ZSB0aGVpciBiaXQgc2V0LiAK ICAgICAgICAgICAgVGhlIGJpdHMgcmVwcmVzZW50IHRoZSBmb2xsb3dpbmc6IAogICAgICAgICAg ICAgIGRoY3AgICAgICAgICAgLSBkdmJOaXVEaGNwIGdyb3VwIAogICAgICAgICAgICAgIGlwRmls dGVycyAgICAgLSBkdmJOaXVJcEZpbHRlciBncm91cCAKICAgICAgICAgICAgICBldGhGaWx0ZXJz ICAgIC0gZHZiTml1RXRoRmlsZXRlciBncm91cCAKICAgICAgICAgICAgICBhZGRyVHJhbnNOYXQg IC0gZHZiTml1TmF0IGdyb3VwIAogICAgICAgICAgICAgIGFkZHJUcmFuc05hcHQgLSBkdmJOaXVO YXB0IGdyb3VwIAogICAgICAgICAgICAgIGNwZUlwQ29udHJvbCAgLSBkdmJOaXVDcGUgZ3JvdXAi IAogICA6Oj0geyBkdmJOaXVTeXN0ZW0gMTIgfSAKICAgIAogICBkdmJOaXVNdWx0aWNhc3QgT0JK RUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJTlRFR0VSIHsgCiAgICAgICAgICAgICAgICAg ICAgICAgZGlzYWJsZWQoMSksIAogICAgICAgICAgICAgICAgICAgICAgIGRvd25zdHJlYW1Pbmx5 KDIpLCAKICAgICAgICAgICAgICAgICAgICAgICB1cHN0cmVhbU9ubHkoMyksIAogICAgICAgICAg ICAgICAgICAgICAgIGVuYWJsZWQoNCkgCiAgICAgICAgICAgICAgICAgICB9IAogICAgICAgTUFY LUFDQ0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBE RVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyBvYmplY3QgaXMgdXNlZCB0byByZXN0cmljdCB0 aGUgbGV2ZWwgb2YgbXVsdGljYXN0IAogICAgICAgICAgICBzdXBwb3J0IHByb3ZpZGVkIGJ5IHRo ZSBOSVUuICAgCiAgICAgICAgICAgICAgZGlzYWJsZWQgLSBObyBJR01QIG9yIG11bHRpY2FzdCBw YWNrZXRzIGFyZSBmb3J3YXJkZWQgCiAgICAgICAgICAgICAgICAgICAgICAgICB0aHJvdWdoIHRo ZSBOSVUgaW4gZWl0aGVyIGRpcmVjdGlvbi4gIAogICAgICAgICAgICAgIGRvd25zdHJlYW1Pbmx5 IC0gT25seSBtdWx0aWNhc3QgcGFja2V0cyBpbiB0aGUgZG93bnN0cmVhbSAKICAgICAgICAgICAg ICAgICAgICAgICAgIGRpcmVjdGlvbiB3aWxsIGJlIGZvcndhcmRlZCBmb3IgdGhlIGdyb3VwIHRv IAogICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggdGhlIHN1YnNjcmliZXIgaGFzIG1lbWJl cnNoaXAuICBJR01QICAKICAgICAgICAgICAgICAgICAgICAgICAgIG1lc3NhZ2VzIGFyZSBhbGxv d2VkIHRvIG1hbmFnZSBncm91cCAgCiAgICAgICAgICAgICAgICAgICAgICAgICBtZW1iZXJzaGlw IGZvciBkb3duc3RyZWFtIGdyb3VwcyBvbmx5LiAgQW55IAogICAgICAgICAgICAgICAgICAgICAg ICAgdXBzdHJlYW0gbXVsdGljYXN0IHBhY2tldHMgYXJlIGRpc2NhcmRlZC4gCiAgICAgICAgICAg ICAgdXBzdHJlYW1Pbmx5IC0gIE9ubHkgbXVsdGljYXN0IHBhY2tldHMgaW4gdGhlIHVwc3RyZWFt ICAKICAgICAgICAgICAgICAgICAgICAgICAgIGRpcmVjdGlvbiB3aWxsIGJlIGZvcndhcmRlZCBi eSB0aGUgTklVLiBJR01QICAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBp cmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAgICAxNyAMCiAgICAgICAgICAgICAgICAgRFZC IENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAog ICAgICAgICAgICAgICAgICAgICAgICAgbWVzc2FnZXMgYXJlIGFsbG93ZWQgdG8gbWFuYWdlIGdy b3VwICAKICAgICAgICAgICAgICAgICAgICAgICAgIG1lbWJlcnNoaXAgZm9yIHVwc3RyZWFtIGdy b3VwcyBvbmx5LiAKICAgICAgICAgICAgICBlbmFibGVkIC0gIE11bHRpY2FzdCBmb3J3YXJkaW5n IGluIHRoZSBkb3duc3RyZWFtIGFuZCAgCiAgICAgICAgICAgICAgICAgICAgICAgICB1cHN0cmVh bSBkaXJlY3Rpb24gaXMgYWxsb3dlZC4gIElHTVAgIAogICAgICAgICAgICAgICAgICAgICAgICAg bWVzc2FnZXMgYXJlIGFsbG93ZWQgdG8gbWFuYWdlIGdyb3VwICAKICAgICAgICAgICAgICAgICAg ICAgICAgIG1lbWJlcnNoaXAgZm9yIGJvdGggdXBzdHJlYW0gYW5kIGRvd25zdHJlYW0gIAogICAg ICAgICAgICAgICAgICAgICAgICAgbXVsdGljYXN0IGdyb3Vwcy4iIAogICA6Oj0geyBkdmJOaXVT eXN0ZW0gMTMgfSAKICAgIAogICAgCiAgIC0tID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSAKICAgLS0gPSAgU29mdHdhcmUgR3Jv dXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IAogICAtLSA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0gCiAgICAKICAgLS0gU29mdHdhcmUgdmVyc2lvbiB0YWJsZSAKICAgIAogICBkdmJOaXVT d1ZlclRhYmxlIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgU0VRVUVOQ0UgT0YgRHZi Tml1U3dWZXJFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAg U1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGlz IHRhYmxlIGlzIHVzZWQgdG8gY2hlY2sgdGhlIHZlcnNpb25zIG9mIHNvZnR3YXJlIHN0b3JlZCAK ICAgICAgICAgICAgaW4gdGhlIE5JVS4gIEl0IGlzIGFsc28gdXNlZCB0byBjb25maWd1cmUgd2hp Y2gvd2hlbiAgCiAgICAgICAgICAgIHZlcnNpb25zIG9mIHNvZnR3YXJlIGlzIGV4ZWN1dGVkLiIg CiAgIDo6PSB7IGR2Yk5pdVNvZnR3YXJlIDEgfSAKICAgIAogICBkdmJOaXVTd1ZlckVudHJ5IE9C SkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgRHZiTml1U3dWZXJFbnRyeSAKICAgICAgIE1B WC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAg ICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGVyZSB3aWxsIGJlIGEgcm93IGZvciBldmVy eSBzdG9yYWdlIHNsb3Qgd2l0aGluIHRoZSAKICAgICAgICAgICAgTklVLiAgQSBzbG90IGlzIGEg bG9jYXRpb24gd2hlcmUgYSBmdWxsIHNvZnR3YXJlIGltYWdlIAogICAgICAgICAgICBjYW4gYmUg c3RvcmVkLiAgU2xvdCAwLCBpcyByZXNlcnZlZCBmb3IgUkFNLiIgCiAgICAgICBJTkRFWCB7IGR2 Yk5pdVN3U2xvdCB9IAogICA6Oj0geyBkdmJOaXVTd1ZlclRhYmxlIDEgfSAKICAgIAogICBEdmJO aXVTd1ZlckVudHJ5IDo6PSBTRVFVRU5DRSB7IAogICAgICAgZHZiTml1U3dTbG90ICAgICAgSW50 ZWdlcjMyLCAKICAgICAgIGR2Yk5pdVN3VmVyc2lvbiAgIFNubXBBZG1pblN0cmluZywgCiAgICAg ICBkdmJOaXVTd1N0YXRlICAgICBJTlRFR0VSLCAKICAgICAgIGR2Yk5pdVN3QWN0aW9uICAgIElO VEVHRVIsIAogICAgICAgZHZiTml1U3dEYXRlVGltZSAgRGF0ZUFuZFRpbWUgCiAgIH0gCiAgICAK ICAgIAogICBkdmJOaXVTd1Nsb3QgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggSW50ZWdlcjMy ICgxLi4xMDApIAogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFU VVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSBzbG90 IG51bWJlciB0aGUgc29mdHdhcmUgaW1hZ2UgaXMgaGVsZCBpbi4gU2xvdCAwIGlzIAogICAgICAg ICAgICByZXNlcnZlZCBmb3IgUkFNLCBpdCBpcyB1c2VkIHRvIGlkZW50aWZ5IGFuIGltYWdlIGRp cmVjdGx5IAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVt YmVyIDIwMDAgICAgICAgICAgICAgIDE4IAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0 d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgICAgICAgICAg IGxvYWRlZCBpbnRvIFJBTSBlLmcuIGZvciBkZWJ1ZyBwdXJwb3Nlcy4gVGhlIHNsb3RzIHNob3Vs ZCAKICAgICAgICAgICAgYmUgY29uc2VjdXRpdmVseSBudW1iZXJlZCBzdGFydGluZyBmcm9tIDEu IiAKICAgOjo9IHsgZHZiTml1U3dWZXJFbnRyeSAxIH0gCiAgICAKICAgZHZiTml1U3dWZXJzaW9u IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgU25tcEFkbWluU3RyaW5nIAogICAgICAg TUFYLUFDQ0VTUyAgcmVhZC1vbmx5IAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAg IERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgdmVyc2lvbiBvZiB0aGUgc29mdHdhcmUgbG9j YXRlZCBpbiB0aGUgc2xvdC4gVGhpcyBpcyAKICAgICAgICAgICAgYSBtYW51ZmFjdHVyZXIgZGVw ZW5kYW50IHN0cmluZy4iIAogICA6Oj0geyBkdmJOaXVTd1ZlckVudHJ5IDIgfSAKICAgIAogICBk dmJOaXVTd1N0YXRlIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSU5URUdFUiB7IAog ICAgICAgICAgICAgICAgICAgICAgIGV4ZWN1dGluZygxKSwgCiAgICAgICAgICAgICAgICAgICAg ICAgZmFpbGVkKDIpLCAKICAgICAgICAgICAgICAgICAgICAgICBub25lKDMpIAogICAgICAgICAg ICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seSAKICAgICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlIGV4ZWN1dGlv biBzdGF0ZSBvZiB0aGUgc29mdHdhcmUgaW4gdGhlIHNsb3QuICBJZiB0aGUgICAgICAKICAgICAg ICAgICAgcy93IGlzIGN1cnJlbnRseSBleGVjdXRpbmcgdGhlIHN0YXRlIHdpbGwgYmUgZXhlY3V0 aW5nKDEpLiAgCiAgICAgICAgICAgIElmIHRoZSBzL3cgdHJpZWQgdG8gZXhlY3V0ZSBidXQgZmFp bGVkIGl0IHdpbGwgYmUgIAogICAgICAgICAgICBmYWlsZWQoMikuIElmIHRoZSBzL3cgaXMgbm90 IGluIHVzZSB0aGVuIGl0IHdpbGwgYmUgIAogICAgICAgICAgICBub25lKDMpLiIgCiAgIDo6PSB7 IGR2Yk5pdVN3VmVyRW50cnkgMyB9IAogICAgCiAgIGR2Yk5pdVN3QWN0aW9uIE9CSkVDVC1UWVBF IAogICAgICAgU1lOVEFYICAgICAgSU5URUdFUiB7IAogICAgICAgICAgICAgICAgICAgICAgIGJv b3QoMSksIAogICAgICAgICAgICAgICAgICAgICAgIGJhY2t1cCgyKSwgCiAgICAgICAgICAgICAg ICAgICAgICAgbm9uZSgzKSwgCiAgICAgICAgICAgICAgICAgICAgICAgZW1wdHlTbG90KDQpIAog ICAgICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUgCiAgICAg ICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIldo ZW4gdGhlIE5JVSBpcyBpbml0aWFsaXNpbmcsIHRoaXMgaWRlbnRpZmllcyB3aGljaCBzL3cgCiAg ICAgICAgICAgIGltYWdlIHNob3VsZCBiZSB1c2VkLiAgIAogICAgICAgIAogICAgICAgICAgICAg ICAgYm9vdCAgIC0gaWRlbnRpZmllcyB0aGF0IHRoaXMgcy93IHNob3VsZCBiZSB1c2VkIGF0IAog ICAgICAgICAgICAgICAgICAgICAgICAgaW5pdGlhbGlzYXRpb24uICBUaGVyZSBtdXN0IGJlIG9u ZSBzL3cgdmVyc2lvbiAKICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggdGhpcyBhY3Rpb24g YW5kIHRoZXJlIG11c3QgYmUgb25seSBvbmUuIAogICAgICAgICAgICAgICAgYmFja3VwIC0gaXMg dXNlZCB0byBpZGVudGlmeSBhIHMvdyB2ZXJzaW9uIHRvIHVzZSBpbiAKICAgICAgICAgICAgICAg ICAgICAgICAgIHRoZSBldmVudCB0aGF0IHRoZSBib290IHZlcnNpb24gZmFpbHMuIAogICAgICAg ICAgICAgICAgICAgICAgICAgTXVsdGlwbGUgcy93IHZlcnNpb25zIG1heSBoYXZlIHRoaXMgYWN0 aW9uLiAKICAgICAgICAgICAgICAgICAgICAgICAgIEluIHRoaXMgY2FzZSB0aGV5IHdpbGwgYmUg dHJpZWQgaW4gc2xvdCBvcmRlci4gCiAgICAgICAgICAgICAgICBub25lICAgLSBpcyB1c2VkIHRv IGlkZW50aWZ5IGEgcy93IHZlcnNpb24gdGhhdCBpcyBub3QgIAogICAgICAgICAgICAgICAgICAg ICAgICAgdXNlZCBhdCBpbml0aWFsaXNhdGlvbi4gCiAgICAgICAgICAgICAgICBlbXB0eVNsb3Qg LSBpZGVudGlmaWVzIHRoZSBzbG90IGFzIGNvbnRhaW5pbmcgbm8gcy93LiAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgIElmIHRoaXMgaXMgYXBwbGllZCB0byBhIHNsb3QgdGhhdCBjdXJyZW50 bHkgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIg MjAwMCAgICAgICAgICAgICAgMTkgDAogICAgICAgICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3Jr IEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGNvbnRhaW5zIGEgcy93IGltYWdlIHRoZSBpbWFnZSB3aWxsIGJlICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGVyYXNlZCBhbmQgbm90IGlkZW50aWZpZWQgaW4gdGhl IHNsb3QuIiAKICAgOjo9IHsgZHZiTml1U3dWZXJFbnRyeSA0IH0gCiAgICAKICAgZHZiTml1U3dE YXRlVGltZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIERhdGVBbmRUaW1lIAogICAg ICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5IAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAg ICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgZGF0ZSBhbmQgdGltZSB0aGUgaW1hZ2Ug d2FzIGRvd25sb2FkZWQgdG8gdGhlIHNsb3QuIiAKICAgOjo9IHsgZHZiTml1U3dWZXJFbnRyeSA1 IH0gCiAgICAKICAgLS0gRW5kIG9mIHNvZnR3YXJlIHZlcnNpb24gdGFibGUgCiAgICAKICAgZHZi Tml1U3dTZXJ2ZXJBZGRyVHlwZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIEluZXRB ZGRyZXNzVHlwZSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUgCiAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSB0eXBlIG9m IGFkZHJlc3MgdXNlZCBmb3IgdGhlIFRGVFAgc2VydmVyLiIgCiAgIDo6PSB7IGR2Yk5pdVNvZnR3 YXJlIDIgfSAKICAgIAogICBkdmJOaXVTd1NlcnZlciBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRB WCAgICAgIEluZXRBZGRyZXNzIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZSAKICAgICAg IFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhp cyBpcyB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgVEZUUCBzZXJ2ZXIgdXNlZCBmb3Igcy93IAogICAg ICAgICAgICB1cGRhdGVzIiAKICAgOjo9IHsgZHZiTml1U29mdHdhcmUgMyB9IAogICAgCiAgIGR2 Yk5pdVN3RmlsZW5hbWUgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBPQ1RFVCBTVFJJ TkcgKFNJWkUoMC4uNTAwKSkgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLXdyaXRlIAogICAgICAg U1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGlz IGlzIHRoZSBmaWxlbmFtZSBpbmNsdWRpbmcgdGhlIHBhdGggZm9yIHRoZSBzb2Z0d2FyZSAKICAg ICAgICAgICAgaW1hZ2UgdGhhdCBpcyB0byBiZSBkb3dubG9hZGVkLiIgCiAgIDo6PSB7IGR2Yk5p dVNvZnR3YXJlIDQgfSAKICAgIAogICBkdmJOaXVTd0Rvd25sb2FkU2xvdCBPQkpFQ1QtVFlQRSAK ICAgICAgIFNZTlRBWCAgICAgIEludGVnZXIzMiAoMC4uMTAwKSAKICAgICAgIE1BWC1BQ0NFU1Mg IHJlYWQtd3JpdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJ T04gCiAgICAgICAgICAgIlRoaXMgaWRlbnRpZmllcyB0aGUgaW1hZ2Ugc2xvdCB3aGljaCB0aGUg c29mdHdhcmUgaXMgdG8gYmUgCiAgICAgICAgICAgIGRvd25sb2FkZWQgaW50by4gIFRoZSBvcGVy YXRvciBjYW4gbWFudWFsbHkgc2VsZWN0IHRoZSBzbG90ICAKICAgICAgICAgICAgdG8gZG93bmxv YWQgaW50by4gU2xvdCAwIGlzIGEgc3BlY2lhbCBjYXNlIHdoaWNoIGlzIHVzZWQgdG8gCiAgICAg ICAgICAgIGlkZW50aWZ5IGEgZGlyZWN0IHRvIFJBTSBkb3dubG9hZCwgd2hpY2ggc2hvdWxkIG9u bHkgYmUgIAogICAgICAgICAgICB1c2VkIGZvciBkaWFnbm9zdGljIHB1cnBvc2VzLiAgQnkgZGVm YXVsdCB0aGlzIG9iamVjdCB3aWxsICAKICAgICAgICAgICAgcG9pbnQgdG8gdGhlIGZpcnN0IGVt cHR5IHNsb3QuICBJZiB0aGVyZSBhcmUgbm8gZW1wdHkgc2xvdHMgIAogICAgICAgICAgICBpdCB3 aWxsIHBvaW50IHRvIHRoZSBmaXJzdCBiYWNrdXAgaW1hZ2UuIiAKICAgOjo9IHsgZHZiTml1U29m dHdhcmUgNSB9IAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2Vw dGVtYmVyIDIwMDAgICAgICAgICAgICAgIDIwIAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUg TmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgICAKICAg ZHZiTml1U3dBZG1pblN0YXR1cyBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIElOVEVH RVIgeyAKICAgICAgICAgICAgICAgICAgICAgICBpbml0VXBncmQoMSksIAogICAgICAgICAgICAg ICAgICAgICAgIGNvbnRhY3RpbmdURlRQU2VydmVyKDIpLCAKICAgICAgICAgICAgICAgICAgICAg ICBkb3dubG9hZEluUHJvZ3Jlc3MoMyksIAogICAgICAgICAgICAgICAgICAgICAgIGZhaWx1cmVU RlRQKDQpLCAKICAgICAgICAgICAgICAgICAgICAgICBiYWRJbWFnZSg1KSwgCiAgICAgICAgICAg ICAgICAgICAgICAgYmFkSGFyZHdhcmUoNiksIAogICAgICAgICAgICAgICAgICAgICAgIGRvd25s b2FkU3VjY2Vzc2Z1bCg3KSwgCiAgICAgICAgICAgICAgICAgICAgICAgaWRsZSg4KSAKICAgICAg ICAgICAgICAgICAgIH0gCiAgICAgICBNQVgtQUNDRVNTICByZWFkLXdyaXRlIAogICAgICAgU1RB VFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGlzIHdp bGwgYWRtaW5pc3RlciB0aGUgc29mdHdhcmUgdXBncmFkZSBhbmQgIAogICAgICAgICAgICBwcm92 aWRlIHN0YXR1cyBvZiBpdHMgcHJvZ3Jlc3MuIAogICAgCiAgICAgICAgICAgIEluaXRpYXRlVXBn cmFkZSAgICAgIC0gVGhpcyBpcyB0aGUgb25seSBhZG1pbiBzZWxlY3RhYmxlICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB2YWx1ZSBhbmQgaW5pdGlhdGVzIHRoZSB1cGdyYWRl IAogICAgICAgICAgICBDb250YWN0aW5nVEZUUFNlcnZlciAtIFRoZSBURlRQIHNlcnZlciBpcyBi ZWluZyBjb250YWN0ZWQgCiAgICAgICAgICAgIERvd25sb2FkSW5Qcm9ncmVzcyAgIC0gVGhlIGlt YWdlIGlzIGN1cnJlbnRseSBiZWluZyAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZG93bmxvYWRlZCB0byB0aGUgTml1IAogICAgICAgICAgICBURlRQRmFpbHVyZSAgICAgICAg ICAtIFRoZXJlIHdhcyBhIGZhaWx1cmUgYXQgdGhlIFRGVFAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGxheWVyIHdoaWxlIGRvd25sb2FkaW5nIAogICAgICAgICAgICBCYWRJ bWFnZSAgICAgICAgICAgICAtIFRoZSBkb3dubG9hZGVkIHNvZnR3YXJlIGltYWdlIGZhaWxlZCAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbiBpbnRlZ3JpdHkgY2hlY2sgCiAg ICAgICAgICAgIEJhZEhhcmR3YXJlICAgICAgICAgIC0gVGhlIGRvd25sb2FkZWQgc29mdHdhcmUg aW1hZ2UgaXMgbm90IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1aXRhYmxl IGZvciB0aGUgSC9XIHBsYXRmb3JtIAogICAgICAgICAgICBEb3dubG9hZFN1Y2Nlc3NmdWwgICAt IFRoZSBkb3dubG9hZGVkIHNvZnR3YXJlIGltYWdlIGhhcyAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYmVlbiBzdWNjZXNzZnVsIAogICAgICAgICAgICBJZGxlICAgICAgICAg ICAgICAgICAtIE5vIGF0dGVtcHQgdG8gZG93bmxvYWQgc29mdHdhcmUgaGFzICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBiZWVuIG1hZGUgc2luY2UgdGhlIGxhc3QgcmVzZXQi IAogICA6Oj0geyBkdmJOaXVTb2Z0d2FyZSA2IH0gCiAgICAKICAgLS0gPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IAogICAtLSA9 ICBESENQIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgID0gCiAgIC0tID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PSAKICAgIAogICBkdmJOaXVEaGNwVGFibGUgT0JKRUNULVRZUEUg CiAgICAgICBTWU5UQVggICAgICBTRVFVRU5DRSBPRiBEdmJOaXVEaGNwRW50cnkgCiAgICAgICBN QVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAg ICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyB0YWJsZSBpcyB1c2VkIHRvIG1hbmFn ZSB0aGUgREhDUC9CT09UUCBmdW5jdGlvbmFsaXR5IAogICAgICAgICAgICBvbiBhIHBlciBpbnRl cmZhY2UgYmFzaXMuICBBbGwgREhDUC9CT09UUCByZXF1ZXN0cyB3aWxsIAogICAgICAgICAgICBi ZSB2aWEgdGhlIEhGQyBpbnRlcmZhY2UuIiAKICAgOjo9IHsgZHZiTml1RGhjcCAxIH0gCiAgICAK ICAgZHZiTml1RGhjcEVudHJ5IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgRHZiTml1 RGhjcEVudHJ5IAogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFU VVMgICAgICBjdXJyZW50IAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGly ZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDIxIAwKICAgICAgICAgICAgICAgICBEVkIg Q2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAg ICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlcmUgd2lsbCBiZSBhIHJvdyBmb3IgZXZl cnkgaW50ZXJmYWNlIHdpdGhpbiB0aGUgCiAgICAgICAgICAgIGVxdWlwbWVudC4gCiAgICAgICAg ICAgIEZvciB0aGUgSEZDIGludGVyZmFjZSB3aGljaCBpcyBpZGVudGlmaWVkIGJ5IDMgaW50ZXJm YWNlcywgCiAgICAgICAgICAgIHRoZSBkdmJSY2NNYWNMYXllciBJL0Ygc2hhbGwgYmUgdXNlZCB0 byBpZGVudGlmeSBpdC4gCiAgICAgICAgICAgIEZvciBhbiBpbnRlcmZhY2UgaXQgaXMgcG9zc2li bGUgdG8gc3BlY2lmeSB0aGUgREhDUC9CT09UUCAgCiAgICAgICAgICAgIHNlcnZlciB0byBiZSB1 c2VkIHRvIG9idGFpbiBhbiBJUCBhZGRyZXNzIGZvciB0aGUgaW50ZXJmYWNlIAogICAgICAgICAg ICBhbmQgYW55IERIQ1AvQk9PVFAgcmVxdWVzdHMgcmVjZWl2ZWQgb24gdGhhdCBpbnRlcmZhY2Ug dGhhdCAKICAgICAgICAgICAgcmVxdWlyZSByZWxheWluZy4gIEJhY2t1cCBESENQL0JPT1RQIHNl cnZlcnMgY2FuIGJlICAKICAgICAgICAgICAgc3BlY2lmaWVkIGZvciBlYWNoIGludGVyZmFjZS4i IAogICAgICAgSU5ERVggeyBpZkluZGV4LCBkdmJOaXVEaGNwSW5kZXggfSAKICAgOjo9IHsgZHZi Tml1RGhjcFRhYmxlIDEgfSAKICAgIAogICBEdmJOaXVEaGNwRW50cnkgOjo9IFNFUVVFTkNFIHsg CiAgICAgICBkdmJOaXVEaGNwSW5kZXggICAgICAgICAgIFVuc2lnbmVkMzIsIAogICAgICAgZHZi Tml1RGhjcFNlcnZlckFkZHJUeXBlICBJbmV0QWRkcmVzc1R5cGUsIAogICAgICAgZHZiTml1RGhj cFNlcnZlciAgICAgICAgICBJbmV0QWRkcmVzcywgCiAgICAgICBkdmJOaXVEaGNwUmVsYXkgICAg ICAgICAgIElOVEVHRVIsIAogICAgICAgZHZiTml1RGhjcFJlcUlmICAgICAgICAgICBJTlRFR0VS LCAKICAgICAgIGR2Yk5pdURoY3BTZXJUeXBlICAgICAgICAgSU5URUdFUiwgCiAgICAgICBkdmJO aXVEaGNwU3RhdGUgICAgICAgICAgIElOVEVHRVIsIAogICAgICAgZHZiTml1RGhjcFN0YXR1cyAg ICAgICAgICBSb3dTdGF0dXMgCiAgIH0gCiAgICAKICAgZHZiTml1RGhjcEluZGV4IE9CSkVDVC1U WVBFIAogICAgICAgU1lOVEFYICAgICAgVW5zaWduZWQzMiAKICAgICAgIE1BWC1BQ0NFU1MgIG5v dC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBU SU9OIAogICAgICAgICAgICJJbmRleCB1c2VkIHRvIG9yZGVyIHRoZSBhcHBsaWNhdGlvbiBvZiBi YWNrdXAgCiAgICAgICAgICAgIGVudHJpZXMuIiAKICAgOjo9IHsgZHZiTml1RGhjcEVudHJ5IDEg fSAKICAgIAogICBkdmJOaXVEaGNwU2VydmVyQWRkclR5cGUgT0JKRUNULVRZUEUgCiAgICAgICBT WU5UQVggICAgICBJbmV0QWRkcmVzc1R5cGUgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0 ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAg ICAgICAiVGhlIHR5cGUgb2YgSVAgYWRkcmVzcyBmb3IgdGhlIERIQ1Agc2VydmVyLiIgCiAgIDo6 PSB7IGR2Yk5pdURoY3BFbnRyeSAyIH0gCiAgICAKICAgIAogICBkdmJOaXVEaGNwU2VydmVyIE9C SkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW5ldEFkZHJlc3MgCiAgICAgICBNQVgtQUND RVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVND UklQVElPTiAKICAgICAgICAgICAiVGhlIElQIGFkZHJlc3Mgb2YgdGhlIERIQ1AgLyBCT09UUCBz ZXJ2ZXIgdG8gYmUgdXNlZCBmb3IgCiAgICAgICAgICAgIERIQ1AvQk9PVFAgcmVxdWVzdHMgZm9y IHRoZSAvIHJlY2VpdmVkIGJ5IHRoZSBpbnRlcmZhY2UuIAogICAgICAgICAgICBUaGlzIHNlcnZl ciBNVVNUIGJlIGFjY2Vzc2libGUgdGhyb3VnaCB0aGUgSEZDIGludGVyZmFjZS4gCiAgICAgICAg ICAgIFRoZSBicm9hZGNhc3QgSVAgYWRkcmVzcyBtdXN0IGJlIHVzZWQgd2hlbiB0aGUgSVAgYWRk cmVzcyAKICAgICAgICAgICAgaXMgdG8gYmUgdW5zcGVjaWZpZWQgb3IgdGhlIGludGVyZmFjZSBp cyB0aGUgSEZDICAKICAgICAgICAgICAgaW50ZXJmYWNlLiIgCiAgClZhbGVudGluZSAgICAgICBJ bmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMjIgDAog ICAgICAgICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBO b3ZlbWJlciAyMDAwIAogCiAKICAgOjo9IHsgZHZiTml1RGhjcEVudHJ5IDMgfSAKICAgIAogICBk dmJOaXVEaGNwUmVsYXkgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJTlRFR0VSICB7 IAogICAgICAgICAgICAgICAgICAgICAgIGVuYWJsZWQoMSksIAogICAgICAgICAgICAgICAgICAg ICAgIGRpc2FibGVkKDIpIAogICAgICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1Mg IHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBU SU9OIAogICAgICAgICAgICJUaGlzIGlzIHVzZWQgdG8gc2VsZWN0IHdoZXRoZXIgdGhlIE5JVSB3 aWxsIHJlbGF5IAogICAgICAgICAgICBESENQL0Jvb3RQIHJlcXVlc3RzIHJlY2VpdmVkIGZyb20g dGhpcyBpbnRlcmZhY2UgdG8gdGhlIEhGQyAKICAgICAgICAgICAgaW50ZXJmYWNlLiAgVGhpcyBv cHRpb24gaXMgaWdub3JlZCBmb3IgdGhlIEhGQyBpbnRlcmZhY2UuIAogICAgICAgICAgICAgICAg ZW5hYmxlZCAgLSByZWxheSBESENQL0Jvb3RQIGFzIHBlciBSRkNzIDk1MSwxNTQyLCAyMTMxIAog ICAgICAgICAgICAgICAgZGlzYWJsZWQgLSBkaXNjYXJkIERIQ1AvQm9vdFAiIAogICAgICAgREVG VkFMICAgICAgeyBkaXNhYmxlZCB9IAogICA6Oj0geyBkdmJOaXVEaGNwRW50cnkgNCB9IAogICAg CiAgIGR2Yk5pdURoY3BSZXFJZiBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIElOVEVH RVIgIHsgCiAgICAgICAgICAgICAgICAgICAgICAgZW5hYmxlZCgxKSwgCiAgICAgICAgICAgICAg ICAgICAgICAgZGlzYWJsZWQoMikgCiAgICAgICAgICAgICAgICAgICB9IAogICAgICAgTUFYLUFD Q0VTUyAgcmVhZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVT Q1JJUFRJT04gCiAgICAgICAgICAgIlRoaXMgaXMgdXNlZCB0byBzZWxlY3Qgd2hldGhlciB0aGUg TklVIHdpbGwgcmVxdWVzdCBhbiBJUCAKICAgICAgICAgICAgYWRkcmVzcyBieSBESENQL0Jvb3RQ IGZvciB0aGlzIGludGVyZmFjZSB2aWEgdGhlIEhGQyAKICAgICAgICAgICAgaW50ZXJmYWNlLiAg SWYgdGhpcyBpcyBkaXNhYmxlZCB0aGVuIHRoZXJlIG11c3QgYmUgYW4gZW50cnkgCiAgICAgICAg ICAgIGluIHRoZSBzdGF0aWMgSVAgdGFibGUgZm9yIHRoaXMgaW50ZXJmYWNlLiAKICAgICAgICAg ICAgICAgIGVuYWJsZWQgIC0gcmVxdWVzdCBhZGRyZXNzIGJ5IERIQ1AvQm9vdFAgCiAgICAgICAg ICAgICAgICBkaXNhYmxlZCAtIFVzZSBzdGF0aWMgSVAgYWRkcmVzcyBhc3NpZ25tZW50IiAKICAg LS0gICAgREVGVkFMIHsgZW5hYmxlZCB9IGZvciB0aGUgSEZDIGludGVyZmFjZSAKICAgOjo9IHsg ZHZiTml1RGhjcEVudHJ5IDUgfSAKICAgIAogICBkdmJOaXVEaGNwU2VyVHlwZSBPQkpFQ1QtVFlQ RSAKICAgICAgIFNZTlRBWCAgICAgIElOVEVHRVIgIHsgCiAgICAgICAgICAgICAgICAgICAgICAg cHJpbWFyeSgxKSwgCiAgICAgICAgICAgICAgICAgICAgICAgYmFja3VwKDIpIAogICAgICAgICAg ICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVT ICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGlzIGlzIHVz ZWQgdG8gaWRlbnRpZnkgd2hldGhlciB0aGUgc3BlY2lmaWVkIHNlcnZlciBmb3IgCiAgICAgICAg ICAgIHRoZSBpbnRlcmZhY2UgaXMgdGhlIHByaW1hcnkgc2VydmVyIG9yIGJhY2t1cC4gIEluIHRo ZSAgCiAgICAgICAgICAgIGV2ZW50IHRoYXQgdGhlIHByaW1hcnkgc2VydmVyIGRvZXMgbm90IHJl c3BvbmQsIHRoZSBiYWNrdXAgIAogICAgICAgICAgICBzZXJ2ZXIgaXMgdXNlZC4gIFRoZXJlIGNh biBiZSBvbmx5IG9uZSBwcmltYXJ5IHNlcnZlciBmb3IgIAogICAgICAgICAgICBhbiBpbnRlcmZh Y2UsIGJ1dCBtdWx0aXBsZSBiYWNrdXAgc2VydmVycy4gIFRoZSBiYWNrdXAgIAogICAgICAgICAg ICBzZXJ2ZXJzIHVzZSB0aGUgdmFsdWVzIGR2Yk5pdURoY3BSZWxheSBhbmQgZHZiTml1RGhjcFJl cUlmICAKICAgICAgICAgICAgc3BlY2lmaWVkIGZvciB0aGUgcHJpbWFyeSBzZXJ2ZXIgZm9yIHRo ZSBpbnRlcmZhY2UsIGlmIGEgIAogICAgICAgICAgICBwcmltYXJ5IHNlcnZlciBpcyBwcmVzZW50 IG90aGVyd2lzZSB0aGUgdmFsdWVzIGFyZSBhcyAgCiAgICAgICAgICAgIGRlZmluZWQgZm9yIHRo ZSBiYWNrdXAgc2VydmVyIHJvdy4gIFRoZSBvcmRlciBpbiB3aGljaCAKICAgICAgICAgICAgYmFj a3VwIHNlcnZlcnMgYXJlIHRyaWVkIGlzIGltcGxpZWQgYnkgdGhlIHZhbHVlIG9mICAKICAKVmFs ZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAg ICAgICAgICAyMyAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNl IFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgICAgICBkdmJOaXVEaGNwSW5k ZXgsIGxvd2VzdCBmaXJzdC4gIFRoaXMgZmllbGQgaXMgbm90IAogICAgICAgICAgICBhcHBsaWNh YmxlIGZvciB0aGUgSEZDIGludGVyZmFjZS4iIAogICAgICAgREVGVkFMIHsgcHJpbWFyeSB9IAog ICA6Oj0geyBkdmJOaXVEaGNwRW50cnkgNiB9IAogICAgCiAgIGR2Yk5pdURoY3BTdGF0ZSBPQkpF Q1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIElOVEVHRVIgIHsgCiAgICAgICAgICAgICAgICAg ICAgICAgaWRsZSgxKSwgCiAgICAgICAgICAgICAgICAgICAgICAgd2FpdGluZ0ZvckRIQ1BvZmZl cigyKSwgCiAgICAgICAgICAgICAgICAgICAgICAgd2FpdGluZ0ZvckRIQ1BhY2soMyksIAogICAg ICAgICAgICAgICAgICAgICAgIGFzc2lnbmVkKDQpIAogICAgICAgICAgICAgICAgICAgfSAKICAg ICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAg ICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyBpcyB0aGUgc3RhdHVzIGZvciBESENQ IGZvciB0aGlzIGludGVyZmFjZS4gCiAgICAgICAgICAgIGlkbGUgICAtIE5vIERIQ1AgcmVxdWVz dCBoYXMgYmVlbiBtYWRlIAogICAgICAgICAgICB3YWl0aW5nRm9yREhDUG9mZmVyIC0gV2FpdGlu ZyBmb3IgREhDUCBvZmZlciAKICAgICAgICAgICAgd2FpdGluZ0ZvckRIQ1BhY2sgICAtIFdhaXRp bmcgZm9yIERIQ1AgYWNrIAogICAgICAgICAgICBhc3NpZ25lZCAtIElQIGFkZHJlc3MgZm9yIEkv RiBhc3NpZ25lZCBieSBESENQLiIgCiAgIDo6PSB7IGR2Yk5pdURoY3BFbnRyeSA3IH0gCiAgICAK ICAgZHZiTml1RGhjcFN0YXR1cyBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIFJvd1N0 YXR1cyAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVTICAgICAg Y3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJDb250cm9scyBhbmQgcmVm bGVjdHMgdGhlIHN0YXR1cyBvZiByb3dzIGluIHRoaXMgCiAgICAgICAgICAgIHRhYmxlLiBSb3dz IGluIHRoaXMgdGFibGUgbWF5IGJlIGNyZWF0ZWQgYnkgZWl0aGVyIHRoZSAKICAgICAgICAgICAg Y3JlYXRlLWFuZC1nbyBvciBjcmVhdGUtYW5kLXdhaXQgcGFyYWRpZ21zLiAgVGhlcmUgaXMgbm8g CiAgICAgICAgICAgIHJlc3RyaWN0aW9uIG9uIGNoYW5naW5nIHZhbHVlcyBpbiBhIHJvdyBvZiB0 aGlzIHRhYmxlIHdoaWxlIAogICAgICAgICAgICB0aGUgcm93IGlzIGFjdGl2ZS4iIAogICA6Oj0g eyBkdmJOaXVEaGNwRW50cnkgOCB9IAogICAgCiAgIC0tID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSAKICAgLS0gPSAgRXZlbnQg R3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IAog ICAtLSA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0gCiAgICAKICAgIAogICBkdmJOaXVFdmVudFBvbGljeSBPQkpFQ1QtVFlQRSAK ICAgICAgIFNZTlRBWCAgICAgIElOVEVHRVIgeyAKICAgICAgICAgICAgICAgICAgICAgICB3cmFw KDEpLCAKICAgICAgICAgICAgICAgICAgICAgICBzdG9wKDIpLCAKICAgICAgICAgICAgICAgICAg ICAgICBvbmVIb3VyKDMpLCAKICAgICAgICAgICAgICAgICAgICAgICBjbGVhck5vdyg0KSAKICAg ICAgICAgICAgICAgICAgIH0gCiAgICAgICBNQVgtQUNDRVNTICByZWFkLXdyaXRlIAogICAgICAg U1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGlz IGRlZmluZXMgZXZlbnQgbG9nIHBvbGljeS4gCiAgICAgICAgICAgICAgICB3cmFwICAgICAgICBX aGVuIGZ1bGwgdGhlIGxvZyB3cmFwcyAKICAgICAgICAgICAgICAgIHN0b3AgICAgICAgIFN0b3Ag ZXZlbnQgbG9nZ2luZyB3aGVuIGZ1bGwgCiAgICAgICAgICAgICAgICBvbmVIb3VyICAgICBDbGVh ciB0aGUgbG9nIGF0IHRoZSBzdGFydCBvZiBldmVyeSBob3VyIAogIApWYWxlbnRpbmUgICAgICAg SW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDI0IAwK ICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAg Tm92ZW1iZXIgMjAwMCAKIAogCiAgICAgICAgICAgICAgICBjbGVhck5vdyAgICBDbGVhcnMgdGhl IGV2ZW50IGxvZy4gUHJldmlvdXMgcG9saWN5IGlzIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgcmVzdG9yZWQuIAogICAgCiAgICAgICAgICAgICAgIEF0IGluaXRpYWwgc3RhcnR1cCB0aGlz IG9iamVjdCBoYXMgdGhlIGRlZmF1bHQgdmFsdWUgb2YgCiAgICAgICAgICAgICAgIHdyYXAoMSku IiAKICAgOjo9IHsgZHZiTml1RXZlbnQgMSB9IAogICAgCiAgIC0tIEV2ZW50IGNvbnRyb2wgdGFi bGUgCiAgICAKICAgZHZiTml1RXZlbnRDb250cm9sVGFibGUgT0JKRUNULVRZUEUgCiAgICAgICBT WU5UQVggICAgICBTRVFVRU5DRSBPRiBEdmJOaXVFdmVudENvbnRyb2xFbnRyeSAKICAgICAgIE1B WC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAg ICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGlzIHRhYmxlIGRlZmluZXMgdGhlIGFjdGlv biB0byBiZSB0YWtlbiBmb3IgdGhlIGRlZmluZWQgCiAgICAgICAgICAgIGV2ZW50IHByaW9yaXRp ZXMuICBBIHJvdyB3aWxsIGV4aXN0IGZvciBlYWNoIHByaW9yaXR5OiAgCiAgICAgICAgICAgIEVt ZXJnZW5jeSwgQWxlcnQsIENyaXRpY2FsLCBFcnJvciwgV2FybmluZywgTm90aWNlLCAgCiAgICAg ICAgICAgIEluZm9ybWF0aW9uIGFuZCBEZWJ1Zy4gQSBiaXQgZmllbGQgaXMgdXNlZCB0byBpZGVu dGlmeSB0aGUgCiAgICAgICAgICAgIGFjdGlvbiB0byBiZSB0YWtlbiBmb3IgdGhlIGV2ZW50IHBy aW9yaXR5LiBBY3Rpb25zIGNhbiBiZTogIAogICAgICAgICAgICBwbGFjZSB0aGUgZXZlbnQgaW4g dGhlIGV2ZW50IHRhYmxlOyBpc3N1ZSBhbiBTTk1QIFRyYXAiIAogICA6Oj0geyBkdmJOaXVFdmVu dCAyIH0gCiAgICAKICAgZHZiTml1RXZlbnRDb250cm9sRW50cnkgT0JKRUNULVRZUEUgCiAgICAg ICBTWU5UQVggICAgICBEdmJOaXVFdmVudENvbnRyb2xFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1Mg IG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NS SVBUSU9OIAogICAgICAgICAgICJUaGVyZSBpcyBhIHJvdyBwZXIgZXZlbnQgYW5kIGFyZSByZWNv cmRlZCBpbiBjaHJvbm9sb2dpY2FsIAogICAgICAgICAgICBvcmRlci4iICAgCiAgICAgICBJTkRF WCB7IGR2Yk5pdUV2ZW50Q3RybFByaW9yaXR5IH0gCiAgIDo6PSB7IGR2Yk5pdUV2ZW50Q29udHJv bFRhYmxlIDEgfSAKICAgIAogICBEdmJOaXVFdmVudENvbnRyb2xFbnRyeSA6Oj0gU0VRVUVOQ0Ug eyAgCiAgICAgICBkdmJOaXVFdmVudENvbnRyb2xQcmlvcml0eSAgICBEdmJFdmVudFByaW9yaXR5 LCAKICAgICAgIGR2Yk5pdUV2ZW50Q29udHJvbEFjdGlvbiAgICAgIEJJVFMgCiAgIH0gCiAgICAK ICAgZHZiTml1RXZlbnRDb250cm9sUHJpb3JpdHkgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVgg ICAgICBEdmJFdmVudFByaW9yaXR5IAogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUg CiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAg ICAgIlRoZSBwcmlvcml0eSBsZXZlbCB0aGF0IGlzIGNvbnRyb2xsZWQgYnkgdGhpcyBlbnRyeS4g IAogICAgICAgICAgICBUaGVzZSBhcmUgb3JkZXJlZCBmcm9tIG1vc3QgKGVtZXJnZW5jeSkgdG8g bGVhc3QgKGRlYnVnKSAKICAgICAgICAgICAgY3JpdGljYWwuICBFYWNoIGV2ZW50IHdpdGggYSBO SVUgaGFzIGEgcGFydGljdWxhciAKICAgICAgICAgICAgcHJpb3JpdHkgbGV2ZWwgYXNzb2NpYXRl ZCB3aXRoIGl0IChhcyBkZWZpbmVkIGJ5IHRoZSAKICAgICAgICAgICAgdmVuZG9yKS4gRHVyaW5n IG5vcm1hbCBvcGVyYXRpb24gbm8gZXZlbnQgbW9yZSBjcml0aWNhbCAgCiAgICAgICAgICAgIHRo YW4gbm90aWNlKDYpIHNob3VsZCBiZSBnZW5lcmF0ZWQuIEV2ZW50cyBiZXR3ZWVuIHdhcm5pbmcg IAogICAgICAgICAgICBhbmQgZW1lcmdlbmN5IHNob3VsZCBiZSBnZW5lcmF0ZWQgYXQgYXBwcm9w cmlhdGUgbGV2ZWxzIG9mIAogICAgICAgICAgICBwcm9ibGVtcyAoZS5nLiBlbWVyZ2VuY3kgd2hl biB0aGUgYm94IGlzIGFib3V0IHRvIAogICAgICAgICAgICBjcmFzaCkuIiAKICAgOjo9IHsgZHZi Tml1RXZlbnRDb250cm9sRW50cnkgMSB9IAogICAgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1h dGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMjUgDAogICAgICAg ICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJl ciAyMDAwIAogCiAKICAgZHZiTml1RXZlbnRDb250cm9sQWN0aW9uIE9CSkVDVC1UWVBFIAogICAg ICAgU1lOVEFYICAgICAgQklUUyB7IAogICAgICAgICAgICAgICAgICAgICAgIGxvY2FsKDApLCAK ICAgICAgICAgICAgICAgICAgICAgICB0cmFwKDEpIAogICAgICAgICAgICAgICAgICAgfSAKICAg ICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAog ICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoaXMgZGVmaW5lcyB0aGUgYWN0aW9ucyB0 byBwZXJmb3JtIHdoZW4gYW4gZXZlbnQgaGFwcGVucyAKICAgICAgICAgICAgb2YgdGhpcyBwcmlv cml0eS4gbG9jYWwgY2F1c2VzIHRoZSBldmVudCB0byBiZSB3cml0dGVuIHRvICAKICAgICAgICAg ICAgdGhlIGxvY2FsIGV2ZW50IGxvZy4gdHJhcCBjYXVzZXMgYSB0cmFwIHRvIGJlIGlzc3VlZC4i IAogICA6Oj0geyBkdmJOaXVFdmVudENvbnRyb2xFbnRyeSAyIH0gCiAgICAKICAgLS0gQ3VycmVu dGx5IG5vIHRyYXBzIGFyZSBkZWZpbmVkLCB0aGVzZSBuZWVkIHRvIGJlIGFkZGVkLiAKICAgIAog ICAtLSBFbmQgb2YgRXZlbnQgY29udHJvbCB0YWJsZSAKICAgIAogICBkdmJOaXVFdmVudFRhYmxl TWF4U2l6ZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIEludGVnZXIzMiAoMS4uMjE0 NzQ4MzY0NykgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAgICAgICBTVEFUVVMgICAg ICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSBtYXhpbXVtIG51 bWJlciBvZiBlbnRyaWVzIHRoZSBldmVudCBsb2cgbWF5IGhvbGQiIAogICA6Oj0geyBkdmJOaXVF dmVudCAzIH0gCiAgICAKICAgLS0gRXZlbnQgdGFibGUgCiAgICAKICAgZHZiTml1RXZlbnRUYWJs ZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIFNFUVVFTkNFIE9GIER2Yk5pdUV2ZW50 RW50cnkgCiAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZSAKICAgICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiQ29udGFpbnMgYSBs b2cgb2YgbmV0d29yayBhbmQgZGV2aWNlIGV2ZW50cyB0aGF0IG1heSBiZSBvZiAKICAgICAgICAg ICAgaW50ZXJlc3QgaW4gZmF1bHQgaXNvbGF0aW9uIGFuZCB0cm91YmxlIHNob290aW5nLiIgCiAg IDo6PSB7IGR2Yk5pdUV2ZW50IDQgfSAKICAgIAogICBkdmJOaXVFdmVudEVudHJ5IE9CSkVDVC1U WVBFIAogICAgICAgU1lOVEFYICAgICAgRHZiTml1RXZlbnRFbnRyeSAKICAgICAgIE1BWC1BQ0NF U1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERF U0NSSVBUSU9OIAogICAgICAgICAgICJFbnRyaWVzIGFyZSBjcmVhdGVkIHdoZW4gYW4gZXZlbnQg b2NjdXJycy4gIAogICAgICAgICAgICBkdmJOaXVFdmVudFBvbGljeSBjYW4gYmUgdXNlZCB0byBj bGVhciB0aGUgdGFibGUgaW4gIAogICAgICAgICAgICBhZGRpdGlvbiBpbmRpdmlkdWFsIGV2ZW50 cyBjYW4gYmUgZGVsZXRlZC4iICAgCiAgICAgICBJTkRFWCB7IGR2Yk5pdUV2ZW50SW5kZXggfSAK ICAgOjo9IHsgZHZiTml1RXZlbnRUYWJsZSAxIH0gCiAgICAKICAgRHZiTml1RXZlbnRFbnRyeSA6 Oj0gU0VRVUVOQ0UgeyAgCiAgICAgICBkdmJOaXVFdmVudEluZGV4ICAgICAgICBVbnNpZ25lZDMy LCAKICAgICAgIGR2Yk5pdUV2ZW50VHlwZSAgICAgICAgIER2YkV2ZW50UHJpb3JpdHksIAogICAg ICAgZHZiTml1RXZlbnREYXRlVGltZSAgICAgRGF0ZUFuZFRpbWUsIAogICAgICAgZHZiTml1RXZl bnREZXNjcmlwdGlvbiAgU25tcEFkbWluU3RyaW5nLCAKICAgICAgIGR2Yk5pdUV2ZW50Q29kZSAg ICAgICAgIFNubXBBZG1pblN0cmluZywgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFs IC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMjYgDAogICAgICAgICAgICAg ICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAw IAogCiAKICAgICAgIGR2Yk5pdUV2ZW50U3RhdHVzICAgICAgIFJvd1N0YXR1cyAKICAgfSAKICAg IAogICBkdmJOaXVFdmVudEluZGV4IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgVW5z aWduZWQzMiAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVT ICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OICAKICAgICAgICAgICAiVGhpcyBwcm92 aWRlcyByZWxhdGl2ZSBvcmRlcmluZyBvZiB0aGUgb2JqZWN0cyBpbiB0aGUgZXZlbnQgCiAgICAg ICAgICAgIGxvZy4gVGhpcyBvYmplY3Qgd2lsbCBhbHdheXMgaW5jcmVhc2UgZXhjZXB0IHdoZW4g CiAgICAgICAgICAgICAgICAoYSkgdGhlIGxvZyBpcyByZXNldCB2aWEgZHZiTml1RXZlbnRQb2xp Y3ksIAogICAgICAgICAgICAgICAgKGIpIHRoZSBkZXZpY2UgcmVib290cyBhbmQgZG9lcyBub3Qg aW1wbGVtZW50IG5vbi0gCiAgICAgICAgICAgICAgICAgICAgdm9sYXRpbGUgc3RvcmFnZSBmb3Ig dGhpcyBsb2csIG9yIChjKSBpdCByZWFjaGVzICAgCiAgICAgICAgICAgICAgICAgICAgdGhlIHZh bHVlIDJeMzEuIFRoZSBuZXh0IGVudHJ5IGZvciBhbGwgdGhlIGFib3ZlICAKICAgICAgICAgICAg ICAgICAgICBjYXNlcyBpcyAxLiIgCiAgIDo6PSB7IGR2Yk5pdUV2ZW50RW50cnkgMSB9IAogICAg CiAgIGR2Yk5pdUV2ZW50VHlwZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIER2YkV2 ZW50UHJpb3JpdHkgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gIAogICAgICAgICAgICJUaGlzIGlzIHRo ZSBwcmlvcml0eSBvZiB0aGUgZXZlbnQuIiAKICAgOjo9IHsgZHZiTml1RXZlbnRFbnRyeSAyIH0g CiAgICAKICAgZHZiTml1RXZlbnREYXRlVGltZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAg ICAgIERhdGVBbmRUaW1lIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5IAogICAgICAgU1RB VFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OICAKICAgICAgICAgICAiVGhpcyBp cyB0aGUgZGF0ZSBhbmQgdGltZSB0aGUgZXZlbnQgb2NjdXJyZWQuIiAKICAgOjo9IHsgZHZiTml1 RXZlbnRFbnRyeSAzIH0gCiAgICAKICAgZHZiTml1RXZlbnREZXNjcmlwdGlvbiBPQkpFQ1QtVFlQ RSAKICAgICAgIFNZTlRBWCAgICAgIFNubXBBZG1pblN0cmluZyAKICAgICAgIE1BWC1BQ0NFU1Mg IHJlYWQtb25seSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElP TiAgCiAgICAgICAgICAgIlRoaXMgaXMgYSB2ZW5kb3Igc3BlY2lmaWMgdGV4dHVhbCBkZXNjcmlw dGlvbiBvZiB0aGUgIAogICAgICAgICAgICBldmVudC4iIAogICA6Oj0geyBkdmJOaXVFdmVudEVu dHJ5IDQgfSAKICAgIAogICBkdmJOaXVFdmVudENvZGUgT0JKRUNULVRZUEUgCiAgICAgICBTWU5U QVggICAgICBTbm1wQWRtaW5TdHJpbmcgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gIAogICAgICAgICAg ICJUaGlzIGlzIHRoZSBldmVudCBjb2RlIHdoaWNoIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIGV2 ZW50LiAKICAgICAgICAgICAgVGhlIGV2ZW50IGNvZGVzIHNob3VsZCBiZSBpbiB0aGUgZm9ybSB0 cHB4eHh4eCB3aGVyZTotIAogICAgICAgICAgICB0ICAtIGlkZW50aWZpZXMgd2hvIGFsbG9jYXRl ZCB0aGUgZXZlbnQgaWRlbnRpZmllcjsgZCA9IAogICAgICAgICAgICAgICAgIGR2YiwgdiA9IHZl bmRvciAKICAgICAgICAgICAgcHAgLSBpZGVudGlmaWVzIHRoZSBwcmlvcml0eTsgZW0gPSBlbWVy Z2VuY3ksIGFsID0gYWxlcnQsIAogICAgICAgICAgICAgICAgIGNyID0gY3JpdGljYWwsIGVyID0g ZXJyb3IsIHdhID0gd2FybmluZywgbm8gPSBub3RpY2UsIAogIApWYWxlbnRpbmUgICAgICAgSW5m b3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDI3IAwKICAg ICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92 ZW1iZXIgMjAwMCAKIAogCiAgICAgICAgICAgICAgICAgaW4gPSBpbmZvcm1hdGlvbiwgZGUgPSBk ZWJ1ZyAKICAgICAgICAgICAgeHh4eHh4eCAtIHRoZSBldmVudCBpZGVudGlmaWVyIHdoaWNoIGlz IDUgY2hhcmFjdGVycy4iIAogICA6Oj0geyBkdmJOaXVFdmVudEVudHJ5IDUgfSAKICAgIAogICBk dmJOaXVFdmVudFN0YXR1cyBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIFJvd1N0YXR1 cyAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50IAogICAgICAgREVTQ1JJUFRJT04gIAogICAgICAgICAgICJUaGlzIGlzIHVzZWQgdG8gZGVs ZXRlIGluZGl2aWR1YWwgZXZlbnRzLiAgVGhlIG9ubHkgdmFsaWQgCiAgICAgICAgICAgIG1hbmFn ZW1lbnQgb3BlcmF0aW9uIGlzIGRlc3Ryb3ksIHdoaWNoIGNhdXNlcyB0aGUgZXZlbnQgdG8gIAog ICAgICAgICAgICBiZSBkZWxldGVkLiAgV2hlbiByZWFkIHRoaXMgb2JqZWN0IHNob3VsZCBhbHdh eXMgcmV0dXJuICAKICAgICAgICAgICAgYWN0aXZlLiIgCiAgIDo6PSB7IGR2Yk5pdUV2ZW50RW50 cnkgNiB9IAogICAgCiAgIC0tIEVuZCBvZiBFdmVudCB0YWJsZSAKICAgIAogICAtLSBUaGVzZSBh cHBseSB0byB0cmFwcyBzZW50IHRvIGFsbCAKICAgIAogICBkdmJOaXVFdlRocm90dGxlQWRtaW5T dGF0dXMgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJTlRFR0VSIHsgCiAgICAgICAg ICAgICAgICAgICAgICAgdW5jb25zdHJhaW5lZCgxKSwgCiAgICAgICAgICAgICAgICAgICAgICAg bWFpbnRhaW5CZWxvd1RocmVzaG9sZCgyKSwgCiAgICAgICAgICAgICAgICAgICAgICAgc3RvcEF0 VGhyZXNob2xkKDMpLCAKICAgICAgICAgICAgICAgICAgICAgICBpbmhpYml0ZWQoNCkgCiAgICAg ICAgICAgICAgICAgICB9IAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNU QVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiQ29udHJv bHMgdGhlIHRyYW5zbWlzc2lvbiBvZiB0cmFwcyB3aXRoIHJlc3BlY3QgdG8gdGhlIAogICAgICAg ICAgICB0cmFwIHBhY2luZyB0aHJlc2hvbGQuIAogICAgICAgICAgICB1bmNvbnN0cmFpbmVkKDEp IGNhdXNlcyB0cmFwcyB0byBiZSB0cmFuc21pdHRlZCB3aXRob3V0IAogICAgICAgICAgICByZWdh cmQgdG8gdGhlIHRocmVzaG9sZCBzZXR0aW5ncy4gCiAgICAgICAgICAgIG1haW50YWluQmVsb3dU aHJlc2hvbGQoMikgY2F1c2VzIHRyYXAgdHJhbnNtaXNzaW9uIHRvIGJlIAogICAgICAgICAgICBz dXBwcmVzc2VkIGlmIHRoZSBudW1iZXIgb2YgdHJhcHMgd291bGQgb3RoZXJ3aXNlIGV4Y2VlZCAK ICAgICAgICAgICAgdGhlIHRocmVzaG9sZC4gCiAgICAgICAgICAgIHN0b3BBdFRocmVzaG9sZCgz KSBjYXVzZXMgdHJhcCB0cmFuc21pc3Npb24gdG8gY2Vhc2UgCiAgICAgICAgICAgIGF0IHRoZSB0 aHJlc2hvbGQsIGFuZCBub3QgcmVzdW1lIHVudGlsIGRpcmVjdGVkIHRvIGRvIHNvLiAKICAgICAg ICAgICAgU2VlIGFsc28gUkZDIDEyMjQuIAogICAgICAgICAgICBpbmhpYml0ZWQoNCkgY2F1c2Vz IGFsbCB0cmFwIHRyYW5zbWlzc2lvbiBtZXNzYWdlcyB0byBiZSAKICAgICAgICAgICAgc3VwcHJl c3NlZC4gIAogICAgCiAgICAgICAgICAgIFdyaXRpbmcgdG8gdGhpcyBvYmplY3QgcmVzZXRzIHRo ZSB0aHJlc2hvbGRpbmcgc3RhdGUuIAogICAgCiAgICAgICAgICAgIEF0IGluaXRpYWwgc3RhcnR1 cCwgdGhpcyBvYmplY3QgaGFzIGEgZGVmYXVsdCB2YWx1ZSBvZiAKICAgICAgICAgICAgdW5jb25z dHJhaW5lZCgxKS4gCiAgICAKICAgICAgICAgICAgQWxsIHRoZSBuZXR3b3JrIG1hbmFnZXJzIHdp dGggdGhlIHRyYXAgY2FwYWJpbGl0eSBhcyBwZXIgCiAgICAgICAgICAgIFJGQzI1NzMgd2lsbCBi ZSB0cmVhdGVkIGFzIGEgc2luZ2xlIGVudGl0eSB3aXRoIHJlZ2FyZCB0byAKICAgICAgICAgICAg VHJhcCBtYW5hZ2VtZW50LiAgVGhpcyBpcyBkb25lIHRvIHNpbXBsaWZ5IGltcGxlbWVudGF0aW9u IAogICAgICAgICAgICB3aXRoaW4gdGhlIE5JVS4iIAogICA6Oj0geyBkdmJOaXVFdmVudCA1IH0g CiAgICAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJl ciAyMDAwICAgICAgICAgICAgICAyOCAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdv cmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICBkdmJOaXVFdlRo cm90dGxlSW5oaWJpdGVkIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgVHJ1dGhWYWx1 ZSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJl bnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiSWYgdHJ1ZSgxKSwgdHJhcCBpcyBj dXJyZW50bHkgaW5oaWJpdGVkIGR1ZSB0byB0aHJlc2hvbGRzIAogICAgICAgICAgICBhbmQvb3Ig dGhlIGN1cnJlbnQgc2V0dGluZyBvZiBkdmJOaXVFdlRocm90dGxlQWRtaW5TdGF0dXMuIAogICAg ICAgICAgICBJbiBhZGRpdGlvbiwgdGhpcyBpcyBzZXQgdG8gdHJ1ZSgxKSBpZiB0cmFuc21pc3Np b24gaXMgCiAgICAgICAgICAgIGluaGliaXRlZCBkdWUgdG8gbm8gdHJhcCAoZHZiTml1Tm1BY2Nl c3NFbnRyeSkgCiAgICAgICAgICAgIGRlc3RpbmF0aW9ucyBoYXZpbmcgYmVlbiBzZXQuIiAKICAg Ojo9IHsgZHZiTml1RXZlbnQgNiB9IAogICAgCiAgIGR2Yk5pdUV2VGhyb3R0bGVUaHJlc2hvbGQg T0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBVbnNpZ25lZDMyIAogICAgICAgTUFYLUFD Q0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVND UklQVElPTiAKICAgICAgICAgICAiTnVtYmVyIG9mIHRyYXAgZXZlbnRzIHBlciBEdmJOaXVFdlRo cm90dGxlSW50ZXJ2YWwgCiAgICAgICAgICAgIHRvIGJlIHRyYW5zbWl0dGVkIGJlZm9yZSB0aHJv dHRsaW5nLiAKICAgIAogICAgICAgICAgICBBdCBpbml0aWFsIHN0YXJ0dXAsIHRoaXMgb2JqZWN0 IHJldHVybnMgMC4iIAogICA6Oj0geyBkdmJOaXVFdmVudCA3IH0gCiAgICAKICAgZHZiTml1RXZU aHJvdHRsZUludGVydmFsIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW50ZWdlcjMy ICgxLi4yMTQ3NDgzNjQ3KSAKICAgICAgIFVOSVRTICAgICAgICJzZWNvbmRzIiAKICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtd3JpdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAg REVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSBpbnRlcnZhbCBvdmVyIHdoaWNoIHRoZSB0cmFw IHRocmVzaG9sZCBhcHBsaWVzLiAKICAgICAgICAgICAgQXQgaW5pdGlhbCBzdGFydHVwLCB0aGlz IG9iamVjdCBoYXMgYSB2YWx1ZSBvZiAxLiIgCiAgIDo6PSB7IGR2Yk5pdUV2ZW50IDggfSAKICAg IAogICAgCiAgICAKICAgLS0gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09IAogICAtLSA9ICBJUCBGaWx0ZXIgR3JvdXAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gCiAgIC0tID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSAKICAg IAogICBkdmJOaXVJcEZpbHRlckVuYWJsZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAg IElOVEVHRVIgeyAKICAgICAgICAgICAgICAgICAgICAgICBlbmFibGVkKDEpLCAKICAgICAgICAg ICAgICAgICAgICAgICBjb3VudEhpdHMoMyksIAogICAgICAgICAgICAgICAgICAgICAgIGRpc2Fi bGVkKDQpIAogICAgICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3Jp dGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAg ICAgICAgIlRoaXMgY29udHJvbHMgdGhlIElQIGZpbHRlciB0YWJsZS4gCiAgICAgICAgICAgICAg ICBlbmFibGUgICAgIC0gRW5hYmxlcyB0aGUgSVAgZmlsdGVyIHRhYmxlLiAKICAgICAgICAgICAg ICAgIGNvdW50SGl0cyAgLSBUaGlzIG9wdGlvbiBpcyB1c2VkIHRvIGRlYnVnIHRoZSBmaWx0ZXIg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFibGUuICBJdCBhbGxvd3MgcGFja2V0cyB0 byBiZSBjaGVja2VkICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZ2FpbnN0IHRoZSBm aWx0ZXIgdGFibGUgYW5kIGluY3JlbWVudHMgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlv bmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMjkgDAogICAgICAgICAg ICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAy MDAwIAogCiAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkdmJOaXVJcEZpbHRlck1hdGNo ZXMgZm9yIGEgbWF0Y2hpbmcgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsdGVyLCBi dXQgQUxMIFBBQ0tFVFMgQVJFIEFMTE9XRUQgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRIUk9VR0guICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBkaXNh YmxlZCAgIC0gRGlzYWJsZXMgSVAgZmlsdGVyaW5nLCBhbGwgcGFja2V0cyBhcmUgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYWxsb3dlZCB0aHJvdWdoLiAKICAgIAogICAgICAgICAgICAg ICAgQXQgaW5pdGlhbCBzdGFydHVwIHRoaXMgb2JqZWN0IGhhcyB0aGUgZGVmYXVsdCB2YWx1ZSBv ZiAKICAgICAgICAgICAgICAgIGRpc2FibGVkKDQpLiIgCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVy IDEgfSAKICAgIAogICAgCiAgIGR2Yk5pdUlwRmlsdGVyVGFibGUgT0JKRUNULVRZUEUgCiAgICAg ICBTWU5UQVggICAgICBTRVFVRU5DRSBPRiBEdmJOaXVJcEZpbHRlckVudHJ5IAogICAgICAgTUFY LUFDQ0VTUyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAg ICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIkFuIG9yZGVyZWQgbGlzdCBvZiBmaWx0ZXJzIG9y IGNsYXNzaWZpZXJzIHRvIGFwcGx5IHRvIAogICAgICAgICAgICBJUCB0cmFmZmljLiBGaWx0ZXIg YXBwbGljYXRpb24gaXMgb3JkZXJlZCBieSB0aGUgZmlsdGVyIAogICAgICAgICAgICBpbmRleCwg cmF0aGVyIHRoYW4gYnkgYSBiZXN0IG1hdGNoIGFsZ29yaXRobSAoTm90ZSB0aGF0IAogICAgICAg ICAgICB0aGlzIGltcGxpZXMgdGhhdCB0aGUgZmlsdGVyIHRhYmxlIG1heSBoYXZlIGdhcHMgaW4g dGhlIAogICAgICAgICAgICBpbmRleCB2YWx1ZXMpLiBQYWNrZXRzIHdoaWNoIGhhdmUgbWF0Y2hl ZCBubyBmaWx0ZXJzIHdpbGwgCiAgICAgICAgICAgIGJlIGRpc2NhcmRlZCBpLmUuIG5vIGhpdHMg b24gYW55IGZpbHRlci4gCiAgICAKICAgICAgICAgICAgQW55IElQIHBhY2tldCBjYW4gdGhlb3Jl dGljYWxseSBtYXRjaCBtdWx0aXBsZSByb3dzIG9mIAogICAgICAgICAgICB0aGlzIHRhYmxlLiAg V2hlbiBjb25zaWRlcmluZyBhIHBhY2tldCwgdGhlIHRhYmxlIGlzIAogICAgICAgICAgICBzY2Fu bmVkIGluIHJvdyBpbmRleCBvcmRlciAoZS5nLiBmaWx0ZXIgMTAgaXMgY2hlY2tlZCAKICAgICAg ICAgICAgYmVmb3JlIGZpbHRlciAyMCkuICBJZiB0aGUgcGFja2V0IG1hdGNoZXMgdGhhdCBmaWx0 ZXIgCiAgICAgICAgICAgICh3aGljaCBtZWFucyB0aGF0IGl0IG1hdGNoZXMgQUxMIGNyaXRlcmlh IGZvciB0aGF0IHJvdyksIAogICAgICAgICAgICBhY3Rpb25zIGFwcHJvcHJpYXRlIHRvIGR2Yk5p dUlwRmlsdGVyQWN0aW9uIGFuZCAKICAgICAgICAgICAgZHZiTml1SXBGaWx0ZXJBY3Rpb25QdHIg YXJlIHRha2VuLiAgSWYgdGhlIHBhY2tldCB3YXMgCiAgICAgICAgICAgIGRpc2NhcmRlZCBwcm9j ZXNzaW5nIGlzIGNvbXBsZXRlLiAgSWYgCiAgICAgICAgICAgIGR2Yk5pdUlwRmlsdGVyQ29udGlu dWUgaXMgc2V0IHRvIHRydWUsIHRoZSBmaWx0ZXIgCiAgICAgICAgICAgIGNvbXBhcmlzb24gY29u dGludWVzIHdpdGggdGhlIG5leHQgcm93IGluIHRoZSB0YWJsZSAKICAgICAgICAgICAgbG9va2lu ZyBmb3IgYWRkaXRpb25hbCBtYXRjaGVzLiIgCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyIDIgfSAK ICAgIAogICBkdmJOaXVJcEZpbHRlckVudHJ5IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAg ICAgRHZiTml1SXBGaWx0ZXJFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxl IAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAg ICAgICJEZXNjcmliZXMgYSBmaWx0ZXIgdG8gYXBwbHkgdG8gSVAgdHJhZmZpYyByZWNlaXZlZCBv biBhIAogICAgICAgICAgICBzcGVjaWZpZWQgaW50ZXJmYWNlLiAgQWxsIGlkZW50aXR5IG9iamVj dHMgaW4gdGhpcyB0YWJsZSAKICAgICAgICAgICAgKGUuZy4gc291cmNlIGFuZCBkZXN0aW5hdGlv biBhZGRyZXNzL21hc2ssIHByb3RvY29sLCAKICAgICAgICAgICAgc291cmNlL2Rlc3QgcG9ydCwg VE9TL21hc2ssIGludGVyZmFjZSBhbmQgZGlyZWN0aW9uKSBtdXN0IAogICAgICAgICAgICBtYXRj aCB0aGVpciByZXNwZWN0aXZlIGZpZWxkcyBpbiB0aGUgcGFja2V0IGZvciBhbnkgZ2l2ZW4gCiAg ICAgICAgICAgIGZpbHRlciB0byBtYXRjaC4gCiAgICAKICAgICAgICAgICAgVG8gY3JlYXRlIGFu IGVudHJ5IGluIHRoaXMgdGFibGUsIGR2Yk5pdUlwRmlsdGVySWZJbmRleCAKICAgICAgICAgICAg bXVzdCBiZSBzcGVjaWZpZWQuIiAKICAgICAgICAgICAgSU5ERVggeyBkdmJOaXVJcEZpbHRlcklu ZGV4IH0gCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyVGFibGUgMSB9IAogICAgCiAgClZhbGVudGlu ZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAg ICAgMzAgDAogICAgICAgICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0 IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAKICAgRHZiTml1SXBGaWx0ZXJFbnRyeSA6Oj0gU0VR VUVOQ0UgeyAKICAgICAgIGR2Yk5pdUlwRmlsdGVySW5kZXggICAgICAgICAgVW5zaWduZWQzMiwg CiAgICAgICBkdmJOaXVJcEZpbHRlclN0YXR1cyAgICAgICAgIFJvd1N0YXR1cywgCiAgICAgICBk dmJOaXVJcEZpbHRlcklmSW5kZXggICAgICAgIEludGVyZmFjZUluZGV4T3JaZXJvLCAKICAgICAg IGR2Yk5pdUlwRmlsdGVyRGlyZWN0aW9uICAgICAgSU5URUdFUiwgCiAgICAgICBkdmJOaXVJcEZp bHRlclRvcyAgICAgICAgICAgIE9DVEVUIFNUUklORywgCiAgICAgICBkdmJOaXVJcEZpbHRlclRv c01hc2sgICAgICAgIE9DVEVUIFNUUklORywgCiAgICAgICBkdmJOaXVJcEZpbHRlclNyY0FkZHJU eXBlICAgIEluZXRBZGRyZXNzVHlwZSwgICAgICAgICAKICAgICAgIGR2Yk5pdUlwRmlsdGVyU3Jj QWRkciAgICAgICAgSW5ldEFkZHJlc3MsIAogICAgICAgZHZiTml1SXBGaWx0ZXJTcmNNYXNrVHlw ZSAgICBJbmV0QWRkcmVzc1R5cGUsIAogICAgICAgZHZiTml1SXBGaWx0ZXJTcmNNYXNrICAgICAg ICBJbmV0QWRkcmVzcywgCiAgICAgICBkdmJOaXVJcEZpbHRlckRzdEFkZHJUeXBlICAgIEluZXRB ZGRyZXNzVHlwZSwgCiAgICAgICBkdmJOaXVJcEZpbHRlckRzdEFkZHIgICAgICAgIEluZXRBZGRy ZXNzLCAKICAgICAgIGR2Yk5pdUlwRmlsdGVyRHN0TWFza1R5cGUgICAgSW5ldEFkZHJlc3NUeXBl LCAKICAgICAgIGR2Yk5pdUlwRmlsdGVyRHN0TWFzayAgICAgICAgSW5ldEFkZHJlc3MsIAogICAg ICAgZHZiTml1SXBGaWx0ZXJQcm90b2NvbCAgICAgICBJbnRlZ2VyMzIsIAogICAgICAgZHZiTml1 SXBGaWx0ZXJTcmNQb3J0TG93ICAgICBJbnRlZ2VyMzIsIAogICAgICAgZHZiTml1SXBGaWx0ZXJT cmNQb3J0SGlnaCAgICBJbnRlZ2VyMzIsIAogICAgICAgZHZiTml1SXBGaWx0ZXJEc3RQb3J0TG93 ICAgICBJbnRlZ2VyMzIsIAogICAgICAgZHZiTml1SXBGaWx0ZXJEc3RQb3J0SGlnaCAgICBJbnRl Z2VyMzIsIAogICAgICAgZHZiTml1SXBGaWx0ZXJBY3Rpb24gICAgICAgICBJTlRFR0VSLCAKICAg ICAgIGR2Yk5pdUlwRmlsdGVyTWF0Y2hlcyAgICAgICAgQ291bnRlcjMyLCAKICAgICAgIGR2Yk5p dUlwRmlsdGVyQ29udGludWUgICAgICAgVHJ1dGhWYWx1ZSwgCiAgICAgICBkdmJOaXVJcEZpbHRl ckFjdGlvblB0ciAgICAgIEludGVnZXIzMiAKICAgfSAKICAgIAogICBkdmJOaXVJcEZpbHRlcklu ZGV4IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgVW5zaWduZWQzMiAKICAgICAgIE1B WC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAg ICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJJbmRleCB1c2VkIHRvIG9yZGVyIHRoZSBhcHBs aWNhdGlvbiBvZiBmaWx0ZXJzLiAKICAgICAgICAgICAgVGhlIGZpbHRlciB3aXRoIHRoZSBsb3dl c3QgaW5kZXggaXMgYWx3YXlzIGFwcGxpZWQgCiAgICAgICAgICAgIGZpcnN0LiIgCiAgIDo6PSB7 IGR2Yk5pdUlwRmlsdGVyRW50cnkgMSB9IAogICAgCiAgIGR2Yk5pdUlwRmlsdGVyU3RhdHVzIE9C SkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgUm93U3RhdHVzIAogICAgICAgTUFYLUFDQ0VT UyAgcmVhZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJ UFRJT04gCiAgICAgICAgICAgIkNvbnRyb2xzIGFuZCByZWZsZWN0cyB0aGUgc3RhdHVzIG9mIHJv d3MgaW4gdGhpcyAKICAgICAgICAgICAgdGFibGUuIFNwZWNpZnlpbmcgb25seSB0aGlzIG9iamVj dCAod2l0aCB0aGUgYXBwcm9wcmlhdGUgCiAgICAgICAgICAgIGluZGV4KSBvbiBhIE5JVSBpcyBz dWZmaWNpZW50IHRvIGNyZWF0ZSBhIGZpbHRlciByb3cgd2hpY2ggCiAgICAgICAgICAgIG1hdGNo ZXMgYWxsIGluYm91bmQgcGFja2V0cyBvbiB0aGUgRXRoZXJuZXQgaW50ZXJmYWNlLCAKICAgICAg ICAgICAgYW5kIHJlc3VsdHMgaW4gdGhlIHBhY2tldHMgYmVpbmcgZGlzY2FyZGVkLiAgQ3JlYXRp b24gb2YgIAogICAgICAgICAgICB0aGUgcm93cyBtYXkgYmUgZG9uZSB2aWEgZWl0aGVyIGNyZWF0 ZS1hbmQtd2FpdCBvciAKICAgICAgICAgICAgY3JlYXRlLWFuZC1nbywgYnV0IHRoZSBmaWx0ZXIg aXMgbm90IGFwcGxpZWQgdW50aWwgdGhpcyAKICAgICAgICAgICAgb2JqZWN0IGlzIHNldCB0byAo b3IgY2hhbmdlcyB0bykgYWN0aXZlLiBUaGVyZSBpcyBubyAKICAgICAgICAgICAgcmVzdHJpY3Rp b24gaW4gY2hhbmdpbmcgYW55IG9iamVjdCBpbiBhIHJvdyB3aGlsZSB0aGlzIAogICAgICAgICAg ICBvYmplY3QgaXMgc2V0IHRvIGFjdGl2ZS4iIAogICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5 IDIgfSAKICAgIAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2Vw dGVtYmVyIDIwMDAgICAgICAgICAgICAgIDMxIAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUg TmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgICAKICAg ZHZiTml1SXBGaWx0ZXJJZkluZGV4IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW50 ZXJmYWNlSW5kZXhPclplcm8gCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAg IFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhl IGVudHJ5IGludGVyZmFjZSB0byB3aGljaCB0aGlzIGZpbHRlciBhcHBsaWVzLiBUaGUgCiAgICAg ICAgICAgIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGlmSW5kZXggZm9yIGVpdGhlciBhIENBVFYgTUFD IG9yIAogICAgICAgICAgICBhbm90aGVyIG5ldHdvcmsgaW50ZXJmYWNlLiBJZiB0aGUgdmFsdWUg aXMgemVybywgdGhlIAogICAgICAgICAgICBmaWx0ZXIgYXBwbGllcyB0byBhbGwgaW50ZXJmYWNl cy4gRGVmYXVsdCB2YWx1ZSBpbiBOSVUgCiAgICAgICAgICAgIGlzIHRoZSBpbmRleCBvZiB0aGUg Y3VzdG9tZXItc2lkZSAoZS5nLiBldGhlcm5ldCkgCiAgICAgICAgICAgIGludGVyZmFjZS4iIAog ICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5IDQgfSAKICAgIAogICBkdmJOaXVJcEZpbHRlckRp cmVjdGlvbiBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCBJTlRFR0VSIHsgCiAgICAgICAgICAg ICAgICAgIGluYm91bmQoMSksIAogICAgICAgICAgICAgICAgICBvdXRib3VuZCgyKSwgCiAgICAg ICAgICAgICAgICAgIGJvdGgoMykgCiAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1Mg IHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBU SU9OIAogICAgICAgICAgICJEZXRlcm1pbmVzIHdoZXRoZXIgdGhlIGZpbHRlciBpcyBhcHBsaWVk IHRvIGluYm91bmQoMSkgCiAgICAgICAgICAgIHRyYWZmaWMsIG91dGJvdW5kKDIpIHRyYWZmaWMs IG9yIHRyYWZmaWMgaW4gYm90aCgzKSAKICAgICAgICAgICAgZGlyZWN0aW9ucy4iIAogICAgICAg REVGVkFMIHsgaW5ib3VuZCB9IAogICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5IDUgfSAKICAg IAogICBkdmJOaXVJcEZpbHRlclRvcyAgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBP Q1RFVCBTVFJJTkcgKCBTSVpFICgxKSkgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAK ICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAg ICAiVGhpcyBpcyB0aGUgdmFsdWUgdG8gYmUgbWF0Y2hlZCB0byB0aGUgcGFja2V0J3MgCiAgICAg ICAgICAgIFRPUyAoVHlwZSBvZiBTZXJ2aWNlKSB2YWx1ZSAoYWZ0ZXIgdGhlIFRPUyB2YWx1ZSAK ICAgICAgICAgICAgaXMgQU5EJ2Qgd2l0aCBkdmJOaXVJcEZpbHRlclRvc01hc2spLiAgQSB2YWx1 ZSBmb3IgdGhpcyAKICAgICAgICAgICAgb2JqZWN0IG9mIDAgYW5kIGEgbWFzayBvZiAwIG1hdGNo ZXMgYWxsIFRPUyB2YWx1ZXMuIiAKICAgICAgIERFRlZBTCB7ICcwMCdoIH0gCiAgIDo6PSB7IGR2 Yk5pdUlwRmlsdGVyRW50cnkgNiB9IAogICAgCiAgIGR2Yk5pdUlwRmlsdGVyVG9zTWFzayBPQkpF Q1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIE9DVEVUIFNUUklORyAoIFNJWkUgKDEpICkgCiAg ICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQg CiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlIG1hc2sgdG8gYmUgYXBwbGllZCB0 byB0aGUgcGFja2V0J3MgVE9TIHZhbHVlIGJlZm9yZSAKICAgICAgICAgICAgbWF0Y2hpbmcuIiAK ICAgICAgIERFRlZBTCB7ICcwMCdoIH0gCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyRW50cnkgNyB9 IAogICAgCiAgIGR2Yk5pdUlwRmlsdGVyU3JjQWRkclR5cGUgT0JKRUNULVRZUEUgCiAgICAgICBT WU5UQVggICAgICBJbmV0QWRkcmVzc1R5cGUgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlv bmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMzIgDAogICAgICAgICAg ICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAy MDAwIAogCiAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVTICAg ICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgdHlwZSBvZiBJ UCBhZGRyZXNzIGZvciB0aGUgc291cmNlIGFkZHJlc3MuIiAKICAgOjo9IHsgZHZiTml1SXBGaWx0 ZXJFbnRyeSA4IH0gCiAgICAKICAgZHZiTml1SXBGaWx0ZXJTcmNBZGRyIE9CSkVDVC1UWVBFIAog ICAgICAgU1lOVEFYICAgICAgSW5ldEFkZHJlc3MgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNy ZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAg ICAgICAgICAiVGhlIHNvdXJjZSBJUCBhZGRyZXNzLCBvciBwb3J0aW9uIHRoZXJlb2YsIHRoYXQg aXMgdG8gYmUgCiAgICAgICAgICAgIG1hdGNoZWQgZm9yIHRoaXMgZmlsdGVyLiAgVGhlIHNvdXJj ZSBhZGRyZXNzIGlzIGZpcnN0IAogICAgICAgICAgICBtYXNrZWQgKGFuZCdlZCkgYWdhaW5zdCBk dmJOaXVJcEZpbHRlclNyY01hc2sgYmVmb3JlIGJlaW5nIAogICAgICAgICAgICBjb21wYXJlZCAg dG8gdGhpcyB2YWx1ZS4gIEEgdmFsdWUgb2YgMCBmb3IgdGhpcyBvYmplY3QgCiAgICAgICAgICAg IGFuZCAwIGZvciB0aGUgbWFzayBtYXRjaGVzIGFsbCBJUCBhZGRyZXNzZXMuIiAKICAgOjo9IHsg ZHZiTml1SXBGaWx0ZXJFbnRyeSA5IH0gCiAgICAKICAgZHZiTml1SXBGaWx0ZXJTcmNNYXNrVHlw ZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIEluZXRBZGRyZXNzVHlwZSAKICAgICAg IE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAg ICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgdHlwZSBvZiBJUCBhZGRyZXNzIGZvciB0 aGUgc291cmNlIGFkZHJlc3MgbWFzay4iIAogICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5IDEw IH0gCiAKICAgZHZiTml1SXBGaWx0ZXJTcmNNYXNrIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFY ICAgICAgSW5ldEFkZHJlc3MgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAg IFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiQSBi aXQgbWFzayB0aGF0IGlzIHRvIGJlIGFwcGxpZWQgdG8gdGhlIHNvdXJjZSBhZGRyZXNzIAogICAg ICAgICAgICBwcmlvciB0byBtYXRjaGluZy4gVGhpcyBtYXNrIGlzIG5vdCBuZWNlc3NhcmlseSB0 aGUgc2FtZSAKICAgICAgICAgICAgYXMgYSBzdWJuZXQgbWFzaywgYnV0IDEncyBiaXRzIG11c3Qg YmUgbGVmdG1vc3QgYW5kIAogICAgICAgICAgICBjb250aWd1b3VzLiIgCiAgIDo6PSB7IGR2Yk5p dUlwRmlsdGVyRW50cnkgMTEgfSAKICAgIAogICBkdmJOaXVJcEZpbHRlckRzdEFkZHJUeXBlIE9C SkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW5ldEFkZHJlc3NUeXBlIAogICAgICAgTUFY LUFDQ0VTUyAgcmVhZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAg REVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSB0eXBlIG9mIElQIGFkZHJlc3MgZm9yIHRoZSBk ZXN0aW5hdGlvbiBhZGRyZXNzLiIgCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyRW50cnkgMTIgfSAK IAogICBkdmJOaXVJcEZpbHRlckRzdEFkZHIgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAg ICBJbmV0QWRkcmVzcyAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAgU1RB VFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgZGVz dGluYXRpb24gSVAgYWRkcmVzcywgb3IgcG9ydGlvbiB0aGVyZW9mLCB0aGF0IGlzIAogICAgICAg ICAgICB0byBiZSBtYXRjaGVkIGZvciB0aGlzIGZpbHRlci4gVGhlIGRlc3RpbmF0aW9uIGFkZHJl c3MgaXMgCiAgICAgICAgICAgIGZpcnN0IG1hc2tlZCAoYW5kJ2VkKSBhZ2FpbnN0IGR2Yk5pdUlw RmlsdGVyRHN0TWFzayBiZWZvcmUgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0g RXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMzMgDAogICAgICAgICAgICAgICAg IERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAog CiAKICAgICAgICAgICAgYmVpbmcgY29tcGFyZWQgIHRvIHRoaXMgdmFsdWUuICBBIHZhbHVlIG9m IDAgZm9yIHRoaXMgIAogICAgICAgICAgICBvYmplY3QgYW5kIDAgZm9yIHRoZSBtYXNrIG1hdGNo ZXMgYWxsIElQIGFkZHJlc3Nlcy4iIAogICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5IDEzIH0g CiAgICAKICAgZHZiTml1SXBGaWx0ZXJEc3RNYXNrVHlwZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZ TlRBWCAgICAgIEluZXRBZGRyZXNzVHlwZSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRl IAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAg ICAgICJUaGUgdHlwZSBvZiBJUCBhZGRyZXNzIGZvciB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBt YXNrLiIgCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyRW50cnkgMTQgfSAKICAgIAogICBkdmJOaXVJ cEZpbHRlckRzdE1hc2sgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJbmV0QWRkcmVz cyAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVTICAgICAgY3Vy cmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJBIGJpdCBtYXNrIHRoYXQgaXMg dG8gYmUgYXBwbGllZCB0byB0aGUgZGVzdGluYXRpb24gCiAgICAgICAgICAgIGFkZHJlc3MgcHJp b3IgdG8gbWF0Y2hpbmcuIFRoaXMgbWFzayBpcyBub3QgbmVjZXNzYXJpbHkgCiAgICAgICAgICAg IHRoZSBzYW1lIGFzIGEgc3VibmV0IG1hc2ssIGJ1dCAxJ3MgYml0cyBtdXN0IGJlIGxlZnRtb3N0 IAogICAgICAgICAgICBhbmQgY29udGlndW91cy4iIAogICA6Oj0geyBkdmJOaXVJcEZpbHRlckVu dHJ5IDE1IH0gCiAgICAKICAgZHZiTml1SXBGaWx0ZXJQcm90b2NvbCBPQkpFQ1QtVFlQRSAKICAg ICAgIFNZTlRBWCBJbnRlZ2VyMzIgKDAuLjI1NikgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNy ZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAg ICAgICAgICAiVGhlIElQIHByb3RvY29sIHZhbHVlIHRoYXQgaXMgdG8gYmUgbWF0Y2hlZC4gRm9y IGV4YW1wbGU6IAogICAgICAgICAgICBpY21wIGlzIDEsIHRjcCBpcyA2LCB1ZHAgaXMgMTcuIEEg dmFsdWUgb2YgMjU2IG1hdGNoZXMgCiAgICAgICAgICAgIEFOWSBwcm90b2NvbC4iIAogICAgICAg REVGVkFMIHsgMjU2IH0gCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyRW50cnkgMTYgfSAKICAgIAog ICBkdmJOaXVJcEZpbHRlclNyY1BvcnRMb3cgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAg ICBJbnRlZ2VyMzIgKDAuLjY1NTM1KSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAog ICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAg ICJJZiBkdmJOaXVJcEZpbHRlclByb3RvY29sIGlzIHVkcCBvciB0Y3AsIHRoaXMgaXMgdGhlIAog ICAgICAgICAgICBpbmNsdXNpdmUgbG93ZXIgYm91bmQgb2YgdGhlIHRyYW5zcG9ydC1sYXllciBz b3VyY2UgcG9ydCAKICAgICAgICAgICAgcmFuZ2UgdGhhdCBpcyB0byBiZSBtYXRjaGVkLCBvdGhl cndpc2UgaXQgaXMgaWdub3JlZCAKICAgICAgICAgICAgZHVyaW5nIG1hdGNoaW5nLiIgCiAgICAg ICBERUZWQUwgeyAwIH0gCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyRW50cnkgMTcgfSAKICAgIAog ICBkdmJOaXVJcEZpbHRlclNyY1BvcnRIaWdoIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAg ICAgSW50ZWdlcjMyICgwLi42NTUzNSkgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAK ICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAg ICAiSWYgZHZiTml1SXBGaWx0ZXJQcm90b2NvbCBpcyB1ZHAgb3IgdGNwLCB0aGlzIGlzIHRoZSAK ICAgICAgICAgICAgaW5jbHVzaXZlIHVwcGVyIGJvdW5kIG9mIHRoZSB0cmFuc3BvcnQtbGF5ZXIg c291cmNlIHBvcnQgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBT ZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMzQgDAogICAgICAgICAgICAgICAgIERWQiBDYWJs ZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAKICAgICAg ICAgICAgcmFuZ2UgdGhhdCBpcyB0byBiZSBtYXRjaGVkLCBvdGhlcndpc2UgaXQgaXMgaWdub3Jl ZCAKICAgICAgICAgICAgZHVyaW5nIG1hdGNoaW5nLiIgCiAgICAgICBERUZWQUwgeyA2NTUzNSB9 IAogICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5IDE4IH0gCiAgICAKICAgZHZiTml1SXBGaWx0 ZXJEc3RQb3J0TG93IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW50ZWdlcjMyICgw Li42NTUzNSkgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiSWYgZHZiTml1SXBG aWx0ZXJQcm90b2NvbCBpcyB1ZHAgb3IgdGNwLCB0aGlzIGlzIHRoZSAKICAgICAgICAgICAgaW5j bHVzaXZlIGxvd2VyIGJvdW5kIG9mIHRoZSB0cmFuc3BvcnQtbGF5ZXIgZGVzdGluYXRpb24gCiAg ICAgICAgICAgIHBvcnQgcmFuZ2UgdGhhdCBpcyB0byBiZSBtYXRjaGVkLCBvdGhlcndpc2UgaXQg aXMgaWdub3JlZCAKICAgICAgICAgICAgZHVyaW5nIG1hdGNoaW5nLiIgCiAgICAgICBERUZWQUwg eyAwIH0gCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyRW50cnkgMTkgfSAKICAgIAogICBkdmJOaXVJ cEZpbHRlckRzdFBvcnRIaWdoIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW50ZWdl cjMyICgwLi42NTUzNSkgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNU QVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiSWYgZHZi Tml1SXBGaWx0ZXJQcm90b2NvbCBpcyB1ZHAgb3IgdGNwLCB0aGlzIGlzIHRoZSAKICAgICAgICAg ICAgaW5jbHVzaXZlIHVwcGVyIGJvdW5kIG9mIHRoZSB0cmFuc3BvcnQtbGF5ZXIgZGVzdGluYXRp b24gCiAgICAgICAgICAgIHBvcnQgcmFuZ2UgdGhhdCBpcyB0byBiZSBtYXRjaGVkLCBvdGhlcndp c2UgaXQgaXMgaWdub3JlZCAKICAgICAgICAgICAgZHVyaW5nIG1hdGNoaW5nLiIgCiAgICAgICBE RUZWQUwgeyA2NTUzNSB9IAogICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5IDIwIH0gCiAgICAK ICAgZHZiTml1SXBGaWx0ZXJBY3Rpb24gT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJ TlRFR0VSIHsgCiAgICAgICAgICAgICAgICAgICAgICAgZGlzY2FyZCgxKSwgCiAgICAgICAgICAg ICAgICAgICAgICAgYWNjZXB0KDIpLCAKICAgICAgICAgICAgICAgICAgICAgICBuYXQoMyksIAog ICAgICAgICAgICAgICAgICAgICAgIG5hcHQoNCksIAogICAgICAgICAgICAgICAgICAgICAgIHRv c21hcCg1KSAKICAgICAgICAgICAgICAgICAgIH0gCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNy ZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAg ICAgICAgICAiVGhpcyBpcyB0aGUgYWN0aW9uIHRvIGJlIHBlcmZvcm1lZCBpZiB0aGVyZSBpcyBh IG1hdGNoIAogICAgICAgICAgICBhZ2FpbnN0IHRoaXMgZmlsdGVyLiAgUG9zc2libGUgYWN0aW9u cyBhcmU6IAogICAgICAgICAgICBkaXNjYXJkIC0gRGlzY2FyZCB0aGUgcGFja2V0LiAKICAgICAg ICAgICAgYWNjZXB0ICAtIEFjY2VwdCB0aGUgcGFja2V0IGZvciBmdXJ0aGVyIHByb2Nlc3Npbmcg LyAgCiAgICAgICAgICAgICAgICAgICAgICBmb3J3YXJkaW5nLiAKICAgICAgICAgICAgbmF0ICAg ICAtIFBlcmZvcm0gbmV0d29yayBhZGRyZXNzIHRyYW5zbGF0aW9uIG9uIHRoaXMgIAogICAgICAg ICAgICAgICAgICAgICAgcGFja2V0LiAKICAgICAgICAgICAgICAgICAgICAgIFRoaXMgaXMgdXNl ZCB0byBpZGVudGlmeSBpbnRlcm5hbCBhZGRyZXNzZXMgdGhhdCAKICAgICAgICAgICAgICAgICAg ICAgIGNhbiBiZSBtYXBwZWQgdG8gZXh0ZXJuYWwgYWRkcmVzc2VzLiAKICAgICAgICAgICAgbmFw dCAgICAtIFBlcmZvcm0gbmV0d29yayBwb3J0IGFkZHJlc3MgdHJhbnNsYXRpb24gb24gdGhpcyAK ICAgICAgICAgICAgICAgICAgICAgIHBhY2tldC4gVGhpcyBpcyB1c2VkIHRvIGlkZW50aWZ5IGlu dGVybmFsIAogICAgICAgICAgICAgICAgICAgICAgYWRyZXNzZXMgdGhhdCBjYW4gYmUgbWFwcGVk IHRvIGFuIGV4dGVybmFsICAKICAgICAgICAgICAgICAgICAgICAgIGFkZHJlc3MvcG9ydC4gCiAg ClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAg ICAgICAgICAgICAgMzUgDAogICAgICAgICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVy ZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAKICAgICAgICAgICAgdG9zbWFwICAt IEFwcGx5IFRPUyB0byB0aGlzIHBhY2tldC4iIAogICAgICAgREVGVkFMIHsgZGlzY2FyZCB9IAog ICA6Oj0geyBkdmJOaXVJcEZpbHRlckVudHJ5IDIxIH0gCiAgICAKICAgZHZiTml1SXBGaWx0ZXJN YXRjaGVzIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyIAogICAgICAg TUFYLUFDQ0VTUyAgcmVhZC1vbmx5IAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAg IERFU0NSSVBUSU9OIAogICAgICAgICAgICJDb3VudHMgdGhlIG51bWJlciBvZiB0aW1lcyB0aGlz IGZpbHRlciB3YXMgbWF0Y2hlZC4gCiAgICAgICAgICAgIFRoaXMgb2JqZWN0IGlzIGluaXRpYWxp emVkIHRvIDAgYXQgYm9vdCwgb3IgYXQgcm93IAogICAgICAgICAgICBjcmVhdGlvbiwgYW5kIGlz IHJlc2V0IG9ubHkgdXBvbiByZWJvb3QuIiAKICAgOjo9IHsgZHZiTml1SXBGaWx0ZXJFbnRyeSAy MiB9IAogICAgCiAgIGR2Yk5pdUlwRmlsdGVyQ29udGludWUgT0JKRUNULVRZUEUgCiAgICAgICBT WU5UQVggICAgICBUcnV0aFZhbHVlIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUgCiAg ICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAg IklmIHRoaXMgdmFsdWUgaXMgc2V0IHRvIHRydWUgYW5kIGR2Yk5pdUlwRmlsdGVyQWN0aW9uIAog ICAgICAgICAgICBpcyBub3QgZGlzY2FyZCwgY29udGludWUgc2Nhbm5pbmcgYW5kIGFwcGx5aW5n IAogICAgICAgICAgICBtYXRjaGluZyBmaWx0ZXIgYWN0aW9ucy4iIAogICAgICAgREVGVkFMIHsg ZmFsc2UgfSAKICAgOjo9IHsgZHZiTml1SXBGaWx0ZXJFbnRyeSAyMyB9IAogICAgCiAgIGR2Yk5p dUlwRmlsdGVyQWN0aW9uUHRyIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW50ZWdl cjMyICgwLi4yMTQ3NDgzNjQ3KSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAg ICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJU aGlzIG9iamVjdCBpZGVudGlmaWVzIHRoZSBkdmJOaXVJcFRvc01hcFBvbGljeUlkIAogICAgICAg ICAgICBpbiBkdmJOaXVJcFRPU01hcFRhYmxlIHRoYXQgaXMgdG8gYmUgYXBwbGllZCBpZiAgCiAg ICAgICAgICAgIGR2Yk5pdUlwRmlsdGVyQWN0aW9uIGlzIHNldCB0byB0b3NNYXAuICAKICAgICAg ICAgICAgSWYgbm8gbWF0Y2hpbmcgcG9saWN5IGV4aXN0cywgdHJlYXQgYXMgaWYgCiAgICAgICAg ICAgIGR2Yk5pdUlwRmlsdGVyQWN0aW9uIHdlcmUgc2V0IHRvIGFjY2VwdCAoMSkuIAogICAgICAg ICAgICBJZiB0aGlzIG9iamVjdCBpcyBzZXQgdG8gdGhlIHZhbHVlIG9mIDAsIHRoZXJlIGlzIG5v IAogICAgICAgICAgICBtYXRjaGluZyBwb2xpY3ksIGFuZCBkdmJOaXVJcFRPU01hcFRhYmxlIE1V U1QgTk9UIGJlIAogICAgICAgICAgICBjb25zdWx0ZWQuIiAKICAgICAgIERFRlZBTCB7IDAgfSAK ICAgOjo9IHsgZHZiTml1SXBGaWx0ZXJFbnRyeSAyNCB9IAogICAgCiAgIC0tIEVuZCBvZiBJUCBm aWx0ZXIgdGFibGUgCiAgICAKICAgLS0gVE9TIE1hcCBUYWJsZSAKICAgIAogICBkdmJOaXVJcFRP U01hcFRhYmxlIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgU0VRVUVOQ0UgT0YgRHZi Tml1SXBUT1NNYXBFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAg ICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJB IFRhYmxlIHdoaWNoIG1hcHMgYmV0d2VlbiBhIHBvbGljeSBpZCAgCiAgICAgICAgICAgIChkdmJO aXVJcFRvc01hcFBvbGljeUlkKSBhbmQgYSBwb2xpY3kgdG8gYmUgYXBwbGllZC4gIFRoaXMgCiAg ICAgICAgICAgIHRhYmxlIGFwcGxpZXMgb25seSB0byB0aGUgVE9TIHdpdGhpbiB0aGUgSVAgaGVh ZGVyLiAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJl ciAyMDAwICAgICAgICAgICAgICAzNiAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdv cmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgICAgIFBv bGljeSBJRCAwIGlzIHJlc2VydmVkLiIgCiAgIDo6PSB7IGR2Yk5pdUlwRmlsdGVyIDMgfSAKICAg IAogICBkdmJOaXVJcFRPU01hcEVudHJ5IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAg RHZiTml1SXBUT1NNYXBFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAog ICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAg ICJUYWJsZSB1c2VkIHRvIGRlc2NyaWJlIFR5cGUgb2YgU2VydmljZSAoVE9TKSBiaXRzIAogICAg ICAgICAgICBwcm9jZXNzaW5nLiAKICAgIAogICAgICAgICAgICBUaGlzIHRhYmxlIGlzIGFuIGFk anVuY3QgdG8gdGhlIGR2Yk5pdUlwRmlsdGVyVGFibGUuIAogICAgICAgICAgICBFbnRyaWVzIGlu IHRoZSBsYXR0ZXIgdGFibGUgY2FuIHBvaW50IHRvIHNwZWNpZmljIHJvd3MgIAogICAgICAgICAg ICBpbiB0aGlzIChhbmQgb3RoZXIpdGFibGVzIGFuZCBjYXVzZSBzcGVjaWZpYyBhY3Rpb25zIHRv IAogICAgICAgICAgICBiZSB0YWtlbi4gIFRoaXMgdGFibGUgcGVybWl0cyB0aGUgbWFuaXB1bGF0 aW9uIG9mIHRoZSB2YWx1ZSAKICAgICAgICAgICAgb2YgdGhlIFR5cGUgb2YgU2VydmljZSBiaXRz IGluIHRoZSBJUCBoZWFkZXIgb2YgdGhlIG1hdGNoZWQgCiAgICAgICAgICAgIHBhY2tldCBhcyBm b2xsb3dzOiAKICAgICAgICAgICAgU2V0IHRoZSB0b3NCaXRzIG9mIHRoZSBwYWNrZXQgdG8gCiAg ICAgICAgICAgICh0b3NCaXRzICYgZHZiTml1SXBUb3NNYXBBbmRNYXNrKSB8IGR2Yk5pdUlwVG9z TWFwT3JNYXNrIAogICAgCiAgICAgICAgICAgIFRoaXMgY29uc3RydWN0IGFsbG93cyB5b3UgdG8g ZG8gYSBjbGVhciBhbmQgc2V0IG9mIGFsbCAKICAgICAgICAgICAgdGhlIFRPUyBiaXRzIGluIGEg ZmxleGlibGUgbWFubmVyLiIgCiAgICAgICBJTkRFWCB7IGR2Yk5pdUlwVG9zTWFwSW5kZXggfSAK ICAgOjo9IHsgZHZiTml1SXBUT1NNYXBUYWJsZSAxIH0gCiAgICAKICAgRHZiTml1SXBUT1NNYXBF bnRyeSA6Oj0gU0VRVUVOQ0UgeyAKICAgICAgIGR2Yk5pdUlwVG9zTWFwSW5kZXggICAgIFVuc2ln bmVkMzIsICAKICAgICAgIGR2Yk5pdUlwVG9zTWFwUG9saWN5SWQgIFVuc2lnbmVkMzIsIAogICAg ICAgZHZiTml1SXBUb3NNYXBTdGF0dXMgICAgUm93U3RhdHVzLCAKICAgICAgIGR2Yk5pdUlwVG9z TWFwQW5kTWFzayAgIE9DVEVUIFNUUklORyAoU0laRSAoMSkpLCAKICAgICAgIGR2Yk5pdUlwVG9z TWFwT3JNYXNrICAgIE9DVEVUIFNUUklORyAoU0laRSAoMSkpIAogICB9IAogICAgCiAgIGR2Yk5p dUlwVG9zTWFwSW5kZXggT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBVbnNpZ25lZDMy IAogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFUVVMgICAgICBj dXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gIAogICAgICAgICAgICJUaGUgdW5pcXVlIGluZGV4 IGZvciB0aGlzIHJvdy4gIFRoZXJlIGFyZSBubyBvcmRlcmluZyAKICAgICAgICAgICAgcmVxdWly ZW1lbnRzIGZvciB0aGlzIHRhYmxlIGFuZCBhbnkgdmFsaWQgaW5kZXggbWF5IGJlIAogICAgICAg ICAgICBzcGVjaWZpZWQuIiAKICAgOjo9IHsgZHZiTml1SXBUT1NNYXBFbnRyeSAxIH0gCiAgICAK ICAgZHZiTml1SXBUb3NNYXBQb2xpY3lJZCBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAg IFVuc2lnbmVkMzIgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gIAogICAgICAgICAgICJUaGUgdW5pcXVl IGluZGV4IGZvciB0aGlzIHJvdy4gIFRoZXJlIGFyZSBubyBvcmRlcmluZyAKICAgICAgICAgICAg cmVxdWlyZW1lbnRzIGZvciB0aGlzIHRhYmxlIGFuZCBhbnkgdmFsaWQgaW5kZXggbWF5IGJlIAog ICAgICAgICAgICBzcGVjaWZpZWQuICBUaGlzIGluZGV4IGlzIHVzZWQgYnkgZHZiTml1SXBGaWx0 ZXJQb2xpY3lJZCBhcyAKICAgICAgICAgICAgdGhlIHBvaW50ZXIgdG8gdGhlIFRPUyBtYXBwaW5n IHRvIGJlIHBlcmZvcm1lZC4iIAogICA6Oj0geyBkdmJOaXVJcFRPU01hcEVudHJ5IDIgfSAKICAK VmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAg ICAgICAgICAgICAzNyAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJm YWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgCiAgIGR2Yk5pdUlwVG9zTWFw U3RhdHVzIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgUm93U3RhdHVzIAogICAgICAg TUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAg ICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSBvYmplY3QgdXNlZCB0byBjcmVhdGUgYW5k IGRlbGV0ZSBlbnRyaWVzIGluIHRoaXMgCiAgICAgICAgICAgIHRhYmxlLiBBIHJvdyBjcmVhdGVk IGJ5IHNwZWNpZnlpbmcganVzdCB0aGlzIG9iamVjdCAKICAgICAgICAgICAgcmVzdWx0cyBpbiBh IHJvdyB3aGljaCBzcGVjaWZpZXMgbm8gY2hhbmdlIHRvIHRoZSBUT1MgCiAgICAgICAgICAgIGJp dHMuICAgQSByb3cgbWF5IGJlIGNyZWF0ZWQgdXNpbmcgZWl0aGVyIHRoZSBjcmVhdGUtYW5kLWdv IAogICAgICAgICAgICBvciBjcmVhdGUtYW5kLXdhaXQgcGFyYWRpZ21zLiBUaGVyZSBpcyBubyBy ZXN0cmljdGlvbiBvbiAKICAgICAgICAgICAgdGhlIGFiaWxpdHkgdG8gY2hhbmdlIHZhbHVlcyBp biB0aGlzIHJvdyB3aGlsZSB0aGUgcm93IGlzIAogICAgICAgICAgICBhY3RpdmUuIiAKICAgOjo9 IHsgZHZiTml1SXBUT1NNYXBFbnRyeSAzIH0gCiAgICAKICAgZHZiTml1SXBUb3NNYXBBbmRNYXNr IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgT0NURVQgU1RSSU5HIChTSVpFICgxKSkg CiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJl bnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyB2YWx1ZSBpcyBiaXR3aXNl IEFORCdkIHdpdGggdGhlIG1hdGNoZWQgIHBhY2tldCdzIAogICAgICAgICAgIFRPUyBiaXRzLiIg CiAgICAgICBERUZWQUwgeyAnZmYnaCB9IAogICA6Oj0geyBkdmJOaXVJcFRPU01hcEVudHJ5IDQg fSAKICAgIAogICBkdmJOaXVJcFRvc01hcE9yTWFzayBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRB WCAgICAgIE9DVEVUIFNUUklORyAoU0laRSAoMSkpIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1j cmVhdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAg ICAgICAgICAgIkFmdGVyIGJpdHdpc2UgQU5EJ2luZyB3aXRoIHRoZSBhYm92ZSBiaXRzLCB0aGUg cGFja2V0J3MgCiAgICAgICAgICAgIFRPUyBiaXRzIGFyZSBiaXR3aXNlIE9SJ2Qgd2l0aCB0aGVz ZSBiaXRzLiIgCiAgICAgICBERUZWQUwgeyAnMDAnaCB9IAogICA6Oj0geyBkdmJOaXVJcFRPU01h cEVudHJ5IDUgfSAKICAgIAogICAtLSBFbmQgb2YgVE9TIE1hcCB0YWJsZSAKICAgIAogICAtLSA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0gCiAgIC0tID0gIE5BVCBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPSAKICAgLS0gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IAogICAgCiAgIC0tIE5BVCBhc3NpZ25t ZW50IHRhYmxlIAogICAgCiAgIGR2Yk5pdU5hdFRhYmxlIE9CSkVDVC1UWVBFIAogICAgICAgU1lO VEFYICAgICAgU0VRVUVOQ0UgT0YgRHZiTml1TmF0RW50cnkgCiAgICAgICBNQVgtQUNDRVNTICBu b3QtYWNjZXNzaWJsZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQ VElPTiAKICAgICAgICAgICAiVGhpcyB0YWJsZSBpcyB1c2VkIHRvIGxpc3QgZXh0ZXJuYWwgSVAg YWRkcmVzc2VzIGF2YWlsYWJsZSAKICAgICAgICAgICAgZm9yIGFzc2lnbm1lbnQgdG8gaW50ZXJu YWwgSVAgYWRkcmVzc2VzLiAgVGhlIGZpbHRlciB0YWJsZSAgCiAgICAgICAgICAgIGlzIHVzZWQg dG8gaWRlbnRpZnkgaW50ZXJuYWwgYWRkcmVzc2VzIHRoYXQgcmVxdWlyZSBOQVQgIAogICAgICAg ICAgICBiZWZvcmUgZW50ZXJpbmcgdGhlIGV4dGVybmFsIGRvbWFpbiAodXBzdHJlYW0pLiAgSW4g dGhlIAogICAgICAgICAgICBkb3duc3RyZWFtIGRpcmVjdGlvbiBOQVQgKGludmVyc2Ugb2YgdGhl IE5BVCBhcHBsaWVkIGluIHRoZSAgCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0g RXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgMzggDAogICAgICAgICAgICAgICAg IERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAog CiAKICAgICAgICAgICAgdXBzdHJlYW0pIGlzIGFwcGxpZWQgYmVmb3JlIGFwcGx5aW5nIHRoZSBJ UCBmaWx0ZXIgdGFibGUuICAgCiAgICAgICAgICAgIE5BVCBhc3NpZ25tZW50IGFsZ29yaXRoaW1z IGFyZSB2ZW5kb3IgZGVwZW5kYW50LiAgV2hlbiBhbiAgCiAgICAgICAgICAgIGV4dGVybmFsIElQ IGFkZHJlc3MgaXMgbm8gbG9uZ2VyIGFzc2lnbmVkIHRvIGFuIElQIGFkZGVzcywgIAogICAgICAg ICAgICBkdmJOaXVOYXRJbnRJcCBzaG91bGQgYmUgYWxsIDAncy4gSWYgdGhlcmUgYXJlIG5vIGZy ZWUgIAogICAgICAgICAgICBleHRlcm5hbCBhZGRyZXNzZXMgdGhlIHBhY2tldCByZXF1aXJpbmcg dHJhbnNsYXRpb24gc2hvdWxkIAogICAgICAgICAgICBiZSBkcm9wcGVkLiAKICAgIAogICAgICAg ICAgICBOQVBUIGlzIG5vdCBhcHBsaWNhYmxlIHRvIG11bHRpY2FzdCBwYWNrZXRzLiIgCiAgIDo6 PSB7IGR2Yk5pdU5hdCAxIH0gCiAgICAKICAgZHZiTml1TmF0RW50cnkgT0JKRUNULVRZUEUgCiAg ICAgICBTWU5UQVggICAgICBEdmJOaXVOYXRFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1h Y2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9O IAogICAgICAgICAgICJBIHJvdyBzaG91bGQgYmUgY3JlYXRlZCBmb3IgZWFjaCBleHRlcm5hbCBJ UCBhZGRyZXNzIAogICAgICAgICAgICBhdmFpbGFibGUgZm9yIHRyYW5zbGF0aW9uLiAgV2hlbiBh biBpbnRlcm5hbCBhZGRyZXNzIGlzIAogICAgICAgICAgICBhc3NpZ25lbmVkIHRvIGFuIGV4dGVy bmFsIGFkZHJlc3MsIGR2Yk5pdU5hdEludElwIHdpbGwgIAogICAgICAgICAgICBjb250YWluZWQg dGhlIG1hcHBlZCBpbnRlcm5hbCBhZGRyZXNzLiIgCiAgICAgICBJTkRFWCB7IGR2Yk5pdU5hdEV4 dElwVHlwZSwgZHZiTml1TmF0RXh0SXAgfSAKICAgOjo9IHsgZHZiTml1TmF0VGFibGUgMSB9IAog ICAgCiAgIER2Yk5pdU5hdEVudHJ5IDo6PSBTRVFVRU5DRSB7ICAKICAgICAgIGR2Yk5pdU5hdEV4 dElwVHlwZSBJbmV0QWRkcmVzc1R5cGUsIAogICAgICAgZHZiTml1TmF0RXh0SXAgICAgIEluZXRB ZGRyZXNzLCAKICAgICAgIGR2Yk5pdU5hdEludElwVHlwZSBJbmV0QWRkcmVzc1R5cGUsIAogICAg ICAgZHZiTml1TmF0SW50SXAgICAgIEluZXRBZGRyZXNzLCAKICAgICAgIGR2Yk5pdU5hdFN0YXR1 cyAgICBSb3dTdGF0dXMgCiAgIH0gCiAgICAKICAgZHZiTml1TmF0RXh0SXBUeXBlIE9CSkVDVC1U WVBFIAogICAgICAgU1lOVEFYICAgICAgSW5ldEFkZHJlc3NUeXBlIAogICAgICAgTUFYLUFDQ0VT UyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVT Q1JJUFRJT04gCiAgICAgICAgICAgIlRoZSB0eXBlIG9mIHRoZSBleHRlcm5hbCBJUCBhZGRyZXNz IGF2YWlsYWJsZSBmb3IgTkFUICAKICAgICAgICAgICAgYXNzaWdubWVudCIgCiAgIDo6PSB7IGR2 Yk5pdU5hdEVudHJ5IDEgfSAKICAgIAogICBkdmJOaXVOYXRFeHRJcCBPQkpFQ1QtVFlQRSAKICAg ICAgIFNZTlRBWCAgICAgIEluZXRBZGRyZXNzIChTSVpFICgxLi42NCkpIAogICAgICAgTUFYLUFD Q0VTUyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAg REVTQ1JJUFRJT04gCiAgICAgICAgICAgIkFuIGV4dGVybmFsIElQIGFkZHJlc3MgYXZhaWxhYmxl IGZvciBOQVQgYXNzaWdubWVudCIgCiAgIDo6PSB7IGR2Yk5pdU5hdEVudHJ5IDIgfSAKICAgIAog ICBkdmJOaXVOYXRJbnRJcFR5cGUgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJbmV0 QWRkcmVzc1R5cGUgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSB0eXBlIG9m IHRoZSBpbnRlcm5hbCBJUCBhZGRyZXNzIGFzc2lnbmVkIGZvciBOQVQuIiAKICAKVmFsZW50aW5l ICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAg ICAzOSAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQg TUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICA6Oj0geyBkdmJOaXVOYXRFbnRyeSAzIH0gCiAg ICAKICAgZHZiTml1TmF0SW50SXAgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJbmV0 QWRkcmVzcyAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seSAKICAgICAgIFNUQVRVUyAgICAg IGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlIGludGVybmFsIElQ IGFkZHJlc3MgYXNzaWduZWQgdG8gdGhlIGV4dGVybmFsIElQICAKICAgICAgICAgICAgYWRkcmVz cy4gSWYgbm8gYWRkcmVzcyBpcyBhc3NpZ25lZCB0aGlzIHdpbGwgYmUgYWxsIDAncy4iIAogICA6 Oj0geyBkdmJOaXVOYXRFbnRyeSA0IH0gCiAgICAKICAgZHZiTml1TmF0U3RhdHVzIE9CSkVDVC1U WVBFIAogICAgICAgU1lOVEFYICAgICAgUm93U3RhdHVzIAogICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04g CiAgICAgICAgICAgIlRoaXMgY29udHJvbHMgYW5kIHJlZmxlY3RzIHRoZSBzdGF0dXMgb2YgdGhl IHJvdy4gCiAgICAgICAgICAgIFJvd3MgY2FuIGJlIGNyZWF0ZWQgYnkgdXNpbmcgYm90aCBjcmVh dGVBbmRHbyBhbmQgCiAgICAgICAgICAgIGNyZWF0ZUFuZFdhaXQuICBSb3dzIGNhbiBiZSBtb2Rp ZmllZC9kZWxldGVkIE9OTFkgaWYgdGhlIAogICAgICAgICAgICBkdmJOaXVOYXRJbnRJcCBpcyBh bGwgMCdzLiAgbm90SW5TZXJ2aWNlIGNhbiBiZSBhcHBsaWVkIHRvICAKICAgICAgICAgICAgYSBy b3cgd2hpY2ggY3VycmVudGx5IGhhcyBkdmJOaXVOYXRJbnRJcCBhc3NpZ25lZCwgaW4gdGhpcyAg CiAgICAgICAgICAgIGNhc2Ugd2hlbiBkdmJOaXVOYXRJbnRJcCBiZWNvbWUgZnJlZSAoYWxsIDAn cykgdGhlICAKICAgICAgICAgICAgYXNzb2NpYXRlZCBkdmJOaXVOYXRFeHRJcCBjYW5ub3QgYmUg dXNlZCBmb3IgZnVydGhlciAgCiAgICAgICAgICAgIGFzc2lnbWVudHMuIiAKICAgOjo9IHsgZHZi Tml1TmF0RW50cnkgNSB9IAogICAgCiAgIC0tIEVuZCBvZiBOQVQgdGFibGUgCiAgICAKICAgIAog ICAtLSA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0gCiAgIC0tID0gIE5BUFQgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPSAKICAgLS0gPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IAogICAgCiAgIGR2Yk5pdU5h cHRBZGRyVHlwZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIEluZXRBZGRyZXNzVHlw ZSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSB0eXBlIG9mIGV4dGVybmFs IElQIGFkZHJlc3MgdG8gYmUgdXNlZCBmb3IgTkFQVC4iIAogICA6Oj0geyBkdmJOaXVOYXB0IDEg fSAKICAgIAogICBkdmJOaXVOYXB0QWRkciBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAg IEluZXRBZGRyZXNzIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNUQVRV UyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlIGV4dGVy bmFsIElQIGFkZHJlc3MgdG8gYmUgdXNlZCBmb3IgTkFQVC4gCiAgICAgICAgICAgIFRoZSBmaWx0 ZXIgdGFibGUgaXMgdXNlZCB0byBpZGVudGlmeSBpbnRlcm5hbCAKICAgICAgICAgICAgYWRkcmVz c2VzIHRoYXQgcmVxdWlyZSBOQVBUIGJlZm9yZSBlbnRlcmluZyB0aGUgCiAgICAgICAgICAgIGV4 dGVybmFsIGRvbWFpbiAodXBzdHJlYW0pLiAgSW4gdGhlIGRvd25zdHJlYW0gZGlyZWN0aW9uICAK ICAgICAgICAgICAgTkFQVCAoaW52ZXJzZSBvZiB0aGUgTkFQVCBhcHBsaWVkIGluIHRoZSB1cHN0 cmVhbSkgaXMgIAogICAgICAgICAgICBhcHBsaWVkIGJlZm9yZSBhcHBseWluZyB0aGUgSVAgZmls dGVyIHRhYmxlLiAgTkFQVCAgCiAgICAgICAgICAgIGFzc2lnbm1lbnQgYWxnb3JpdGhpbXMgYXJl IHZlbmRvciBkZXBlbmRhbnQuICBUaGUgdmFsdWUgb2YgIAogIApWYWxlbnRpbmUgICAgICAgSW5m b3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDQwIAwKICAg ICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92 ZW1iZXIgMjAwMCAKIAogCiAgICAgICAgICAgIGFsbCAwJ3Mgc3BlY2lmaWVzIHRoYXQgTkFQVCBp cyBub3QgYXZhaWxhYmxlIGFuZCB0aGUgcGFja2V0ICAKICAgICAgICAgICAgcmVxdWlyaW5nIGl0 IHNob3VsZCBiZSBkaXNjYXJkZWQuICBBIHZhbHVlIHdpdGggYWxsIGJpdHMgIAogICAgICAgICAg ICBzZXQgdG8gMSBzcGVjaWZpZXMgdGhhdCBOQVBUIHdpbGwgdXNlIHRoZSBJUCBhZGRyZXNzICAK ICAgICAgICAgICAgYXNzaWduZWQgdG8gdGhlIEhGQyBpbnRlcmZhY2UuIAogICAgCiAgICAgICAg ICAgIE5BUFQgaXMgbm90IGFwcGxpY2FibGUgdG8gbXVsdGljYXN0IHBhY2tldHMuIAogICAgCiAg ICAgICAgICAgIEF0IGluaXRpYWwgc3RhcnR1cCB0aGlzIG9iamVjdCBoYXMgdGhlIGRlZmF1bHQg dmFsdWUgb2YgCiAgICAgICAgICAgIGFsbCAwJ3MiIAogICA6Oj0geyBkdmJOaXVOYXB0IDIgfSAK ICAgIAogICAtLSBOQVBUIGFzc2lnbm1lbnQgdGFibGUgCiAgICAKICAgZHZiTml1TmFwdFRhYmxl IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgU0VRVUVOQ0UgT0YgRHZiTml1TmFwdEVu dHJ5IAogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFUVVMgICAg ICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoaXMgdGFibGUgbGlz dHMgdGhlIGN1cnJlbnQgaW50ZXJuYWwvZXh0ZXJuYWwgcG9ydCAKICAgICAgICAgICAgYXNzaWdu bWVudHMuIFRoZSBOQVBUIGFzc2lnbm1lbnQgYWxnb3JpdGhpbXMgdXNlZCBmb3IgcG9ydCAgCiAg ICAgICAgICAgIGFzc2lnbm1lbnRzIGFyZSB2ZW5kb3IgZGVwZW5kYW50LiIgCiAgIDo6PSB7IGR2 Yk5pdU5hcHQgMyB9IAogICAgCiAgIGR2Yk5pdU5hcHRFbnRyeSBPQkpFQ1QtVFlQRSAKICAgICAg IFNZTlRBWCAgICAgIER2Yk5pdU5hcHRFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nl c3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAog ICAgICAgICAgICJBIHJvdyBzaG91bGQgYmUgY3JlYXRlZCBmb3IgZWFjaCBpbnRlcm5hbCB0byBl eHRlcm5hbCBwb3J0IAogICAgICAgICAgICBtYXBwaW5nLiAgRWFjaCByb3cgY29udGFpbnMgdGhl IGludGVybmFsIGFuZCBleHRlcm5hbCBwb3J0cyAKICAgICAgICAgICAgdXNlZCBpbiB0aGUgbWFw cGluZywgYW5kIHRoZSBpbnRlcm5hbCBJUCBhZGRyZXNzIG9mIHRoZSAKICAgICAgICAgICAgaG9z dCBiZWluZyBtYXBwZWQuICBXaGVuIHRoZSBhc3NpZ25tZW50IGlzIG5vIGxvbmdlciAgCiAgICAg ICAgICAgIHJlcXVpcmVkIHRoZSByb3cgc2hvdWxkIGJlIGRlbGV0ZWQuIiAKICAgICAgIElOREVY IHsgZHZiTml1TmFwdEV4dFBvcnQgfSAKICAgOjo9IHsgZHZiTml1TmFwdFRhYmxlIDEgfSAKICAg IAogICBEdmJOaXVOYXB0RW50cnkgOjo9IFNFUVVFTkNFIHsgCiAgICAgICBkdmJOaXVOYXB0RXh0 UG9ydCAgIEludGVnZXIzMiwgCiAgICAgICBkdmJOaXVOYXB0SW50UG9ydCAgIEludGVnZXIzMiwg CiAgICAgICBkdmJOaXVOYXB0SW50SXBUeXBlIEluZXRBZGRyZXNzVHlwZSwgCiAgICAgICBkdmJO aXVOYXB0SW50SXAgICAgIEluZXRBZGRyZXNzIAogICB9IAogICAgCiAgIGR2Yk5pdU5hcHRFeHRQ b3J0IE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW50ZWdlcjMyICgxLi42NTUzNSkg CiAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZSAKICAgICAgIFNUQVRVUyAgICAgIGN1 cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlIGV4dGVybmFsIHBvcnQg YXNzaWduZWQgdG8gdGhlIGludGVybmFsIHBvcnQvSVAgCiAgICAgICAgICAgIEFkZHJlc3MuIiAK ICAgOjo9IHsgZHZiTml1TmFwdEVudHJ5IDEgfSAKICAgIAogICBkdmJOaXVOYXB0SW50UG9ydCBP QkpFQ1QtVFlQRSAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNl cHRlbWJlciAyMDAwICAgICAgICAgICAgICA0MSAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxl IE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAg U1lOVEFYICAgICAgSW50ZWdlcjMyICgxLi42NTUzNSkgCiAgICAgICBNQVgtQUNDRVNTICByZWFk LW9ubHkgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAg ICAgICAgICAgIlRoZSBpbnRlcm5hbCBwb3J0IHRoYXQgcmVxdWlyZWQgbWFwcGluZyB0byB0aGUg ZXh0ZXJuYWwgCiAgICAgICAgICAgIHBvcnQuIiAKICAgOjo9IHsgZHZiTml1TmFwdEVudHJ5IDIg fSAKICAgIAogICBkdmJOaXVOYXB0SW50SXBUeXBlIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFY ICAgICAgSW5ldEFkZHJlc3NUeXBlIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5IAogICAg ICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJU aGUgaW50ZXJuYWwgSVAgYWRkcmVzcyB0eXBlLiIgCiAgIDo6PSB7IGR2Yk5pdU5hcHRFbnRyeSAz IH0gCiAKICAgZHZiTml1TmFwdEludElwIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAg SW5ldEFkZHJlc3MgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkgCiAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRoZSBpbnRlcm5h bCBJUCBhZGRyZXNzIG9mIHRoZSBob3N0IHRvIHdoaWNoIHRoZSBwb3J0ICAKICAgICAgICAgICAg bWFwcGluZyBpcyBiZWluZyBhcHBsaWVkLiIgCiAgIDo6PSB7IGR2Yk5pdU5hcHRFbnRyeSA0IH0g CiAgICAKICAgLS0gRW5kIG9mIE5BUFQgdGFibGUgCiAgICAKICAgLS0gPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IAogICAtLSA9 ICBFdGhlcm5ldCBGaWx0ZXJzIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgID0gCiAgIC0tID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PSAKICAgIAogICBkdmJOaXVFdGhlcm5ldEZpbHRlckVuYWJsZSAK ICAgIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSU5URUdFUiB7IAogICAgICAgICAg ICAgICAgICAgICAgIGVuYWJsZWQoMSksIAogICAgICAgICAgICAgICAgICAgICAgIGNvdW50SGl0 cygyKSwgCiAgICAgICAgICAgICAgICAgICAgICAgZGlzYWJsZWQoMykgCiAgICAgICAgICAgICAg ICAgICB9IAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNUQVRVUyAgICAg IGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyBjb250cm9scyB0 aGUgRXRoZXJuZXQgZmlsdGVyIHRhYmxlLiAKICAgICAgICAgICAgICAgIGVuYWJsZSAgICAgLSBF bmFibGVzIHRoZSBFdGhlcm5ldCBmaWx0ZXIgdGFibGUuIAogICAgICAgICAgICAgICAgY291bnRI aXRzICAtIFRoaXMgb3B0aW9uIGlzIHVzZWQgdG8gZGVidWcgdGhlIGZpbHRlciAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0YWJsZS4gIEl0IGFsbG93cyBmcmFtZXNzIHRvIGJlIGNoZWNr ZWQgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWdhaW5zdCB0aGUgZmlsdGVyIHRhYmxl IGFuZCBpbmNyZW1lbnRzIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdUV0aGVy bmV0RmlsdGVyTWF0Y2hlcyBmb3IgYSBtYXRjaGluZyAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBmaWx0ZXIsIGJ1dCBBTEwgZnJhbWVzIEFSRSBBTExPV0VEIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRIUk9VR0guICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBkaXNhYmxl ZCAgIC0gRGlzYWJsZXMgRXRoZXJuZXQgZmlsdGVyaW5nLCBhbGwgZnJhbWVzIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGFyZSBhbGxvd2VkIHRocm91Z2guIAogICAgCiAgICAgICAgICAg IEF0IGluaXRpYWwgc3RhcnR1cCB0aGlzIG9iamVjdCBoYXMgdGhlIGRlZmF1bHQgdmFsdWUgb2Yg CiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAw MCAgICAgICAgICAgICAgNDIgDAogICAgICAgICAgICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIElu dGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAyMDAwIAogCiAKICAgICAgICAgICAgZGlzYWJs ZWQoMykuIiAKICAgOjo9IHsgZHZkTml1RXRoRmlsdGVyIDEgfSAKICAgIAogICBkdmJOaXVFdGhl cm5ldEZpbHRlclRhYmxlIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgU0VRVUVOQ0Ug T0YgRHZiTml1RXRoZXJuZXRGaWx0ZXJFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nl c3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAog ICAgICAgICAgICJBIGxpc3Qgb2YgZmlsdGVycyB0byBhcHBseSB0byBFdGhlcm5ldCB0eXBlIGZy YW1lcyB0byAKICAgICAgICAgICAgY29udHJvbCB0aGUgdHlwZXMgb2YgdXBwZXIgbGF5ZXIgcHJv dG9jb2xzIHRoYXQgY2FuIGJlIAogICAgICAgICAgICB0cmFuc3BvcnRlZC4gIFRoZSBFdGhlclR5 cGUvTExDIGZpZWxkIGlzIGV4YW1pbmVkIGFuZCAKICAgICAgICAgICAgdGhlIGZpbHRlciB0YWJs ZSBpcyBjaGVja2VkIHRvIHNlZSBpZiB0aGVyZSBpcyBhIGZpbHRlciAKICAgICAgICAgICAgZm9y IHRoZSBwcm90b2NvbC4gIElmIG5vIG1hdGNoIGlzIGZvdW5kIHRoZSBmcmFtZSBpcyAKICAgICAg ICAgICAgZGlzY2FyZGVkLCBvdGhlcndpc2UgdGhlIGZpbHRlciBhY3Rpb24gaXMgcGVyZm9ybWVk LiAKICAgIAogICAgICAgICAgICBUaGUgZmlsdGVyIHRhYmxlIGRvZXMgbm90IGhhdmUgdG8gYmUg b3JkZXJlZCBhcyB0aGVyZSAKICAgICAgICAgICAgY2FuIGJlIG9ubHkgb25lIHBvc3NpYmxlIG1h dGNoLiIgCiAgIDo6PSB7IGR2ZE5pdUV0aEZpbHRlciAyIH0gCiAgICAKICAgZHZiTml1RXRoZXJu ZXRGaWx0ZXJFbnRyeSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIER2Yk5pdUV0aGVy bmV0RmlsdGVyRW50cnkgCiAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZSAKICAgICAg IFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiRGVz Y3JpYmVzIGEgZmlsdGVyIHRvIGFwcGx5IHRvIEV0aGVybmV0IGZyYW1lIHJlY2VpdmVkIG9uIGEg CiAgICAgICAgICAgIHNwZWNpZmllZCBpbnRlcmZhY2UuICBUaGUgZHZiTml1RXRoZXJuZXRGaWx0 ZXJQcm90b2NvbCBpbiAgCiAgICAgICAgICAgIHRoaXMgdGFibGUgbXVzdCBtYXRjaCBpdHMgcmVz cGVjdGl2ZSBmaWVsZHMgaW4gdGhlIGZyYW1lIAogICAgICAgICAgICBmb3IgYW55IGdpdmVuIGZp bHRlciB0byBtYXRjaC4iIAogICAgICAgICAgICBJTkRFWCB7IGR2Yk5pdUV0aGVybmV0RmlsdGVy SW5kZXggfSAKICAgOjo9IHsgZHZiTml1RXRoZXJuZXRGaWx0ZXJUYWJsZSAxIH0gCiAgICAKICAg RHZiTml1RXRoZXJuZXRGaWx0ZXJFbnRyeSA6Oj0gU0VRVUVOQ0UgeyAKICAgICAgIGR2Yk5pdUV0 aGVybmV0RmlsdGVySW5kZXggICAgICAgIFVuc2lnbmVkMzIsIAogICAgICAgZHZiTml1RXRoZXJu ZXRGaWx0ZXJTdGF0dXMgICAgICAgUm93U3RhdHVzLCAKICAgICAgIGR2Yk5pdUV0aGVybmV0Rmls dGVySWZJbmRleCAgICAgIEludGVyZmFjZUluZGV4T3JaZXJvLCAKICAgICAgIGR2Yk5pdUV0aGVy bmV0RmlsdGVyRXRoZXJUeXBlICAgIElOVEVHRVIsIAogICAgICAgZHZiTml1RXRoZXJuZXRGaWx0 ZXJQcm90b2NvbCAgICAgSW50ZWdlcjMyLCAKICAgICAgIGR2Yk5pdUV0aGVybmV0RmlsdGVyQWN0 aW9uICAgICAgIElOVEVHRVIsIAogICAgICAgZHZiTml1RXRoZXJuZXRGaWx0ZXJNYXRjaGVzICAg ICAgQ291bnRlcjMyIAogICB9IAogICAgCiAgIGR2Yk5pdUV0aGVybmV0RmlsdGVySW5kZXggT0JK RUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBVbnNpZ25lZDMyIAogICAgICAgTUFYLUFDQ0VT UyAgbm90LWFjY2Vzc2libGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVT Q1JJUFRJT04gIAogICAgICAgICAgICJUaGUgdW5pcXVlIGluZGV4IGZvciB0aGlzIHJvdy4gIFRo ZXJlIGFyZSBubyBvcmRlcmluZyAKICAgICAgICAgICAgcmVxdWlyZW1lbnRzIGZvciB0aGlzIHRh YmxlIGFuZCBhbnkgdmFsaWQgaW5kZXggbWF5IGJlIAogICAgICAgICAgICBzcGVjaWZpZWQuIiAK ICAgOjo9IHsgZHZiTml1RXRoZXJuZXRGaWx0ZXJFbnRyeSAxIH0gCiAgICAgICAgIAogICBkdmJO aXVFdGhlcm5ldEZpbHRlclN0YXR1cyBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIFJv d1N0YXR1cyAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRl bWJlciAyMDAwICAgICAgICAgICAgICA0MyAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5l dHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgTUFY LUFDQ0VTUyAgcmVhZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAg REVTQ1JJUFRJT04gCiAgICAgICAgICAgIkNvbnRyb2xzIGFuZCByZWZsZWN0cyB0aGUgc3RhdHVz IG9mIHJvd3MgaW4gdGhpcyAKICAgICAgICAgICAgdGFibGUuICBDcmVhdGlvbiBvZiB0aGUgcm93 cyBtYXkgYmUgZG9uZSB2aWEgZWl0aGVyICAKICAgICAgICAgICAgY3JlYXRlLWFuZC13YWl0IG9y IGNyZWF0ZS1hbmQtZ28sIGJ1dCB0aGUgZmlsdGVyIGlzICAKICAgICAgICAgICAgbm90IGFwcGxp ZWQgdW50aWwgdGhpcyBvYmplY3QgaXMgc2V0IHRvIChvciBjaGFuZ2VzIHRvKSAKICAgICAgICAg ICAgYWN0aXZlLiBUaGVyZSBpcyBubyByZXN0cmljdGlvbiBpbiBjaGFuZ2luZyBhbnkgb2JqZWN0 IAogICAgICAgICAgICBpbiBhIHJvdyB3aGlsZSB0aGlzIG9iamVjdCBpcyBzZXQgdG8gYWN0aXZl LiIgCiAgIDo6PSB7IGR2Yk5pdUV0aGVybmV0RmlsdGVyRW50cnkgMiB9IAogICAgCiAgIGR2Yk5p dUV0aGVybmV0RmlsdGVySWZJbmRleCBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAgIElu dGVyZmFjZUluZGV4T3JaZXJvIAogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUgCiAgICAg ICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgIlRo ZSBlbnRyeSBpbnRlcmZhY2UgdG8gd2hpY2ggdGhpcyBmaWx0ZXIgYXBwbGllcy4gVGhlIAogICAg ICAgICAgICB2YWx1ZSBjb3JyZXNwb25kcyB0byBpZkluZGV4IGZvciBlaXRoZXIgYSBDQVRWIE1B QyBvciAKICAgICAgICAgICAgYW5vdGhlciBuZXR3b3JrIGludGVyZmFjZS4gSWYgdGhlIHZhbHVl IGlzIHplcm8sIHRoZSAKICAgICAgICAgICAgZmlsdGVyIGFwcGxpZXMgdG8gYWxsIGludGVyZmFj ZXMuIERlZmF1bHQgdmFsdWUgaW4gTklVcyAKICAgICAgICAgICAgaXMgdGhlIGluZGV4IG9mIHRo ZSBjdXN0b21lci1zaWRlIChlLmcuIGV0aGVybmV0KSAKICAgICAgICAgICAgaW50ZXJmYWNlLiIg CiAgIDo6PSB7IGR2Yk5pdUV0aGVybmV0RmlsdGVyRW50cnkgMyB9IAogICAgCiAgIGR2Yk5pdUV0 aGVybmV0RmlsdGVyRXRoZXJUeXBlIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSU5U RUdFUiB7IAogICAgICAgICAgICAgICAgICAgICAgIGV0aGVybmV0MigxKSwgCiAgICAgICAgICAg ICAgICAgICAgICAgc25hcCgyKSwgCiAgICAgICAgICAgICAgICAgICAgICAgbGxjKDMpIAogICAg ICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAg U1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUg Zm9ybWF0IG9mIHRoZSBldGhlcmVudCBmcmFtZS4gIFRoaXMgY2FuIGJlIEV0aGVybmV0MiwgCiAg ICAgICAgICAgICA4MDIuMiBTTkFQIG9yIDgwMi4yIExMQy4gIFRoaXMgaXMgdXNlZCB0byBjb3Jy ZWN0bHkgCiAgICAgICAgICAgICBsb2NhdGUgdGhlIGZpZWxkIGlkZW50aWZ5aW5nIHRoZSBwcm90 b2NvbCBiZWluZyAgCiAgICAgICAgICAgICB0cmFuc3BvcnRlZC4iIAogICA6Oj0geyBkdmJOaXVF dGhlcm5ldEZpbHRlckVudHJ5IDQgfSAKICAgIAogICBkdmJOaXVFdGhlcm5ldEZpbHRlclByb3Rv Y29sIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSW50ZWdlcjMyICgxLi42NTUzNSkg CiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJl bnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlIHByb3RvY29sIHRvIGZpbHRl ciBvbi4gIEZvciBFdGhlcm5ldDIgYW5kIDgwMi4yIFNOQVAgCiAgICAgICAgICAgIHRoZSB2YWx1 ZSBpbiB0aGUgRXRoZXJUeXBlIGZpZWxkIGlzIGNoZWNrZWQuICBGb3IgODAyLjIgTExDIAogICAg ICAgICAgICB0aGUgdmFsdXMgaW4gdGhlIFNBUCBmaWVsZCBpcyBjaGVja2VkLiIgCiAgIDo6PSB7 IGR2Yk5pdUV0aGVybmV0RmlsdGVyRW50cnkgNCB9IAogICAgCiAgIGR2Yk5pdUV0aGVybmV0Rmls dGVyQWN0aW9uIE9CSkVDVC1UWVBFIAogICAgICAgU1lOVEFYICAgICAgSU5URUdFUiB7IAogICAg ICAgICAgICAgICAgICAgICAgIGFjY2VwdCgxKSwgCiAgICAgICAgICAgICAgICAgICAgICAgZGlz Y2FyZCgyKSAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRl bWJlciAyMDAwICAgICAgICAgICAgICA0NCAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5l dHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgICAg ICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAgICAgU1RBVFVT ICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgYWN0aW9u IHRvIGJlIHRha2VuIHdoZW4gdGhlcmUgaXMgYSBmaWx0ZXIgbWF0Y2guICBJZiAgCiAgICAgICAg ICAgIGl0IGlzIGFjY2VwdCwgdGhlIGZyYW1lIHdpbGwgYmUgZm9yd2FyZGVkIG90aGVyd2lzZSAg CiAgICAgICAgICAgIHRoZSBmcmFtZSB3aWxsIGJlIGRpc2NhcmRlZC4iIAogICA6Oj0geyBkdmJO aXVFdGhlcm5ldEZpbHRlckVudHJ5IDUgfSAKICAgIAogICBkdmJOaXVFdGhlcm5ldEZpbHRlck1h dGNoZXMgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBDb3VudGVyMzIgCiAgICAgICBN QVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAg ICBERVNDUklQVElPTiAKICAgICAgICAgICAiQ291bnRzIHRoZSBudW1iZXIgb2YgdGltZXMgdGhp cyBmaWx0ZXIgd2FzIG1hdGNoZWQuIAogICAgICAgICAgICBUaGlzIG9iamVjdCBpcyBpbml0aWFs aXplZCB0byAwIGF0IGJvb3QsIG9yIGF0IHJvdyAKICAgICAgICAgICAgY3JlYXRpb24sIGFuZCBp cyByZXNldCBvbmx5IHVwb24gcmVib290LiIgCiAgIDo6PSB7IGR2Yk5pdUV0aGVybmV0RmlsdGVy RW50cnkgNiB9IAogICAgCiAgICAKICAgLS0gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IAogICAtLSA9ICBDUEUgSVAgTWFuYWdl bWVudCBhbmQgYW50aSBzcG9vZmluZyBncm91cCAgICAgICAgICAgICAgICAgID0gCiAgIC0tID09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PSAKICAgIAogICAtLSBUaGlzIENQRSBzZWN0aW9uIGlzIHRha2VuIGZyb20gUkZDMjY2OSBh bmQgZW5oYW5jZWQgCiAgICAKICAgZHZiTml1Q3BlRW5yb2xsIE9CSkVDVC1UWVBFIAogICAgICAg U1lOVEFYICAgICAgSU5URUdFUiB7IAogICAgICAgICAgICAgICAgICAgICAgIG5vbmUoMSksIAog ICAgICAgICAgICAgICAgICAgICAgIGFueSgyKSwgCiAgICAgICAgICAgICAgICAgICB9IAogICAg ICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAg ICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhpcyBvYmplY3QgY29udHJvbHMgdGhlIHBv cHVsYXRpb24gb2YgZHZiTml1Q3BlVGFibGUuIAogICAgICAgICAgICBJZiBzZXQgdG8gbm9uZSwg dGhlIGZpbHRlcnMgbXVzdCBiZSBzZXQgbWFudWFsbHkuIAogICAgICAgICAgICBJZiBzZXQgdG8g YW55LCB0aGUgTklVIHNuaWZmcyB0aGUgcGFja2V0cyBvcmlnaW5hdGluZyAKICAgICAgICAgICAg ZnJvbSB0aGUgRXRoZXJuZXQgYW5kIGVucm9sbHMgdXAgdG8gZHZiTml1Q3BlSXBNYXggCiAgICAg ICAgICAgIGFkZHJlc3NlcyBiYXNlZCBvbiB0aGUgc291cmNlIElQIGFkZHJlc3NlcyBvZiB0aG9z ZSAKICAgICAgICAgICAgcGFja2V0cy4gQXQgaW5pdGlhbCBzeXN0ZW0gc3RhcnR1cCwgZGVmYXVs dCB2YWx1ZSBmb3IgdGhpcyAgCiAgICAgICAgICAgIG9iamVjdCBpcyBhbnkoMikuIiAKICAgOjo9 IHsgZHZiTml1Q3BlIDEgfSAKICAgIAogICBkdmJOaXVDcGVJcE1heCBPQkpFQ1QtVFlQRSAKICAg ICAgIFNZTlRBWCAgICAgIEludGVnZXIzMiAoLTEuLjIxNDc0ODM2NDcpIAogICAgICAgTUFYLUFD Q0VTUyAgcmVhZC13cml0ZSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVND UklQVElPTiAKICAgICAgICAgICAiVGhpcyBvYmplY3QgY29udHJvbHMgdGhlIG1heGltdW0gbnVt YmVyIG9mIENQRXMgYWxsb3dlZCB0byAKICAgICAgICAgICAgY29ubmVjdCBiZWhpbmQgdGhpcyBk ZXZpY2UuIElmIHNldCB0byB6ZXJvLCBhbnkgbnVtYmVyIG9mIAogICAgICAgICAgICBDUEVzIG1h eSBjb25uZWN0IHVwIHRvIHRoZSBtYXhpbXVtIHBlcm1pdHRlZCBmb3IgdGhlICAKICAgICAgICAg ICAgZGV2aWNlIG9yIHRoZSBtYXhpbXVtIGFsbG93ZWQgZm9yIHRoZSBzdWJuZXQgY29uZmlndXJl ZCBmb3IgIAogICAgICAgICAgICB0aGUgQ1BFIChzdWJzY3JpYmVyKSBpbnRlcmZhY2UsIHdoaWNo ZXZlciBpcyB0aGUgc21hbGxlci4gIAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAt IEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDQ1IAwKICAgICAgICAgICAgICAg ICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAK IAogCiAgICAgICAgICAgIElmIHNldCB0byAtMSwgbm8gZmlsdGVyaW5nIGlzIGRvbmUgb24gQ1BF IHNvdXJjZSBhZGRyZXNzZXMsICAKICAgICAgICAgICAgYW5kIG5vIGVudHJpZXMgYXJlIG1hZGUg aW4gdGhlIGR2Yk5pdUNwZVRhYmxlLiAgCiAgICAgICAgICAgIElmIGFuIGF0dGVtcHQgaXMgbWFk ZSB0byBzZXQgdGhpcyB0byBhIG51bWJlciBncmVhdGVyIHRoYW4gIAogICAgICAgICAgICB0aGF0 IHBlcm1pdHRlZCBmb3IgdGhlIGRldmljZS9zdWJuZXQsIGl0IGlzIHNldCB0byB0aGF0ICAKICAg ICAgICAgICAgbWF4aW11bSBvZiB0aGUgc21hbGxlc3QgdmFsdWUgKGRldmljZSBvciBzdWJuZXQp LiAKICAgICAgICAgICAgQXQgaW5pdGlhbCBzeXN0ZW0gc3RhcnR1cCwgZGVmYXVsdCB2YWx1ZSBm b3IgdGhpcyBvYmplY3QgCiAgICAgICAgICAgIGlzIDEuIiAKICAgOjo9IHsgZHZiTml1Q3BlIDIg fSAKICAgIAogICBkdmJOaXVDcGVUYWJsZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgICAg IFNFUVVFTkNFIE9GIER2Yk5pdUNwZUVudHJ5IAogICAgICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vz c2libGUgCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IAogICAgICAgREVTQ1JJUFRJT04gCiAg ICAgICAgICAgIlRoaXMgdGFibGUgbGlzdHMgdGhlIElQIGFkZHJlc3NlcyBzZWVuIChvciBwZXJt aXR0ZWQpICBhcyAKICAgICAgICAgICAgc291cmNlIGFkZHJlc3NlcyBpbiBwYWNrZXRzIG9yaWdp bmF0aW5nIGZyb20gdGhlIGN1c3RvbWVyIAogICAgICAgICAgICBpbnRlcmZhY2Ugb24gdGhpcyBk ZXZpY2UuIEluIGFkZGl0aW9uLCB0aGlzIHRhYmxlIGNhbiBiZSAKICAgICAgICAgICAgcHJvdmlz aW9uZWQgd2l0aCB0aGUgc3BlY2lmaWMgYWRkcmVzc2VzIHBlcm1pdHRlZCBmb3IgdGhlIAogICAg ICAgICAgICBDUEVzIHZpYSB0aGUgbm9ybWFsIHJvdyBjcmVhdGlvbiBtZWNoYW5pc21zLiIgCiAg IDo6PSB7IGR2Yk5pdUNwZSAzIH0gCiAgICAKICAgZHZiTml1Q3BlRW50cnkgT0JKRUNULVRZUEUg CiAgICAgICBTWU5UQVggICAgICBEdmJOaXVDcGVFbnRyeSAKICAgICAgIE1BWC1BQ0NFU1MgIG5v dC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBU SU9OIAogICAgICAgICAgICJBbiBlbnRyeSBpbiB0aGUgZHZiTml1Q3BlVGFibGUuIFRoZXJlIGlz IG9uZSBlbnRyeSAKICAgICAgICAgICAgZm9yIGVhY2ggSVAgQ1BFIHNlZW4gb3IgcHJvdmlzaW9u ZWQuIElmIGR2Yk5pdUNwZUlwTWF4IAogICAgICAgICAgICBpcyBzZXQgdG8gLTEsIHRoaXMgdGFi bGUgaXMgaWdub3JlZCwgb3RoZXJ3aXNlOiBVcG9uICAKICAgICAgICAgICAgcmVjZWlwdCBvZiBh biBJUCAgcGFja2V0IGZyb20gdGhlIGN1c3RvbWVyIGludGVyZmFjZSBvZiB0aGUgIAogICAgICAg ICAgICBDTSwgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIGlzIGNoZWNrZWQgYWdhaW5zdCB0aGlzIHRh YmxlLiBJZiAgCiAgICAgICAgICAgIHRoZSBhZGRyZXNzIGlzIGluIHRoZSB0YWJsZSwgcGFja2V0 IHByb2Nlc3NpbmcgY29udGludWVzLiAKICAgIAogICAgICAgICAgICBJZiB0aGUgYWRkcmVzcyBp cyBub3QgaW4gdGhlIHRhYmxlLCBidXQgZHZiTml1Q3BlRW5yb2xsIAogICAgICAgICAgICBpcyBz ZXQgdG8gYW55IGFuZCB0aGUgdGFibGUgc2l6ZSBpcyBsZXNzIHRoYW4gCiAgICAgICAgICAgIGR2 Yk5pdUNwZUlwTWF4LCB0aGUgYWRkcmVzcyBpcyBhZGRlZCB0byB0aGUgdGFibGUgYW5kIAogICAg ICAgICAgICBwYWNrZXQgcHJvY2Vzc2luZyBjb250aW51ZXMuIE90aGVyd2lzZSwgdGhlIHBhY2tl dCBpcyAKICAgICAgICAgICAgZHJvcHBlZC4gCiAgICAKICAgICAgICAgICAgVGhlIGZpbHRlcmlu ZyBhY3Rpb25zIHNwZWNpZmllZCBieSB0aGlzIHRhYmxlIG9jY3VyIGFmdGVyIAogICAgICAgICAg ICBhbnkgRXRoZXJuZXQgZmlsdGVyaW5nIChkdmJOaXVFdGhlcm5ldEZpbHRlclRhYmxlKSwgYnV0 ICAKICAgICAgICAgICAgcHJpb3IgdG8gYW55IElQIGZpbHRlcmluZyAoZHZiTml1SXBGaWx0ZXJU YWJsZSkuIiAKICAgICAgIElOREVYICAgeyBkdmJOaXVDcGVBZGRyVHlwZSwgZHZiTml1Q3BlSXAg fSAKICAgOjo9IHsgZHZiTml1Q3BlVGFibGUgMSB9IAogICAgCiAgIER2Yk5pdUNwZUVudHJ5IDo6 PSBTRVFVRU5DRSB7IAogICAgICAgZHZiTml1Q3BlSXBUeXBlICAgIEluZXRBZGRyZXNzVHlwZSwg CiAgICAgICBkdmJOaXVDcGVJcCAgICAgICAgSW5ldEFkZHJlc3MsIAogICAgICAgZHZiTml1Q3Bl TWFza1R5cGUgIEluZXRBZGRyZXNzVHlwZSwgCiAgICAgICBkdmJOaXVDcGVNYXNrICAgICAgSW5l dEFkZHJlc3MsIAogICAgICAgZHZiTml1Q3BlU291cmNlICAgIElOVEVHRVIsIAogICAgICAgZHZi Tml1Q3BlU3RhdHVzICAgIFJvd1N0YXR1cyAKICAgfSAKICAKVmFsZW50aW5lICAgICAgIEluZm9y bWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAgICA0NiAMCiAgICAg ICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVt YmVyIDIwMDAgCiAKIAogICAgCiAgIGR2Yk5pdUNwZUlwVHlwZSBPQkpFQ1QtVFlQRSAKICAgICAg IFNZTlRBWCAgICAgIEluZXRBZGRyZXNzVHlwZSAKICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nl c3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAog ICAgICAgICAgICJUaGUgdHlwZSBvZiBJUCBhZGRyZXNzIHVzZWQgZm9yIHRoZSBpZGVudGlmaWVk IENQRS4iIAogICA6Oj0geyBkdmJOaXVDcGVFbnRyeSAxIH0gCiAgICAKICAgZHZiTml1Q3BlSXAg T0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJbmV0QWRkcmVzcyAKICAgICAgIE1BWC1B Q0NFU1MgIG5vdC1hY2Nlc3NpYmxlIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAg IERFU0NSSVBUSU9OIAogICAgICAgICAgICJUaGUgSVAgYWRkcmVzcyB0byB3aGljaCB0aGlzIGVu dHJ5IGFwcGxpZXMuIiAKICAgOjo9IHsgZHZiTml1Q3BlRW50cnkgMiB9IAogICAgCiAgICAKICAg ZHZiTml1Q3BlTWFza1R5cGUgT0JKRUNULVRZUEUgCiAgICAgICBTWU5UQVggICAgICBJbmV0QWRk cmVzc1R5cGUgCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSAKICAgICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiVGhlIHR5cGUgb2Yg SVAgYWRkcmVzcyBmb3IgdGhlIENQRSBhZGRyZXNzIG1hc2suIiAKICAgOjo9IHsgZHZiTml1Q3Bl RW50cnkgMyB9IAogICAgCiAgIGR2Yk5pdUNwZU1hc2sgT0JKRUNULVRZUEUgCiAgICAgICBTWU5U QVggICAgICBJbmV0QWRkcmVzcyAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlIAogICAg ICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJB IGJpdCBtYXNrIHRoYXQgaXMgdG8gYmUgYXBwbGllZCB0byB0aGUgQ1BFIHNvdXJjZSBJUCAKICAg ICAgICAgICAgYWRkcmVzcyBwcmlvciB0byBtYXRjaGluZy4gVGhpcyBtYXNrIGlzIG5vdCBuZWNl c3NhcmlseSAKICAgICAgICAgICAgdGhlIHNhbWUgYXMgYSBzdWJuZXQgbWFzaywgYnV0IDEncyBi aXRzIG11c3QgYmUgbGVmdG1vc3QgCiAgICAgICAgICAgIGFuZCBjb250aWd1b3VzLiAgV2hlbiBj cmVhdGVkIGF1dG9tYXRpY2FsbHkgdGhpcyB3aWxsIGJlIAogICAgICAgICAgICBhbGwgMSdzLiAg Rm9yIG1hbnVhbCBlbnRyaWVzLCBpdCBjYW4gYmUgdXNlZCB0byByZXByZXNlbnQgYSAgCiAgICAg ICAgICAgIHJhbmdlIChzdWJuZXQpIHRodXMgcmVkdWNpbmcgdGhlIG51bWJlciBvZiBlbnRyaWVz IGluIHRoZSAgCiAgICAgICAgICAgIHRhYmxlLiIgCiAgIDo6PSB7IGR2Yk5pdUNwZUVudHJ5IDQg fSAKICAgIAogICAgCiAgIGR2Yk5pdUNwZVNvdXJjZSBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRB WCAgICAgIElOVEVHRVIgeyAKICAgICAgICAgICAgICAgICAgICAgICBvdGhlcigxKSwgCiAgICAg ICAgICAgICAgICAgICAgICAgbWFudWFsKDIpLCAKICAgICAgICAgICAgICAgICAgICAgICBsZWFy bmVkKDMpIAogICAgICAgICAgICAgICAgICAgfSAKICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAg ICAgICAiVGhpcyBvYmplY3QgZGVzY3JpYmVzIGhvdyB0aGlzIGVudHJ5IHdhcyBjcmVhdGVkLiBJ ZiB0aGUgCiAgICAgICAgICAgIHZhbHVlIGlzIG1hbnVhbCgyKSwgdGhpcyByb3cgd2FzIGNyZWF0 ZWQgYnkgYSBuZXR3b3JrIAogICAgICAgICAgICBtYW5hZ2VtZW50IGFjdGlvbiAoZWl0aGVyIGNv bmZpZ3VyYXRpb24sIG9yIFNOTVAgc2V0KS4gCiAgClZhbGVudGluZSAgICAgICBJbmZvcm1hdGlv bmFsIC0gRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMCAgICAgICAgICAgICAgNDcgDAogICAgICAgICAg ICAgICAgIERWQiBDYWJsZSBOZXR3b3JrIEludGVyZmFjZSBVbml0IE1JQiAgICBOb3ZlbWJlciAy MDAwIAogCiAKICAgICAgICAgICAgSWYgc2V0IHRvIGxlYXJuZWQoMyksIHRoZW4gaXQgd2FzIGZv dW5kIHZpYSAKICAgICAgICAgICAgbG9va2luZyBhdCB0aGUgc291cmNlIElQIGFkZHJlc3Mgb2Yg YSByZWNlaXZlZCBwYWNrZXQuIiAKICAgOjo9IHsgZHZiTml1Q3BlRW50cnkgNSB9IAogICAgCiAg IGR2Yk5pdUNwZVN0YXR1cyBPQkpFQ1QtVFlQRSAKICAgICAgIFNZTlRBWCAgUm93U3RhdHVzIAog ICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUgCiAgICAgICBTVEFUVVMgIGN1cnJlbnQgCiAg ICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAgIlN0YW5kYXJkIG9iamVjdCB0byBtYW5pcHVs YXRlIHJvd3MuIFRvIGNyZWF0ZSBhIHJvdyBpbiAgCiAgICAgICAgICAgICB0aGlzIHRhYmxlLCB5 b3Ugb25seSBuZWVkIHRvIHNwZWNpZnkgdGhpcyBvYmplY3QuICAKICAgICAgICAgICAgIE1hbmFn ZW1lbnQgc3RhdGlvbnMgU0hPVUxEIHVzZSB0aGUgY3JlYXRlLWFuZC1nbyBtZWNoYW5pc20gIAog ICAgICAgICAgICAgZm9yIGNyZWF0aW5nIHJvd3MgaW4gdGhpcyB0YWJsZS4iIAogICA6Oj0geyBk dmJOaXVDcGVFbnRyeSA2IH0gCiAgICAKICAgICAgICAgICAgICAgICAKICAgIAogICAtLSBDb25m b3JtYW5jZSBzdGF0ZW1lbnRzICAKICAgIAogICBkdmJOaXVDb21wbGlhbmNlIE1PRFVMRS1DT01Q TElBTkNFIAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAog ICAgICAgICAgICJUaGUgY29tcGxpYW5jZSBzdGF0ZW1lbnQgZm9yIEV1cm9Nb2RlbSBOSVVzICAK ICAgICAgICAgICAgd2hpY2ggaW1wbGVtZW50IHRoZSBEVkItQ0FCTEUtTklVLU1JQiBNSUIuICBB biAKICAgICAgICAgICAgaW1wbG1lbnRhdGlvbiBvbmx5IGhhcyB0byBzdXBwb3J0IElQdjQgYWRk cmVzc2VzIHRvIGJlICAKICAgICAgICAgICAgY29tcGxpYW50LiIgCiAgICAKICAgTU9EVUxFICAt LSBkdmJOaXUgCiAgICAgICBNQU5EQVRPUlktR1JPVVBTIHsgZHZiTml1U3lzdGVtR3JvdXAsICAK ICAgICAgICAgICAgICAgICAgICAgICAgICBkdmJOaXVTb2Z0d2FyZUdyb3VwLCAKICAgICAgICAg ICAgICAgICAgICAgICAgICBkdmJOaXVFdmVudEdyb3VwIAogICAgICAgICAgICAgICAgICAgICAg ICB9IAogICAgICAgR1JPVVAgZHZiTml1RGhjcEdyb3VwICAgCiAgICAgICAgICAgREVTQ1JJUFRJ T04gCiAgICAgICAgICAgICAgICJUaGUgZ3JvdXAgaXMgb3B0aW9uYWwgYnV0IHNob3VsZCBiZSBp bXBsZW1lbnRlZCBpZiAgCiAgICAgICAgICAgICAgICBESENQL0JPT1RQIGlzIGltcGxlbWVudGVk LiIgCiAgICAKICAgICAgIEdST1VQIGR2Yk5pdUlwRmlsdGVyR3JvdXAgICAKICAgICAgICAgICBE RVNDUklQVElPTiAKICAgICAgICAgICAgICAgIlRoZSBncm91cCBpcyBvcHRpb25hbCBidXQgc2hv dWxkIGJlIGltcGxlbWVudGVkIGlmICAKICAgICAgICAgICAgICAgIGR2Yk5pdU5hdEdyb3VwIG9y IGR2ZE5pdU5hcHRHcm91cCBhcmUgaW1wbGVtZW5ldGVkLiAgIAogICAgICAgICAgICAgICAgVGhl IGltcGxlbWVudGF0aW9uIG9mIHRoaXMgZ3JvdXAgZG9lcyBub3QgbWFuZGF0ZSB0aGUgIAogICAg ICAgICAgICAgICAgaW1wbGVtZW50YXRpb24gb2YgZHZiTml1TmF0R3JvdXAgb3IgZHZkTml1TmFw dEdyb3VwLiIgCiAgICAKICAgICAgIEdST1VQIGR2Yk5pdU5hdEdyb3VwICAgCiAgICAgICAgICAg REVTQ1JJUFRJT04gCiAgICAgICAgICAgICAgICJUaGUgZ3JvdXAgaXMgb3B0aW9uYWwgYnV0IHNo b3VsZCBiZSBpbXBsZW1lbnRlZCBpZiBOQVQgCiAgICAgICAgICAgICAgICBpcyBpbXBsZW1lbnRl ZC4iIAogICAgCiAgICAgICBHUk9VUCBkdmJOaXVOYXB0R3JvdXAgICAKICAgICAgICAgICBERVND UklQVElPTiAKICAgICAgICAgICAgICAgIlRoZSBncm91cCBpcyBvcHRpb25hbCBidXQgc2hvdWxk IGJlIGltcGxlbWVudGVkIGlmIE5BUFQgCiAgICAgICAgICAgICAgICBpcyBpbXBsZW1lbnRlZC4i IAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIw MDAgICAgICAgICAgICAgIDQ4IAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJ bnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgICAKICAgICAgIEdST1VQ IGR2Yk5pdUV0aEZpbHRlckdyb3VwICAgCiAgICAgICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAg ICAgICAgICJUaGUgZ3JvdXAgaXMgb3B0aW9uYWwgYnV0IHNob3VsZCBiZSBpbXBsZW1lbnRlZCBp ZiAgCiAgICAgICAgICAgICAgICBFdGhlcm5ldCBmaWx0ZXJpbmcgaXMgaW1wbGVtZW50ZWQuICBJ ZiB0aGUgTklVIHN1cHBvcnRzIAogICAgICAgICAgICAgICAgYnJpZGdpbmcgdGhlbiBpdCBpcyBz dHJvbmdseSByZWNvbW1lbmRlZCB0aGlzIGdyb3VwIGlzIAogICAgICAgICAgICAgICAgaW1wbGVt ZW50ZWQuIiAKICAgIAogICAgICAgR1JPVVAgZHZiTml1Q3BlR3JvdXAgICAKICAgICAgICAgICBE RVNDUklQVElPTiAKICAgICAgICAgICAgICAgIlRoZSBncm91cCBpcyBvcHRpb25hbCBidXQgc2hv dWxkIGJlIGltcGxlbWVudGVkIHRvIAogICAgICAgICAgICAgICAgcHJldmVudCBzcG9vZmluZyB0 eXBlIGF0dGFja3MgYW5kIHJlc3RyaWN0IHRoZSBudW1iZXIgCiAgICAgICAgICAgICAgICBvZiBD UEUgZGV2aWNlcyBhdHRhY2hlZCB0byB0aGUgTklVLiIgCiAgICAKICAgICAgIE9CSkVDVCBkdmJO aXVTdGF0aWNJcE1hc2tUeXBlIAogICAgICAgICAgU1lOVEFYICBJbmV0QWRkcmVzc1R5cGUgeyBp cHY0KDEpfSAKICAgICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICAgICJBbiBpbXBsZW1l bnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgSVB2NCAKICAgICAgICAgICAgICAg YWRkcmVzc2VzLiIgCiAgICAKICAgICAgIE9CSkVDVCBkdmJOaXVTdGF0aWNJcE1hc2sgCiAgICAg ICAgICBTWU5UQVggIEluZXRBZGRyZXNzIChTSVpFKDQpKSAKICAgICAgICAgIERFU0NSSVBUSU9O IAogICAgICAgICAgICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1 cHBvcnQgSVB2NCAKICAgICAgICAgICAgICAgYWRkcmVzc2VzLiIgCiAgICAKICAgICAgIE9CSkVD VCBkdmJOaXVTd1NlcnZlckFkZHJUeXBlIAogICAgICAgICAgU1lOVEFYICBJbmV0QWRkcmVzc1R5 cGUgeyBpcHY0KDEpfSAKICAgICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICAgICJBbiBp bXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgSVB2NCAKICAgICAgICAg ICAgICAgYWRkcmVzc2VzLiIgCiAgICAKICAgICAgIE9CSkVDVCBkdmJOaXVTd1NlcnZlciAKICAg ICAgICAgIFNZTlRBWCAgSW5ldEFkZHJlc3MgKFNJWkUoNCkpIAogICAgICAgICAgREVTQ1JJUFRJ T04gCiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8g c3VwcG9ydCBJUHY0IAogICAgICAgICAgICAgICBhZGRyZXNzZXMuIiAKICAgIAogICAgICAgT0JK RUNUIGR2Yk5pdURoY3BTZXJ2ZXJBZGRyVHlwZSAKICAgICAgICAgIFNZTlRBWCAgSW5ldEFkZHJl c3NUeXBlIHsgaXB2NCgxKX0gCiAgICAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAgICAi QW4gaW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IElQdjQgCiAgICAg ICAgICAgICAgIGFkZHJlc3Nlcy4iIAogICAgCiAgICAgICBPQkpFQ1QgZHZiTml1RGhjcFNlcnZl ciAKICAgICAgICAgIFNZTlRBWCAgSW5ldEFkZHJlc3MgKFNJWkUoNCkpIAogICAgICAgICAgREVT Q1JJUFRJT04gCiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWly ZWQgdG8gc3VwcG9ydCBJUHY0IAogICAgICAgICAgICAgICBhZGRyZXNzZXMuICBUaGUgYnJvYWRj YXN0IGFkZHJlc3MgdG8gYmUgdXNlZCBmb3IgSVB2NCBpcyAgCiAgICAgICAgICAgICAgIDI1NS4y NTUuMjU1LjI1NSBhbmQgc2hvdWxkIGJlIHRoZSBkZWZhdWx0IHZhbHVlLiIgCiAgICAKICAgICAg IE9CSkVDVCBkdmJOaXVJcEZpbHRlckRzdEFkZHJUeXBlIAogICAgICAgICAgU1lOVEFYICBJbmV0 QWRkcmVzc1R5cGUgeyBpcHY0KDEpfSAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwg LSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAgICA0OSAMCiAgICAgICAgICAgICAg ICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAg CiAKIAogICAgICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0 aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0IAogICAgICAgICAgICAgICBhZGRy ZXNzZXMuIiAKICAgIAogICAgICAgT0JKRUNUIGR2Yk5pdUlwRmlsdGVyRHN0QWRkciAKICAgICAg ICAgIFNZTlRBWCAgSW5ldEFkZHJlc3MgKFNJWkUoNCkpIAogICAgICAgICAgREVTQ1JJUFRJT04g CiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3Vw cG9ydCBJUHY0IAogICAgICAgICAgICAgICBhZGRyZXNzZXMuIFRoZSBkZWZhdWx0IHZhbHVlIGZv ciB0aGlzIG9iamVjdCBmb3IgSVB2NCBpcyAgCiAgICAgICAgICAgICAgIDAuMC4wLjAiIAogICAg CiAgICAgICBPQkpFQ1QgZHZiTml1SXBGaWx0ZXJTcmNBZGRyVHlwZSAKICAgICAgICAgIFNZTlRB WCAgSW5ldEFkZHJlc3NUeXBlIHsgaXB2NCgxKX0gCiAgICAgICAgICBERVNDUklQVElPTiAKICAg ICAgICAgICAgICAiQW4gaW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0 IElQdjQgCiAgICAgICAgICAgICAgIGFkZHJlc3Nlcy4iIAogICAgCiAgICAgICBPQkpFQ1QgZHZi Tml1SXBGaWx0ZXJTcmNBZGRyIAogICAgICAgICAgU1lOVEFYICBJbmV0QWRkcmVzcyAoU0laRSg0 KSkgCiAgICAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAgICAiQW4gaW1wbGVtZW50YXRp b24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IElQdjQgCiAgICAgICAgICAgICAgIGFkZHJl c3Nlcy4gVGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoaXMgb2JqZWN0IGZvciBJUHY0IGlzICAKICAg ICAgICAgICAgICAgMC4wLjAuMCIgCiAgICAKICAgICAgIE9CSkVDVCBkdmJOaXVJcEZpbHRlckRz dE1hc2tUeXBlIAogICAgICAgICAgU1lOVEFYICBJbmV0QWRkcmVzc1R5cGUgeyBpcHY0KDEpfSAK ICAgICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICAgICJBbiBpbXBsZW1lbnRhdGlvbiBp cyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgSVB2NCAKICAgICAgICAgICAgICAgYWRkcmVzc2Vz LiIgCiAgICAKICAgICAgIE9CSkVDVCBkdmJOaXVJcEZpbHRlckRzdE1hc2sgCiAgICAgICAgICBT WU5UQVggIEluZXRBZGRyZXNzIChTSVpFKDQpKSAKICAgICAgICAgIERFU0NSSVBUSU9OIAogICAg ICAgICAgICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQg SVB2NCAKICAgICAgICAgICAgICAgYWRkcmVzc2VzLiBUaGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhp cyBvYmplY3QgZm9yIElQdjQgaXMgIAogICAgICAgICAgICAgICAwLjAuMC4wIiAKICAgIAogICAg ICAgT0JKRUNUIGR2Yk5pdUlwRmlsdGVyU3JjTWFza1R5cGUgCiAgICAgICAgICBTWU5UQVggIElu ZXRBZGRyZXNzVHlwZSB7IGlwdjQoMSl9IAogICAgICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAg ICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0 IAogICAgICAgICAgICAgICBhZGRyZXNzZXMuIiAKICAgIAogICAgICAgT0JKRUNUIGR2Yk5pdUlw RmlsdGVyU3JjTWFzayAKICAgICAgICAgIFNZTlRBWCAgSW5ldEFkZHJlc3MgKFNJWkUoNCkpIAog ICAgICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlz IG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0IAogICAgICAgICAgICAgICBhZGRyZXNzZXMu IFRoZSBkZWZhdWx0IHZhbHVlIGZvciB0aGlzIG9iamVjdCBmb3IgSVB2NCBpcyAgCiAgICAgICAg ICAgICAgIDAuMC4wLjAiIAogICAgCiAgICAgICBPQkpFQ1QgZHZiTml1TmF0SW50SXBUeXBlIAog ICAgICAgICAgU1lOVEFYICBJbmV0QWRkcmVzc1R5cGUgeyBpcHY0KDEpfSAKICAgICAgICAgIERF U0NSSVBUSU9OIAogIApWYWxlbnRpbmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2Vw dGVtYmVyIDIwMDAgICAgICAgICAgICAgIDUwIAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUg TmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgICAgICAg ICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0 IAogICAgICAgICAgICAgICBhZGRyZXNzZXMuIiAKICAgIAogICAgICAgT0JKRUNUIGR2Yk5pdU5h dEludElwIAogICAgICAgICAgU1lOVEFYICBJbmV0QWRkcmVzcyAoU0laRSg0KSkgCiAgICAgICAg ICBERVNDUklQVElPTiAKICAgICAgICAgICAgICAiQW4gaW1wbGVtZW50YXRpb24gaXMgb25seSBy ZXF1aXJlZCB0byBzdXBwb3J0IElQdjQgCiAgICAgICAgICAgICAgIGFkZHJlc3Nlcy4iIAogICAg CiAgICAgICBPQkpFQ1QgZHZiTml1TmFwdEFkZHJUeXBlIAogICAgICAgICAgU1lOVEFYICBJbmV0 QWRkcmVzc1R5cGUgeyBpcHY0KDEpfSAKICAgICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAg ICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgSVB2NCAK ICAgICAgICAgICAgICAgYWRkcmVzc2VzLiIgCiAgICAKICAgICAgIE9CSkVDVCBkdmJOaXVOYXB0 QWRkciAKICAgICAgICAgIFNZTlRBWCAgSW5ldEFkZHJlc3MgKFNJWkUoNCkpIAogICAgICAgICAg REVTQ1JJUFRJT04gCiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVx dWlyZWQgdG8gc3VwcG9ydCBJUHY0IAogICAgICAgICAgICAgICBhZGRyZXNzZXMuIiAKICAgIAog ICAgICAgT0JKRUNUIGR2Yk5pdU5hcHRJbnRJcFR5cGUgCiAgICAgICAgICBTWU5UQVggIEluZXRB ZGRyZXNzVHlwZSB7IGlwdjQoMSl9IAogICAgICAgICAgREVTQ1JJUFRJT04gCiAgICAgICAgICAg ICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0IAog ICAgICAgICAgICAgICBhZGRyZXNzZXMuIiAKICAgIAogICAgICAgT0JKRUNUIGR2Yk5pdU5hcHRJ bnRJcCAKICAgICAgICAgIFNZTlRBWCAgSW5ldEFkZHJlc3MgKFNJWkUoNCkpIAogICAgICAgICAg REVTQ1JJUFRJT04gCiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlzIG9ubHkgcmVx dWlyZWQgdG8gc3VwcG9ydCBJUHY0IAogICAgICAgICAgICAgICBhZGRyZXNzZXMuIiAKICAgIAog ICAgICAgT0JKRUNUIGR2Yk5pdUNwZUlwVHlwZSAKICAgICAgICAgIFNZTlRBWCAgSW5ldEFkZHJl c3NUeXBlIHsgaXB2NCgxKX0gCiAgICAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAgICAi QW4gaW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IElQdjQgCiAgICAg ICAgICAgICAgIGFkZHJlc3Nlcy4iIAogICAgCiAgICAgICBPQkpFQ1QgZHZiTml1Q3BlSXAgCiAg ICAgICAgICBTWU5UQVggIEluZXRBZGRyZXNzIChTSVpFKDQpKSAKICAgICAgICAgIERFU0NSSVBU SU9OIAogICAgICAgICAgICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRv IHN1cHBvcnQgSVB2NCAKICAgICAgICAgICAgICAgYWRkcmVzc2VzLiIgCiAgICAKICAgICAgIE9C SkVDVCBkdmJOaXVDcGVNYXNrVHlwZSAKICAgICAgICAgIFNZTlRBWCAgSW5ldEFkZHJlc3NUeXBl IHsgaXB2NCgxKX0gCiAgICAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAgICAiQW4gaW1w bGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IElQdjQgCiAgICAgICAgICAg ICAgIGFkZHJlc3Nlcy4iIAogICAgCiAgICAgICBPQkpFQ1QgZHZiTml1Q3BlTWFzayAKICAgICAg ICAgIFNZTlRBWCAgSW5ldEFkZHJlc3MgKFNJWkUoNCkpIAogIApWYWxlbnRpbmUgICAgICAgSW5m b3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDUxIAwKICAg ICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92 ZW1iZXIgMjAwMCAKIAogCiAgICAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAgICAiQW4g aW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IElQdjQgCiAgICAgICAg ICAgICAgIGFkZHJlc3Nlcy4iIAogICAgCiAgIDo6PSB7IGR2Yk5pdUNvbXBsaWFuY2VzIDEgfSAK ICAgIAogICBkdmJOaXVTeXN0ZW1Hcm91cCBPQkpFQ1QtR1JPVVAgCiAgICAgICBPQkpFQ1RTICAg ICB7IAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVDb25maWdTZXQsIAogICAgICAgICAgICAg ICAgICAgICBkdmJOaXVNaWJWZXJzaW9uLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1U2Vy aWFsTnVtLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1UmVzZXROb3csIAogICAgICAgICAg ICAgICAgICAgICBkdmJOaXVSZXNldENvdW50cywgCiAgICAgICAgICAgICAgICAgICAgIGR2Yk5p dURhdGVBbmRUaW1lLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1T3BlclN0YXR1cywgCiAg ICAgICAgICAgICAgICAgICAgIGR2Yk5pdU1vZGVtdHlwZSwgCiAgICAgICAgICAgICAgICAgICAg IGR2Yk5pdVN0YXRpY0lwTWFza1R5cGUsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVTdGF0 aWNJcE1hc2ssIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVTdGF0aWNJcFN0YXR1cywgCiAg ICAgICAgICAgICAgICAgICAgIGR2Yk5pdUV1cm9sb2FkZXIsIAogICAgICAgICAgICAgICAgICAg ICBkdmJOaXVJbXBsU2V0LCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1TXVsdGljYXN0IAog ICAgICAgICAgICAgICAgICAgfSAKICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQgCiAgICAgICBE RVNDUklQVElPTiAKICAgICAgICAgICAiQSBjb2xsZWN0aW9uIG9mIG9iamVjdHMgcHJvdmlkaW5n IGJhc2ljIHN5c3RlbSBsZXZlbCAKICAgICAgICAgICAgY29udHJvbCBhbmQgaW5zdHJ1bWVudGF0 aW9uIG9mIHRoZSBFdXJvTW9kZW0uIiAKICAgOjo9IHsgZHZiTml1R3JvdXBzIDEgfSAKICAgIAog ICBkdmJOaXVTb2Z0d2FyZUdyb3VwIE9CSkVDVC1HUk9VUCAKICAgICAgIE9CSkVDVFMgICAgIHsg CiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdVN3VmVyc2lvbiwgCiAgICAgICAgICAgICAgICAg ICAgIGR2Yk5pdVN3U3RhdGUsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVTd0FjdGlvbiwg CiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdVN3RGF0ZVRpbWUsIAogICAgICAgICAgICAgICAg ICAgICBkdmJOaXVTd1NlcnZlckFkZHJUeXBlLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1 U3dTZXJ2ZXIsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVTd0ZpbGVuYW1lLCAKICAgICAg ICAgICAgICAgICAgICAgZHZiTml1U3dEb3dubG9hZFNsb3QsIAogICAgICAgICAgICAgICAgICAg ICBkdmJOaXVTd0FkbWluU3RhdHVzIAogICAgICAgICAgICAgICAgICAgfSAKICAgICAgIFNUQVRV UyAgICAgIGN1cnJlbnQgCiAgICAgICBERVNDUklQVElPTiAKICAgICAgICAgICAiQSBjb2xsZWN0 aW9uIG9mIG9iamVjdHMgcHJvdmlkaW5nIGNvbnRyb2wgYW5kICAKICAgICAgICAgICAgaW5zdHJ1 bWVudGF0aW9uIG9mIHRoZSBFdXJvTW9kZW0ncyBzb2Z0d2FyZS4iIAogICA6Oj0geyBkdmJOaXVH cm91cHMgMiB9IAogICAgCiAgIGR2Yk5pdURoY3BHcm91cCBPQkpFQ1QtR1JPVVAgCiAgICAgICBP QkpFQ1RTICAgICB7IAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVEaGNwU2VydmVyQWRkclR5 cGUsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVEaGNwU2VydmVyLCAKICAgICAgICAgICAg ICAgICAgICAgZHZiTml1RGhjcFJlbGF5LCAKICAgICAgICAgICAgICAgICAgICAgZHZkTml1RGhj cFJlcUlmLCAKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRl bWJlciAyMDAwICAgICAgICAgICAgICA1MiAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5l dHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgICAg ICAgICAgICAgICBkdmJOaXVEaGNwU3RhdGUsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVE aGNwU2VyVHlwZSwgCiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdURoY3BTdGF0dXMgCiAgICAg ICAgICAgICAgICAgICB9IAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NS SVBUSU9OIAogICAgICAgICAgICJBIGNvbGxlY3Rpb24gb2Ygb2JqZWN0cyBwcm92aWRpbmcgY29u dHJvbCBvdmVyIHRoZSAKICAgICAgICAgICAgRXVyb01vZGVtJ3MgREhDUC9Cb290cCBmdW5jdGlv bmFsaXR5LiIgCiAgIDo6PSB7IGR2Yk5pdUdyb3VwcyAzIH0gCiAgICAKICAgZHZiTml1RXZlbnRH cm91cCBPQkpFQ1QtR1JPVVAgCiAgICAgICBPQkpFQ1RTICAgICB7IAogICAgICAgICAgICAgICAg ICAgICBkdmJOaXVFdmVudFBvbGljeSwgCiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdUV2ZW50 Q29udHJvbFRhYmxlLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1RXZlbnRUYWJsZU1heFNp emUsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVUcmFwUmF0ZSwgCiAgICAgICAgICAgICAg ICAgICAgIGR2Yk5pdUV2ZW50Q29udHJvbFByaW9yaXR5LCAKICAgICAgICAgICAgICAgICAgICAg ZHZiTml1RXZlbnRDb250cm9sQWN0aW9uLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1RXZl bnRUeXBlLCAKICAgICAgICAgICAgICAgICAgICAgZHZiRXZlbnREYXRlVGltZSwgCiAgICAgICAg ICAgICAgICAgICAgIGR2YkV2ZW50RGVzY3JpcHRpb24sIAogICAgICAgICAgICAgICAgICAgICBk dmJFdmVudENvZGUsIAogICAgICAgICAgICAgICAgICAgICBkdmJFdmVudFN0YXR1cywgCiAgICAg ICAgICAgICAgICAgICAgIGR2Yk5pdUV2VGhyb3R0bGVBZG1pblN0YXR1cywgCiAgICAgICAgICAg ICAgICAgICAgIGR2Yk5pdUV2VGhyb3R0bGVJbmhpYml0ZWQsIAogICAgICAgICAgICAgICAgICAg ICBkdmJOaXVFdlRocm90dGxlVGhyZXNob2xkLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1 RXZUaHJvdHRsZUludGVydmFsICAgICAgCiAgICAgICAgICAgICAgICAgICB9IAogICAgICAgU1RB VFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJBIGNvbGxl Y3Rpb24gb2Ygb2JqZWN0cyB1c2VkIHRvIGNvbnRyb2wgYW5kIG1vbml0b3IgCiAgICAgICAgICAg IEV1cm9Nb2RlbSBldmVudHMuIiAKICAgOjo9IHsgZHZiTml1R3JvdXBzIDQgfSAKICAgIAogICBk dmJOaXVJcEZpbHRlckdyb3VwIE9CSkVDVC1HUk9VUCAKICAgICAgIE9CSkVDVFMgICAgIHsgCiAg ICAgICAgICAgICAgICAgICAgIGR2Yk5pdUlwRmlsdGVyRHN0QWRkclR5cGUsIAogICAgICAgICAg ICAgICAgICAgICBkdmJOaXVJcEZpbHRlckRzdEFkZHIsIAogICAgICAgICAgICAgICAgICAgICBk dmJOaXVJcEZpbHRlckRzdE1hc2tUeXBlLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBG aWx0ZXJEc3RNYXNrLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBGaWx0ZXJTdGF0dXMs IAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVJcEZpbHRlclByb3RvY29sLCAKICAgICAgICAg ICAgICAgICAgICAgZHZiTml1SXBGaWx0ZXJJZkluZGV4LCAKICAgICAgICAgICAgICAgICAgICAg ZHZiTml1SXBGaWx0ZXJTcmNQb3J0TG93LCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBG aWx0ZXJEaXJlY3Rpb24sIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVJcEZpbHRlclNyY1Bv cnRIaWdoLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBGaWx0ZXJUb3MsIAogICAgICAg ICAgICAgICAgICAgICBkdmJOaXVJcEZpbHRlckRzdFBvcnRMb3csIAogICAgICAgICAgICAgICAg ICAgICBkdmJOaXVJcEZpbHRlclRvc01hc2ssIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVJ cEZpbHRlckRzdFBvcnRIaWdoLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBGaWx0ZXJT cmNBZGRyVHlwZSwgCiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdUlwRmlsdGVyU3JjQWRkciwg CiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdUlwRmlsdGVyQWN0aW9uLCAKICAKVmFsZW50aW5l ICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAg ICA1MyAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQg TUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVJcEZp bHRlck1hdGNoZXMsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVJcEZpbHRlclNyY01hc2tU eXBlLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBGaWx0ZXJTcmNNYXNrLCAKICAgICAg ICAgICAgICAgICAgICAgZHZiTml1SXBGaWx0ZXJDb250aW51ZSwgCiAgICAgICAgICAgICAgICAg ICAgIGR2Yk5pdUlwRmlsdGVyRW5hYmxlLCAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBU b3NNYXBJbmRleCwgCiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdUlwVG9zTWFwU3RhdHVzLCAK ICAgICAgICAgICAgICAgICAgICAgZHZiTml1SXBUb3NNYXBBbmRNYXNrLCAKICAgICAgICAgICAg ICAgICAgICAgZHZiTml1SXBUb3NNYXBPck1hc2sgCiAgICAgICAgICAgICAgICAgICB9IAogICAg ICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJB IGNvbGxlY3Rpb24gb2Ygb2JqZWN0cyBwcm92aWRpbmcgYSBmaWx0ZXJpbmcgY2FwYWJpbGl0eSAK ICAgICAgICAgICAgYXQgdGhlIElQIGxheWVyLiIgCiAgIDo6PSB7IGR2Yk5pdUdyb3VwcyA1IH0g CiAgICAKICAgZHZiTml1RXRoRmlsdGVyR3JvdXAgT0JKRUNULUdST1VQIAogICAgICAgT0JKRUNU UyAgICAgeyAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1RXRoZXJuZXRGaWx0ZXJTdGF0dXMs IAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVFdGhlcm5ldEZpbHRlcklmSW5kZXgsIAogICAg ICAgICAgICAgICAgICAgICBkdmJOaXVFdGhlcm5ldEZpbHRlckV0aGVyVHlwZSwgCiAgICAgICAg ICAgICAgICAgICAgIGR2Yk5pdUV0aGVybmV0RmlsdGVyQWN0aW9uLCAKICAgICAgICAgICAgICAg ICAgICAgZHZiTml1RXRoZXJuZXRGaWx0ZXJNYXRjaGVzLCAKICAgICAgICAgICAgICAgICAgICAg ZHZiTml1RXRoZXJuZXRGaWx0ZXJFbmFibGUgCiAgICAgICAgICAgICAgICAgICB9IAogICAgICAg U1RBVFVTICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJBIGNv bGxlY3Rpb24gb2Ygb2JqZWN0cyBwcm92aWRpbmcgYSBmaWx0ZXJpbmcgY2FwYWJpbGl0eSAKICAg ICAgICAgICAgYXQgdGhlIEV0aGVybmV0IGxheWVyLiIgCiAgIDo6PSB7IGR2Yk5pdUdyb3VwcyA2 IH0gCiAgICAKICAgZHZiTml1TmF0R3JvdXAgT0JKRUNULUdST1VQIAogICAgICAgT0JKRUNUUyAg ICAgeyAKICAgICAgICAgICAgICAgICAgICAgZHZiTml1TmF0SW50SXBUeXBlLCAKICAgICAgICAg ICAgICAgICAgICAgZHZiTml1TmF0SW50SXAsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVO YXRTdGF0dXMgCiAgICAgICAgICAgICAgICAgICB9IAogICAgICAgU1RBVFVTICAgICAgY3VycmVu dCAKICAgICAgIERFU0NSSVBUSU9OIAogICAgICAgICAgICJBIGNvbGxlY3Rpb24gb2Ygb2JqZWN0 cyBwcm92aWRpbmcgYWRkcmVzcyB0cmFuc2xhdGlvbiBhdCAKICAgICAgICAgICAgZWl0aGVyIHRo ZSBhZGRyZXNzIGxldmVsIiAKICAgOjo9IHsgZHZiTml1R3JvdXBzIDcgfSAKICAgIAogICBkdmJO aXVOYXB0R3JvdXAgT0JKRUNULUdST1VQIAogICAgICAgT0JKRUNUUyAgICAgeyAKICAgICAgICAg ICAgICAgICAgICAgZHZiTml1TmFwdEFkZHJUeXBlLCAKICAgICAgICAgICAgICAgICAgICAgZHZi Tml1TmFwdEFkZHIsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVOYXB0SW50UG9ydCwgCiAg ICAgICAgICAgICAgICAgICAgIGR2Yk5pdU5hcHRJbnRJcFR5cGUsIAogICAgICAgICAgICAgICAg ICAgICBkdmJOaXVOYXB0SW50SXAgCiAgICAgICAgICAgICAgICAgICB9IAogICAgICAgU1RBVFVT ICAgICAgY3VycmVudCAKICAgICAgIERFU0NSSVBUSU9OIAogIApWYWxlbnRpbmUgICAgICAgSW5m b3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDU0IAwKICAg ICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92 ZW1iZXIgMjAwMCAKIAogCiAgICAgICAgICAgIkEgY29sbGVjdGlvbiBvZiBvYmplY3RzIHByb3Zp ZGluZyBhZGRyZXNzIHRyYW5zbGF0aW9uIGF0IAogICAgICAgICAgICBlaXRoZXIgdGhlIHBvcnQg bGV2ZWwiIAogICA6Oj0geyBkdmJOaXVHcm91cHMgOCB9IAogICAgCiAgIGR2Yk5pdUNwZUdyb3Vw IE9CSkVDVC1HUk9VUCAKICAgICAgIE9CSkVDVFMgICAgIHsgCiAgICAgICAgICAgICAgICAgICAg IGR2Yk5pdUNwZUVucm9sbCwgCiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdUNwZUlwTWF4LCAK ICAgICAgICAgICAgICAgICAgICAgZHZiTml1Q3BlSXBUeXBlLCAKICAgICAgICAgICAgICAgICAg ICAgZHZiTml1Q3BlSXAsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVDcGVNYXNrVHlwZSwg CiAgICAgICAgICAgICAgICAgICAgIGR2Yk5pdUNwZU1hc2ssIAogICAgICAgICAgICAgICAgICAg ICBkdmJOaXVDcGVTb3VyY2UsIAogICAgICAgICAgICAgICAgICAgICBkdmJOaXVDcGVTdGF0dXMg CiAgICAgICAgICAgICAgICAgICB9IAogICAgICAgU1RBVFVTICAgICAgY3VycmVudCAKICAgICAg IERFU0NSSVBUSU9OIAogICAgICAgICAgICJBIGNvbGxlY3Rpb24gb2Ygb2JqZWN0cyBwcm92aWRp bmcgYW50aSBzcG9vZmluZyAvIENQRSAKICAgICAgICAgICAgYWRkcmVzcyBtYW5hZ2VtZW50IiAK ICAgOjo9IHsgZHZiTml1R3JvdXBzIDkgfSAKICAgIAogICBFTkQgCiAgICAKNS4gU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgCiAKICAgVGhpcyBNSUIgcmVsYXRlcyB0byBhIHN5c3RlbSB3aGljaCB3 aWxsIHByb3ZpZGUgbWV0cm9wb2xpdGFuIHB1YmxpYyAKICAgaW50ZXJuZXQgYWNjZXNzLiAgQXMg c3VjaCwgaW1wcm9wZXIgbWFuaXB1bGF0aW9uIG9mIHRoZSBvYmplY3RzIAogICByZXByZXNlbnRl ZCBieSB0aGlzIE1JQiBtYXkgcmVzdWx0IGluIGRlbmlhbCBvZiBzZXJ2aWNlIHRvIGEgbGFyZ2Ug CiAgIG51bWJlciBvZiBlbmQtdXNlcnMuICBJbiBhZGRpdGlvbiwgbWFuaXB1bGF0aW9uIG9mIAog ICBkdmJOaXVFdGhlcm5ldEZpbHRlclRhYmxlIGFuZCBkdmJOaXVJcEZpbHRlclRhYmxlIG1heSBh bGxvdyBhbiBlbmQtCiAgIHVzZXIgdG8gaW5jcmVhc2UgdGhlaXIgc2VydmljZSBsZXZlbHMsIHNw b29mIHRoZWlyIElQIGFkZHJlc3NlcyBvciAKICAgYWZmZWN0IG90aGVyIGVuZC11c2VycyBpbiBl aXRoZXIgYSBwb3NpdGl2ZSBvciBuZWdhdGl2ZSBtYW5uZXIuIAogICAgCiAgIFRoZXJlIGFyZSBh IG51bWJlciBvZiBtYW5hZ2VtZW50IG9iamVjdHMgZGVmaW5lZCBpbiB0aGlzIE1JQiB0aGF0IAog ICBoYXZlIGEgTUFYLUFDQ0VTUyBjbGF1c2Ugb2YgcmVhZC13cml0ZSBhbmQvb3IgcmVhZC1jcmVh dGUuICBTdWNoIAogICBvYmplY3RzIG1heSBiZSBjb25zaWRlcmVkIHNlbnNpdGl2ZSBvciB2dWxu ZXJhYmxlIGluIHNvbWUgbmV0d29yayAKICAgZW52aXJvbm1lbnRzLiAgVGhlIHN1cHBvcnQgZm9y IFNFVCBvcGVyYXRpb25zIGluIGEgbm9uLXNlY3VyZSAKICAgZW52aXJvbm1lbnQgd2l0aG91dCBw cm9wZXIgcHJvdGVjdGlvbiBjYW4gaGF2ZSBhIG5lZ2F0aXZlIGVmZmVjdCBvbiAKICAgbmV0d29y ayBvcGVyYXRpb25zLiAgSW4gYWRkaXRpb24gdG8gdGhvc2UgbWVudGlvbmVkIGFib3ZlOiAKICAg IAogICBvICAgIGR2Yk5pdVN0YXRpY0lwVGFibGUgYW5kIGR2Yk5pdURoY3BUYWJsZSBjYW4gYmUg bWFuaXB1bGF0ZWQgdG8gCiAgICAgICAgcHJldmVudCBJUCBhZGRyZXNzZXMgYmVpbmcgYXNzaWdu ZWQgdG8gdGhlIE5JVSBhZnRlciBhIHJlc2V0LCAKICAgICAgICB3aGljaCByZXN1bHRzIGluIGEg ZGVuaWFsIG9mIHNlcnZpY2UuIAogICAgCiAgIG8gICAgVGhlIE5JVSBtYXkgaGF2ZSBpdHMgc29m dHdhcmUgY2hhbmdlZCBieSB0aGUgYWN0aW9ucyBvZiB0aGUgCiAgICAgICAgbWFuYWdlbWVudCBz eXN0ZW0uICBBbiBpbXByb3BlciBzb2Z0d2FyZSBsb2FkIG1heSByZXN1bHQgaW4gCiAgICAgICAg c3Vic3RhbnRpYWwgdnVsbmVyYWJpbGl0aWVzIGFuZCB0aGUgbG9zcyBvZiB0aGUgYWJpbGl0eSBv ZiB0aGUgCiAgICAgICAgbWFuYWdlbWVudCBzeXN0ZW0gdG8gY29udHJvbCB0aGUgTklVLiAKICAg IAogICBvICAgIFNldHRpbmcgZG9jc0RldkV2VGhyb3R0bGVBZG1pblN0YXR1cyA9IHVuY29uc3Ry YWluZWQoMSkgbWF5IAogICAgICAgIGNhdXNlIGZsb29kaW5nIG9mIHRyYXBzLCB3aGljaCBjYW4g ZGlzcnVwdCBuZXR3b3JrIHNlcnZpY2UuIAogICAgCgogIApWYWxlbnRpbmUgICAgICAgSW5mb3Jt YXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAgICAgIDU1IAwKICAgICAg ICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5pdCBNSUIgICAgTm92ZW1i ZXIgMjAwMCAKIAogCiAgIFRoaXMgTUlCIGRvZXMgbm90IGFmZmVjdCBjb25maWRlbnRpYWxpdHkg b2Ygc2VydmljZXMgb24gYSBjYWJsZSAKICAgc3lzdGVtLiBUaGUgRFZCL0RBVklDIEludGVyb3Bl cmFiaWxpdHkgQ29uc29ydGl1bSBleHBlY3RzIHRvIHByb2R1Y2UgCiAgIGEgTUlCIGZvciB0aGUg c2VjdXJpdHkgbWVjaGFuaXNtIGluIHRoZSBuZWFyIGZ1dHVyZS4gCiAgICAKICAgU05NUHYxIGJ5 IGl0c2VsZiBpcyBub3QgYSBzZWN1cmUgZW52aXJvbm1lbnQuIEV2ZW4gaWYgdGhlIG5ldHdvcmsg CiAgIGl0c2VsZiBpcyBzZWN1cmUgKGZvciBleGFtcGxlIGJ5IHVzaW5nIElQU2VjKSwgZXZlbiB0 aGVuLCB0aGVyZSBpcyAKICAgbm8gY29udHJvbCBhcyB0byB3aG8gb24gdGhlIHNlY3VyZSBuZXR3 b3JrIGlzIGFsbG93ZWQgdG8gYWNjZXNzIGFuZCAKICAgR0VUL1NFVCAocmVhZC9jaGFuZ2UvY3Jl YXRlL2RlbGV0ZSkgdGhlIG9iamVjdHMgaW4gdGhpcyBNSUIuIEl0IGlzIAogICByZWNvbW1lbmRl ZCB0aGF0IHRoZSBpbXBsZW1lbnRlcnMgY29uc2lkZXIgdGhlIHNlY3VyaXR5IGZlYXR1cmVzIGFz IAogICBwcm92aWRlZCBieSB0aGUgU05NUHYzIGZyYW1ld29yay4gU3BlY2lmaWNhbGx5LCB0aGUg dXNlIG9mIHRoZSBVc2VyLQogICBiYXNlZCBTZWN1cml0eSBNb2RlbCBSRkMgMjU3NCBbUkZDMjU3 NF0gYW5kIHRoZSBWaWV3LSBiYXNlZCBBY2Nlc3MgCiAgIENvbnRyb2wgTW9kZWwgUkZDIDI1NzUg W1JGQzI1NzVdIGlzIHJlY29tbWVuZGVkLiAgCiAgICAKICAgSXQgaXMgdGhlbiBhIGN1c3RvbWVy L3VzZXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdGhlIFNOTVAgCiAgIGVudGl0eSBn aXZpbmcgYWNjZXNzIHRvIGFuIGluc3RhbmNlIG9mIHRoaXMgTUlCLCBpcyBwcm9wZXJseSAKICAg Y29uZmlndXJlZCB0byBnaXZlIGFjY2VzcyB0byB0aGUgb2JqZWN0cyBvbmx5IHRvIHRob3NlIHBy aW5jaXBhbHMgCiAgICh1c2VycykgdGhhdCBoYXZlIGxlZ2l0aW1hdGUgcmlnaHRzIHRvIGluZGVl ZCBHRVQgb3IgU0VUIAogICAoY2hhbmdlL2NyZWF0ZS9kZWxldGUpIHRoZW0uICAKICAgIAogICAg CiAgICAKNi4gUmVmZXJlbmNlcyAKICAgIAogICBbUkZDMjU3MV0gICBIYXJyaW5ndG9uLCBELiwg UHJlc3VobiwgUi4sIGFuZCBCLiBXaWpuZW4sICAKICAgICAgICAgICAgICAgIkFuIEFyY2hpdGVj dHVyZSBmb3IgRGVzY3JpYmluZyBTTk1QIE1hbmFnZW1lbnQgICAKICAgICAgICAgICAgICAgRnJh bWV3b3JrcyIsIFJGQyAyNTcxLCBBcHJpbCAxOTk5LiAKICAgIAogICBbUkZDMTE1NV0gICBSb3Nl LCBNLiwgYW5kIEsuIE1jQ2xvZ2hyaWUsICAKICAgICAgICAgICAgICAgIlN0cnVjdHVyZSBhbmQg SWRlbnRpZmljYXRpb24gb2YgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiAgCiAgICAgICAgICAgICAg IGZvciBUQ1AvSVAtYmFzZWQgSW50ZXJuZXRzIiwgU1REIDE2LCBSRkMgMTE1NSwgTWF5IDE5OTAu IAogICAgCiAgIFtSRkMxMjEyXSAgIFJvc2UsIE0uLCBhbmQgSy4gTWNDbG9naHJpZSwgIAogICAg ICAgICAgICAgICAiQ29uY2lzZSBNSUIgRGVmaW5pdGlvbnMiLCBTVEQgMTYsIFJGQyAxMjEyLCBN YXJjaCAxOTkxLiAKICAgIAogICBbUkZDMTIxNV0gICBNLiBSb3NlLCAKICAgICAgICAgICAgICAg IkEgQ29udmVudGlvbiBmb3IgRGVmaW5pbmcgVHJhcHMgZm9yIHVzZSB3aXRoIHRoZSBTTk1QIiwg CiAgICAgICAgICAgICAgIFJGQyAxMjE1LCBNYXJjaCAxOTkxLiAKICAgIAogICBbUkZDMjU3OF0g ICBNY0Nsb2docmllLCBLLiwgUGVya2lucywgRC4sIFNjaG9lbndhZWxkZXIsIEouLCBDYXNlLEou LCAKICAgICAgICAgICAgICAgUm9zZSwgTS4sIGFuZCBTLiBXYWxkYnVzc2VyLCAiU3RydWN0dXJl IG9mIE1hbmFnZW1lbnQgCiAgICAgICAgICAgICAgIEluZm9ybWF0aW9uIFZlcnNpb24gMiAoU01J djIpIiwgU1REIDU4LCBSRkMgMjU3OCwgQXByaWwgCiAgICAgICAgICAgICAgIDE5OTkuIAogICAg CiAgIFtSRkMyNTc5XSAgIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRl ciwgSi4sIENhc2UsICAKICAgICAgICAgICAgICAgSi4sIFJvc2UsIE0uLCBhbmQgUy4gV2FsZGJ1 c3NlciwgIlRleHR1YWwgQ29udmVudGlvbnMgCiAgICAgICAgICAgICAgIGZvciBTTUl2MiIsIFNU RCA1OCwgUkZDIDI1NzksIEFwcmlsIDE5OTkuIAogICAgCiAgIFtSRkMyNTgwXSAgIE1jQ2xvZ2hy aWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENhc2UsICAKICAgICAgICAg ICAgICAgSi4sIFJvc2UsIE0uLCBhbmQgUy4gV2FsZGJ1c3NlciwgIkNvbmZvcm1hbmNlIFN0YXRl bWVudHMgIAogICAgICAgICAgICAgICBmb3IgU01JdjIiLCBTVEQgNTgsIFJGQyAyNTgwLCBBcHJp bCAxOTk5LiAKICAgIAogICBbUkZDMTE1N10gICBDYXNlLCBKLiwgRmVkb3IsIE0uLCBTY2hvZmZz dGFsbCwgTS4sIGFuZCBKLiBEYXZpbiwgIAogICAgICAgICAgICAgICAiU2ltcGxlIE5ldHdvcmsg TWFuYWdlbWVudCBQcm90b2NvbCIsIFNURCAxNSwgUkZDIDExNTcsICAKICAKVmFsZW50aW5lICAg ICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAgICA1 NiAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNlIFVuaXQgTUlC ICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICAgICAgICAgICAgICBNYXkgMTk5MC4gCiAgICAKICAg W1JGQzE5MDFdICAgQ2FzZSwgSi4sIE1jQ2xvZ2hyaWUsIEsuLCBSb3NlLCBNLiwgYW5kIFMuIFdh bGRidXNzZXIsIAogICAgICAgICAgICAgICAiSW50cm9kdWN0aW9uIHRvIENvbW11bml0eS1iYXNl ZCBTTk1QdjIiLCBSRkMgMTkwMSwgIAogICAgICAgICAgICAgICBKYW51YXJ5IDE5OTYuIAogICAg CiAgIFtSRkMxOTA2XSAgIENhc2UsIEouLCBNY0Nsb2docmllLCBLLiwgUm9zZSwgTS4sIGFuZCBT LiBXYWxkYnVzc2VyLCAKICAgICAgICAgICAgICAgIlRyYW5zcG9ydCBNYXBwaW5ncyBmb3IgVmVy c2lvbiAyIG9mIHRoZSBTaW1wbGUgTmV0d29yayAKICAgICAgICAgICAgICAgTWFuYWdlbWVudCBQ cm90b2NvbCAoU05NUHYyKSIsIFJGQyAxOTA2LCBKYW51YXJ5IDE5OTYuIAogICAgCiAgIFtSRkMy NTcyXSAgIENhc2UsIEouLCBIYXJyaW5ndG9uIEQuLCBQcmVzdWhuIFIuLCBhbmQgQi4gV2lqbmVu LCAgCiAgICAgICAgICAgICAgICJNZXNzYWdlIFByb2Nlc3NpbmcgYW5kIERpc3BhdGNoaW5nIGZv ciB0aGUgU2ltcGxlICAKICAgICAgICAgICAgICAgTmV0d29yayBNYW5hZ2VtZW50IFByb3RvY29s IChTTk1QKSIsIFJGQyAyNTcyLCBBcHJpbCAgCiAgICAgICAgICAgICAgIDE5OTkuIAogICAgCiAg IFtSRkMyNTc0XSAgIEJsdW1lbnRoYWwsIFUuLCBhbmQgQi4gV2lqbmVuLCAiVXNlci1iYXNlZCBT ZWN1cml0eSAgCiAgICAgICAgICAgICAgIE1vZGVsIChVU00pIGZvciB2ZXJzaW9uIDMgb2YgdGhl IFNpbXBsZSBOZXR3b3JrICAgCiAgICAgICAgICAgICAgIE1hbmFnZW1lbnQgUHJvdG9jb2wgKFNO TVB2MykiLCBSRkMgMjU3NCwgQXByaWwgMTk5OS4gCiAgICAKICAgW1JGQzE5MDVdICAgQ2FzZSwg Si4sIE1jQ2xvZ2hyaWUsIEsuLCBSb3NlLCBNLiwgYW5kIFMuIFdhbGRidXNzZXIsIAogICAgICAg ICAgICAgICAiUHJvdG9jb2wgT3BlcmF0aW9ucyBmb3IgVmVyc2lvbiAyIG9mIHRoZSBTaW1wbGUg TmV0d29yayAKICAgICAgICAgICAgICAgTWFuYWdlbWVudCBQcm90b2NvbCAoU05NUHYyKSIsIFJG QyAxOTA1LCBKYW51YXJ5IDE5OTYuIAogICAgCiAgIFtSRkMyNTczXSAgIExldmksIEQuLCBNZXll ciwgUC4sIGFuZCBCLiBTdGV3YXJ0LCAiU05NUHYzICAKICAgICAgICAgICAgICAgQXBwbGljYXRp b25zIiwgUkZDIDI1NzMsIEFwcmlsIDE5OTkuIAogICAgCiAgIFtSRkMyNTc1XSAgIFdpam5lbiwg Qi4sIFByZXN1aG4sIFIuLCBhbmQgSy4gTWNDbG9naHJpZSwgIlZpZXctYmFzZWQgCiAgICAgICAg ICAgICAgIEFjY2VzcyBDb250cm9sIE1vZGVsIChWQUNNKSBmb3IgdGhlIFNpbXBsZSBOZXR3b3Jr IAogICAgICAgICAgICAgICBNYW5hZ2VtZW50IFByb3RvY29sIChTTk1QKSIsIFJGQyAyNTc1LCBB cHJpbCAxOTk5LiAKICAgIAogICBbUkZDMjU3MF0gICBDYXNlLCBKLiwgTXVuZHksIFIuLCBQYXJ0 YWluLCBELiwgYW5kIEIuIFN0ZXdhcnQsIAogICAgICAgICAgICAgICAiSW50cm9kdWN0aW9uIHRv IFZlcnNpb24gMyBvZiB0aGUgSW50ZXJuZXQtc3RhbmRhcmQgIAogICAgICAgICAgICAgICBOZXR3 b3JrIE1hbmFnZW1lbnQgRnJhbWV3b3JrIiwgUkZDIDI1NzAsIEFwcmlsIDE5OTkuIAogICAgCiAg IFtSRkMxMjI0XSAgIFN0ZWluYmVyZywgTC4sICJUZWNobmlxdWVzIGZvciBNYW5hZ2luZyBBc3lu Y2hyb25vdXNseSAgCiAgICAgICAgICAgICAgIEdlbmVyYXRlZCBBbGVydHMiLCBSRkMgMTIyNCwg TWF5IDE5OTEuIAogICAgCiAgIFtSRkMyMTE5XSAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSAgCiAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExl dmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuIAogICAgCiAgIFtSRkMyODUxICAg IE0uIERhbmllbGUsIEIuIEhhYmVybWFuLCBTLiBSb3V0aGllciwgSi4gU2Nob2Vud2FlbGRlciwg CiAgICAgICAgICAgICAgICJUZXh0dWFsIENvbnZlbnRpb25zIGZvciBJbnRlcm5ldCBOZXR3b3Jr IEFkZHJlc3NlcyIsIAogICAgICAgICAgICAgICBKdW5lIDIwMDAgIAogICAgCiAgIFtFVVJPTV0g ICAgIEVDQ0EsIlRlY2huaWNhbCBTcGVjaWZpY2F0aW9uIG9mIGEgRXVyb3BlYW4gQ2FibGUgTW9k ZW0gIAogICAgICAgICAgICAgICBmb3IgZGlnaXRhbCBiaS1kaXJlY3Rpb25hbCBjb21tdW5pY2F0 aW9ucyB2aWEgY2FibGUgIAogICAgICAgICAgICAgICBuZXR3b3JrcyIsIFZlcnNpb24gMS4wLCAx MnRoIE1heSAxOTk5IAogICAgCiAgICAKNy4gQWNrbm93bGVkZ21lbnRzIAogICAgCgoKICAKVmFs ZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAg ICAgICAgICA1NyAMCiAgICAgICAgICAgICAgICAgRFZCIENhYmxlIE5ldHdvcmsgSW50ZXJmYWNl IFVuaXQgTUlCICAgIE5vdmVtYmVyIDIwMDAgCiAKIAogICBUaGlzIE1JQiB3YXMgdGhlIHJlc3Vs dCBvZiB0aGUgd29yayB1bmRlcnRha2VuIGJ5IERWQi9EQVZJQyAKICAgSW50ZXJvcGVyYWJpbGl0 eSBjb25zb3J0aXVtIHRvIGRlZmluZSBhIGNvbW1vbiBtYW5hZ2VtZW50IGludGVyZmFjZSAKICAg Zm9yIEV1cm9Nb2RlbSBjb21wbGlhbnQgTklVLiAKICAgIAogICBSRkMgMjY2OSBlZGl0ZWQgYnkg TWljaGFlbCBTdCBKb2hucyB3YXMgdXNlZCBhcyB0aGUgdGVtcGxhdGUgZm9yIAogICB0aGlzIGRv Y3VtZW50LiAKICAgIAogCjguIEF1dGhvcidzIEFkZHJlc3NlcyAKICAgIAogICBBbmRyZXcgVmFs ZW50aW5lIAogICBIdWdoZXMgTmV0d29yayBTeXN0ZW1zIEx0ZCAKICAgU2F4b24gU3RyZWV0LCAK ICAgTGluZm9yZCBXb29kLCAKICAgTWlsdG9uIEtleW5lcy4gCiAgIE1LMTQgNkxEIAogICBFTkdM QU5EIAogICBQaG9uZTogKzQ0IDE5MDggMjIxMTIyIAogICBFbWFpbDogYS52YWxlbnRpbmVAZXUu aG5zLmNvbSAKICAgIAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogIApWYWxlbnRp bmUgICAgICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDAgICAgICAgICAg ICAgIDU4IAwKICAgICAgICAgICAgICAgICBEVkIgQ2FibGUgTmV0d29yayBJbnRlcmZhY2UgVW5p dCBNSUIgICAgTm92ZW1iZXIgMjAwMCAKIAogCiAgICAKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50 IAogCgogICAiQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoZGF0ZSkuIEFsbCBS aWdodHMgUmVzZXJ2ZWQuIAogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQg bWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvIAogICBvdGhlcnMsIGFuZCBkZXJpdmF0aXZl IHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFpbiBpdCAKICAgb3IgYXNz aXN0IGluIGl0cyBpbXBsbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNo ZWQgCiAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0 cmljdGlvbiBvZiBhbnkgCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdo dCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIAogICBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2gg Y29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0aGlzIAogICBkb2N1bWVudCBp dHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5n IAogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBT b2NpZXR5IG9yIG90aGVyIAogICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVl ZGVkIGZvciB0aGUgcHVycG9zZSBvZiAKICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMg aW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgCiAgIGNvcHlyaWdodHMgZGVmaW5lZCBp biB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZSAKICAgZm9sbG93ZWQsIG9y IGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIAogICAgCiAgICAKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKICAKVmFsZW50aW5lICAgICAgIEluZm9ybWF0aW9uYWwg LSBFeHBpcmVzIFNlcHRlbWJlciAyMDAwICAgICAgICAgICAgICA1OSAM --0__=0025698C005CFB4E8f9e8a93df938690918c0025698C005CFB4E-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Mon Nov 6 16:09:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28039; Mon, 6 Nov 2000 16:09:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24930; Mon, 6 Nov 2000 16:07:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24904 for ; Mon, 6 Nov 2000 16:07:02 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27584 for ; Mon, 6 Nov 2000 16:06:56 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-83.cisco.com [161.44.133.83]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA07224 for ; Mon, 6 Nov 2000 16:06:27 -0500 (EST) Message-Id: <4.3.2.7.2.20001106155144.00b53760@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Nov 2000 16:08:00 -0500 To: ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] IPCDN Agenda Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, The IPCDN working group is scheduled to meet at the 49th IETF in San Diego, California. Our time slot is Wednesday morning, December 13th, 9:00am to 11:30am -- . Our current agenda is as follows: WG charter revision - Rich Woundy/Andy Valentine - 10 Min Euromodem MIB(s) update - Andy Valentine - 10 Min DOCSIS 1.1 QoS MIB update - - 20 Min? DOCSIS 1.1 Trap Definitions - Junming Gao - 20 Min DOCSIS Subscriber Management MIB - Rich Woundy - 5 Min (on behalf of Wilson Sawyer) RFC 2669 MIB Update update - Baseline Privacy MIB update - Rich Woundy - 10 Min Baseline Privacy Plus MIB update - Rich Woundy - 10 Min (on behalf of Stuart Green) Call for volunteers - Rich Woundy - 10 Min (e.g. telco-return MIB, IGMP over DOCSIS MIB) Any other business? I am still confirming some of the agenda items at this time. If someone else wants to make a presentation to the working group, please notify *both* Andrew Valentine and myself . Let us know how the presentation relates to the modification of one of the current RFCs or internet-drafts, or to the submission of a new internet-draft to this working group. Thanks. -- Richard Woundy, IPCDN co-chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Mon Nov 6 18:13:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12692; Mon, 6 Nov 2000 18:13:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26264; Mon, 6 Nov 2000 18:09:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26236 for ; Mon, 6 Nov 2000 18:09:28 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10824 for ; Mon, 6 Nov 2000 18:09:25 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-83.cisco.com [161.44.133.83]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA21230 for ; Mon, 6 Nov 2000 18:08:57 -0500 (EST) Message-Id: <4.3.2.7.2.20001106172121.00bdece0@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Nov 2000 18:10:30 -0500 To: ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, I just submitted a new version of the BPI MIB, draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. This revision is as a result of a review with the IETF MIB doctor. Most of the changes were minor textual changes, and will be listed in a separate email. However, I did want to point out a particular modification to the DESCRIPTION of two MIB objects. In particular, I added the sentence, "There is no restriction on the ability to change values in this row while the row is active", to the two RowStatus objects in the multicast portion of the BPI MIB: docsBpiIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address prefix mapping entry. There is no restriction on the ability to change values in this row while the row is active." ::= { docsBpiIpMulticastMapEntry 4 } docsBpiMulticastAuthControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the CM authorization for each multicast SID. There is no restriction on the ability to change values in this row while the row is active." ::= { docsBpiMulticastAuthEntry 3 } According to the definition of "RowStatus" in RFC 2579, the DESCRIPTION clause of a RowStatus column needs to "specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified." I followed the example of the Cable Device MIB, RFC 2669, which typically specifies that values in a row of a table can be changed while the row is active. For example, see docsDevNmAccessStatus, docsDevFilterLLCStatus, docsDevFilterIpStatus, and docsDevFilterTosStatus. A counter-example is the docsIfQosProfStatus in RFC 2670, which does not permit modifications when there are dependencies from the docsIfCmServiceTable and docsIfCmtsServiceTable on the docsIfQosProfileTable. My opinion was to follow the lead of the Cable Device MIB. Does anyone on the mailing list disagree? -- Richard Woundy _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Mon Nov 6 19:03:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02039; Mon, 6 Nov 2000 19:03:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26783; Mon, 6 Nov 2000 19:00:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26757 for ; Mon, 6 Nov 2000 19:00:56 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00907 for ; Mon, 6 Nov 2000 19:00:55 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-83.cisco.com [161.44.133.83]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA25204 for ; Mon, 6 Nov 2000 19:00:25 -0500 (EST) Message-Id: <4.3.2.7.2.20001106181142.00be5170@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Nov 2000 19:01:58 -0500 To: ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, I just submitted a new version of the BPI MIB, draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. This revision is as a result of a review with the IETF MIB doctor. Most of the changes were minor textual changes. I didn't send a copy of the new BPI MIB draft to the mailing list, but I will forward it by request. It should show up on the reflectors in the next few days. Here is a summary of changes between draft-ietf-ipcdn-mcns-bpi-mib-01.txt and draft-ietf-ipcdn-mcns-bpi-mib-02.txt. 1. I made minor textual changes to the Abstract, including a comment that CableLabs requires implementation of the BPI MIB: CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. 2. I updated the text of "The SNMP Management Framework" in section 1, per . 3. I made a minor editorial change to the "DOCSIS" definition in section 2.7. 4. I made a minor editorial change to the requirements for CMTS management in section 3.2, "Management requirements". I changed the wording from "The CMTS MUST support configuring and viewing all FSM-related parameters..." to "The CMTS MUST support viewing (and configuring if possible) all FSM-related parameters..." This is a better reflection of the current contents of the BPI MIB, not any real change in requirements or in the MIB structure itself. 5. I added a new section 3.3, "Textual convention", which states the following: CableLabs has required the implementation of prior versions of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. The Baseline Privacy Interface MIB contains eight MIB objects defined with the (now obsolete) DisplayString textual convention, and one MIB object defined with the (now undesirable) IpAddress textual convention. In the judgment of the working group, it is preferable to keep these less-than-desirable textual conventions, in order to maintain backward compatibility and interoperability with DOCSIS 1.0 cable modems that implemented previous versions of this MIB. 6. I added more descriptive text to the MODULE-IDENTITY object, docsBpiMIB, including more contact information, a statement about the CableLabs baseline privacy requirement, and new REVISION clauses. 7. I removed an extraneous sentence from the DESCRIPTION clauses of docsBpiCmAuthGraceTime, docsBpiCmTEKGraceTime, docsBpiCmAuthWaitTimeout, docsBpiCmReauthWaitTimeout, docsBpiCmOpWaitTimeout, docsBpiCmRekeyWaitTimeout, and docsBpiCmAuthRejectWaitTimeout. The removed sentence stated "The value of this object cannot be changed while the authorization state machine is running." All of these objects are read-only, so the sentence was misleading. 8. I added back the docsBpiCmtsDefaultAuthGraceTime and docsBpiCmtsDefaultTEKGraceTime MIB objects, clearly marking them as obsolete objects in the MIB. This prevents folks from accidentally reassigning the OIDs. I also added a new group, "docsBpiObsoleteObjectsGroup", so that the MIB compiled cleanly with the obsolete objects. 9. I added the following text to the DESCRIPTION clauses of docsBpiIpMulticastMapControl and docsBpiMulticastAuthControl: "There is no restriction on the ability to change values in this row while the row is active." RFC 2579 requires that the BPI MIB "specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified." I followed the examples of RowStatus objects in RFC 2669. 10. I updated the DOCSIS references, and added a reference to RFC 2570 to accommodate the new MIB boilerplate. -- Richard Woundy _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 7 06:09:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08105; Tue, 7 Nov 2000 06:09:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08826; Tue, 7 Nov 2000 06:03:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08798 for ; Tue, 7 Nov 2000 06:03:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05714; Tue, 7 Nov 2000 06:03:40 -0500 (EST) Message-Id: <200011071103.GAA05714@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: Tue, 07 Nov 2000 06:03:40 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-mcns-bpi-mib-02.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org --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 : Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy Filename : draft-ietf-ipcdn-mcns-bpi-mib-02.txt Pages : 44 Date : 06-Nov-00 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 the Baseline Privacy Interface, which provides data privacy for DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-mcns-bpi-mib-02.txt 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-mcns-bpi-mib-02.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-mcns-bpi-mib-02.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: <20001106120112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-mcns-bpi-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-mcns-bpi-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106120112.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 14:45:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08459; Thu, 9 Nov 2000 14:45:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24347; Thu, 9 Nov 2000 14:23:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24318 for ; Thu, 9 Nov 2000 14:23:42 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02190 for ; Thu, 9 Nov 2000 14:23:40 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 11:19:44 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4BF2@SCEXCH01> From: "Ziper, Anna" To: "'Kaz Ozawa'" , "'Stuart Green'" Cc: "'docsis-sec@cablelabs.com'" , "'docsis-oss@cablelabs.com'" , "'ipcdn@ietf.org'" Date: Thu, 9 Nov 2000 11:20:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="x-user-defined" Subject: [ipcdn] Multicast Mapping and Authorization Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Kaz and Stuart, I'd like to clarify some points on this issue. We had such conversation on reflector, but I still have some questions. There are two MIB tables for implementation BPI+ multicast. docsBpi2CmtsIpMulticastMapTable - this table maps multicast addresses to SAIDs. docsBpi2CmtsMulticastAuthTable - this table maps a multicast SAID to the CM that is authorized to use it. Both tables include data for dynamic and static SAIDs. For static SAIDs tables can include provisioned information. It is possible to get mapping an Ip address to a SAID using the first table, then to check a CM authorization for the SAID by the second table. But for dynamic SAIDs the tables include only tracking info. So for dynamic Ip multicast addresses CMTS creates the table entries by itself. The different behavior depended on type of SAID causes the problem of management these tables. 1. How CMTS can distinguish between static and dynamic Ip multicast addresses? 2. Both tables say: "Note: For dynamic multicast SAIDs, create access does not apply". I.e. if operator updates the table for dynamic SAID, CMTS should reject it? 3. The first table docsBpi2CmtsIpMulticastMapTable maps multicast addresses to SAIDs with ifIndex. Does it mean that different ifIndexes for the same multicast group can be mapped into different SAIDs? at least for static SAIDs. Can CMTS reject multi SAID mapping for the same multicast address? 4. What the meaning of mask in this table for dynamic SAID, if in this case entries created by CMTS. 5. Can we use these standard tables only as tracking info? I.e. they are filled only by CMTS. "Create access does not apply for both types of SAIDs". The question is there is any test that checks functionality of these tables for set. I am going to define our proprietary MIB table, that includes Multicast Ip Address, type of multicast address, Said (for dynamic CMTS creates by itself), and list of legal cable modems for the group. I want to be sure that there are no other standard tables included such info. I still want to set different ranges for static SAIDs and dynamic SAIDs to avoid collisions in numbers because different sources assign SAIDs. CMTS can update standard MIB tables using this one. Thank you, Anna _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 14:56:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12164; Thu, 9 Nov 2000 14:56:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24668; Thu, 9 Nov 2000 14:33:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24640 for ; Thu, 9 Nov 2000 14:33:41 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04979 for ; Thu, 9 Nov 2000 14:33:39 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 11:29:44 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4BF3@SCEXCH01> From: "Ziper, Anna" To: "'Rich Woundy'" , ipcdn@ietf.org Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Thu, 9 Nov 2000 11:30:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Hi, A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and not BPI MIB. Is it right? Thanks, Anna -----Original Message----- From: Rich Woundy [mailto:rwoundy@cisco.com] Sent: Monday, November 06, 2000 3:11 PM To: ipcdn@ietf.org Subject: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Folks, I just submitted a new version of the BPI MIB, draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. This revision is as a result of a review with the IETF MIB doctor. Most of the changes were minor textual changes, and will be listed in a separate email. However, I did want to point out a particular modification to the DESCRIPTION of two MIB objects. In particular, I added the sentence, "There is no restriction on the ability to change values in this row while the row is active", to the two RowStatus objects in the multicast portion of the BPI MIB: docsBpiIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address prefix mapping entry. There is no restriction on the ability to change values in this row while the row is active." ::= { docsBpiIpMulticastMapEntry 4 } docsBpiMulticastAuthControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the CM authorization for each multicast SID. There is no restriction on the ability to change values in this row while the row is active." ::= { docsBpiMulticastAuthEntry 3 } According to the definition of "RowStatus" in RFC 2579, the DESCRIPTION clause of a RowStatus column needs to "specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified." I followed the example of the Cable Device MIB, RFC 2669, which typically specifies that values in a row of a table can be changed while the row is active. For example, see docsDevNmAccessStatus, docsDevFilterLLCStatus, docsDevFilterIpStatus, and docsDevFilterTosStatus. A counter-example is the docsIfQosProfStatus in RFC 2670, which does not permit modifications when there are dependencies from the docsIfCmServiceTable and docsIfCmtsServiceTable on the docsIfQosProfileTable. My opinion was to follow the lead of the Cable Device MIB. Does anyone on the mailing list disagree? -- Richard Woundy _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 15:10:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18161; Thu, 9 Nov 2000 15:10:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25055; Thu, 9 Nov 2000 14:56:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25030 for ; Thu, 9 Nov 2000 14:56:29 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12099 for ; Thu, 9 Nov 2000 14:56:25 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 11:52:29 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4BF6@SCEXCH01> From: "Ziper, Anna" To: ipcdn@ietf.org Date: Thu, 9 Nov 2000 11:53:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Said Type Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Hi, Why type of Said is 32 bits, if it cannot be more than 14 bits? thank you, Anna _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 15:10:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18219; Thu, 9 Nov 2000 15:10:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25134; Thu, 9 Nov 2000 14:56:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25106 for ; Thu, 9 Nov 2000 14:56:56 -0500 (EST) Received: from cisco.com (frogger.cisco.com [171.71.161.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12272 for ; Thu, 9 Nov 2000 14:56:52 -0500 (EST) Received: from cisco.com (dhcp-71-150-186.cisco.com [171.71.150.186]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id LAA12268; Thu, 9 Nov 2000 11:55:42 -0800 (PST) Message-ID: <3A0B0109.415EABE7@cisco.com> Date: Thu, 09 Nov 2000 11:54:50 -0800 From: Azlina Ahmad Reply-To: azlina@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Ziper, Anna" CC: "'Rich Woundy'" , ipcdn@ietf.org Subject: Re: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt References: <37063C40296BD411A68400D0B7AF537AFC4BF3@SCEXCH01> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Correct. Azlina "Ziper, Anna" wrote: > Hi, > > A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and not BPI MIB. > Is it right? > > Thanks, > Anna > > -----Original Message----- > From: Rich Woundy [mailto:rwoundy@cisco.com] > Sent: Monday, November 06, 2000 3:11 PM > To: ipcdn@ietf.org > Subject: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > Folks, > > I just submitted a new version of the BPI MIB, > draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. This revision > is as a result of a review with the IETF MIB doctor. Most of the changes > were minor textual changes, and will be listed in a separate email. > > However, I did want to point out a particular modification to the > DESCRIPTION of two MIB objects. In particular, I added the sentence, "There > is no restriction on the ability to change values in this row while the row > is active", to the two RowStatus objects in the multicast portion of the > BPI MIB: > > docsBpiIpMulticastMapControl OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object controls and reflects the IP multicast address prefix > mapping entry. There is no restriction on the ability to change values > in this row while the row is active." > ::= { docsBpiIpMulticastMapEntry 4 } > > docsBpiMulticastAuthControl OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object controls and reflects the CM authorization for each > multicast SID. There is no restriction on the ability to change > values in this row while the row is active." > ::= { docsBpiMulticastAuthEntry 3 } > > According to the definition of "RowStatus" in RFC 2579, the DESCRIPTION > clause of a RowStatus column needs to "specify whether the status column > must not be `active' in order for the value of some other column of the > same conceptual row to be modified." > > I followed the example of the Cable Device MIB, RFC 2669, which typically > specifies that values in a row of a table can be changed while the row is > active. For example, see docsDevNmAccessStatus, docsDevFilterLLCStatus, > docsDevFilterIpStatus, and docsDevFilterTosStatus. A counter-example is the > docsIfQosProfStatus in RFC 2670, which does not permit modifications when > there are dependencies from the docsIfCmServiceTable and > docsIfCmtsServiceTable on the docsIfQosProfileTable. > > My opinion was to follow the lead of the Cable Device MIB. > > Does anyone on the mailing list disagree? > > -- Richard Woundy > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 15:34:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27078; Thu, 9 Nov 2000 15:34:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25860; Thu, 9 Nov 2000 15:21:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25822 for ; Thu, 9 Nov 2000 15:21:22 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22546 for ; Thu, 9 Nov 2000 15:21:14 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-60.cisco.com [161.44.133.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09515; Thu, 9 Nov 2000 15:20:43 -0500 (EST) Message-Id: <4.3.2.7.2.20001109151854.00bdd740@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Nov 2000 15:22:12 -0500 To: "Ziper, Anna" , ipcdn@ietf.org From: Rich Woundy Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt In-Reply-To: <37063C40296BD411A68400D0B7AF537AFC4BF3@SCEXCH01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ MIB, per the DOCSIS OSS specification. See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, . -- Rich At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: >Hi, > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and not BPI MIB. >Is it right? > >Thanks, >Anna > >-----Original Message----- >From: Rich Woundy [mailto:rwoundy@cisco.com] >Sent: Monday, November 06, 2000 3:11 PM >To: ipcdn@ietf.org >Subject: [ipcdn] possible issue with new version of BPI MIB: >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > >Folks, > >I just submitted a new version of the BPI MIB, >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. This revision >is as a result of a review with the IETF MIB doctor. Most of the changes >were minor textual changes, and will be listed in a separate email. > >However, I did want to point out a particular modification to the >DESCRIPTION of two MIB objects. In particular, I added the sentence, "There >is no restriction on the ability to change values in this row while the row >is active", to the two RowStatus objects in the multicast portion of the >BPI MIB: > >docsBpiIpMulticastMapControl OBJECT-TYPE >SYNTAX RowStatus >MAX-ACCESS read-create >STATUS current >DESCRIPTION >"This object controls and reflects the IP multicast address prefix >mapping entry. There is no restriction on the ability to change values >in this row while the row is active." >::= { docsBpiIpMulticastMapEntry 4 } > >docsBpiMulticastAuthControl OBJECT-TYPE >SYNTAX RowStatus >MAX-ACCESS read-create >STATUS current >DESCRIPTION >"This object controls and reflects the CM authorization for each >multicast SID. There is no restriction on the ability to change >values in this row while the row is active." >::= { docsBpiMulticastAuthEntry 3 } > >According to the definition of "RowStatus" in RFC 2579, the DESCRIPTION >clause of a RowStatus column needs to "specify whether the status column >must not be `active' in order for the value of some other column of the >same conceptual row to be modified." > >I followed the example of the Cable Device MIB, RFC 2669, which typically >specifies that values in a row of a table can be changed while the row is >active. For example, see docsDevNmAccessStatus, docsDevFilterLLCStatus, >docsDevFilterIpStatus, and docsDevFilterTosStatus. A counter-example is the >docsIfQosProfStatus in RFC 2670, which does not permit modifications when >there are dependencies from the docsIfCmServiceTable and >docsIfCmtsServiceTable on the docsIfQosProfileTable. > >My opinion was to follow the lead of the Cable Device MIB. > >Does anyone on the mailing list disagree? > >-- Richard Woundy > > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 16:25:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14716; Thu, 9 Nov 2000 16:25:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26543; Thu, 9 Nov 2000 15:52:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26515 for ; Thu, 9 Nov 2000 15:51:59 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03489 for ; Thu, 9 Nov 2000 15:51:57 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-60.cisco.com [161.44.133.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA13307; Thu, 9 Nov 2000 15:51:25 -0500 (EST) Message-Id: <4.3.2.7.2.20001109153718.00bebed0@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Nov 2000 15:52:55 -0500 To: "Ziper, Anna" , ipcdn@ietf.org From: Rich Woundy Subject: Re: [ipcdn] Said Type In-Reply-To: <37063C40296BD411A68400D0B7AF537AFC4BF6@SCEXCH01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Anna, I assume your question is in reference to the BPI+ MIB, and to objects that use "Integer32" SYNTAX to hold SAID values. A typical MIB object in the BPI+ MIB is: docsBpi2CmTEKSAId OBJECT-TYPE SYNTAX Integer32 (1..16383) ... The constraint of (1..16383) keeps this MIB object value to 14 bits. Note that this is actually the same syntax as docsIfCmServiceId (DOCSIS 1.0 SID) in RFC 2670. The DOCSIS 1.0 SID is also a 14 bit value. docsIfCmServiceId OBJECT-TYPE SYNTAX Integer32 (1..16383) ... According to RFC 2578, Integer32 is "indistinguishable from INTEGER, but never needs more than 32-bits for a two's complement representation". I think the MIB object SYNTAX is OK. Do you agree? -- Rich At 11:53 AM 11/9/00 -0800, Ziper, Anna wrote: >Hi, > >Why type of Said is 32 bits, >if it cannot be more than 14 bits? > >thank you, >Anna > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 17:15:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27419; Thu, 9 Nov 2000 17:15:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27653; Thu, 9 Nov 2000 17:00:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27623 for ; Thu, 9 Nov 2000 17:00:17 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23936 for ; Thu, 9 Nov 2000 17:00:16 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 13:56:21 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4BFC@SCEXCH01> From: "Ziper, Anna" To: "'Rich Woundy'" , "Ziper, Anna" , ipcdn@ietf.org Subject: RE: [ipcdn] Said Type Date: Thu, 9 Nov 2000 13:57:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Rich, You are right, if type Integer16 does not exist for MIBS? It looks like it is enough 16 bits for Said. thanks, Anna -----Original Message----- From: Rich Woundy [mailto:rwoundy@cisco.com] Sent: Thursday, November 09, 2000 12:53 PM To: Ziper, Anna; ipcdn@ietf.org Subject: Re: [ipcdn] Said Type Anna, I assume your question is in reference to the BPI+ MIB, and to objects that use "Integer32" SYNTAX to hold SAID values. A typical MIB object in the BPI+ MIB is: docsBpi2CmTEKSAId OBJECT-TYPE SYNTAX Integer32 (1..16383) ... The constraint of (1..16383) keeps this MIB object value to 14 bits. Note that this is actually the same syntax as docsIfCmServiceId (DOCSIS 1.0 SID) in RFC 2670. The DOCSIS 1.0 SID is also a 14 bit value. docsIfCmServiceId OBJECT-TYPE SYNTAX Integer32 (1..16383) ... According to RFC 2578, Integer32 is "indistinguishable from INTEGER, but never needs more than 32-bits for a two's complement representation". I think the MIB object SYNTAX is OK. Do you agree? -- Rich At 11:53 AM 11/9/00 -0800, Ziper, Anna wrote: >Hi, > >Why type of Said is 32 bits, >if it cannot be more than 14 bits? > >thank you, >Anna > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 17:35:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02713; Thu, 9 Nov 2000 17:35:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27906; Thu, 9 Nov 2000 17:27:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27878 for ; Thu, 9 Nov 2000 17:27:39 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00291 for ; Thu, 9 Nov 2000 17:27:37 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id XAA01564; Thu, 9 Nov 2000 23:27:35 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id XAA27931; Thu, 9 Nov 2000 23:27:35 +0100 Date: Thu, 9 Nov 2000 23:27:35 +0100 Message-Id: <200011092227.XAA27931@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: anna.ziper@terayon.com CC: rwoundy@cisco.com, ipcdn@ietf.org In-reply-to: <37063C40296BD411A68400D0B7AF537AFC4BFC@SCEXCH01> (anna.ziper@terayon.com) Subject: Re: [ipcdn] Said Type References: <37063C40296BD411A68400D0B7AF537AFC4BFC@SCEXCH01> Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org >>>>> Ziper, Anna writes: Anna> You are right, if type Integer16 does not exist for MIBS? It Anna> looks like it is enough 16 bits for Said. You can easily define a TEXTUAL-CONVENTION (TC) which introduces an Integer16. You can also introduce a more specific TCs for a SAID which has more specific semantics as an Integer16. I do not really know the context of this MIB, but it looks like you should consider to introduce TCs for these application specific types. And it is often also a good idea to introduce pairs of ID types, such as InterfaceIndex and InterfaceIndexOrZero in the IF-MIB. [Just ignore this comment if it does not apply here.] /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 18:32:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15947; Thu, 9 Nov 2000 18:32:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28458; Thu, 9 Nov 2000 18:13:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28428 for ; Thu, 9 Nov 2000 18:13:42 -0500 (EST) Received: from ariel.gi.com ([168.84.84.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11763 for ; Thu, 9 Nov 2000 18:13:40 -0500 (EST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWCA09DGHOEZLAC5@GI.COM> for ipcdn@ietf.org; Thu, 9 Nov 2000 15:13:09 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 09 Nov 2000 15:12:09 -0500 Content-return: allowed Date: Thu, 09 Nov 2000 18:15:15 -0500 From: "Holborow, Clive (SD-EX)" Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt To: "'Rich Woundy'" , "Ziper, Anna" , ipcdn@ietf.org Message-id: <973597126BDDD11197AA00805FA7EBC90387EEDF@ntas0026.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org It seems the OSS spec. writers need to talk to the BPI+ spec writers. See p146 of sp-bpi+-i05-000714. Item b) says in part: "..., a CMTS with Baseline Privacy Plus MUST be capable of falling back into a Baseline Privacy compatible mode of operation." Is this possible without support of the BPI MIB? The BPI MIB is all 1.0 CMs know about, and it has always been required that a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. The diagram on p37 of the 1.1 OSS spec makes it clear that 1.1 CMs must support both BPI and BPI+ MIBs. It doesn't make sense to me that the 1.1 CMTS does not also need to support both MIBs, since it should support a 1.1 CM operating in 1.0/BPI mode. Clive Holborow Motorola > -----Original Message----- > From: Rich Woundy [mailto:rwoundy@cisco.com] > Sent: Thursday, November 09, 2000 12:22 PM > To: Ziper, Anna; ipcdn@ietf.org > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > MIB, per the > DOCSIS OSS specification. > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > . > > -- Rich > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > >Hi, > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > not BPI MIB. > >Is it right? > > > >Thanks, > >Anna > > > >-----Original Message----- > >From: Rich Woundy [mailto:rwoundy@cisco.com] > >Sent: Monday, November 06, 2000 3:11 PM > >To: ipcdn@ietf.org > >Subject: [ipcdn] possible issue with new version of BPI MIB: > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > >Folks, > > > >I just submitted a new version of the BPI MIB, > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > This revision > >is as a result of a review with the IETF MIB doctor. Most > of the changes > >were minor textual changes, and will be listed in a separate email. > > > >However, I did want to point out a particular modification to the > >DESCRIPTION of two MIB objects. In particular, I added the > sentence, "There > >is no restriction on the ability to change values in this > row while the row > >is active", to the two RowStatus objects in the multicast > portion of the > >BPI MIB: > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > >SYNTAX RowStatus > >MAX-ACCESS read-create > >STATUS current > >DESCRIPTION > >"This object controls and reflects the IP multicast address prefix > >mapping entry. There is no restriction on the ability to > change values > >in this row while the row is active." > >::= { docsBpiIpMulticastMapEntry 4 } > > > >docsBpiMulticastAuthControl OBJECT-TYPE > >SYNTAX RowStatus > >MAX-ACCESS read-create > >STATUS current > >DESCRIPTION > >"This object controls and reflects the CM authorization for each > >multicast SID. There is no restriction on the ability to change > >values in this row while the row is active." > >::= { docsBpiMulticastAuthEntry 3 } > > > >According to the definition of "RowStatus" in RFC 2579, the > DESCRIPTION > >clause of a RowStatus column needs to "specify whether the > status column > >must not be `active' in order for the value of some other > column of the > >same conceptual row to be modified." > > > >I followed the example of the Cable Device MIB, RFC 2669, > which typically > >specifies that values in a row of a table can be changed > while the row is > >active. For example, see docsDevNmAccessStatus, > docsDevFilterLLCStatus, > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > counter-example is the > >docsIfQosProfStatus in RFC 2670, which does not permit > modifications when > >there are dependencies from the docsIfCmServiceTable and > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > >My opinion was to follow the lead of the Cable Device MIB. > > > >Does anyone on the mailing list disagree? > > > >-- Richard Woundy > > > > > >_______________________________________________ > >IPCDN mailing list > >IPCDN@ietf.org > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 20:54:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18342; Thu, 9 Nov 2000 20:54:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29995; Thu, 9 Nov 2000 20:39:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29967 for ; Thu, 9 Nov 2000 20:39:28 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14743 for ; Thu, 9 Nov 2000 20:39:26 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-60.cisco.com [161.44.133.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA09117; Thu, 9 Nov 2000 20:38:53 -0500 (EST) Message-Id: <4.3.2.7.2.20001109201752.00b7de60@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Nov 2000 20:40:23 -0500 To: "Holborow, Clive (SD-EX)" , "Ziper, Anna" From: Rich Woundy Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com In-Reply-To: <973597126BDDD11197AA00805FA7EBC90387EEDF@ntas0026.gi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Clive, You make a good argument. A DOCSIS 1.1 CMTS probably ought to implement both the BPI MIB and the BPI+ MIB, in anticipation of the simultaneous management of both DOCSIS 1.0 and 1.1 modems on the CMTS side. That would include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and docsBpiCmtsTEKTable, but hopefully *not* docsBpiIpMulticastMapTable nor docsBpiMulticastAuthTable (assuming that downstream multicast encryption is restricted to DOCSIS 1.1/BPI+ CMs). Does anyone disagree? However, my statement ("a DOCSIS 1.1 CMTS is only required to support the BPI+ MIB") is still literally true, until someone submits an ECR against the DOCSIS 1.1 OSS spec. I think this issue has to be resolved on the docsis-oss mailing list. -- Rich At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: >It seems the OSS spec. writers need to talk to the BPI+ spec writers. >See p146 of sp-bpi+-i05-000714. Item b) says in part: >"..., a CMTS with Baseline Privacy Plus MUST be capable of falling back into >a Baseline Privacy compatible mode of operation." > >Is this possible without support of the BPI MIB? >The BPI MIB is all 1.0 CMs know about, and it has always been required that >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > >The diagram on p37 of the 1.1 OSS spec makes it clear that 1.1 CMs must >support both BPI and BPI+ MIBs. >It doesn't make sense to me that the 1.1 CMTS does not also need to support >both MIBs, since it should support a 1.1 CM operating in 1.0/BPI mode. > >Clive Holborow >Motorola > > > -----Original Message----- > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > Sent: Thursday, November 09, 2000 12:22 PM > > To: Ziper, Anna; ipcdn@ietf.org > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > MIB, per the > > DOCSIS OSS specification. > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > . > > > > -- Rich > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > >Hi, > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > not BPI MIB. > > >Is it right? > > > > > >Thanks, > > >Anna > > > > > >-----Original Message----- > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > >Sent: Monday, November 06, 2000 3:11 PM > > >To: ipcdn@ietf.org > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > >Folks, > > > > > >I just submitted a new version of the BPI MIB, > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > This revision > > >is as a result of a review with the IETF MIB doctor. Most > > of the changes > > >were minor textual changes, and will be listed in a separate email. > > > > > >However, I did want to point out a particular modification to the > > >DESCRIPTION of two MIB objects. In particular, I added the > > sentence, "There > > >is no restriction on the ability to change values in this > > row while the row > > >is active", to the two RowStatus objects in the multicast > > portion of the > > >BPI MIB: > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > >SYNTAX RowStatus > > >MAX-ACCESS read-create > > >STATUS current > > >DESCRIPTION > > >"This object controls and reflects the IP multicast address prefix > > >mapping entry. There is no restriction on the ability to > > change values > > >in this row while the row is active." > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > >SYNTAX RowStatus > > >MAX-ACCESS read-create > > >STATUS current > > >DESCRIPTION > > >"This object controls and reflects the CM authorization for each > > >multicast SID. There is no restriction on the ability to change > > >values in this row while the row is active." > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > DESCRIPTION > > >clause of a RowStatus column needs to "specify whether the > > status column > > >must not be `active' in order for the value of some other > > column of the > > >same conceptual row to be modified." > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > which typically > > >specifies that values in a row of a table can be changed > > while the row is > > >active. For example, see docsDevNmAccessStatus, > > docsDevFilterLLCStatus, > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > counter-example is the > > >docsIfQosProfStatus in RFC 2670, which does not permit > > modifications when > > >there are dependencies from the docsIfCmServiceTable and > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > >Does anyone on the mailing list disagree? > > > > > >-- Richard Woundy > > > > > > > > >_______________________________________________ > > >IPCDN mailing list > > >IPCDN@ietf.org > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 9 20:58:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19154; Thu, 9 Nov 2000 20:58:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00128; Thu, 9 Nov 2000 20:49:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00092 for ; Thu, 9 Nov 2000 20:49:33 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17198 for ; Thu, 9 Nov 2000 20:49:32 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-60.cisco.com [161.44.133.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA09740; Thu, 9 Nov 2000 20:48:26 -0500 (EST) Message-Id: <4.3.2.7.2.20001109204705.00be6ef0@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Nov 2000 20:49:56 -0500 To: Juergen Schoenwaelder , anna.ziper@terayon.com From: Rich Woundy Subject: Re: [ipcdn] Said Type Cc: ipcdn@ietf.org In-Reply-To: <200011092227.XAA27931@henkell.ibr.cs.tu-bs.de> References: <37063C40296BD411A68400D0B7AF537AFC4BFC@SCEXCH01> <37063C40296BD411A68400D0B7AF537AFC4BFC@SCEXCH01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org I would let the BPI+ MIB author, and/or the consensus of the working group, decide whether such a new textual-convention is necessary for a SAID-related object. The BPI+ MIB is not strictly incorrect if it does not employ such a textual-convention... -- Rich At 11:27 PM 11/9/00 +0100, Juergen Schoenwaelder wrote: > >>>>> Ziper, Anna writes: > >Anna> You are right, if type Integer16 does not exist for MIBS? It >Anna> looks like it is enough 16 bits for Said. > >You can easily define a TEXTUAL-CONVENTION (TC) which introduces an >Integer16. You can also introduce a more specific TCs for a SAID which >has more specific semantics as an Integer16. > >I do not really know the context of this MIB, but it looks like you >should consider to introduce TCs for these application specific types. >And it is often also a good idea to introduce pairs of ID types, such >as InterfaceIndex and InterfaceIndexOrZero in the IF-MIB. > >[Just ignore this comment if it does not apply here.] > >/js > >-- >Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks >Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany >Fax: +49 531 391 5936 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Nov 10 11:23:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25806; Fri, 10 Nov 2000 11:23:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14353; Fri, 10 Nov 2000 11:04:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14294 for ; Fri, 10 Nov 2000 11:04:14 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18781 for ; Fri, 10 Nov 2000 11:04:13 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCVY2>; Fri, 10 Nov 2000 10:03:23 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D039B3EE@cadant1.cadant.com> From: "Schmitt, Matt" To: "'Rich Woundy'" , "Holborow, Clive (SD-EX)" , "Ziper, Anna" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, "'docsis-sec@cablelabs.com'" Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Fri, 10 Nov 2000 10:03:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org I disagree. The reason for that is that it is possible for a CMTS to support a CM in BPI mode using the BPI+ MIB. For the Base, Auth, and TEK tables, all of the objects included in the BPI MIB are also included in the BPI+ MIB. The BPI+ MIB merely expands some of these tables to add some new objects (which simply aren't populated for a BPI CM). In fact, one of the new objects indicates whether a modem is running BPI or BPI+, which indicates to me that the table was designed to handle both types of modems simultaneously. I believe there are other examples like this as well. For me, the only questions on these MIBs might relate to the multicast tables in the BPI MIB. The first question is whether or not a 1.1 CMTS can restrict encrypted multicast traffic to just 1.1 BPI+ CMs (as referenced by Rich) and still be conformant to the spec. I'd really like to hear some comments on that, since I've been trying to find an answer in the specs to that question without much luck. The next question would be whether or not the multicast tables in the BPI+ MIB could support 1.0 CMs if that capability was implemented. At a quick glance, it appears that they probably could, as long as the SAID in the BPI+ table translates to the SID of the BPI table. Thoughts? Matt -----Original Message----- From: Rich Woundy [mailto:rwoundy@cisco.com] Sent: Thursday, November 09, 2000 7:40 PM To: Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Clive, You make a good argument. A DOCSIS 1.1 CMTS probably ought to implement both the BPI MIB and the BPI+ MIB, in anticipation of the simultaneous management of both DOCSIS 1.0 and 1.1 modems on the CMTS side. That would include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and docsBpiCmtsTEKTable, but hopefully *not* docsBpiIpMulticastMapTable nor docsBpiMulticastAuthTable (assuming that downstream multicast encryption is restricted to DOCSIS 1.1/BPI+ CMs). Does anyone disagree? However, my statement ("a DOCSIS 1.1 CMTS is only required to support the BPI+ MIB") is still literally true, until someone submits an ECR against the DOCSIS 1.1 OSS spec. I think this issue has to be resolved on the docsis-oss mailing list. -- Rich At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: >It seems the OSS spec. writers need to talk to the BPI+ spec writers. >See p146 of sp-bpi+-i05-000714. Item b) says in part: >"..., a CMTS with Baseline Privacy Plus MUST be capable of falling back into >a Baseline Privacy compatible mode of operation." > >Is this possible without support of the BPI MIB? >The BPI MIB is all 1.0 CMs know about, and it has always been required that >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > >The diagram on p37 of the 1.1 OSS spec makes it clear that 1.1 CMs must >support both BPI and BPI+ MIBs. >It doesn't make sense to me that the 1.1 CMTS does not also need to support >both MIBs, since it should support a 1.1 CM operating in 1.0/BPI mode. > >Clive Holborow >Motorola > > > -----Original Message----- > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > Sent: Thursday, November 09, 2000 12:22 PM > > To: Ziper, Anna; ipcdn@ietf.org > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > MIB, per the > > DOCSIS OSS specification. > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > . > > > > -- Rich > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > >Hi, > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > not BPI MIB. > > >Is it right? > > > > > >Thanks, > > >Anna > > > > > >-----Original Message----- > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > >Sent: Monday, November 06, 2000 3:11 PM > > >To: ipcdn@ietf.org > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > >Folks, > > > > > >I just submitted a new version of the BPI MIB, > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > This revision > > >is as a result of a review with the IETF MIB doctor. Most > > of the changes > > >were minor textual changes, and will be listed in a separate email. > > > > > >However, I did want to point out a particular modification to the > > >DESCRIPTION of two MIB objects. In particular, I added the > > sentence, "There > > >is no restriction on the ability to change values in this > > row while the row > > >is active", to the two RowStatus objects in the multicast > > portion of the > > >BPI MIB: > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > >SYNTAX RowStatus > > >MAX-ACCESS read-create > > >STATUS current > > >DESCRIPTION > > >"This object controls and reflects the IP multicast address prefix > > >mapping entry. There is no restriction on the ability to > > change values > > >in this row while the row is active." > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > >SYNTAX RowStatus > > >MAX-ACCESS read-create > > >STATUS current > > >DESCRIPTION > > >"This object controls and reflects the CM authorization for each > > >multicast SID. There is no restriction on the ability to change > > >values in this row while the row is active." > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > DESCRIPTION > > >clause of a RowStatus column needs to "specify whether the > > status column > > >must not be `active' in order for the value of some other > > column of the > > >same conceptual row to be modified." > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > which typically > > >specifies that values in a row of a table can be changed > > while the row is > > >active. For example, see docsDevNmAccessStatus, > > docsDevFilterLLCStatus, > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > counter-example is the > > >docsIfQosProfStatus in RFC 2670, which does not permit > > modifications when > > >there are dependencies from the docsIfCmServiceTable and > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > >Does anyone on the mailing list disagree? > > > > > >-- Richard Woundy > > > > > > > > >_______________________________________________ > > >IPCDN mailing list > > >IPCDN@ietf.org > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Nov 10 15:10:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17748; Fri, 10 Nov 2000 15:10:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16953; Fri, 10 Nov 2000 14:28:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16924 for ; Fri, 10 Nov 2000 14:28:42 -0500 (EST) Received: from ns.intelenet.net ([204.182.160.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03360 for ; Fri, 10 Nov 2000 14:28:42 -0500 (EST) Received: from KazBook (att250-11.cablelabs.com [12.17.250.11]) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id LAA21272; Fri, 10 Nov 2000 11:28:29 -0800 (PST) From: "Kaz Ozawa" To: "Schmitt, Matt" , "'Rich Woundy'" , "Holborow, Clive \(SD-EX\)" , "Ziper, Anna" Cc: , , Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Date: Fri, 10 Nov 2000 12:25:26 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <5E1D5067851CD411BC900090270F79D039B3EE@cadant1.cadant.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit All, The DOCSIS 1.1 CMTS MUST support the BPI+ MIB tables but MUST NOT the BPI MIB tables. This is the current requirement. I believe all the CMTS BPI MIB objects are in the BPI+ MIB tables while I know we need many clarifications including the difference between the SAID in the BPI+ and the SID in the BPI. Thanks, kaz > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > Schmitt, Matt > Sent: Friday, November 10, 2000 9:03 AM > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; 'docsis-sec@cablelabs.com' > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > I disagree. > The reason for that is that it is possible for a CMTS to support a > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and TEK > tables, all > of the objects included in the BPI MIB are also included in the BPI+ MIB. > The BPI+ MIB merely expands some of these tables to add some new objects > (which simply aren't populated for a BPI CM). In fact, one of the new > objects indicates whether a modem is running BPI or BPI+, which > indicates to > me that the table was designed to handle both types of modems > simultaneously. I believe there are other examples like this as well. > For me, the only questions on these MIBs might relate to the > multicast tables in the BPI MIB. The first question is whether > or not a 1.1 > CMTS can restrict encrypted multicast traffic to just 1.1 BPI+ CMs (as > referenced by Rich) and still be conformant to the spec. I'd > really like to > hear some comments on that, since I've been trying to find an > answer in the > specs to that question without much luck. The next question would be > whether or not the multicast tables in the BPI+ MIB could support > 1.0 CMs if > that capability was implemented. At a quick glance, it appears that they > probably could, as long as the SAID in the BPI+ table translates > to the SID > of the BPI table. > Thoughts? > > Matt > > -----Original Message----- > From: Rich Woundy [mailto:rwoundy@cisco.com] > Sent: Thursday, November 09, 2000 7:40 PM > To: Holborow, Clive (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Clive, > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to implement > both the BPI MIB and the BPI+ MIB, in anticipation of the simultaneous > management of both DOCSIS 1.0 and 1.1 modems on the CMTS side. That would > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > docsBpiCmtsTEKTable, but hopefully *not* docsBpiIpMulticastMapTable nor > docsBpiMulticastAuthTable (assuming that downstream multicast > encryption is > restricted to DOCSIS 1.1/BPI+ CMs). > > Does anyone disagree? > > However, my statement ("a DOCSIS 1.1 CMTS is only required to support the > BPI+ MIB") is still literally true, until someone submits an ECR against > the DOCSIS 1.1 OSS spec. > > I think this issue has to be resolved on the docsis-oss mailing list. > > -- Rich > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > >It seems the OSS spec. writers need to talk to the BPI+ spec writers. > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > >"..., a CMTS with Baseline Privacy Plus MUST be capable of falling back > into > >a Baseline Privacy compatible mode of operation." > > > >Is this possible without support of the BPI MIB? > >The BPI MIB is all 1.0 CMs know about, and it has always been > required that > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that 1.1 CMs must > >support both BPI and BPI+ MIBs. > >It doesn't make sense to me that the 1.1 CMTS does not also need > to support > >both MIBs, since it should support a 1.1 CM operating in 1.0/BPI mode. > > > >Clive Holborow > >Motorola > > > > > -----Original Message----- > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > Sent: Thursday, November 09, 2000 12:22 PM > > > To: Ziper, Anna; ipcdn@ietf.org > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > MIB, per the > > > DOCSIS OSS specification. > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > . > > > > > > -- Rich > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > >Hi, > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > not BPI MIB. > > > >Is it right? > > > > > > > >Thanks, > > > >Anna > > > > > > > >-----Original Message----- > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > >Sent: Monday, November 06, 2000 3:11 PM > > > >To: ipcdn@ietf.org > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > >Folks, > > > > > > > >I just submitted a new version of the BPI MIB, > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > This revision > > > >is as a result of a review with the IETF MIB doctor. Most > > > of the changes > > > >were minor textual changes, and will be listed in a separate email. > > > > > > > >However, I did want to point out a particular modification to the > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > sentence, "There > > > >is no restriction on the ability to change values in this > > > row while the row > > > >is active", to the two RowStatus objects in the multicast > > > portion of the > > > >BPI MIB: > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > >SYNTAX RowStatus > > > >MAX-ACCESS read-create > > > >STATUS current > > > >DESCRIPTION > > > >"This object controls and reflects the IP multicast address prefix > > > >mapping entry. There is no restriction on the ability to > > > change values > > > >in this row while the row is active." > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > >SYNTAX RowStatus > > > >MAX-ACCESS read-create > > > >STATUS current > > > >DESCRIPTION > > > >"This object controls and reflects the CM authorization for each > > > >multicast SID. There is no restriction on the ability to change > > > >values in this row while the row is active." > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > DESCRIPTION > > > >clause of a RowStatus column needs to "specify whether the > > > status column > > > >must not be `active' in order for the value of some other > > > column of the > > > >same conceptual row to be modified." > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > which typically > > > >specifies that values in a row of a table can be changed > > > while the row is > > > >active. For example, see docsDevNmAccessStatus, > > > docsDevFilterLLCStatus, > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > counter-example is the > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > modifications when > > > >there are dependencies from the docsIfCmServiceTable and > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > >-- Richard Woundy > > > > > > > > > > > >_______________________________________________ > > > >IPCDN mailing list > > > >IPCDN@ietf.org > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Nov 10 15:10:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17787; Fri, 10 Nov 2000 15:10:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17268; Fri, 10 Nov 2000 14:41:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17238 for ; Fri, 10 Nov 2000 14:41:01 -0500 (EST) Received: from ariel.gi.com ([168.84.84.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08020 for ; Fri, 10 Nov 2000 14:41:00 -0500 (EST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWDGUUPQUQEZM04D@GI.COM> for ipcdn@ietf.org; Fri, 10 Nov 2000 11:40:26 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 11:39:25 -0500 Content-return: allowed Date: Fri, 10 Nov 2000 14:42:33 -0500 From: "Nakanishi, Greg" Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt To: "'Schmitt, Matt'" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" , "Ziper, Anna" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, "'docsis-sec@cablelabs.com'" Message-id: <97DEDE66B3DCD11199D200805FA71BE203BD7399@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org With regard to the multicast tables in the BPI+ MIB... I don't think the multicast mapping table, as defined in the BPI+ MIB, can be used to support both BPI and BPI+ simultaneously. BPI maps an IP address to a SID; whereas BPI+ maps an IP address to a SAID. With the exception of the primary SID, there is no relationship between a SAID and SID. It is possible that an IP multicast address has to map to a SAID for BPI+ CMs and to a SID for BPI CMs. This would result in two entries in the multicast mapping table for the same IP address without being able to differentiate whether the associated mapping is a SID or SAID. One solution would be to add another object in the mapping table to identify whether it is a SAID or SID. A higher level question is are any operators planning to do multicast to 1.0 CMs? If not, this would be a non-issue. The multicast mapping table could remain as-is and only map to SAIDs. greg Greg Nakanishi Motorola Cable Modem Engineering 6450 Sequence Drive, San Diego, CA 92121 (858) 404-2366 > -----Original Message----- > From: Schmitt, Matt [mailto:matt@cadant.com] > Sent: Friday, November 10, 2000 8:03 AM > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > 'docsis-sec@cablelabs.com' > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > I disagree. > The reason for that is that it is possible for a CMTS > to support a > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > TEK tables, all > of the objects included in the BPI MIB are also included in > the BPI+ MIB. > The BPI+ MIB merely expands some of these tables to add some > new objects > (which simply aren't populated for a BPI CM). In fact, one of the new > objects indicates whether a modem is running BPI or BPI+, > which indicates to > me that the table was designed to handle both types of modems > simultaneously. I believe there are other examples like this as well. > For me, the only questions on these MIBs might relate to the > multicast tables in the BPI MIB. The first question is > whether or not a 1.1 > CMTS can restrict encrypted multicast traffic to just 1.1 BPI+ CMs (as > referenced by Rich) and still be conformant to the spec. I'd > really like to > hear some comments on that, since I've been trying to find an > answer in the > specs to that question without much luck. The next question would be > whether or not the multicast tables in the BPI+ MIB could > support 1.0 CMs if > that capability was implemented. At a quick glance, it > appears that they > probably could, as long as the SAID in the BPI+ table > translates to the SID > of the BPI table. > Thoughts? > > Matt > > -----Original Message----- > From: Rich Woundy [mailto:rwoundy@cisco.com] > Sent: Thursday, November 09, 2000 7:40 PM > To: Holborow, Clive (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Clive, > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > implement > both the BPI MIB and the BPI+ MIB, in anticipation of the > simultaneous > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > side. That would > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > docsBpiCmtsTEKTable, but hopefully *not* > docsBpiIpMulticastMapTable nor > docsBpiMulticastAuthTable (assuming that downstream multicast > encryption is > restricted to DOCSIS 1.1/BPI+ CMs). > > Does anyone disagree? > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > support the > BPI+ MIB") is still literally true, until someone submits an > ECR against > the DOCSIS 1.1 OSS spec. > > I think this issue has to be resolved on the docsis-oss mailing list. > > -- Rich > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > >It seems the OSS spec. writers need to talk to the BPI+ spec writers. > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > falling back > into > >a Baseline Privacy compatible mode of operation." > > > >Is this possible without support of the BPI MIB? > >The BPI MIB is all 1.0 CMs know about, and it has always > been required that > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > 1.1 CMs must > >support both BPI and BPI+ MIBs. > >It doesn't make sense to me that the 1.1 CMTS does not also > need to support > >both MIBs, since it should support a 1.1 CM operating in > 1.0/BPI mode. > > > >Clive Holborow > >Motorola > > > > > -----Original Message----- > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > Sent: Thursday, November 09, 2000 12:22 PM > > > To: Ziper, Anna; ipcdn@ietf.org > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > MIB, per the > > > DOCSIS OSS specification. > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > . > > > > > > -- Rich > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > >Hi, > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > not BPI MIB. > > > >Is it right? > > > > > > > >Thanks, > > > >Anna > > > > > > > >-----Original Message----- > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > >Sent: Monday, November 06, 2000 3:11 PM > > > >To: ipcdn@ietf.org > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > >Folks, > > > > > > > >I just submitted a new version of the BPI MIB, > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > This revision > > > >is as a result of a review with the IETF MIB doctor. Most > > > of the changes > > > >were minor textual changes, and will be listed in a > separate email. > > > > > > > >However, I did want to point out a particular > modification to the > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > sentence, "There > > > >is no restriction on the ability to change values in this > > > row while the row > > > >is active", to the two RowStatus objects in the multicast > > > portion of the > > > >BPI MIB: > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > >SYNTAX RowStatus > > > >MAX-ACCESS read-create > > > >STATUS current > > > >DESCRIPTION > > > >"This object controls and reflects the IP multicast > address prefix > > > >mapping entry. There is no restriction on the ability to > > > change values > > > >in this row while the row is active." > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > >SYNTAX RowStatus > > > >MAX-ACCESS read-create > > > >STATUS current > > > >DESCRIPTION > > > >"This object controls and reflects the CM authorization for each > > > >multicast SID. There is no restriction on the ability to change > > > >values in this row while the row is active." > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > DESCRIPTION > > > >clause of a RowStatus column needs to "specify whether the > > > status column > > > >must not be `active' in order for the value of some other > > > column of the > > > >same conceptual row to be modified." > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > which typically > > > >specifies that values in a row of a table can be changed > > > while the row is > > > >active. For example, see docsDevNmAccessStatus, > > > docsDevFilterLLCStatus, > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > counter-example is the > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > modifications when > > > >there are dependencies from the docsIfCmServiceTable and > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > >-- Richard Woundy > > > > > > > > > > > >_______________________________________________ > > > >IPCDN mailing list > > > >IPCDN@ietf.org > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Nov 10 16:22:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11514; Fri, 10 Nov 2000 16:22:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18757; Fri, 10 Nov 2000 16:06:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18699 for ; Fri, 10 Nov 2000 16:06:39 -0500 (EST) Received: from ns.intelenet.net ([204.182.160.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06287 for ; Fri, 10 Nov 2000 16:06:40 -0500 (EST) Received: from KazBook (att250-11.cablelabs.com [12.17.250.11]) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id NAA03717; Fri, 10 Nov 2000 13:06:39 -0800 (PST) From: "Kaz Ozawa" To: "Nakanishi, Greg" Cc: , , Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Date: Fri, 10 Nov 2000 14:03:35 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE203BD739C@ntas0027.gi.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:06:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29939; Tue, 14 Nov 2000 18:06:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07114; Tue, 14 Nov 2000 18:05:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15106 for ; Fri, 10 Nov 2000 12:08:17 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11228 for ; Fri, 10 Nov 2000 12:08:16 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCV6G>; Fri, 10 Nov 2000 11:07:31 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D03DF3D1@cadant1.cadant.com> From: "White, David" To: "Schmitt, Matt" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" , "Ziper, Anna" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, "'docsis-sec@cablelabs.com'" , "Markovich, Joe" Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Fri, 10 Nov 2000 11:07:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Not only do I just disagree, I vehemently disagree. The BPI+ MIB was designed to handle both 1.0 and 1.1 CMs and replace the BPI MIB for 1.1 CMTSs. Requiring both MIBs would open the window to inconsistencies, require extra CMTS vendor work, extra CableLabs testing work, and most importantly, confuse customers. Until someone explains to me a concrete benefit of a 1.1 CMTS supporting both the BPI+ MIB and the BPI MIB, I will continue to vehemently disagree. David -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Friday, November 10, 2000 10:03 AM To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; 'docsis-sec@cablelabs.com' Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt I disagree. The reason for that is that it is possible for a CMTS to support a CM in BPI mode using the BPI+ MIB. For the Base, Auth, and TEK tables, all of the objects included in the BPI MIB are also included in the BPI+ MIB. The BPI+ MIB merely expands some of these tables to add some new objects (which simply aren't populated for a BPI CM). In fact, one of the new objects indicates whether a modem is running BPI or BPI+, which indicates to me that the table was designed to handle both types of modems simultaneously. I believe there are other examples like this as well. For me, the only questions on these MIBs might relate to the multicast tables in the BPI MIB. The first question is whether or not a 1.1 CMTS can restrict encrypted multicast traffic to just 1.1 BPI+ CMs (as referenced by Rich) and still be conformant to the spec. I'd really like to hear some comments on that, since I've been trying to find an answer in the specs to that question without much luck. The next question would be whether or not the multicast tables in the BPI+ MIB could support 1.0 CMs if that capability was implemented. At a quick glance, it appears that they probably could, as long as the SAID in the BPI+ table translates to the SID of the BPI table. Thoughts? Matt -----Original Message----- From: Rich Woundy [mailto:rwoundy@cisco.com] Sent: Thursday, November 09, 2000 7:40 PM To: Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Clive, You make a good argument. A DOCSIS 1.1 CMTS probably ought to implement both the BPI MIB and the BPI+ MIB, in anticipation of the simultaneous management of both DOCSIS 1.0 and 1.1 modems on the CMTS side. That would include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and docsBpiCmtsTEKTable, but hopefully *not* docsBpiIpMulticastMapTable nor docsBpiMulticastAuthTable (assuming that downstream multicast encryption is restricted to DOCSIS 1.1/BPI+ CMs). Does anyone disagree? However, my statement ("a DOCSIS 1.1 CMTS is only required to support the BPI+ MIB") is still literally true, until someone submits an ECR against the DOCSIS 1.1 OSS spec. I think this issue has to be resolved on the docsis-oss mailing list. -- Rich At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: >It seems the OSS spec. writers need to talk to the BPI+ spec writers. >See p146 of sp-bpi+-i05-000714. Item b) says in part: >"..., a CMTS with Baseline Privacy Plus MUST be capable of falling back into >a Baseline Privacy compatible mode of operation." > >Is this possible without support of the BPI MIB? >The BPI MIB is all 1.0 CMs know about, and it has always been required that >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > >The diagram on p37 of the 1.1 OSS spec makes it clear that 1.1 CMs must >support both BPI and BPI+ MIBs. >It doesn't make sense to me that the 1.1 CMTS does not also need to support >both MIBs, since it should support a 1.1 CM operating in 1.0/BPI mode. > >Clive Holborow >Motorola > > > -----Original Message----- > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > Sent: Thursday, November 09, 2000 12:22 PM > > To: Ziper, Anna; ipcdn@ietf.org > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > MIB, per the > > DOCSIS OSS specification. > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > . > > > > -- Rich > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > >Hi, > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > not BPI MIB. > > >Is it right? > > > > > >Thanks, > > >Anna > > > > > >-----Original Message----- > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > >Sent: Monday, November 06, 2000 3:11 PM > > >To: ipcdn@ietf.org > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > >Folks, > > > > > >I just submitted a new version of the BPI MIB, > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > This revision > > >is as a result of a review with the IETF MIB doctor. Most > > of the changes > > >were minor textual changes, and will be listed in a separate email. > > > > > >However, I did want to point out a particular modification to the > > >DESCRIPTION of two MIB objects. In particular, I added the > > sentence, "There > > >is no restriction on the ability to change values in this > > row while the row > > >is active", to the two RowStatus objects in the multicast > > portion of the > > >BPI MIB: > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > >SYNTAX RowStatus > > >MAX-ACCESS read-create > > >STATUS current > > >DESCRIPTION > > >"This object controls and reflects the IP multicast address prefix > > >mapping entry. There is no restriction on the ability to > > change values > > >in this row while the row is active." > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > >SYNTAX RowStatus > > >MAX-ACCESS read-create > > >STATUS current > > >DESCRIPTION > > >"This object controls and reflects the CM authorization for each > > >multicast SID. There is no restriction on the ability to change > > >values in this row while the row is active." > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > DESCRIPTION > > >clause of a RowStatus column needs to "specify whether the > > status column > > >must not be `active' in order for the value of some other > > column of the > > >same conceptual row to be modified." > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > which typically > > >specifies that values in a row of a table can be changed > > while the row is > > >active. For example, see docsDevNmAccessStatus, > > docsDevFilterLLCStatus, > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > counter-example is the > > >docsIfQosProfStatus in RFC 2670, which does not permit > > modifications when > > >there are dependencies from the docsIfCmServiceTable and > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > >Does anyone on the mailing list disagree? > > > > > >-- Richard Woundy > > > > > > > > >_______________________________________________ > > >IPCDN mailing list > > >IPCDN@ietf.org > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:06:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00020; Tue, 14 Nov 2000 18:06:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07246; Tue, 14 Nov 2000 18:05:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17931 for ; Fri, 10 Nov 2000 15:17:36 -0500 (EST) Received: from ariel.gi.com ([168.84.84.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20157 for ; Fri, 10 Nov 2000 15:17:34 -0500 (EST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWDI521TMQEZLZJW@GI.COM> for ipcdn@ietf.org; Fri, 10 Nov 2000 12:16:57 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 12:15:52 -0500 Content-return: allowed Date: Fri, 10 Nov 2000 15:19:01 -0500 From: "Nakanishi, Greg" Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt To: "'Kaz Ozawa'" , "'Schmitt, Matt'" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" , "Ziper, Anna" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Message-id: <97DEDE66B3DCD11199D200805FA71BE203BD739C@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Kaz, Isn't what you're suggesting essentially equivalent of getting rid of the concept of SAIDs and just using SIDs like it was in BPI? Another thing I noticed was that the index for the IP multicast mapping table will not allow two entries with the same IP address. That is, there couldn't be an entry that maps an IP address to an SAID and another entry that maps the same IP address to a SID. greg > -----Original Message----- > From: Kaz Ozawa [mailto:kaz@pobox.com] > Sent: Friday, November 10, 2000 12:01 PM > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Greg, > > I supposed that the CMTS could (and must) manage the relation > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > BPI. > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > indeces of the table, it must be unique. That is, all the SID > values must be different from all the SAID values. > Is this a problem? > > Thanks, > kaz > > > -----Original Message----- > > From: owner-docsis-sec@cablelabs.com > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > Sent: Friday, November 10, 2000 12:43 PM > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > 'docsis-sec@cablelabs.com' > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > I don't think the multicast mapping table, as defined in > the BPI+ MIB, can > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > IP address > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > exception of > > the primary SID, there is no relationship between a SAID and SID. > > > > It is possible that an IP multicast address has to map to a > SAID for BPI+ > > CMs and to a SID for BPI CMs. This would result in two > entries in the > > multicast mapping table for the same IP address without > being able to > > differentiate whether the associated mapping is a SID or SAID. > > > > One solution would be to add another object in the mapping table > > to identify > > whether it is a SAID or SID. > > > > A higher level question is are any operators planning to do > > multicast to 1.0 > > CMs? If not, this would be a non-issue. The multicast > mapping table could > > remain as-is and only map to SAIDs. > > > > greg > > > > Greg Nakanishi > > Motorola Cable Modem Engineering > > 6450 Sequence Drive, San Diego, CA 92121 > > (858) 404-2366 > > > > > > > -----Original Message----- > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > Sent: Friday, November 10, 2000 8:03 AM > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > I disagree. > > > The reason for that is that it is possible for a CMTS > > > to support a > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > TEK tables, all > > > of the objects included in the BPI MIB are also included in > > > the BPI+ MIB. > > > The BPI+ MIB merely expands some of these tables to add some > > > new objects > > > (which simply aren't populated for a BPI CM). In fact, > one of the new > > > objects indicates whether a modem is running BPI or BPI+, > > > which indicates to > > > me that the table was designed to handle both types of modems > > > simultaneously. I believe there are other examples like > this as well. > > > For me, the only questions on these MIBs might relate to the > > > multicast tables in the BPI MIB. The first question is > > > whether or not a 1.1 > > > CMTS can restrict encrypted multicast traffic to just 1.1 > BPI+ CMs (as > > > referenced by Rich) and still be conformant to the spec. I'd > > > really like to > > > hear some comments on that, since I've been trying to find an > > > answer in the > > > specs to that question without much luck. The next > question would be > > > whether or not the multicast tables in the BPI+ MIB could > > > support 1.0 CMs if > > > that capability was implemented. At a quick glance, it > > > appears that they > > > probably could, as long as the SAID in the BPI+ table > > > translates to the SID > > > of the BPI table. > > > Thoughts? > > > > > > Matt > > > > > > -----Original Message----- > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > Sent: Thursday, November 09, 2000 7:40 PM > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > Clive, > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > implement > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > simultaneous > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > side. That would > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > docsBpiCmtsTEKTable, but hopefully *not* > > > docsBpiIpMulticastMapTable nor > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > encryption is > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > Does anyone disagree? > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > support the > > > BPI+ MIB") is still literally true, until someone submits an > > > ECR against > > > the DOCSIS 1.1 OSS spec. > > > > > > I think this issue has to be resolved on the docsis-oss > mailing list. > > > > > > -- Rich > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > >It seems the OSS spec. writers need to talk to the BPI+ > spec writers. > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > falling back > > > into > > > >a Baseline Privacy compatible mode of operation." > > > > > > > >Is this possible without support of the BPI MIB? > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > been required that > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > 1.1 CMs must > > > >support both BPI and BPI+ MIBs. > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > need to support > > > >both MIBs, since it should support a 1.1 CM operating in > > > 1.0/BPI mode. > > > > > > > >Clive Holborow > > > >Motorola > > > > > > > > > -----Original Message----- > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > Subject: RE: [ipcdn] possible issue with new version > of BPI MIB: > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > MIB, per the > > > > > DOCSIS OSS specification. > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > . > > > > > > > > > > -- Rich > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > >Hi, > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > not BPI MIB. > > > > > >Is it right? > > > > > > > > > > > >Thanks, > > > > > >Anna > > > > > > > > > > > >-----Original Message----- > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > >To: ipcdn@ietf.org > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > This revision > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > of the changes > > > > > >were minor textual changes, and will be listed in a > > > separate email. > > > > > > > > > > > >However, I did want to point out a particular > > > modification to the > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > sentence, "There > > > > > >is no restriction on the ability to change values in this > > > > > row while the row > > > > > >is active", to the two RowStatus objects in the multicast > > > > > portion of the > > > > > >BPI MIB: > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > >SYNTAX RowStatus > > > > > >MAX-ACCESS read-create > > > > > >STATUS current > > > > > >DESCRIPTION > > > > > >"This object controls and reflects the IP multicast > > > address prefix > > > > > >mapping entry. There is no restriction on the ability to > > > > > change values > > > > > >in this row while the row is active." > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > >SYNTAX RowStatus > > > > > >MAX-ACCESS read-create > > > > > >STATUS current > > > > > >DESCRIPTION > > > > > >"This object controls and reflects the CM > authorization for each > > > > > >multicast SID. There is no restriction on the > ability to change > > > > > >values in this row while the row is active." > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > DESCRIPTION > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > status column > > > > > >must not be `active' in order for the value of some other > > > > > column of the > > > > > >same conceptual row to be modified." > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > which typically > > > > > >specifies that values in a row of a table can be changed > > > > > while the row is > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > docsDevFilterLLCStatus, > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > counter-example is the > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > modifications when > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >IPCDN mailing list > > > > > >IPCDN@ietf.org > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > IPCDN mailing list > > > > > IPCDN@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:06:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00053; Tue, 14 Nov 2000 18:06:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07299; Tue, 14 Nov 2000 18:06:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18673 for ; Fri, 10 Nov 2000 16:06:17 -0500 (EST) Received: from ns.intelenet.net ([204.182.160.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06172 for ; Fri, 10 Nov 2000 16:06:18 -0500 (EST) Received: from KazBook (att250-11.cablelabs.com [12.17.250.11]) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id NAA03657; Fri, 10 Nov 2000 13:06:10 -0800 (PST) From: "Kaz Ozawa" To: "Nakanishi, Greg" , "'Kaz Ozawa'" , "'Schmitt, Matt'" , "'Rich Woundy'" , "Holborow, Clive \(SD-EX\)" , "Ziper, Anna" Cc: , , Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Date: Fri, 10 Nov 2000 14:03:06 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE203BD739C@ntas0027.gi.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:06:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00143; Tue, 14 Nov 2000 18:06:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07371; Tue, 14 Nov 2000 18:06:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06767 for ; Sat, 11 Nov 2000 19:16:44 -0500 (EST) Received: from scbh01.terayon.com ([63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02524 for ; Sat, 11 Nov 2000 19:16:44 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Sat, 11 Nov 2000 16:12:44 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4C09@SCEXCH01> From: "Ziper, Anna" To: "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Schmitt, Matt'" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" , "Ziper, Anna" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Sat, 11 Nov 2000 16:13:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:09:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00926; Tue, 14 Nov 2000 18:09:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07160; Tue, 14 Nov 2000 18:05:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17618 for ; Fri, 10 Nov 2000 15:04:09 -0500 (EST) Received: from ns.intelenet.net ([204.182.160.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15661 for ; Fri, 10 Nov 2000 15:04:07 -0500 (EST) Received: from KazBook (att250-11.cablelabs.com [12.17.250.11]) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id MAA18420; Fri, 10 Nov 2000 12:03:55 -0800 (PST) From: "Kaz Ozawa" To: "Nakanishi, Greg" , "'Schmitt, Matt'" , "'Rich Woundy'" , "Holborow, Clive \(SD-EX\)" , "Ziper, Anna" Cc: , , Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Date: Fri, 10 Nov 2000 13:00:52 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE203BD7399@ntas0027.gi.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Greg, I supposed that the CMTS could (and must) manage the relation between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with BPI. The docsBpi2CmtsTEKTable is supposed to contain both the entries for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the indeces of the table, it must be unique. That is, all the SID values must be different from all the SAID values. Is this a problem? Thanks, kaz > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 12:43 PM > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; 'docsis-sec@cablelabs.com' > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > With regard to the multicast tables in the BPI+ MIB... > > I don't think the multicast mapping table, as defined in the BPI+ MIB, can > be used to support both BPI and BPI+ simultaneously. BPI maps an > IP address > to a SID; whereas BPI+ maps an IP address to a SAID. With the > exception of > the primary SID, there is no relationship between a SAID and SID. > > It is possible that an IP multicast address has to map to a SAID for BPI+ > CMs and to a SID for BPI CMs. This would result in two entries in the > multicast mapping table for the same IP address without being able to > differentiate whether the associated mapping is a SID or SAID. > > One solution would be to add another object in the mapping table > to identify > whether it is a SAID or SID. > > A higher level question is are any operators planning to do > multicast to 1.0 > CMs? If not, this would be a non-issue. The multicast mapping table could > remain as-is and only map to SAIDs. > > greg > > Greg Nakanishi > Motorola Cable Modem Engineering > 6450 Sequence Drive, San Diego, CA 92121 > (858) 404-2366 > > > > -----Original Message----- > > From: Schmitt, Matt [mailto:matt@cadant.com] > > Sent: Friday, November 10, 2000 8:03 AM > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > I disagree. > > The reason for that is that it is possible for a CMTS > > to support a > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > TEK tables, all > > of the objects included in the BPI MIB are also included in > > the BPI+ MIB. > > The BPI+ MIB merely expands some of these tables to add some > > new objects > > (which simply aren't populated for a BPI CM). In fact, one of the new > > objects indicates whether a modem is running BPI or BPI+, > > which indicates to > > me that the table was designed to handle both types of modems > > simultaneously. I believe there are other examples like this as well. > > For me, the only questions on these MIBs might relate to the > > multicast tables in the BPI MIB. The first question is > > whether or not a 1.1 > > CMTS can restrict encrypted multicast traffic to just 1.1 BPI+ CMs (as > > referenced by Rich) and still be conformant to the spec. I'd > > really like to > > hear some comments on that, since I've been trying to find an > > answer in the > > specs to that question without much luck. The next question would be > > whether or not the multicast tables in the BPI+ MIB could > > support 1.0 CMs if > > that capability was implemented. At a quick glance, it > > appears that they > > probably could, as long as the SAID in the BPI+ table > > translates to the SID > > of the BPI table. > > Thoughts? > > > > Matt > > > > -----Original Message----- > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > Sent: Thursday, November 09, 2000 7:40 PM > > To: Holborow, Clive (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Clive, > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > implement > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > simultaneous > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > side. That would > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > docsBpiCmtsTEKTable, but hopefully *not* > > docsBpiIpMulticastMapTable nor > > docsBpiMulticastAuthTable (assuming that downstream multicast > > encryption is > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > Does anyone disagree? > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > support the > > BPI+ MIB") is still literally true, until someone submits an > > ECR against > > the DOCSIS 1.1 OSS spec. > > > > I think this issue has to be resolved on the docsis-oss mailing list. > > > > -- Rich > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > >It seems the OSS spec. writers need to talk to the BPI+ spec writers. > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > falling back > > into > > >a Baseline Privacy compatible mode of operation." > > > > > >Is this possible without support of the BPI MIB? > > >The BPI MIB is all 1.0 CMs know about, and it has always > > been required that > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > 1.1 CMs must > > >support both BPI and BPI+ MIBs. > > >It doesn't make sense to me that the 1.1 CMTS does not also > > need to support > > >both MIBs, since it should support a 1.1 CM operating in > > 1.0/BPI mode. > > > > > >Clive Holborow > > >Motorola > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > MIB, per the > > > > DOCSIS OSS specification. > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > . > > > > > > > > -- Rich > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > >Hi, > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > not BPI MIB. > > > > >Is it right? > > > > > > > > > >Thanks, > > > > >Anna > > > > > > > > > >-----Original Message----- > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > >To: ipcdn@ietf.org > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > >Folks, > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > This revision > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > of the changes > > > > >were minor textual changes, and will be listed in a > > separate email. > > > > > > > > > >However, I did want to point out a particular > > modification to the > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > sentence, "There > > > > >is no restriction on the ability to change values in this > > > > row while the row > > > > >is active", to the two RowStatus objects in the multicast > > > > portion of the > > > > >BPI MIB: > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > >SYNTAX RowStatus > > > > >MAX-ACCESS read-create > > > > >STATUS current > > > > >DESCRIPTION > > > > >"This object controls and reflects the IP multicast > > address prefix > > > > >mapping entry. There is no restriction on the ability to > > > > change values > > > > >in this row while the row is active." > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > >SYNTAX RowStatus > > > > >MAX-ACCESS read-create > > > > >STATUS current > > > > >DESCRIPTION > > > > >"This object controls and reflects the CM authorization for each > > > > >multicast SID. There is no restriction on the ability to change > > > > >values in this row while the row is active." > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > DESCRIPTION > > > > >clause of a RowStatus column needs to "specify whether the > > > > status column > > > > >must not be `active' in order for the value of some other > > > > column of the > > > > >same conceptual row to be modified." > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > which typically > > > > >specifies that values in a row of a table can be changed > > > > while the row is > > > > >active. For example, see docsDevNmAccessStatus, > > > > docsDevFilterLLCStatus, > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > counter-example is the > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > modifications when > > > > >there are dependencies from the docsIfCmServiceTable and > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > >_______________________________________________ > > > > >IPCDN mailing list > > > > >IPCDN@ietf.org > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > _______________________________________________ > > > > IPCDN mailing list > > > > IPCDN@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:09:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00833; Tue, 14 Nov 2000 18:09:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07945; Tue, 14 Nov 2000 18:08:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09127 for ; Mon, 13 Nov 2000 12:09:41 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03158 for ; Mon, 13 Nov 2000 12:09:35 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCXFQ>; Mon, 13 Nov 2000 11:08:46 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D039B410@cadant1.cadant.com> From: "Schmitt, Matt" To: "'Ziper, Anna'" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "Schmitt, Matt" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 11:08:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:10:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01147; Tue, 14 Nov 2000 18:10:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07735; Tue, 14 Nov 2000 18:08:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11365 for ; Mon, 13 Nov 2000 14:29:29 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17689 for ; Mon, 13 Nov 2000 14:29:29 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 11:25:27 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4C0A@SCEXCH01> From: "Ziper, Anna" To: "'Schmitt, Matt'" , "Ziper, Anna" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 11:26:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:10:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01162; Tue, 14 Nov 2000 18:10:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08159; Tue, 14 Nov 2000 18:08:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14386 for ; Mon, 13 Nov 2000 18:07:42 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27801 for ; Mon, 13 Nov 2000 18:07:41 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCXVG>; Mon, 13 Nov 2000 17:06:56 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D039B425@cadant1.cadant.com> From: "Schmitt, Matt" To: "'Ziper, Anna'" , "Schmitt, Matt" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 17:06:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org My understanding of the definition of a static SAID is that it's one that's statically provisioned in the table. On the flip side, a dynamic SAID is automatically generated from learned information -- no operating input is involved. So by that defintion, if you're setting anything in the multicast MAP table, it's static. If it's populated by some other external action, then it's dynamic. Or put another way, for a static SAID, you populate the table, and for a dynamic SAID, the CMTS populates the table. BTW, when you mention "you've created entry for the SAID in the TEK table", do you mean when you the operator adds an entry, or when the CMTS adds an entry? Because my assumption is that once the SAID is created (either by static or dynamic means), a TEK state machine should be initiated on the CMTS, and the TEK table should automatically be populated by the CMTS as a part of that process. As for the Primary SAID issue... My assumption is that if the SAID # that you enter into the MulticastMapTable is the same as a Primary SAID, then it'll use the keying material for that Primary SAID. If so, this illustrates the potentially extreme danger of using static SAIDs -- if you accidentally use a Primary SAID when you don't mean to, I'm not quite sure what would happen. I guess you could think of that as a sharp stick for the operator. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 4:37 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt The BPI+ mib for docsBpiCmtsIpMulticastMapTable says "This table maps multicast IP addresses to SAIDs. It is intended to map BOTH dynamic and static multicast IP addresses." It is also says: "For dynamic multicast IP addresses, create access does not apply." It is clear that after you have the Ip multicast address mapping to SAID and you've created entry for the SAID in the TEK table you can find the type of SAID. But how you configure both tables. For example, CMTS gets snmpset for docsBpiCmtsIpMulticastMapTable for the multicast address, how do you know what kind of SAID this multicast address is going to use and if you should create it by yourself or wait for setting. An additional question: if this table can use primary SAID. I haven't found opposite, so I assume yes. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 2:14 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt As far as I'm aware, a multicast address is a multicast address -- it isn't static or dynamic. Static or dynamic just refers to the type of SAID being used: Static SAIDs are input into the table manually, and Dynamic SAIDs are added automatically. So as long as we've got a mapping from the multicast address to a SAID, we can use the TEK table to map that to the SA Type. Please, someone correct me if I'm going down the wrong road here. :) Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 3:29 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt I guess multicast address can be static or dynamic as well as type of Said. I think static or dynamic it is like type of application. Am I right? Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 1:16 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, I'm not sure I quite follow you... What are you referring to by "type of multicast address"? Thanks. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 1:27 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:10:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01176; Tue, 14 Nov 2000 18:10:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07972; Tue, 14 Nov 2000 18:08:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13581 for ; Mon, 13 Nov 2000 17:14:48 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13881 for ; Mon, 13 Nov 2000 17:14:48 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCXR7>; Mon, 13 Nov 2000 16:14:01 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D039B421@cadant1.cadant.com> From: "Schmitt, Matt" To: "'Ziper, Anna'" , "Schmitt, Matt" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 16:14:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org As far as I'm aware, a multicast address is a multicast address -- it isn't static or dynamic. Static or dynamic just refers to the type of SAID being used: Static SAIDs are input into the table manually, and Dynamic SAIDs are added automatically. So as long as we've got a mapping from the multicast address to a SAID, we can use the TEK table to map that to the SA Type. Please, someone correct me if I'm going down the wrong road here. :) Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 3:29 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt I guess multicast address can be static or dynamic as well as type of Said. I think static or dynamic it is like type of application. Am I right? Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 1:16 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, I'm not sure I quite follow you... What are you referring to by "type of multicast address"? Thanks. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 1:27 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:10:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01177; Tue, 14 Nov 2000 18:10:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08117; Tue, 14 Nov 2000 18:08:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13942 for ; Mon, 13 Nov 2000 17:40:13 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21671 for ; Mon, 13 Nov 2000 17:40:13 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 14:36:13 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4C0E@SCEXCH01> From: "Ziper, Anna" To: "'Schmitt, Matt'" , "Ziper, Anna" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 14:37:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org The BPI+ mib for docsBpiCmtsIpMulticastMapTable says "This table maps multicast IP addresses to SAIDs. It is intended to map BOTH dynamic and static multicast IP addresses." It is also says: "For dynamic multicast IP addresses, create access does not apply." It is clear that after you have the Ip multicast address mapping to SAID and you've created entry for the SAID in the TEK table you can find the type of SAID. But how you configure both tables. For example, CMTS gets snmpset for docsBpiCmtsIpMulticastMapTable for the multicast address, how do you know what kind of SAID this multicast address is going to use and if you should create it by yourself or wait for setting. An additional question: if this table can use primary SAID. I haven't found opposite, so I assume yes. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 2:14 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt As far as I'm aware, a multicast address is a multicast address -- it isn't static or dynamic. Static or dynamic just refers to the type of SAID being used: Static SAIDs are input into the table manually, and Dynamic SAIDs are added automatically. So as long as we've got a mapping from the multicast address to a SAID, we can use the TEK table to map that to the SA Type. Please, someone correct me if I'm going down the wrong road here. :) Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 3:29 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt I guess multicast address can be static or dynamic as well as type of Said. I think static or dynamic it is like type of application. Am I right? Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 1:16 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, I'm not sure I quite follow you... What are you referring to by "type of multicast address"? Thanks. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 1:27 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:10:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01232; Tue, 14 Nov 2000 18:10:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07891; Tue, 14 Nov 2000 18:08:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08729 for ; Mon, 13 Nov 2000 11:56:18 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28496 for ; Mon, 13 Nov 2000 11:56:17 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCX15>; Mon, 13 Nov 2000 10:55:26 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D039B40F@cadant1.cadant.com> From: "Schmitt, Matt" To: "'Kaz Ozawa'" , "Nakanishi, Greg" , "Schmitt, Matt" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" , "Ziper, Anna" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 10:55:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Kaz, Maybe I'm overlooking something, but I don't understand why a CMTS can't use the same number for a SID and a SAID. In fact, if a multicast SAID can be the same as the SID for a DS multicast flow, I don't see why the table in the BPI+ MIB can't be used for both BPI and BPI+ multicast. My apologies to everyone, but I need to kind of walk through this from the beginning, because I want to touch on some unicast and multicast issues with this. With unicast flows in DOCSIS 1.1, the SAID for all unicast traffic is the Primary SAID, which is equal to the SID of the primary US flow, and is used for all unicast US and DS traffic. In the 1.0 world, the SID (an US construct) is used as the security identifier for both US and DS traffic (though it is theoretically possible to have multiple SIDs in 1.0, I have the impression that the spec was written assuming 1, which is used for the DS as well). This makes the SID essentially the same as the Primary SAID, and I don't see a reason why in the unicast tables the 1.0 SID can't be used in the fields that call for the SAID. As for multicast, in 1.0, a SID is created specifically as a security identifier for a DS multicast traffic flow -- it has not US component. In 1.1, we create a SAID specifically as a security identifier for a DS multicast traffic flow. Excepting the fact that SAIDs come in two flavors (dynamic and static), is a multicast SID and a multicast SAID essentially the same thing? And why wouldn't it be possible to report a multicast SAID to a 1.0 CM as a multicast SID? And populate the tables in the BPI+ MIB with just the SAID, which would be seen by a 1.0 CM as a SID? Of course, the biggest issue is that of dynamic vs. static SAIDs, and their relationship to multicast SIDs. Thinking off the top of my head, I can see a couple of possible implementations. One would be to only associate static SAIDs with multicast SIDs (ie, a 1.0 CM can only do encrypted multicast with static SAIDs). Another would be for the CMTS to not differentiate between the two when reporting SIDs for multicast flows to a CM -- it reports the static one on the auth renewal after it's been input, and reports the dynamic one on the auth renewal after it's been generated in the CMTS. As I said, maybe I'm missing something, but I think this would work, and would appear to be a simple implementation than trying to maintain two completely separate functions. To be usable, they need to be merged together somehow on the CMTS end, IMHO. Then again, there's another, even much bigger issue -- the whole concept of a 1.1 CMTS doing encrypted multicast with a 1.0 CM. Is that capability even realistic? Is it desireable? For that matter, is it even required? Reading through the specs, I'm not convinced that it is required. I think it's unlikely that anyone's actually going to want to use such a function either. If that's the case, I'm less worried about spending a lot of time defining this. So before arguing anything else, perhaps those are the questions we really need to answer first. Matt -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 3:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:10:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01230; Tue, 14 Nov 2000 18:10:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07823; Tue, 14 Nov 2000 18:08:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12834 for ; Mon, 13 Nov 2000 16:17:03 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25839 for ; Mon, 13 Nov 2000 16:17:02 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCX35>; Mon, 13 Nov 2000 15:16:16 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D039B41E@cadant1.cadant.com> From: "Schmitt, Matt" To: "'Ziper, Anna'" , "Schmitt, Matt" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 15:16:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Anna, I'm not sure I quite follow you... What are you referring to by "type of multicast address"? Thanks. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 1:27 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:10:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01355; Tue, 14 Nov 2000 18:10:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07682; Tue, 14 Nov 2000 18:08:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14946 for ; Mon, 13 Nov 2000 18:57:34 -0500 (EST) Received: from cadant1.cadant.com ([209.170.120.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12139 for ; Mon, 13 Nov 2000 18:57:35 -0500 (EST) Received: by cadant1.cadant.com with Internet Mail Service (5.5.2650.21) id <4ZPXCXX6>; Mon, 13 Nov 2000 17:56:47 -0600 Message-ID: <5E1D5067851CD411BC900090270F79D039B428@cadant1.cadant.com> From: "Schmitt, Matt" To: "'Ziper, Anna'" , "Schmitt, Matt" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 17:56:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org 1. I can't say I'm familiar with how this would be implemented, but that sounds plausible. 2. In the BPI+ MIB (ver. 03), I think the equivalent to this is the PrefixLength parameter. My assumption is that for a dynamic SAID, this would most likely be 255.255.255.255. 3. Interesting point... As for the SAID ranges, I understand the logic -- it would protect operators. The question is, do we need to mandate that in the spec? Or is a sharp stick, and an opportunity for vendor differentiation (ie, an implementation issue)? I don't see why someone couldn't implement things this way, but I don't think they have to either. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 5:32 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, The way you are describing, it is implicit way to learn if the SAID is static or dynamic. I guess, it works. But I still have a few points that I don't understand. 1. How you can make your table read-only only for dynamic SAIDs. So every time you access to the docsBpiCmtsIpMulticastMapTable you should check in the TEK table if the SAID is dynamic or static. 2. There is a parameter called filter in docsBpiCmtsIpMulticastMapTable. It is a mask on Ip multicast addresses. In case of dynamic SAID this parameter is not used? 3. In the way the docsBpiCmtsIpMulticastMapTable is built, it is possible that different ifIndexes for the same Ip multicast address use different SAID. This state complicates things. About primary SAIDs... In case there are different ranges between SID (primary SAID), static SAID and dynamic SAID, their usage cannot be confused. What for I want to separate ranges. About TEK machine... I agree with your definition. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 3:07 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt My understanding of the definition of a static SAID is that it's one that's statically provisioned in the table. On the flip side, a dynamic SAID is automatically generated from learned information -- no operating input is involved. So by that defintion, if you're setting anything in the multicast MAP table, it's static. If it's populated by some other external action, then it's dynamic. Or put another way, for a static SAID, you populate the table, and for a dynamic SAID, the CMTS populates the table. BTW, when you mention "you've created entry for the SAID in the TEK table", do you mean when you the operator adds an entry, or when the CMTS adds an entry? Because my assumption is that once the SAID is created (either by static or dynamic means), a TEK state machine should be initiated on the CMTS, and the TEK table should automatically be populated by the CMTS as a part of that process As for the Primary SAID issue... My assumption is that if the SAID # that you enter into the MulticastMapTable is the same as a Primary SAID, then it'll use the keying material for that Primary SAID. If so, this illustrates the potentially extreme danger of using static SAIDs -- if you accidentally use a Primary SAID when you don't mean to, I'm not quite sure what would happen. I guess you could think of that as a sharp stick for the operator. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 4:37 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt The BPI+ mib for docsBpiCmtsIpMulticastMapTable says "This table maps multicast IP addresses to SAIDs. It is intended to map BOTH dynamic and static multicast IP addresses." It is also says: "For dynamic multicast IP addresses, create access does not apply." It is clear that after you have the Ip multicast address mapping to SAID and you've created entry for the SAID in the TEK table you can find the type of SAID. But how you configure both tables. For example, CMTS gets snmpset for docsBpiCmtsIpMulticastMapTable for the multicast address, how do you know what kind of SAID this multicast address is going to use and if you should create it by yourself or wait for setting. An additional question: if this table can use primary SAID. I haven't found opposite, so I assume yes. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 2:14 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt As far as I'm aware, a multicast address is a multicast address -- it isn't static or dynamic. Static or dynamic just refers to the type of SAID being used: Static SAIDs are input into the table manually, and Dynamic SAIDs are added automatically. So as long as we've got a mapping from the multicast address to a SAID, we can use the TEK table to map that to the SA Type. Please, someone correct me if I'm going down the wrong road here. :) Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 3:29 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt I guess multicast address can be static or dynamic as well as type of Said. I think static or dynamic it is like type of application. Am I right? Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 1:16 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, I'm not sure I quite follow you... What are you referring to by "type of multicast address"? Thanks. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 1:27 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:13:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02025; Tue, 14 Nov 2000 18:13:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08046; Tue, 14 Nov 2000 18:08:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13070 for ; Mon, 13 Nov 2000 16:31:42 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00523 for ; Mon, 13 Nov 2000 16:31:40 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 13:27:36 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4C0C@SCEXCH01> From: "Ziper, Anna" To: "'Schmitt, Matt'" , "Ziper, Anna" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 13:28:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org I guess multicast address can be static or dynamic as well as type of Said. I think static or dynamic it is like type of application. Am I right? Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 1:16 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, I'm not sure I quite follow you... What are you referring to by "type of multicast address"? Thanks. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 1:27 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Nov 14 18:13:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02072; Tue, 14 Nov 2000 18:13:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08186; Tue, 14 Nov 2000 18:08:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14774 for ; Mon, 13 Nov 2000 18:34:33 -0500 (EST) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05684 for ; Mon, 13 Nov 2000 18:34:32 -0500 (EST) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 15:30:32 -0800 Message-ID: <37063C40296BD411A68400D0B7AF537AFC4C10@SCEXCH01> From: "Ziper, Anna" To: "'Schmitt, Matt'" , "Ziper, Anna" , "'Kaz Ozawa'" , "Nakanishi, Greg" , "'Rich Woundy'" , "Holborow, Clive (SD-EX)" Cc: ipcdn@ietf.org, docsis-oss@cablelabs.com, docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Date: Mon, 13 Nov 2000 15:31:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Matt, The way you are describing, it is implicit way to learn if the SAID is static or dynamic. I guess, it works. But I still have a few points that I don't understand. 1. How you can make your table read-only only for dynamic SAIDs. So every time you access to the docsBpiCmtsIpMulticastMapTable you should check in the TEK table if the SAID is dynamic or static. 2. There is a parameter called filter in docsBpiCmtsIpMulticastMapTable. It is a mask on Ip multicast addresses. In case of dynamic SAID this parameter is not used? 3. In the way the docsBpiCmtsIpMulticastMapTable is built, it is possible that different ifIndexes for the same Ip multicast address use different SAID. This state complicates things. About primary SAIDs... In case there are different ranges between SID (primary SAID), static SAID and dynamic SAID, their usage cannot be confused. What for I want to separate ranges. About TEK machine... I agree with your definition. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 3:07 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt My understanding of the definition of a static SAID is that it's one that's statically provisioned in the table. On the flip side, a dynamic SAID is automatically generated from learned information -- no operating input is involved. So by that defintion, if you're setting anything in the multicast MAP table, it's static. If it's populated by some other external action, then it's dynamic. Or put another way, for a static SAID, you populate the table, and for a dynamic SAID, the CMTS populates the table. BTW, when you mention "you've created entry for the SAID in the TEK table", do you mean when you the operator adds an entry, or when the CMTS adds an entry? Because my assumption is that once the SAID is created (either by static or dynamic means), a TEK state machine should be initiated on the CMTS, and the TEK table should automatically be populated by the CMTS as a part of that process As for the Primary SAID issue... My assumption is that if the SAID # that you enter into the MulticastMapTable is the same as a Primary SAID, then it'll use the keying material for that Primary SAID. If so, this illustrates the potentially extreme danger of using static SAIDs -- if you accidentally use a Primary SAID when you don't mean to, I'm not quite sure what would happen. I guess you could think of that as a sharp stick for the operator. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 4:37 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt The BPI+ mib for docsBpiCmtsIpMulticastMapTable says "This table maps multicast IP addresses to SAIDs. It is intended to map BOTH dynamic and static multicast IP addresses." It is also says: "For dynamic multicast IP addresses, create access does not apply." It is clear that after you have the Ip multicast address mapping to SAID and you've created entry for the SAID in the TEK table you can find the type of SAID. But how you configure both tables. For example, CMTS gets snmpset for docsBpiCmtsIpMulticastMapTable for the multicast address, how do you know what kind of SAID this multicast address is going to use and if you should create it by yourself or wait for setting. An additional question: if this table can use primary SAID. I haven't found opposite, so I assume yes. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 2:14 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt As far as I'm aware, a multicast address is a multicast address -- it isn't static or dynamic. Static or dynamic just refers to the type of SAID being used: Static SAIDs are input into the table manually, and Dynamic SAIDs are added automatically. So as long as we've got a mapping from the multicast address to a SAID, we can use the TEK table to map that to the SA Type. Please, someone correct me if I'm going down the wrong road here. :) Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 3:29 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt I guess multicast address can be static or dynamic as well as type of Said. I think static or dynamic it is like type of application. Am I right? Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 1:16 PM To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, I'm not sure I quite follow you... What are you referring to by "type of multicast address"? Thanks. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Monday, November 13, 2000 1:27 PM To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Matt, I agree with you that NOT supporting DOCSIS1.0 multicast issue in DOCSIS1.1 CMTS simplifies things. Kaz, what is your opinion? Multicast SAID type in the TEK table does not help a lot. The table IpMulticastTable maps multicast Ip address to a SAID. The question: how do you know which multicast it is when you create row in the table? The TEK table gets knowledge about type of SAID, but not about type of multicast address. thanks, Anna -----Original Message----- From: Schmitt, Matt [mailto:matt@cadant.com] Sent: Monday, November 13, 2000 9:09 AM To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich Woundy'; Holborow, Clive (SD-EX) Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Anna, A few comments... Admittedly, I'm not a developer. But on the CMTS side, I'd think it would be a lot easier to implement just one set of MIB tables that handle all modems regardless of BPI or BPI+, vs. having separate tables for each type of modem. It also makes an operators job and life easier if they're combined. And I think this is the way the CMTS tables were designed. Regarding the benefit of BPI encrypted multicast, I think there's probably very little. As I understand it, there are very few (if any) MSO's using multicast with 1.0 systems, because of the lack of good support and definition. If that's true, it's unlikely that there will be much (if any) demand for using multicast with 1.0 modems, and I think it would be a wholly legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at all (or at least no support for encrypted multicast to 1.0 CMs). If we can come to that conclusion, it might make a lot of this discussion a lot easier. As for different ranges for different types of SAIDs, I'd look at that as an implementation issue rather than a spec issue. And as for distinguishing between different types of SAIDs, there actually is already a MIB object in the TEK table that does this. The docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or Dynamic. What's interesting to note is that in the description of the object, there is a statement to the effect that "Dynamic does not apply to CMs running in BPI mode." The implication, of course, is that the types of Primary and Static DO apply to CMs running in BPI mode. In other words, setting up a static SAID is the same as setting up a SID for multicast traffic on a 1.0 modem. So perhaps that's the right answer -- the static SAID and the 1.0 SID for multicast encryption are the same, which would allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS. Matt -----Original Message----- From: Ziper, Anna [mailto:anna.ziper@terayon.com] Sent: Saturday, November 11, 2000 6:14 PM To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt Kaz, To support BPI Multicast Mib in BPI+ Multicast Mib is very complicate and expensive in development. The question is how benefit the multicast feature in Bpi, and it is reasonable to leave this feature separated in BPI and BPI+. see my comments inline Thank you, Anna -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Friday, November 10, 2000 1:03 PM To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-ietf-ipcdn-mcns-bpi-mib-02.txt Greg, > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > Sent: Friday, November 10, 2000 1:19 PM > To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > (SD-EX); Ziper, Anna > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > Kaz, > > Isn't what you're suggesting essentially equivalent of getting rid of the > concept of SAIDs and just using SIDs like it was in BPI? Well..., yes and no. 1.0/BPI CM have to continue to rely on the SIDs. And the 1.1 CMTS which MUST be compatible to 1.0/BPI have to handle them. And the 1.1 CMTS must not use the same number for both SID and SAID. But, other than that, the SIDs and the SAIDs are isolated by definition. It is very good idea to use different numbers for SID and SAID, (only primary SAID is equal to SID), I'd separate between static and dynamic SAIDs ranges too. > > Another thing I noticed was that the index for the IP multicast mapping > table will not allow two entries with the same IP address. That is, there > couldn't be an entry that maps an IP address to an SAID and another entry > that maps the same IP address to a SID. This is a good point. Because of the difference of the key management rules between the BPI and the BPI+, it's not realistic to use the same number as both the SAID and the SID. The addition of the new object for the SID may be the solution. The object with type of Said can be very helpful, not even either SID or Said, but distinguish between dynamic, static and primary SAID. Thanks, kaz > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, November 10, 2000 12:01 PM > > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; docsis-sec@cablelabs.com > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > Greg, > > > > I supposed that the CMTS could (and must) manage the relation > > between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with > > BPI. > > > > The docsBpi2CmtsTEKTable is supposed to contain both the entries > > for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry > > for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the > > SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the > > indeces of the table, it must be unique. That is, all the SID > > values must be different from all the SAID values. > > Is this a problem? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > Sent: Friday, November 10, 2000 12:43 PM > > > To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive > > (SD-EX); Ziper, Anna > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > 'docsis-sec@cablelabs.com' > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > With regard to the multicast tables in the BPI+ MIB... > > > > > > I don't think the multicast mapping table, as defined in > > the BPI+ MIB, can > > > be used to support both BPI and BPI+ simultaneously. BPI maps an > > > IP address > > > to a SID; whereas BPI+ maps an IP address to a SAID. With the > > > exception of > > > the primary SID, there is no relationship between a SAID and SID. > > > > > > It is possible that an IP multicast address has to map to a > > SAID for BPI+ > > > CMs and to a SID for BPI CMs. This would result in two > > entries in the > > > multicast mapping table for the same IP address without > > being able to > > > differentiate whether the associated mapping is a SID or SAID. > > > > > > One solution would be to add another object in the mapping table > > > to identify > > > whether it is a SAID or SID. > > > > > > A higher level question is are any operators planning to do > > > multicast to 1.0 > > > CMs? If not, this would be a non-issue. The multicast > > mapping table could > > > remain as-is and only map to SAIDs. > > > > > > greg > > > > > > Greg Nakanishi > > > Motorola Cable Modem Engineering > > > 6450 Sequence Drive, San Diego, CA 92121 > > > (858) 404-2366 > > > > > > > > > > -----Original Message----- > > > > From: Schmitt, Matt [mailto:matt@cadant.com] > > > > Sent: Friday, November 10, 2000 8:03 AM > > > > To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com; > > > > 'docsis-sec@cablelabs.com' > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > I disagree. > > > > The reason for that is that it is possible for a CMTS > > > > to support a > > > > CM in BPI mode using the BPI+ MIB. For the Base, Auth, and > > > > TEK tables, all > > > > of the objects included in the BPI MIB are also included in > > > > the BPI+ MIB. > > > > The BPI+ MIB merely expands some of these tables to add some > > > > new objects > > > > (which simply aren't populated for a BPI CM). In fact, > > one of the new > > > > objects indicates whether a modem is running BPI or BPI+, > > > > which indicates to > > > > me that the table was designed to handle both types of modems > > > > simultaneously. I believe there are other examples like > > this as well. > > > > For me, the only questions on these MIBs might relate to the > > > > multicast tables in the BPI MIB. The first question is > > > > whether or not a 1.1 > > > > CMTS can restrict encrypted multicast traffic to just 1.1 > > BPI+ CMs (as > > > > referenced by Rich) and still be conformant to the spec. I'd > > > > really like to > > > > hear some comments on that, since I've been trying to find an > > > > answer in the > > > > specs to that question without much luck. The next > > question would be > > > > whether or not the multicast tables in the BPI+ MIB could > > > > support 1.0 CMs if > > > > that capability was implemented. At a quick glance, it > > > > appears that they > > > > probably could, as long as the SAID in the BPI+ table > > > > translates to the SID > > > > of the BPI table. > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -----Original Message----- > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > Sent: Thursday, November 09, 2000 7:40 PM > > > > To: Holborow, Clive (SD-EX); Ziper, Anna > > > > Cc: ipcdn@ietf.org; docsis-oss@cablelabs.com > > > > Subject: RE: [ipcdn] possible issue with new version of BPI MIB: > > > > draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > Clive, > > > > > > > > You make a good argument. A DOCSIS 1.1 CMTS probably ought to > > > > implement > > > > both the BPI MIB and the BPI+ MIB, in anticipation of the > > > > simultaneous > > > > management of both DOCSIS 1.0 and 1.1 modems on the CMTS > > > > side. That would > > > > include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and > > > > docsBpiCmtsTEKTable, but hopefully *not* > > > > docsBpiIpMulticastMapTable nor > > > > docsBpiMulticastAuthTable (assuming that downstream multicast > > > > encryption is > > > > restricted to DOCSIS 1.1/BPI+ CMs). > > > > > > > > Does anyone disagree? > > > > > > > > However, my statement ("a DOCSIS 1.1 CMTS is only required to > > > > support the > > > > BPI+ MIB") is still literally true, until someone submits an > > > > ECR against > > > > the DOCSIS 1.1 OSS spec. > > > > > > > > I think this issue has to be resolved on the docsis-oss > > mailing list. > > > > > > > > -- Rich > > > > > > > > At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote: > > > > >It seems the OSS spec. writers need to talk to the BPI+ > > spec writers. > > > > >See p146 of sp-bpi+-i05-000714. Item b) says in part: > > > > >"..., a CMTS with Baseline Privacy Plus MUST be capable of > > > > falling back > > > > into > > > > >a Baseline Privacy compatible mode of operation." > > > > > > > > > >Is this possible without support of the BPI MIB? > > > > >The BPI MIB is all 1.0 CMs know about, and it has always > > > > been required that > > > > >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs. > > > > > > > > > >The diagram on p37 of the 1.1 OSS spec makes it clear that > > > > 1.1 CMs must > > > > >support both BPI and BPI+ MIBs. > > > > >It doesn't make sense to me that the 1.1 CMTS does not also > > > > need to support > > > > >both MIBs, since it should support a 1.1 CM operating in > > > > 1.0/BPI mode. > > > > > > > > > >Clive Holborow > > > > >Motorola > > > > > > > > > > > -----Original Message----- > > > > > > From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > Sent: Thursday, November 09, 2000 12:22 PM > > > > > > To: Ziper, Anna; ipcdn@ietf.org > > > > > > Subject: RE: [ipcdn] possible issue with new version > > of BPI MIB: > > > > > > draft-iet f-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ > > > > > > MIB, per the > > > > > > DOCSIS OSS specification. > > > > > > > > > > > > See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, > > > > > > . > > > > > > > > > > > > -- Rich > > > > > > > > > > > > At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and > > > > > > not BPI MIB. > > > > > > >Is it right? > > > > > > > > > > > > > >Thanks, > > > > > > >Anna > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rich Woundy [mailto:rwoundy@cisco.com] > > > > > > >Sent: Monday, November 06, 2000 3:11 PM > > > > > > >To: ipcdn@ietf.org > > > > > > >Subject: [ipcdn] possible issue with new version of BPI MIB: > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt > > > > > > > > > > > > > > > > > > > > >Folks, > > > > > > > > > > > > > >I just submitted a new version of the BPI MIB, > > > > > > >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. > > > > > > This revision > > > > > > >is as a result of a review with the IETF MIB doctor. Most > > > > > > of the changes > > > > > > >were minor textual changes, and will be listed in a > > > > separate email. > > > > > > > > > > > > > >However, I did want to point out a particular > > > > modification to the > > > > > > >DESCRIPTION of two MIB objects. In particular, I added the > > > > > > sentence, "There > > > > > > >is no restriction on the ability to change values in this > > > > > > row while the row > > > > > > >is active", to the two RowStatus objects in the multicast > > > > > > portion of the > > > > > > >BPI MIB: > > > > > > > > > > > > > >docsBpiIpMulticastMapControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the IP multicast > > > > address prefix > > > > > > >mapping entry. There is no restriction on the ability to > > > > > > change values > > > > > > >in this row while the row is active." > > > > > > >::= { docsBpiIpMulticastMapEntry 4 } > > > > > > > > > > > > > >docsBpiMulticastAuthControl OBJECT-TYPE > > > > > > >SYNTAX RowStatus > > > > > > >MAX-ACCESS read-create > > > > > > >STATUS current > > > > > > >DESCRIPTION > > > > > > >"This object controls and reflects the CM > > authorization for each > > > > > > >multicast SID. There is no restriction on the > > ability to change > > > > > > >values in this row while the row is active." > > > > > > >::= { docsBpiMulticastAuthEntry 3 } > > > > > > > > > > > > > >According to the definition of "RowStatus" in RFC 2579, the > > > > > > DESCRIPTION > > > > > > >clause of a RowStatus column needs to "specify whether the > > > > > > status column > > > > > > >must not be `active' in order for the value of some other > > > > > > column of the > > > > > > >same conceptual row to be modified." > > > > > > > > > > > > > >I followed the example of the Cable Device MIB, RFC 2669, > > > > > > which typically > > > > > > >specifies that values in a row of a table can be changed > > > > > > while the row is > > > > > > >active. For example, see docsDevNmAccessStatus, > > > > > > docsDevFilterLLCStatus, > > > > > > >docsDevFilterIpStatus, and docsDevFilterTosStatus. A > > > > > > counter-example is the > > > > > > >docsIfQosProfStatus in RFC 2670, which does not permit > > > > > > modifications when > > > > > > >there are dependencies from the docsIfCmServiceTable and > > > > > > >docsIfCmtsServiceTable on the docsIfQosProfileTable. > > > > > > > > > > > > > >My opinion was to follow the lead of the Cable Device MIB. > > > > > > > > > > > > > >Does anyone on the mailing list disagree? > > > > > > > > > > > > > >-- Richard Woundy > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >IPCDN mailing list > > > > > > >IPCDN@ietf.org > > > > > > >http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPCDN mailing list > > > > > > IPCDN@ietf.org > > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Nov 17 13:35:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06014; Fri, 17 Nov 2000 13:35:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18044; Fri, 17 Nov 2000 13:29:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18014 for ; Fri, 17 Nov 2000 13:29:48 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03943; Fri, 17 Nov 2000 13:29:46 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-60.cisco.com [161.44.133.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24935; Fri, 17 Nov 2000 13:29:17 -0500 (EST) Message-Id: <4.3.2.7.2.20001117132708.00b8fed0@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Nov 2000 13:30:46 -0500 To: ipcdn@ietf.org From: Rich Woundy Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Current IPCDN agenda Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, The IPCDN working group is scheduled to meet at the 49th IETF in San Diego, California. Our time slot is Wednesday morning, December 13th, 9:00am to 11:30am -- . Our updated agenda is as follows: WG charter revision - Rich Woundy/Andy Valentine - 10 Min Euromodem MIB(s) update - Andy Valentine - 10 Min DOCSIS 1.1 QoS MIB update - Mike Patrick - 20 Min DOCSIS 1.1 Trap Definitions - Junming Gao - 20 Min DOCSIS Subscriber Management MIB - Rich Woundy - 5 Min (presenting on behalf of Wilson Sawyer) RFC 2669/2670 MIBs Update - Rich Woundy - 20 Min Baseline Privacy MIB update - Rich Woundy - 10 Min Baseline Privacy Plus MIB update - Rich Woundy - 10 Min (presenting on behalf of Stuart Green) DOCSIS Usage of RFC 2933 MIB - Rich Woundy - 10 Min (presenting on behalf of Howard Abramson) Call for volunteers (e.g. telco-return MIB) - Rich Woundy - 5 Min Any other business? -- Richard Woundy, IPCDN co-chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Nov 17 14:31:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00677; Fri, 17 Nov 2000 14:31:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18791; Fri, 17 Nov 2000 14:26:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18761 for ; Fri, 17 Nov 2000 14:26:29 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28458 for ; Fri, 17 Nov 2000 14:26:27 -0500 (EST) Received: from rwoundy-pc.cisco.com (ch2-dhcp133-60.cisco.com [161.44.133.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA02415; Fri, 17 Nov 2000 14:25:57 -0500 (EST) Message-Id: <4.3.2.7.2.20001117135129.00b9eb00@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Nov 2000 14:27:26 -0500 To: ipcdn@ietf.org, docsis-oss@cablelabs.com From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Some joint DOCSIS/IPCDN issues Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, Pak Siripunkaw and I had a phone call on joint DOCSIS/IPCDN issues on October 19th. This conversation generated new IPCDN work activities, which I wanted to communicate with the working groups. Note that *all* IPCDN decisions occur in public, as a group, on the ipcdn mailing list. No IPCDN working group decisions occurred on this phone call. Below are my notes on our conversation. We discussed three major subjects: DOCSIS applicability of RFC 2933 (formerly known as draft-ietf-ipcdn-igmp-mib-00.txt), new DOCSIS traps, and the "IP Spoofing Filters" in RFC 2669 (docsDevCpe group). * DOCSIS Applicability of RFC 2933 The DOCSIS OSS group has developed an Engineering Change Request to their OSS specification, ECR OSS-R-00106, that describes how the IGMP MIB defined in RFC 2933 applies to DOCSIS 1.1 cable modem environments. With respect to IGMP capability, a DOCSIS 1.1 CM or CMTS can act in "passive mode" (where it merely passes through subscriber IGMP messages) or in "active mode" (where it terminates subscriber IGMP messages and originates its own IGMP messages, such as in the role of an IGMP proxy or a multicast router). Similar functionality was originally proposed in IPCDN as draft-ietf-ipcdn-igmp-mib-00.txt, which was allowed to expire. Since our phone call, Howard Abramson (original author of draft-ietf-ipcdn-igmp-mib-00.txt) has agreed to reintroduce the text in OSS-R-00106 into an updated IPCDN internet-draft. Another related proposal was to extend the Cable Device MIB (RFC2669) to add one (or two) MIB objects that would manage the IGMP passive/active mode state of a DOCSIS 1.1 CM. In the two object version of the proposal, one object would report the current mode, and the other object would allow a manager to change the mode (if possible -- note that some modems are passive-only). * New DOCSIS Traps The DOCSIS OSS group has developed another Engineering Change Request to their OSS specification, ECR OSS-R-00108, that defines a set of trap OIDs for DOCSIS 1.1 cable modem environments (which might also be used for DOCSIS 1.0 as well). It also extends the RFC 2670 MIB with one new MIB object that indicates the DOCSIS operating mode (i.e. 1.0 versus 1.1). RFC 2669 section 3.2.2 defined requirements for trap definitions but explicitly did not define any standard trap OIDs. Since our phone call, Junming Gao (author of OSS-R-00108) and Pak Siripunkaw have agreed to create a new IPCDN internet-draft for the DOCSIS traps. * IP Spoofing Filters in RFC 2669 (docsDevCpe) Pak stated that several MSOs and DOCSIS vendors were encountering development and deployment difficulties with the IP Spoofing Filters in RFC 2669, i.e. the docsDevCpe group. The DOCSIS CM learns up to docsDevCpeIpMax IP addresses from subscriber equipment before packets are dropped. The default value for docsDevCpeIpMax is 1, which requires a DOCSIS configuration file override for many MSOs. The docsDevCpe group also appears to interfere with IP subnet renumbering, since the CM does not track DHCP conversations of subscriber equipment. Pak and I agreed that these issues needed to be discussed on both the docsis-oss and IPCDN mailing lists. The most attractive solution appears to be to make the docsDevCpe group functionality optional, though we are still debating a little bit on the right approach. One approach (Pak's) is to declare the docsDevCpe group MIB objects to be optional. The other approach (Rich's) is to declare the default value of docsDevCpeIpMax to be -1, since that value effectively makes the docsDevCpe group non-functional. Since our phone call, Pak has sent email on this subject to docsis-oss, which generated agreement from several vendors and no opposition. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Nov 17 19:49:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15531; Fri, 17 Nov 2000 19:49:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22331; Fri, 17 Nov 2000 19:48:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22302 for ; Fri, 17 Nov 2000 19:48:44 -0500 (EST) Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15508 for ; Fri, 17 Nov 2000 19:48:43 -0500 (EST) Received: from otdcpop.cadence.com (otdcpop.Cadence.COM [158.140.153.79]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id QAA29555; Fri, 17 Nov 2000 16:48:33 -0800 (PST) Received: from tality.com (annex-ottawa-04 [158.140.166.104]) by otdcpop.cadence.com (8.9.3/8.8.5) with ESMTP id TAA06096; Fri, 17 Nov 2000 19:47:11 -0500 (EST) Message-ID: <3A15D1DE.9540ED70@tality.com> Date: Fri, 17 Nov 2000 19:48:30 -0500 From: Andre Lejeune Organization: Tality Canada Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: fr-CA,en MIME-Version: 1.0 To: Rich Woundy CC: ipcdn@ietf.org, docsis-oss@cablelabs.com, Pak Siripunkaw References: <4.3.2.7.2.20001117135129.00b9eb00@funnel.cisco.com> Content-Type: text/plain; charset=iso-8859-1 X-Received: By mailgate2.Cadence.COM as QAA29555 at Fri Nov 17 16:48:33 2000 X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate2.Cadence.COM id QAA29555 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA22303 Subject: [ipcdn] Re: Some joint DOCSIS/IPCDN issues Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id TAA22331 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15531 Pak, Rich, About IP anti-spoofing, one solution does not prevent the other: declare the docsDevCpe group MIB objects to be optional AND declare the default value of docsDevCpeIpMax to be -1. This way, the solution (default of -1) that was put in place in oss-n-99090 would still be valid. I would not like it if it was now required to change 1.0 code that was providing the same results. André Rich Woundy wrote: > > Folks, > > Pak Siripunkaw and I had a phone call on joint DOCSIS/IPCDN issues on > October 19th. This conversation generated new IPCDN work activities, which > I wanted to communicate with the working groups. > > Note that *all* IPCDN decisions occur in public, as a group, on the ipcdn > mailing list. No IPCDN working group decisions occurred on this phone call. > > Below are my notes on our conversation. We discussed three major subjects: > DOCSIS applicability of RFC 2933 (formerly known as > draft-ietf-ipcdn-igmp-mib-00.txt), new DOCSIS traps, and the "IP Spoofing > Filters" in RFC 2669 (docsDevCpe group). > > * DOCSIS Applicability of RFC 2933 > > The DOCSIS OSS group has developed an Engineering Change Request to their > OSS specification, ECR OSS-R-00106, that describes how the IGMP MIB defined > in RFC 2933 applies to DOCSIS 1.1 cable modem environments. With respect to > IGMP capability, a DOCSIS 1.1 CM or CMTS can act in "passive mode" (where > it merely passes through subscriber IGMP messages) or in "active mode" > (where it terminates subscriber IGMP messages and originates its own IGMP > messages, such as in the role of an IGMP proxy or a multicast router). > > Similar functionality was originally proposed in IPCDN as > draft-ietf-ipcdn-igmp-mib-00.txt, which was allowed to expire. > > Since our phone call, Howard Abramson (original author of > draft-ietf-ipcdn-igmp-mib-00.txt) has agreed to reintroduce the text in > OSS-R-00106 into an updated IPCDN internet-draft. > > Another related proposal was to extend the Cable Device MIB (RFC2669) to > add one (or two) MIB objects that would manage the IGMP passive/active mode > state of a DOCSIS 1.1 CM. In the two object version of the proposal, one > object would report the current mode, and the other object would allow a > manager to change the mode (if possible -- note that some modems are > passive-only). > > * New DOCSIS Traps > > The DOCSIS OSS group has developed another Engineering Change Request to > their OSS specification, ECR OSS-R-00108, that defines a set of trap OIDs > for DOCSIS 1.1 cable modem environments (which might also be used for > DOCSIS 1.0 as well). It also extends the RFC 2670 MIB with one new MIB > object that indicates the DOCSIS operating mode (i.e. 1.0 versus 1.1). > > RFC 2669 section 3.2.2 defined requirements for trap definitions but > explicitly did not define any standard trap OIDs. > > Since our phone call, Junming Gao (author of OSS-R-00108) and Pak > Siripunkaw have agreed to create a new IPCDN internet-draft for the DOCSIS > traps. > > * IP Spoofing Filters in RFC 2669 (docsDevCpe) > > Pak stated that several MSOs and DOCSIS vendors were encountering > development and deployment difficulties with the IP Spoofing Filters in RFC > 2669, i.e. the docsDevCpe group. The DOCSIS CM learns up to docsDevCpeIpMax > IP addresses from subscriber equipment before packets are dropped. The > default value for docsDevCpeIpMax is 1, which requires a DOCSIS > configuration file override for many MSOs. The docsDevCpe group also > appears to interfere with IP subnet renumbering, since the CM does not > track DHCP conversations of subscriber equipment. > > Pak and I agreed that these issues needed to be discussed on both the > docsis-oss and IPCDN mailing lists. The most attractive solution appears to > be to make the docsDevCpe group functionality optional, though we are still > debating a little bit on the right approach. One approach (Pak's) is to > declare the docsDevCpe group MIB objects to be optional. The other approach > (Rich's) is to declare the default value of docsDevCpeIpMax to be -1, since > that value effectively makes the docsDevCpe group non-functional. > > Since our phone call, Pak has sent email on this subject to docsis-oss, > which generated agreement from several vendors and no opposition. > > -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Nov 22 06:05:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19972; Wed, 22 Nov 2000 06:05:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06255; Wed, 22 Nov 2000 06:03:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06217 for ; Wed, 22 Nov 2000 06:03:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19609; Wed, 22 Nov 2000 06:03:44 -0500 (EST) Message-Id: <200011221103.GAA19609@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, 22 Nov 2000 06:03:44 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-04.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org --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 Filename : draft-ietf-ipcdn-bpiplus-mib-04.txt Pages : 62 Date : 21-Nov-00 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-04.txt 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-04.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-04.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: <20001121110820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-bpiplus-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121110820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Nov 22 06:05:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19988; Wed, 22 Nov 2000 06:05:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06215; Wed, 22 Nov 2000 06:03:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06183 for ; Wed, 22 Nov 2000 06:03:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19593; Wed, 22 Nov 2000 06:03:40 -0500 (EST) Message-Id: <200011221103.GAA19593@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, 22 Nov 2000 06:03:40 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docsisevent-mib-00.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org --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 : Event Notification Management Information Base for DOCSIS 1.1 Compliant Cable Modems and Cable Modem Termination Systems Author(s) : J. Gao, P. Siripunkaw Filename : draft-ietf-ipcdn-docsisevent-mib-00.txt Pages : Date : 21-Nov-00 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 event notification management of DOCSIS 1.1 compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB, RFC 2669. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-00.txt 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-docsisevent-mib-00.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-docsisevent-mib-00.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: <20001121110812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docsisevent-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docsisevent-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121110812.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Nov 22 15:37:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00267; Wed, 22 Nov 2000 15:37:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14255; Wed, 22 Nov 2000 15:21:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14229 for ; Wed, 22 Nov 2000 15:21:37 -0500 (EST) Received: from riverstonenet.com (mail.yagosys.com [207.135.89.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24440 for ; Wed, 22 Nov 2000 15:21:34 -0500 (EST) Received: from mordor.yagosys.com by riverstonenet.com (8.8.8+Sun/SMI-SVR4-Yago) id MAA21091; Wed, 22 Nov 2000 12:18:09 -0800 (PST) Received: from valhalla.yagosys.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id MAA24112; Wed, 22 Nov 2000 12:21:34 -0800 Message-Id: <4.3.2.7.1.20001122103737.02e5ebf8@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Nov 2000 12:27:04 -0800 To: jgao@cisco.com, psiripunkaw@broadband.att.com From: Michael MacFaden Cc: ipcdn@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] draft-ietf-ipcdn-docsisevent-mib-00.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Hi, A good start on a trap mib for cable modems. Here are some things to consider in the next version. When defining traps using SMIv2, please be sure to follow the RFC 2576 section 2.1.2 so that it will be possible to have a DOCSIS 1.0 device implement the NOTIFICATIONS using SNMPv1 traps or for a Proxy to convert from SNMPv1 traps to SNMPv2c/V3 NOTIFICATIONS. Also, I'd like to introduce you to the work going on in SNMPCONF working group regarding designing traps. This working group is defining a Best Current Practice for Configuring Networks and Devices with SNMP. Here was the slide presentation at Pittsburg: http://www.ietf.org/proceedings/00jul/SLIDES/snmpconf-bcp-status/index.html The working group documents are here: http://www.ietf.org/html.charters/snmpconf-charter.html In particular, I hope the mib will consider these BCP's for trap mib design: 1) Since any traps sent are unreliable if sent in SNMPv1, be sure that there are underlying objects that can be polled. 2) Design in an upper limit to the number of traps of that may be sent. Otherwise, an object such as RFC 2115's frTrapMaxRate may be useful so that mgmt stations are not overwhelmed by thousands of cable modems. 3) Design traps so they can't be used in DoS attacks. The authTrap from RFC 1215 sends one trap for every bad snmp msg it gets. It is an example of how not to define an snmp trap and would be even worse if it was a notification that required acks from the mgmt station. If there were any other items you found useful in design, the snmpconf working group would be interested in them. Regards, Mike MacFaden Riverstone Networks, Inc www.riverstonenet.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Mon Nov 27 10:02:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05934; Mon, 27 Nov 2000 10:02:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29233; Mon, 27 Nov 2000 09:54:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29180 for ; Mon, 27 Nov 2000 09:54:50 -0500 (EST) Received: from basmail.basystems.com (basmail.basystems.com [209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03468 for ; Mon, 27 Nov 2000 09:54:46 -0500 (EST) Received: from habramson ([172.16.1.32]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 644; Mon, 27 Nov 2000 09:56:20 -0500 From: "Howard Abramson" To: Date: Mon, 27 Nov 2000 10:01:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C05858.F6CDE970" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ipcdn] Revised IPCDN IGMP MIB Note (draft-ipcdn-igmp-mib-01.txt) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C05858.F6CDE970 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id JAA29233 Content-Transfer-Encoding: quoted-printable Please see attached. Respectfully, Howard _____________________________________________________________ _/ _/ _/_/_/ _/_/_/ Howard D. Abramson _/ _/ _/ _/ _/ _/ ADC Telecommunications* _/_/_/_/ _/ _/ _/_/_/_/ 8 Technology Drive _/ _/ _/ _/ _/ _/ Westborough, MA 01581 _/ _/ _/_/_/ _/ _/ habramson@basystems.com _____________________________________________________________ * formerly Broadband Access Systems, Inc. IP over Cable Data Network (IPCDN) H. Abramson Internet Draft ADC Telecommunications Document: December 2000 Category: Informational Application of the IGMP MIB, RFC 2933, and Cable Device MIB, RFC 2669, to Docsis 1.1 Devices Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) Society (2000). All Rights Reserved. Abstract This memo describes the application of a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the application of the managed objects specified in RFC 2933, [19], and proposes a new object for the Cable Device MIB, RFC 2669 [25], for SNMP-based management of DOCSIS 1.1 IGMPv2 compliant interfaces. 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. Abramson Informational (Expires June 2001) 1 =0C Docsis 1.1 IGMPv2 MIB December 2000 Table of Contents 1. THE SNMP MANAGEMENT FRAMEWORK..............................3 2. GLOSSARY...................................................4 3. OVERVIEW...................................................5 4. DOCSIS 1.1 INTERFACE AND THE IGMP MIB......................6 4.1 DOCSIS 1.1 CM SUPPORT FOR THE IGMP MIB.................6 4.2 DOCSIS 1.1 CMTS SUPPORT FOR THE IGMP MIB..............13 4.3 IGMP MIB COMPLIANCE AND MIB OBJECT GROUPINGS..........20 5. DOCSIS 1.1 IGMP MODE CONTROL AND CABLE DEVICE MIB SUPORT..22 6. SECURITY CONSIDERATIONS...................................23 8. REFERENCES................................................25 9. ACKNOWLEDGMENTS...........................................27 10. AUTHOR'S ADDRESS..........................................27 Abramson Informational ( Expires June 2001) 2 =0C Docsis 1.1 IGMPv2 MIB December 2000 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [3]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [4], RFC 1212 [5] and RFC 1215 [6]. The second version, called SMIv2, is described in RFC 2578 [7], RFC 2579 [8] and RFC 2580 [9]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [10]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [11] and RFC 1906 [12]. The third version of the message protocol is called SNMPv3 and described in RFC 2574 [14], RFC 2272 [18] and RFC 2274 [19]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [10]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [15]. o A set of fundamental applications described in RFC 2273 [16] and the view-based access control mechanism described in RFC 2575 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo describes the application of a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Abramson Informational ( Expires June 2001) 3 =0C Docsis 1.1 IGMPv2 MIB December 2000 2. Glossary The following non-ietf terms are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification process. CATV - Originally 'Community Antenna Television', refers to cable or HFC (see below) system used to deliver video signals to a community. CM, Cable Modem - A CM acts as a 'slave' station in a DOCSIS compliant cable data system. CMTS, Cable Modem Termination System - A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs. CMCI - or Subscriber side, refers to the Cable Modem Customer Interface that connects to CPE on the CM. CPE - Customer Premise Equipment, non-Cable Modem IP Hosts attached to the Cable Modem. DOCSIS - 'Data Over Cable Interface Specification'. A term referring to the ITU-T J.112 Annex B standard for cable modem systems, [23] Downstream - From the head-end towards the subscriber. Head-end - The origination point in most cable systems of the subscriber video signals. Generally this is also the location of the CMTS equipment. HFC - Hybrid-Fiber-Coax, refers to physical wire(s) connecting the CMTS and CM. MAC Packet - A DOCSIS PDU. NSI - Network-Side-Interface, refers to interface(s) on the CMTS that are typically connected to the Internet. RF - Radio Frequency. Upstream - From the subscriber towards the head-end. 2.1 Conventions used in this document The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC-2119, [2]. Abramson Informational ( Expires June 2001) 4 =0C Docsis 1.1 IGMPv2 MIB December 2000 3. Overview The Docsis Multicast CM and CMTS interconnect specification can be modeled (or described) by 'splitting' the traditional Internet Group Management Protocol (IGMP), [22], interfaces into Host and Querier side interfaces. That is, to provide basic Docsis 1.1 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. It is expected that the root of each 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 MUST only be in the downstream direction (initiated by an NSI Querier or the CMTS itself). Host Membership Reporting is expected to be in the upstream direction (from CPE or active IGMP CM devices). The IGMPv2 MIB provides an excellent and standard means for managing multicast within such a network. 3.1 IGMP Capabilities: Active and Passive Mode 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 side (as described in [21]). A more complete example of an active IGMP device is that of a Multicast Router. Although a specific implementation is not imposed, the Docsis 1.1 device MUST meet the requirements stated in section 3.3.1 of [23] and MUST support the IDMR IGMP MIB, [20], and Cable Device MIB, [25], as described herein. As specified in the DOCSIS 1.1 RFI, active CMs are explicitly prohibited from transmitting IGMP Queries upstream onto the HFC. However, active CMTSs may transmit IGMP Queries on any of its interfaces. Abramson Informational ( Expires June 2001) 5 =0C Docsis 1.1 IGMPv2 MIB December 2000 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 Interface and the IGMP MIB DOCSIS 1.1 devices, CM and CMTS, MUST support the IDMR IGMP MIB (RFC-2933), [20]. As such, 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. 4.1 Docsis 1.1 CM Support for the IGMP MIB There are two types of interfaces applicable to IGMP on the DOCSIS 1.1 CM. These are the HFC-Side and CMCI-Side interfaces, respectively. Application of the IGMP MIB to DOCSIS 1.1 CMs is presented in terms of passive and active CM operation and these two interface types. 4.1.1 igmpInterfaceTable - igmpInterfaceEntry 4.1.1.1 igmpInterfaceIfIndex The ifIndex value of the interface for which IGMP is enabled. All Modes / Both sides: same for passive and active modes. HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV MAC Layer CMCI-side: not-accessible. ifIndex of CMCI-Side interface. Abramson Informational ( Expires June 2001) 6 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.1.1.2 igmpInterfaceQueryInterval The frequency at which IGMP Host-Query packets are transmitted on this interface. Passive Mode ------------ HFC-side: n/a, read-only. The CM MUST not transmit queries upstream. Return a value of zero. CMCI-side: read only . This value is derived based on the interval of queries received from an upstream querier. Active Mode ----------- HFC-side: n/a, read-only. The CM MUST not transmit queries upstream. Return a value of zero. CMCI-side: read-create. Min =3D 0; Max =3D (2^32 - 1); Default =3D 12= 5 4.1.1.3 igmpInterfaceStatus The activation of a row enables IGMP on the interface. The destruction of a row disables IGMP on the interface. All Modes / Both sides: MUST be enabled on both interfaces for all DOCSIS 1.1 CM interfaces. 4.1.1.4 igmpInterfaceVersion The version of IGMP which is running on this interface. All Modes / Both sides: MUST be version 2 for all DOCSIS 1.1 CM interfaces. 4.1.1.5 igmpInterfaceQuerier The address of the IGMP Querier on the IP subnet to which this interface is attached. Passive Mode ------------ HFC-side: read-only. MUST be the address of an upstream device for both active and passive CMs. CMCI-side: read-only. Same as HFC-side value. Active Mode ----------- HFC-side: read-only. MUST be the address of an upstream device for both active and passive CMs. CMCI-side: read-only. Active CMs may report it as the HFC-side value. However, active CMs that participate in IGMP Querier negotiation on the CMCI may report it as a different CPE. Abramson Informational ( Expires June 2001) 7 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.1.1.6 igmpInterfaceQueryMaxResponseTime The maximum query response time advertised in IGMPv2 queries on this interface. Passive Mode ------------ HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-only. This value is derived from observation of queries received from an upstream querier Active Mode ----------- HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100. 4.1.1.7 igmpInterfaceQuerierUpTime The time since igmpInterfaceQuerier was last changed. Passive Mode ----------- HFC-side: read-only. CMC-side: n/a, read-only. Return a value of zero. Active Mode ----------- HFC-side: read-only. CMCI-side: read-only. 4.1.1.8 igmpInterfaceQuerierExpiryTime The amount of time remaining before the other querier present timer expires. If the local system is the querier, the value of this object is zero. Passive Mode ------------ Both Sides: n/a, read-only. The CM is never the querier, return 0. Active Mode ----------- HFC-side: n/a, read-only. Return 0. CMCI-side: read-only. The CM may only be the querier on the CMCI. 4.1.1.9 igmpInterfaceVersion1QuerierTimer The time remaining until the host assumes that there are no IGMPv1 routers present on the interface. While this is non-zero, the host will reply to all queries with version 1 membership reports. Abramson Informational ( Expires June 2001) 8 =0C Docsis 1.1 IGMPv2 MIB December 2000 Passive Mode ------------ HFC-side: n/a read-only. Return a value of zero. CMCI-side: n/a read-only. Return a value of zero. Active Mode ----------- HFC-side: read-only. CMCI-side: read-only. 4.1.1.10 igmpInterfaceWrongVersionQueries The number of queries received whose IGMP version does not match igmpInterfaceVersion, over the lifetime of the row entry. IGMP requires that all routers on a LAN be configured to run the same version of IGMP. Although, DOCSIS 1.1 requires that all CM and CMTS devices support IGMPv2, it is possible for an upstream querier to be an IGMPv1 querier. All Modes / Both sides - read-only. The number of non-v2 queries received on this interface. 4.1.1.11 igmpInterfaceJoins The number of times a group membership has been added on this interface; that is, the number of times an entry for this interface has been added to the Cache Table. This object gives an indication of the amount of IGMP activity over the lifetime of the row entry. All HFC-side - n/a, read-only. Always return a value of zero (see CMCI-side). All CMCI-side - read-only. Group membership is defined to only exist on the CMCI. 4.1.1.12 igmpInterfaceProxyIfIndex Some devices implement a form of IGMP proxy whereby memberships learned on the interface represented by this row, cause IGMP Host Membership Reports to be sent on the interface whose ifIndex value is given by this object. Such a device would implement the igmpV2RouterMIBGroup only on its router interfaces (those interfaces with non-zero igmpInterfaceProxyIfIndex). Typically, the value of this object is 0, indicating that no proxy is being done. Passive Mode ------------ Both side: read-only. Always return a value of zero. Abramson Informational ( Expires June 2001) 9 =0C Docsis 1.1 IGMPv2 MIB December 2000 Active Mode ----------- HFC-side: read-only. Always return a value of zero. CMCI-side: read-only. Always return ifIndex for HFC-side interface. 4.1.1.13 igmpInterfaceGroups The current number of entries for this interface in the Cache Table (number of active sessions Proxied or Active on this Interface). All HFC-side - n/a, read-only. Always return a value of zero (see CMCI-side). All CMCI-side - read-only. Group membership is defined to only exist on the CMCI. 4.1.1.14 igmpInterfaceRobustness The robustness variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the robustness variable may be increased. IGMP is robust to (robustness variable-1) packet losses. Passive Mode ------------ HFC-side: n/a read-only. Return a value of zero. CMCI-side: n/a read-only. Return a value of zero. Active Mode ----------- Both sides: read-create. Min =3D 1; Max =3D (2^32 - 1); Default =3D 2 4.1.1.15 igmpInterfaceLastMemberQueryIntvl The last member query interval is the max response time inserted into group specific queries sent in response to leave group messages, and is also the amount of time between group specific query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group. Passive Mode ------------ HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-only. This value is derived from observation of queries received from an upstream querier Active Mode ----------- HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100. Abramson Informational ( Expires June 2001) 10 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.1.2 igmpCacheTable - igmpCacheEntry 4.1.2.1 igmpCacheAddress The IP multicast group address for which this entry contains information. All Modes / Both sides: Not-accessible (index). Report the address of active IP Multicast on the CMCI interface. 4.1.2.2 igmpCacheIfIndex The interface for which this entry contains information for an IP multicast group address. All Modes / CMCI side: MUST only apply to CMCI interface (e.g., membership is only active on subscriber side of CM). 4.1.2.3 igmpCacheSelf An indication of whether the local system is a member of this group address on this interface. Passive Mode / Both sides: read-only. MUST be set to FALSE. The CM is not a member of any group. Active Mode / Both sides: read-create. Implementation specific. If the CM is configured to be a member of the group, then membership reports are sent with the CMs IP Address but MUST ONLY be sent in proxy for active sessions on the CMCI (e.g., the CM MUST NOT be a member of a multicast group that is not active on the CMCI). If the CM is not configured to be a member, then the source IP Address of membership reports MUST be set to the current value of the igmpCacheLastReporter address. 4.1.2.4 igmpCacheLastReporter The IP address of the source of the last membership report received for this IP Multicast group address on this interface. If no membership report has been received, this object has the value of 0.0.0.0. All Modes / CMCI side: MUST only apply to last reporter on CMCI interface (e.g., membership only active on subscriber side of CM). Abramson Informational ( Expires June 2001) 11 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.1.2.5 igmpCacheUpTime The time elapsed since this entry was created. All Modes / CMCI side: read-only. MUST only apply to duration of membership on CMCI interface (e.g., membership is only active on subscriber side of CM). 4.1.2.6 igmpCacheExpiryTime The minimum amount of time remaining before this entry will be aged out. All Modes / Both sides - read-only. MUST only apply to duration of membership on CMCI interface (e.g., membership is only active on subscriber side of CM). 4.1.2.7 igmpCacheStatus The status of this entry. All Modes / CMCI side - read-create. MUST only apply to membership on CMCI interface (e.g., membership is only active on subscriber side of CM). Deletion of a row results in preventing downstream forwarding to this IP Multicast group address on this interface. 4.1.2.8 igmpCacheVersion1HostTimer The time remaining until the local querier will assume that there are no longer any IGMP version 1 members on this IP subnet attached to this interface. Upon hearing any IGMPv1 membership report, this value is reset to the group membership timer. While this time remaining is non-zero, the local querier ignores any IGMPv2 leave messages for this group that it receives on this interface. Passive Mode ------------ Both side: n/a, read-only. Return a value of zero. Active Mode ----------- HFC-side: n/a, read-only. Return a value of zero. CMCI-side: read-only. Abramson Informational ( Expires June 2001) 12 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.2 Docsis 1.1 CMTS Support for the IGMP MIB There are two types of interfaces applicable to IGMP on the DOCSIS 1.1 CMTS. These are the NSI-Side and NSI-Side interfaces, respectively. Application of the IGMP MIB to DOCSIS 1.1 CMTSs is presented in terms of passive and active CMTS operation and these two interface types. In contrast to a CM, the CMTS is likely to have several NSI-side interfaces and several HFC-side (subscriber-side) interfaces. It is important to note that an active IGMP capable CMTS may be implemented as a proxy, router, or hybrid device. As such, the CMTS may be capable of querying on both its NSI and HFC side interfaces and may manage membership for devices on its NSI interfaces (e.g., as a multicast router). This is different than an active CM, which MUST NOT query on its HFC side interface (e.g., it may only query on its CMCI). This capability is accounted for in the application of the IGMP MIB to the CMTS. 4.2.1 igmpInterfaceTable- igmpInterfaceEntry 4.2.1.1 igmpInterfaceIfIndex The ifIndex value of the interface for which IGMP is enabled. All Modes --------- This is the same for passive and active modes. NSI-side: not-accessible. ifIndex of applicable network side interface(s). HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV MAC Layer interface. 4.2.1.2 igmpInterfaceQueryInterval The frequency at which IGMP Host-Query packets are transmitted on this interface. Passive Mode ------------ NSI-side: n/a, read-only. Return a value of zero. HFC-side: read only . This value is derived based on the interval of queries received from a Network Side querier. Active Mode ----------- NSI-side: read-create. Min =3D 0; Max =3D (2^32 - 1); Default =3D 12= 5 HFC-side: read-create. Min =3D 0; Max =3D (2^32 - 1); Default =3D 12= 5 Abramson Informational ( Expires June 2001) 13 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.2.1.3 igmpInterfaceStatus All Modes / All Interfaces: the activation of a row enables IGMP on the interface. The destruction of a row disables IGMP on the interface. 4.2.1.4 igmpInterfaceVersion The version of IGMP which is running on this interface. MUST be version 2 for all DOCSIS 1.1 CMTS interfaces. 4.2.1.5 igmpInterfaceQuerier The address of the IGMP Querier on the IP subnet to which this interface is attached. Passive Mode ------------ NSI-side: read-only. This is the address of a network side device. HFC-side: read-only. Same as NSI-side value. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Active CMTSs MUST report this as an IP Address assigned to the CMTS' HFC-side interface. That is, queries MUST not originate from CMs or CPE. 4.2.1.6 igmpInterfaceQueryMaxResponseTime The maximum query response time advertised in IGMPv2 queries on this interface. Passive Mode ------------ NSI-side: n/a, read-only. return a value of zero. HFC-side: read-only. This value is derived from observation of queries received from a network side querier. Active Mode ----------- NSI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100. HFC-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100. 4.2.1.7 igmpInterfaceQuerierUpTime The time since igmpInterfaceQuerier was last changed. Passive Mode ----------- NSI-side: read-only. HFC-side: n/a, read-only. Return a value of zero. Abramson Informational ( Expires June 2001) 14 =0C Docsis 1.1 IGMPv2 MIB December 2000 Active Mode ----------- NSI-side: read-only. HFC-side: read-only. 4.2.1.8 igmpInterfaceQuerierExpiryTime The amount of time remaining before the other querier present timer expires. If the local system is the querier, the value of this object is zero. Passive Mode ------------ All interfaces: n/a, read-only. The CMTS is not a querier, return 0. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. The CMTS MUST be the only querier on the HFC. 4.2.1.9 igmpInterfaceVersion1QuerierTimer The time remaining until the host assumes that there are no IGMPv1 routers present on the interface. While this is non-zero, the host will reply to all queries with version 1 membership reports. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. 4.2.1.10 igmpInterfaceWrongVersionQueries The number of queries received whose IGMP version does not match igmpInterfaceVersion, over the lifetime of the row entry. IGMP requires that all routers on a LAN be configured to run the same version of IGMP. Although, DOCSIS 1.1 requires that all CMTS and CMTSTS devices support IGMPv2, it is possible for a network side querier to be an IGMPv1 querier. All Modes / All interfaces: read-only. The number of non-v2 queries received on this interface. Abramson Informational ( Expires June 2001) 15 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.2.1.11 igmpInterfaceJoins The number of times a group membership has been added on this interface; that is, the number of times an entry for this interface has been added to the Cache Table. This object gives an indication of the amount of IGMP activity over the lifetime of the row entry. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. 4.2.1.12 igmpInterfaceProxyIfIndex Some devices implement a form of IGMP proxy whereby memberships learned on the interface represented by this row, cause IGMP Host Membership Reports to be sent on the interface whose ifIndex value is given by this object. Such a device would implement the igmpV2RouterMIBGroup only on its router interfaces (those interfaces with non-zero igmpInterfaceProxyIfIndex). Typically, the value of this object is 0, indicating that no proxy is being done. Passive Mode ------------ All Interfaces: read-only. Always return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Always return an ifIndex for a NSI-side interface. 4.2.1.13 igmpInterfaceGroups The current number of entries for this interface in the Cache Table. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Group membership of HFC-side devices. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Abramson Informational ( Expires June 2001) 16 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.2.1.14 igmpInterfaceRobustness The robustness variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the robustness variable may be increased. IGMP is robust to (robustness variable-1) packet losses. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Return a value of zero. Active Mode ----------- All interfaces: read-create. Min =3D 1; Max =3D (2^32 - 1); Default =3D= 2 4.2.1.15 igmpInterfaceLastMemberQueryIntvl The last member query interval is the max response time inserted into group specific queries sent in response to leave group messages, and is also the amount of time between group specific query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group. Passive Mode ------------ NSI-side: n/a, read-only. return a value of zero. HFC-side: read-only. This value is derived from observation of queries received from a network side querier. Active Mode ----------- NSI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100. HFC-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100. 4.2.2 igmpCacheTable - igmpCacheEntry 4.2.2.1 igmpCacheAddress The IP multicast group address for which this entry contains information. All Modes / All Interfaces: Not-accessible (index). Report the address of active IP Multicast on the interface. 4.2.2.2 igmpCacheIfIndex The interface for which this entry contains information for an IP multicast group address. Abramson Informational ( Expires June 2001) 17 =0C Docsis 1.1 IGMPv2 MIB December 2000 Passive Mode / HFC Side: MUST only apply to HFC side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: not-accessible HFC-side: not-accessible 4.2.2.3 igmpCacheSelf An indication of whether the local system is a member of this group address on this interface. Passive Mode / All Interfaces: read-only. MUST be set to FALSE. The CMTS is not a member of any group. Active Mode ----------- NSI-side: read-create. Implementation specific (i.e., may apply to RIPv2 or OSPF) HFC-side: MUST be set to FALSE. The CMTS is not a member of any group on the HFC. 4.2.2.4 igmpCacheLastReporter The IP address of the source of the last membership report received for this IP Multicast group address on this interface. If no membership report has been received, this object has the value of 0.0.0.0. Passive Mode / HFC Side: MUST only apply to last reporter on HFC- side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: read-only HFC-side: read-only 4.2.2.5 igmpCacheUpTime The time elapsed since this entry was created. Passive Mode / HFC-side: MUST only apply to duration of membership on HFC-side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: read-only HFC-side: read-only Abramson Informational ( Expires June 2001) 18 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.2.2.6 igmpCacheExpiryTime The minimum amount of time remaining before this entry will be aged out. Passive Mode / HFC-side: MUST only apply to duration of membership on HFC-side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: read-only HFC-side: read-only 4.2.2.7 igmpCacheStatus The status of this entry. Passive Mode / HFC-side: read-create MUST only apply to membership on HFC-side interface (e.g., membership is only active on subscriber side of CMTS). Deletion of a row results in preventing downstream forwarding to this IP Multicast group address on this interface. Active Mode ----------- NSI-side: read-create HFC-side: read-create 4.2.2.8 igmpCacheVersion1HostTimer The time remaining until the local querier will assume that there are no longer any IGMP version 1 members on this IP subnet attached to this interface. Upon hearing any IGMPv1 membership report, this value is reset to the group membership timer. While this time remaining is non-zero, the local querier ignores any IGMPv2 leave messages for this group that it receives on this interface. Passive Mode / All interfaces: n/a, read-only. Return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Abramson Informational ( Expires June 2001) 19 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.3 IGMP MIB Compliance and MIB Object Groupings This section presents a proposed set of MIB compliance and MIB Groups that are applicable to the description as set forth in this document. 4.3.1 Docsis 1.1. IGMP MIB Compliance Statements 4.3.1.1 docsIgmpV2PassiveDeviceCompliance docsIgmpV2PassiveDeviceCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Devices passively running IGMPv2 and implementing the IGMP MIB.=94 MODULE - this module MANDATORY-GROUPS { igmpBaseMIBGroup, igmpRouterMIBGroup, igmpV2RouterMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::=3D {docsIgmpMIBCompliances 1} 4.3.1.2 docsIgmpV2ActiveDeviceCompliance docsIgmpV2ActiveCmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Devices actively running IGMPv2 and implementing the IGMP MIB.=94 MODULE - this module MANDATORY-GROUPS { igmpBaseMIBGroup, igmpV2HostMIBGroup, igmpRouterMIBGroup, igmpV2RouterMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required.=94 ::=3D {docsIgmpMIBCompliances 2} Abramson Informational ( Expires June 2001) 20 =0C Docsis 1.1 IGMPv2 MIB December 2000 4.3.2 MIB Groups See IGMP MIB for a description of the objects included in each group. 4.3.2.1 igmpV2HostMIBGroup Active Devices only (optional, see notes for igmpCacheSelf). 4.3.2.1 igmpV2RouterMIBGroup Active and Passive Devices 4.3.2.2 igmpBaseMIBGroup Active and Passive Devices 4.3.2.3 igmpV2RouterMIBGroup Active and Passive Devices 4.3.2.4 igmpRouterMIBGroup Active and Passive Devices 4.3.2.5 igmpV2HostOptMIBGroup Active and Passive Devices 4.3.2.6 igmpV2ProxyMIBGroup Active Devices only. Abramson Informational ( Expires June 2001) 21 =0C Docsis 1.1 IGMPv2 MIB December 2000 5. Docsis 1.1 IGMP Mode Control and Cable Device MIB Support The default mode of a Docsis 1.1 CM MUST be to support passive IGMP operation. The default mode of a Docsis 1.1 CMTS SHOULD be to support passive IGMP operation. No objects in the IDMR IGMP MIB provide a consistent way to control this mode for a DOCSIS 1.1 device. One option considered was to overload the context of the igmpInterfaceProxyIfIndex such that setting this object constitutes active mode and clearing the object constitutes passive mode. The problem is that this precludes implementation of a DOCSIS 1.1 device as a multicast router. Another option was to overload the context of the igmpInterfaceQueryInterval such that setting this object constitutes active mode and clearing this object constitutes passive mode. However, this precludes setting the query interval to zero. The, unambiguous, solution to controlling DOCSIS 1.1 IGMP mode is to define a new object. The following object is proposed as a new entry to the docsDevBaseGroup in the Cable Device MIB, [25]. This object is shown as read-write for devices that support both modes. For devices that only support the required passive mode, this object is specified to be read-only. docsDevIgmpModeControl OBJECT-TYPE SYNTAX INTEGER {passive(1), active(2)} MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the mode of operation that the CM/CMTS will operate in. In passive mode, the device forwards IGMP between interfaces based on knowledge of Multicast Session activity on the subscriber side interface and the rules defined in section 3.3.1 of the RFI. In active mode, the device terminates at and initiates IGMP through its interfaces based on the knowledge of Multicast Session activity on the subscriber side interface." DEFVAL { 1 } -- passive ::=3D { docsDevBase 6 } docsDevBaseGroup OBJECT-GROUP OBJECTS { docsDevRole, docsDevDateTime, docsDevResetNow, docsDevSerialNumber, docsDevSTPControl, docsDevIgmpModeControl } STATUS current DESCRIPTION "A collection of objects providing device status and control." Abramson Informational ( Expires June 2001) 22 =0C Docsis 1.1 IGMPv2 MIB December 2000 ::=3D { docsDevGroups 1 } docsDevBasicComplianceV2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for MCNS Cable Modems and Cable Modem Termination Systems." OBJECT docsDevIgmpModeControl MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support passive(1) mode." ::=3D { docsDevCompliances 1 } Abramson Informational ( Expires June 2001) 23 =0C Docsis 1.1 IGMPv2 MIB December 2000 6. Security Considerations This MIB relates to a system which will provide metropolitan public internet access to multicast services. The security considerations discussed in RFC 2933, [20], apply here as well. 6.1 Additional Docsis IGMP Security Considerations Although it is beyond the scope of this MIB application note, the security of IGMP and IP Multicasting in a Docsis network is worth further discussion. For example, improper transmission of IGMP PDUs may result in unauthorized access to multicast services, and may present 'denial-of-service' potential on the HFC (e.g., mischievous users could simply flood the upstream with IGMP for sessions they are not authorized to receive; the result being cluttering the downstream with unauthorized and undesired multicast traffic). Early discussions on IGMP within the IPCDN and Docsis communities centered on conditional and timed multicast session activity. More recent discussions have focused on a tighter coupling between the Baseline Privacy Plus protocol, [24], and IGMP to resolve these issues. Tying these protocols too tightly together may present problems and complexity that is unwarranted during the early stages of multicast deployments in Docsis networks. It is important to note that a Docsis CM will never forward unauthorized and encrypted data from the HFC to the CMCI as it will fail on the downstream Security Association as defined by the BPI+ protocol. It is expected that 'non-destructive' users will give up trying to receive unauthorized sessions (e.g., stop sending membership reports for sessions not received). This will result in timing-out the session through normal IGMP mechanisms (e.g., no one left sending MRs for this group). Preventing denial-of-service is, perhaps, the greater security concern for IGMP in a Docsis network. One approach is to establish controls on the CMTS that consult BPI+ Authorization tables before accepting IGMP Membership Reports from a given CM. 6.1.1 Proposed Security Rules for Docsis IGMP The following set of rules have been proposed to provide better security for IGMP/IP Multicast in Docsis networks. The reader is referred to the RFC 2236, [22], and the BPI+ specification, [24]. NOTE: forwarding of IGMP, presented below, MUST be subject to permit rules at the IP and IEEE802.2 MAC Layer. o The CM MUST NOT forward IGMP PDUs (Membership Reports, Leaves, etc.) upstream for Multicast Sessions that have been SA-MAP Reply Rejected for authorization (e.g., this does not apply to SA-MAP reject for unencrypted sessions). Abramson Informational ( Expires June 2001) 24 =0C Docsis 1.1 IGMPv2 MIB December 2000 Discussion: this requires that the CM apply the following order to forwarding of IGMP PDUs upstream. If the IGMP PDU is for a Session that is new to the CMCI-LAN, then the CM MUST NOT forward the PDU for this Session until such time as a BPI+ SA-MAP Reply, with the requested SA mapping, or a SA-Map Reject 'not mapped to a SA' is received. Said another way, the CM MUST NOT forward IGMP for Sessions that result in a SA-MAP Reject not authorized for SA. The CM MUST continue to treat all subsequent IGMP Membership Reports for this session as being new and MUST result in a SA-MAP Request for this traffic flow (Session). o The CM MUST consider all Multicast Sessions, associated with a given SA, inactive on the CMCI-LAN as soon as the TEK state machine terminates for these sessions. That is, once the TEK state machine terminates (either by a Key Reject or Authorization Invalid), Multicast data for Sessions associated with this SA MUST NOT be forwarded from the HFC to the CMCI AND the CM MUST consider subsequent MRs for these Sessions as being new (as described above). o The CMTS SHOULD NOT process an IGMP PDU sent from/through a CM if the MR is for a Session that is associated with Multicast Addresses that has a SA (is encrypted) and is not authorized for the CM (based on the HFC-side CM mac address). Discussion: this requires that the CMTS consult the BPI+ docsBpi2CmIpMulticastMapTable (IP Multicast Address to SAID) table and the docsBpi2CmtsMulticastAuthTable (CMTS Multicast SAID Authorization) table before processing IGMP messages (MR or Leave; Queries are explicitly prohibited on the upstream). The following rules apply. If the IGMP is for a Multicast address that has an SA and the CM from which this IGMP PDU was sent is authorized for this SA, then process the IGMP (i.e., MRs are reflected on downstream, and the NSI multicast filters are removed to send downstream data, etc.) If the IGMP is for a Multicast address that does not have an SA, then process the IGMP. If the IGMP is for a Multicast address that has an SA and the CM from which this IGMP PDU was sent is not authorized for this SA, then the IGMP PDU SHOULD be silently discarded. Abramson Informational ( Expires June 2001) 25 =0C Docsis 1.1 IGMPv2 MIB December 2000 o The CMTS MAY stop forwarding Multicast data downstream for Sessions that have an SA and for which there is no TEK state machine running. 8. References [1] Bradner, S., "The Internet Standards Process - Revision- 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, May 1999. [4] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP - based Internets", STD 16, RFC 1155, May 1990. [5] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [6] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information for Version 2 (SMIv2)", STD 58, RFC2578, April 1999. [8] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [9] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [10] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. Abramson Informational ( Expires June 2001) 26 =0C Docsis 1.1 IGMPv2 MIB December 2000 [13] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [14] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [16] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [17] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol(SNMP)", RFC 2575, April 1999. [18] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)=94, RFC 2272, January 1998. [19] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)=94, RFC 2274, January 1998. [20] McCloghrie, K., Farinacci, D., Thaler, D., "Internet Group Management Protocol MIB=94, RFC 2933, October 2000. [21] Fenner, W., "IGMP-based Multicast Forwarding (''IGMP Proxying'')=94, IETF Internet Draft, http://www.ietf.org/ internet-drafts/draft-fenner-igmp-proxy-03.txt. [22] Fenner, W. " Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [23] "Data Over Cable Service Interface Specifications - Radio Frequency Interface Specification=94, vSP-RFIv1.1- I05-000714, July 14, 2000. [24] "Data Over Cable Service Interface Specifications - Baseline Privacy Plus Interface Specification=94, vSP- BPI+-I05-000714, July 14, 2000. [25] St. Johns, M., "DOCSIS Cable Device MIB=94, RFC 2669, August 1999. Abramson Informational ( Expires June 2001) 27 =0C Docsis 1.1 IGMPv2 MIB December 2000 9. Acknowledgments The author would like to acknowledge the following individuals for contributions to this document. This includes Paul Gray, Greg Nakanishi, Pak Siripunkaw, Mike St. Johns, Rich Woundy, and Greg White. 10. Author's Address Howard D. Abramson ADC Telecommunications 8 Technology Drive Westborough, MA 01581 Phone: 508.870.2615 Email: howard_abramson@adc.com Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Abramson Informational ( Expires June 2001) 28 =0C Docsis 1.1 IGMPv2 MIB December 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abramson Informational ( Expires June 2001) 29 ------=_NextPart_000_0016_01C05858.F6CDE970 Content-Type: text/plain; name="draft-ietf-ipcdn-igmp-mib-01.txt" Content-Disposition: attachment; filename="draft-ietf-ipcdn-igmp-mib-01.txt" Content-Transfer-Encoding: quoted-printable IP over Cable Data Network (IPCDN) H. Abramson=20 Internet Draft ADC=20 Telecommunications=20 Document: December 2000=20 Category: Informational =20 =20 =20 Application of the IGMP MIB, RFC 2933, and Cable=20 Device MIB, RFC 2669, to Docsis 1.1 Devices=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts=20 as reference material or to cite them other than as 'work in=20 progress.'=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Copyright Notice=20 =20 Copyright (c) Society (2000). All Rights Reserved.=20 =20 Abstract=20 =20 This memo describes the application of a portion of the Management=20 Information Base (MIB) for use with network management protocols in=20 the Internet community. In particular, it describes the application=20 of the managed objects specified in RFC 2933, [19], and proposes a=20 new object for the Cable Device MIB, RFC 2669 [25], for SNMP-based=20 management of DOCSIS 1.1 IGMPv2 compliant interfaces.=20 =20 This memo is a product of the IPCDN working group within the=20 Internet Engineering Task Force. Comments are solicited and should=20 be addressed to the working group's mailing list at ipcdn@ietf.org=20 and/or the author.=20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational (Expires June 2001) 1=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 Table of Contents=20 =20 1. THE SNMP MANAGEMENT FRAMEWORK..............................3=20 2. GLOSSARY...................................................4=20 3. OVERVIEW...................................................5=20 4. DOCSIS 1.1 INTERFACE AND THE IGMP MIB......................6=20 4.1 DOCSIS 1.1 CM SUPPORT FOR THE IGMP MIB.................6=20 4.2 DOCSIS 1.1 CMTS SUPPORT FOR THE IGMP MIB..............13=20 4.3 IGMP MIB COMPLIANCE AND MIB OBJECT GROUPINGS..........20=20 5. DOCSIS 1.1 IGMP MODE CONTROL AND CABLE DEVICE MIB SUPORT..22=20 6. SECURITY CONSIDERATIONS...................................23=20 8. REFERENCES................................................25=20 9. ACKNOWLEDGMENTS...........................................27=20 10. AUTHOR'S ADDRESS..........................................27=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 2=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 1. The SNMP Management Framework=20 =20 The SNMP Management Framework presently consists of five major=20 components:=20 =20 o An overall architecture, described in RFC 2571 [3].=20 =20 o Mechanisms for describing and naming objects and events for the=20 purpose of management. The first version of this Structure of = =20 Management Information (SMI) is called SMIv1 and described in = =20 RFC 1155 [4], RFC 1212 [5] and RFC 1215 [6]. The second version, = =20 called SMIv2, is described in RFC 2578 [7], RFC 2579 [8] and RFC = =20 2580 [9].=20 =20 o Message protocols for transferring management information. The=20 first version of the SNMP message protocol is called SNMPv1 and = =20 described in RFC 1157 [10]. A second version of the SNMP message = =20 protocol, which is not an Internet standards track protocol, is = =20 called SNMPv2c and described in RFC 1901 [11] and RFC 1906 [12]. = =20 The third version of the message protocol is called SNMPv3 and = =20 described in RFC 2574 [14], RFC 2272 [18] and RFC 2274 [19].=20 =20 o Protocol operations for accessing management information. The = =20 first set of protocol operations and associated PDU formats is = =20 described in RFC 1157 [10]. A second set of protocol operations = =20 and associated PDU formats is described in RFC 1905 [15].=20 =20 o A set of fundamental applications described in RFC 2273 [16] and=20 the view-based access control mechanism described in RFC 2575 = =20 [17].=20 =20 Managed objects are accessed via a virtual information store, termed=20 the Management Information Base or MIB. Objects in the MIB are=20 defined using the mechanisms defined in the SMI.=20 =20 This memo describes the application of a MIB module that is=20 compliant to the SMIv2. A MIB conforming to the SMIv1 can be=20 produced through the appropriate translations. The resulting=20 translated MIB must be semantically equivalent, except where objects=20 or events are omitted because no translation is possible (use of=20 Counter64). Some machine readable information in SMIv2 will be=20 converted into textual descriptions in SMIv1 during the translation=20 process. However, this loss of machine readable information is not=20 considered to change the semantics of the MIB.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 3=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 2. Glossary=20 =20 The following non-ietf terms are derived either from normal cable=20 system usage, or from the documents associated with the Data Over=20 Cable Service Interface Specification process.=20 =20 CATV - Originally 'Community Antenna Television', refers to cable or=20 HFC (see below) system used to deliver video signals to a community.=20 =20 CM, Cable Modem - A CM acts as a 'slave' station in a DOCSIS=20 compliant cable data system.=20 =20 CMTS, Cable Modem Termination System - A generic term covering a=20 cable bridge or cable router in a head-end. A CMTS acts as the=20 master station in a DOCSIS compliant cable data system. It is the=20 only station that transmits downstream, and it controls the=20 scheduling of upstream transmissions by its associated CMs.=20 =20 CMCI - or Subscriber side, refers to the Cable Modem Customer=20 Interface that connects to CPE on the CM.=20 =20 CPE - Customer Premise Equipment, non-Cable Modem IP Hosts attached=20 to the Cable Modem.=20 =20 DOCSIS - 'Data Over Cable Interface Specification'. A term=20 referring to the ITU-T J.112 Annex B standard for cable modem=20 systems, [23]=20 =20 Downstream - From the head-end towards the subscriber.=20 =20 Head-end - The origination point in most cable systems of the=20 subscriber video signals. Generally this is also the location of the=20 CMTS equipment.=20 =20 HFC - Hybrid-Fiber-Coax, refers to physical wire(s) connecting the=20 CMTS and CM.=20 =20 MAC Packet - A DOCSIS PDU.=20 =20 NSI - Network-Side-Interface, refers to interface(s) on the CMTS=20 that are typically connected to the Internet.=20 =20 RF - Radio Frequency.=20 =20 Upstream - From the subscriber towards the head-end.=20 =20 2.1 Conventions used in this document=20 =20 =20 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',=20 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in=20 this document are to be interpreted as described in RFC-2119, [2].=20 =20 =20 Abramson Informational ( Expires June 2001) 4=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 3. Overview=20 =20 The Docsis Multicast CM and CMTS interconnect specification can be=20 modeled (or described) by 'splitting' the traditional Internet Group=20 Management Protocol (IGMP), [22], interfaces into Host and Querier=20 side interfaces. That is, to provide basic Docsis 1.1 Multicast=20 capabilities, all NSI-facing interfaces (NSI on the CMTS and HFC- side on CM) need only present an IGMP Host interface to the external=20 multicast network. All Subscriber-facing interfaces (HFC-side on=20 CMTS and CPE-side on CM) need only present a Querier interface to=20 CPE. This is in contrast to a Multicast Router model where each=20 interface has both Host and Querier capabilities. =20 =20 It is expected that the root of each Multicast session tree=20 originate from the NSI interface(s). Although not strictly=20 prohibited by the RFI, a more symmetrical model, where the root of a=20 Multicast group may be on the HFC/Subscriber-side, is discouraged.=20 In either case, Querying MUST only be in the downstream direction=20 (initiated by an NSI Querier or the CMTS itself). Host Membership=20 Reporting is expected to be in the upstream direction (from CPE or=20 active IGMP CM devices). The IGMPv2 MIB provides an excellent and=20 standard means for managing multicast within such a network.=20 =20 3.1 IGMP Capabilities: Active and Passive Mode=20 =20 There are two basic modes of IGMP capability defined by the Docsis=20 1.1 RFI specification that are applicable to a DOCSIS 1.1 device.=20 =20 o Passive IGMP Devices - The first mode is a passive operation in=20 which the device selectively forwards IGMP based upon the known=20 state of multicast session activity on the subscriber side (an=20 example of this is described in Appendix L of [23]). In passive=20 mode, the device derives its IGMP timers based on the rules=20 specified in section 3.3.1 of the RFI.=20 =20 o Active IGMP Devices - The second mode is an active operation in=20 which the device terminates and initiates IGMP based upon the=20 known state of multicast session activity on the subscriber=20 side. One example of the latter, active, mode is commonly=20 referred to as an IGMP-Proxy implementation side (as described=20 in [21]). A more complete example of an active IGMP device is=20 that of a Multicast Router.=20 =20 Although a specific implementation is not imposed, the Docsis 1.1=20 device MUST meet the requirements stated in section 3.3.1 of [23]=20 and MUST support the IDMR IGMP MIB, [20], and Cable Device MIB,=20 [25], as described herein. As specified in the DOCSIS 1.1 RFI,=20 active CMs are explicitly prohibited from transmitting IGMP Queries=20 upstream onto the HFC. However, active CMTSs may transmit IGMP=20 Queries on any of its interfaces.=20 =20 =20 =20 Abramson Informational ( Expires June 2001) 5=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 3.2 IGMP Timers=20 =20 The IGMP standard, [22], defines several timers that are applicable=20 to the management of Multicast session activity on a given=20 interface. Timers for Docsis 1.1 passive IGMP devices are derived=20 based on the requirements specified in section 3.3.1 of [23]. As=20 such, MIB objects that apply to these timers must be considered read=20 only values. IGMP timers in active devices should be considered=20 values that may be managed within the device.=20 =20 4. DOCSIS 1.1 Interface and the IGMP MIB=20 =20 DOCSIS 1.1 devices, CM and CMTS, MUST support the IDMR IGMP MIB=20 (RFC-2933), [20]. As such, the following sections describe the=20 application of RFC-2933 to DOCSIS 1.1 devices.=20 =20 The IDMR IGMP MIB is organized into two distinct tables, the=20 interface and cache tables. The IGMP Interface Table contains=20 entries for each interface that supports IGMP on a device. For=20 DOCSIS 1.1 this includes the NSI and HFC for the CMTS and the HFC=20 and CMCI on the CM. The IGMP Cache Table contains one row for each=20 IP Multicast Group for which there are active members on a given=20 interface. Active membership MUST only exist on the CMCI of a Cable=20 Modem. However, active membership MAY exist on both the NSI and HFC=20 side interfaces of the CMTS. This is because a CMTS may be=20 implemented as a Multicast Router on which other network side=20 devices are actively participating in a multicast session.=20 =20 Support of the IDMR IGMP MIB by DOCSIS 1.1 devices is presented in=20 terms of IGMP capabilities, the device type (CM or CMTS), and the=20 interface on which IGMP is supported. This is followed by a set of=20 new IGMP MIB conformance, compliance and group statements for DOCSIS=20 1.1 devices.=20 =20 4.1 Docsis 1.1 CM Support for the IGMP MIB=20 =20 There are two types of interfaces applicable to IGMP on the DOCSIS=20 1.1 CM. These are the HFC-Side and CMCI-Side interfaces,=20 respectively. Application of the IGMP MIB to DOCSIS 1.1 CMs is=20 presented in terms of passive and active CM operation and these two=20 interface types.=20 =20 4.1.1 igmpInterfaceTable - igmpInterfaceEntry=20 =20 4.1.1.1 igmpInterfaceIfIndex=20 =20 The ifIndex value of the interface for which IGMP is enabled.=20 =20 All Modes / Both sides: same for passive and active modes.=20 =20 HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV=20 MAC Layer=20 CMCI-side: not-accessible. ifIndex of CMCI-Side interface.=20 =20 Abramson Informational ( Expires June 2001) 6=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.1.1.2 igmpInterfaceQueryInterval=20 =20 The frequency at which IGMP Host-Query packets are transmitted on=20 this interface.=20 =20 Passive Mode=20 ------------=20 HFC-side: n/a, read-only. The CM MUST not transmit queries=20 upstream. Return a value of zero.=20 CMCI-side: read only . This value is derived based on the interval=20 of queries received from an upstream querier.=20 =20 Active Mode=20 -----------=20 HFC-side: n/a, read-only. The CM MUST not transmit queries=20 upstream. Return a value of zero.=20 CMCI-side: read-create. Min =3D 0; Max =3D (2^32 - 1); Default =3D = 125=20 =20 4.1.1.3 igmpInterfaceStatus=20 =20 The activation of a row enables IGMP on the interface. The=20 destruction of a row disables IGMP on the interface.=20 =20 All Modes / Both sides: MUST be enabled on both interfaces for all=20 DOCSIS 1.1 CM interfaces.=20 =20 4.1.1.4 igmpInterfaceVersion=20 The version of IGMP which is running on this interface.=20 =20 All Modes / Both sides: MUST be version 2 for all DOCSIS 1.1 CM=20 interfaces.=20 =20 4.1.1.5 igmpInterfaceQuerier=20 The address of the IGMP Querier on the IP subnet to which this=20 interface is attached.=20 =20 Passive Mode=20 ------------=20 HFC-side: read-only. MUST be the address of an upstream device for=20 both active and passive CMs.=20 CMCI-side: read-only. Same as HFC-side value.=20 =20 Active Mode=20 -----------=20 HFC-side: read-only. MUST be the address of an upstream device for=20 both active and passive CMs.=20 CMCI-side: read-only. Active CMs may report it as the HFC-side=20 value. However, active CMs that participate in IGMP=20 Querier negotiation on the CMCI may report it as a=20 different CPE.=20 =20 =20 =20 Abramson Informational ( Expires June 2001) 7=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 4.1.1.6 igmpInterfaceQueryMaxResponseTime=20 =20 The maximum query response time advertised in IGMPv2 queries on this=20 interface.=20 =20 Passive Mode=20 ------------=20 HFC-side: n/a, read-only. return a value of zero.=20 CMCI-side: read-only. This value is derived from observation of=20 queries received from an upstream querier=20 =20 Active Mode=20 -----------=20 HFC-side: n/a, read-only. return a value of zero.=20 CMCI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100.=20 =20 4.1.1.7 igmpInterfaceQuerierUpTime=20 =20 The time since igmpInterfaceQuerier was last changed.=20 =20 Passive Mode=20 -----------=20 HFC-side: read-only.=20 CMC-side: n/a, read-only. Return a value of zero.=20 =20 Active Mode=20 -----------=20 HFC-side: read-only.=20 CMCI-side: read-only.=20 =20 4.1.1.8 igmpInterfaceQuerierExpiryTime=20 =20 The amount of time remaining before the other querier present timer=20 expires. If the local system is the querier, the value of this=20 object is zero.=20 =20 Passive Mode=20 ------------=20 Both Sides: n/a, read-only. The CM is never the querier, return 0.=20 =20 Active Mode=20 -----------=20 HFC-side: n/a, read-only. Return 0.=20 CMCI-side: read-only. The CM may only be the querier on the CMCI.=20 =20 4.1.1.9 igmpInterfaceVersion1QuerierTimer=20 =20 The time remaining until the host assumes that there are no IGMPv1=20 routers present on the interface. While this is non-zero, the host=20 will reply to all queries with version 1 membership reports.=20 =20 Abramson Informational ( Expires June 2001) 8=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 Passive Mode=20 ------------=20 HFC-side: n/a read-only. Return a value of zero.=20 CMCI-side: n/a read-only. Return a value of zero.=20 =20 Active Mode=20 -----------=20 HFC-side: read-only.=20 CMCI-side: read-only.=20 =20 4.1.1.10 igmpInterfaceWrongVersionQueries=20 =20 The number of queries received whose IGMP version does not match=20 igmpInterfaceVersion, over the lifetime of the row entry. IGMP=20 requires that all routers on a LAN be configured to run the same=20 version of IGMP. Although, DOCSIS 1.1 requires that all CM and CMTS=20 devices support IGMPv2, it is possible for an upstream querier to be=20 an IGMPv1 querier.=20 =20 All Modes / Both sides - read-only. The number of non-v2 queries=20 received on this interface.=20 =20 4.1.1.11 igmpInterfaceJoins=20 =20 The number of times a group membership has been added on this=20 interface; that is, the number of times an entry for this interface=20 has been added to the Cache Table. This object gives an indication=20 of the amount of IGMP activity over the lifetime of the row entry.=20 =20 All HFC-side - n/a, read-only. Always return a value of zero (see=20 CMCI-side).=20 =20 All CMCI-side - read-only. Group membership is defined to only exist=20 on the CMCI.=20 =20 4.1.1.12 igmpInterfaceProxyIfIndex=20 =20 Some devices implement a form of IGMP proxy whereby memberships=20 learned on the interface represented by this row, cause IGMP Host=20 Membership Reports to be sent on the interface whose ifIndex value=20 is given by this object. Such a device would implement the=20 igmpV2RouterMIBGroup only on its router interfaces (those interfaces=20 with non-zero igmpInterfaceProxyIfIndex). Typically, the value of=20 this object is 0, indicating that no proxy is being done.=20 =20 Passive Mode=20 ------------=20 Both side: read-only. Always return a value of zero.=20 =20 =20 Abramson Informational ( Expires June 2001) 9=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 Active Mode=20 -----------=20 HFC-side: read-only. Always return a value of zero.=20 CMCI-side: read-only. Always return ifIndex for HFC-side interface.=20 =20 4.1.1.13 igmpInterfaceGroups=20 =20 The current number of entries for this interface in the Cache Table=20 (number of active sessions Proxied or Active on this Interface).=20 =20 All HFC-side - n/a, read-only. Always return a value of zero (see=20 CMCI-side).=20 =20 All CMCI-side - read-only. Group membership is defined to only exist=20 on the CMCI.=20 =20 4.1.1.14 igmpInterfaceRobustness=20 =20 The robustness variable allows tuning for the expected packet loss=20 on a subnet. If a subnet is expected to be lossy, the robustness=20 variable may be increased. IGMP is robust to (robustness variable-1)=20 packet losses.=20 =20 Passive Mode=20 ------------=20 HFC-side: n/a read-only. Return a value of zero.=20 CMCI-side: n/a read-only. Return a value of zero.=20 =20 Active Mode=20 -----------=20 Both sides: read-create. Min =3D 1; Max =3D (2^32 - 1); Default =3D 2 = =20 4.1.1.15 igmpInterfaceLastMemberQueryIntvl=20 =20 The last member query interval is the max response time inserted=20 into group specific queries sent in response to leave group=20 messages, and is also the amount of time between group specific=20 query messages. This value may be tuned to modify the leave latency=20 of the network. A reduced value results in reduced time to detect=20 the loss of the last member of a group.=20 =20 =20 Passive Mode=20 ------------=20 HFC-side: n/a, read-only. return a value of zero.=20 CMCI-side: read-only. This value is derived from observation of=20 queries received from an upstream querier=20 =20 Active Mode=20 -----------=20 HFC-side: n/a, read-only. return a value of zero.=20 CMCI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100.=20 =20 Abramson Informational ( Expires June 2001) 10=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.1.2 igmpCacheTable - igmpCacheEntry=20 =20 4.1.2.1 igmpCacheAddress=20 =20 The IP multicast group address for which this entry contains=20 information.=20 =20 All Modes / Both sides: Not-accessible (index). Report the address=20 of active IP Multicast on the CMCI interface.=20 =20 4.1.2.2 igmpCacheIfIndex=20 =20 The interface for which this entry contains information for an IP=20 multicast group address.=20 =20 All Modes / CMCI side: MUST only apply to CMCI interface (e.g.,=20 membership is only active on subscriber side of CM).=20 =20 4.1.2.3 igmpCacheSelf=20 =20 An indication of whether the local system is a member of this group=20 address on this interface.=20 =20 Passive Mode / Both sides: read-only. MUST be set to FALSE. The CM=20 is not a member of any group.=20 =20 Active Mode / Both sides: read-create. Implementation specific. If=20 the CM is configured to be a member of the group, then membership=20 reports are sent with the CMs IP Address but MUST ONLY be sent in=20 proxy for active sessions on the CMCI (e.g., the CM MUST NOT be a=20 member of a multicast group that is not active on the CMCI). If the=20 CM is not configured to be a member, then the source IP Address of=20 membership reports MUST be set to the current value of the=20 igmpCacheLastReporter address.=20 =20 4.1.2.4 igmpCacheLastReporter=20 =20 The IP address of the source of the last membership report received=20 for this IP Multicast group address on this interface. If no=20 membership report has been received, this object has the value of=20 0.0.0.0.=20 =20 All Modes / CMCI side: MUST only apply to last reporter on CMCI=20 interface (e.g., membership only active on subscriber side of CM).=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 11=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.1.2.5 igmpCacheUpTime=20 =20 The time elapsed since this entry was created.=20 =20 All Modes / CMCI side: read-only. MUST only apply to duration of=20 membership on CMCI interface (e.g., membership is only active on=20 subscriber side of CM).=20 =20 4.1.2.6 igmpCacheExpiryTime=20 =20 The minimum amount of time remaining before this entry will be aged=20 out.=20 =20 All Modes / Both sides - read-only. MUST only apply to duration of=20 membership on CMCI interface (e.g., membership is only active on=20 subscriber side of CM).=20 =20 4.1.2.7 igmpCacheStatus=20 =20 The status of this entry.=20 =20 All Modes / CMCI side - read-create. MUST only apply to membership=20 on CMCI interface (e.g., membership is only active on subscriber=20 side of CM). Deletion of a row results in preventing downstream=20 forwarding to this IP Multicast group address on this interface.=20 =20 4.1.2.8 igmpCacheVersion1HostTimer=20 =20 The time remaining until the local querier will assume that there=20 are no longer any IGMP version 1 members on this IP subnet attached=20 to this interface. Upon hearing any IGMPv1 membership report, this=20 value is reset to the group membership timer. While this time=20 remaining is non-zero, the local querier ignores any IGMPv2 leave=20 messages for this group that it receives on this interface.=20 =20 Passive Mode=20 ------------=20 Both side: n/a, read-only. Return a value of zero.=20 =20 Active Mode=20 -----------=20 HFC-side: n/a, read-only. Return a value of zero.=20 CMCI-side: read-only.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 12=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.2 Docsis 1.1 CMTS Support for the IGMP MIB=20 =20 There are two types of interfaces applicable to IGMP on the DOCSIS=20 1.1 CMTS. These are the NSI-Side and NSI-Side interfaces,=20 respectively. Application of the IGMP MIB to DOCSIS 1.1 CMTSs is=20 presented in terms of passive and active CMTS operation and these=20 two interface types. In contrast to a CM, the CMTS is likely to have=20 several NSI-side interfaces and several HFC-side (subscriber-side)=20 interfaces.=20 =20 It is important to note that an active IGMP capable CMTS may be=20 implemented as a proxy, router, or hybrid device. As such, the CMTS=20 may be capable of querying on both its NSI and HFC side interfaces=20 and may manage membership for devices on its NSI interfaces (e.g.,=20 as a multicast router). This is different than an active CM, which=20 MUST NOT query on its HFC side interface (e.g., it may only query on=20 its CMCI). This capability is accounted for in the application of=20 the IGMP MIB to the CMTS.=20 =20 4.2.1 igmpInterfaceTable- igmpInterfaceEntry=20 =20 4.2.1.1 igmpInterfaceIfIndex=20 =20 The ifIndex value of the interface for which IGMP is enabled.=20 =20 All Modes=20 ---------=20 This is the same for passive and active modes.=20 =20 NSI-side: not-accessible. ifIndex of applicable network side=20 interface(s).=20 HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV=20 MAC Layer interface.=20 =20 4.2.1.2 igmpInterfaceQueryInterval=20 =20 The frequency at which IGMP Host-Query packets are transmitted on=20 this interface.=20 =20 Passive Mode=20 ------------=20 NSI-side: n/a, read-only. Return a value of zero.=20 HFC-side: read only . This value is derived based on the interval=20 of queries received from a Network Side querier.=20 =20 Active Mode=20 -----------=20 NSI-side: read-create. Min =3D 0; Max =3D (2^32 - 1); Default =3D = 125=20 HFC-side: read-create. Min =3D 0; Max =3D (2^32 - 1); Default =3D = 125=20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 13=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.2.1.3 igmpInterfaceStatus=20 =20 All Modes / All Interfaces: the activation of a row enables IGMP on=20 the interface. The destruction of a row disables IGMP on the=20 interface.=20 =20 4.2.1.4 igmpInterfaceVersion=20 =20 The version of IGMP which is running on this interface. MUST be=20 version 2 for all DOCSIS 1.1 CMTS interfaces.=20 =20 4.2.1.5 igmpInterfaceQuerier=20 =20 The address of the IGMP Querier on the IP subnet to which this=20 interface is attached.=20 =20 Passive Mode=20 ------------=20 NSI-side: read-only. This is the address of a network side device.=20 HFC-side: read-only. Same as NSI-side value.=20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only. Active CMTSs MUST report this as an IP=20 Address assigned to the CMTS' HFC-side interface. That=20 is, queries MUST not originate from CMs or CPE.=20 =20 4.2.1.6 igmpInterfaceQueryMaxResponseTime=20 =20 The maximum query response time advertised in IGMPv2 queries on this=20 interface.=20 =20 Passive Mode=20 ------------=20 NSI-side: n/a, read-only. return a value of zero.=20 HFC-side: read-only. This value is derived from observation of=20 queries received from a network side querier.=20 =20 Active Mode=20 -----------=20 NSI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100.=20 HFC-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100.=20 =20 4.2.1.7 igmpInterfaceQuerierUpTime=20 =20 The time since igmpInterfaceQuerier was last changed.=20 =20 =20 Passive Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: n/a, read-only. Return a value of zero.=20 =20 Abramson Informational ( Expires June 2001) 14=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only.=20 =20 4.2.1.8 igmpInterfaceQuerierExpiryTime=20 =20 The amount of time remaining before the other querier present timer=20 expires. If the local system is the querier, the value of this=20 object is zero.=20 =20 Passive Mode=20 ------------=20 All interfaces: n/a, read-only. The CMTS is not a querier, return 0.=20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only. The CMTS MUST be the only querier on the HFC.=20 =20 4.2.1.9 igmpInterfaceVersion1QuerierTimer=20 =20 The time remaining until the host assumes that there are no IGMPv1=20 routers present on the interface. While this is non-zero, the host=20 will reply to all queries with version 1 membership reports.=20 =20 Passive Mode=20 ------------=20 NSI-side: n/a read-only. Return a value of zero.=20 HFC-side: n/a read-only. Return a value of zero.=20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only.=20 =20 4.2.1.10 igmpInterfaceWrongVersionQueries=20 =20 The number of queries received whose IGMP version does not match=20 igmpInterfaceVersion, over the lifetime of the row entry. IGMP=20 requires that all routers on a LAN be configured to run the same=20 version of IGMP. Although, DOCSIS 1.1 requires that all CMTS and=20 CMTSTS devices support IGMPv2, it is possible for a network side=20 querier to be an IGMPv1 querier.=20 =20 All Modes / All interfaces: read-only. The number of non-v2 queries=20 received on this interface.=20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 15=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.2.1.11 igmpInterfaceJoins=20 =20 The number of times a group membership has been added on this=20 interface; that is, the number of times an entry for this interface=20 has been added to the Cache Table. This object gives an indication=20 of the amount of IGMP activity over the lifetime of the row entry.=20 =20 Passive Mode=20 ------------=20 NSI-side: n/a read-only. Return a value of zero.=20 HFC-side: n/a read-only. Return a value of zero.=20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only.=20 =20 4.2.1.12 igmpInterfaceProxyIfIndex=20 =20 Some devices implement a form of IGMP proxy whereby memberships=20 learned on the interface represented by this row, cause IGMP Host=20 Membership Reports to be sent on the interface whose ifIndex value=20 is given by this object. Such a device would implement the=20 igmpV2RouterMIBGroup only on its router interfaces (those interfaces=20 with non-zero igmpInterfaceProxyIfIndex). Typically, the value of=20 this object is 0, indicating that no proxy is being done.=20 =20 Passive Mode=20 ------------=20 All Interfaces: read-only. Always return a value of zero.=20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only. Always return an ifIndex for a NSI-side=20 interface.=20 =20 4.2.1.13 igmpInterfaceGroups=20 =20 The current number of entries for this interface in the Cache Table.=20 =20 Passive Mode=20 ------------=20 NSI-side: n/a read-only. Return a value of zero.=20 HFC-side: n/a read-only. Group membership of HFC-side devices.=20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only.=20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 16=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 4.2.1.14 igmpInterfaceRobustness=20 =20 The robustness variable allows tuning for the expected packet loss=20 on a subnet. If a subnet is expected to be lossy, the robustness=20 variable may be increased. IGMP is robust to (robustness variable-1)=20 packet losses.=20 =20 Passive Mode=20 ------------=20 NSI-side: n/a read-only. Return a value of zero.=20 HFC-side: n/a read-only. Return a value of zero.=20 =20 Active Mode=20 -----------=20 All interfaces: read-create. Min =3D 1; Max =3D (2^32 - 1); Default = =3D 2=20 =20 4.2.1.15 igmpInterfaceLastMemberQueryIntvl=20 =20 The last member query interval is the max response time inserted=20 into group specific queries sent in response to leave group=20 messages, and is also the amount of time between group specific=20 query messages. This value may be tuned to modify the leave latency=20 of the network. A reduced value results in reduced time to detect=20 the loss of the last member of a group.=20 =20 Passive Mode=20 ------------=20 NSI-side: n/a, read-only. return a value of zero.=20 HFC-side: read-only. This value is derived from observation of=20 queries received from a network side querier.=20 =20 Active Mode=20 -----------=20 NSI-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100.=20 HFC-side: read-create. Min =3D 0; Max =3D 255; Default =3D 100.=20 =20 4.2.2 igmpCacheTable - igmpCacheEntry=20 =20 4.2.2.1 igmpCacheAddress=20 =20 The IP multicast group address for which this entry contains=20 information.=20 =20 All Modes / All Interfaces: Not-accessible (index). Report the=20 address of active IP Multicast on the interface.=20 =20 4.2.2.2 igmpCacheIfIndex=20 =20 The interface for which this entry contains information for an IP=20 multicast group address.=20 =20 =20 Abramson Informational ( Expires June 2001) 17=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 Passive Mode / HFC Side: MUST only apply to HFC side interface=20 (e.g., membership is only active on subscriber side of CMTS).=20 =20 Active Mode=20 -----------=20 NSI-side: not-accessible=20 HFC-side: not-accessible=20 =20 4.2.2.3 igmpCacheSelf=20 =20 An indication of whether the local system is a member of this group=20 address on this interface.=20 =20 Passive Mode / All Interfaces: read-only. MUST be set to FALSE. The=20 CMTS is not a member of any group.=20 =20 Active Mode=20 -----------=20 NSI-side: read-create. Implementation specific (i.e., may apply to=20 RIPv2 or OSPF)=20 HFC-side: MUST be set to FALSE. The CMTS is not a member of any=20 group on the HFC.=20 =20 4.2.2.4 igmpCacheLastReporter=20 =20 The IP address of the source of the last membership report received=20 for this IP Multicast group address on this interface. If no=20 membership report has been received, this object has the value of=20 0.0.0.0.=20 =20 Passive Mode / HFC Side: MUST only apply to last reporter on HFC- side interface (e.g., membership is only active on subscriber side=20 of CMTS).=20 =20 Active Mode=20 -----------=20 NSI-side: read-only=20 HFC-side: read-only=20 =20 4.2.2.5 igmpCacheUpTime=20 The time elapsed since this entry was created.=20 =20 Passive Mode / HFC-side: MUST only apply to duration of membership=20 on HFC-side interface (e.g., membership is only active on subscriber=20 side of CMTS).=20 =20 Active Mode=20 -----------=20 NSI-side: read-only=20 HFC-side: read-only=20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 18=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.2.2.6 igmpCacheExpiryTime=20 =20 The minimum amount of time remaining before this entry will be aged=20 out.=20 =20 Passive Mode / HFC-side: MUST only apply to duration of membership=20 on HFC-side interface (e.g., membership is only active on subscriber=20 side of CMTS).=20 =20 Active Mode=20 -----------=20 NSI-side: read-only=20 HFC-side: read-only=20 =20 4.2.2.7 igmpCacheStatus=20 =20 The status of this entry.=20 =20 Passive Mode / HFC-side: read-create MUST only apply to membership=20 on HFC-side interface (e.g., membership is only active on subscriber=20 side of CMTS). Deletion of a row results in preventing downstream=20 forwarding to this IP Multicast group address on this interface.=20 =20 Active Mode=20 -----------=20 NSI-side: read-create=20 HFC-side: read-create=20 =20 =20 4.2.2.8 igmpCacheVersion1HostTimer=20 =20 The time remaining until the local querier will assume that there=20 are no longer any IGMP version 1 members on this IP subnet attached=20 to this interface. Upon hearing any IGMPv1 membership report, this=20 value is reset to the group membership timer. While this time=20 remaining is non-zero, the local querier ignores any IGMPv2 leave=20 messages for this group that it receives on this interface.=20 =20 Passive Mode / All interfaces: n/a, read-only. Return a value of=20 zero.=20 =20 Active Mode=20 -----------=20 NSI-side: read-only.=20 HFC-side: read-only.=20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 19=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.3 IGMP MIB Compliance and MIB Object Groupings=20 =20 This section presents a proposed set of MIB compliance and MIB=20 Groups that are applicable to the description as set forth in this=20 document.=20 =20 4.3.1 Docsis 1.1. IGMP MIB Compliance Statements=20 =20 4.3.1.1 docsIgmpV2PassiveDeviceCompliance=20 =20 docsIgmpV2PassiveDeviceCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "The compliance statement for DOCSIS Devices passively running=20 IGMPv2 and implementing the IGMP MIB.=94=20 MODULE - this module=20 MANDATORY-GROUPS { igmpBaseMIBGroup,=20 igmpRouterMIBGroup,=20 igmpV2RouterMIBGroup=20 }=20 OBJECT igmpInterfaceStatus=20 MIN-ACCESS read-only=20 DESCRIPTION=20 "Write access is not required. "=20 OBJECT igmpCacheStatus=20 MIN-ACCESS read-only=20 DESCRIPTION=20 "Write access is not required."=20 ::=3D {docsIgmpMIBCompliances 1}=20 =20 4.3.1.2 docsIgmpV2ActiveDeviceCompliance=20 docsIgmpV2ActiveCmCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "The compliance statement for DOCSIS Devices actively running=20 IGMPv2 and implementing the IGMP MIB.=94=20 MODULE - this module=20 MANDATORY-GROUPS { igmpBaseMIBGroup,=20 igmpV2HostMIBGroup,=20 igmpRouterMIBGroup,=20 igmpV2RouterMIBGroup=20 }=20 OBJECT igmpInterfaceStatus=20 MIN-ACCESS read-only=20 DESCRIPTION=20 "Write access is not required."=20 OBJECT igmpCacheStatus=20 MIN-ACCESS read-only=20 DESCRIPTION=20 "Write access is not required.=94=20 ::=3D {docsIgmpMIBCompliances 2}=20 =20 =20 =20 Abramson Informational ( Expires June 2001) 20=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 4.3.2 MIB Groups=20 =20 See IGMP MIB for a description of the objects included in each=20 group.=20 =20 4.3.2.1 igmpV2HostMIBGroup=20 =20 Active Devices only (optional, see notes for igmpCacheSelf).=20 =20 4.3.2.1 igmpV2RouterMIBGroup=20 =20 Active and Passive Devices=20 =20 4.3.2.2 igmpBaseMIBGroup=20 =20 Active and Passive Devices=20 =20 4.3.2.3 igmpV2RouterMIBGroup=20 =20 Active and Passive Devices=20 =20 4.3.2.4 igmpRouterMIBGroup=20 =20 Active and Passive Devices=20 =20 4.3.2.5 igmpV2HostOptMIBGroup=20 =20 Active and Passive Devices=20 =20 4.3.2.6 igmpV2ProxyMIBGroup=20 =20 Active Devices only.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 21=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 5. Docsis 1.1 IGMP Mode Control and Cable Device MIB Support=20 =20 The default mode of a Docsis 1.1 CM MUST be to support passive IGMP=20 operation. The default mode of a Docsis 1.1 CMTS SHOULD be to=20 support passive IGMP operation. No objects in the IDMR IGMP MIB=20 provide a consistent way to control this mode for a DOCSIS 1.1=20 device. One option considered was to overload the context of the=20 igmpInterfaceProxyIfIndex such that setting this object constitutes=20 active mode and clearing the object constitutes passive mode. The=20 problem is that this precludes implementation of a DOCSIS 1.1 device=20 as a multicast router. Another option was to overload the context of=20 the igmpInterfaceQueryInterval such that setting this object=20 constitutes active mode and clearing this object constitutes passive=20 mode. However, this precludes setting the query interval to zero.=20 =20 The, unambiguous, solution to controlling DOCSIS 1.1 IGMP mode is to=20 define a new object. The following object is proposed as a new entry=20 to the docsDevBaseGroup in the Cable Device MIB, [25]. This object=20 is shown as read-write for devices that support both modes. For=20 devices that only support the required passive mode, this object is=20 specified to be read-only.=20 =20 docsDevIgmpModeControl OBJECT-TYPE=20 SYNTAX INTEGER {passive(1), active(2)}=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION "This object controls the mode of operation that=20 the CM/CMTS will operate in. In passive mode,=20 the device forwards IGMP between interfaces=20 based on knowledge of Multicast Session activity=20 on the subscriber side interface and the rules=20 defined in section 3.3.1 of the RFI. In active=20 mode, the device terminates at and initiates=20 IGMP=20 through its interfaces based on the knowledge of=20 Multicast Session activity on the subscriber=20 side interface."=20 DEFVAL { 1 } -- passive=20 ::=3D { docsDevBase 6 }=20 =20 docsDevBaseGroup OBJECT-GROUP=20 OBJECTS {=20 docsDevRole,=20 docsDevDateTime,=20 docsDevResetNow,=20 docsDevSerialNumber,=20 docsDevSTPControl,=20 docsDevIgmpModeControl=20 }=20 STATUS current=20 DESCRIPTION=20 "A collection of objects providing device status and=20 control."=20 =20 Abramson Informational ( Expires June 2001) 22=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 ::=3D { docsDevGroups 1 }=20 =20 docsDevBasicComplianceV2 MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "The compliance statement for MCNS Cable Modems and=20 Cable Modem Termination Systems."=20 =20 OBJECT docsDevIgmpModeControl=20 MIN-ACCESS read-only=20 DESCRIPTION=20 "It is compliant to implement this object as read-only.=20 Devices need only support passive(1) mode."=20 ::=3D { docsDevCompliances 1 }=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 23=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 =20 6. Security Considerations=20 =20 This MIB relates to a system which will provide metropolitan public=20 internet access to multicast services. The security considerations=20 discussed in RFC 2933, [20], apply here as well.=20 =20 6.1 Additional Docsis IGMP Security Considerations=20 =20 Although it is beyond the scope of this MIB application note, the=20 security of IGMP and IP Multicasting in a Docsis network is worth=20 further discussion. For example, improper transmission of IGMP PDUs=20 may result in unauthorized access to multicast services, and may=20 present 'denial-of-service' potential on the HFC (e.g., mischievous=20 users could simply flood the upstream with IGMP for sessions they=20 are not authorized to receive; the result being cluttering the=20 downstream with unauthorized and undesired multicast traffic).=20 =20 Early discussions on IGMP within the IPCDN and Docsis communities=20 centered on conditional and timed multicast session activity. More=20 recent discussions have focused on a tighter coupling between the=20 Baseline Privacy Plus protocol, [24], and IGMP to resolve these=20 issues. Tying these protocols too tightly together may present=20 problems and complexity that is unwarranted during the early stages=20 of multicast deployments in Docsis networks. It is important to note=20 that a Docsis CM will never forward unauthorized and encrypted data=20 from the HFC to the CMCI as it will fail on the downstream Security=20 Association as defined by the BPI+ protocol. It is expected that=20 'non-destructive' users will give up trying to receive unauthorized=20 sessions (e.g., stop sending membership reports for sessions not=20 received). This will result in timing-out the session through normal=20 IGMP mechanisms (e.g., no one left sending MRs for this group).=20 Preventing denial-of-service is, perhaps, the greater security=20 concern for IGMP in a Docsis network. One approach is to establish=20 controls on the CMTS that consult BPI+ Authorization tables before=20 accepting IGMP Membership Reports from a given CM.=20 =20 6.1.1 Proposed Security Rules for Docsis IGMP=20 =20 The following set of rules have been proposed to provide better=20 security for IGMP/IP Multicast in Docsis networks. The reader is=20 referred to the RFC 2236, [22], and the BPI+ specification, [24].=20 =20 NOTE: forwarding of IGMP, presented below, MUST be subject to permit=20 rules at the IP and IEEE802.2 MAC Layer.=20 =20 o The CM MUST NOT forward IGMP PDUs (Membership Reports, Leaves,=20 etc.) upstream for Multicast Sessions that have been SA-MAP=20 Reply Rejected for authorization (e.g., this does not apply to=20 SA-MAP reject for unencrypted sessions).=20 =20 =20 =20 Abramson Informational ( Expires June 2001) 24=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 =20 Discussion: this requires that the CM apply the following order to=20 forwarding of IGMP PDUs upstream.=20 =20 If the IGMP PDU is for a Session that is new to the=20 CMCI-LAN, then the CM MUST NOT forward the PDU for this=20 Session until such time as a BPI+ SA-MAP Reply, with the=20 requested SA mapping, or a SA-Map Reject 'not mapped to=20 a SA' is received. Said another way, the CM MUST NOT=20 forward IGMP for Sessions that result in a SA-MAP Reject=20 not authorized for SA. The CM MUST continue to treat all=20 subsequent IGMP Membership Reports for this session as=20 being new and MUST result in a SA-MAP Request for this=20 traffic flow (Session). =20 =20 o The CM MUST consider all Multicast Sessions, associated with a=20 given SA, inactive on the CMCI-LAN as soon as the TEK state=20 machine terminates for these sessions. That is, once the TEK=20 state machine terminates (either by a Key Reject or=20 Authorization Invalid), Multicast data for Sessions associated=20 with this SA MUST NOT be forwarded from the HFC to the CMCI AND=20 the CM MUST consider subsequent MRs for these Sessions as being=20 new (as described above).=20 =20 o The CMTS SHOULD NOT process an IGMP PDU sent from/through a CM=20 if the MR is for a Session that is associated with Multicast=20 Addresses that has a SA (is encrypted) and is not authorized for=20 the CM (based on the HFC-side CM mac address).=20 =20 Discussion: this requires that the CMTS consult the BPI+=20 docsBpi2CmIpMulticastMapTable (IP Multicast Address to SAID) table=20 and the docsBpi2CmtsMulticastAuthTable (CMTS Multicast SAID=20 Authorization) table before processing IGMP messages (MR or Leave;=20 Queries are explicitly prohibited on the upstream). The following=20 rules apply.=20 =20 If the IGMP is for a Multicast address that has an SA=20 and the CM from which this IGMP PDU was sent is=20 authorized for this SA, then process the IGMP (i.e., MRs=20 are reflected on downstream, and the NSI multicast=20 filters are removed to send downstream data, etc.)=20 =20 If the IGMP is for a Multicast address that does not=20 have an SA, then process the IGMP.=20 =20 If the IGMP is for a Multicast address that has an SA=20 and the CM from which this IGMP PDU was sent is not=20 authorized for this SA, then the IGMP PDU SHOULD be=20 silently discarded.=20 =20 =20 Abramson Informational ( Expires June 2001) 25=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 o The CMTS MAY stop forwarding Multicast data downstream for=20 Sessions that have an SA and for which there is no TEK state=20 machine running.=20 =20 =20 =20 =20 8. References=20 =20 [1] Bradner, S., "The Internet Standards Process - Revision- 3", BCP 9, RFC 2026, October 1996.=20 =20 [2] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 =20 [3] Harrington, D., Presuhn, R. and B. Wijnen, "An=20 Architecture for Describing SNMP Management Frameworks",=20 RFC 2571, May 1999.=20 =20 [4] Rose, M. and K. McCloghrie, "Structure and=20 Identification of Management Information for TCP/IP - based Internets", STD 16, RFC 1155, May 1990.=20 =20 [5] Rose, M. and K. McCloghrie, "Concise MIB Definitions",=20 STD 16, RFC 1212, March 1991.=20 =20 [6] Rose, M., "A Convention for Defining Traps for use with=20 the SNMP", RFC 1215, March 1991.=20 =20 [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder,=20 "Structure of Management Information for Version 2=20 (SMIv2)", STD 58, RFC2578, April 1999.=20 =20 [8] McCloghrie, K., Perkins, D. and J. Schoenwaelder,=20 "Textual Conventions for SMIv2", STD 58, RFC 2579, April=20 1999.=20 =20 [9] McCloghrie, K., Perkins, D. and J. Schoenwaelder,=20 "Conformance Statements for SMIv2", STD 58, RFC 2580,=20 April 1999.=20 =20 [10] Case, J., Fedor, M., Schoffstall, M. and J. Davin,=20 "Simple Network Management Protocol", STD 15, RFC 1157,=20 May 1990.=20 =20 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,=20 "Introduction to Community-based SNMPv2", RFC 1901,=20 January 1996.=20 =20 [12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,=20 "Transport Mappings for Version 2 of the Simple Network=20 Management Protocol (SNMPv2)", RFC 1906, January 1996.=20 =20 =20 Abramson Informational ( Expires June 2001) 26=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 [13] Case, J., Harrington D., Presuhn R. and B. Wijnen,=20 "Message Processing and Dispatching for the Simple=20 Network Management Protocol (SNMP)", RFC 2572, April=20 1999.=20 =20 [14] Blumenthal, U. and B. Wijnen, "User-based Security Model=20 (USM)for version 3 of the Simple Network Management=20 Protocol (SNMPv3)", RFC 2574, April 1999.=20 =20 =20 [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,=20 "Protocol Operations for Version 2 of the Simple Network=20 Management Protocol (SNMPv2)", RFC 1905, January 1996.=20 =20 [16] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",=20 RFC 2573, April 1999.=20 =20 [17] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based=20 Access Control Model (VACM) for the Simple Network=20 Management Protocol(SNMP)", RFC 2575, April 1999.=20 =20 [18] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,=20 "Message Processing and Dispatching for the Simple=20 Network Management Protocol (SNMP)=94, RFC 2272, January=20 1998.=20 =20 [19] Blumenthal, U., and B. Wijnen, "User-based Security=20 Model (USM) for version 3 of the Simple Network=20 Management Protocol (SNMPv3)=94, RFC 2274, January 1998.=20 =20 [20] McCloghrie, K., Farinacci, D., Thaler, D., "Internet=20 Group Management Protocol MIB=94, RFC 2933, October 2000. = =20 [21] Fenner, W., "IGMP-based Multicast Forwarding (''IGMP=20 Proxying'')=94, IETF Internet Draft, http://www.ietf.org/ = internet-drafts/draft-fenner-igmp-proxy-03.txt.=20 =20 [22] Fenner, W. " Internet Group Management Protocol, Version=20 2", RFC 2236, November 1997.=20 =20 [23] "Data Over Cable Service Interface Specifications -=20 Radio Frequency Interface Specification=94, vSP-RFIv1.1- I05-000714, July 14, 2000.=20 =20 [24] "Data Over Cable Service Interface Specifications - Baseline Privacy Plus Interface Specification=94, vSP- BPI+-I05-000714, July 14, 2000.=20 =20 [25] St. Johns, M., "DOCSIS Cable Device MIB=94, RFC 2669,=20 August 1999.=20 =20 =20 =20 =20 Abramson Informational ( Expires June 2001) 27=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 9. Acknowledgments=20 =20 The author would like to acknowledge the following individuals for=20 contributions to this document. This includes Paul Gray, Greg=20 Nakanishi, Pak Siripunkaw, Mike St. Johns, Rich Woundy, and Greg=20 White.=20 =20 =20 10. Author's Address=20 =20 Howard D. Abramson=20 ADC Telecommunications=20 8 Technology Drive=20 Westborough, MA 01581=20 Phone: 508.870.2615=20 Email: howard_abramson@adc.com=20 =20 =20 =20 =20 Intellectual Property=20 =20 The IETF takes no position regarding the validity or scope of any =20 intellectual property or other rights that might be claimed to=20 pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; neither does it represent that it=20 has made any effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track and=20 standards-related documentation can be found in BCP-11. Copies of=20 claims of rights made available for publication and any assurances=20 of licenses to be made available, or the result of an attempt made=20 to obtain a general license or permission for the use of such=20 proprietary rights by implementers or users of this specification=20 can be obtained from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights which may cover technology that may be required to practice=20 this standard. Please address the information to the IETF Executive=20 Director.=20 =20 =20 Abramson Informational ( Expires June 2001) 28=20 =0C Docsis 1.1 IGMPv2 MIB December 2000=20 =20 =20 =20 =20 =20 =20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2000). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 =20 =20 Abramson Informational ( Expires June 2001) 29=20 =0C ------=_NextPart_000_0016_01C05858.F6CDE970-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Nov 29 17:31:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07156; Wed, 29 Nov 2000 17:31:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15886; Wed, 29 Nov 2000 17:27:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15861 for ; Wed, 29 Nov 2000 17:27:39 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05761 for ; Wed, 29 Nov 2000 17:27:38 -0500 (EST) Received: from rwoundy-pc.cisco.com (dhcp-128-107-137-30.cisco.com [128.107.137.30]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA01205; Wed, 29 Nov 2000 17:27:09 -0500 (EST) Message-Id: <4.3.2.7.2.20001117153307.00b92310@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 17:28:45 -0500 To: ipcdn@ietf.org From: Rich Woundy Cc: narten@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] BPI MIB last call Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, I would like to announce the beginning of the second, hopefully final) working group last call for the BPI MIB. Please send your comments to this mailing list. Note that this last call happens to end on the same day as the IPCDN meeting at the San Diego IETF. As I have noted in previous email, there were a small number of changes required from the IETF MIB Doctor review, most importantly affecting docsBpiIpMulticastMapControl and docsBpiMulticastAuthControl. I have not received any comments on the latest published draft -- except for the (somewhat unrelated) discussion about whether the BPI MIB must be implemented on DOCSIS 1.1 CMTSs. I believe the consensus answer is no; the BPI+ MIB should be (or must be made) sufficient to manage the state of both BPI and BPI+ cable modems. Incidentally, that is also Cisco's own position, despite my earlier doubts (due to SAID/SID collisions). -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 30 11:38:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25639; Thu, 30 Nov 2000 11:38:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14562; Thu, 30 Nov 2000 11:37:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14528 for ; Thu, 30 Nov 2000 11:36:54 -0500 (EST) Received: from ferao.jungle.bt.co.uk (ferao.jungle.bt.co.uk [132.146.107.45]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24876 for ; Thu, 30 Nov 2000 11:36:52 -0500 (EST) Received: from bt.com ([132.146.107.103]) by ferao.jungle.bt.co.uk (8.9.1b+Sun/Jungle-8.9.1-03) with ESMTP id QAA27523 for ; Thu, 30 Nov 2000 16:20:17 GMT Message-ID: <3A2681F4.D981D910@bt.com> Date: Thu, 30 Nov 2000 16:36:04 +0000 From: jerome tassel X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: ipcdn@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] DOCSIS 1.1 QoS Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit I am trying to understand what DOCSIS 1.1 actually provides. If I understand well it can be used to provide bandwidth guarantees to a single cable modem. Like: assure 2Mbps from an IP@ to at modem. There is a profile per cable modem. BUT if all users are within their profile and the sum of their traffic is more than the downstream channel bandwidth (27 or 40Mbps) what happens to the extra traffic? Is it randomly dropped or are the traffic priority within each cable profile retained. i.e. lower priority traffic to each cable modem would get dropped before hihger priority ones ? Or is the handling of this vendor specific? Jerome _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Nov 30 13:01:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01650; Thu, 30 Nov 2000 13:01:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16486; Thu, 30 Nov 2000 12:42:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16458 for ; Thu, 30 Nov 2000 12:42:39 -0500 (EST) Received: from mail07b.vwh1.net (mail07b.vwh1.net [209.238.9.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23747 for ; Thu, 30 Nov 2000 12:42:37 -0500 (EST) Received: from www.carrier9.com (209.238.173.203) by mail07b.vwh1.net (RS ver 1.0.58s) with SMTP id 03508356; Thu, 30 Nov 2000 12:42:05 -0500 (EST) From: "Sukanta Ganguly" To: "jerome tassel" , Subject: RE: [ipcdn] DOCSIS 1.1 QoS Date: Thu, 30 Nov 2000 09:45:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A2681F4.D981D910@bt.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Loop-Detect: 1 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit This is a subjective question and is dependent on the service provider as to how it would want to handle. Every subscriber has a profile which will ( or better if I say 'should') be respected. Ideally the provider should not subscribe more than the total downstream bw, but there are lot of smart algorithms, based on hueristics that could be applied so that over provisioning can be done and based on the policies appropriate decisions could be made. Dropping packets, delayed scheduling etc can be done. SG -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of jerome tassel Sent: Thursday, November 30, 2000 8:36 AM To: ipcdn@ietf.org Subject: [ipcdn] DOCSIS 1.1 QoS I am trying to understand what DOCSIS 1.1 actually provides. If I understand well it can be used to provide bandwidth guarantees to a single cable modem. Like: assure 2Mbps from an IP@ to at modem. There is a profile per cable modem. BUT if all users are within their profile and the sum of their traffic is more than the downstream channel bandwidth (27 or 40Mbps) what happens to the extra traffic? Is it randomly dropped or are the traffic priority within each cable profile retained. i.e. lower priority traffic to each cable modem would get dropped before hihger priority ones ? Or is the handling of this vendor specific? Jerome _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn