From bclaise@cisco.com Mon Nov 5 07:05:43 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25EE21F84AB for ; Mon, 5 Nov 2012 07:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5N9eIAsgOw9 for ; Mon, 5 Nov 2012 07:05:43 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id D07C621F84DB for ; Mon, 5 Nov 2012 07:05:42 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA5F5gcH023642 for ; Mon, 5 Nov 2012 10:05:42 -0500 (EST) Received: from [10.82.218.240] (rtp-vpn3-749.cisco.com [10.82.218.240]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA5F5fCW028715 for ; Mon, 5 Nov 2012 10:05:41 -0500 (EST) Message-ID: <5097D5C5.1030400@cisco.com> Date: Mon, 05 Nov 2012 10:05:41 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <20121101203215.28287.2702.idtracker@ietfa.amsl.com> In-Reply-To: <20121101203215.28287.2702.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101203215.28287.2702.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090007060409030806060802" Subject: [MIB-DOCTORS] =?utf-8?q?MEF_UNIV-EVC_MIB_review_=28was=3A_New_Lia?= =?utf-8?q?ison_Statement=2C_=22Ethernet_Services_MIB_Status=22=C2=B0?= X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:05:43 -0000 This is a multi-part message in MIME format. --------------090007060409030806060802 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Who would like to volunteer to review the MEF UNI-EVC MIB? See Ethernet Services MIB Status https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx Regards, Benoit -------- Original Message -------- Subject: New Liaison Statement, "Ethernet Services MIB Status" Date: Thu, 01 Nov 2012 13:32:15 -0700 From: Liaison Statement Management Tool To: Ronald Bonica , Benoit Claise CC: The IETF Chair , Nan Chen , Bill Bjorkman , Raghu Ranganathan , Title: Ethernet Services MIB Status Submission Date: 2012-10-29 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1214/ Please reply by 2013-01-28 From: MEF (Mike Bencheck ) To: Operations and Management Area (Ronald Bonica , Benoit Claise ) Cc: The IETF Chair ,Nan Chen ,Bill Bjorkman ,Raghu Ranganathan , Reponse Contact: Technical Contact: Purpose: For comment Body: Attachments: Ethernet Services MIB Status https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx --------------090007060409030806060802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear all,

Who would like to volunteer to review the MEF UNI-EVC MIB?
See Ethernet Services MIB Status https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx

Regards, Benoit


-------- Original Message --------
Subject: New Liaison Statement, "Ethernet Services MIB Status"
Date: Thu, 01 Nov 2012 13:32:15 -0700
From: Liaison Statement Management Tool <lsmt@ietf.org>
To: Ronald Bonica <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>
CC: The IETF Chair <chair@ietf.org>, Nan Chen <nan@metroethernetforum.org>, Bill Bjorkman <bill@metroethernetforum.net>, Raghu Ranganathan <rraghu@ciena.com>, <nan@metroethernetforum.org> 


Title: Ethernet Services MIB Status
Submission Date: 2012-10-29
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1214/
Please reply by 2013-01-28
From: MEF (Mike Bencheck <mike.bencheck@verizon.com>)
To: Operations and Management Area (Ronald Bonica <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>)
Cc: The IETF Chair <chair@ietf.org>,Nan Chen <nan@metroethernetforum.org>,Bill Bjorkman <bill@metroethernetforum.net>,Raghu Ranganathan <rraghu@ciena.com>,<nan@metroethernetforum.org>
Reponse Contact: 
Technical Contact: 
Purpose: For comment

Body: 
Attachments:

    Ethernet Services MIB Status
    https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx



--------------090007060409030806060802-- From bclaise@cisco.com Wed Nov 7 09:03:16 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C8B21F89F5 for ; Wed, 7 Nov 2012 09:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.476 X-Spam-Level: X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zorIA--qhLZJ for ; Wed, 7 Nov 2012 09:03:15 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 512B321F8C30 for ; Wed, 7 Nov 2012 09:03:08 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA7H34gg008643 for ; Wed, 7 Nov 2012 12:03:05 -0500 (EST) Received: from [10.82.212.55] (rtp-vpn4-1079.cisco.com [10.82.212.55]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA7H305T012154 for ; Wed, 7 Nov 2012 12:03:00 -0500 (EST) Message-ID: <509A9444.80108@cisco.com> Date: Wed, 07 Nov 2012 12:03:00 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <20121101203215.28287.2702.idtracker@ietfa.amsl.com> <5097D5C5.1030400@cisco.com> In-Reply-To: <5097D5C5.1030400@cisco.com> Content-Type: multipart/alternative; boundary="------------020703090201040908020909" Subject: Re: [MIB-DOCTORS] MEF UNIV-EVC MIB review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:03:16 -0000 This is a multi-part message in MIME format. --------------020703090201040908020909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Who would like to volunteer to review the MEF UNI-EVC MIB? Regards, Benoit > Dear all, > > Who would like to volunteer to review the MEF UNI-EVC MIB? > See Ethernet Services MIB Status > https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx > > Regards, Benoit > > > -------- Original Message -------- > Subject: New Liaison Statement, "Ethernet Services MIB Status" > Date: Thu, 01 Nov 2012 13:32:15 -0700 > From: Liaison Statement Management Tool > To: Ronald Bonica , Benoit Claise > > CC: The IETF Chair , Nan Chen > , Bill Bjorkman > , Raghu Ranganathan , > > > > > Title: Ethernet Services MIB Status > Submission Date: 2012-10-29 > URL of the IETF Web page:http://datatracker.ietf.org/liaison/1214/ > Please reply by 2013-01-28 > From: MEF (Mike Bencheck) > To: Operations and Management Area (Ronald Bonica, Benoit Claise) > Cc: The IETF Chair,Nan Chen,Bill Bjorkman,Raghu Ranganathan, > Reponse Contact: > Technical Contact: > Purpose: For comment > > Body: > Attachments: > > Ethernet Services MIB Status > https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx > > > > > > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors --------------020703090201040908020909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Who would like to volunteer to review the MEF UNI-EVC MIB?

Regards, Benoit
Dear all,

Who would like to volunteer to review the MEF UNI-EVC MIB?
See Ethernet Services MIB Status https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx

Regards, Benoit


-------- Original Message --------
Subject: New Liaison Statement, "Ethernet Services MIB Status"
Date: Thu, 01 Nov 2012 13:32:15 -0700
From: Liaison Statement Management Tool <lsmt@ietf.org>
To: Ronald Bonica <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>
CC: The IETF Chair <chair@ietf.org>, Nan Chen <nan@metroethernetforum.org>, Bill Bjorkman <bill@metroethernetforum.net>, Raghu Ranganathan <rraghu@ciena.com>, <nan@metroethernetforum.org> 


Title: Ethernet Services MIB Status
Submission Date: 2012-10-29
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1214/
Please reply by 2013-01-28
From: MEF (Mike Bencheck <mike.bencheck@verizon.com>)
To: Operations and Management Area (Ronald Bonica <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>)
Cc: The IETF Chair <chair@ietf.org>,Nan Chen <nan@metroethernetforum.org>,Bill Bjorkman <bill@metroethernetforum.net>,Raghu Ranganathan <rraghu@ciena.com>,<nan@metroethernetforum.org>
Reponse Contact: 
Technical Contact: 
Purpose: For comment

Body: 
Attachments:

    Ethernet Services MIB Status
    https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx









_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors

--------------020703090201040908020909-- From bertietf@bwijnen.net Wed Nov 7 12:15:22 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D375121F8A12 for ; Wed, 7 Nov 2012 12:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZtdikCQxbNb for ; Wed, 7 Nov 2012 12:15:18 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id E793521F8CBC for ; Wed, 7 Nov 2012 12:15:17 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TWC1r-0002Oq-EZ; Wed, 07 Nov 2012 21:15:17 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=dhcp-4560.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TWC1r-0004EM-7c; Wed, 07 Nov 2012 21:15:15 +0100 Message-ID: <509AC151.5000100@bwijnen.net> Date: Wed, 07 Nov 2012 15:15:13 -0500 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Benoit Claise References: <20121101203215.28287.2702.idtracker@ietfa.amsl.com> <5097D5C5.1030400@cisco.com> <509A9444.80108@cisco.com> In-Reply-To: <509A9444.80108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121107 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43d6ba150e3dbc68bd3b41a772352086c Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] MEF UNIV-EVC MIB review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:15:22 -0000 So do they have an ascii txt file of the MIB module? I could only find a PDF file, and that even was through 2 or 3 levels of indirection from the below email. Quickly scanning the PDF file... I bet it will be a time consuming undertaking. I see weird things, but I also see use of obsoleted TC questionable use INTEGER. I won't have the needed time to commit to this. This page: http://metroethernetforum.org/liaison_login.htm startes that it is an "Approved draft 1". So does that mean it is already final? Bert On 11/7/12 12:03 PM, Benoit Claise wrote: > Who would like to volunteer to review the MEF UNI-EVC MIB? > > Regards, Benoit >> Dear all, >> >> Who would like to volunteer to review the MEF UNI-EVC MIB? >> See Ethernet Services MIB Status >> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx >> >> Regards, Benoit >> >> >> -------- Original Message -------- >> Subject: New Liaison Statement, "Ethernet Services MIB Status" >> Date: Thu, 01 Nov 2012 13:32:15 -0700 >> From: Liaison Statement Management Tool >> To: Ronald Bonica , Benoit Claise >> CC: The IETF Chair , Nan Chen , Bill Bjorkman , Raghu >> Ranganathan , >> >> >> >> Title: Ethernet Services MIB Status >> Submission Date: 2012-10-29 >> URL of the IETF Web page:http://datatracker.ietf.org/liaison/1214/ >> Please reply by 2013-01-28 >> From: MEF (Mike Bencheck) >> To: Operations and Management Area (Ronald Bonica, Benoit Claise) >> Cc: The IETF Chair,Nan Chen,Bill Bjorkman,Raghu Ranganathan, >> Reponse Contact: >> Technical Contact: >> Purpose: For comment >> >> Body: >> Attachments: >> >> Ethernet Services MIB Status >> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx >> >> >> >> >> >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From bclaise@cisco.com Thu Nov 8 20:46:59 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094BE11E80BA for ; Thu, 8 Nov 2012 20:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqGmrOwAKfkx for ; Thu, 8 Nov 2012 20:46:58 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0B59C11E809B for ; Thu, 8 Nov 2012 20:46:57 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA94kvnl004719; Thu, 8 Nov 2012 23:46:57 -0500 (EST) Received: from [10.82.240.217] (rtp-vpn2-217.cisco.com [10.82.240.217]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA94krrT006346; Thu, 8 Nov 2012 23:46:53 -0500 (EST) Message-ID: <509C8ABD.8030708@cisco.com> Date: Thu, 08 Nov 2012 23:46:53 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <20121108231803.406E772E038@rfc-editor.org> In-Reply-To: <20121108231803.406E772E038@rfc-editor.org> X-Forwarded-Message-Id: <20121108231803.406E772E038@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------020307090604030306090502" Cc: Ron Bonica Subject: [MIB-DOCTORS] Fwd: [Technical Errata Reported] RFC3416 (3402) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 04:46:59 -0000 This is a multi-part message in MIME format. --------------020307090604030306090502 Content-Type: multipart/alternative; boundary="------------060609060706060302090406" --------------060609060706060302090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Guys, Is this a correct errata? Regards, Benoit -------- Original Message -------- Subject: [Technical Errata Reported] RFC3416 (3402) Date: Thu, 8 Nov 2012 15:18:03 -0800 (PST) From: RFC Errata System To: rbonica@juniper.net, bclaise@cisco.com, mundy@tislabs.com, dbh@enterasys.com CC: msauve@alientech.net, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3416&eid=3402 -------------------------------------- Type: Technical Reported by: Mike Sauve Section: 3 Original Text ------------- max-bindings INTEGER ::= 2147483647 Corrected Text -------------- max-bindings ::= INTEGER (2147483647) Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3416 (draft-ietf-snmpv3-update-proto-08) -------------------------------------- Title : Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) Publication Date : December 2002 Author(s) : R. Presuhn, Ed. Category : STANDARD Source : SNMP Version 3 Area : Operations and Management Stream : IETF Verifying Party : IESG --------------060609060706060302090406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Guys,

Is this a correct errata?

Regards, Benoit


-------- Original Message --------
Subject: [Technical Errata Reported] RFC3416 (3402)
Date: Thu, 8 Nov 2012 15:18:03 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: rbonica@juniper.net, bclaise@cisco.com, mundy@tislabs.com, dbh@enterasys.com
CC: msauve@alientech.net, rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC3416,
"Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3416&eid=3402

--------------------------------------
Type: Technical
Reported by: Mike Sauve <msauve@alientech.net>

Section: 3

Original Text
-------------
max-bindings INTEGER ::= 2147483647

Corrected Text
--------------
max-bindings ::= INTEGER (2147483647)

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3416 (draft-ietf-snmpv3-update-proto-08)
--------------------------------------
Title               : Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
Publication Date    : December 2002
Author(s)           : R. Presuhn, Ed.
Category            : STANDARD
Source              : SNMP Version 3
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG



--------------060609060706060302090406-- --------------020307090604030306090502 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------020307090604030306090502-- From randy_presuhn@mindspring.com Thu Nov 8 22:31:43 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6729221F8B97 for ; Thu, 8 Nov 2012 22:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.41 X-Spam-Level: X-Spam-Status: No, score=-100.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS6EE2f6GPL2 for ; Thu, 8 Nov 2012 22:31:42 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id AA02121F8B96 for ; Thu, 8 Nov 2012 22:31:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qVNYiQ1qHbMMx1xGvschNvyOPeMpBDzR45ooRR/qbd6hjzRt1In5VBffP2huNCYi; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.227.99] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TWi7v-0003eh-A6; Fri, 09 Nov 2012 01:31:39 -0500 Message-ID: <002c01cdbf0d$0be74b80$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Benoit Claise" , "MIB Doctors \(E-mail\)" References: <20121108231803.406E772E038@rfc-editor.org> <509C8ABD.8030708@cisco.com> Date: Fri, 9 Nov 2012 22:31:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97e0cd956e51b76c774951c9a3afc0ebeb5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.227.99 Cc: Ron Bonica Subject: Re: [MIB-DOCTORS] Fwd: [Technical Errata Reported] RFC3416 (3402) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 06:31:43 -0000 Hi - I'm pretty sure RFC 3416 is correct as-is with respect to the proposed erratum. According to section 4.2 of the ASN.1 spec, the grammar for the value notation is ValueDefinition ::= identifier Type "::=" Value The current text conforms to this grammar, and the usage in this particular case is closely analogous to the example the ASN.1 standard gives in that same section. It looks like the submitter wants to change the value definition into a type definition, which to me would be inconsistent with how the the SNMP specification employs max-bindings. Bottom line: I don't see a problem in the original text, and would reject the proposed change. Randy ----- Original Message ----- > From: "Benoit Claise" > To: "MIB Doctors (E-mail)" > Cc: "Ron Bonica" > Sent: Thursday, November 08, 2012 8:46 PM > Subject: [MIB-DOCTORS] Fwd: [Technical Errata Reported] RFC3416 (3402) > > Hi Guys, > > Is this a correct errata? > > Regards, Benoit > > > -------- Original Message -------- > Subject: [Technical Errata Reported] RFC3416 (3402) > Date: Thu, 8 Nov 2012 15:18:03 -0800 (PST) > From: RFC Errata System > To: rbonica@juniper.net, bclaise@cisco.com, mundy@tislabs.com, > dbh@enterasys.com > CC: msauve@alientech.net, rfc-editor@rfc-editor.org > > > > The following errata report has been submitted for RFC3416, > "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3416&eid=3402 > > -------------------------------------- > Type: Technical > Reported by: Mike Sauve > > Section: 3 > > Original Text > ------------- > max-bindings INTEGER ::= 2147483647 > > Corrected Text > -------------- > max-bindings ::= INTEGER (2147483647) > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC3416 (draft-ietf-snmpv3-update-proto-08) > -------------------------------------- > Title : Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) > Publication Date : December 2002 > Author(s) : R. Presuhn, Ed. > Category : STANDARD > Source : SNMP Version 3 > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > > > > > -------------------------------------------------------------------------------- > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From j.schoenwaelder@jacobs-university.de Fri Nov 9 03:18:28 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E027621F8440 for ; Fri, 9 Nov 2012 03:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88+2-Z7uUzs8 for ; Fri, 9 Nov 2012 03:18:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3508321F8436 for ; Fri, 9 Nov 2012 03:18:28 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5142720C27; Fri, 9 Nov 2012 12:18:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ynsZJc9S8dtW; Fri, 9 Nov 2012 12:18:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AACD320C15; Fri, 9 Nov 2012 12:18:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9FFCF22B9A87; Fri, 9 Nov 2012 12:18:29 +0100 (CET) Date: Fri, 9 Nov 2012 12:18:29 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20121109111829.GA81766@elstar.local> Mail-Followup-To: Randy Presuhn , Benoit Claise , "MIB Doctors (E-mail)" , Ron Bonica References: <20121108231803.406E772E038@rfc-editor.org> <509C8ABD.8030708@cisco.com> <002c01cdbf0d$0be74b80$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01cdbf0d$0be74b80$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Fwd: [Technical Errata Reported] RFC3416 (3402) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:18:29 -0000 On Fri, Nov 09, 2012 at 10:31:39PM -0800, Randy Presuhn wrote: [...] > Bottom line: > I don't see a problem in the original text, and would reject the > proposed change. +1 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Fri Nov 9 04:52:19 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC54F21F8695 for ; Fri, 9 Nov 2012 04:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT-TwfE-SZYt for ; Fri, 9 Nov 2012 04:52:17 -0800 (PST) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28521F868F for ; Fri, 9 Nov 2012 04:52:17 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA9CqG7K021416; Fri, 9 Nov 2012 04:52:16 -0800 (PST) Received: from [10.82.216.168] (rtp-vpn3-168.cisco.com [10.82.216.168]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA9CqAHT024014; Fri, 9 Nov 2012 07:52:10 -0500 (EST) Message-ID: <509CFC7A.8010602@cisco.com> Date: Fri, 09 Nov 2012 07:52:10 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Randy Presuhn , "MIB Doctors (E-mail)" , Ron Bonica References: <20121108231803.406E772E038@rfc-editor.org> <509C8ABD.8030708@cisco.com> <002c01cdbf0d$0be74b80$6b01a8c0@oemcomputer> <20121109111829.GA81766@elstar.local> In-Reply-To: <20121109111829.GA81766@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] Fwd: [Technical Errata Reported] RFC3416 (3402) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:52:20 -0000 Thanks Randy and Juergen, Regards, Benoit > On Fri, Nov 09, 2012 at 10:31:39PM -0800, Randy Presuhn wrote: > > [...] > >> Bottom line: >> I don't see a problem in the original text, and would reject the >> proposed change. > +1 > > /js > From bclaise@cisco.com Sun Nov 11 10:53:58 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1165D21F8578 for ; Sun, 11 Nov 2012 10:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7lQ5B0pDJEx for ; Sun, 11 Nov 2012 10:53:57 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id DDB1E21F8564 for ; Sun, 11 Nov 2012 10:53:56 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABIrspg003916 for ; Sun, 11 Nov 2012 13:53:54 -0500 (EST) Received: from [10.82.242.230] (rtp-vpn2-742.cisco.com [10.82.242.230]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABIrrew008711 for ; Sun, 11 Nov 2012 13:53:54 -0500 (EST) Message-ID: <509FCAA0.4040403@cisco.com> Date: Sun, 11 Nov 2012 10:56:16 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <509D476A.1090500@alientech.net> In-Reply-To: <509D476A.1090500@alientech.net> X-Forwarded-Message-Id: <509D476A.1090500@alientech.net> Content-Type: multipart/alternative; boundary="------------090802010501010208000709" Subject: [MIB-DOCTORS] Fwd: Re: [Errata Rejected] RFC3416 (3402) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 18:53:58 -0000 This is a multi-part message in MIME format. --------------090802010501010208000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And here is the answer to the rejected errata. Any follow up? Regards, Benoit -------- Original Message -------- Subject: Re: [Errata Rejected] RFC3416 (3402) Date: Fri, 09 Nov 2012 13:11:54 -0500 From: Mike Sauve To: RFC Errata System CC: bclaise@cisco.com, iesg@ietf.org On 11/9/2012 11:39 AM, RFC Errata System wrote: > --VERIFIER NOTES-- > According to section 4.2 of the ASN.1 spec, the grammar for the value notation is > > ValueDefinition ::= identifier Type "::=" Value > The current text conforms to this grammar, and the usage in this particular case > is closely analogous to the example the ASN.1 standard gives in that same > section. Refer to ASN.1 spec (ITU-T X.680, 11/2008), found at http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.680-200811-I!!PDF-E There is no section 4.2. The term "ValueDefinition" is not found. > It looks like the submitter wants to change the value definition into a > type definition, which to me would be inconsistent with how the the SNMP > specification employs max-bindings. Actually, I'm just trying to resolve an issue being experienced by users of net-snmp, which reports an error on that element. Changed as I did, it parses fine. Maybe it's their problem, maybe not. ASN.1 is not a plainly written spec. More info by Googling "Bad operator (INTEGER): At line 73 in /usr/share/mibs/ietf/SNMPv2-PDU" -- Mike --------------090802010501010208000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And here is the answer to the rejected errata.
Any follow up?

Regards, Benoit

-------- Original Message --------
Subject: Re: [Errata Rejected] RFC3416 (3402)
Date: Fri, 09 Nov 2012 13:11:54 -0500
From: Mike Sauve <msauve@alientech.net>
To: RFC Errata System <rfc-editor@rfc-editor.org>
CC: bclaise@cisco.com, iesg@ietf.org 


On 11/9/2012 11:39 AM, RFC Errata System wrote:

>   --VERIFIER NOTES--
> According to section 4.2 of the ASN.1 spec, the grammar for the value notation is
>
>    ValueDefinition ::= identifier Type "::=" Value

> The current text conforms to this grammar, and the usage in this particular case
> is closely analogous to the example the ASN.1 standard gives in that same
> section.

Refer to ASN.1 spec (ITU-T X.680, 11/2008), found at 
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.680-200811-I!!PDF-E

There is no section 4.2. The term "ValueDefinition" is not found.

> It looks like the submitter wants to change the value definition into a
> type definition, which to me would be inconsistent with how the the SNMP
> specification employs max-bindings.

Actually, I'm just trying to resolve an issue being experienced by users 
of net-snmp, which reports an error on that element. Changed as I did, 
it parses fine. Maybe it's their problem, maybe not. ASN.1 is not a 
plainly written spec. More info by Googling "Bad operator (INTEGER): At 
line 73 in /usr/share/mibs/ietf/SNMPv2-PDU"




-- 
Mike



--------------090802010501010208000709-- From bclaise@cisco.com Sun Nov 11 10:53:58 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7BE21F8564; Sun, 11 Nov 2012 10:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFOUOSrE0NC8; Sun, 11 Nov 2012 10:53:57 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id E00A721F856E; Sun, 11 Nov 2012 10:53:56 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABIru5l003921; Sun, 11 Nov 2012 13:53:56 -0500 (EST) Received: from [10.82.242.230] (rtp-vpn2-742.cisco.com [10.82.242.230]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABIrsnG008720; Sun, 11 Nov 2012 13:53:55 -0500 (EST) Message-ID: <509FCBB0.7090002@cisco.com> Date: Sun, 11 Nov 2012 11:00:48 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121108231217.12473.66688.idtracker@ietfa.amsl.com> In-Reply-To: <20121108231217.12473.66688.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121108231217.12473.66688.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-11-15 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 18:53:58 -0000 Dear all, Please find below the agenda of the November 15th IESG telechat. Please send your questions, comments and concerns before Nov 14 COB. Thanks and Regards, Benoit ================================================ INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2012-11-15 IESG Teleconference This agenda was generated at 2012-11-08 15:10:41 PST Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-v6ops-ra-guard-implementation-05 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) (Best Current Practice) Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-xrblock-rtcp-xr-delay-10 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay metric Reporting (Proposed Standard) Note: Shida Schubert (shida@ntt-at.com) is the Document Shepherd. Token: Gonzalo Camarillo o draft-ietf-mpls-mldp-in-band-signaling-07 Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths (Proposed Standard) Note: Loa Andersson (loa@pi.nu) is the document shepherd. Token: Adrian Farrel o draft-ietf-mpls-ipv6-pw-lsp-ping-03 Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs (Proposed Standard) Note: Loa Andersson (loa.andersson@ericsson.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-ipfix-a9n-07 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol (Proposed Standard) Note: Nevil Brownlee (n.brownlee@auckland.ac.nz) is the document shepherd. Token: Ronald Bonica 2.1.2 Returning Items o draft-ietf-dnsext-rfc2671bis-edns0-09 Extension Mechanisms for DNS (EDNS(0)) (Internet Standard) Note: Olafur Gudmundsson (ogud at ogud.com) is the document shepherd. Token: Ralph Droms o draft-ietf-pkix-caa-15 DNS Certification Authority Authorization (CAA) Resource Record (Proposed Standard) Note: Steve Kent (kent@bbn.com) is the Document Shepherd. Token: Sean Turner 2.2 Individual Submissions 2.2.1 New Items o draft-leiba-5322upd-from-group-07 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields (Proposed Standard) Token: Pete Resnick o draft-gont-intarea-obsolete-eid-option-01 Obsoleting the Endpoint Identifier (EID) Option (Proposed Standard) Note: Christopher LILJENSTOLPE (liljenstolpe@gmail.com) is the document shepherd. Token: Ronald Bonica 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-bmwg-protection-meth-12 Methodology for Benchmarking MPLS-TE Fast Reroute Protection (Informational) Note: Al Morton (acmorton@att.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-mptcp-api-06 MPTCP Application Interface Considerations (Informational) Token: Wesley Eddy o draft-ietf-karp-ospf-analysis-05 Analysis of OSPF Security According to KARP Design Guide (Informational) Note: Brian Weis is the document shepherd. Token: Stewart Bryant 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-leiba-extended-doc-shepherd-01 Document Shepherding Throughout a Document's Lifecycle (Informational) Token: Russ Housley 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o conflict-review-secure-cookie-session-protocol-00 IETF conflict review for draft-secure-cookie-session-protocol draft-secure-cookie-session-protocol-08 SCS: Secure Cookie Sessions for HTTP (ISE: Informational) Token: Barry Leiba 3.3.2 Returning Items NONE 3.3.3 For Action o conflict-review-boucadair-mmusic-altc-00 IETF conflict review for draft-boucadair-mmusic-altc draft-boucadair-mmusic-altc-06 Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute (ISE: Informational) Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From j.schoenwaelder@jacobs-university.de Sun Nov 11 11:01:10 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FE621F84B7 for ; Sun, 11 Nov 2012 11:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLjlLuVl3+XI for ; Sun, 11 Nov 2012 11:01:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C236021F84BF for ; Sun, 11 Nov 2012 11:01:04 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B846B20BED; Sun, 11 Nov 2012 20:01:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M6XpskUSPH5m; Sun, 11 Nov 2012 20:01:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45F0B20BEC; Sun, 11 Nov 2012 20:01:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DE7D822C9A96; Sun, 11 Nov 2012 20:01:06 +0100 (CET) Date: Sun, 11 Nov 2012 20:01:06 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20121111190106.GA90581@elstar.local> Mail-Followup-To: Benoit Claise , "MIB Doctors (E-mail)" References: <509D476A.1090500@alientech.net> <509FCAA0.4040403@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <509FCAA0.4040403@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Fwd: Re: [Errata Rejected] RFC3416 (3402) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 19:01:10 -0000 Benoit, this version of ASN.1 does not apply to SMIv2 since it is newer. That said, the value assignment syntax did not change. You can find it in section 16.2 of this never ASN.1 specification ValueAssignment ::= valuereference Type "::=" Value If NET-SNMP does not get this right, then its a bug in their parser code not a bug in the specification. /js On Sun, Nov 11, 2012 at 10:56:16AM -0500, Benoit Claise wrote: > And here is the answer to the rejected errata. > Any follow up? > > Regards, Benoit > > -------- Original Message -------- > Subject: Re: [Errata Rejected] RFC3416 (3402) > Date: Fri, 09 Nov 2012 13:11:54 -0500 > From: Mike Sauve > To: RFC Errata System > CC: bclaise@cisco.com, iesg@ietf.org > > > > On 11/9/2012 11:39 AM, RFC Errata System wrote: > > > --VERIFIER NOTES-- > >According to section 4.2 of the ASN.1 spec, the grammar for the value notation is > > > > ValueDefinition ::= identifier Type "::=" Value > > >The current text conforms to this grammar, and the usage in this particular case > >is closely analogous to the example the ASN.1 standard gives in that same > >section. > > Refer to ASN.1 spec (ITU-T X.680, 11/2008), found at > http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.680-200811-I!!PDF-E > > There is no section 4.2. The term "ValueDefinition" is not found. > > >It looks like the submitter wants to change the value definition into a > >type definition, which to me would be inconsistent with how the the SNMP > >specification employs max-bindings. > > Actually, I'm just trying to resolve an issue being experienced by users > of net-snmp, which reports an error on that element. Changed as I did, > it parses fine. Maybe it's their problem, maybe not. ASN.1 is not a > plainly written spec. More info by Googling "Bad operator (INTEGER): At > line 73 in /usr/share/mibs/ietf/SNMPv2-PDU" > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Sun Nov 11 11:20:13 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC0921F8508 for ; Sun, 11 Nov 2012 11:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmQmmq1FD6pI for ; Sun, 11 Nov 2012 11:20:12 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id AADCF21F8506 for ; Sun, 11 Nov 2012 11:20:12 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABJK8Yf006242; Sun, 11 Nov 2012 14:20:09 -0500 (EST) Received: from [10.82.242.230] (rtp-vpn2-742.cisco.com [10.82.242.230]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABJK54W023846; Sun, 11 Nov 2012 14:20:06 -0500 (EST) Message-ID: <509FFA65.2060407@cisco.com> Date: Sun, 11 Nov 2012 14:20:05 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <20121101203215.28287.2702.idtracker@ietfa.amsl.com> <5097D5C5.1030400@cisco.com> <509A9444.80108@cisco.com> <509AC151.5000100@bwijnen.net> In-Reply-To: <509AC151.5000100@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] MEF UNIV-EVC MIB review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 19:20:13 -0000 Thanks Bert. Let me follow up Regards, Benoit > So do they have an ascii txt file of the MIB module? > I could only find a PDF file, and that even was through > 2 or 3 levels of indirection from the below email. > > Quickly scanning the PDF file... I bet it will be a time > consuming undertaking. > I see weird things, but I also see use of obsoleted TC > questionable use INTEGER. > > I won't have the needed time to commit to this. > > This page: > http://metroethernetforum.org/liaison_login.htm > startes that it is an "Approved draft 1". So does that mean > it is already final? > > Bert > > On 11/7/12 12:03 PM, Benoit Claise wrote: >> Who would like to volunteer to review the MEF UNI-EVC MIB? >> >> Regards, Benoit >>> Dear all, >>> >>> Who would like to volunteer to review the MEF UNI-EVC MIB? >>> See Ethernet Services MIB Status >>> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx >>> >>> >>> Regards, Benoit >>> >>> >>> -------- Original Message -------- >>> Subject: New Liaison Statement, "Ethernet Services MIB Status" >>> Date: Thu, 01 Nov 2012 13:32:15 -0700 >>> From: Liaison Statement Management Tool >>> To: Ronald Bonica , Benoit Claise >>> >>> CC: The IETF Chair , Nan Chen >>> , Bill Bjorkman >>> , Raghu >>> Ranganathan , >>> >>> >>> >>> Title: Ethernet Services MIB Status >>> Submission Date: 2012-10-29 >>> URL of the IETF Web page:http://datatracker.ietf.org/liaison/1214/ >>> Please reply by 2013-01-28 >>> From: MEF (Mike Bencheck) >>> To: Operations and Management Area (Ronald >>> Bonica, Benoit Claise) >>> Cc: The IETF Chair,Nan >>> Chen,Bill >>> Bjorkman,Raghu >>> Ranganathan, >>> Reponse Contact: >>> Technical Contact: >>> Purpose: For comment >>> >>> Body: >>> Attachments: >>> >>> Ethernet Services MIB Status >>> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > > From bclaise@cisco.com Sun Nov 11 11:27:40 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E27D21F8510 for ; Sun, 11 Nov 2012 11:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSWe89BVSkDl for ; Sun, 11 Nov 2012 11:27:39 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6F22B21F850A for ; Sun, 11 Nov 2012 11:27:39 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABJRctL006933 for ; Sun, 11 Nov 2012 14:27:38 -0500 (EST) Received: from [10.82.242.230] (rtp-vpn2-742.cisco.com [10.82.242.230]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABJRb7S027991 for ; Sun, 11 Nov 2012 14:27:37 -0500 (EST) Message-ID: <509FFC29.1050907@cisco.com> Date: Sun, 11 Nov 2012 14:27:37 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <20121101203215.28287.2702.idtracker@ietfa.amsl.com> <5097D5C5.1030400@cisco.com> <509A9444.80108@cisco.com> In-Reply-To: <509A9444.80108@cisco.com> Content-Type: multipart/alternative; boundary="------------050005040805020804020108" Subject: Re: [MIB-DOCTORS] MEF UNIV-EVC MIB review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 19:27:40 -0000 This is a multi-part message in MIME format. --------------050005040805020804020108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Any takers? Note: I requested the .txt file Regards, Benoit > Who would like to volunteer to review the MEF UNI-EVC MIB? > > Regards, Benoit >> Dear all, >> >> Who would like to volunteer to review the MEF UNI-EVC MIB? >> See Ethernet Services MIB Status >> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx >> >> Regards, Benoit >> >> >> -------- Original Message -------- >> Subject: New Liaison Statement, "Ethernet Services MIB Status" >> Date: Thu, 01 Nov 2012 13:32:15 -0700 >> From: Liaison Statement Management Tool >> To: Ronald Bonica , Benoit Claise >> >> CC: The IETF Chair , Nan Chen >> , Bill Bjorkman >> , Raghu Ranganathan , >> >> >> >> >> Title: Ethernet Services MIB Status >> Submission Date: 2012-10-29 >> URL of the IETF Web page:http://datatracker.ietf.org/liaison/1214/ >> Please reply by 2013-01-28 >> From: MEF (Mike Bencheck) >> To: Operations and Management Area (Ronald Bonica, Benoit Claise) >> Cc: The IETF Chair,Nan Chen,Bill Bjorkman,Raghu Ranganathan, >> Reponse Contact: >> Technical Contact: >> Purpose: For comment >> >> Body: >> Attachments: >> >> Ethernet Services MIB Status >> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx >> >> >> >> >> >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors --------------050005040805020804020108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Any takers?
Note: I requested the .txt file

Regards, Benoit
Who would like to volunteer to review the MEF UNI-EVC MIB?

Regards, Benoit
Dear all,

Who would like to volunteer to review the MEF UNI-EVC MIB?
See Ethernet Services MIB Status https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx

Regards, Benoit


-------- Original Message --------
Subject: New Liaison Statement, "Ethernet Services MIB Status"
Date: Thu, 01 Nov 2012 13:32:15 -0700
From: Liaison Statement Management Tool <lsmt@ietf.org>
To: Ronald Bonica <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>
CC: The IETF Chair <chair@ietf.org>, Nan Chen <nan@metroethernetforum.org>, Bill Bjorkman <bill@metroethernetforum.net>, Raghu Ranganathan <rraghu@ciena.com>, <nan@metroethernetforum.org> 


Title: Ethernet Services MIB Status
Submission Date: 2012-10-29
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1214/
Please reply by 2013-01-28
From: MEF (Mike Bencheck <mike.bencheck@verizon.com>)
To: Operations and Management Area (Ronald Bonica <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>)
Cc: The IETF Chair <chair@ietf.org>,Nan Chen <nan@metroethernetforum.org>,Bill Bjorkman <bill@metroethernetforum.net>,Raghu Ranganathan <rraghu@ciena.com>,<nan@metroethernetforum.org>
Reponse Contact: 
Technical Contact: 
Purpose: For comment

Body: 
Attachments:

    Ethernet Services MIB Status
    https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef-ops-ethernet-services-mib-status-attachment-1.docx









_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors




_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors

--------------050005040805020804020108-- From randy_presuhn@mindspring.com Sun Nov 11 20:21:06 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1036F21F8485 for ; Sun, 11 Nov 2012 20:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[AWL=1.996, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-eZOGqdAOm8 for ; Sun, 11 Nov 2012 20:21:05 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3F74121F8482 for ; Sun, 11 Nov 2012 20:21:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=exxnakBhpFn1Qc/ARfGAbBtknkQMxHuggjL7Y8B7HbT1GrW9R74eOfYzGVTk5B0m; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.226.220] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TXlWC-0000Lh-6J; Sun, 11 Nov 2012 23:21:04 -0500 Message-ID: <004301cdc08d$2675f9c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Benoit Claise" , "MIB Doctors \(E-mail\)" References: <509D476A.1090500@alientech.net> <509FCAA0.4040403@cisco.com> Date: Sun, 11 Nov 2012 20:21:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97ec723d7a86e3ace25e92bc1d96073426c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.220 Subject: Re: [MIB-DOCTORS] Fwd: Re: [Errata Rejected] RFC3416 (3402) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 04:21:06 -0000 Hi - > From: "Benoit Claise" > To: "MIB Doctors (E-mail)" > Sent: Sunday, November 11, 2012 7:56 AM > Subject: [MIB-DOCTORS] Fwd: Re: [Errata Rejected] RFC3416 (3402) > > And here is the answer to the rejected errata. > Any follow up? > > Regards, Benoit > > -------- Original Message -------- > Subject: Re: [Errata Rejected] RFC3416 (3402) > Date: Fri, 09 Nov 2012 13:11:54 -0500 > From: Mike Sauve > To: RFC Errata System > CC: bclaise@cisco.com, iesg@ietf.org > > > > On 11/9/2012 11:39 AM, RFC Errata System wrote: > > > --VERIFIER NOTES-- > > According to section 4.2 of the ASN.1 spec, the grammar for the value notation is > > > > ValueDefinition ::= identifier Type "::=" Value > > > The current text conforms to this grammar, and the usage in this particular case > > is closely analogous to the example the ASN.1 standard gives in that same > > section. > > Refer to ASN.1 spec (ITU-T X.680, 11/2008), found at > http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.680-200811-I!!PDF-E > > There is no section 4.2. The term "ValueDefinition" is not found. Note well that SNMP uses the 1987 version of the ASN.1 spec. In researching my comment, I used the closest thing at hand, CCITT X.409 from CCITT Red Book (1984) Volume VIII Fascicle VIII.7, which is *very* close to the ISO 8824-1987 used by the SNMP specification. The X.680-2008 is a radically different document, even though they purport to describe very similar things. (But not the same. Ask anyone who suffered through the pain and anguish in ISO/IEC JTC1/SC21 when the "new" ASN.1 came out.) > > It looks like the submitter wants to change the value definition into a > > type definition, which to me would be inconsistent with how the the SNMP > > specification employs max-bindings. > > Actually, I'm just trying to resolve an issue being experienced by users > of net-snmp, which reports an error on that element. Changed as I did, > it parses fine. Maybe it's their problem, maybe not. ASN.1 is not a > plainly written spec. More info by Googling "Bad operator (INTEGER): At > line 73 in /usr/share/mibs/ietf/SNMPv2-PDU" Sounds like a parser bug to me. The parsers used when this was written didn't have any trouble with it, and it hand-checks against the grammar. Randy From bclaise@cisco.com Mon Nov 12 08:19:44 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758A321F8635 for ; Mon, 12 Nov 2012 08:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.195 X-Spam-Level: X-Spam-Status: No, score=-8.195 tagged_above=-999 required=5 tests=[AWL=-2.404, BAYES_40=-0.185, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuxp8KgOAVTR for ; Mon, 12 Nov 2012 08:19:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E1B6E21F862B for ; Mon, 12 Nov 2012 08:19:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACGJaa6012532 for ; Mon, 12 Nov 2012 17:19:36 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACGJZZ7022656 for ; Mon, 12 Nov 2012 17:19:35 +0100 (CET) Message-ID: <50A12197.6080505@cisco.com> Date: Mon, 12 Nov 2012 17:19:35 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <3C4966DA52505D4DB66B360647B8A89A15A3E1756E@FHDP1LUMXC7V43.us.one.verizon.com> In-Reply-To: <3C4966DA52505D4DB66B360647B8A89A15A3E1756E@FHDP1LUMXC7V43.us.one.verizon.com> X-Forwarded-Message-Id: <3C4966DA52505D4DB66B360647B8A89A15A3E1756E@FHDP1LUMXC7V43.us.one.verizon.com> Content-Type: multipart/mixed; boundary="------------000901050906090307080301" Subject: [MIB-DOCTORS] Fwd: RE: New Liaison Statement, "Ethernet Services MIB Status" X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:19:44 -0000 This is a multi-part message in MIME format. --------------000901050906090307080301 Content-Type: multipart/alternative; boundary="------------010407030607040306090305" --------------010407030607040306090305 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Here is the .txt version. And I received the answer regarding the "Approved Dratf": In MEF Approved Draft means that the draft document has reached a point in development where we can share it with liaison partners. Still looking for a volunteer for this one Regards, Benoit -------- Original Message -------- Subject: RE: New Liaison Statement, "Ethernet Services MIB Status" Date: Mon, 12 Nov 2012 10:57:48 -0500 From: Bencheck, Michael U To: Benoit Claise Attached is the .txt version of the MIB. Thanks, Mike -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Sunday, November 11, 2012 1:27 PM To: Benoit Claise Cc: Bencheck, Michael U; Ronald Bonica; The IETF Chair; Nan Chen; Bill Bjorkman; Raghu Ranganathan; me Subject: Re: New Liaison Statement, "Ethernet Services MIB Status" Dear Mike, The link mentions "Approved draft 1 of the MEF UNI-EVC MIB". Does it mean that it's approved already? One of our experts already found a couple of issues. However, we would really need a .txt file (as opposed to PDF), so that we could use the MIB compilation tools. Regards, Benoit > Dear Mike, > > Thank you for liaison statement. > I have asked the MIB doctors to review the UNIV-EVC MIB. > We will get to you shortly with the feedback. > > Regards, Benoit (Operations and Management Area Director) >> Title: Ethernet Services MIB Status >> Submission Date: 2012-10-29 >> URL of the IETF Web page: http://datatracker.ietf.org/liaison/1214/ >> Please reply by 2013-01-28 >> From: MEF (Mike Bencheck ) >> To: Operations and Management Area (Ronald Bonica >> , Benoit Claise ) >> Cc: The IETF Chair ,Nan Chen >> ,Bill Bjorkman >> ,Raghu Ranganathan >> , >> Reponse Contact: >> Technical Contact: >> Purpose: For comment >> >> Body: >> Attachments: >> >> Ethernet Services MIB Status >> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef >> -ops-ethernet-services-mib-status-attachment-1.docx >> >> >> > --------------010407030607040306090305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Here is the .txt version.
And I received the answer regarding the "Approved Dratf": In MEF Approved Draft means that the draft document has reached a point in development where we can share it with liaison partners.

Still looking for a volunteer for this one

Regards, Benoit


-------- Original Message --------
Subject: RE: New Liaison Statement, "Ethernet Services MIB Status"
Date: Mon, 12 Nov 2012 10:57:48 -0500
From: Bencheck, Michael U <mike.bencheck@verizon.com>
To: Benoit Claise <bclaise@cisco.com> 


Attached is the .txt version of the MIB.  

Thanks,
 
Mike

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Sunday, November 11, 2012 1:27 PM
To: Benoit Claise
Cc: Bencheck, Michael U; Ronald Bonica; The IETF Chair; Nan Chen; Bill Bjorkman; Raghu Ranganathan; me
Subject: Re: New Liaison Statement, "Ethernet Services MIB Status"

Dear Mike,

The link mentions "Approved draft 1 of the MEF UNI-EVC MIB". Does it mean that it's approved already?
One of our experts already found a couple of issues. However, we would really need a .txt file (as opposed to PDF), so that we could use the MIB compilation tools.

Regards, Benoit

> Dear Mike,
>
> Thank you for liaison statement.
> I have asked the MIB doctors to review the UNIV-EVC MIB.
> We will get to you shortly with the feedback.
>
> Regards, Benoit (Operations and Management Area Director)
>> Title: Ethernet Services MIB Status
>> Submission Date: 2012-10-29
>> URL of the IETF Web page: http://datatracker.ietf.org/liaison/1214/
>> Please reply by 2013-01-28
>> From: MEF (Mike Bencheck <mike.bencheck@verizon.com>)
>> To: Operations and Management Area (Ronald Bonica 
>> <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>)
>> Cc: The IETF Chair <chair@ietf.org>,Nan Chen 
>> <nan@metroethernetforum.org>,Bill Bjorkman 
>> <bill@metroethernetforum.net>,Raghu Ranganathan 
>> <rraghu@ciena.com>,<nan@metroethernetforum.org>
>> Reponse Contact:
>> Technical Contact:
>> Purpose: For comment
>>
>> Body:
>> Attachments:
>>
>>      Ethernet Services MIB Status
>> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-10-29-mef
>> -ops-ethernet-services-mib-status-attachment-1.docx
>>
>>
>>
>



--------------010407030607040306090305-- --------------000901050906090307080301 Content-Type: text/plain; charset=windows-1252; name="MEF-UNI-EVC-MIB.txt.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="MEF-UNI-EVC-MIB.txt.txt" TUVGLVVOSS1FVkMtTUlCIERFRklOSVRJT05TIDo6PSBCRUdJTg0KICBJTVBPUlRTDQogICAg Tk9USUZJQ0FUSU9OLVRZUEUsIE1PRFVMRS1JREVOVElUWSwgT0JKRUNULVRZUEUsIFVuc2ln bmVkMzIsIGVudGVycHJpc2VzLA0KICAgIENvdW50ZXIzMiwgQ291bnRlcjY0DQogICAgICAg ICAgICAgRlJPTSBTTk1QdjItU01JICAgICAgICAgICAgLS0gUkZDIDI1NzgNCiAgICBSb3dT dGF0dXMsIE1hY0FkZHJlc3MsIERhdGVBbmRUaW1lLCBURVhUVUFMLUNPTlZFTlRJT04sIERp c3BsYXlTdHJpbmcNCiAgICAgICAgICAgICBGUk9NIFNOTVB2Mi1UQyAgICAgICAgICAgICAt LSBSRkMgMjU3OQ0KICAgIE9CSkVDVC1HUk9VUCwgTk9USUZJQ0FUSU9OLUdST1VQLCBNT0RV TEUtQ09NUExJQU5DRQ0KICAgICAgICAgICAgIEZST00gU05NUHYyLUNPTkYgICAgICAgICAg IC0tIFJGQyAyNTgwDQogICAgaWZJbmRleA0KICAgICAgICAgICAgIEZST00gSUYtTUlCICAg ICAgICAgICAgICAgIC0tIFtSRkMyODYzXQ0KICAgIEVudGl0eUFkbWluU3RhdGUsIEVudGl0 eU9wZXJTdGF0ZQ0KICAgICAgICAgICAgIEZST00gRU5USVRZLVNUQVRFLVRDLU1JQiAgIC0t IFJGQyA0MjY4DQogICAgVmxhbklkICAgICANCiAgICAgICAgICAgICBGUk9NIFEtQlJJREdF LU1JQiAgICAgICAgICAtLSBbUkZDNDM2M10NCiAgICBJRUVFODAyMVByaW9yaXR5VmFsdWUN CiAgICAgICAgICAgICBGUk9NIElFRUU4MDIxLVRDLU1JQiAgICAgICAtLSBJRUVFIDgwMi4x YXANCiAgICBJQU5BaWZNYXVUeXBlTGlzdEJpdHMNCiAgICAgICAgICAgICBGUk9NIElBTkEt TUFVLU1JQjsgICAgICAgICAtLSBJQU5BIE1BVSBkZWZpbml0aW9uDQoNCm1lZlVuaUV2Y01p YiBNT0RVTEUtSURFTlRJVFkNCiAgICBMQVNULVVQREFURUQgICAgIjIwMTIxMDEyMTgwMFoi IC0tIE9jdG9iZXIgMTgsIDIwMTINCiAgICBPUkdBTklaQVRJT04gICAgIk1ldHJvIEV0aGVy bmV0IEZvcnVtIg0KICAgIENPTlRBQ1QtSU5GTw0KICAgICAgICJXZWIgVVJMOiBodHRwOi8v bWV0cm9ldGhlcm5ldGZvcnVtLm9yZy8NCiAgICAgICAgRS1tYWlsOiAgbWlic0BtZXRyb2V0 aGVybmV0Zm9ydW0ub3JnDQogICAgICAgIFBvc3RhbDogIE1ldHJvIEV0aGVybmV0IEZvcnVt DQogICAgICAgICAgICAgICAgIDYwMzMgVy4gQ2VudHVyeSBCb3VsZXZhcmQsIFN1aXRlIDgz MA0KICAgICAgICAgICAgICAgICBMb3MgQW5nZWxlcywgQ0EgOTAwNDUNCiAgICAgICAgICAg ICAgICAgVS5TLkEuDQogICAgICAgIFBob25lOiAgICsxIDMxMC02NDItMjgwMA0KICAgICAg ICBGYXg6ICAgICArMSAzMTAtNjQyLTI4MDgiDQogICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICJUaGlzIE1JQiBtb2R1bGUgY29udGFpbnMgdGhlIG1hbmFnZW1lbnQgb2JqZWN0cyBm b3IgdGhlDQogICAgICAgICAgICBtYW5hZ2VtZW50IG9mIFVzZXIgTmV0d29yayBJbnRlcmZh Y2VzIChVTklzKSBhbmQgRXRoZXJuZXQNCiAgICAgICAgICAgIFZpcnR1YWwgQ29ubmVjdGlv bnMgKEVWQ3MpDQoNCiAgICAgICAgICAgIENvcHlyaWdodCAyMDEyIE1ldHJvIEV0aGVybmV0 IEZvcnVtDQogICAgICAgICAgICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICAgKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KICAgIFJlZmVyZW5jZSBPdmVydmlldw0KDQogICAgQSBudW1i ZXIgb2YgYmFzZSBkb2N1bWVudHMgaGF2ZSBiZWVuIHVzZWQgdG8gY3JlYXRlIHRoaXMgTUlC LiBUaGUgZm9sbG93aW5nDQogICAgYXJlIHRoZSBhYmJyZXZpYXRpb25zIGZvciB0aGUgYmFz ZWxpbmUgZG9jdW1lbnRzOg0KDQogICAgW01FRjYuMV0gcmVmZXJzIHRvIE1FRiA2LjEgJ0V0 aGVybmV0IFNlcnZpY2VzIERlZmluaXRpb25zIC0gUGhhc2UgMicsDQogICAgICAgIEFwcmls IDIwMDgNCiAgICBbTUVGIDYuMS4xXSByZWZlcnMgdG8gTUVGIDYuMS4xICdMYXllciAyIENv bnRyb2wgUHJvdG9jb2wgSGFuZGxpbmcgQW1lbmRtZW50DQogICAgICAgdG8gTUVGIDYuMScs IEphbnVhcnkgMjAxMg0KICAgIFtNRUYgNy4yXSByZWZlcnMgdG8gTUVGIDcuMiAnQ2Fycmll ciBFdGhlcm5ldCBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIE1vZGVsJywNCiAgICAgICAgQXBy aWwgMjAxMg0KICAgIFtNRUYgMTAuMl0gcmVmZXJzIHRvIE1FRiAxMC4yICdFdGhlcm5ldCBT ZXJ2aWNlcyBBdHRyaWJ1dGVzIFBoYXNlIDInLA0KICAgICAgICBPY3RvYmVyIDIwMDkNCiAg ICBbTUVGIDI2LjFdIHJlZmVyZXMgdG8gTUVGIDI2LjEgJyAnLCBKYW51YXJ5IDIwMTINCiAg ICBbUS44NDAuMV0gcmVmZXJzIHRvICdJVFUtVCBSZXF1aXJlbWVudHMgYW5kIGFuYWx5c2lz IGZvciBOTVMtRU1TDQogICAgICAgIG1hbmFnZW1lbnQgaW50ZXJmYWNlIG9mIEV0aGVybmV0 IG92ZXIgVHJhbnNwb3J0IGFuZCBNZXRybyBFdGhlcm5ldA0KICAgICAgICBOZXR3b3JrIChF b1QvTUVOKScsIE1hcmNoIDIwMDcNCiAgICBbWS4xNzMxXSByZWZlcnMgdG8gSVRVLVQgWS4x NzMxICdPQU0gZnVuY3Rpb25zIGFuZCBtZWNoYW5pc21zIGZvciBFdGhlcm5ldA0KICAgICAg ICBiYXNlZCBuZXR3b3JrcycsIEZlYnJ1YXJ5IDIwMTENCiAgICAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQogICAgICAgICAgICINCiAgICBSRVZJU0lPTiAgICAgICAgIjIwMTIxMDE4MTIw MFoiIC0tIE9jdG9iZXIgMTgsIDIwMTINCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAg IkluaXRpYWwgVmVyc2lvbi4iDQogICAgOjo9IHsgZW50ZXJwcmlzZXMgbWVmKDE1MDA3KSBt ZWZTZXJ2aWNlKDIpIDIgfQ0KDQoNCi0tICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQotLSBP YmplY3QgZGVmaW5pdGlvbnMgaW4gdGhlIFNlcnZpY2UgTUlCIE1vZHVsZQ0KLS0gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCm1lZlNlcnZpY2VOb3RpZmljYXRpb25zICAgICAgT0JKRUNU IElERU5USUZJRVIgOjo9IHsgbWVmVW5pRXZjTWliIDAgfQ0KbWVmU2VydmljZU9iamVjdHMg ICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBtZWZVbmlFdmNNaWIgMSB9DQpt ZWZTZXJ2aWNlTWliQ29uZm9ybWFuY2UgICAgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IG1l ZlVuaUV2Y01pYiAyIH0NCg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCi0tIEdyb3Vw cyBpbiB0aGUgU2VydmljZSBNSUIgTW9kdWxlDQotLSAqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KbWVmU2VydmljZUludGVyZmFjZSAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0g eyBtZWZTZXJ2aWNlT2JqZWN0cyAxIH0NCm1lZlNlcnZpY2VVbmlBdHRyaWJ1dGVzICAgICAg T0JKRUNUIElERU5USUZJRVIgOjo9IHsgbWVmU2VydmljZU9iamVjdHMgMiB9DQptZWZTZXJ2 aWNlRXZjQXR0cmlidXRlcyAgICAgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IG1lZlNlcnZp Y2VPYmplY3RzIDMgfQ0KDQptZWZTZXJ2aWNlQndwQXR0cmlidXRlcyAgICAgIE9CSkVDVCBJ REVOVElGSUVSIDo6PSB7IG1lZlNlcnZpY2VPYmplY3RzIDQgfQ0KbWVmU2VydmljZUNvc0F0 dHJpYnV0ZXMgICAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBtZWZTZXJ2aWNlT2JqZWN0 cyA1IH0NCm1lZlNlcnZpY2VMMmNwQXR0cmlidXRlcyAgICAgT0JKRUNUIElERU5USUZJRVIg Ojo9IHsgbWVmU2VydmljZU9iamVjdHMgNiB9DQptZWZTZXJ2aWNlUGVyZkF0dHJpYnV0ZXMg ICAgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IG1lZlNlcnZpY2VPYmplY3RzIDcgfQ0KbWVm U2VydmljZU5vdGlmaWNhdGlvbkNmZyAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBtZWZT ZXJ2aWNlT2JqZWN0cyA4IH0NCm1lZlNlcnZpY2VOb3RpZmljYXRpb25PYmogICAgT0JKRUNU IElERU5USUZJRVIgOjo9IHsgbWVmU2VydmljZU9iamVjdHMgOSB9DQoNCg0KLS0gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCi0tIEV0aGVybmV0IFNlcnZpY2UgVGV4dHVhbCBDb252ZW50 aW9ucw0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KTWVmU2VydmljZUludGVyZmFj ZVR5cGUgOjo9IFRFWFRVQUwtQ09OVkVOVElPTg0KICAgIFNUQVRVUyBjdXJyZW50DQogICAg REVTQ1JJUFRJT04NCiAgICAgICAiQSBNRUYgSW50ZXJmYWNlIGNhbiBiZSBvbmUgb2Ygc2V2 ZXJhbCB0eXBlczoNCg0KICAgICAgICAgYlVuaTFkMSgwKSAgICBVTkkgVHlwZSAxLjENCiAg ICAgICAgIGJVbmkxZDIoMSkgICAgVU5JIFR5cGUgMS4yDQogICAgICAgICBiVW5pMmQxKDIp ICAgIFVOSSBUeXBlIDIuMQ0KICAgICAgICAgYlVuaTJkMigzKSAgICBVTkkgVHlwZSAyLjIN CiAgICAgICAgIGJFbm5pKDQpICAgICAgRU5OSQ0KICAgICAgICAgYkVubmlWdW5pKDUpICBW VU5JIG9uIGFuIEVOTkkNCiAgICAgICAiIA0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVG IDYuMV0gNi4wIg0KICAgIFNZTlRBWCAgICAgIEJJVFMgew0KICAgICAgICAgICAgICAgICAg ICAgYlVuaTFkMSgwKSwNCiAgICAgICAgICAgICAgICAgICAgIGJVbmkxZDIoMSksDQogICAg ICAgICAgICAgICAgICAgICBiVW5pMmQxKDIpLA0KICAgICAgICAgICAgICAgICAgICAgYlVu aTJkMigzKSwNCiAgICAgICAgICAgICAgICAgICAgIGJFbm5pKDQpLA0KICAgICAgICAgICAg ICAgICAgICAgYkVubmlWdW5pKDUpDQogICAgICAgICAgICAgICAgfQ0KDQpNZWZTZXJ2aWNl TGlzdFR5cGUgOjo9IFRFWFRVQUwtQ09OVkVOVElPTg0KICAgICAgIERJU1BMQVktSElOVCAi MjU1dCINCiAgICAgICBTVEFUVVMgICAgICAgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICJBbiBvY3RldCBzdHJpbmcgY29udGFpbmluZyBhIGxpc3Qgb2YgdGFn IHZhbHVlcy4NCg0KICAgICAgICAgICAgQSB0YWcgdmFsdWUgaXMgYW4gYXJiaXRyYXJ5IHN0 cmluZyBvZiBvY3RldHMgZnJvbQ0KICAgICAgICAgICAgQVNDSUkgY2hhcmFjdGVyIDB4MjEg LSAweEZFLCBidXQgbWF5IG5vdCBjb250YWluIA0KICAgICAgICAgICAgYSBkZWxpbWl0ZXIg Y2hhcmFjdGVyLiBEZWxpbWl0ZXIgY2hhcmFjdGVycyBhcmUgDQogICAgICAgICAgICBkZWZp bmVkIHRvIGJlIG9uZSBvZiB0aGUgZm9sbG93aW5nOg0KDQogICAgICAgICAgICAgICAgLSAg QW4gQVNDSUkgc3BhY2UgY2hhcmFjdGVyICgweDIwKQ0KICAgICAgICAgICAgICAgIC0gIEFu IEFTQ0lJIGNvbW1hIGNoYXJhY3RlciAoMHgyQykNCiAgICAgICAgICAgICAgICAtICBBbiBB U0NJSSBjb2xvbiBjaGFyYWN0ZXIgKDB4M0EpDQogICAgICAgICAgICAgICAgLSAgQW4gQVND SUkgZm9yd2FyZCBzbGFzaCAoMHgyRikNCg0KICAgICAgICAgICAgRGVsaW1pdGVyIGNoYXJh Y3RlcnMgYXJlIHVzZWQgdG8gc2VwYXJhdGUgdGFnIHZhbHVlcw0KICAgICAgICAgICAgaW4g YSB0YWcgbGlzdC4gIE9ubHkgYSBzaW5nbGUgZGVsaW1pdGVyIGNoYXJhY3RlciBtYXkNCiAg ICAgICAgICAgIG9jY3VyIGJldHdlZW4gdHdvIHRhZyB2YWx1ZXMuICBBIHRhZyB2YWx1ZSBt YXkgbm90DQogICAgICAgICAgICBoYXZlIGEgemVybyBsZW5ndGguICBUaGVzZSBjb25zdHJh aW50cyBpbXBseSBjZXJ0YWluDQogICAgICAgICAgICByZXN0cmljdGlvbnMgb24gdGhlIGNv bnRlbnRzIG9mIHRoaXMgb2JqZWN0Og0KDQogICAgICAgICAgICAgICAgLSBUaGVyZSBjYW5u b3QgYmUgYSBsZWFkaW5nIG9yIHRyYWlsaW5nIGRlbGltaXRlcg0KICAgICAgICAgICAgICAg ICAgY2hhcmFjdGVyLg0KDQogICAgICAgICAgICAgICAgLSBUaGVyZSBjYW5ub3QgYmUgbXVs dGlwbGUgYWRqYWNlbnQgZGVsaW1pdGVyDQogICAgICAgICAgICAgICAgICBjaGFyYWN0ZXJz Lg0KDQogICAgICAgICAgICBTb21lIGV4YW1wbGVzIG9mIHZhbGlkIHRhZyBsaXN0cyBhcmU6 DQoNCiAgICAgICAgICAgICAgICAtICcnICAgICAgICAgICAgLS0gYW4gZW1wdHkgbGlzdA0K ICAgICAgICAgICAgICAgIC0gJzEyMzQnICAgICAgICAtLSBsaXN0IG9mIG9uZSB0YWcNCiAg ICAgICAgICAgICAgICAtICcxMCwxMSwxMicgICAgLS0gbGlzdCBvZiBzZXZlcmFsIHRhZ3MN CiAgICAgICAgICAgICAgICAtICcxMDoyMCcgICAgICAgLS0gYSBsaXN0IGNvbnRhaW5pbmcg YWxsIHRoZSB2YWxpZCB2YWx1ZXMgZnJvbQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxMCB0aHJvdWdoIDIwDQoNCiAgICAgICAgICAgIE5vdGUgdGhhdCBhbHRob3Vn aCBhIHRhZyB2YWx1ZSBtYXkgbm90IGhhdmUgYSBsZW5ndGggb2YNCiAgICAgICAgICAgIHpl cm8sIGFuIGVtcHR5IHN0cmluZyBpcyBzdGlsbCB2YWxpZC4gIFRoaXMgaW5kaWNhdGVzDQog ICAgICAgICAgICBhbiBlbXB0eSBsaXN0IChpLmUuIHRoZXJlIGFyZSBubyB0YWcgdmFsdWVz IGluIHRoZSBsaXN0KS4NCg0KICAgICAgICAgICAgVGhlIHVzZSBvZiB0aGUgdGFnIGxpc3Qg dG8gc2VsZWN0IHRhYmxlIGVudHJpZXMgaXMNCiAgICAgICAgICAgIGFwcGxpY2F0aW9uIGFu ZCBNSUIgc3BlY2lmaWMuICBUeXBpY2FsbHksIGFuIGFwcGxpY2F0aW9uDQogICAgICAgICAg ICB3aWxsIHByb3ZpZGUgb25lIG9yIG1vcmUgdGFnIHZhbHVlcywgYW5kIGFueSBlbnRyeQ0K ICAgICAgICAgICAgd2hpY2ggY29udGFpbnMgc29tZSBjb21iaW5hdGlvbiBvZiB0aGVzZSB0 YWcgdmFsdWVzDQogICAgICAgICAgICB3aWxsIGJlIHNlbGVjdGVkLg0KICAgICAgICAgICAi DQogICAgICAgU1lOVEFYICAgICAgIE9DVEVUIFNUUklORyAoU0laRSAoMC4uMjU1KSkNCg0K DQotLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KLS0gRXRoZXJuZXQgU2VydmljZSBJbnRl cmZhY2UgQ29uZmlndXJhdGlvbg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KbWVm U2VydmljZUludGVyZmFjZUNmZ1RhYmxlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAg U0VRVUVOQ0UgT0YgTWVmU2VydmljZUludGVyZmFjZUNmZ0VudHJ5DQogICAgTUFYLUFDQ0VT UyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJ UFRJT04NCiAgICAgICAiVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBsb2NhbCBpbnRlcmZh Y2UgY29uZmlndXJhdGlvbiB0YWJsZSBmb3IgYW4NCiAgICAgICAgTUVGIEV0aGVybmV0IGNv bXBsaWFudCBOZXR3b3JrIEVsZW1lbnQgKE5FKS4gVGhlIHByaW1hcnkgcHVycG9zZSBvZiAN CiAgICAgICAgdGhpcyB0YWJsZSBpcyB0byBwcm92aWRlIGNvbmZpZ3VyYXRpb24gb2YgdGhl IGludGVyZmFjZSBmb3IgYSBNRUYgTkUuIA0KICAgICAgICBSb3dzIGFyZSBhdXRvbWF0aWNh bGx5IGNyZWF0ZWQgaW4gdGhlIHRhYmxlIGJhc2VkIHVwb24gdGhlIGludGVyZmFjZXMgDQog ICAgICAgIHRoYXQgYSBNRUYgTkUgY29udGFpbnMuIEEgcm93IGlzIGFjY2Vzc2VkIGJ5IHRo ZSBJRi1NSUIgaW50ZXJmYWNlIA0KICAgICAgICBvYmplY3QgaWZJbmRleC4NCiAgICAgICAi DQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSwgW01FRiA3LjJdLCBbTUVGIDEw LjJdLCBbUS44NDAuMV0iDQogICAgOjo9IHsgbWVmU2VydmljZUludGVyZmFjZSAxIH0NCg0K bWVmU2VydmljZUludGVyZmFjZUNmZ0VudHJ5IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAg ICAgTWVmU2VydmljZUludGVyZmFjZUNmZ0VudHJ5DQogICAgTUFYLUFDQ0VTUyAgbm90LWFj Y2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAg ICAgICAiVGhlIGNvbmNlcHR1YWwgcm93IG9mIG1lZlNlcnZpY2VJbnRlcmZhY2VDZmdUYWJs ZS4iDQogICAgSU5ERVggeyBpZkluZGV4IH0NCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJm YWNlQ2ZnVGFibGUgMSB9DQoNCk1lZlNlcnZpY2VJbnRlcmZhY2VDZmdFbnRyeSA6Oj0gU0VR VUVOQ0Ugew0KICAgICAgbWVmU2VydmljZUludGVyZmFjZUNmZ1R5cGUgICAgICAgICAgICAg ICAgIE1lZlNlcnZpY2VJbnRlcmZhY2VUeXBlLA0KICAgICAgbWVmU2VydmljZUludGVyZmFj ZUNmZ0lkZW50aWZpZXIgICAgICAgICAgIERpc3BsYXlTdHJpbmcsDQogICAgICBtZWZTZXJ2 aWNlSW50ZXJmYWNlQ2ZnTW9kZSAgICAgICAgICAgICAgICAgSU5URUdFUiwNCiAgICAgIG1l ZlNlcnZpY2VJbnRlcmZhY2VDZmdOZWdvdGlhdGUgICAgICAgICAgICBJTlRFR0VSLA0KICAg ICAgbWVmU2VydmljZUludGVyZmFjZUNmZ0Zsb3dDb250cm9sICAgICAgICAgIElOVEVHRVIs DQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnRnJhbWVGb3JtYXQgICAgICAgICAgSU5U RUdFUiwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VDZmdJbmdyZXNzQndwSW5kZXggICAg ICBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUludGVyZmFjZUNmZ0VncmVzc0J3cElu ZGV4ICAgICAgIFVuc2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnTDJj cEluZGV4ICAgICAgICAgICAgVW5zaWduZWQzMg0KICAgIH0NCg0KbWVmU2VydmljZUludGVy ZmFjZUNmZ1R5cGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBNZWZTZXJ2aWNlSW50 ZXJmYWNlVHlwZQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUNCiAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNh dGVzIHRoZSBjb25maWd1cmVkIGludGVyZmFjZSB0eXBlLiBPbmUNCiAgICAgICAgYml0IGlu IHRoZSB2ZWN0b3IgY2FuIGJlIHNldCBhdCBvbmUgdGltZSBiYXNlZCB1cG9uIHRoZQ0KICAg ICAgICBwb3NzaWJsZSB2YWx1ZXMgaW5kaWNhdGVkIGJ5IG1lZlNlcnZpY2VJbnRlcmZhY2VT dGF0dXNUeXBlLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2LjFd IDYuMDsgW01FRiA3LjJdIDYuMi4xLjEsIDYuMi4xLjIsIDYuMi4xLjMiDQogICAgOjo9IHsg bWVmU2VydmljZUludGVyZmFjZUNmZ0VudHJ5IDEgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNl Q2ZnSWRlbnRpZmllciBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIERpc3BsYXlTdHJp bmcgKFNJWkUoMC4uNDUpKSANCiAgICBNQVgtQUNDRVNTICByZWFkLXdyaXRlDQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0 IGluZGljYXRlcyB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXIgYW5kIGlzIGFuIGFyYml0cmFy eSANCiAgICAgICAgdGV4dCBzdHJpbmcgdGhhdCBpcyB1c2VkIHRvIGlkZW50aWZ5IGFuIGlu dGVyZmFjZS4gVW5pcXVlIHN0cmluZw0KICAgICAgICB2YWx1ZXMgYXJlIGNob3NlbiB0byB1 bmlxdWVseSBpZGVudGlmeSBhbiBpbnRlcmZhY2UuDQoNCiAgICAgICAgT2N0ZXQgdmFsdWVz IG9mIDB4MDAgdGhyb3VnaCAweDFmIGFyZSBpbGxlZ2FsLg0KICAgICAgICINCiAgICBSRUZF UkVOQ0UNCiAgICAgICAiW01FRiA3LjJdIDYuMi4xLjQiDQogICAgOjo9IHsgbWVmU2Vydmlj ZUludGVyZmFjZUNmZ0VudHJ5IDIgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnTW9kZSBP QkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICBmdWxsRHVw bGV4ICAoMSksDQogICAgICAgIGhhbGZEdXBsZXggICgyKQ0KICAgIH0NCiAgICBNQVgtQUND RVNTICByZWFkLXdyaXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBU SU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUgaW50ZXJmYWNlJ3MgZGVz aXJlZCBvciBhZHZlcnRpc2VkIGR1cGxleCBtb2RlLg0KDQogICAgICAgIGZ1bGxEdXBsZXgo MSkgICAgaW5kaWNhdGVzIHRoZSBpbnRlcmZhY2UgaXMgb3BlcmF0aW5nIGF0IGZ1bGwgZHVw bGV4DQogICAgICAgIGhhbGZEdXBsZXgoMikgICAgaW5kaWNhdGVzIHRoZSBpbnRlcmZhY2Ug aXMgb3BlcmF0aW5nIGF0IGhhbGYgZHVwbGV4DQoNCiAgICAgICAiDQogICAgUkVGRVJFTkNF DQogICAgICAgIltNRUYgNi4xXSA2LjA7IFtNRUYgNy4yXSA2LjIuMS4xIg0KICAgIDo6PSB7 IG1lZlNlcnZpY2VJbnRlcmZhY2VDZmdFbnRyeSAzIH0NCg0KbWVmU2VydmljZUludGVyZmFj ZUNmZ05lZ290aWF0ZSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0K ICAgICAgICBmb3JjZSAgICAgICAoMSksDQogICAgICAgIGF1dG8gICAgICAgICgyKQ0KICAg IH0NCiAgICBNQVgtQUNDRVNTICByZWFkLXdyaXRlDQogICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUg aW50ZXJmYWNlJ3MgZGVzaXJlZCBvciBhZHZlcnRpc2VkIG5lZ290aWF0aW9uDQogICAgICAg IG1vZGUuDQoNCiAgICAgICAgZm9yY2UoMSkgICAgICBpbmRpY2F0ZXMgdGhlIGludGVyZmFj ZSBpcyBzZXQgdG8gYSBtYW51YWwgbW9kZSBhbmQNCiAgICAgICAgICAgICAgICAgICAgICBz cGVlZCwgZHVwbGV4LCBhbmQgZmxvdyBjb250cm9sIGFyZSBkZXRlcm1pbmVkIHZpYQ0KICAg ICAgICAgICAgICAgICAgICAgIGZvcmNlZCBtYW51YWwgc2V0dGluZ3MNCiAgICAgICAgYXV0 bygyKSAgICAgICBpbmRpY2F0ZXMgdGhlIGludGVyZmFjZSBzcGVlZCwgZHVwbGV4LCBhbmQg ZmxvdyBjb250cm9sDQogICAgICAgICAgICAgICAgICAgICAgYXJlIGRldGVyaW1pbmVkIHZp YSBhdXRvLW5lZ290aWF0aW9uDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJb TUVGIDYuMV0gNi4wOyBbTUVGIDcuMl0gNi4yLjEuMSINCiAgICA6Oj0geyBtZWZTZXJ2aWNl SW50ZXJmYWNlQ2ZnRW50cnkgNCB9DQoNCm1lZlNlcnZpY2VJbnRlcmZhY2VDZmdGbG93Q29u dHJvbCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICBm bG93Q29udHJvbE9mZiAgKDEpLA0KICAgICAgICBmbG93Q29udHJvbE9uICAgKDIpDQogICAg fQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBp bnRlcmZhY2UncyBkZXNpcmVkIG9yIGFkdmVydGlzZWQgZmxvdw0KICAgICAgICBjb250cm9s IG1vZGUuDQoNCiAgICAgICAgZmxvd0NvbnRyb2xPZmYoMSkgIGluZGljYXRlcyB0aGUgZmxv dyBjb250cm9sIGZvciB0aGUgaW50ZXJmYWNlIGlzDQogICAgICAgICAgICAgICAgICAgICAg ICAgICBpcyB0dXJuZWQgb2ZmDQogICAgICAgIGZsb3dDb250cm9sT24oMikgICBpbmRpY2F0 ZXMgdGhhdCBmbG93IGNvbnRyb2wgZm9yIHRoZSBpbnRlcmZhY2UgaXMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHR1cm5lZCBvbg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAg ICAgICAiW01FRiA3LjJdIDYuMi4xOyBbUS44NDAuMV0gNi4yLjEuMiINCiAgICA6Oj0geyBt ZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnRW50cnkgNSB9DQoNCm1lZlNlcnZpY2VJbnRlcmZhY2VD ZmdGcmFtZUZvcm1hdCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0K ICAgICAgICBub1RhZyAgICAgICAoMSksDQogICAgICAgIGN0YWcgICAgICAgICgyKSwNCiAg ICAgICAgc3RhZyAgICAgICAgKDMpLA0KICAgICAgICBzdGFnQ3RhZyAgICAoNCkNCiAgICB9 DQogICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQN CiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhlIGlu dGVyZmFjZSBmcmFtZSBmb3JtYXQgdHlwZSB0aGF0IHRoZQ0KICAgICAgICBJbnRlcmZhY2Ug Y2FuIHJlY29nbml6ZS4NCg0KICAgICAgICBub1RhZygxKSAgICAgICAgaW5kaWNhdGVzIHRo YXQgYWxsIGRhdGEgb24gdGhlIGludGVyZmFjZSBpcw0KICAgICAgICAgICAgICAgICAgICAg ICAgYXMgdW50YWdnZWQgZGF0YQ0KICAgICAgICBjdGFnKDIpICAgICAgICAgaW5kaWNhdGVz IHRoYXQgdGFnZ2VkIGRhdGEgaXMgYXNzb2NpYXRlZCB3aXRoDQogICAgICAgICAgICAgICAg ICAgICAgICBDRS1WTEFOIElEIG9yIGEgQy1UQUcNCiAgICAgICAgc3RhZygzKSAgICAgICAg IGluZGljYXRlcyB0aGF0IHRhZ2dlZCBkYXRhIGlzIGFzc29jaWF0ZWQgd2l0aA0KICAgICAg ICAgICAgICAgICAgICAgICAgYSBwcm92aWRlciB0YWcgb3IgUy1UQUcNCiAgICAgICAgc3Rh Z0N0YWcoNCkgICAgIGluZGljYXRlcyB0aGF0IHNlcnZpY2UgdHJhZmZpYyBpZGVudGlmaWVk IHdpdGgNCiAgICAgICAgICAgICAgICAgICAgICAgIGJvdGggYW4gUy1UQUcgKG91dGVyIHRh ZykgYW5kIGEgQy1UQUcgKGlubmVyIHRhZykNCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQog ICAgICAgIltNRUYgNi4xXSA2LjAiDQogICAgOjo9IHsgbWVmU2VydmljZUludGVyZmFjZUNm Z0VudHJ5IDYgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnSW5ncmVzc0J3cEluZGV4IE9C SkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1Mg IHJlYWQtd3JpdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04N CiAgICAgICAiVGhpcyBvYmplY3QgaXMgdGhlIGluZGV4IG51bWJlciBvZiB0aGUgaW5ncmVz cyBiYW5kd2lkdGggcHJvZmlsZQ0KICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIGN1cnJl bnQgaW50ZXJmYWNlLiBBIHZhbHVlIG9mIDAgaW5kaWNhdGVzIHRoYXQgbm8NCiAgICAgICAg aW50ZXJmYWNlIGluZ3Jlc3MgYmFuZHdpdGggcHJvZmlsZSBpcyBhc3NvY2lhdGVkIHdpdGgg dGhlIGludGVyZmFjZS4NCg0KICAgICAgICBUaGlzIGluZGV4IGluZGljYXRlcyBhIHNwZWNp ZmljIHByb2ZpbGUgcHJldmlvdXNseSBjb25maWd1cmVkIHZpYQ0KICAgICAgICBtZWZTZXJ2 aWNlQndwQ2ZnVGFibGUuIE11bHRpcGxlIENvUyBiYW5kd2lkdGggcHJvZmlsZXMgdXNpbmcg dGhpcw0KICAgICAgICBvbmUgaW5kZXggcG9pbnQgdG8gdGhlIG1lZlNlcnZpY2VCd3BDZmdJ dGVtVGFibGUuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0g Ni4wOyBbTUVGIDcuMl0gNi4yLjEuMiINCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJmYWNl Q2ZnRW50cnkgNyB9DQoNCm1lZlNlcnZpY2VJbnRlcmZhY2VDZmdFZ3Jlc3NCd3BJbmRleCBP QkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFVuc2lnbmVkMzINCiAgICBNQVgtQUNDRVNT ICByZWFkLXdyaXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9O DQogICAgICAgIlRoaXMgb2JqZWN0IGlzIHRoZSBpbmRleCBudW1iZXIgb2YgdGhlIGVncmVz cyBiYW5kd2lkdGggcHJvZmlsZQ0KICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIGN1cnJl bnQgaW50ZXJmYWNlLiBBIHZhbHVlIG9mIDAgaW5kaWNhdGVzIHRoYXQgbm8NCiAgICAgICAg aW50ZXJmYWNlIGVncmVzcyBiYW5kd2l0aCBwcm9maWxlIGlzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgaW50ZXJmYWNlLg0KDQogICAgICAgIFRoaXMgaW5kZXggaW5kaWNhdGVzIGEgc3BlY2lm aWMgcHJvZmlsZSBwcmV2aW91c2x5IGNvbmZpZ3VyZWQgdmlhDQogICAgICAgIG1lZlNlcnZp Y2VCd3BDZmdUYWJsZS4gTXVsdGlwbGUgQ29TIGJhbmR3aWR0aCBwcm9maWxlcyB1c2luZyB0 aGlzDQogICAgICAgIG9uZSBpbmRleCBwb2ludCB0byB0aGUgbWVmU2VydmljZUJ3cENmZ0l0 ZW1UYWJsZQ0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2LjFdIDYu MDsgW01FRiA3LjJdIDYuMi4xLjIiDQogICAgOjo9IHsgbWVmU2VydmljZUludGVyZmFjZUNm Z0VudHJ5IDggfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnTDJjcEluZGV4IE9CSkVDVC1U WVBFDQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQt d3JpdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAiVGhpcyBvYmplY3QgaXMgdGhlIGluZGV4IG9mIHRoZSBMMkNQIHByb2ZpbGUgKG1lZlNl cnZpY2VMMmNwQ2ZnSW5kZXgpDQogICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgY3VycmVu dCBpbnRlcmZhY2UuIEEgdmFsdWUgb2YgMCBpbmRpY2F0ZXMgdGhhdCBubw0KICAgICAgICBp bnRlcmZhY2UgTDJDUCBwcm9maWxlIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgaW50ZXJmYWNl Lg0KDQogICAgICAgIFRoaXMgaW5kZXggaW5kaWNhdGVzIGEgc3BlY2lmaWMgTDJDUCBwcm9m aWxlIHByZXZpb3VzbHkgY29uZmlndXJlZCB2aWENCiAgICAgICAgbWVmU2VydmljZUwyY3BD ZmdUYWJsZS4gSW5kaXZpZHVhbCBMMkNQIHByb3RvY2xzIHByb2ZpbGVzIHVzaW5nIHRoaXMN CiAgICAgICAgb25lIGluZGV4IHBvaW50IHRvIHRoZSBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1U YWJsZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjA7 IFtNRUYgNi4xLjFdIDguMDsgW01FRiA3LjJdIDYuMi4xLjIiDQogICAgOjo9IHsgbWVmU2Vy dmljZUludGVyZmFjZUNmZ0VudHJ5IDkgfQ0KDQoNCi0tICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQotLSBFdGhlcm5ldCBTZXJ2aWNlIEludGVyZmFjZSBTdGF0dXMNCi0tICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQoNCm1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNUYWJsZSBPQkpF Q1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFNFUVVFTkNFIE9GIE1lZlNlcnZpY2VJbnRlcmZh Y2VTdGF0dXNFbnRyeQ0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgdGFibGUg cmVwcmVzZW50cyB0aGUgbG9jYWwgaW50ZXJmYWNlIHN0YXR1cyB0YWJsZSBmb3IgYW4NCiAg ICAgICAgTUVGIEV0aGVybmV0IGNvbXBsaWFudCBORS4gVGhlIHByaW1hcnkgcHVycG9zZSBv ZiB0aGlzIHRhYmxlIGlzIHRvDQogICAgICAgIHByb3ZpZGUgc3RhdHVzIGluZm9ybWF0aW9u IG9mIHRoZSBpbnRlcmZhY2UgZm9yIGEgTUVGIE5FLiBSb3dzIGFyZQ0KICAgICAgICBhdXRv bWF0aWNhbGx5IGNyZWF0ZWQgaW4gdGhlIHRhYmxlIGJhc2VkIHVwb24gdGhlIGludGVyZmFj ZXMgdGhhdCBhIE1FRg0KICAgICAgICBORSBjb250YWlucy4gSW5kaXZpZHVhbCByb3dzIGFy ZSBhY2Nlc3NlZCB2aWEgdGhlIGlmSW5kZXggaW5kZXguDQogICAgICAgIg0KICAgIFJFRkVS RU5DRQ0KICAgICAgICJbTUVGIDYuMV0sIFtNRUYgNy4yXSwgW01FRiAxMC4yXSwgW1EuODQw LjFdIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2UgMiB9DQoNCm1lZlNlcnZpY2VJ bnRlcmZhY2VTdGF0dXNFbnRyeSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIE1lZlNl cnZpY2VJbnRlcmZhY2VTdGF0dXNFbnRyeQ0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3Np YmxlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAg IlRoZSBjb25jZXB0dWFsIHJvdyBvZiBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVzVGFibGUu Ig0KICAgIElOREVYIHsgaWZJbmRleCB9DQogICAgOjo9IHsgbWVmU2VydmljZUludGVyZmFj ZVN0YXR1c1RhYmxlIDEgfQ0KDQpNZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVzRW50cnkgOjo9 IFNFUVVFTkNFIHsNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNUeXBlICAgICAg ICAgICAgICAgTWVmU2VydmljZUludGVyZmFjZVR5cGUsDQogICAgICBtZWZTZXJ2aWNlSW50 ZXJmYWNlU3RhdHVzUGh5c2ljYWxMYXllciAgICAgIElBTkFpZk1hdVR5cGVMaXN0Qml0cywN CiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNNb2RlICAgICAgICAgICAgICAgSU5U RUdFUiwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNGbG93Q29udHJvbCAgICAg ICAgSU5URUdFUiwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNNYXhWYyAgICAg ICAgICAgICAgVW5zaWduZWQzMiwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNN YXhFbmRQb2ludFBlclZjICAgVW5zaWduZWQzMg0KICAgIH0NCg0KbWVmU2VydmljZUludGVy ZmFjZVN0YXR1c1R5cGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBNZWZTZXJ2aWNl SW50ZXJmYWNlVHlwZQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpcyBh IHZlY3RvcnMgb2YgYml0cyB0aGF0IGluZGljYXRlcyB0aGUgcG9zc2libGUNCiAgICAgICAg aW50ZXJmYWNlIHR5cGVzIHRoYXQgYW4gaW50ZXJmYWNlIGNhbiBiZSBjb25maWd1cmVkIHRv LiBBbiBpbnRlcmZhY2UsDQogICAgICAgIGZvciBpbnN0YW5jZSwgY2FuIGJlIGNvbmZpZ3Vy ZWQgdG8gYmUgYSBVTkkgdHlwZSAxIG9yIDIsIG9yIGFuIEVOTkkuDQoNCiAgICAgICAgQWxs IHRoZSBwb3NzaWJsZSBjYXBhYmlsaXRpZXMgb2YgYW4gaW50ZXJmYWNlIGFyZSBpbmRpY2lh dGVkLCBvbmUgYml0DQogICAgICAgIHBlciBwb3NzaWJsZSB0eXBlLiBBdCBsZWFzdCBvbmUg Yml0IG11c3QgYmUgc2V0IGZvciBNRUYgY29tcGxpYW50IE5Fcy4NCiAgICAgICAiDQogICAg UkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjAiDQogICAgOjo9IHsgbWVmU2Vydmlj ZUludGVyZmFjZVN0YXR1c0VudHJ5IDEgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVz UGh5c2ljYWxMYXllciBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElBTkFpZk1hdVR5 cGVMaXN0Qml0cw0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAg IGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpcyBhIHZl Y3RvciBvZiBiaXRzIHRoYXQgaW5kaWNhdGVzIHRoZSBpbnRlcmZhY2UgDQogICAgICAgIHBo eXNpY2FsIGxheWVyIE1BVSB0eXBlIGFzIHNwZWNpZmllZCBpbiB0aGUgSUFOQS1NQVUtTUlC Lg0KDQogICAgICAgIEFsbCBwb3NzaWJsZSBjYXBhYmlsaXRpZXMgb2YgYW4gaW50ZXJmYWNl IGFyZSBpbmRpY2F0ZWQsIG9uZSBiaXQNCiAgICAgICAgcGVyIHBvc3NpYmxlIHR5cGUuIEF0 IGxlYXN0IG9uZSBtdXN0IGJpdCBtdXN0IGJlIHNldCBmb3IgTUVGDQogICAgICAgIGNvbXBs aWFudCBORXMuIA0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2LjFd IDYuMCINCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVzRW50cnkgMiB9DQoN Cm1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNNb2RlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFY ICAgICAgSU5URUdFUiB7DQogICAgICAgIGZ1bGxEdXBsZXggICgxKSwNCiAgICAgICAgaGFs ZkR1cGxleCAgKDIpDQogICAgfQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNU QVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVj dCBpbmRpY2F0ZXMgdGhlIG9wZXJhdGluZyBpbnRlcmZhY2UgZHVwbGV4IG1vZGUgYWZ0ZXIN CiAgICAgICAgQSBsaW5rIGhhcyBiZWVuIGVzdGFibGlzaGVkIHdpdGggdGhlIE5FcyBwYXJ0 bmVyLg0KDQogICAgICAgIGZ1bGxEdXBsZXgoMSkgICAgaW5kaWNhdGVzIHRoZSBpbnRlcmZh Y2UgaXMgb3BlcmF0aW5nIGF0IGZ1bGwgZHVwbGV4DQogICAgICAgIGhhbGZEdXBsZXgoMikg ICAgaW5kaWNhdGVzIHRoZSBpbnRlcmZhY2UgaXMgb3BlcmF0aW5nIGF0IGhhbGYgZHVwbGV4 DQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0gNi4wOyBbTUVG IDcuMl0gNi4yLjEuMSINCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVzRW50 cnkgMyB9DQoNCm1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNGbG93Q29udHJvbCBPQkpFQ1Qt VFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICBmbG93Q29udHJvbE9m ZiAgKDEpLA0KICAgICAgICBmbG93Q29udHJvbE9uICAgKDIpDQogICAgfQ0KICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQ VElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhlIG9wZXJhdGluZyBpbnRl cmZhY2UgZmxvdyBjb250cm9sIG1vZGUuDQoNCiAgICAgICAgZmxvd0NvbnRyb2xPZmYoMSkg IGluZGljYXRlcyB0aGUgZmxvdyBjb250cm9sIGZvciB0aGUgaW50ZXJmYWNlIGlzDQogICAg ICAgICAgICAgICAgICAgICAgICAgICBpcyB0dXJuZWQgb2ZmDQogICAgICAgIGZsb3dDb250 cm9sT24oMikgICBpbmRpY2F0ZXMgdGhhdCBmbG93IGNvbnRyb2wgZm9yIHRoZSBpbnRlcmZh Y2UgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHR1cm5lZCBvbg0KICAgICAgICIN CiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA3LjJdIDYuMi4xOyBbUS44NDAuMV0gNi4y LjIuMiINCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVzRW50cnkgNCB9DQoN Cm1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNNYXhWYyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRB WCAgICAgIFVuc2lnbmVkMzIgKDEuLjQwOTUpDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5 DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRo aXMgb2JqZWN0IGluZGljYXRlcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgdmlydHVhbCBjaGFu bmVscyB0aGF0IHRoZQ0KICAgICAgICBpbnRlcmZhY2UgY2FuIHN1cHBvcnQuIEEgdmlydHVh bCBjYW4gYmUgYW4gRVZDIG9yIGFuIE9WQyBkZXBlbmRpbmcgDQogICAgICAgIHVwb24gdGhl IHR5cGUgb2YgaW50ZXJmYWNlIHRoYXQgaXMgc2VsZWN0ZWQuICANCiAgICAgICAiDQogICAg UkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjA7IFtNRUYgNy4yXSA2LjIuMS4yIg0K ICAgIDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNFbnRyeSA1IH0NCg0KbWVmU2Vy dmljZUludGVyZmFjZVN0YXR1c01heEVuZFBvaW50UGVyVmMgT0JKRUNULVRZUEUNCiAgICBT WU5UQVggICAgICBVbnNpZ25lZDMyICgxLi4xMCkNCiAgICBNQVgtQUNDRVNTICByZWFkLW9u bHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAi VGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBpbnRlcmZhY2UgbWF4aW11bSBudW1iZXIgb2Yg ZW5kIHBvaW50cyBwZXINCiAgICAgICAgdmlydHVhbCBjaGFubmVsLiBJdCBjYW4gYmUgdXNl ZCB0byBpbmRpY2F0ZSB0aGUgbWF4aW11bSBudW1iZXIgb2YgT1ZDDQogICAgICAgIGVuZCBw b2ludHMgcGVyIE9WQy4gSXQgaGFzIG5vIGN1cnJlbnQgYXBwbGljYWJpbGl0eSBmb3IgRVZD cy4gDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDI2LjFdIg0KICAg IDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNFbnRyeSA2IH0NCg0KDQotLSAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KLS0gRXRoZXJuZXQgU2VydmljZSBJbnRlcmZhY2UgU3Rh dGlzdGljcw0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KbWVmU2VydmljZUludGVy ZmFjZVN0YXRpc3RpY3NUYWJsZSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFNFUVVF TkNFIE9GIE1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzRW50cnkNCiAgICBNQVgtQUND RVNTICBub3QtYWNjZXNzaWJsZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVND UklQVElPTg0KICAgICAgICJUaGlzIHRhYmxlIHJlcHJlc2VudHMgdGhlIGxvY2FsIGludGVy ZmFjZSBzdGF0aXN0aWNzIHRhYmxlIGZvciBhbg0KICAgICAgICBNRUYgRXRoZXJuZXQgY29t cGxpYW50IE5FLiBUaGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoaXMgdGFibGUgaXMgdG8NCiAg ICAgICAgcHJvdmlkZSBzdGF0aXN0aWNzIGluZm9ybWF0aW9uIG9mIHRoZSBpbnRlcmZhY2Ug Zm9yIGEgTUVGIE5FLiBSb3dzIGFyZQ0KICAgICAgICBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQg aW4gdGhlIHRhYmxlIGJhc2VkIHVwb24gdGhlIGludGVyZmFjZXMgdGhhdCBhIE1FRg0KICAg ICAgICBORSBjb250YWlucy4gSW5kaXZpZHVhbCByb3dzIGFyZSBhY2Nlc3NlZCB2aWEgdGhl IGlmSW5kZXggaW5kZXguDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVG IDE1XSwgW1EuODQwLjFdIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2UgMyB9DQoN Cm1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzRW50cnkgT0JKRUNULVRZUEUNCiAgICBT WU5UQVggICAgICBNZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0VudHJ5DQogICAgTUFY LUFDQ0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAg REVTQ1JJUFRJT04NCiAgICAgICAiVGhlIGNvbmNlcHR1YWwgcm93IG9mIG1lZlNlcnZpY2VJ bnRlcmZhY2VTdGF0aXN0aWNzVGFibGUuIg0KICAgIElOREVYIHsgaWZJbmRleCB9DQogICAg Ojo9IHsgbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NUYWJsZSAxIH0NCg0KTWVmU2Vy dmljZUludGVyZmFjZVN0YXRpc3RpY3NFbnRyeSA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgbWVm U2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NJbmdyZXNzVW5kZXJzaXplZCAgIENvdW50ZXIz MiwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzSW5ncmVzc092ZXJzaXpl ZCAgICBDb3VudGVyMzIsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0lu Z3Jlc3NGcmFnbWVudHMgICAgQ291bnRlcjMyLA0KICAgICAgbWVmU2VydmljZUludGVyZmFj ZVN0YXRpc3RpY3NJbmdyZXNzQ3JjQWxpZ25tZW50IENvdW50ZXIzMiwNCiAgICAgIG1lZlNl cnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzSW5ncmVzc0ludmFsaWRWaWQgICBDb3VudGVyMzIs DQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0luZ3Jlc3NPY3RldHMgICAg ICAgQ291bnRlcjY0LA0KICAgICAgbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NJbmdy ZXNzVW5pY2FzdCAgICAgIENvdW50ZXIzMiwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VT dGF0aXN0aWNzSW5ncmVzc011bHRpY2FzdCAgICBDb3VudGVyMzIsDQogICAgICBtZWZTZXJ2 aWNlSW50ZXJmYWNlU3RhdGlzdGljc0luZ3Jlc3NCcm9hZGNhc3QgICAgQ291bnRlcjMyLA0K ICAgICAgbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NFZ3Jlc3NPY3RldHMgICAgICAg IENvdW50ZXI2NCwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzRWdyZXNz VW5pY2FzdCAgICAgICBDb3VudGVyMzIsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlU3Rh dGlzdGljc0VncmVzc011bHRpY2FzdCAgICAgQ291bnRlcjMyLA0KICAgICAgbWVmU2Vydmlj ZUludGVyZmFjZVN0YXRpc3RpY3NFZ3Jlc3NCcm9hZGNhc3QgICAgIENvdW50ZXIzMg0KICAg IH0NCg0KbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NJbmdyZXNzVW5kZXJzaXplZCAg IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VT UyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9O DQogICAgICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUgbnVtYmVyIG9mIGZyYW1lcyB0 aGF0IHdlcmUgcmVjZWl2ZWQNCiAgICAgICAgb24gYSBORSBpbnRlcmZhY2UgdGhhdCB3ZXJl IHNtYWxsZXIgdGhhbiA2NCBvY3RldHMuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAg ICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6Oj0geyBtZWZTZXJ2 aWNlSW50ZXJmYWNlU3RhdGlzdGljc0VudHJ5IDEgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNl U3RhdGlzdGljc0luZ3Jlc3NPdmVyc2l6ZWQgICAgT0JKRUNULVRZUEUNCiAgICBTWU5UQVgg ICAgICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5k aWNhdGVzIHRoZSBudW1iZXIgb2YgZnJhbWVzIHRoYXQgd2VyZSByZWNlaXZlZA0KICAgICAg ICBvbiBhIE5FIGludGVyZmFjZSB0aGF0IHdlcmUgbGFyZ2VyIHRoYW4gdGhlIG1heGltdW0g TVRVIHNpemUuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4 LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJmYWNlU3Rh dGlzdGljc0VudHJ5IDIgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0luZ3Jl c3NGcmFnbWVudHMgICAgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzIN CiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBudW1i ZXIgb2YgZnJhbWVzIHRoYXQgd2VyZSByZWNlaXZlZA0KICAgICAgICBvbiBhIE5FIGludGVy ZmFjZSB0aGF0IHdlcmUgbGVzcyB0aGFuIDY0IG9jdGV0cyBpbiBsZW5ndGgNCiAgICAgICAg KGV4Y2x1ZGluZyBmcmFtaW5nIGJpdHMgYnV0IGluY2x1ZGluZyBGQ1Mgb2N0ZXRzKSBhbmQg aGFkIA0KICAgICAgICBlaXRoZXIgYSBiYWQgRnJhbWUgQ2hlY2sgU2VxdWVuY2UgKEZDUykg d2l0aCBhbiBpbnRlZ3JhbCANCiAgICAgICAgbnVtYmVyIG9mIG9jdGV0cyAoRkNTIEVycm9y KSBvciBhIGJhZCBGQ1Mgd2l0aCBhIG5vbi1pbnRlZ3JhbA0KICAgICAgICBudW1iZXIgb2Yg b2N0ZXRzIChBbGlnbm1lbnQgRXJyb3IpLg0KDQogICAgICAgIE5vdGUgdGhhdCBpdCBpcyBl bnRpcmVseSBub3JtYWwgZm9yIHRoaXMgY291bnRlciB0bw0KICAgICAgICBpbmNyZW1lbnQu ICBUaGlzIGlzIGJlY2F1c2UgaXQgY291bnRzIGJvdGggcnVudHMgKHdoaWNoIGFyZQ0KICAg ICAgICBub3JtYWwgb2NjdXJyZW5jZXMgZHVlIHRvIGNvbGxpc2lvbnMpIGFuZCBub2lzZSBo aXRzLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiAxNV0gOC4yOyBb US44NDAuMV0gNi4yLjQiDQogICAgOjo9IHsgbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3Rp Y3NFbnRyeSAzIH0NCg0KbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NJbmdyZXNzQ3Jj QWxpZ25tZW50IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAg TUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERF U0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUgbnVtYmVyIG9m IGZyYW1lcyB0aGF0IHdlcmUgcmVjZWl2ZWQNCiAgICAgICAgb24gYSBORSBpbnRlcmZhY2Ug dGhhdCB3ZXJlIGZyb20gNjQgb2N0ZXRzIHRvIHRoZSBtYXhpbXVtIE1UVQ0KICAgICAgICBz aXplIGluIGxlbmd0aCwgYnV0IGhhZCBlaXRoZXIgYSBiYWQgRnJhbWUgQ2hlY2sgU2VxdWVu Y2UgKEZDUykNCiAgICAgICAgd2l0aCBhbiBpbnRlZ3JhbCBudW1iZXIgb2Ygb2N0ZXRzIChG Q1MgRXJyb3IpIG9yIGEgYmFkIEZDUyB3aXRoDQogICAgICAgIGEgbm9uLWludGVncmFsIG51 bWJlciBvZiBvY3RldHMgKEFsaWdubWVudCBFcnJvcikuDQogICAgICAgIg0KICAgIFJFRkVS RU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6Oj0g eyBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0VudHJ5IDQgfQ0KDQptZWZTZXJ2aWNl SW50ZXJmYWNlU3RhdGlzdGljc0luZ3Jlc3NJbnZhbGlkVmlkICAgT0JKRUNULVRZUEUNCiAg ICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAg ICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBv YmplY3QgaW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgZnJhbWVzIHRoYXQgd2VyZSByZWNlaXZl ZA0KICAgICAgICBvbiBhIE5FIGludGVyZmFjZSB3aXRoIGFuIGludmFsaWQgVkxBTiBJRC4N CiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgMTVdIDguMjsgW1EuODQw LjFdIDYuMi40Ig0KICAgIDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzRW50 cnkgNSB9DQoNCm1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzSW5ncmVzc09jdGV0cyAg T0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyNjQNCiAgICBNQVgtQUNDRVNT ICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04N CiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgdmFsaWQgb2N0 ZXRzIHRoYXQgd2VyZSANCiAgICAgICAgcmVjZWl2ZWQgb24gYSBORSBpbnRlcmZhY2UuDQog ICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4x XSA2LjIuNCINCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0VudHJ5 IDYgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0luZ3Jlc3NVbmljYXN0IE9C SkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAg cmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQog ICAgICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUgbnVtYmVyIG9mIHVuaWNhc3QgZnJh bWVzIHRoYXQgDQogICAgICAgIHdlcmUgcmVjZWl2ZWQgb24gYSBORSBpbnRlcmZhY2UuDQog ICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4x XSA2LjIuNCINCiAgICA6Oj0geyBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0VudHJ5 IDcgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0luZ3Jlc3NNdWx0aWNhc3Qg ICAgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICBNQVgtQUND RVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgbXVsdGlj YXN0IGZyYW1lcyB0aGF0IA0KICAgICAgICB3ZXJlIHJlY2VpdmVkIG9uIGEgTkUgaW50ZXJm YWNlLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiAxNV0gOC4yOyBb US44NDAuMV0gNi4yLjQiDQogICAgOjo9IHsgbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3Rp Y3NFbnRyeSA4IH0NCg0KbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NJbmdyZXNzQnJv YWRjYXN0IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgTUFY LUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NS SVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUgbnVtYmVyIG9mIGJy b2FkY2FzdCBmcmFtZXMgdGhhdCANCiAgICAgICAgd2VyZSByZWNlaXZlZCBvbiBhIE5FIGlu dGVyZmFjZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgMTVdIDgu MjsgW1EuODQwLjFdIDYuMi40Ig0KICAgIDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0 aXN0aWNzRW50cnkgOSB9DQoNCm1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0aXN0aWNzRWdyZXNz T2N0ZXRzICBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXI2NA0KICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVND UklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiB2 YWxpZCBvY3RldHMgdGhhdCB3ZXJlIA0KICAgICAgICB0cmFuc21pdHRlZCBvbiBhIE5FIGlu dGVyZmFjZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgMTVdIDgu MjsgW1EuODQwLjFdIDYuMi40Ig0KICAgIDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0 aXN0aWNzRW50cnkgMTAgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0VncmVz c1VuaWNhc3QgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICBN QVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVT Q1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBudW1iZXIgb2Yg dW5pY2FzdCBmcmFtZXMgdGhhdCANCiAgICAgICAgd2VyZSB0cmFuc21pdHRlZCBvbiBhIE5F IGludGVyZmFjZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgMTVd IDguMjsgW1EuODQwLjFdIDYuMi40Ig0KICAgIDo6PSB7IG1lZlNlcnZpY2VJbnRlcmZhY2VT dGF0aXN0aWNzRW50cnkgMTEgfQ0KDQptZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGljc0Vn cmVzc011bHRpY2FzdCAgICBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIz Mg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQN CiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhlIG51 bWJlciBvZiBtdWx0aWNhc3QgZnJhbWVzIHRoYXQgDQogICAgICAgIHdlcmUgdHJhbnNtaXR0 ZWQgb24gYSBORSBpbnRlcmZhY2UuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAg ICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6Oj0geyBtZWZTZXJ2aWNl SW50ZXJmYWNlU3RhdGlzdGljc0VudHJ5IDEyIH0NCg0KbWVmU2VydmljZUludGVyZmFjZVN0 YXRpc3RpY3NFZ3Jlc3NCcm9hZGNhc3QgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBD b3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBj dXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVz IHRoZSBudW1iZXIgb2YgYnJvYWRjYXN0IGZyYW1lcyB0aGF0IA0KICAgICAgICB3ZXJlIHRy YW5zbWl0dGVkIG9uIGEgTkUgaW50ZXJmYWNlLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UN CiAgICAgICAiW01FRiAxNV0gOC4yOyBbUS44NDAuMV0gNi4yLjQiDQogICAgOjo9IHsgbWVm U2VydmljZUludGVyZmFjZVN0YXRpc3RpY3NFbnRyeSAxMyB9DQoNCiAgICANCi0tICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQotLSBFdGhlcm5ldCBVTkkgSW50ZXJmYWNlIENvbmZpZ3Vy YXRpb24NCi0tICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCm1lZlNlcnZpY2VVbmlDZmdU YWJsZSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFNFUVVFTkNFIE9GIE1lZlNlcnZp Y2VVbmlDZmdFbnRyeQ0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgdGFibGUg cmVwcmVzZW50cyB0aGUgc3BlY2lmaWMgVU5JIGF0dHJpYnV0ZXMgY29uZmlndXJhdGlvbiB0 YWJsZQ0KICAgICAgICBmb3IgYW4gTUVGIEV0aGVybmV0IGNvbXBsaWFudCBORS4gVGhlIHBy aW1hcnkgcHVycG9zZSBvZiB0aGlzIHRhYmxlDQogICAgICAgIGlzIHRvIHByb3ZpZGUgY29u ZmlndXJhdGlvbiBvZiB0aGUgVU5JIGZvciBhIE1FRiBORS4gUm93cyBhcmUNCiAgICAgICAg YXV0b21hdGljYWxseSBjcmVhdGVkIGluIHRoZSB0YWJsZSB3aGVuIGFuIGludGVyZmFjZSBp cyBjb25maWd1cmVkIGFzDQogICAgICAgIHR5cGUgVU5JLiBJbmRpdmlkdWFsIHJvd3MgYXJl IGFjY2Vzc2VkIHZpYSB0aGUgaWZJbmRleCBpbmRleC4NCiAgICAgICAiDQogICAgUkVGRVJF TkNFDQogICAgICAgIltNRUYgNi4xXSwgW01FRiA3LjJdLCBbTUVGIDEwLjJdLCBbUS44NDAu MV0iDQogICAgOjo9IHsgbWVmU2VydmljZVVuaUF0dHJpYnV0ZXMgMSB9DQoNCm1lZlNlcnZp Y2VVbmlDZmdFbnRyeSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIE1lZlNlcnZpY2VV bmlDZmdFbnRyeQ0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVT ICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoZSBjb25jZXB0dWFs IHJvdyBvZiBtZWZTZXJ2aWNlVW5pQ2ZnVGFibGUuIg0KICAgIElOREVYIHsgaWZJbmRleCB9 DQogICAgOjo9IHsgbWVmU2VydmljZVVuaUNmZ1RhYmxlIDEgfQ0KDQpNZWZTZXJ2aWNlVW5p Q2ZnRW50cnkgOjo9IFNFUVVFTkNFIHsNCiAgICAgIG1lZlNlcnZpY2VVbmlDZmdJZGVudGlm aWVyICAgICAgICAgIERpc3BsYXlTdHJpbmcsDQogICAgICBtZWZTZXJ2aWNlVW5pQ2ZnQnVu ZGxpbmdNdWx0aXBsZXggICBJTlRFR0VSLA0KICAgICAgbWVmU2VydmljZVVuaUNmZ0NlVmlk VW50YWdnZWQgICAgICAgVmxhbklkLA0KICAgICAgbWVmU2VydmljZVVuaUNmZ0NlUHJpb3Jp dHlVbnRhZ2dlZCAgSUVFRTgwMjFQcmlvcml0eVZhbHVlDQogICAgfQ0KDQptZWZTZXJ2aWNl VW5pQ2ZnSWRlbnRpZmllciBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIERpc3BsYXlT dHJpbmcgKFNJWkUoMC4uNDUpKQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUNCiAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmpl Y3QgaW5kaWNhdGVzIHRoZSBVTkkgaWRlbnRpZmllci4gVGhpcyBpcyBkaXN0aW5jdCBmcm9t IA0KICAgICAgICB0aGUgbWVmU2VydmljZUludGVyZmFjZUNmZ0lkZW50aWZpZXIgYW5kIGFs bG93cyB0aGUgbmFtaW5nIG9mIHRoZQ0KICAgICAgICBVTkkgc2VwYXJhdGVseSBmcm9tIHRo ZSBJbnRlcmZhY2UgbmFtZS4gVGhlIGlkZW50aWZpZXIgaXMNCiAgICAgICAgYW4gYXJiaXRy YXJ5IHRleHQgc3RyaW5nIHRoYXQgaXMgdXNlZCB0byBpZGVudGlmeSBhbiBpbnRlcmZhY2Uu IA0KICAgICAgICBVbmlxdWUgc3RyaW5nIHZhbHVlcyBhcmUgY2hvc2VuIHRvIHVuaXF1ZWx5 IGlkZW50aWZ5IHRoZSBVTkkuDQoNCiAgICAgICAgT2N0ZXQgdmFsdWVzIG9mIDB4MDAgdGhy b3VnaCAweDFmIGFyZSBpbGxlZ2FsLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAg ICAiW01FRiA2LjFdIDYuMCwgW01FRiA3LjJdIDYuMi4xLjIiDQogICAgOjo9IHsgbWVmU2Vy dmljZVVuaUNmZ0VudHJ5IDEgfQ0KDQoNCm1lZlNlcnZpY2VVbmlDZmdCdW5kbGluZ011bHRp cGxleCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICBh bGxUb09uZSAgICAgICAgICAgICgxKSwNCiAgICAgICAgYnVuZGxpbmcgICAgICAgICAgICAo MiksDQogICAgICAgIG11bHRpcGxleCAgICAgICAgICAgKDMpLA0KICAgICAgICBidW5kbGlu Z011bHRpcGxleCAgICg0KQ0KICAgIH0NCiAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0K ICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAiQ29u ZmlndXJlcyBidW5kbGluZyBhbmQgbXVsdGlwbGV4aW5nIG9wdGlvbnMgZm9yIHRoZSBVTkku IFRoaXMgb2JqZWN0DQogICAgICAgICBpcyBhbiBlbnVtZXJhdGVkIGxpc3Qgb2YgcG9zc2li bGUgbXVsdGlwbGV4aW5nIGFuZCBidW5kbGluZyBvcHRpb25zDQogICAgICAgICBvbiBhIFVO SSB0aGF0IGlzIHVuYW1iaWd1b3VzIGFuZCBwcm92aWRlcyBvbmx5IHRoZSBsZWdhbCBwb3Nz aWJpbGl0aWVzLg0KDQogICAgICAgICBhbGxUb09uZSgxKSAgICAgICAgICBBbGwgdG8gT25l IEJ1bmRsaW5nLCB1c2VkIGZvciBQcml2YXRlIHNlcnZpY2VzOg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRVBMLCBFUC1MQU4sIGFuZCBFUC1UcmVlDQoNCiAgICAgICAgIGJ1 bmRsaW5nKDIpICAgICAgICAgIEJ1bmRsaW5nLCBpbmRpY2F0ZXMgb25lIG9yIG1vcmUgQ0Ut VkxBTlMgcGVyIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VydmljZSwgdXNl ZCBmb3IgdmlydHVhbCBwcml2YXRlIENFLVZMQU4gDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBwcmVzZXJ2YXRpb24gc2VydmljZXM6IEVWUEwsIEVWUC1MQU4sIEVWUC1UcmVl DQoNCiAgICAgICAgIG11bHRpcGxleCgzKSAgICAgICAgIFNlcnZpY2UgTXVsdGlwbGV4aW5n LCBpbmRpY2F0ZXMgb25lIG9yIG1vcmUgRVZDcw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgcGVyIFVOSSwgdXNlZCBmb3IgdmlydHVhbCBwcml2YXRlIENFLVZMQU4gDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBwcmVzZXJ2YXRpb24gb3Igbm9uLXByZXNlcnZh dGlvbiBzZXJ2aWNlczoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVWUEwsIEVW UC1MQU4sIEVWUC1UcmVlDQoNCiAgICAgICAgIGJ1bmRsaW5nTXVsdGlwbGV4KDQpIFNlcnZp Y2UgTXVsdGlwbGV4aW5nIHBsdXMgQnVuZGxpbmcsIGluZGljYXRlcyBvbmUgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBvciBtb3JlIEVWQ3MgcGVyIFVOSSB0aGF0IGFyZSBj b21wb3NlZCBvZiBvbmUgb3IgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3Jl IENFLVZMQU5zLCB1c2VkIGZvciB2aXJ0dWFsIENFLVZMQU4gDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBwcmVzZXJ2YXRpb24gc2VydmljZXM6IEVWUEwsIEVWUC1MQU4sIEVW UC1UcmVlDQogICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2LjFdIDYu MCwgW01FRiA3LjJdIDYuMi4xLjIiDQogICAgOjo9IHsgbWVmU2VydmljZVVuaUNmZ0VudHJ5 IDIgfQ0KDQptZWZTZXJ2aWNlVW5pQ2ZnQ2VWaWRVbnRhZ2dlZCBPQkpFQ1QtVFlQRQ0KICAg IFNZTlRBWCAgICAgIFZsYW5JZA0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAg U1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICJDb25maWd1 cmVzIHRoZSBDRSBWTEFOIElEIGFzc29jaWF0ZWQgd2l0aCB1bnRhZ2dlZCBhbmQgcHJpb3Jp dHkNCiAgICAgICAgIFNlcnZpY2UgRnJhbWVzLiBJdCBhbGxvd3MgdGhlIGlkZW50aWZpY2F0 aW9uIG9mIHVudGFnZ2VkIGFuZCANCiAgICAgICAgIFByaW9yaXR5IHRhZ2dlZCB0cmFmZmlj IHdpdGggYSBzcGVjaWZpYyBDRS1WTEFOIElELiBUaGlzIG9iamVjdA0KICAgICAgICAgaXMg aWdub3JlZCBmb3IgYWxsIHRvIG9uZSBidW5kbGluZyBhdCB0aGUgVU5JLg0KICAgICAgICAi DQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjAsIFtNRUYgNy4yXSA2LjIu MS4yIg0KICAgIERFRlZBTCB7IDEgfQ0KICAgIDo6PSB7IG1lZlNlcnZpY2VVbmlDZmdFbnRy eSAzIH0NCg0KbWVmU2VydmljZVVuaUNmZ0NlUHJpb3JpdHlVbnRhZ2dlZCBPQkpFQ1QtVFlQ RQ0KICAgIFNZTlRBWCAgICAgIElFRUU4MDIxUHJpb3JpdHlWYWx1ZQ0KICAgIE1BWC1BQ0NF U1MgIHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBU SU9ODQogICAgICAgICJDb25maWd1cmVzIHRoZSBDRSBWTEFOIFByaW9yaXR5IGFzc29jaWF0 ZWQgd2l0aCB1bnRhZ2dlZCBTZXJ2aWNlDQogICAgICAgICBGcmFtZXMuIEl0IGFsbG93cyB0 aGUgYXNzaWdubWVudCBvZiBhIHNwZWNpZmljIFZMQU4gcHJpb3JpdHkgdG8NCiAgICAgICAg IFVudGFnZ2VkIHRyYWZmaWMuIFRoaXMgb2JqZWN0IGlzIGlnbm9yZWQgZm9yIGFsbCB0byBv bmUgYnVuZGxpbmcNCiAgICAgICAgIGF0IHRoZSBVTkkuDQogICAgICAgICINCiAgICBSRUZF UkVOQ0UNCiAgICAgICAiW01FRiA3LjJdIDYuMi4xLjIiDQogICAgOjo9IHsgbWVmU2Vydmlj ZVVuaUNmZ0VudHJ5IDQgfQ0KDQoNCi0tICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQotLSBF dGhlcm5ldCBFVkMgQ29uZmlndXJhdGlvbg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cg0KbWVmU2VydmljZUV2Y05leHRJbmRleCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAg IFVuc2lnbmVkMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgY29udGFp bnMgYW4gdW51c2VkIHZhbHVlIGZvciBhbiBFVkMgb24gYQ0KICAgICAgICBNRUYgY29tcGxp YW50IE5FLCBvciBhIHplcm8gdG8gaW5kaWNhdGUgdGhhdCBub25lIGV4aXN0LiBUaGlzIHZh bHVlDQogICAgICAgIG5lZWRzIHRvIGJlIHJlYWQgaW4gb3JkZXIgdG8gZmluZCBhbiBhdmFp bGFibGUgaW5kZXggZm9yIHJvdy1jcmVhdGlvbiBvZg0KICAgICAgICBhbiBFVkMgYW5kIHRo ZW4gdXNlZCB3aGVuIGEgcm93IGlzIGNyZWF0ZWQuIFRoaXMgdmFsdWUgaXMNCiAgICAgICAg YXV0b21hdGljYWxseSB1cGRhdGVkIGJ5IHRoZSBTTk1QIEFnZW50IGFmdGVyIHRoZSByb3cg aXMgY3JlYXRlZC4NCg0KICAgICAgICBSZWZlcmVudGlhbCBpbnRlZ3JpdHkgaXMgbmVjZXNz YXJ5LCBpLmUuLCB0aGUgaW5kZXggbmVlZHMgdG8gYmUNCiAgICAgICAgcGVyc2lzdGVudCB1 cG9uIGEgcmVib290IG9yIHJlc3RhcnQgb2YgYSBORS4gIFRoZSBpbmRleA0KICAgICAgICBp cyBuZXZlciB0byBiZSByZXVzZWQgZm9yIGEgbmV3IEVWQyBvbiB0aGUgc2FtZSBNRUYgY29t cGxpYW50DQogICAgICAgIE5FIHVudGlsIGl0IHdyYXBzIHRvIHplcm8uICBUaGUgaW5kZXgg dmFsdWUga2VlcHMNCiAgICAgICAgaW5jcmVhc2luZyB1cCB0byB0aGF0IHRpbWUuIFRoaXMg aXMgdG8gZmFjaWxpdGF0ZSBhY2Nlc3MgY29udHJvbCBiYXNlZA0KICAgICAgICBvbiBhIGZp eGVkIGluZGV4IGZvciBhbiBFTVMsIHNpbmNlIHRoZSBpbmRleCBpcyBub3QgcmV1c2VkLg0K ICAgICAgICINCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZjQXR0cmlidXRlcyAxIH0NCg0KbWVm U2VydmljZUV2Y0NmZ1RhYmxlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgU0VRVUVO Q0UgT0YgTWVmU2VydmljZUV2Y0NmZ0VudHJ5DQogICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vz c2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAiVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBzcGVjaWZpYyBFVkMgYXR0cmlidXRlcyBj b25maWd1cmF0aW9uIHRhYmxlDQogICAgICAgIGZvciBhbiBNRUYgRXRoZXJuZXQgY29tcGxp YW50IE5FLiBUaGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoaXMgdGFibGUNCiAgICAgICAgaXMg dG8gcHJvdmlkZSBjb25maWd1cmF0aW9uIG9mIHRoZSBFVkMgZm9yIGEgTUVGIE5FLg0KICAg ICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2LjFdLCBbTUVGIDcuMl0sIFtN RUYgMTAuMl0sIFtRLjg0MC4xXSINCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZjQXR0cmlidXRl cyAyIH0NCg0KbWVmU2VydmljZUV2Y0NmZ0VudHJ5IE9CSkVDVC1UWVBFDQogICAgU1lOVEFY ICAgICAgTWVmU2VydmljZUV2Y0NmZ0VudHJ5DQogICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vz c2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAiVGhlIGNvbmNlcHR1YWwgcm93IG9mIG1lZlNlcnZpY2VFdmNDZmdUYWJsZS4iDQogICAg SU5ERVggeyBtZWZTZXJ2aWNlRXZjQ2ZnSW5kZXggfQ0KICAgIDo6PSB7IG1lZlNlcnZpY2VF dmNDZmdUYWJsZSAxIH0NCg0KTWVmU2VydmljZUV2Y0NmZ0VudHJ5IDo6PSBTRVFVRU5DRSB7 DQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnSW5kZXggICAgICAgICAgICAgICAgIFVuc2lnbmVk MzIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnSWRlbnRpZmllciAgICAgICAgICAgIERpc3Bs YXlTdHJpbmcsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnU2VydmljZVR5cGUgICAgICAgICAg IElOVEVHRVIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnTXR1U2l6ZSAgICAgICAgICAgICAg IFVuc2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnQ2V2bGFuSWRQcmVzZXJ2YXRp b24gIElOVEVHRVIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnQ2V2bGFuQ29zUHJlc2VydmF0 aW9uIElOVEVHRVIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnVW5pY2FzdERlbGl2ZXJ5ICAg ICAgIElOVEVHRVIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnTXVsdGljYXN0RGVsaXZlcnkg ICAgIElOVEVHRVIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnQnJvYWRjYXN0RGVsaXZlcnkg ICAgIElOVEVHRVIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnTDJjcEluZGV4ICAgICAgICAg ICAgIFVuc2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnQWRtaW5TdGF0ZSAgICAg ICAgICAgIEVudGl0eUFkbWluU3RhdGUsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnUm93U3Rh dHVzICAgICAgICAgICAgIFJvd1N0YXR1cw0KICAgIH0NCg0KbWVmU2VydmljZUV2Y0NmZ0lu ZGV4IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1B Q0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERF U0NSSVBUSU9ODQogICAgICAgICJFVkMgaW5kZXggbnVtYmVyLiINCiAgICA6Oj0geyBtZWZT ZXJ2aWNlRXZjQ2ZnRW50cnkgMSB9DQoNCm1lZlNlcnZpY2VFdmNDZmdJZGVudGlmaWVyIE9C SkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgRGlzcGxheVN0cmluZyAoU0laRSgwLi40NSkp DQogICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBF VkMgaWRlbnRpZmllci4gVGhlIGlkZW50aWZpZXIgaXMNCiAgICAgICAgYW4gYXJiaXRyYXJ5 IHRleHQgc3RyaW5nIHRoYXQgaXMgdXNlZCB0byBpZGVudGlmeSBhbiBFVkMuIA0KICAgICAg ICBVbmlxdWUgc3RyaW5nIHZhbHVlcyBhcmUgY2hvc2VuIHRvIHVuaXF1ZWx5IGlkZW50aWZ5 IHRoZSBFVkMuDQoNCiAgICAgICAgT2N0ZXQgdmFsdWVzIG9mIDB4MDAgdGhyb3VnaCAweDFm IGFyZSBpbGxlZ2FsLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2 LjFdIDYuMTsgW01FRiA3LjJdIDYuMi4xLjMiDQogICAgOjo9IHsgbWVmU2VydmljZUV2Y0Nm Z0VudHJ5IDIgfQ0KDQptZWZTZXJ2aWNlRXZjQ2ZnU2VydmljZVR5cGUgT0JKRUNULVRZUEUN CiAgICBTWU5UQVggICAgICBJTlRFR0VSIHsNCiAgICAgICAgcG9pbnRUb1BvaW50ICAgICAg ICAgICAgKDEpLA0KICAgICAgICBtdWx0aXBvaW50VG9NdWx0aXBvaW50ICAoMiksDQogICAg ICAgIHJvb3RlZE11bHRpcG9pbnQgICAgICAgICgzKQ0KICAgIH0NCiAgICBNQVgtQUNDRVNT ICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElP Tg0KICAgICAgICAiQ29uZmlndXJlcyB0aGUgRVZDIHNlcnZpY2UgdHlwZSBmb3IgdGhlIE1F RiBORS4NCg0KICAgICAgICAgcG9pbnRUb1BvaW50KDEpICAgICAgICAgICAgIEVWQyBQb2lu dC10by1Qb2ludCBzZXJ2aWNlLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHVzZWQgZm9yIEVQTCBhbmQgRVZQTCBzZXJ2aWNlcw0KDQogICAgICAgICBtdWx0aXBv aW50VG9NdWx0aXBvaW50KDIpICAgRVZDIE11bHRpcG9pbnQtdG8tTXVsdGlwb2ludCBTZXJ2 aWNlLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVzZWQgZm9yIEVQ LUxBTiBhbmQgRVZQLUxBTiBzZXJ2aWNlcw0KIA0KICAgICAgICAgcm9vdGVkTXVsdGlwb2lu dCgzKSAgICAgICAgIEVWQyBSb290ZWQtTXVsdGlwb2ludCBTZXJ2aWNlLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVzZWQgZm9yIEVQLVRyZWUgYW5kIEVWUC1U cmVlIHNlcnZpY2VzDQogICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2 LjFdIDYuMTsgW01FRiA3LjJdIDYuMi4xLjMiDQogICAgOjo9IHsgbWVmU2VydmljZUV2Y0Nm Z0VudHJ5IDMgfQ0KDQptZWZTZXJ2aWNlRXZjQ2ZnTXR1U2l6ZSBPQkpFQ1QtVFlQRQ0KICAg IFNZTlRBWCAgICAgIFVuc2lnbmVkMzIgKDE1MjIuLjE2Mzg0KQ0KICAgIE1BWC1BQ0NFU1Mg IHJlYWQtd3JpdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04N CiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBjb25maWd1cmVkIEVWQyBtYXhp bXVtIHNlcnZpY2UgZnJhbWUgZm9ybWF0DQogICAgICAgIHNpemUuIEl0IG11c3QgYmUgbGVz cyB0aGFuIG9yIGVxdWFsIHRvIHRoZQ0KICAgICAgICBtZWZTZXJ2aWNlRXZjU3RhdHVzTWF4 TXR1U2l6ZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2 LjE7IFtNRUYgNy4yXSA2LjIuMS4zIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNDZmdFbnRy eSA0IH0NCg0KbWVmU2VydmljZUV2Y0NmZ0NldmxhbklkUHJlc2VydmF0aW9uIE9CSkVDVC1U WVBFDQogICAgU1lOVEFYICAgICAgSU5URUdFUiB7DQogICAgICAgIHByZXNlcnZlICAgICAg ICAgICAgICAoMSksDQogICAgICAgIG5vUHJlc2VydmUgICAgICAgICAgICAoMikNCiAgICB9 DQogICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgIkNvbmZpZ3VyZXMgdGhlIEVWQyBDRS1WTEFO IElEIHByZXNlcnZhdGlvbi4NCg0KICAgICAgICBwcmVzZXJ2ZSgxKSAgICAgICAgICAgVGhl IENFLVZMQU4gSUQgaXMgcHJlc2VydmVkLiBUaGUgaW5ncmVzcyBDRS1WTEFODQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBpcyB0aGUgQ0UtVkxBTiBJRCBhdCB0aGUgZWdyZXNz IFVOSQ0KICAgICAgICBub1ByZXNlcnZlKDIpICAgICAgICAgVGhlIENFLVZMQU4gSUQgaXMg bm90IHByZXNlcnZlZC4gVGhlIGluZ3Jlc3MgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBDRS1WTEFOIElEIG1heSBub3QgYmUgdGhlIENFLVZMQU4gSUQgYXQgdGhlIGVncmVz cyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVOSQ0KICAgICAgICAiDQogICAg UkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjE7IFtNRUYgNy4yXSA2LjIuMS4zIg0K ICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNDZmdFbnRyeSA1IH0NCg0KbWVmU2VydmljZUV2Y0Nm Z0NldmxhbkNvc1ByZXNlcnZhdGlvbiBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElO VEVHRVIgew0KICAgICAgICBwcmVzZXJ2ZSAgICAgICAgICAgICAgKDEpLA0KICAgICAgICBu b1ByZXNlcnZlICAgICAgICAgICAgKDIpDQogICAgfQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQt Y3JlYXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAg ICAgICJDb25maWd1cmVzIEVWQyBDRS1WTEFOIENvUyBwcmVzZXJ2YXRpb24uDQoNCiAgICAg ICAgcHJlc2VydmUoMSkgICAgICAgICAgIFRoZSBDRS1WTEFOIENvUyBpcyBwcmVzZXJ2ZWQu IFRoZSBpbmdyZXNzIENFLVZMQU4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENP UyBpcyB0aGUgQ0UtVkxBTiBDb1MgYXQgdGhlIGVncmVzcyBVTkkNCiAgICAgICAgbm9QcmVz ZXJ2ZSgyKSAgICAgICAgIFRoZSBDRS1WTEFOIENvUyBpcyBub3QgcHJlc2VydmVkLiBUaGUg aW5ncmVzcyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENFLVZMQU4gQ29TIG1h eSBub3QgdGhlIENFLVZMQU4gQ29TIGF0IHRoZSBlZ3Jlc3MNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFVOSQ0KICAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltN RUYgNi4xXSA2LjE7IFtNRUYgNy4yXSA2LjIuMS4zIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VF dmNDZmdFbnRyeSA2IH0NCg0KbWVmU2VydmljZUV2Y0NmZ1VuaWNhc3REZWxpdmVyeSBPQkpF Q1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICBkaXNjYXJkICAg ICAgICAgICAgICAgKDEpLA0KICAgICAgICB1bmNvbmRpdGlvbmFsICAgICAgICAgKDIpLA0K ICAgICAgICBjb25kaXRpb25hbCAgICAgICAgICAgKDMpDQogICAgfQ0KICAgIE1BWC1BQ0NF U1MgIHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBU SU9ODQogICAgICAgICJDb25maWd1cmVzIEVWQyBVbmljYXN0IGRlbGl2ZXJ5IGNvbmRpdGlv bi4NCg0KICAgICAgICBkaXNjYXJkKDEpICAgICAgICAgICAgVW5pY2FzdCBTZXJ2aWNlIEZy YW1lcyBhcmUgZGlzY2FyZGVkDQogICAgICAgIHVuY29uZGl0aW9uYWwoMikgICAgICBVbmlj YXN0IFNlcnZpY2UgRnJhbWVzIGFyZSB1bmNvbmRpdGlvbmFsbHkNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGRlbGl2ZXJlZCBubyBtYXR0ZXIgdGhlIGNvbnRlbnQgb2YgdGhl IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmljZSBGcmFtZS4gQW4gZXhh bXBsZSBvZiB0aGlzIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIFBvaW50 LXRvLVBvaW50IEVWQw0KICAgICAgICBjb25kaXRpb25hbCgzKSAgICAgICAgVW5pY2FzdCBT ZXJ2aWNlIEZyYW1lIGFyZSBjb25kaXRpb25hbGx5IA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZGVsaXZlcmVkIHRvIHRoZSBkZXN0aW5hdGlvbiBVTkkuIFRoZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY29uZGl0aW9uIGlzIHNwZWNpZmllZCwgZm9yIGV4 YW1wbGUgdmlhIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhbmR3aWR0aCBw cm9maWxlIG9yIE1BQyBhZGRyZXNzIGxlYXJuaW5nLg0KICAgICAgICAiDQogICAgUkVGRVJF TkNFDQogICAgICAgIltNRUYgNi4xXSA2LjE7IFtNRUYgNy4yXSA2LjIuMS4zIg0KICAgIDo6 PSB7IG1lZlNlcnZpY2VFdmNDZmdFbnRyeSA3IH0NCg0KbWVmU2VydmljZUV2Y0NmZ011bHRp Y2FzdERlbGl2ZXJ5IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgSU5URUdFUiB7DQog ICAgICAgIGRpc2NhcmQgICAgICAgICAgICAgICAoMSksDQogICAgICAgIHVuY29uZGl0aW9u YWwgICAgICAgICAoMiksDQogICAgICAgIGNvbmRpdGlvbmFsICAgICAgICAgICAoMykNCiAg ICB9DQogICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgIkNvbmZpZ3VyZXMgRVZDIE11bHRpY2Fz dCBkZWxpdmVyeSBjb25kaXRpb24uDQoNCiAgICAgICAgZGlzY2FyZCgxKSAgICAgICAgICAg IE11bHRpY2FzdCBTZXJ2aWNlIEZyYW1lcyBhcmUgZGlzY2FyZGVkDQogICAgICAgIHVuY29u ZGl0aW9uYWwoMikgICAgICBNdWx0aWNhc3QgU2VydmljZSBGcmFtZXMgYXJlIHVuY29uZGl0 aW9uYWxseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVsaXZlcmVkIG5vIG1h dHRlciB0aGUgY29udGVudCBvZiB0aGUgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTZXJ2aWNlIEZyYW1lLiBBbiBleGFtcGxlIG9mIHRoaXMgaXMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGEgUG9pbnQtdG8tUG9pbnQgRVZDDQogICAgICAgIGNvbmRpdGlv bmFsKDMpICAgICAgICBNdWx0aWNhc3QgU2VydmljZSBGcmFtZSBhcmUgY29uZGl0aW9uYWxs eSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlbGl2ZXJlZCB0byB0aGUgZGVz dGluYXRpb24gVU5JLiBUaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbmRp dGlvbiBpcyBzcGVjaWZpZWQsIGZvciBleGFtcGxlIGlhIGEgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBiYW5kd2lkdGggcHJvZmlsZSBvciBNQUMgYWRkcmVzcyBsZWFybmlu Zy4NCiAgICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0gNi4xOyBb TUVGIDcuMl0gNi4yLjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZjQ2ZnRW50cnkgOCB9 DQoNCm1lZlNlcnZpY2VFdmNDZmdCcm9hZGNhc3REZWxpdmVyeSBPQkpFQ1QtVFlQRQ0KICAg IFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICBkaXNjYXJkICAgICAgICAgICAgICAg KDEpLA0KICAgICAgICB1bmNvbmRpdGlvbmFsICAgICAgICAgKDIpLA0KICAgICAgICBjb25k aXRpb25hbCAgICAgICAgICAgKDMpDQogICAgfQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3Jl YXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAg ICJDb25maWd1cmVzIEVWQyBCcm9hZGNhc3QgZGVsaXZlcnkgY29uZGl0aW9uLg0KDQogICAg ICAgIGRpc2NhcmQoMSkgICAgICAgICAgICBCcm9hZGNhc3QgU2VydmljZSBGcmFtZXMgYXJl IGRpc2NhcmRlZA0KICAgICAgICB1bmNvbmRpdGlvbmFsKDIpICAgICAgQnJvYWRjYXN0IFNl cnZpY2UgRnJhbWVzIGFyZSB1bmNvbmRpdGlvbmFsbHkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGRlbGl2ZXJlZCBubyBtYXR0ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmljZSBGcmFtZS4gQW4gZXhhbXBsZSBv ZiB0aGlzIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIFBvaW50LXRvLVBv aW50IEVWQw0KICAgICAgICBjb25kaXRpb25hbCgzKSAgICAgICAgQnJvYWRjYXN0IFNlcnZp Y2UgRnJhbWUgYXJlIGNvbmRpdGlvbmFsbHkgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBkZWxpdmVyZWQgdG8gdGhlIGRlc3RpbmF0aW9uIFVOSS4gVGhlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25kaXRpb24gaXMgc3BlY2lmaWVkLCBmb3IgZXhhbXBs ZSBpYSBhIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFuZHdpZHRoIHByb2Zp bGUgb3IgTUFDIGFkZHJlc3MgbGVhcm5pbmcuDQogICAgICAgICINCiAgICBSRUZFUkVOQ0UN CiAgICAgICAiW01FRiA2LjFdIDYuMTsgW01FRiA3LjJdIDYuMi4xLjMiDQogICAgOjo9IHsg bWVmU2VydmljZUV2Y0NmZ0VudHJ5IDkgfQ0KDQptZWZTZXJ2aWNlRXZjQ2ZnTDJjcEluZGV4 IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NF U1MgIHJlYWQtd3JpdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAiVGhpcyBvYmplY3QgaXMgdGhlIGluZGV4IG9mIHRoZSBMMkNQIHByb2Zp bGUgKG1lZlNlcnZpY2VMMmNwQ2ZnSW5kZXgpDQogICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0 aGUgY3VycmVudCBFVkMgb24gYW4gaW50ZXJmYWNlLiBBIHZhbHVlIG9mIDANCiAgICAgICAg aW5kaWNhdGVzIHRoYXQgbm8gRVZDIEwyQ1AgcHJvZmlsZSBpcyBhc3NvY2lhdGVkIHdpdGgg dGhlDQogICAgICAgIEVWQy4NCg0KICAgICAgICBUaGlzIGluZGV4IGluZGljYXRlcyBhIHNw ZWNpZmljIEwyQ1AgcHJvZmlsZSBwcmV2aW91c2x5IGNvbmZpZ3VyZWQgdmlhDQogICAgICAg IG1lZlNlcnZpY2VMMmNwQ2ZnVGFibGUuIEluZGl2aWR1YWwgTDJDUCBwcm90b2NscyBwcm9m aWxlcyB1c2luZyB0aGlzDQogICAgICAgIG9uZSBpbmRleCBwb2ludCB0byB0aGUgbWVmU2Vy dmljZUwyY3BDZmdJdGVtVGFibGUuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAg ICJbTUVGIDYuMV0gNi4xOyBbTUVGIDYuMS4xXSA4LjA7IFtNRUYgNy4yXSA2LjIuMS4zIg0K ICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNDZmdFbnRyeSAxMCB9DQoNCm1lZlNlcnZpY2VFdmND ZmdBZG1pblN0YXRlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgRW50aXR5QWRtaW5T dGF0ZQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgICAgY3Vy cmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgYXR0cmlidXRlIHNwZWNpZmll cyB0aGUgYWRtaW5pc3RyYXRpdmUgc3RhdGUgb2YgdGhlIEVWQy4NCg0KICAgICAgICBJZiBt ZWZTZXJ2aWNlRXZjQ2ZnQWRtaW5TdGF0ZSBpcyBzZXQgdG8gJ2xvY2tlZCcsIHRoZSBFVkMg d2lsbCBiZQ0KICAgICAgICBhZG1pbmlzdHJhdGl2ZWx5IGxvY2tlZC4NCg0KICAgICAgICBJ ZiBtZWZTZXJ2aWNlRXZjQ2ZnQWRtaW5TdGF0ZSBpcyBzZXQgdG8gJ3VubG9ja2VkJywgdGhl IEVWQyB3aWxsIGJlDQogICAgICAgIGFkbWluaXN0cmF0aXZlbHkgdW5sb2NrZWQgaWYgcHJl dmlvdXNseSBsb2NrZWQuDQoNCiAgICAgICAgT3RoZXIgdmFsdWVzIG9mIG1lZlNlcnZpY2VF dmNDZmdBZG1pblN0YXRlIGFyZSB1bmRlZmluZWQuDQogICAgICAgIg0KICAgIFJFRkVSRU5D RQ0KICAgICAgICJbTUVGIDcuMl0gNi4yLjEuMyINCiAgICBERUZWQUwgeyB1bmxvY2tlZCB9 DQogICAgOjo9IHsgbWVmU2VydmljZUV2Y0NmZ0VudHJ5IDExIH0NCg0KbWVmU2VydmljZUV2 Y0NmZ1Jvd1N0YXR1cyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFJvd1N0YXR1cw0K ICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0K ICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoZSBzdGF0dXMgb2YgdGhlIHJvdy4NCg0KICAg ICAgICBUaGUgd3JpdGFibGUgY29sdW1ucyBpbiBhIHJvdyBjYW5ub3QgYmUgY2hhbmdlZCBp ZiB0aGUgcm93DQogICAgICAgIGlzIGFjdGl2ZS4gQWxsIGNvbHVtbnMgbXVzdCBoYXZlIGEg dmFsaWQgdmFsdWUgYmVmb3JlIGEgcm93DQogICAgICAgIGNhbiBiZSBhY3RpdmF0ZWQuDQog ICAgICAgIg0KICAgOjo9IHsgbWVmU2VydmljZUV2Y0NmZ0VudHJ5IDEyIH0NCg0KDQotLSAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KLS0gRXRoZXJuZXQgVU5JcyBvbiBhIEVWQyBDb25m aWd1cmF0aW9uDQotLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQptZWZTZXJ2aWNlRXZj VW5pQ2ZnVGFibGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBTRVFVRU5DRSBPRiBN ZWZTZXJ2aWNlRXZjVW5pQ2ZnRW50cnkNCiAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJs ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJU aGlzIHRhYmxlIHJlcHJlc2VudHMgdGhlIHNwZWNpZmljIEVWQyBhdHRyaWJ1dGVzIGNvbmZp Z3VyYXRpb24gdGFibGUNCiAgICAgICAgZm9yIGFuIE1FRiBFdGhlcm5ldCBjb21wbGlhbnQg TkUuIFRoZSBwcmltYXJ5IHB1cnBvc2Ugb2YgdGhpcyB0YWJsZQ0KICAgICAgICBpcyB0byBw cm92aWRlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIEVWQyBmb3IgYSBNRUYgTkUgYXQgZWFjaCBN RUYNCiAgICAgICAgY29tcGxpYW50IGludGVyZmFjZS4NCg0KICAgICAgICBSb3dzIGluIHRo ZSB0YWJsZSBjYW4gb25seSBiZSBjcmVhdGVkIGFmdGVyIHRoZSBFVkMgaXMgY3JlYXRlZC4g DQogICAgICAgIEludGVyZmFjZXMgYXJlIGFkZGVkIHRvIHRoZSBFVkMgYW5kIGFyZSBzZWxl Y3RlZCBhcyBlaXRoZXIgYSB0eXBlICdyb290Jw0KICAgICAgICBvciAnbGVhZicgYnkgdGhl IGNyZWF0aW9uIG9mIHRoZSByb3cgYXMgYWRkcmVzc2VkIGJ5IA0KICAgICAgICBtZWZTZXJ2 aWNlRXZjQ2ZnSW5kZXggYW5kIGlmSW5kZXguDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0K ICAgICAgICJbTUVGIDYuMV0sIFtNRUYgNy4yXSwgW01FRiAxMC4yXSwgW1EuODQwLjFdIg0K ICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNBdHRyaWJ1dGVzIDMgfQ0KDQptZWZTZXJ2aWNlRXZj VW5pQ2ZnRW50cnkgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBNZWZTZXJ2aWNlRXZj VW5pQ2ZnRW50cnkNCiAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZQ0KICAgIFNUQVRV UyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGUgY29uY2VwdHVh bCByb3cgb2YgbWVmU2VydmljZUV2Y1VuaUNmZ1RhYmxlLiINCiAgICBJTkRFWCB7IG1lZlNl cnZpY2VFdmNDZmdJbmRleCwgaWZJbmRleCB9DQogICAgOjo9IHsgbWVmU2VydmljZUV2Y1Vu aUNmZ1RhYmxlIDEgfQ0KDQpNZWZTZXJ2aWNlRXZjVW5pQ2ZnRW50cnkgOjo9IFNFUVVFTkNF IHsNCiAgICAgIG1lZlNlcnZpY2VFdmNVbmlDZmdUeXBlICAgICAgICAgICAgICAgSU5URUdF Ug0KICAgIH0NCg0KbWVmU2VydmljZUV2Y1VuaUNmZ1R5cGUgT0JKRUNULVRZUEUNCiAgICBT WU5UQVggICAgICBJTlRFR0VSIHsNCiAgICAgICAgcm9vdCAgICAgICAgICAgICAgICAgICgx KSwNCiAgICAgICAgbGVhZiAgICAgICAgICAgICAgICAgICgyKSwNCiAgICAgICAgdW5rbm93 biAgICAgICAgICAgICAgICgzKQ0KICAgIH0NCiAgICBNQVgtQUNDRVNTICByZWFkLXdyaXRl DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICJD b25maWd1cmVzIFVOSSB0eXBlIG9uIGFuIEVWQy4NCg0KICAgICAgICByb290KDEpICAgICAg ICAgICAgVmFsaWQgc2V0dGluZyBmb3IgYWxsIHNlcnZpY2UgdHlwZXMuIEEgVU5JIHNldA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gdGhpcyB2YWx1ZSBtYXkgc2VuZCBmcmFt ZXMgdG8gVU5JcyBjb25maWd1cmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICBhcyAn cm9vdCcgb3IgJ2xlYWYnDQogICAgICAgIGxlYWYoMikgICAgICAgICAgICBWYWxpZCBzZXR0 aW5nIGZvciBSb290LU11bHRpcG9pbnQgRVZDcyBvbmx5LiBBDQogICAgICAgICAgICAgICAg ICAgICAgICAgICBVTkkgc2V0IHRvIHRoaXMgdmFsdWUgbWF5IHNlbmQgZnJhbWVzIHRvIFVO SXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICdyb290Jw0KICAgICAgICB1bmtub3du KDMpICAgICAgICAgVU5JIHBvcnQgaXMgbm90IGNvbmZpZ3VyZWQgb3IgaWxsZWdhbGx5DQog ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25maWd1cmVkDQogICAgICAgICINCiAgICBS RUZFUkVOQ0UNCiAgICAgICAiW01FRiAxMC4yXSINCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZj VW5pQ2ZnRW50cnkgMSB9DQoNCg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCi0tIEV0 aGVybmV0IFNlcnZpY2UgRVZDIFN0YXR1cw0KLS0gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cg0KbWVmU2VydmljZUV2Y1N0YXR1c1RhYmxlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAg ICAgU0VRVUVOQ0UgT0YgTWVmU2VydmljZUV2Y1N0YXR1c0VudHJ5DQogICAgTUFYLUFDQ0VT UyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJ UFRJT04NCiAgICAgICAiVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBFVkMgc3RhdHVzIHRh YmxlIGZvciBhbg0KICAgICAgICBNRUYgRXRoZXJuZXQgY29tcGxpYW50IE5FLiBUaGUgcHJp bWFyeSBwdXJwb3NlIG9mIHRoaXMgdGFibGUgaXMgdG8NCiAgICAgICAgcHJvdmlkZSBzdGF0 dXMgaW5mb3JtYXRpb24gb2YgdGhlIEVWQyBmb3IgYSBNRUYgTkUuIFJvd3MgYXJlDQogICAg ICAgIGF1dG9tYXRpY2FsbHkgY3JlYXRlZCBpbiB0aGUgdGFibGUgYmFzZWQgdXBvbiB0aGUg RVZDcyB0aGF0IGEgTUVGDQogICAgICAgIE5FIGNvbnRhaW5zLg0KICAgICAgICINCiAgICBS RUZFUkVOQ0UNCiAgICAgICAiW01FRiAxMC4yXSINCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZj QXR0cmlidXRlcyA0IH0NCg0KbWVmU2VydmljZUV2Y1N0YXR1c0VudHJ5IE9CSkVDVC1UWVBF DQogICAgU1lOVEFYICAgICAgTWVmU2VydmljZUV2Y1N0YXR1c0VudHJ5DQogICAgTUFYLUFD Q0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVT Q1JJUFRJT04NCiAgICAgICAiVGhlIGNvbmNlcHR1YWwgcm93IG9mIG1lZlNlcnZpY2VJbnRl cmZhY2VTdGF0dXNUYWJsZS4iDQogICAgSU5ERVggeyBtZWZTZXJ2aWNlRXZjQ2ZnSW5kZXgg fQ0KICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNTdGF0dXNUYWJsZSAxIH0NCg0KTWVmU2Vydmlj ZUV2Y1N0YXR1c0VudHJ5IDo6PSBTRVFVRU5DRSB7DQogICAgICBtZWZTZXJ2aWNlRXZjU3Rh dHVzTWF4TXR1U2l6ZSAgICAgICAgIFVuc2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNlRXZj U3RhdHVzTWF4TnVtVW5pICAgICAgICAgIFVuc2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNl RXZjU3RhdHVzT3BlcmF0aW9uYWxTdGF0ZSAgIElOVEVHRVINCiAgICB9DQoNCm1lZlNlcnZp Y2VFdmNTdGF0dXNNYXhNdHVTaXplIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgVW5z aWduZWQzMiAoMTUyMi4uMTYzODQpDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAg U1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2Jq ZWN0IGluZGljYXRlcyB0aGUgRVZDIG1heGltdW0gY29uZmlndXJhYmxlIHNlcnZpY2UNCiAg ICAgICAgZnJhbWUgZm9ybWF0IHNpemUuIFRoZSBhY3R1YWwgY29uZmlndXJlZCBzaXplIGlz IHNldCB2aWEgdGhlDQogICAgICAgIG1lZlNlcnZpY2VFdmNDZmdNdHVTaXplIG9iamVjdC4N CiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjE7IFtNRUYg Ny4yXSA2LjIuMS4zIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNTdGF0dXNFbnRyeSAxIH0N Cg0KbWVmU2VydmljZUV2Y1N0YXR1c01heE51bVVuaSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRB WCAgICAgIFVuc2lnbmVkMzIgKDIuLjE2Mzg0KQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJU aGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhlIG1heGltdW0gbnVtYmVyIG9mIFVOSXMgaW4gYW4g RVZDLiBGb3INCiAgICAgICAgYSBQb2ludC10by1Qb2ludCBFVkMgdGhpcyB2YWx1ZSBpcyAn MicuIEZvciBhIE11bHRpcG9pbnQgRVZDIHRoZSANCiAgICAgICAgdmFsdWUgY2FuIGJlICcy JyBvciBncmVhdGVyLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2 LjFdIDYuMTsgW01FRiA3LjJdIDYuMi4xLjMiDQogICAgOjo9IHsgbWVmU2VydmljZUV2Y1N0 YXR1c0VudHJ5IDIgfQ0KDQptZWZTZXJ2aWNlRXZjU3RhdHVzT3BlcmF0aW9uYWxTdGF0ZSBP QkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIEVudGl0eU9wZXJTdGF0ZQ0KICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQ VElPTg0KICAgICAgICJUaGlzIGF0dHJpYnV0ZSBpbmRpY2F0ZXMgdGhlIG9wZXJhdGlvbmFs IHN0YXRlIChjdXJyZW50DQogICAgICAgIGNhcGFiaWxpdHkpIG9mIHRoZSBFVkMuDQoNCiAg ICAgICAgSWYgdGhlIHZhbHVlIGlzICdlbmFibGVkJywgdGhlIEVWQyBpcyBhYmxlIHRvIGlu Z3Jlc3MgYW5kDQogICAgICAgIGVncmVzcyBzZXJ2aWNlIGZyYW1lcyBhbmQgaGFzIGJlZW4g c2V0IHRvIGFjdGl2ZS4NCg0KICAgICAgICBJZiB0aGUgdmFsdWUgaXMgJ2Rpc2FibGVkJyB0 aGUgRVZDIGlzIG5vdCBhYmxlIHRvIGluZ3Jlc3MgYW5kDQogICAgICAgIGVncmVzcyBzZXJ2 aWNlIGZyYW1lcywgaGFzIGRldGVjdGVkIGFuIG9wZXJhdGlvbmFsIGZhaWx1cmUNCiAgICAg ICAgY29uZGl0aW9uLCBvciBoYXMgZmFpbGVkIGFuIGludGVybmFsIHRlc3QuDQoNCiAgICAg ICAgSWYgdGhlIHZhbHVlIGlzICd0ZXN0aW5nJyB0aGUgRVZDIGhhcyBiZWVuIHBsYWNlZCBp bnRvIGEgdGVzdCBtb2RlLA0KICAgICAgICBlaXRoZXIgYSB0cm91Ymxlc2hvb3RpbmcgbW9k ZSBvciBhIHRlc3QgbW9kZS4NCg0KICAgICAgICBJZiB0aGUgdmFsdWUgaXMgJ3Vua25vd24n IHRoZSBFVkMgaXMgdW5hYmxlIHRvIHJlcG9ydCB0aGUgb3BlcmF0aW9uYWwNCiAgICAgICAg c3RhdGUuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDcuMl0gNi4y LjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZjU3RhdHVzRW50cnkgMyB9DQoNCg0KLS0g KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCi0tIEV0aGVybmV0IEVWQyBwZXIgVU5JIEF0dHJp YnV0ZXMgQ29uZmlndXJhdGlvbg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KbWVm U2VydmljZUV2Y1BlclVuaUNmZ1RhYmxlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAg U0VRVUVOQ0UgT0YgTWVmU2VydmljZUV2Y1BlclVuaUNmZ0VudHJ5DQogICAgTUFYLUFDQ0VT UyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJ UFRJT04NCiAgICAgICAiVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBzcGVjaWZpYyBFVkMg cGVyIFVOSSBhdHRyaWJ1dGVzIGNvbmZpZ3VyYXRpb24NCiAgICAgICAgdGFibGUgZm9yIGFu IE1FRiBFdGhlcm5ldCBjb21wbGlhbnQgTkUuIFRoZSBwcmltYXJ5IHB1cnBvc2Ugb2YgdGhp cyB0YWJsZQ0KICAgICAgICBpcyB0byBwcm92aWRlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIEVW QyBwZXIgVU5JIGF0dHJpYnV0ZXMgZm9yIGEgTUVGDQogICAgICAgIE5FLiBSb3dzIGFyZSBh dXRvbWF0aWNhbGx5IGNyZWF0ZWQgaW4gdGhlIHRhYmxlIHdpdGggdGhlIGluZGljYXRlZA0K ICAgICAgICBkZWZhdWx0IHZhbHVlcyB3aGVuIGFuIGludGVyZmFjZSBpcyBhZGRlZCB0byB0 aGUgRVZDIHZpYSB0aGUgDQogICAgICAgIG1lZlNlcnZpY2VFdmNVbmlDZmdUeXBlIG9iamVj dC4gUm93cyBhcmUgYWNjZXNzZWQgdmlhIHRoZSBpZkluZGV4IGFuZA0KICAgICAgICBtZWZT ZXJ2aWNlRXZjQ2ZnSW5kZXguDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJb TUVGIDYuMV0gNi4xOyBbTUVGIDcuMl0gNi4yLjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNl VW5pQXR0cmlidXRlcyAyIH0NCg0KbWVmU2VydmljZUV2Y1BlclVuaUNmZ0VudHJ5IE9CSkVD VC1UWVBFDQogICAgU1lOVEFYICAgICAgTWVmU2VydmljZUV2Y1BlclVuaUNmZ0VudHJ5DQog ICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhlIGNvbmNlcHR1YWwgcm93IG9mIG1lZlNl cnZpY2VVbmlDZmdUYWJsZS4NCiAgICAgICAiDQogICAgSU5ERVggeyBpZkluZGV4LCBtZWZT ZXJ2aWNlRXZjQ2ZnSW5kZXggfQ0KICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNQZXJVbmlDZmdU YWJsZSAxIH0NCg0KTWVmU2VydmljZUV2Y1BlclVuaUNmZ0VudHJ5IDo6PSBTRVFVRU5DRSB7 DQogICAgIG1lZlNlcnZpY2VFdmNQZXJVbmlDZmdTZXJ2aWNlVHlwZSAgICAgICAgICBJTlRF R0VSLA0KICAgICBtZWZTZXJ2aWNlRXZjUGVyVW5pQ2ZnSWRlbnRpZmllciAgICAgICAgICAg RGlzcGxheVN0cmluZywNCiAgICAgbWVmU2VydmljZUV2Y1BlclVuaUNmZ0NlVmxhbk1hcCAg ICAgICAgICAgIE1lZlNlcnZpY2VMaXN0VHlwZSwNCiAgICAgbWVmU2VydmljZUV2Y1BlclVu aUNmZ0luZ3Jlc3NCd3BJbmRleCAgICAgIFVuc2lnbmVkMzIsDQogICAgIG1lZlNlcnZpY2VF dmNQZXJVbmlDZmdJbmdyZXNzQ29zSW5kZXggICAgICBVbnNpZ25lZDMyLA0KICAgICBtZWZT ZXJ2aWNlRXZjUGVyVW5pQ2ZnRWdyZXNzQndwSW5kZXggICAgICAgVW5zaWduZWQzMiwNCiAg ICAgbWVmU2VydmljZUV2Y1BlclVuaUNmZ0VncmVzc0Nvc0luZGV4ICAgICAgIFVuc2lnbmVk MzINCiAgICB9DQoNCm1lZlNlcnZpY2VFdmNQZXJVbmlDZmdTZXJ2aWNlVHlwZSBPQkpFQ1Qt VFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICBlcGwgICAgICAgICAg ICAgKDEpLA0KICAgICAgICBldnBsICAgICAgICAgICAgKDIpLA0KICAgICAgICBlcGxhbiAg ICAgICAgICAgKDMpLA0KICAgICAgICBldnBsYW4gICAgICAgICAgKDQpLA0KICAgICAgICBl cHRyZWUgICAgICAgICAgKDUpLA0KICAgICAgICBldnB0cmVlICAgICAgICAgKDYpDQogICAg fQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQN CiAgICBERVNDUklQVElPTg0KICAgICAgICAiSW5kaWNhdGVzIHRoZSBzcGVjaWZpYyBFdGhl cm5ldCBzZXJ2aWNlIHR5cGUgVGhpcyB2YWx1ZSBpcyANCiAgICAgICAgIGRlcml2ZWQgZnJv bSB0aGUgRVZDIG9iamVjdCAnbWVmU2VydmljZUV2Y0NmZ1R5cGUnIGFuZCB0aGUgVU5JIG9i amVjdA0KICAgICAgICAgJ21lZlNlcnZpY2VVbmlDZmdCdW5kbGluZ011bHRpcGxleCcuIA0K DQogICAgICAgICBlcGwoMSkgICAgICBFdGhlcm5ldCBQcml2YXRlIExpbmUgU2VydmljZSAo RVBMKQ0KICAgICAgICAgICAgICAgICAgICAgUG9pbnQtdG8tUG9pbnQgRVZDLCBhbGwgdG8g b25lIGJ1bmRsaW5nDQoNCiAgICAgICAgIGV2cGwoMikgICAgIEV0aGVybmV0IFZpcnR1YWwg UHJpdmF0ZSBMaW5lIChFVlBMKQ0KICAgICAgICAgICAgICAgICAgICAgUG9pbnQtdG8tUG9p bnQgRVZDLCBidW5kbGluZyBhbmQvb3IgbXVsdGlwbGV4aW5nDQoNCiAgICAgICAgIGVwbGFu KDMpICAgIEV0aGVybmV0IFByaXZhdGUgTEFOIFNlcnZpY2UgKEVQLUxBTikNCiAgICAgICAg ICAgICAgICAgICAgIE11bHRpcG9pbnQtdG8tTXVsdGlwb2ludCBFVkMsIGFsbCB0byBvbmUg YnVuZGxpbmcNCg0KICAgICAgICAgZXZwbGFuKDQpICAgRXRoZXJuZXQgVmlydHVhbCBQcml2 YXRlIExBTiBTZXJ2aWNlIChFVlAtTEFOKQ0KICAgICAgICAgICAgICAgICAgICAgTXVsdGlw b2ludC10by1NdWx0aXBvaW50IEVWQywgYnVuZGxpbmcgYW5kL29yIG11bHRpcGxleGluZw0K DQogICAgICAgICBlcHRyZWUoNSkgICBFdGhlcm5ldCBQcml2YXRlIFRyZWUgU2VydmljZSAo RVAtVHJlZSkNCiAgICAgICAgICAgICAgICAgICAgIFJvb3RlZC1NdWx0aXBvaW50IEVWQywg YWxsIHRvIG9uZSBidW5kbGluZw0KDQogICAgICAgICBldnB0cmVlKDYpICBFdGhlcm5ldCBW aXJ0dWFsIFByaXZhdGUgVHJlZSBTZXJ2aWNlIChFVlAtVHJlZSkNCiAgICAgICAgICAgICAg ICAgICAgIFJvb3RlZC1NdWx0aXBvaW50IEVWQywgYnVuZGxpbmcgYW5kL29yIG11bHRpcGxl eGluZw0KICAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjE7 IFtNRUYgNy4yXSA2LjIuMS4zIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VFdmNQZXJVbmlDZmdF bnRyeSAxIH0NCg0KbWVmU2VydmljZUV2Y1BlclVuaUNmZ0lkZW50aWZpZXIgT0JKRUNULVRZ UEUNCiAgICBTWU5UQVggICAgICBEaXNwbGF5U3RyaW5nIChTSVpFKDAuLjkwKSkNCiAgICBN QVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVT Q1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBjb25jYXRlbmF0 ZWQgRVZDLVVOSSBpZGVudGlmaWVyLiBJdCBpcw0KICAgICAgICBUaGUgY29uY2F0ZW5hdGlv biBvZiB0aGUgbWVmU2VydmljZVVuaUNmZ0lkZW50aWZpZXIgYW5kIHRoZQ0KICAgICAgICBt ZWZTZXJ2aWNlRXZjQ2ZnSWRlbnRpZmllci4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQog ICAgICAgIltNRUYgNi4xXSA2LjE7IFtNRUYgNy4yXSA2LjIuMS4zIg0KICAgOjo9IHsgbWVm U2VydmljZUV2Y1BlclVuaUNmZ0VudHJ5IDIgfQ0KDQptZWZTZXJ2aWNlRXZjUGVyVW5pQ2Zn Q2VWbGFuTWFwIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgTWVmU2VydmljZUxpc3RU eXBlDQogICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhl IENFLVZMQU5zIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3BlY2lmaWMNCiAgICAgICAgRVZDIG9u IGEgVU5JLiBDRS1WTEFOIElEcyBoYXZlIHZhbHVlIG9mIDAgdG8gNDA5NS4gVGhlIENFLVZM QU4gSUQNCiAgICAgICAgbGlzdCBjYW4gYmUgYSBzaW5nbGUgdmFsdWUgb3IgbXVsdGlwbGUg dmFsdWVzIHNlcGFyYXRlZCBieSBhIGRlbGltZXRlci4NCg0KICAgICAgICBTb21lIHZhbGlk IHZhbHVlcyBhcmU6ICcxMDAnLCAnMToxMCcsICcxMCwyMCwzMCcsICcxOjQwOTUnDQogICAg ICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0gNi4xOyBbTUVGIDcuMl0g Ni4yLjEuMyINCiAgICBERUZWQUwgeyAiMTo0MDk1IiB9ICAgIA0KIDo6PSB7IG1lZlNlcnZp Y2VFdmNQZXJVbmlDZmdFbnRyeSAzIH0NCg0KbWVmU2VydmljZUV2Y1BlclVuaUNmZ0luZ3Jl c3NCd3BJbmRleCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFVuc2lnbmVkMzINCiAg ICBNQVgtQUNDRVNTICByZWFkLXdyaXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg IERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGlzIHRoZSBpbmRleCBudW1iZXIg b2YgdGhlIGluZ3Jlc3MgYmFuZHdpZHRoIHByb2ZpbGUNCiAgICAgICAgYXNzb2NpYXRlZCB3 aXRoIHRoZSBjdXJyZW50IEVWQyBvbiBhIFVOSS4gQSB2YWx1ZSBvZiAwIGluZGljYXRlcyB0 aGF0DQogICAgICAgIG5vIGluZ3Jlc3MgYmFuZHdpdGggcHJvZmlsZSBpcyBhc3NvY2lhdGVk IHdpdGggdGhlIEVWQyBvbiBhIFVOSS4NCg0KICAgICAgICBUaGlzIGluZGV4IGluZGljYXRl cyBhIHNwZWNpZmljIHByb2ZpbGUgcHJldmlvdXNseSBjb25maWd1cmVkIHZpYQ0KICAgICAg ICBtZWZTZXJ2aWNlQndwQ2ZnVGFibGUuIE11bHRpcGxlIENvUyBiYW5kd2lkdGggcHJvZmls ZXMgdXNpbmcgdGhpcw0KICAgICAgICBvbmUgaW5kZXggcG9pbnQgdG8gdGhlIG1lZlNlcnZp Y2VCd3BDZmdJdGVtVGFibGUuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJb TUVGIDYuMV0gNi4xOyBbTUVGIDcuMl0gNi4yLjEuMyINCiAgICBERUZWQUwgeyAwIH0gIA0K ICAgOjo9IHsgbWVmU2VydmljZUV2Y1BlclVuaUNmZ0VudHJ5IDQgfQ0KDQptZWZTZXJ2aWNl RXZjUGVyVW5pQ2ZnSW5ncmVzc0Nvc0luZGV4IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAg ICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUNCiAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaXMg dGhlIGluZGV4IG51bWJlciBvZiB0aGUgaW5ncmVzcyBDb1MgcHJvZmlsZQ0KICAgICAgICBh c3NvY2lhdGVkIHdpdGggdGhlIGN1cnJlbnQgRVZDIG9uIGEgVU5JLiBBIHZhbHVlIG9mIDAg aW5kaWNhdGVzIHRoYXQNCiAgICAgICAgbm8gaW5ncmVzcyBDb1MgcHJvZmlsZSBpcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIEVWQyBvbiBhIFVOSS4NCg0KICAgICAgICBUaGlzIGluZGV4IGlu ZGljYXRlcyBhIHNwZWNpZmljIENvUyBwcm9maWxlIHByZXZpb3VzbHkgY29uZmlndXJlZCB2 aWENCiAgICAgICAgbWVmU2VydmljZUNvc0NmZ1RhYmxlLg0KICAgICAgICINCiAgICBSRUZF UkVOQ0UNCiAgICAgICAiW01FRiA2LjFdIDYuMTsgW01FRiA3LjJdIDYuMi4xLjMiDQogICAg REVGVkFMIHsgMCB9ICANCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZjUGVyVW5pQ2ZnRW50cnkg NSB9DQoNCm1lZlNlcnZpY2VFdmNQZXJVbmlDZmdFZ3Jlc3NCd3BJbmRleCBPQkpFQ1QtVFlQ RQ0KICAgIFNZTlRBWCAgICAgIFVuc2lnbmVkMzINCiAgICBNQVgtQUNDRVNTICByZWFkLXdy aXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAg IlRoaXMgb2JqZWN0IGlzIHRoZSBpbmRleCBudW1iZXIgb2YgdGhlIGVncmVzcyBiYW5kd2lk dGggcHJvZmlsZQ0KICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIGN1cnJlbnQgRVZDIG9u IGEgVU5JLiBBIHZhbHVlIG9mIDAgaW5kaWNhdGVzIHRoYXQNCiAgICAgICAgbm8gZWdyZXNz IGJhbmR3aXRoIHByb2ZpbGUgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBFVkMgb24gYSBVTkku DQoNCiAgICAgICAgVGhpcyBpbmRleCBpbmRpY2F0ZXMgYSBzcGVjaWZpYyBwcm9maWxlIHBy ZXZpb3VzbHkgY29uZmlndXJlZCB2aWENCiAgICAgICAgbWVmU2VydmljZUJ3cENmZ1RhYmxl LiBNdWx0aXBsZSBDb1MgYmFuZHdpZHRoIHByb2ZpbGVzIHVzaW5nIHRoaXMNCiAgICAgICAg b25lIGluZGV4IHBvaW50IHRvIHRoZSBtZWZTZXJ2aWNlQndwQ2ZnSXRlbVRhYmxlLg0KICAg ICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2LjFdIDYuMTsgW01FRiA3LjJd IDYuMi4xLjMiDQogICAgREVGVkFMIHsgMCB9ICANCiAgICA6Oj0geyBtZWZTZXJ2aWNlRXZj UGVyVW5pQ2ZnRW50cnkgNiB9DQoNCm1lZlNlcnZpY2VFdmNQZXJVbmlDZmdFZ3Jlc3NDb3NJ bmRleCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFVuc2lnbmVkMzINCiAgICBNQVgt QUNDRVNTICByZWFkLXdyaXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NS SVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGlzIHRoZSBpbmRleCBudW1iZXIgb2YgdGhl IGVncmVzcyBDb1MgcHJvZmlsZQ0KICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIGN1cnJl bnQgRVZDIG9uIGEgVU5JLiBBIHZhbHVlIG9mIDAgaW5kaWNhdGVzIHRoYXQNCiAgICAgICAg bm8gZWdyZXNzIENvUyBwcm9maWxlIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgRVZDIG9uIGEg VU5JLg0KDQogICAgICAgIFRoaXMgaW5kZXggaW5kaWNhdGVzIGEgc3BlY2lmaWMgQ29TIHBy b2ZpbGUgcHJldmlvdXNseSBjb25maWd1cmVkIHZpYQ0KICAgICAgICBtZWZTZXJ2aWNlQ29z Q2ZnVGFibGUuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0g Ni4xOyBbTUVGIDcuMl0gNi4yLjEuMyINCiAgICBERUZWQUwgeyAwIH0gIA0KICAgIDo6PSB7 IG1lZlNlcnZpY2VFdmNQZXJVbmlDZmdFbnRyeSA3IH0NCg0KDQotLSAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KLS0gRXRoZXJuZXQgU2VydmljZSBCYW5kd2lkdGggUHJvZmlsZSBUYWJs ZQ0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KbWVmU2VydmljZUJ3cE5leHRJbmRl eCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFVuc2lnbmVkMzINCiAgICBNQVgtQUND RVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAiVGhpcyBvYmplY3QgY29udGFpbnMgYW4gdW51c2VkIHZhbHVlIGZvciBh IGJhbmR3aWR0aCBwcm9maWxlIG9uIGENCiAgICAgICAgTUVGIGNvbXBsaWFudCBORSwgb3Ig YSB6ZXJvIHRvIGluZGljYXRlIHRoYXQgbm9uZSBleGlzdC4gVGhpcyB2YWx1ZQ0KICAgICAg ICBuZWVkcyB0byBiZSByZWFkIGluIG9yZGVyIHRvIGZpbmQgYW4gYXZhaWxhYmxlIGluZGV4 IGZvciByb3ctY3JlYXRpb24gb2YNCiAgICAgICAgYSBiYW5kd2lkdGggcHJvZmlsZSBhbmQg dGhlbiB1c2VkIHdoZW4gYSByb3cgaXMgY3JlYXRlZC4gVGhpcyB2YWx1ZSBpcw0KICAgICAg ICBhdXRvbWF0aWNhbGx5IHVwZGF0ZWQgYnkgdGhlIFNOTVAgQWdlbnQgYWZ0ZXIgdGhlIHJv dyBpcyBjcmVhdGVkLg0KDQogICAgICAgIFJlZmVyZW50aWFsIGludGVncml0eSBpcyBuZWNl c3NhcnksIGkuZS4sIHRoZSBpbmRleCBuZWVkcyB0byBiZQ0KICAgICAgICBwZXJzaXN0ZW50 IHVwb24gYSByZWJvb3Qgb3IgcmVzdGFydCBvZiBhIE5FLiAgVGhlIGluZGV4DQogICAgICAg IGlzIG5ldmVyIHRvIGJlIHJldXNlZCBmb3IgYSBuZXcgYmFuZHdpZHRoIHByb2ZpbGUgb24g dGhlIHNhbWUgTUVGIA0KICAgICAgICBjb21wbGlhbnQgTkUgdW50aWwgaXQgd3JhcHMgdG8g emVyby4gIFRoZSBpbmRleCB2YWx1ZSBrZWVwcw0KICAgICAgICBpbmNyZWFzaW5nIHVwIHRv IHRoYXQgdGltZS4gVGhpcyBpcyB0byBmYWNpbGl0YXRlIGFjY2VzcyBjb250cm9sIGJhc2Vk DQogICAgICAgIG9uIGEgZml4ZWQgaW5kZXggZm9yIGFuIEVNUywgc2luY2UgdGhlIGluZGV4 IGlzIG5vdCByZXVzZWQuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVG IDYuMV0gNi4wLCA2LjEsIDYuMiwgNi4zOyBbTUVGIDcuMl0gNi4yLjEuMiwgNi4yLjEuMyIN CiAgICA6Oj0geyBtZWZTZXJ2aWNlQndwQXR0cmlidXRlcyAxIH0NCg0KbWVmU2VydmljZUJ3 cENmZ1RhYmxlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgU0VRVUVOQ0UgT0YgTWVm U2VydmljZUJ3cENmZ0VudHJ5DQogICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUNCiAg ICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyB0 YWJsZSBzdXBwb3J0cyBiYW5kd2lkdGggcHJvZmlsZSBzZXR0aW5ncy4gUm93cyBpbiB0aGlz IHRhYmxlIA0KICAgICAgICBhcmUgY3JlYXRlZCBieSB0aGUgbWFuYWdlbWVudCBlbnRpdHkg d2hlbiBhIGJhbmR3aWR0aCBwcm9maWxlIGlzDQogICAgICAgIGNvbmZpZ3VyZWQuIE9uY2Ug YSByb3cgaW4gdGhpcyB0YWJsZSBpcyBjcmVhdGVkLCBhbiBlbnRyeSBjYW4gYmUNCiAgICAg ICAgY3JlYXRlZCBpbiB0aGUgbWVmU2VydmljZUJ3cENmZ0l0ZW1UYWJsZSB1c2luZyB0aGUg aW5kZXggZnJvbSB0aGlzDQogICAgICAgIHRhYmxlIGFuZCB0aGUgdmFsdWUgb2YgbWVmU2Vy dmljZUJ3cENmZ0l0ZW1OZXh0SW5kZXggb2JqZWN0LiBBIHJvdw0KICAgICAgICBpbiB0aGUg bWVmU2VydmljZUJ3cENmZ0l0ZW1UYWJsZSBpbmRpY2F0ZXMgaG93IGEgc3BlY2lmaWMgYmFu ZHdpZHRoDQogICAgICAgIHByb2ZpbGUgd2lsbCBiZSBoYW5kbGVkLg0KDQogICAgICAgIElm IGEgcm93IGluIHRoaXMgdGFibGUgaXMgY3JlYXRlZCB3aXRoIGEgbm9uLXplcm8gdmFsdWUg b2YgDQogICAgICAgIG1lZlNlcnZpY2VCd3BDZmdJdGVtUGVyZm9ybWFuY2VJbmRleCBhIGNv cnJlc3BvbmRpbmcgcm93IGlzIGNyZWF0ZWQgaW4gDQogICAgICAgIHRoZSBtZWZTZXJ2aWNl UGVyZm9ybWFuY2VUYWJsZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltN RUYgNi4xXSwgW01FRiA2LjEuMV0gOC4wLCBbTUVGIDcuMl0sIFtNRUYgMTAuMl0iDQogICAg Ojo9IHsgbWVmU2VydmljZUJ3cEF0dHJpYnV0ZXMgMiB9DQoNCm1lZlNlcnZpY2VCd3BDZmdF bnRyeSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIE1lZlNlcnZpY2VCd3BDZmdFbnRy eQ0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVTICAgICAgY3Vy cmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIkwyQ1Agc2V0dGluZ3MgdGFibGUgZW50 cnkgb24gYW4gaW50ZXJmYWNlLiINCiAgICBJTkRFWCB7IG1lZlNlcnZpY2VCd3BDZmdJbmRl eCB9DQogICAgOjo9IHsgbWVmU2VydmljZUJ3cENmZ1RhYmxlIDEgfQ0KDQpNZWZTZXJ2aWNl QndwQ2ZnRW50cnkgOjo9IFNFUVVFTkNFIHsNCiAgICAgIG1lZlNlcnZpY2VCd3BDZmdJbmRl eCAgICAgICAgIFVuc2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNlQndwQ2ZnSXRlbU5leHRJ bmRleCBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ1Jvd1N0YXR1cyAgICAg Um93U3RhdHVzDQogICAgfQ0KDQptZWZTZXJ2aWNlQndwQ2ZnSW5kZXggT0JKRUNULVRZUEUN CiAgICBTWU5UQVggICAgICBVbnNpZ25lZDMyDQogICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vz c2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAgIkJhbmR3aWR0aCBwcm9maWxlIGluZGV4IG51bWJlciINCiAgICA6Oj0geyBtZWZTZXJ2 aWNlQndwQ2ZnRW50cnkgMSB9DQoNCm1lZlNlcnZpY2VCd3BDZmdJdGVtTmV4dEluZGV4IE9C SkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1Mg IHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0K ICAgICAgICAiVmFsdWUgdG8gYmUgdXNlZCBhcyB0aGUgaW5kZXggb2YgdGhlIGJhbmR3aWR0 aCBwcm9maWxlIGl0ZW0NCiAgICAgICAgIHRhYmxlIGVudHJpZXMuIFRoaXMgdmFsdWUgaXMg YXV0b21hdGljYWxseSBpbmNyZW1lbnRlZCB3aGVuDQogICAgICAgICBhIHJvdyBpcyBjcmVh dGVkIGluIHRoZSBiYW5kd2lkdGggcHJvZmlsZSBpdGVtIHRhYmxlLiBXaGVuDQogICAgICAg ICB0aGUgbWFuYWdlbWVudCBlbnRpdHkgd2FudHMgdG8gY3JlYXRlIGEgbmV3IHJvdyBpbiB0 aGUgYmFuZHdpZHRoDQogICAgICAgICBwcm9maWxlIGl0ZW0gdGFibGUgdGhlIHZhbHVlIG9m IHRoaXMgb2JqZWN0IGlzIHVzZWQgdG8gY3JlYXRlIHRoZQ0KICAgICAgICAgc3BlY2lmaWMg aXRlbSByb3cuDQogICAgICAgICINCiAgICBERUZWQUwgeyAxIH0NCiAgICA6Oj0geyBtZWZT ZXJ2aWNlQndwQ2ZnRW50cnkgMiB9DQoNCm1lZlNlcnZpY2VCd3BDZmdSb3dTdGF0dXMgT0JK RUNULVRZUEUNCiAgICBTWU5UQVggICAgICBSb3dTdGF0dXMNCiAgICBNQVgtQUNDRVNTICBy ZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0K ICAgICAgICJUaGUgc3RhdHVzIG9mIHRoZSByb3cuDQoNCiAgICAgICAgVGhlIHdyaXRhYmxl IGNvbHVtbnMgaW4gYSByb3cgY2Fubm90IGJlIGNoYW5nZWQgaWYgdGhlIHJvdw0KICAgICAg ICBpcyBhY3RpdmUuIEFsbCBjb2x1bW5zIG11c3QgaGF2ZSBhIHZhbGlkIHZhbHVlIGJlZm9y ZSBhIHJvdw0KICAgICAgICBjYW4gYmUgYWN0aXZhdGVkLg0KICAgICAgICINCiAgIDo6PSB7 IG1lZlNlcnZpY2VCd3BDZmdFbnRyeSAzIH0NCg0KLS0gKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCi0tIEV0aGVybmV0IFNlcnZpY2UgQmFuZHdpZHRoIFByb2ZpbGUgSXRlbSBUYWJsZQ0K LS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KbWVmU2VydmljZUJ3cENmZ0l0ZW1UYWJs ZSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFNFUVVFTkNFIE9GIE1lZlNlcnZpY2VC d3BDZmdJdGVtRW50cnkNCiAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZQ0KICAgIFNU QVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIHRhYmxl IHN1cHBvcnRzIEJhbmR3aWR0aCBwcm9maWxlIHNldHRpbmdzIGFuZCBhbGxvd3MgbXVsdGlw bGUNCiAgICAgICAgYmFuZHdpZHRoIHByb2ZpbGUgdG8gY29uZmlndXJlZCBvbiBhbiBJbnRl cmZhY2Ugb3IgYSBWaXJ0dWFsIFNlcnZpY2UsDQogICAgICAgIGJhc2VkIHVwb24gZGlmZmVy ZW50IENsYXNzIG9mIFNlcnZpY2UgSWRlbnRpZmllcnMuIg0KICAgIDo6PSB7IG1lZlNlcnZp Y2VCd3BBdHRyaWJ1dGVzIDMgfQ0KDQptZWZTZXJ2aWNlQndwQ2ZnSXRlbUVudHJ5IE9CSkVD VC1UWVBFDQogICAgU1lOVEFYICAgICAgTWVmU2VydmljZUJ3cENmZ0l0ZW1FbnRyeQ0KICAg IE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0K ICAgIERFU0NSSVBUSU9ODQogICAgICAgIkJhbmR3aWR0aCBwcm9maWxlIHNldHRpbmdzIHRh YmxlIGVudHJ5LiINCiAgICBJTkRFWCB7IG1lZlNlcnZpY2VCd3BDZmdJbmRleCwgbWVmU2Vy dmljZUJ3cENmZ0l0ZW1JbmRleCB9DQogICAgOjo9IHsgbWVmU2VydmljZUJ3cENmZ0l0ZW1U YWJsZSAxIH0NCg0KTWVmU2VydmljZUJ3cENmZ0l0ZW1FbnRyeSA6Oj0gU0VRVUVOQ0Ugew0K ICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1JbmRleCAgICAgICAgICAgICBVbnNpZ25lZDMy LA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1JZGVudGlmaWVyICAgICAgICBEaXNwbGF5 U3RyaW5nLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1DaXIgICAgICAgICAgICAgICBV bnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1DYnMgICAgICAgICAgICAg ICBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1FaXIgICAgICAgICAg ICAgICBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1FYnMgICAgICAg ICAgICAgICBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1DbSAgICAg ICAgICAgICAgICBJTlRFR0VSLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1DZiAgICAg ICAgICAgICAgICBJTlRFR0VSLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1Db3NJbmRl eCAgICAgICAgICBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1QZXJm b3JtYW5jZUluZGV4ICBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1S b3dTdGF0dXMgICAgICAgICBSb3dTdGF0dXMNCiAgICB9DQoNCm1lZlNlcnZpY2VCd3BDZmdJ dGVtSW5kZXggT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBVbnNpZ25lZDMyDQogICAg TUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgREVTQ1JJUFRJT04NCiAgICAgICAiQmFuZHdpZHRoIHByb2ZpbGUgaW5kZXggbnVtYmVy LiBNdWx0aXBsZSBiYW5kd2lkdGggcHJvZmlsZXMNCiAgICAgICAgY2FuIGJlIHNldCBmb3Ig dGhlIHNhbWUgYmFuZHdpZHRoIHByb2ZpbGUgYXNzaWdubWVudCwgYWxsb3dpbmcgZm9yDQog ICAgICAgIHVuaXF1ZSBiYW5kd2lkdGggcHJvZmlsZXMgZm9yIGVhY2ggQ29TIElkZW50aWZp ZXIuIA0KICAgICAgICINCiAgICA6Oj0geyBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUVudHJ5IDEg fQ0KDQptZWZTZXJ2aWNlQndwQ2ZnSXRlbUlkZW50aWZpZXIgT0JKRUNULVRZUEUNCiAgICBT WU5UQVggICAgICBEaXNwbGF5U3RyaW5nIChTSVpFKDAuLjQ1KSkNCiAgICBNQVgtQUNDRVNT ICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElP Tg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhlIGJhbmR3aWR0aCBwcm9maWxl IGlkZW50aWZpZXIgZm9yIHRoZQ0KICAgICAgICBhc3NvY2lhdGVkIGJhbmR3aWR0aCBwcm9m aWxlIGluZGV4IGFuZCBpcyBhbiBhcmJpdHJhcnkgDQogICAgICAgIHRleHQgc3RyaW5nIHRo YXQgaXMgdXNlZCB0byBpZGVudGlmeSBhbiBiYW5kd2lkdGggcHJvZmlsZS4gVW5pcXVlDQog ICAgICAgIHN0cmluZyB2YWx1ZXMgYXJlIGNob3NlbiB0byB1bmlxdWVseSBpZGVudGlmeSB0 aGUgYmFuZHdpZHRoDQogICAgICAgIHByb2ZpbGUuDQoNCiAgICAgICAgT2N0ZXQgdmFsdWVz IG9mIDB4MDAgdGhyb3VnaCAweDFmIGFyZSBpbGxlZ2FsLg0KICAgICAgICINCiAgICBSRUZF UkVOQ0UNCiAgICAgICAiW01FRiA2LjFdIDYuMCwgNi4xLCA2LjIsIDYuMzsgW01FRiA3LjJd IDYuMi4xLjIsIDYuMi4xLjMiDQogICAgOjo9IHsgbWVmU2VydmljZUJ3cENmZ0l0ZW1FbnRy eSAyIH0NCg0KbWVmU2VydmljZUJ3cENmZ0l0ZW1DaXIgT0JKRUNULVRZUEUNCiAgICBTWU5U QVggICAgICBVbnNpZ25lZDMyICgxLi4xMDAwMDAwMCkNCiAgICBVTklUUyAgICAgICAia2Iv cyINCiAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhl IENvbW1pdHRlZCBJbmZvcm1hdGlvbiBSYXRlIChDSVIpIGluIGtiL3MNCiAgICAgICAgYW5k IGRlZmluZXMgdGhlIGF2ZXJhZ2UgcmF0ZSBpbiBrYml0cy9zZWMgb2YgU2VydmljZSBGcmFt ZXMgdXAgdG8NCiAgICAgICAgdGhlIG5ldHdvcmsgZGVsaXZlcnMgdGhlIFNlcnZpY2UgRnJh bWVzIGFuZCBtZWV0cyB0aGUgcGVyZm9ybWFuY2UNCiAgICAgICAgb2JqZWN0aXZlcy4gU2Vy dmljZSBGcmFtZXMgdGhhdCBtZWV0IHRoZSBDSVIgYXJlIHNhaWQgdG8gYmUgaW4gcHJvZmls ZQ0KICAgICAgICBvciBpbiBjb25mb3JtYW5jZSB0byBwZXJmb3JtYW5jZSBvYmplY3RpdmVz LiBUaGVyZSBmcmFtZXMgYXJlDQogICAgICAgIGdlbmVyYWxseSBpZGVudGlmaWVkIGFzICdH cmVlbicgc2VydmljZSBmcmFtZXMuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAg ICJbTUVGIDYuMV0gNi4wLCA2LjEsIDYuMiwgNi4zOyBbTUVGIDcuMl0gNi4yLjEuMiwgNi4y LjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUVudHJ5IDMgfQ0KDQptZWZT ZXJ2aWNlQndwQ2ZnSXRlbUNicyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFVuc2ln bmVkMzIgKDEuLjEwMDAwKQ0KICAgIFVOSVRTICAgICAgICJLQiINCiAgICBNQVgtQUNDRVNT ICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElP Tg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0ZXMgdGhlIENvbW1pdHRlZCBCdXJzdCBT aXplIChDQlMpIGluIEtCLiBJdCBsaW1pdHMNCiAgICAgICAgVGhlIG1heGltdW0gbnVtYmVy IG9mIGJ5dGVzIGF2YWlsYWJsZSBmb3IgYSBidXJzdCBvZiBTZXJ2aWNlIEZyYW1lc3Mgc2Vu dA0KICAgICAgICBhdCBpbnRlcmZhY2Ugc3BlZWQgdG8gcmVtYWluIENJUi1jb25mb3JtYW50 Lg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiAxMC4yXSINCiAgICA6 Oj0geyBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUVudHJ5IDQgfQ0KDQptZWZTZXJ2aWNlQndwQ2Zn SXRlbUVpciBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFVuc2lnbmVkMzIgKDEuLjEw MDAwMDAwKQ0KICAgIFVOSVRTICAgICAgICJrYi9zIg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQt Y3JlYXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAg ICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUgRXhjZXNzIEluZm9ybWF0aW9uIFJhdGUg KEVJUikgaW4ga2Ivcw0KICAgICAgICBhbmQgZGVmaW5lcyB0aGUgYXZlcmFnZSByYXRlIGlu IGtiaXRzL3NlYyBvZiBTZXJ2aWNlIEZyYW1lcyB1cCB0bw0KICAgICAgICB3aGljaCB0aGUg bmV0d29yayBtYXkgZGVsaXZlciBTZXJ2aWNlIEZyYW1lcyBidXQgd2l0aG91dCBwZXJmb3Jt YW5jZQ0KICAgICAgICBvYmplY3RpdmVzLiBTZXJ2aWNlIEZyYW1lcyB0aGF0IG1lZXQgdGhl IEVJUiBhcyBzZXQgdG8gYmUgaW4gb3V0LW9mLQ0KICAgICAgICBwcm9maWxlIG9yIG5vdCBp biBjb25mb3JtYW5jZSB0byBwZXJmb3JtYW5jZSBvYmplY3RpdmVzLiBUaGVzZSANCiAgICAg ICAgZnJhbWVzIGFyZSBub3QgZ3VhcmFudGVlZCB0byBiZSBkZWxpdmVyZWQgYW5kIGFyZSBn ZW5lcmFsbHkgaWRlbnRpZmllZA0KICAgICAgICBhcyAnWWVsbG93JyBzZXJ2aWNlIGZyYW1l cy4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjAsIDYu MSwgNi4yLCA2LjM7IFtNRUYgNy4yXSA2LjIuMS4yLCA2LjIuMS4zIg0KICAgIDo6PSB7IG1l ZlNlcnZpY2VCd3BDZmdJdGVtRW50cnkgNSB9DQoNCm1lZlNlcnZpY2VCd3BDZmdJdGVtRWJz IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMiAoMS4uMTAwMDApDQog ICAgVU5JVFMgICAgICAgIktCIg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAg U1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2Jq ZWN0IGluZGljYXRlcyB0aGUgRXhjZXNzIEJ1cnN0IFNpemUgKEVCUykgaW4gS0IuIEl0IGxp bWl0cw0KICAgICAgICBUaGUgbWF4aW11bSBudW1iZXIgb2YgYnl0ZXMgYXZhaWxhYmxlIGZv ciBhIGJ1cnN0IG9mIFNlcnZpY2UgRnJhbWVzDQogICAgICAgIHNlbnQgYXQgdGhlIGludGVy ZmFjZSBzcGVlZCB0byByZW1haW4gRUlSLWNvbmZvcm1hbnQuDQogICAgICAgIg0KICAgIFJF RkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0gNi4wLCA2LjEsIDYuMiwgNi4zOyBbTUVGIDcu Ml0gNi4yLjEuMiwgNi4yLjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUVu dHJ5IDYgfQ0KDQptZWZTZXJ2aWNlQndwQ2ZnSXRlbUNtIE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgSU5URUdFUiB7DQogICAgICAgIGNvbG9yQmxpbmQgICAgICAoMSksDQogICAg ICAgIGNvbG9yQXdhcmUgICAgICAoMikNCiAgICB9DQogICAgTUFYLUFDQ0VTUyAgcmVhZC1j cmVhdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAgIkNvbmZpZ3VyZXMgdGhlIGJhbmR3aWR0aCBwcm9maWxlIGNvbG9yIG1vZGUuDQoNCiAg ICAgICAgY29sb3JCbGluZCgxKSAgICBBIGJhbmR3aWR0aCBwcm9maWxlIHByb3BlcnR5IHdo ZXJlIGluZ3Jlc3MgDQogICAgICAgICAgICAgICAgICAgICAgICAgU2VydmljZSBGcmFtZXMg YXJlIG5vdCBwcmUtY29sb3JlZCBmb3IgZWl0aGVyIA0KICAgICAgICAgICAgICAgICAgICAg ICAgIGdyZWVuIG9yIHllbGxvdywgYW5kIGlmIHByZXNlbnQsIGlzIGlnbm9yZWQgd2hlbg0K ICAgICAgICAgICAgICAgICAgICAgICAgIGRldGVybWluaW5nIHRoZSBsZXZlbCBvZiBjb21w bGlhbmNlIGZvciBlYWNoDQogICAgICAgICAgICAgICAgICAgICAgICAgU2VydmljZSBGcmFt ZQ0KICAgICAgICBjb2xvckF3YXJlKDIpICAgIEEgYmFuZHdpZHRoIHByb2ZpbGUgcHJvcGVy dHkgd2VyZSBhIHByZS1kZXRlcm1pbmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgbGV2 ZWwgb2YgQmFuZHdpZHRoIFByb2ZpbGUgY29tcGxpYW5jZSBmb3IgZWFjaA0KICAgICAgICAg ICAgICAgICAgICAgICAgIFNlcnZpY2UgRnJhbWUgaXMgdGFrZW4gaW50byBhY2NvdW50IHdo ZW4gZGV0ZXJtaW5pbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgbGV2ZWwgb2Yg Y29tcGxpYW5jZSBmb3IgZWFjaCBTZXJ2aWNlIEZyYW1lLiANCiAgICAgICAgICAgICAgICAg ICAgICAgICBFYWNoIHNlcnZpY2UgZnJhbWUgY2FuIGJlIGNvbG9yZWQgcmVkIChkaXNjYXJk ZWQpLA0KICAgICAgICAgICAgICAgICAgICAgICAgIHllbGxvdyAoY29uZGl0aW9uYWwgZGVs aXZlcnkpLCBvciBncmVlbiAodW5jb25kaXRpb25hbA0KICAgICAgICAgICAgICAgICAgICAg ICAgIGRlbGl2ZXJ5Lg0KICAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYg Ni4xXSA2LjAsIDYuMSwgNi4yLCA2LjM7IFtNRUYgNy4yXSA2LjIuMS4yLCA2LjIuMS4zIg0K ICAgIDo6PSB7IG1lZlNlcnZpY2VCd3BDZmdJdGVtRW50cnkgNyB9DQoNCm1lZlNlcnZpY2VC d3BDZmdJdGVtQ2YgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBJTlRFR0VSIHsNCiAg ICAgICAgY291cGxpbmdZZWxsb3dFaXJPbmx5ICAgICAoMCksDQogICAgICAgIGNvdXBsaW5n WWVsbG93RWlyUGx1c0NpciAgKDEpDQogICAgfQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3Jl YXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAg ICJDb25maWd1cmVzIHRoZSBiYW5kd2lkdGggcHJvZmlsZSBjb3VwbGluZyBmbGFnIGFuZCBo YXMgdGhlIGVmZmVjdCBvZg0KICAgICAgICAgQ29udHJvbGxpbmcgdGhlIHZvbHVtZSBvZiB0 aGUgU2VydmljZSBGcmFtZXMgdGhhdCBhcmUgZGVjbGFyZWQgWWVsbG93Lg0KDQogICAgICAg IGNvdXBsaW5nWWVsbG93RWlyT25seSgwKSAgICAgVGhlIGxvbmcgdGVybSBhdmVyYWdlIGJp dCByYXRlIG9mIFNlcnZpY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGcmFtZXMgdGhhdCBhcmUgZGVjbGFyZWQgWWVsbG93IGlzIGJvdW5kZWQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBieSBFSVIuICAgICAgICAgDQogICAgICAg IGNvdXBsaW5nWWVsbG93RWlyUGx1c0NpcigxKSAgVGhlIGxvbmcgdGVybSBhdmVyYWdlIGJp dCByYXRlIG9mIFNlcnZpY2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGcmFtZXMgdGhhdCBhcmUgZGVjbGFyZWQgWWVsbG93IGlzIGJvdW5kZWQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBieSBDSVIgKyBFSVIgZGVwZW5kaW5nIG9u IHRoZSB2b2x1bWUgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGUgb2ZmZXJlZCBTZXJ2aWNlIEZyYW1lcyB0aGF0IGFyZSANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBkZWNsYXJlZCBHcmVlbi4NCiAgICAgICAgIg0KICAgIFJF RkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0gNi4wLCA2LjEsIDYuMiwgNi4zOyBbTUVGIDcu Ml0gNi4yLjEuMiwgNi4yLjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUVu dHJ5IDggfQ0KDQptZWZTZXJ2aWNlQndwQ2ZnSXRlbUNvc0luZGV4IE9CSkVDVC1UWVBFDQog ICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUN CiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhp cyBvYmplY3QgaXMgdGhlIGluZGV4IG51bWJlciBvZiB0aGUgaW5ncmVzcyBDb1MgcHJvZmls ZQ0KICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIGN1cnJlbnQgYmFuZHdpZHRoIHByb2Zp bGUuIEEgdmFsdWUgb2YgMCBpbmRpY2F0ZXMNCiAgICAgICAgdGhhdCBubyBpbmdyZXNzIENv UyBwcm9maWxlIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgYmFuZHdpZHRoDQogICAgICAgIHBy b2ZpbGUuDQoNCiAgICAgICAgVGhpcyBpbmRleCBpbmRpY2F0ZXMgYSBzcGVjaWZpYyBDb1Mg cHJvZmlsZSBwcmV2aW91c2x5IGNvbmZpZ3VyZWQgdmlhDQogICAgICAgIG1lZlNlcnZpY2VD b3NDZmdUYWJsZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4x XSA2LjE7IFtNRUYgNy4yXSA2LjIuMS4zIg0KICAgIERFRlZBTCB7IDAgfSAgDQogICAgOjo9 IHsgbWVmU2VydmljZUJ3cENmZ0l0ZW1FbnRyeSA5IH0NCg0KbWVmU2VydmljZUJ3cENmZ0l0 ZW1QZXJmb3JtYW5jZUluZGV4IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgVW5zaWdu ZWQzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUNCiAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVzIHRo ZSBpbmRleCBudW1iZXIgb2YgdGhlIFRyYWZmaWMgUGVyZm9ybWFuY2UNCiAgICAgICAgRGF0 YSBTZXQgQ29TIHByb2ZpbGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjdXJyZW50IGJhbmR3aWR0 aCBwcm9maWxlLg0KICAgICAgICBBIHZhbHVlIG9mIDAgaW5kaWNhdGVzIHRoYXQgbm8gcGVy Zm9ybWFuY2UgcHJvZmlsZSBpcyBhc3NvY2lhdGVkIA0KICAgICAgICB3aXRoIHRoZSBiYW5k d2lkdGggcHJvZmlsZS4NCg0KICAgICAgICBUaGUgbWVmU2VydmljZVBlcmZvcm1hbmNlTmV4 dEluZGV4IG9iamVjdCBuZWVkcyB0byBiZSByZWFkIHRvIGZpbmQNCiAgICAgICAgdGhlIG5l eHQgYXZhaWxhYmxlIHBlcmZvcm1hbmNlIHNldCB0aGF0IGNhbiBiZSB1c2VkLiBXaGVuIGEg cm93IGluDQogICAgICAgIHRoaXMgdGFibGUgaXMgY3JlYXRlZCBhbmQgbWVmU2VydmljZUJ3 cENmZ0l0ZW1QZXJmb3JtYW5jZUluZGV4IGlzDQogICAgICAgIG5vbi16ZXJvIHRoZW4gYSBy b3cgaW4gdGhlIG1lZlNlcnZpY2VQZXJmb3JtYW5jZVRhYmxlIGlzIGF1dG9tYXRpY2FsbHkN CiAgICAgICAgY3JlYXRlZC4gRGVsZXRpbmcgYSByb3cgaW4gdGhpcyB0YWJsZSB3aXRoIGEg bm9uLXplcm8NCiAgICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1QZXJmb3JtYW5jZUluZGV4 IGRlbGV0ZXMgdGhlIGNvcnJlc3BvbmRpbmcgcm93IGluDQogICAgICAgIHRoZSBtZWZTZXJ2 aWNlUGVyZm9ybWFuY2VUYWJsZS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAg IltNRUYgNi4xXSA2LjE7IFtNRUYgNy4yXSA2LjIuMS4zIg0KICAgIERFRlZBTCB7IDAgfSAg DQogICAgOjo9IHsgbWVmU2VydmljZUJ3cENmZ0l0ZW1FbnRyeSAxMCB9DQoNCm1lZlNlcnZp Y2VCd3BDZmdJdGVtUm93U3RhdHVzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgUm93 U3RhdHVzDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBj dXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhlIHN0YXR1cyBvZiB0aGUgcm93 Lg0KDQogICAgICAgIFRoZSB3cml0YWJsZSBjb2x1bW5zIGluIGEgcm93IGNhbm5vdCBiZSBj aGFuZ2VkIGlmIHRoZSByb3cNCiAgICAgICAgaXMgYWN0aXZlLiBBbGwgY29sdW1ucyBtdXN0 IGhhdmUgYSB2YWxpZCB2YWx1ZSBiZWZvcmUgYSByb3cNCiAgICAgICAgY2FuIGJlIGFjdGl2 YXRlZC4NCiAgICAgICAiDQogICA6Oj0geyBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUVudHJ5IDEx IH0NCg0KDQotLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KLS0gRXRoZXJuZXQgU2Vydmlj ZSBDbGFzcyBvZiBTZXJ2aWNlIFByb2ZpbGUgVGFibGUNCi0tICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQoNCm1lZlNlcnZpY2VDb3NOZXh0SW5kZXggT0JKRUNULVRZUEUNCiAgICBTWU5U QVggICAgICBVbnNpZ25lZDMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0 IGNvbnRhaW5zIGFuIHVudXNlZCB2YWx1ZSBmb3IgYSBDbGFzcyBvZiBTZXJ2aWNlIChDb1Mp DQogICAgICAgIHByb2ZpbGUgb24gYSBNRUYgY29tcGxpYW50IE5FLCBvciBhIHplcm8gdG8g aW5kaWNhdGUgdGhhdCBub25lDQogICAgICAgIGV4aXN0LiBUaGlzIHZhbHVlIG5lZWRzIHRv IGJlIHJlYWQgaW4gb3JkZXIgdG8gZmluZCBhbiBhdmFpbGFibGUgaW5kZXgNCiAgICAgICAg Zm9yIHJvdy1jcmVhdGlvbiBvZiBhIENvUyBwcm9maWxlIGFuZCB0aGVuIHVzZWQgd2hlbiBh IHJvdyBpcyBjcmVhdGVkLg0KICAgICAgICBUaGlzIHZhbHVlIGlzIGF1dG9tYXRpY2FsbHkg dXBkYXRlZCBieSB0aGUgU05NUCBBZ2VudCBhZnRlciB0aGUgcm93IGlzDQogICAgICAgIGNy ZWF0ZWQuDQoNCiAgICAgICAgUmVmZXJlbnRpYWwgaW50ZWdyaXR5IGlzIG5lY2Vzc2FyeSwg aS5lLiwgdGhlIGluZGV4IG5lZWRzIHRvIGJlDQogICAgICAgIHBlcnNpc3RlbnQgdXBvbiBh IHJlYm9vdCBvciByZXN0YXJ0IG9mIGEgTkUuICBUaGUgaW5kZXgNCiAgICAgICAgaXMgbmV2 ZXIgdG8gYmUgcmV1c2VkIGZvciBhIG5ldyBDb1MgcHJvZmlsZSBvbiB0aGUgc2FtZSBNRUYg Y29tcGxpYW50DQogICAgICAgIE5FIHVudGlsIGl0IHdyYXBzIHRvIHplcm8uICBUaGUgaW5k ZXggdmFsdWUga2VlcHMNCiAgICAgICAgaW5jcmVhc2luZyB1cCB0byB0aGF0IHRpbWUuIFRo aXMgaXMgdG8gZmFjaWxpdGF0ZSBhY2Nlc3MgY29udHJvbCBiYXNlZA0KICAgICAgICBvbiBh IGZpeGVkIGluZGV4IGZvciBhbiBFTVMsIHNpbmNlIHRoZSBpbmRleCBpcyBub3QgcmV1c2Vk Lg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA2LjFdIDYuMCwgNi4x LCA2LjIsIDYuMzsgW01FRiA3LjJdIDYuMi4xLjIsIDYuMi4xLjMiDQogICAgOjo9IHsgbWVm U2VydmljZUNvc0F0dHJpYnV0ZXMgMSB9DQoNCm1lZlNlcnZpY2VDb3NDZmdUYWJsZSBPQkpF Q1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFNFUVVFTkNFIE9GIE1lZlNlcnZpY2VDb3NDZmdF bnRyeQ0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVTICAgICAg Y3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgdGFibGUgc3VwcG9ydHMg Q2xhc3Mgb2YgU2VydmljZSBwcm9maWxlIHNldHRpbmdzLiINCiAgICA6Oj0geyBtZWZTZXJ2 aWNlQ29zQXR0cmlidXRlcyAyIH0NCg0KbWVmU2VydmljZUNvc0NmZ0VudHJ5IE9CSkVDVC1U WVBFDQogICAgU1lOVEFYICAgICAgTWVmU2VydmljZUNvc0NmZ0VudHJ5DQogICAgTUFYLUFD Q0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVT Q1JJUFRJT04NCiAgICAgICAiQ2xhc3Mgb2YgU2VydmljZSBzZXR0aW5ncyB0YWJsZSBlbnRy eS4iDQogICAgSU5ERVggeyBtZWZTZXJ2aWNlQ29zQ2ZnSW5kZXggfQ0KICAgIDo6PSB7IG1l ZlNlcnZpY2VDb3NDZmdUYWJsZSAxIH0NCg0KTWVmU2VydmljZUNvc0NmZ0VudHJ5IDo6PSBT RVFVRU5DRSB7DQogICAgICBtZWZTZXJ2aWNlQ29zQ2ZnSW5kZXggICAgICAgICAgICAgVW5z aWduZWQzMiwNCiAgICAgIG1lZlNlcnZpY2VDb3NDZmdJZGVudGlmaWVyICAgICAgICBEaXNw bGF5U3RyaW5nLA0KICAgICAgbWVmU2VydmljZUNvc0NmZ1R5cGUgICAgICAgICAgICAgIElO VEVHRVIsDQogICAgICBtZWZTZXJ2aWNlQ29zQ2ZnSWRlbnRpZmllckxpc3QgICAgTWVmU2Vy dmljZUxpc3RUeXBlLA0KICAgICAgbWVmU2VydmljZUNvc0NmZ1Jvd1N0YXR1cyAgICAgICAg IFJvd1N0YXR1cw0KICAgIH0NCg0KbWVmU2VydmljZUNvc0NmZ0luZGV4IE9CSkVDVC1UWVBF DQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nl c3NpYmxlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAg ICAgICJDbGFzcyBvZiBTZXJ2aWNlIHByb2ZpbGUgaW5kZXggbnVtYmVyLiINCiAgICA6Oj0g eyBtZWZTZXJ2aWNlQ29zQ2ZnRW50cnkgMSB9DQoNCm1lZlNlcnZpY2VDb3NDZmdJZGVudGlm aWVyIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgRGlzcGxheVN0cmluZyAoU0laRSgw Li40NSkpDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBj dXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNhdGVz IHRoZSBDbGFzcyBvZiBTZXJ2aWNlIHByb2ZpbGUgaWRlbnRpZmllciBmb3IgdGhlDQogICAg ICAgIGFzc29jaWF0ZWQgQ29TIHByb2ZpbGUgaW5kZXggYW5kIGlzIGFuIGFyYml0cmFyeSB0 ZXh0IHN0cmluZyB0aGF0IGlzDQogICAgICAgIHVzZWQgdG8gaWRlbnRpZnkgYW4gQ29TIHBy b2ZpbGUuIFVuaXF1ZSBzdHJpbmcgdmFsdWVzIGFyZSBjaG9zZW4gdG8gDQogICAgICAgIHVu aXF1ZWx5IGlkZW50aWZ5IHRoZSBwcm9maWxlLg0KDQogICAgICAgIE9jdGV0IHZhbHVlcyBv ZiAweDAwIHRocm91Z2ggMHgxZiBhcmUgaWxsZWdhbC4NCiAgICAgICAiDQogICAgUkVGRVJF TkNFDQogICAgICAgIltNRUYgNi4xXSA2LjAsIDYuMSwgNi4yLCA2LjM7IFtNRUYgNy4yXSA2 LjIuMS4yLCA2LjIuMS4zIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VDb3NDZmdFbnRyeSAyIH0N Cg0KbWVmU2VydmljZUNvc0NmZ1R5cGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBJ TlRFR0VSIHsNCiAgICAgICAgaW50ZXJmYWNlICAgICAgICgxKSwNCiAgICAgICAgZXZjICAg ICAgICAgICAgICgyKSwNCiAgICAgICAgcGNwICAgICAgICAgICAgICgzKSwNCiAgICAgICAg ZHNjcCAgICAgICAgICAgICg0KSwNCiAgICAgICAgbDJjcCAgICAgICAgICAgICg1KQ0KICAg IH0NCiAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJDb25maWd1cmVzIHRoZSBDb1MgdHlwZSBh bmQgaW5kaWNhdGVzIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUNCiAgICAgICAgbWVmU2Vy dmljZUNvc0lkZW50aWZpZXJMaXN0IG9iamVjdC4NCg0KICAgICAgICBpbnRlcmZhY2UoMSkg VGhpcyB2YWx1ZSBpbmRpY2F0ZXMgdGhhdCB0aGUgQ29TIHByb2ZpbGUgaXMgYXNzb2NpYXRl ZA0KICAgICAgICAgICAgICAgICAgICAgd2l0aCB0aGUgaW50ZXJmYWNlLCBpLmUuIFVOSSBv ciBFTk5JDQogICAgICAgIHZjKDIpICAgICAgICBUaGlzIHZhbHVlIGluZGljYXRlcyB0aGF0 IHRoZSBDb1MgcHJvZmlsZSBpcyBhc3NvY2lhdGVkDQogICAgICAgICAgICAgICAgICAgICB3 aXRoIHRoZSB2aXJ0dWFsIGNoYW5uZWwsIGkuZS4gRVZDIG9yIE9WQw0KICAgICAgICBwY3Ao MykgICAgICAgVGhpcyB2YWx1ZSBpbmRpY2F0ZXMgdGhhdCB0aGUgQ29TIHByb2ZpbGUgaXMg YXNzb2NpYXRlZA0KICAgICAgICAgICAgICAgICAgICAgd2l0aCB0aGUgb3V0ZXIgdGFnJ3Mg UHJpb3JpdHkgQ29kZSBQb2ludCAocHJpb3JpdHkgYml0cykNCiAgICAgICAgZHNjcCg0KSAg ICAgIFRoaXMgdmFsdWUgaW5kaWNhdGVzIHRoYXQgdGhlIENvUyBwcm9maWxlIGlzIGFzc29j aWF0ZWQNCiAgICAgICAgICAgICAgICAgICAgIHRoZSBJUCdzIGZyYW1lcyBEU0NQIChwcmlv cml0eSkgc2V0dGluZw0KICAgICAgICBsMmNwKDUpICAgICAgVGhpcyB2YWx1ZSBpbmRpY2F0 ZXMgdGhhdCB0aGUgQ29TIHByb2ZpbGUgaXMgYXNzb2NpYXRlZA0KICAgICAgICAgICAgICAg ICAgICAgYSBMYXllciAyIENvbnRyb2wgUHJvdG9jb2wNCiAgICAgICAgIg0KICAgIFJFRkVS RU5DRQ0KICAgICAgICJbTUVGIDYuMV0gNi4wLCA2LjEsIDYuMiwgNi4zOyBbTUVGIDcuMl0g Ni4yLjEuMiwgNi4yLjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNlQ29zQ2ZnRW50cnkgMyB9 DQoNCm1lZlNlcnZpY2VDb3NDZmdJZGVudGlmaWVyTGlzdCBPQkpFQ1QtVFlQRQ0KICAgIFNZ TlRBWCAgICAgIE1lZlNlcnZpY2VMaXN0VHlwZQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3Jp dGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAi VGhpcyBvYmplY3QgaW5kaWNhdGVzIHRoZSBsaXN0IG9mIENvUyBpZGVudGlmaWVycyBhc3Nv Y2lhdGVkIHdpdGgNCiAgICAgICAgdGhlIHNwZWNpZmljIENvUyBwcm9maWxlLiBJbnRlcnBy ZXRhdGlvbiBvZiB0aGUgdmFsdWVzIGluIHRoZSBsaXN0DQogICAgICAgIGFyZSBiYXNlZCB1 cG9uIHRoZSBtZWZTZXJ2aWNlQ29zQ2ZnVHlwZSBvYmplY3QuDQoNCiAgICAgICAgRm9yIGVh Y2ggb2YgdGhlIG1lZlNlcnZpY2VDb3NDZmdUeXBlIHR5cGVzIHZhbGlkIHJhbmdlIGlzOg0K DQogICAgICAgIGludGVyZmFjZSAtIHRoZSB2YWx1ZSBvZiB0aGlzIG9iamVjdCBpcyBpZ25v cmVkIGZvciB0aGUgJ2ludGVyZmFjZScNCiAgICAgICAgICAgICAgICAgICAgdHlwZQ0KICAg ICAgICB2YyAgICAgICAgLSB0aGUgdmFsdWUgb2YgdGhpcyBvYmplY3QgaXMgaWdub3JlZCBm b3IgdGhlICd2YycgdHlwZQ0KICAgICAgICBwY3AgICAgICAgLSB0aGUgdmFsdWUgb2YgdGhp cyBvYmplY3QgaGFzIGEgcmFuZ2Ugb2YgJzA6NycNCiAgICAgICAgZHNjcCAgICAgIC0gdGhl IHZhbHVlIG9mIHRoaXMgb2JqZWN0IGhhcyBhIHJhbmdlIG9mICcwOjYzJyBmb3IgSVB2NA0K ICAgICAgICAgICAgICAgICAgICBhbmQgJzA6MTYzODQnIGZvciBJUHY2DQogICAgICAgIGwy Y3AgICAgICAtIHRoZSB2YWx1ZSBvZiB0aGlzIG9iamVjdCBpcyBpbiB0aGUgZm9ybSAoYXMg bmVjZXNzYXJ5KQ0KICAgICAgICAgICAgICAgICAgICBmb3IgdGhlIHNlbGVjdGlvbjoNCiAg ICAgICAgICAgICAgICAgICAgICBbTUFDIGFkZHJlc3NdIA0KICAgICAgICAgICAgICAgICAg ICAgICAgIGkuZS4gJzAxLTgwLUMyLTAwLTAwLTAwJw0KICAgICAgICAgICAgICAgICAgICAg IFtNQUMgYWRkcmVzc10vW1Byb3RvY29sXQ0KICAgICAgICAgICAgICAgICAgICAgICAgIGku ZS4gJzAxLTgwLUMyLTAwLTAwLTA3Lzg4RUUnDQogICAgICAgICAgICAgICAgICAgICAgW01B QyBhZGRyZXNzXS9bUHJvdG9jb2xdL1tTdWJUeXBlXQ0KICAgICAgICAgICAgICAgICAgICAg ICAgIGkuZS4gJzAxLTgwLUMyLTAwLTAwLTAyLzg4MDkvMDMnDQoNCiAgICAgICAgQ29TIGlk ZW50aWZpZXIgbGlzdCBjYW4gYmUgYSBzaW5nbGUgdmFsdWUgb3IgbXVsdGlwbGUgdmFsdWVz IHNlcGFyYXRlZA0KICAgICAgICBieSBhIGRlbGltZXRlci4NCg0KICAgICAgICBTb21lIHZh bGlkIHZhbHVlcyBhcmU6ICcxJywgJzE6MycsICcxLDMsNScsICcwOjcnDQogICAgICAgIg0K ICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0gNi4wLCA2LjEsIDYuMiwgNi4zOyBb TUVGIDcuMl0gNi4yLjEuMiwgNi4yLjEuMyINCiAgICA6Oj0geyBtZWZTZXJ2aWNlQ29zQ2Zn RW50cnkgNCB9DQoNCm1lZlNlcnZpY2VDb3NDZmdSb3dTdGF0dXMgT0JKRUNULVRZUEUNCiAg ICBTWU5UQVggICAgICBSb3dTdGF0dXMNCiAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0K ICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGUg c3RhdHVzIG9mIHRoZSByb3cuDQoNCiAgICAgICAgVGhlIHdyaXRhYmxlIGNvbHVtbnMgaW4g YSByb3cgY2Fubm90IGJlIGNoYW5nZWQgaWYgdGhlIHJvdw0KICAgICAgICBpcyBhY3RpdmUu IEFsbCBjb2x1bW5zIG11c3QgaGF2ZSBhIHZhbGlkIHZhbHVlIGJlZm9yZSBhIHJvdw0KICAg ICAgICBjYW4gYmUgYWN0aXZhdGVkLg0KICAgICAgICINCiAgIDo6PSB7IG1lZlNlcnZpY2VD b3NDZmdFbnRyeSA1IH0NCg0KDQotLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KLS0gRXRo ZXJuZXQgU2VydmljZSBMMkNQIFByb2ZpbGUgVGFibGUNCi0tICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQoNCm1lZlNlcnZpY2VMMmNwTmV4dEluZGV4IE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNU QVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVj dCBjb250YWlucyBhbiB1bnVzZWQgdmFsdWUgZm9yIGEgTDJDUCBwcm9maWxlIG9uIGENCiAg ICAgICAgTUVGIGNvbXBsaWFudCBORSwgb3IgYSB6ZXJvIHRvIGluZGljYXRlIHRoYXQgbm9u ZSBleGlzdC4gVGhpcyB2YWx1ZQ0KICAgICAgICBuZWVkcyB0byBiZSByZWFkIGluIG9yZGVy IHRvIGZpbmQgYW4gYXZhaWxhYmxlIGluZGV4IGZvciByb3ctY3JlYXRpb24gb2YNCiAgICAg ICAgYSBMMkNQIHByb2ZpbGUgYW5kIHRoZW4gdXNlZCB3aGVuIGEgcm93IGlzIGNyZWF0ZWQu IFRoaXMgdmFsdWUgaXMNCiAgICAgICAgYXV0b21hdGljYWxseSB1cGRhdGVkIGJ5IHRoZSBT Tk1QIEFnZW50IGFmdGVyIHRoZSByb3cgaXMgY3JlYXRlZC4NCg0KICAgICAgICBSZWZlcmVu dGlhbCBpbnRlZ3JpdHkgaXMgbmVjZXNzYXJ5LCBpLmUuLCB0aGUgaW5kZXggbmVlZHMgdG8g YmUNCiAgICAgICAgcGVyc2lzdGVudCB1cG9uIGEgcmVib290IG9yIHJlc3RhcnQgb2YgYSBO RS4gIFRoZSBpbmRleA0KICAgICAgICBpcyBuZXZlciB0byBiZSByZXVzZWQgZm9yIGEgbmV3 IEwyQ1AgcHJvZmlsZSBvbiB0aGUgc2FtZSBNRUYgY29tcGxpYW50DQogICAgICAgIE5FIHVu dGlsIGl0IHdyYXBzIHRvIHplcm8uICBUaGUgaW5kZXggdmFsdWUga2VlcHMNCiAgICAgICAg aW5jcmVhc2luZyB1cCB0byB0aGF0IHRpbWUuIFRoaXMgaXMgdG8gZmFjaWxpdGF0ZSBhY2Nl c3MgY29udHJvbCBiYXNlZA0KICAgICAgICBvbiBhIGZpeGVkIGluZGV4IGZvciBhbiBFTVMs IHNpbmNlIHRoZSBpbmRleCBpcyBub3QgcmV1c2VkLg0KICAgICAgICINCiAgICBSRUZFUkVO Q0UNCiAgICAgICAiW01FRiA2LjFdLCBbTUVGIDYuMS4xXSA4LjAsIFtNRUYgNy4yXSwgW01F RiAxMC4yXSINCiAgICA6Oj0geyBtZWZTZXJ2aWNlTDJjcEF0dHJpYnV0ZXMgMSB9DQoNCm1l ZlNlcnZpY2VMMmNwQ2ZnVGFibGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBTRVFV RU5DRSBPRiBNZWZTZXJ2aWNlTDJjcENmZ0VudHJ5DQogICAgTUFYLUFDQ0VTUyAgbm90LWFj Y2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAg ICAgICAiVGhpcyB0YWJsZSBzdXBwb3J0cyBMMkNQIHNldHRpbmdzLiBSb3dzIGluIHRoaXMg dGFibGUgYXJlIGNyZWF0ZWQNCiAgICAgICAgYnkgdGhlIG1hbmFnZW1lbnQgZW50aXR5IHdo ZW4gYSBMMkNQIHByb2ZpbGUgaXMgY29uZmlndXJlZC4gT25jZQ0KICAgICAgICBhIHJvdyBp biB0aGlzIHRhYmxlIGlzIGNyZWF0ZWQsIGFuIGVudHJ5IGNhbiBiZSBjcmVhdGVkIGluIHRo ZSANCiAgICAgICAgbWVmU2VydmljZUwyY3BDZmdJdGVtVGFibGUgdXNpbmcgdGhlIGluZGV4 IGZyb20gdGhpcyB0YWJsZSBhbmQgdGhlDQogICAgICAgIHZhbHVlIG9mIG1lZlNlcnZpY2VM MmNwQ2ZnSXRlbU5leHRJbmRleCBvYmplY3QuIEEgcm93IGluIHRoZSANCiAgICAgICAgbWVm U2VydmljZUwyY3BDZmdJdGVtVGFibGUgaW5kaWNhdGVzIGhvdyBhIHNwZWNpZmljIEwyQ1Ag d2lsbCBiZQ0KICAgICAgICBoYW5kbGVkLiINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01F RiA2LjFdLCBbTUVGIDYuMS4xXSA4LjAsIFtNRUYgNy4yXSwgW01FRiAxMC4yXSINCiAgICA6 Oj0geyBtZWZTZXJ2aWNlTDJjcEF0dHJpYnV0ZXMgMiB9DQoNCm1lZlNlcnZpY2VMMmNwQ2Zn RW50cnkgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBNZWZTZXJ2aWNlTDJjcENmZ0Vu dHJ5DQogICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBj dXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiTDJDUCBzZXR0aW5ncyB0YWJsZSBl bnRyeSBvbiBhbiBpbnRlcmZhY2UuIg0KICAgIElOREVYIHsgbWVmU2VydmljZUwyY3BDZmdJ bmRleCB9DQogICAgOjo9IHsgbWVmU2VydmljZUwyY3BDZmdUYWJsZSAxIH0NCg0KTWVmU2Vy dmljZUwyY3BDZmdFbnRyeSA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgbWVmU2VydmljZUwyY3BD ZmdJbmRleCAgICAgICAgIFVuc2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNlTDJjcENmZ0l0 ZW1OZXh0SW5kZXggVW5zaWduZWQzMiwNCiAgICAgIG1lZlNlcnZpY2VMMmNwQ2ZnUm93U3Rh dHVzICAgICBSb3dTdGF0dXMNCiAgICB9DQoNCm1lZlNlcnZpY2VMMmNwQ2ZnSW5kZXggT0JK RUNULVRZUEUNCiAgICBTWU5UQVggICAgICBVbnNpZ25lZDMyDQogICAgTUFYLUFDQ0VTUyAg bm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAgIkwyQ1AgaW5kZXggbnVtYmVyLCBpbmRpY2F0aW5nIHRoZSBzcGVjaWZp YyBMMkNQIHByb2ZpbGUiDQogICAgOjo9IHsgbWVmU2VydmljZUwyY3BDZmdFbnRyeSAxIH0N Cg0KbWVmU2VydmljZUwyY3BDZmdJdGVtTmV4dEluZGV4IE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNU QVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAiVmFsdWUgdG8g YmUgdXNlZCBhcyB0aGUgaW5kZXggb2YgdGhlIEwyQ1AgaXRlbSB0YWJsZSBlbnRyaWVzLg0K ICAgICAgICAgVGhpcyB2YWx1ZSBpcyBhdXRvbWF0aWNhbGx5IGluY3JlbWVudGVkIHdoZW4g YSByb3cgaXMgY3JlYXRlZA0KICAgICAgICAgaW4gdGhlIEwyQ1AgaXRlbSB0YWJsZS4gV2hl biB0aGUgbWFuYWdlbWVudCBlbnRpdHkgd2FudHMgdG8NCiAJICBjcmVhdGUgYSBuZXcgcm93 IGluIHRoZSBMMkNQIGl0ZW0gdGFibGUgdGhlIHZhbHVlIG9mIHRoaXMNCiAgICAgICAgIG9i amVjdCBpcyB1c2VkIHRvIGNyZWF0ZSB0aGUgc3BlY2lmaWMgaXRlbSByb3cuDQogICAgICAg ICANCiAgICAgICAgIEEgZ3JvdXAgb2YgTDJDUCBwcm90b2NvbHMgaXMgaW5kaWNhdGVkIGJ5 IHRoZSB1c2Ugb2YgdGhlDQogICAgICAgICBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1UYWJsZSwg d2hpY2ggYWxsb3dzIG1vcmUgdGhhbiBvbmUNCiAgICAgICAgIExheWVyIDIgUHJvdGNvbCB0 byBiZSBncm91cCB3aXRoIGEgTDJDUCBwcm9maWxlLg0KICAgICAgICAiDQogICAgREVGVkFM IHsgMSB9DQogICAgOjo9IHsgbWVmU2VydmljZUwyY3BDZmdFbnRyeSAyIH0NCg0KbWVmU2Vy dmljZUwyY3BDZmdSb3dTdGF0dXMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBSb3dT dGF0dXMNCiAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1 cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGUgc3RhdHVzIG9mIHRoZSByb3cu DQoNCiAgICAgICAgVGhlIHdyaXRhYmxlIGNvbHVtbnMgaW4gYSByb3cgY2Fubm90IGJlIGNo YW5nZWQgaWYgdGhlIHJvdw0KICAgICAgICBpcyBhY3RpdmUuIEFsbCBjb2x1bW5zIG11c3Qg aGF2ZSBhIHZhbGlkIHZhbHVlIGJlZm9yZSBhIHJvdw0KICAgICAgICBjYW4gYmUgYWN0aXZh dGVkLg0KICAgICAgICINCiAgIDo6PSB7IG1lZlNlcnZpY2VMMmNwQ2ZnRW50cnkgMyB9DQoN Cg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCi0tIEV0aGVybmV0IFNlcnZpY2UgTDJD UCBQcm9maWxlIEl0ZW0gVGFibGUNCi0tICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCm1l ZlNlcnZpY2VMMmNwQ2ZnSXRlbVRhYmxlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAg U0VRVUVOQ0UgT0YgTWVmU2VydmljZUwyY3BDZmdJdGVtRW50cnkNCiAgICBNQVgtQUNDRVNT ICBub3QtYWNjZXNzaWJsZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQ VElPTg0KICAgICAgICJUaGlzIHRhYmxlIHN1cHBvcnRzIEwyQ1Agc2V0dGluZ3MuIg0KICAg IFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDYuMV0sIFtNRUYgNy4yXSwgW01FRiAxMC4yXSIN CiAgICA6Oj0geyBtZWZTZXJ2aWNlTDJjcEF0dHJpYnV0ZXMgMyB9DQoNCm1lZlNlcnZpY2VM MmNwQ2ZnSXRlbUVudHJ5IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgTWVmU2Vydmlj ZUwyY3BDZmdJdGVtRW50cnkNCiAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJsZQ0KICAg IFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJMMkNQIHNl dHRpbmdzIHRhYmxlIGVudHJ5IG9uIGFuIGludGVyZmFjZS4iDQogICAgSU5ERVggeyBtZWZT ZXJ2aWNlTDJjcENmZ0luZGV4LCBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1JbmRleCB9DQogICAg Ojo9IHsgbWVmU2VydmljZUwyY3BDZmdJdGVtVGFibGUgMSB9DQoNCk1lZlNlcnZpY2VMMmNw Q2ZnSXRlbUVudHJ5IDo6PSBTRVFVRU5DRSB7DQogICAgICBtZWZTZXJ2aWNlTDJjcENmZ0l0 ZW1JbmRleCAgICAgICBVbnNpZ25lZDMyLA0KICAgICAgbWVmU2VydmljZUwyY3BDZmdJdGVt VHlwZSAgICAgICAgSU5URUdFUiwNCiAgICAgIG1lZlNlcnZpY2VMMmNwQ2ZnSXRlbU1hdGNo U2NvcGUgIElOVEVHRVIsDQogICAgICBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1NYWNBZGRyZXNz ICBNYWNBZGRyZXNzLA0KICAgICAgbWVmU2VydmljZUwyY3BDZmdJdGVtUHJvdG9jb2wgICAg VW5zaWduZWQzMiwNCiAgICAgIG1lZlNlcnZpY2VMMmNwQ2ZnSXRlbVN1YlR5cGUgICAgIFVu c2lnbmVkMzIsDQogICAgICBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1Sb3dTdGF0dXMgICBSb3dT dGF0dXMNCiAgICB9DQoNCm1lZlNlcnZpY2VMMmNwQ2ZnSXRlbUluZGV4IE9CSkVDVC1UWVBF DQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIG5vdC1hY2Nl c3NpYmxlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAg ICAgICJDb25maWd1cmVzIEwyQ1AgaW5kZXggbnVtYmVyIG9uIGFuIGludGVyZmFjZS4iDQog ICAgOjo9IHsgbWVmU2VydmljZUwyY3BDZmdJdGVtRW50cnkgMSB9DQoNCm1lZlNlcnZpY2VM MmNwQ2ZnSXRlbVR5cGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBJTlRFR0VSIHsN CiAgICAgICAgZGlzY2FyZCAgICgxKSwNCiAgICAgICAgdHVubmVsICAgICgyKSwNCiAgICAg ICAgcGVlciAgICAgICgzKSwNCiAgICAgICAgcGFzc1RvRXZjICg0KQ0KICAgIH0NCiAgICBN QVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBE RVNDUklQVElPTg0KICAgICAgICJDb25maWd1cmVzIEwyQ1AgdHlwZSBzZXR0aW5nLg0KDQog ICAgICAgIGRpc2NhcmQoMSkgICAgIHRoZSBpbmRpY2F0ZWQgTDJDUCBpcyBkaXNjYXJkZWQN CiAgICAgICAgdHVubmVsKDIpICAgICAgdGhlIGluZGljYXRlZCBMMkNQIGlzIHR1bm5lbGVk IChwYXNzZWQpDQogICAgICAgIHBlZXIoMykgICAgICAgIHRoZSBpbmRpY2F0ZWQgTDJDUCBp cyBwZWVyZWQgd2l0aCB0aGUgTkUNCiAgICAgICAgcGFzc1RvRXZjKDQpICAgdGhlIGluZGlj YXRlZCBMMkNQIGlzIHBhc3NlZCB0byB0aGUgRVZDIGZvcg0KICAgICAgICAgICAgICAgICAg ICAgICBFVkMgcHJvY2Vzc2luZyBvZiB0aGUgTDJDUC4gRmluYWwgTDJDUCANCiAgICAgICAg ICAgICAgICAgICAgICAgZGlzcG9zaXRpb24gaXMgYmFzZWQgdGhlIEwyQ1AgcHJvZmlsZSBm b3INCiAgICAgICAgICAgICAgICAgICAgICAgdGhlIEVWQyB0byBiZSB0dW5uZWxlZCwgZGlz Y2FyZGUsIG9yIHBlZXJlZC4NCiAgICAgICAgICAgICAgICAgICAgICAgVGhpcyB2YWx1ZSBp cyBub3QgdmFsaWQgZm9yIEVWQyBiYXNlZA0KICAgICAgICAgICAgICAgICAgICAgICBMMkNQ IEVWQ3MNCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjAs IDguMDsgW01FRiA2LjEuMV0gOC4wOyBbTUVGIDcuMl0gNi4yLjEuMiINCiAgICBERUZWQUwg eyB0dW5uZWwgfQ0KICAgIDo6PSB7IG1lZlNlcnZpY2VMMmNwQ2ZnSXRlbUVudHJ5IDIgfQ0K DQptZWZTZXJ2aWNlTDJjcENmZ0l0ZW1NYXRjaFNjb3BlIE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgSU5URUdFUiB7DQogICAgICAgIGRlc3RpbmF0aW9uQWRkcmVzc09ubHkgICAg ICAgICAoMSksDQogICAgICAgIGRhUGx1c1Byb3RvY29sICAgICAgICAgICAgICAgICAoMiks DQogICAgICAgIGRhUGx1c1Byb3RvY29sUGx1c1N1YnR5cGUgICAgICAoMykNCiAgICB9DQog ICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgREVTQ1JJUFRJT04NCiAgICAgICAiQ29uZmlndXJlcyBMMkNQIHNlbGVjdGlvbiBtYXRj aGluZyBzY29wZS4NCg0KICAgICAgICBkZXN0aW5hdGlvbkFkZHJlc3NPbmx5KDEpICAgICBM MkNQIHNlbGVjdGlvbiBpcyBkZXRlcm1pbmVkIGJ5DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1BQyBEZXN0aW5hdGlvbiBBZGRyZXNzIG9ubHkNCiAgICAgICAg ZGFQbHVzUHJvdG9jb2woMikgICAgICAgICAgICAgTDJDUCBzZWxlY3Rpb24gaXMgZGV0ZXJt aW5lZCBieQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNQUMgRGVz dGluYXRpb24gQWRkcmVzcyBwbHVzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFdGhlcm5ldCBwcm90b2NvbA0KICAgICAgICBkYVBsdXNQcm90b2NvbFBsdXNT dWJ0eXBlKDMpICBMMkNQIHNlbGVjdGlvbiBpcyBkZXRlcm1pbmVkIGJ5DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1BQyBEZXN0aW5hdGlvbiBBZGRyZXNzIHBs dXMgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IHBy b3RvY29sIHBsdXMgc3VidHlwZQ0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAi W01FRiA2LjFdIDYuMCwgOC4wOyBbTUVGIDYuMS4xXSA4LjA7IFtNRUYgNy4yXSA2LjIuMS4y Ig0KICAgIERFRlZBTCB7IGRlc3RpbmF0aW9uQWRkcmVzc09ubHkgfQ0KICAgIDo6PSB7IG1l ZlNlcnZpY2VMMmNwQ2ZnSXRlbUVudHJ5IDMgfQ0KDQptZWZTZXJ2aWNlTDJjcENmZ0l0ZW1N YWNBZGRyZXNzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgTWFjQWRkcmVzcw0KICAg IE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg IERFU0NSSVBUSU9ODQogICAgICAgICJDb25maWd1cmVzIEwyQ1AgRGVzdGluYXRpb24gTUFD IGFkZHJlc3MuDQoNCiAgICAgICAgIFZhbGlkIHZhbHVlcyBhcmUgMDEtODAtQzItMDAtMDAt MDAgdGhyb3VnaCAwMS04MC1DMi0wMC0wMC0wRiBhbmQNCiAgICAgICAgIDAxLTgwLUMyLTAw LTAwLTIwIHRocm91Z2ggMDEtODAtQzItMDAtMDAtMkYNCiAgICAgICAgIg0KICAgIERFRlZB TCB7ICcwMTgwQzIwMDAwMDAnSCB9DQogICAgOjo9IHsgbWVmU2VydmljZUwyY3BDZmdJdGVt RW50cnkgNCB9DQoNCm1lZlNlcnZpY2VMMmNwQ2ZnSXRlbVByb3RvY29sIE9CSkVDVC1UWVBF DQogICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3Jl YXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAg ICJDb25maWd1cmVzIEwyQ1AgcHJvdG9jb2wuIFRoZSBwcm90b2NvbCBpcyBkZWZpbmVkIGlu DQogICAgICAgICB0aGUgRXRoZXJ0eXBlIGZpZWxkIG9mIHRoZSBFdGhlcnR5cGUgZnJhbWUu IEZvciBpbnN0YW5jZSB0aGUNCiAgICAgICAgIEV0aGVydHlwZSBmb3IgTGluayBPQU0gaXMg MHg4ODA5LCBmb3IgRS1MTUkgaXQgaXMgMHg4OEVFLCBmb3INCiAgICAgICAgIExMRFAgaXQg aXMgMHg4OENDLg0KDQogICAgICAgICBWYWxpZCBwcm90b2NvbCB2YWx1ZXMgYXJlIGRlZmlu ZWQgYnkgTUVGIDYuMSBhbmQgTUVGIDYuMS4xLg0KICAgICAgICAiDQogICAgUkVGRVJFTkNF DQogICAgICAgIltNRUYgNi4xXSA2LjAsIDguMDsgW01FRiA2LjEuMV0gOC4wOyBbTUVGIDcu Ml0gNi4yLjEuMiINCiAgICBERUZWQUwgeyAwIH0NCiAgICA6Oj0geyBtZWZTZXJ2aWNlTDJj cENmZ0l0ZW1FbnRyeSA1IH0NCg0KbWVmU2VydmljZUwyY3BDZmdJdGVtU3ViVHlwZSBPQkpF Q1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFVuc2lnbmVkMzINCiAgICBNQVgtQUNDRVNTICBy ZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0K ICAgICAgICAiQ29uZmlndXJlcyBMMkNQIHN1YnR5cGUgZm9yIHRoZSBwcm90b2NvbCBzZWxl Y3RlZC4gRm9yIGluc3RhbmNlDQogICAgICAgICB0aGUgc3VidHlwZSBmb3IgTEFDUCBpcyAn MicgYW5kIExpbmsgT0FNIGlzICczJy4NCg0KICAgICAgICAgVmFsaWQgc3VidHlwZSB2YWx1 ZXMgYXJlIGRlZmluZWQgYnkgTUVGIDYuMSBhbmQgTUVGIDYuMS4xLg0KICAgICAgICAiDQog ICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgNi4xXSA2LjAsIDguMDsgW01FRiA2LjEuMV0g OC4wOyBbTUVGIDcuMl0gNi4yLjEuMiINCiAgICBERUZWQUwgeyAwIH0NCiAgICA6Oj0geyBt ZWZTZXJ2aWNlTDJjcENmZ0l0ZW1FbnRyeSA2IH0NCg0KbWVmU2VydmljZUwyY3BDZmdJdGVt Um93U3RhdHVzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgUm93U3RhdHVzDQogICAg TUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAg REVTQ1JJUFRJT04NCiAgICAgICAiVGhlIHN0YXR1cyBvZiB0aGUgcm93Lg0KDQogICAgICAg IFRoZSB3cml0YWJsZSBjb2x1bW5zIGluIGEgcm93IGNhbm5vdCBiZSBjaGFuZ2VkIGlmIHRo ZSByb3cNCiAgICAgICAgaXMgYWN0aXZlLiBBbGwgY29sdW1ucyBtdXN0IGhhdmUgYSB2YWxp ZCB2YWx1ZSBiZWZvcmUgYSByb3cNCiAgICAgICAgY2FuIGJlIGFjdGl2YXRlZC4NCiAgICAg ICAiDQogICA6Oj0geyBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1FbnRyeSA3IH0NCg0KDQotLSAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KLS0gRXRoZXJuZXQgU2VydmljZSBUcmFmZmljIFBl cmZvcm1hbmNlIERhdGEgU2V0IFRhYmxlDQotLSAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K DQptZWZTZXJ2aWNlUGVyZm9ybWFuY2VOZXh0SW5kZXggT0JKRUNULVRZUEUNCiAgICBTWU5U QVggICAgICBVbnNpZ25lZDMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0 IGNvbnRhaW5zIGFuIHVudXNlZCB2YWx1ZSBmb3IgYSBUcmFmZmljIFBlcmZvcm1hbmNlIERh dGENCiAgICAgICAgU2V0IHByb2ZpbGUgb24gYSBNRUYgY29tcGxpYW50IE5FLCBvciBhIHpl cm8gdG8gaW5kaWNhdGUgdGhhdCBub25lIA0KICAgICAgICBleGlzdC4gVGhpcyB2YWx1ZSBu ZWVkcyB0byBiZSByZWFkIGluIG9yZGVyIHRvIGZpbmQgYW4gYXZhaWxhYmxlIGluZGV4DQog ICAgICAgIGZvciByb3ctY3JlYXRpb24gb2YgYSBUcmFmZmljIFBlcmZvcm1hbmNlIERhdGEg U2V0IHByb2ZpbGUgYW5kIHRoZW4gDQogICAgICAgIHVzZWQgd2hlbiBhIHJvdyBpcyBjcmVh dGVkIGluIHRoZSBtZWZTZXJ2aWNlQndwQ2ZnSXRlbVRhYmxlLiBUaGlzIHZhbHVlDQogICAg ICAgIGlzIGF1dG9tYXRpY2FsbHkgdXBkYXRlZCBieSB0aGUgU05NUCBBZ2VudCBhZnRlciB0 aGUgcm93IGlzIGNyZWF0ZWQuDQoNCiAgICAgICAgQSBUcmFmZmljIFBlcmZvcm1hbmNlIERh dGEgU2V0IGNhbiBiZSBhc3NpZ25lZCB0byBhbiBJbnRlcmZhY2UsIGFuIEVWQywNCiAgICAg ICAgb3IgRVZDIHBsdXMgQ29TIGFzIGluZGljYXRlZCBieSB0aGUgYXNzb2NpYXRpb24gZm91 bmQgaW4gdGhlIA0KICAgICAgICBtZWZTZXJ2aWNlQndwQ2ZnSXRlbVRhYmxlLg0KDQogICAg ICAgIFJlZmVyZW50aWFsIGludGVncml0eSBpcyBuZWNlc3NhcnksIGkuZS4sIHRoZSBpbmRl eCBuZWVkcyB0byBiZQ0KICAgICAgICBwZXJzaXN0ZW50IHVwb24gYSByZWJvb3Qgb3IgcmVz dGFydCBvZiBhIE5FLiAgVGhlIGluZGV4DQogICAgICAgIGlzIG5ldmVyIHRvIGJlIHJldXNl ZCBmb3IgYSBuZXcgcGVyZm9ybWFuY2UgcHJvZmlsZSBvbiB0aGUgc2FtZSBNRUYNCiAgICAg ICAgY29tcGxpYW50IE5FIHVudGlsIGl0IHdyYXBzIHRvIHplcm8uICBUaGUgaW5kZXggdmFs dWUga2VlcHMNCiAgICAgICAgaW5jcmVhc2luZyB1cCB0byB0aGF0IHRpbWUuIFRoaXMgaXMg dG8gZmFjaWxpdGF0ZSBhY2Nlc3MgY29udHJvbCBiYXNlZA0KICAgICAgICBvbiBhIGZpeGVk IGluZGV4IGZvciBhbiBFTVMsIHNpbmNlIHRoZSBpbmRleCBpcyBub3QgcmV1c2VkLg0KICAg ICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiAxNV0gOC4yOyBbUS44NDAuMV0g Ni4yLjQiDQogICAgOjo9IHsgbWVmU2VydmljZVBlcmZBdHRyaWJ1dGVzIDEgfQ0KDQptZWZT ZXJ2aWNlUGVyZm9ybWFuY2VUYWJsZSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIFNF UVVFTkNFIE9GIE1lZlNlcnZpY2VQZXJmb3JtYW5jZUVudHJ5DQogICAgTUFYLUFDQ0VTUyAg bm90LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAiVGhpcyB0YWJsZSBzdXBwb3J0cyBUcmFmZmljIFBlcmZvcm1hbmNlIERh dGEgU2V0IHByb2ZpbGUgc2V0dGluZ3MuIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VQZXJmQXR0 cmlidXRlcyAyIH0NCg0KbWVmU2VydmljZVBlcmZvcm1hbmNlRW50cnkgT0JKRUNULVRZUEUN CiAgICBTWU5UQVggICAgICBNZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeQ0KICAgIE1BWC1B Q0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERF U0NSSVBUSU9ODQogICAgICAgIlRyYWZmaWMgUGVyZm9ybWFuY2UgRGF0YSBTZXQgcHJvZmls ZSBzZXR0aW5ncyB0YWJsZSBlbnRyeS4iDQogICAgSU5ERVggeyBtZWZTZXJ2aWNlUGVyZm9y bWFuY2VJbmRleCB9DQogICAgOjo9IHsgbWVmU2VydmljZVBlcmZvcm1hbmNlVGFibGUgMSB9 DQoNCk1lZlNlcnZpY2VQZXJmb3JtYW5jZUVudHJ5IDo6PSBTRVFVRU5DRSB7DQogICAgICBt ZWZTZXJ2aWNlUGVyZm9ybWFuY2VJbmRleCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VW5zaWduZWQzMiwNCiAgICAgIG1lZlNlcnZpY2VQZXJmb3JtYW5jZUluZ3Jlc3NHcmVlbkZy YW1lQ291bnQgICAgICAgICAgICBDb3VudGVyMzIsDQogICAgICBtZWZTZXJ2aWNlUGVyZm9y bWFuY2VJbmdyZXNzWWVsbG93RnJhbWVDb3VudCAgICAgICAgICAgQ291bnRlcjMyLA0KICAg ICAgbWVmU2VydmljZVBlcmZvcm1hbmNlSW5ncmVzc1JlZEZyYW1lQ291bnQgICAgICAgICAg ICAgIENvdW50ZXIzMiwNCiAgICAgIG1lZlNlcnZpY2VQZXJmb3JtYW5jZUluZ3Jlc3NHcmVl bk9jdGV0cyAgICAgICAgICAgICAgICBDb3VudGVyNjQsDQogICAgICBtZWZTZXJ2aWNlUGVy Zm9ybWFuY2VJbmdyZXNzWWVsbG93T2N0ZXRzICAgICAgICAgICAgICAgQ291bnRlcjY0LA0K ICAgICAgbWVmU2VydmljZVBlcmZvcm1hbmNlSW5ncmVzc1JlZE9jdGV0cyAgICAgICAgICAg ICAgICAgIENvdW50ZXI2NCwNCg0KICAgICAgbWVmU2VydmljZVBlcmZvcm1hbmNlSW5ncmVz c0dyZWVuRnJhbWVEaXNjYXJkcyAgICAgICAgIENvdW50ZXIzMiwNCiAgICAgIG1lZlNlcnZp Y2VQZXJmb3JtYW5jZUluZ3Jlc3NZZWxsb3dGcmFtZURpc2NhcmRzICAgICAgICBDb3VudGVy MzIsDQogICAgICBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VJbmdyZXNzR3JlZW5PY3RldHNEaXNj YXJkcyAgICAgICAgQ291bnRlcjY0LA0KICAgICAgbWVmU2VydmljZVBlcmZvcm1hbmNlSW5n cmVzc1llbGxvd09jdGV0c0Rpc2NhcmRzICAgICAgIENvdW50ZXI2NCwNCg0KICAgICAgbWVm U2VydmljZVBlcmZvcm1hbmNlRWdyZXNzR3JlZW5GcmFtZUNvdW50ICAgICAgICAgICAgIENv dW50ZXIzMiwNCiAgICAgIG1lZlNlcnZpY2VQZXJmb3JtYW5jZUVncmVzc1llbGxvd0ZyYW1l Q291bnQgICAgICAgICAgICBDb3VudGVyMzIsDQogICAgICBtZWZTZXJ2aWNlUGVyZm9ybWFu Y2VFZ3Jlc3NHcmVlbk9jdGV0cyAgICAgICAgICAgICAgICAgQ291bnRlcjY0LA0KICAgICAg bWVmU2VydmljZVBlcmZvcm1hbmNlRWdyZXNzWWVsbG93T2N0ZXRzICAgICAgICAgICAgICAg IENvdW50ZXI2NA0KICAgIH0NCg0KbWVmU2VydmljZVBlcmZvcm1hbmNlSW5kZXggT0JKRUNU LVRZUEUNCiAgICBTWU5UQVggICAgICBVbnNpZ25lZDMyDQogICAgTUFYLUFDQ0VTUyAgbm90 LWFjY2Vzc2libGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04N CiAgICAgICAgIiBUcmFmZmljIE1hbmFnZW1lbnQgRW50aXR5IFBlcmZvcm1hbmNlIERhdGEg Q291bnRlciANCiAgICAgICAgICBwcm9maWxlIGluZGV4IG51bWJlci4iDQogICAgOjo9IHsg bWVmU2VydmljZVBlcmZvcm1hbmNlRW50cnkgMSB9DQoNCm1lZlNlcnZpY2VQZXJmb3JtYW5j ZUluZ3Jlc3NHcmVlbkZyYW1lQ291bnQgICAgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAg ICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5kaWNh dGVzIHRoZSBudW1iZXIgb2YgZ3JlZW4gZnJhbWVzIHRoYXQgd2VyZSANCiAgICAgICAgcmVj ZWl2ZWQgb24gYSBORSBtZWFzdXJlbWVudCBlbnRpdHkuDQogICAgICAgIg0KICAgIFJFRkVS RU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6Oj0g eyBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeSAyIH0NCg0KbWVmU2VydmljZVBlcmZvcm1h bmNlSW5ncmVzc1llbGxvd0ZyYW1lQ291bnQgICAgT0JKRUNULVRZUEUNCiAgICBTWU5UQVgg ICAgICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5k aWNhdGVzIHRoZSBudW1iZXIgb2YgeWVsbG93IGZyYW1lcyB0aGF0IHdlcmUgDQogICAgICAg IHJlY2VpdmVkIG9uIGEgTkUgbWVhc3VyZW1lbnQgZW50aXR5Lg0KICAgICAgICINCiAgICBS RUZFUkVOQ0UNCiAgICAgICAiW01FRiAxNV0gOC4yOyBbUS44NDAuMV0gNi4yLjQiDQogICAg Ojo9IHsgbWVmU2VydmljZVBlcmZvcm1hbmNlRW50cnkgMyB9DQoNCm1lZlNlcnZpY2VQZXJm b3JtYW5jZUluZ3Jlc3NSZWRGcmFtZUNvdW50ICAgIE9CSkVDVC1UWVBFDQogICAgU1lOVEFY ICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVT ICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGlu ZGljYXRlcyB0aGUgbnVtYmVyIG9mIHJlZCBmcmFtZXMgdGhhdCB3ZXJlIA0KICAgICAgICBy ZWNlaXZlZCBvbiBhIE5FIG1lYXN1cmVtZW50IGVudGl0eS4NCiAgICAgICAiDQogICAgUkVG RVJFTkNFDQogICAgICAgIltNRUYgMTVdIDguMjsgW1EuODQwLjFdIDYuMi40Ig0KICAgIDo6 PSB7IG1lZlNlcnZpY2VQZXJmb3JtYW5jZUVudHJ5IDQgfQ0KDQptZWZTZXJ2aWNlUGVyZm9y bWFuY2VJbmdyZXNzR3JlZW5PY3RldHMgICBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAg IENvdW50ZXI2NA0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAg IGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0 ZXMgdGhlIG51bWJlciBvZiB2YWxpZCBncmVlbiBvY3RldHMgDQogICAgICAgIHRoYXQgd2Vy ZSByZWNlaXZlZCBvbiBhIE5FIG1lYXN1cmVtZW50IGVudGl0eS4NCiAgICAgICAiDQogICAg UkVGRVJFTkNFDQogICAgICAgIltNRUYgMTVdIDguMjsgW1EuODQwLjFdIDYuMi40Ig0KICAg IDo6PSB7IG1lZlNlcnZpY2VQZXJmb3JtYW5jZUVudHJ5IDUgfQ0KDQptZWZTZXJ2aWNlUGVy Zm9ybWFuY2VJbmdyZXNzWWVsbG93T2N0ZXRzICAgT0JKRUNULVRZUEUNCiAgICBTWU5UQVgg ICAgICBDb3VudGVyNjQNCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3QgaW5k aWNhdGVzIHRoZSBudW1iZXIgb2YgdmFsaWQgeWVsbG93IG9jdGV0cyANCiAgICAgICAgdGhh dCB3ZXJlIHJlY2VpdmVkIG9uIGEgTkUgbWVhc3VyZW1lbnQgZW50aXR5Lg0KICAgICAgICIN CiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiAxNV0gOC4yOyBbUS44NDAuMV0gNi4yLjQi DQogICAgOjo9IHsgbWVmU2VydmljZVBlcmZvcm1hbmNlRW50cnkgNiB9DQoNCm1lZlNlcnZp Y2VQZXJmb3JtYW5jZUluZ3Jlc3NSZWRPY3RldHMgICBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRB WCAgICAgIENvdW50ZXI2NA0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRV UyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBp bmRpY2F0ZXMgdGhlIG51bWJlciBvZiB2YWxpZCByZWQgb2N0ZXRzIA0KICAgICAgICB0aGF0 IHdlcmUgcmVjZWl2ZWQgb24gYSBORSBtZWFzdXJlbWVudCBlbnRpdHkuDQogICAgICAgIg0K ICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCIN CiAgICA6Oj0geyBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeSA3IH0NCg0KbWVmU2Vydmlj ZVBlcmZvcm1hbmNlSW5ncmVzc0dyZWVuRnJhbWVEaXNjYXJkcyBPQkpFQ1QtVFlQRQ0KICAg IFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAg IFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9i amVjdCBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiBncmVlbiBmcmFtZXMgdGhhdCB3ZXJlIA0K ICAgICAgICBkaXNjYXJkZWQgZHVlIHRvIGNvbmdlc3Rpb24gd2l0aGluIHRoZSBORSBtZWFz dXJlbWVudCBlbnRpdHkuDQogICAgICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVG IDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6Oj0geyBtZWZTZXJ2aWNlUGVyZm9y bWFuY2VFbnRyeSA4IH0NCg0KbWVmU2VydmljZVBlcmZvcm1hbmNlSW5ncmVzc1llbGxvd0Zy YW1lRGlzY2FyZHMgIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQog ICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg IERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMgb2JqZWN0IGluZGljYXRlcyB0aGUgbnVtYmVy IG9mIHllbGxvdyBmcmFtZXMgdGhhdCB3ZXJlIA0KICAgICAgICBkaXNjYXJkZWQgZHVlIHRv IGNvbmdlc3Rpb24gd2l0aGluIHRoZSBORSBtZWFzdXJlbWVudCBlbnRpdHkuDQogICAgICAg Ig0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIu NCINCiAgICA6Oj0geyBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeSA5IH0NCg0KbWVmU2Vy dmljZVBlcmZvcm1hbmNlSW5ncmVzc0dyZWVuT2N0ZXRzRGlzY2FyZHMgIE9CSkVDVC1UWVBF DQogICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5 DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRo aXMgb2JqZWN0IGluZGljYXRlcyB0aGUgbnVtYmVyIG9mIHZhbGlkIGdyZWVuIG9jdGV0cyAN CiAgICAgICAgdGhhdCB3ZXJlIGRpc2NhcmRlZCBkdWUgdG8gY29uZ2VzdGlvbiB3aXRoaW4g dGhlIE5FIA0KICAgICAgICBtZWFzdXJlbWVudCBlbnRpdHkuDQogICAgICAgIg0KICAgIFJF RkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6 Oj0geyBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeSAxMCB9DQoNCm1lZlNlcnZpY2VQZXJm b3JtYW5jZUluZ3Jlc3NZZWxsb3dPY3RldHNEaXNjYXJkcyAgT0JKRUNULVRZUEUNCiAgICBT WU5UQVggICAgICBDb3VudGVyNjQNCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmpl Y3QgaW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgdmFsaWQgeWVsbG93IG9jdGV0cyANCiAgICAg ICAgdGhhdCB3ZXJlIGRpc2NhcmRlZCBkdWUgdG8gY29uZ2VzdGlvbiB3aXRoaW4gdGhlIE5F IA0KICAgICAgICBtZWFzdXJlbWVudCBlbnRpdHkuDQogICAgICAgIg0KICAgIFJFRkVSRU5D RQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCINCiAgICA6Oj0geyBt ZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeSAxMSB9DQoNCm1lZlNlcnZpY2VQZXJmb3JtYW5j ZUVncmVzc0dyZWVuRnJhbWVDb3VudCAgICBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAg IENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAg IGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBpbmRpY2F0 ZXMgdGhlIG51bWJlciBvZiBncmVlbiBmcmFtZXMgdGhhdCB3ZXJlIA0KICAgICAgICB0cmFu c21pdHRlZCBvbiBhIE5FIG1lYXN1cmVtZW50IGVudGl0eS4NCiAgICAgICAiDQogICAgUkVG RVJFTkNFDQogICAgICAgIltNRUYgMTVdIDguMjsgW1EuODQwLjFdIDYuMi40Ig0KICAgIDo6 PSB7IG1lZlNlcnZpY2VQZXJmb3JtYW5jZUVudHJ5IDEyIH0NCg0KbWVmU2VydmljZVBlcmZv cm1hbmNlRWdyZXNzWWVsbG93RnJhbWVDb3VudCAgICBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRB WCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRV UyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlzIG9iamVjdCBp bmRpY2F0ZXMgdGhlIG51bWJlciBvZiB5ZWxsb3cgZnJhbWVzIHRoYXQgd2VyZSANCiAgICAg ICAgdHJhbnNtaXR0ZWQgb24gYSBORSBtZWFzdXJlbWVudCBlbnRpdHkuDQogICAgICAgIg0K ICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2LjIuNCIN CiAgICA6Oj0geyBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeSAxMyB9DQoNCm1lZlNlcnZp Y2VQZXJmb3JtYW5jZUVncmVzc0dyZWVuT2N0ZXRzICAgT0JKRUNULVRZUEUNCiAgICBTWU5U QVggICAgICBDb3VudGVyNjQNCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhpcyBvYmplY3Qg aW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgdmFsaWQgZ3JlZW4gb2N0ZXRzIA0KICAgICAgICB0 aGF0IHdlcmUgdHJhbnNtaXR0ZWQgb24gYSBORSBtZWFzdXJlbWVudCBlbnRpdHkuDQogICAg ICAgIg0KICAgIFJFRkVSRU5DRQ0KICAgICAgICJbTUVGIDE1XSA4LjI7IFtRLjg0MC4xXSA2 LjIuNCINCiAgICA6Oj0geyBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VFbnRyeSAxNCB9DQoNCm1l ZlNlcnZpY2VQZXJmb3JtYW5jZUVncmVzc1llbGxvd09jdGV0cyAgIE9CSkVDVC1UWVBFDQog ICAgU1lOVEFYICAgICAgQ291bnRlcjY0DQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQog ICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoaXMg b2JqZWN0IGluZGljYXRlcyB0aGUgbnVtYmVyIG9mIHZhbGlkIHllbGxvdyBvY3RldHMgDQog ICAgICAgIHRoYXQgd2VyZSB0cmFuc21pdHRlZCBvbiBhIE5FIG1lYXN1cmVtZW50IGVudGl0 eS4NCiAgICAgICAiDQogICAgUkVGRVJFTkNFDQogICAgICAgIltNRUYgMTVdIDguMjsgW1Eu ODQwLjFdIDYuMi40Ig0KICAgIDo6PSB7IG1lZlNlcnZpY2VQZXJmb3JtYW5jZUVudHJ5IDE1 IH0NCg0KDQotLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KLS0gTm90aWZpY2F0aW9uIENv bmZpZ3VyYXRpb24gT2JqZWN0cw0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KbWVm U2VydmljZU5vdGlmaWNhdGlvbkNmZ0FsYXJtRW5hYmxlIE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgQklUUyB7DQogICAgICAgICAgICAgICAgICAgICBiU2VydmljZUNvbmZpZ3Vy YXRpb25BbGFybSgwKQ0KICAgICAgICAgICAgICAgIH0NCiAgICBNQVgtQUNDRVNTICByZWFk LXdyaXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAg ICAgIkEgdmVjdG9yIG9mIGJpdHMgdGhhdCBpbmRpY2F0ZXMgd2hldGhlciBhIHNwZWNpZmlj IG5vdGlmaWNhdGlvbiBpcw0KICAgICAgICBlbmFibGVkLiANCg0KICAgICAgICBBIGJpdCBz ZXQgdG8gJzEnIGVuYWJsZXMgdGhlIHNwZWNpZmljIG5vdGlmaWNhdGlvbiBnZW5lcmF0aW9u LiANCg0KICAgICAgICBBIGJpdCBzZXQgdG8gJzAnIGRpc2FibGVzIHRoZSBzcGVjaWZpYyBu b3RpZmljYXRpb24uDQoNCiAgICAgICAgSWYgYSBwYXJ0aWN1bGFyIGFsYXJtIGlzIG5vdCBz dXBwb3J0ZWQgdGhlIEJJVCB2YWx1ZSBvZiB0aGUgZW5hYmxlL2Rpc2FibGUNCiAgICAgICAg aXMgc2V0IHRvICcwJy4NCg0KICAgICAgICBiU2VydmljZUNvbmZpZ3VyYXRpb25BbGFybSgw KSAgZW5hYmxlcy9kaXNhYmxlcyBtZWZTZXJ2aWNlQ29uZmlndXJhdGlvbkFsYXJtDQogICAg ICAgIg0KICAgIERFRlZBTCB7IHsgfSB9DQogICAgOjo9IHsgbWVmU2VydmljZU5vdGlmaWNh dGlvbkNmZyAxIH0NCg0KDQotLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KLS0gTm90aWZp Y2F0aW9uIERhdGEgT2JqZWN0cw0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KbWVm U2VydmljZU5vdGlmaWNhdGlvbk9iakRhdGVBbmRUaW1lIE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgRGF0ZUFuZFRpbWUNCiAgICBNQVgtQUNDRVNTICBhY2Nlc3NpYmxlLWZvci1u b3RpZnkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAiVGhpcyBvYmplY3QgY29udGFpbnMgdGhlIHRpbWUgYW5kIGRhdGUgYXQgdGhlIHRpbWUg dGhhdA0KICAgICAgICB0aGUgbm90aWZpY2F0aW9uIGV2ZW50IGlzIGRldGVjdGVkLCBub3Qg dGhlIHRpbWUgb2YgdGhlIG5vdGlmaWNhdGlvbg0KICAgICAgICBnZW5lcmF0aW9uLg0KDQog ICAgICAgIFRoaXMgb2JqZWN0IGlzIHVzZWQgb25seSBmb3Igbm90aWZpY2F0aW9ucy4gVGhl IG1lY2hhbmlzbSB0byBzZXQgYW5kIGtlZXANCiAgICAgICAgY3VycmVudCB0aGUgZGF0ZSBh bmQgdGltZSBpcyBub3Qgc3BlY2lmaWVkLg0KICAgICAgICINCiAgICA6Oj0geyBtZWZTZXJ2 aWNlTm90aWZpY2F0aW9uT2JqIDEgfQ0KDQptZWZTZXJ2aWNlTm90aWZpY2F0aW9uQ29uZmln dXJhdGlvbkNoYW5nZVR5cGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBJTlRFR0VS IHsNCiAgICAgICAgICAgICAgICAgIGVudHJ5QWRkZWQgICAgICgxKSwNCiAgICAgICAgICAg ICAgICAgIGVudHJ5RGVsZXRlZCAgICgyKSwNCiAgICAgICAgICAgICAgICAgIGVudHJ5TW9k aWZpZWQgICgzKQ0KICAgICAgICAgICAgICAgIH0NCiAgICBNQVgtQUNDRVNTICBhY2Nlc3Np YmxlLWZvci1ub3RpZnkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAiVGhlIE5vdGlmaWNhdGlvbiBDb25maWd1cmF0aW9uIENoYW5nZSBUeXBl IG9mIHRoZSBvYmplY3QgdGhhdCBjYXVzZWQgdGhlDQogICAgICAgIGdlbmVyYXRpb24uDQoN CiAgICAgICAgZW50cnlBZGRlZCgxKSAgICBpbmRpY2F0ZXMgdGhhdCB0aGUgc3BlY2lmaWMg b2JqZWN0L3NlcnZpY2Ugd2FzIGFkZGVkDQogICAgICAgIGVudHJ5RGVsZXRlKDIpICAgaW5k aWNhdGVzIHRoYXQgdGhlIHNwZWNpZmljIG9iamVjdC9zZXJ2aWNlIHdhcyBkZWxldGVkDQog ICAgICAgIGVudHJ5TW9kaWZpZWQoMykgaW5kaWNhdGVzIHRoYXQgdGhlIHNwZWNpZmljIG9i amVjdC9zZXJ2aWNlIHdhcyBtb2RpZmllZA0KDQogICAgICAgIFRoaXMgb2JqZWN0IGlzIG9u bHkgdXNlZCBmb3IgdGhlIG5vdGlmaWNhdGlvbi4NCiAgICAgICAiDQogICAgUkVGRVJFTkNF DQogICAgICAgIltNRUYgNy4yXSA2LjIuMS4xLCA2LjIuMS4yLCA2LjIuMS4zIg0KICAgIDo6 PSB7IG1lZlNlcnZpY2VOb3RpZmljYXRpb25PYmogMiB9DQoNCm1lZlNlcnZpY2VPYmplY3RJ ZCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIE9CSkVDVCBJREVOVElGSUVSDQogICAg TUFYLUFDQ0VTUyAgYWNjZXNzaWJsZS1mb3Itbm90aWZ5DQogICAgU1RBVFVTICAgICAgY3Vy cmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoZSBPYmplY3QgSWRlbnRpZmllciBv ZiB0aGUgb2JqZWN0IHRoYXQgY2F1c2VkIHRoZSBnZW5lcmF0aW9uIG9mIHRoZQ0KICAgICAg ICBub3RpZmljYXRpb24uDQoNCiAgICAgICAgVGhpcyBvYmplY3QgaXMgb25seSB1c2VkIGZv ciB0aGUgbm90aWZpY2F0aW9uLg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAi W01FRiA3LjJdIDYuMi4xLjEsIDYuMi4xLjIsIDYuMi4xLjMiDQogICAgOjo9IHsgbWVmU2Vy dmljZU5vdGlmaWNhdGlvbk9iaiAzIH0NCg0KDQotLSAqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KLS0gTk9USUZJQ0FUSU9OUyAoVFJBUFMpDQotLSAqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KDQotLSBbRWRpdG9yIE5vdGU6IFNob3VsZCB0aGlzIGFsYXJtIGJlIG1hbmRhdG9yeSBv ciBvcHRpb25hbD9dDQoNCm1lZlNlcnZpY2VDb25maWd1cmF0aW9uQWxhcm0gTk9USUZJQ0FU SU9OLVRZUEUNCiAgICBPQkpFQ1RTICAgICB7DQogICAgICAgICAgICAgICAgbWVmU2Vydmlj ZU5vdGlmaWNhdGlvbk9iakRhdGVBbmRUaW1lLA0KICAgICAgICAgICAgICAgIG1lZlNlcnZp Y2VOb3RpZmljYXRpb25Db25maWd1cmF0aW9uQ2hhbmdlVHlwZSwNCiAgICAgICAgICAgICAg ICBtZWZTZXJ2aWNlT2JqZWN0SWQNCiAgICAgICAgICAgICAgICB9DQogICAgU1RBVFVTICAg ICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIkFuIG1lZlNlcnZpY2VDb25m aWd1cmF0aW9uQWxhcm0gbm90aWZpY2F0aW9uIGlzIHNlbnQgd2hlbiB0aGUgY29uZmlndXJh dGlvbg0KICAgICAgICBvZiBhbiBvYmplY3Qgb3Igc2VydmljZSBpcyBhZGRlZCwgZGVsZXRl ZCwgb3IgbW9kaWZpZWQuDQoNCiAgICAgICAgVGhlIG1hbmFnZW1lbnQgZW50aXR5IHRoYXQg cmVjZWl2ZXMgdGhlIG5vdGlmaWNhdGlvbiBjYW4gaWRlbnRpZnkNCiAgICAgICAgdGhlIHN5 c3RlbSBmcm9tIHRoZSBuZXR3b3JrIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBub3RpZmljYXRp b24sDQogICAgICAgIGFuZCBjYW4gaWRlbnRpZnkgdGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdl IGJ5IHRoZSBpbmRpY2VzIGluIHRoZQ0KICAgICAgICBtZWZTZXJ2aWNlT2JqZWN0SWQgT0lE Lg0KICAgICAgICINCiAgICBSRUZFUkVOQ0UNCiAgICAgICAiW01FRiA3LjJdIDYuMi4xLjEs IDYuMi4xLjIsIDYuMi4xLjMiDQogICAgOjo9IHsgbWVmU2VydmljZU5vdGlmaWNhdGlvbnMg MSB9DQoNCg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCi0tIFNFUlZJQ0UtVU5JIE1J QiBNb2R1bGUgLSBDb25mb3JtYW5jZSBJbmZvcm1hdGlvbg0KLS0gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCg0KbWVmU2VydmljZVVuaUV2Y01pYkNvbXBsaWFuY2VzIE9CSkVDVCBJREVO VElGSUVSIDo6PSB7IG1lZlNlcnZpY2VNaWJDb25mb3JtYW5jZSAxIH0NCm1lZlNlcnZpY2VV bmlFdmNNaWJHcm91cHMgICAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBtZWZTZXJ2aWNl TWliQ29uZm9ybWFuY2UgMiB9DQoNCg0KLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQotLSBTRVJWSUNFLVVO SSBNSUIgVW5pdHMgb2YgY29uZm9ybWFuY2UNCi0tICoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQptZWZTZXJ2 aWNlSW50ZXJmYWNlTWFuZGF0b3J5R3JvdXAgT0JKRUNULUdST1VQDQogICAgT0JKRUNUUyB7 DQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnVHlwZSwNCiAgICAgIG1lZlNlcnZpY2VJ bnRlcmZhY2VDZmdJZGVudGlmaWVyLA0KICAgICAgbWVmU2VydmljZUludGVyZmFjZUNmZ01v ZGUsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnRnJhbWVGb3JtYXQsDQogICAgICBt ZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnSW5ncmVzc0J3cEluZGV4LA0KICAgICAgbWVmU2Vydmlj ZUludGVyZmFjZUNmZ0VncmVzc0J3cEluZGV4LA0KICAgICAgbWVmU2VydmljZUludGVyZmFj ZUNmZ0wyY3BJbmRleCwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VTdGF0dXNUeXBlLA0K ICAgICAgbWVmU2VydmljZUludGVyZmFjZVN0YXR1c1BoeXNpY2FsTGF5ZXIsDQogICAgICBt ZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVzTWF4VmMsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJm YWNlU3RhdHVzTWF4RW5kUG9pbnRQZXJWYywNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VT dGF0aXN0aWNzSW5ncmVzc1VuZGVyc2l6ZWQsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNl U3RhdGlzdGljc0luZ3Jlc3NPdmVyc2l6ZWQsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNl U3RhdGlzdGljc0luZ3Jlc3NGcmFnbWVudHMsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNl U3RhdGlzdGljc0luZ3Jlc3NDcmNBbGlnbm1lbnQsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJm YWNlU3RhdGlzdGljc0luZ3Jlc3NJbnZhbGlkVmlkLA0KICAgICAgbWVmU2VydmljZUludGVy ZmFjZVN0YXRpc3RpY3NJbmdyZXNzT2N0ZXRzLA0KICAgICAgbWVmU2VydmljZUludGVyZmFj ZVN0YXRpc3RpY3NJbmdyZXNzVW5pY2FzdCwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VT dGF0aXN0aWNzSW5ncmVzc011bHRpY2FzdCwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VT dGF0aXN0aWNzSW5ncmVzc0Jyb2FkY2FzdCwNCiAgICAgIG1lZlNlcnZpY2VJbnRlcmZhY2VT dGF0aXN0aWNzRWdyZXNzT2N0ZXRzLA0KICAgICAgbWVmU2VydmljZUludGVyZmFjZVN0YXRp c3RpY3NFZ3Jlc3NVbmljYXN0LA0KICAgICAgbWVmU2VydmljZUludGVyZmFjZVN0YXRpc3Rp Y3NFZ3Jlc3NNdWx0aWNhc3QsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdGlzdGlj c0VncmVzc0Jyb2FkY2FzdA0KICAgIH0NCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAg REVTQ1JJUFRJT04NCiAgICAgICAiTWFuZGF0b3J5IG9iamVjdHMgZm9yIHRoZSBJbnRlcmZh Y2UgZ3JvdXAuIg0KICAgIDo6PSB7IG1lZlNlcnZpY2VVbmlFdmNNaWJHcm91cHMgMSB9DQoN Cg0KbWVmU2VydmljZUludGVyZmFjZU9wdGlvbmFsR3JvdXAgT0JKRUNULUdST1VQDQogICAg T0JKRUNUUyB7DQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlQ2ZnTmVnb3RpYXRlLA0KICAg ICAgbWVmU2VydmljZUludGVyZmFjZUNmZ0Zsb3dDb250cm9sLA0KICAgICAgbWVmU2Vydmlj ZUludGVyZmFjZVN0YXR1c01vZGUsDQogICAgICBtZWZTZXJ2aWNlSW50ZXJmYWNlU3RhdHVz Rmxvd0NvbnRyb2wNCiAgICB9DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NS SVBUSU9ODQogICAgICAgIk9wdGlvbmFsIG9iamVjdHMgZm9yIHRoZSBJbnRlcmZhY2UgQXR0 cmlidXRlcyBncm91cC4iDQogICAgOjo9IHsgbWVmU2VydmljZVVuaUV2Y01pYkdyb3VwcyAy IH0NCg0KDQptZWZTZXJ2aWNlVW5pTWFuZGF0b3J5R3JvdXAgT0JKRUNULUdST1VQDQogICAg T0JKRUNUUyB7DQogICAgICBtZWZTZXJ2aWNlVW5pQ2ZnSWRlbnRpZmllciwNCiAgICAgIG1l ZlNlcnZpY2VVbmlDZmdCdW5kbGluZ011bHRpcGxleCwNCiAgICAgIG1lZlNlcnZpY2VVbmlD ZmdDZVZpZFVudGFnZ2VkLA0KICAgICAgbWVmU2VydmljZVVuaUNmZ0NlUHJpb3JpdHlVbnRh Z2dlZCwNCiAgICAgIG1lZlNlcnZpY2VFdmNQZXJVbmlDZmdTZXJ2aWNlVHlwZSwNCiAgICAg IG1lZlNlcnZpY2VFdmNQZXJVbmlDZmdJZGVudGlmaWVyLA0KICAgICAgbWVmU2VydmljZUV2 Y1BlclVuaUNmZ0NlVmxhbk1hcCwNCiAgICAgIG1lZlNlcnZpY2VFdmNQZXJVbmlDZmdJbmdy ZXNzQndwSW5kZXgsDQogICAgICBtZWZTZXJ2aWNlRXZjUGVyVW5pQ2ZnSW5ncmVzc0Nvc0lu ZGV4LA0KICAgICAgbWVmU2VydmljZUV2Y1BlclVuaUNmZ0VncmVzc0J3cEluZGV4LA0KICAg ICAgbWVmU2VydmljZUV2Y1BlclVuaUNmZ0VncmVzc0Nvc0luZGV4DQogICAgfQ0KICAgIFNU QVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJNYW5kYXRvcnkg b2JqZWN0cyBmb3IgdGhlIFVOSSBBdHRyaWJ1dGVzIGdyb3VwLiINCiAgICA6Oj0geyBtZWZT ZXJ2aWNlVW5pRXZjTWliR3JvdXBzIDMgfQ0KDQoNCm1lZlNlcnZpY2VFdmNNYW5kYXRvcnlH cm91cCBPQkpFQ1QtR1JPVVANCiAgICBPQkpFQ1RTIHsNCiAgICAgIG1lZlNlcnZpY2VFdmNO ZXh0SW5kZXgsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnSWRlbnRpZmllciwNCiAgICAgIG1l ZlNlcnZpY2VFdmNDZmdTZXJ2aWNlVHlwZSwNCiAgICAgIG1lZlNlcnZpY2VFdmNDZmdNdHVT aXplLA0KICAgICAgbWVmU2VydmljZUV2Y0NmZ0NldmxhbklkUHJlc2VydmF0aW9uLA0KICAg ICAgbWVmU2VydmljZUV2Y0NmZ0NldmxhbkNvc1ByZXNlcnZhdGlvbiwNCiAgICAgIG1lZlNl cnZpY2VFdmNDZmdMMmNwSW5kZXgsDQogICAgICBtZWZTZXJ2aWNlRXZjQ2ZnQWRtaW5TdGF0 ZSwNCiAgICAgIG1lZlNlcnZpY2VFdmNDZmdSb3dTdGF0dXMsDQogICAgICBtZWZTZXJ2aWNl RXZjVW5pQ2ZnVHlwZSwNCiAgICAgIG1lZlNlcnZpY2VFdmNTdGF0dXNNYXhNdHVTaXplLA0K ICAgICAgbWVmU2VydmljZUV2Y1N0YXR1c01heE51bVVuaSwNCiAgICAgIG1lZlNlcnZpY2VF dmNTdGF0dXNPcGVyYXRpb25hbFN0YXRlDQogICAgfQ0KICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJNYW5kYXRvcnkgb2JqZWN0cyBmb3IgdGhl IEVWQyBBdHRyaWJ1dGVzIGdyb3VwLiINCiAgICA6Oj0geyBtZWZTZXJ2aWNlVW5pRXZjTWli R3JvdXBzIDQgfQ0KDQoNCm1lZlNlcnZpY2VFdmNPcHRpb25hbEdyb3VwIE9CSkVDVC1HUk9V UA0KICAgIE9CSkVDVFMgew0KICAgICAgbWVmU2VydmljZUV2Y0NmZ1VuaWNhc3REZWxpdmVy eSwNCiAgICAgIG1lZlNlcnZpY2VFdmNDZmdNdWx0aWNhc3REZWxpdmVyeSwNCiAgICAgIG1l ZlNlcnZpY2VFdmNDZmdCcm9hZGNhc3REZWxpdmVyeQ0KICAgIH0NCiAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiT3B0aW9uYWwgb2JqZWN0cyBm b3IgdGhlIEVWQyBBdHRyaWJ1dGVzIGdyb3VwLiINCiAgICA6Oj0geyBtZWZTZXJ2aWNlVW5p RXZjTWliR3JvdXBzIDUgfQ0KDQoNCm1lZlNlcnZpY2VCd3BNYW5kYXRvcnlHcm91cCBPQkpF Q1QtR1JPVVANCiAgICBPQkpFQ1RTIHsNCiAgICAgIG1lZlNlcnZpY2VCd3BOZXh0SW5kZXgs DQogICAgICBtZWZTZXJ2aWNlQndwQ2ZnSXRlbU5leHRJbmRleCwNCiAgICAgIG1lZlNlcnZp Y2VCd3BDZmdSb3dTdGF0dXMsDQogICAgICBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUlkZW50aWZp ZXIsDQogICAgICBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUNpciwNCiAgICAgIG1lZlNlcnZpY2VC d3BDZmdJdGVtQ2JzLA0KICAgICAgbWVmU2VydmljZUJ3cENmZ0l0ZW1FaXIsDQogICAgICBt ZWZTZXJ2aWNlQndwQ2ZnSXRlbUVicywNCiAgICAgIG1lZlNlcnZpY2VCd3BDZmdJdGVtQ20s DQogICAgICBtZWZTZXJ2aWNlQndwQ2ZnSXRlbUNmLA0KICAgICAgbWVmU2VydmljZUJ3cENm Z0l0ZW1Db3NJbmRleCwNCiAgICAgIG1lZlNlcnZpY2VCd3BDZmdJdGVtUGVyZm9ybWFuY2VJ bmRleCwNCiAgICAgIG1lZlNlcnZpY2VCd3BDZmdJdGVtUm93U3RhdHVzDQogICAgfQ0KICAg IFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJNYW5kYXRv cnkgb2JqZWN0cyBmb3IgdGhlIEJXUCBBdHRyaWJ1dGVzIGdyb3VwLiINCiAgICA6Oj0geyBt ZWZTZXJ2aWNlVW5pRXZjTWliR3JvdXBzIDYgfQ0KDQoNCm1lZlNlcnZpY2VDb3NNYW5kYXRv cnlHcm91cCBPQkpFQ1QtR1JPVVANCiAgICBPQkpFQ1RTIHsNCiAgICAgIG1lZlNlcnZpY2VD b3NOZXh0SW5kZXgsDQogICAgICBtZWZTZXJ2aWNlQ29zQ2ZnSWRlbnRpZmllciwNCiAgICAg IG1lZlNlcnZpY2VDb3NDZmdUeXBlLA0KICAgICAgbWVmU2VydmljZUNvc0NmZ0lkZW50aWZp ZXJMaXN0LA0KICAgICAgbWVmU2VydmljZUNvc0NmZ1Jvd1N0YXR1cw0KICAgIH0NCiAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiTWFuZGF0b3J5 IG9iamVjdHMgZm9yIHRoZSBCV1AgQXR0cmlidXRlcyBncm91cC4iDQogICAgOjo9IHsgbWVm U2VydmljZVVuaUV2Y01pYkdyb3VwcyA3IH0NCg0KDQptZWZTZXJ2aWNlTDJjcE1hbmRhdG9y eUdyb3VwIE9CSkVDVC1HUk9VUA0KICAgIE9CSkVDVFMgew0KICAgICAgbWVmU2VydmljZUwy Y3BOZXh0SW5kZXgsDQogICAgICBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1OZXh0SW5kZXgsDQog ICAgICBtZWZTZXJ2aWNlTDJjcENmZ1Jvd1N0YXR1cywNCiAgICAgIG1lZlNlcnZpY2VMMmNw Q2ZnSXRlbVR5cGUsDQogICAgICBtZWZTZXJ2aWNlTDJjcENmZ0l0ZW1NYXRjaFNjb3BlLA0K ICAgICAgbWVmU2VydmljZUwyY3BDZmdJdGVtTWFjQWRkcmVzcywNCiAgICAgIG1lZlNlcnZp Y2VMMmNwQ2ZnSXRlbVByb3RvY29sLA0KICAgICAgbWVmU2VydmljZUwyY3BDZmdJdGVtU3Vi VHlwZSwNCiAgICAgIG1lZlNlcnZpY2VMMmNwQ2ZnSXRlbVJvd1N0YXR1cw0KICAgIH0NCiAg ICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiTWFuZGF0 b3J5IG9iamVjdHMgZm9yIHRoZSBMMkNQIEF0dHJpYnV0ZXMgZ3JvdXAuIg0KICAgIDo6PSB7 IG1lZlNlcnZpY2VVbmlFdmNNaWJHcm91cHMgOCB9DQoNCg0KbWVmU2VydmljZVBlcmZvcm1h bmNlTWFuZGF0b3J5R3JvdXAgT0JKRUNULUdST1VQDQogICAgT0JKRUNUUyB7DQogICAgICBt ZWZTZXJ2aWNlUGVyZm9ybWFuY2VOZXh0SW5kZXgsDQogICAgICBtZWZTZXJ2aWNlUGVyZm9y bWFuY2VJbmdyZXNzR3JlZW5GcmFtZUNvdW50LA0KICAgICAgbWVmU2VydmljZVBlcmZvcm1h bmNlSW5ncmVzc0dyZWVuT2N0ZXRzLA0KICAgICAgbWVmU2VydmljZVBlcmZvcm1hbmNlRWdy ZXNzR3JlZW5GcmFtZUNvdW50LA0KICAgICAgbWVmU2VydmljZVBlcmZvcm1hbmNlRWdyZXNz R3JlZW5PY3RldHMsDQogICAgICBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VSb3dTdGF0dXMNCiAg ICB9DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAg Ik1hbmRhdG9yeSBvYmplY3RzIGZvciB0aGUgUGVyZm9ybWFuY2UgQXR0cmlidXRlcyBncm91 cC4iDQogICAgOjo9IHsgbWVmU2VydmljZVVuaUV2Y01pYkdyb3VwcyA5IH0NCg0KDQptZWZT ZXJ2aWNlUGVyZm9ybWFuY2VPcHRpb25hbEdyb3VwIE9CSkVDVC1HUk9VUA0KICAgIE9CSkVD VFMgew0KICAgICAgbWVmU2VydmljZVBlcmZvcm1hbmNlSW5ncmVzc1llbGxvd0ZyYW1lQ291 bnQsDQogICAgICBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VJbmdyZXNzUmVkRnJhbWVDb3VudCwN CiAgICAgIG1lZlNlcnZpY2VQZXJmb3JtYW5jZUluZ3Jlc3NZZWxsb3dPY3RldHMsDQogICAg ICBtZWZTZXJ2aWNlUGVyZm9ybWFuY2VJbmdyZXNzUmVkT2N0ZXRzLA0KICAgICAgbWVmU2Vy dmljZVBlcmZvcm1hbmNlRWdyZXNzWWVsbG93RnJhbWVDb3VudCwNCiAgICAgIG1lZlNlcnZp Y2VQZXJmb3JtYW5jZUVncmVzc1llbGxvd09jdGV0cywNCiAgICAgIG1lZlNlcnZpY2VQZXJm b3JtYW5jZUluZ3Jlc3NHcmVlbkZyYW1lRGlzY2FyZHMsDQogICAgICBtZWZTZXJ2aWNlUGVy Zm9ybWFuY2VJbmdyZXNzWWVsbG93RnJhbWVEaXNjYXJkcywNCiAgICAgIG1lZlNlcnZpY2VQ ZXJmb3JtYW5jZUluZ3Jlc3NHcmVlbk9jdGV0c0Rpc2NhcmRzLA0KICAgICAgbWVmU2Vydmlj ZVBlcmZvcm1hbmNlSW5ncmVzc1llbGxvd09jdGV0c0Rpc2NhcmRzLA0KICAgIH0NCiAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiT3B0aW9uYWwg b2JqZWN0cyBmb3IgdGhlIFBlcmZvcm1hbmNlIEF0dHJpYnV0ZXMgZ3JvdXAuIg0KICAgIDo6 PSB7IG1lZlNlcnZpY2VVbmlFdmNNaWJHcm91cHMgMTAgfQ0KDQoNCm1lZlNlcnZpY2VOb3Rp ZmljYXRpb25PYmpNYW5kYXRvcnlHcm91cCBPQkpFQ1QtR1JPVVANCiAgICBPQkpFQ1RTIHsN CiAgICAgIG1lZlNlcnZpY2VOb3RpZmljYXRpb25DZmdBbGFybUVuYWJsZSwgICAgICANCiAg ICAgIG1lZlNlcnZpY2VOb3RpZmljYXRpb25PYmpEYXRlQW5kVGltZSwNCiAgICAgIG1lZlNl cnZpY2VOb3RpZmljYXRpb25Db25maWd1cmF0aW9uQ2hhbmdlVHlwZSwNCiAgICAgIG1lZlNl cnZpY2VPYmplY3RJZA0KICAgIH0NCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVT Q1JJUFRJT04NCiAgICAgICAiTWFuZGF0b3J5IG9iamVjdHMgZm9yIHRoZSBOb3RpZmljYXRp b24gT2JqZWN0IGdyb3VwLiINCiAgICA6Oj0geyBtZWZTZXJ2aWNlVW5pRXZjTWliR3JvdXBz IDExIH0NCg0KDQptZWZTZXJ2aWNlTm90aWZpY2F0aW9uc01hbmRhdG9yeUdyb3VwIE5PVElG SUNBVElPTi1HUk9VUA0KICAgIE5PVElGSUNBVElPTlMgew0KICAgICAgbWVmU2VydmljZUNv bmZpZ3VyYXRpb25BbGFybQ0KICAgIH0NCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAg REVTQ1JJUFRJT04NCiAgICAgICAiTWFuZGF0b3J5IG5vdGlmaWNhdGlvbnMgZm9yIHRoZSBO b3RpZmljYXRpb25zIGdyb3VwLiINCiAgICA6Oj0geyBtZWZTZXJ2aWNlVW5pRXZjTWliR3Jv dXBzIDEyIH0NCg0KDQotLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCi0tIFVOSS1FVkMgTUlCIE1vZHVsZSBD b21wbGlhbmNlIHN0YXRlbWVudHMNCi0tICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQptZWZTZXJ2aWNlVW5p TWliQ29tcGxpYW5jZSBNT0RVTEUtQ09NUExJQU5DRQ0KICAgIFNUQVRVUyAgICAgICBjdXJy ZW50DQogICAgREVTQ1JJUFRJT04gIlRoZSBjb21wbGlhbmNlIHN0YXRlbWVudCBmb3IgdGhl IEV0aGVybmV0IFNlcnZpY2UgVU5JIE1JQi4iDQogICAgTU9EVUxFDQogICAgICAgIE1BTkRB VE9SWS1HUk9VUFMgew0KICAgICAgICAgICAgbWVmU2VydmljZUludGVyZmFjZU1hbmRhdG9y eUdyb3VwLA0KICAgICAgICAgICAgbWVmU2VydmljZVVuaU1hbmRhdG9yeUdyb3VwLA0KICAg ICAgICAgICAgbWVmU2VydmljZUV2Y01hbmRhdG9yeUdyb3VwLA0KICAgICAgICAgICAgbWVm U2VydmljZUJ3cE1hbmRhdG9yeUdyb3VwLA0KICAgICAgICAgICAgbWVmU2VydmljZUNvc01h bmRhdG9yeUdyb3VwLA0KICAgICAgICAgICAgbWVmU2VydmljZUwyY3BNYW5kYXRvcnlHcm91 cCwNCiAgICAgICAgICAgIG1lZlNlcnZpY2VQZXJmb3JtYW5jZU1hbmRhdG9yeUdyb3VwLA0K ICAgICAgICAgICAgbWVmU2VydmljZU5vdGlmaWNhdGlvbk9iak1hbmRhdG9yeUdyb3VwLA0K ICAgICAgICAgICAgbWVmU2VydmljZU5vdGlmaWNhdGlvbnNNYW5kYXRvcnlHcm91cA0KICAg ICAgICB9DQoNCiAgICBHUk9VUCBtZWZTZXJ2aWNlSW50ZXJmYWNlT3B0aW9uYWxHcm91cA0K ICAgIERFU0NSSVBUSU9OICJUaGUgbWVmU2VydmljZUludGVyZmFjZU9wdGlvbmFsR3JvdXAg aXMgYW4gb3B0aW9uYWwgDQogICAgICAgIHJlcXVpcmVtZW50LiINCg0KICAgIEdST1VQIG1l ZlNlcnZpY2VFdmNPcHRpb25hbEdyb3VwDQogICAgREVTQ1JJUFRJT04gIlRoZSBtZWZTZXJ2 aWNlRXZjT3B0aW9uYWxHcm91cCBpcyBhbiBvcHRpb25hbCANCiAgICAgICAgcmVxdWlyZW1l bnQuIg0KDQogICAgR1JPVVAgbWVmU2VydmljZVBlcmZvcm1hbmNlT3B0aW9uYWxHcm91cA0K ICAgIERFU0NSSVBUSU9OICJUaGUgbWVmU2VydmljZVBlcmZvcm1hbmNlT3B0aW9uYWxHcm91 cCBpcyBhbiBvcHRpb25hbCANCiAgICAgICAgcmVxdWlyZW1lbnQuIg0KDQogICAgOjo9IHsg bWVmU2VydmljZVVuaUV2Y01pYkNvbXBsaWFuY2VzIDEgfSANCg0KRU5EDQo= --------------000901050906090307080301-- From bclaise@cisco.com Mon Nov 19 07:21:30 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00B221F868F for ; Mon, 19 Nov 2012 07:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCQ9vBBtg6hD for ; Mon, 19 Nov 2012 07:21:30 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B04B721F8667 for ; Mon, 19 Nov 2012 07:21:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAJFL3eO014571; Mon, 19 Nov 2012 16:21:03 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAJFL2LR019185; Mon, 19 Nov 2012 16:21:02 +0100 (CET) Message-ID: <50AA4E5E.7050207@cisco.com> Date: Mon, 19 Nov 2012 16:21:02 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Michelle Cotton Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , 'Brian Haberman' Subject: [MIB-DOCTORS] ianaaddressfamilynumbers-mib versus address-family-numbers X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:21:30 -0000 Hi Michelle, I have a few questions I'm unable to answer. Brian and I have been looking at address family number, address family TC, and the InetAddressType, respectively - [1] http://www.ietf.org/assignments/address-family-numbers/address-family-numbers.txt - [2] http://www.iana.org/assignments/ianaaddressfamilynumbers-mib/ianaaddressfamilynumbers-mib - [3] http://www.ietf.org/rfc/rfc4001.txt First of all, I can't find the procedure to update [2] It contains REVISION "9908260000Z" -- August 26, 1999 DESCRIPTION "Initial version, published as RFC 2677." However, RFC 2677 mentions: Any additions or changes to the list of ADDRESS FAMILY NUMBERS registered via IANA will be done as they have in the past Then, we're wondering if [1] should automatically update [2]? For example, we see some differences for the latest additions in [1]: 16384 EIGRP Common Service Family [Donnie_Savage] 2008-05-13 16385 EIGRP IPv4 Service Family [Donnie_Savage] 2008-05-13 16386 EIGRP IPv6 Service Family [Donnie_Savage] 2008-05-13 16387 LISP Canonical Address Format (LCAF) [David_Meyer] 2009-11-12 Or maybe it the top values are experimental, and that's the reason why they're not shared? And third, for the MIB doctors, [3] has not been updated for a long time. Is this because [2] is somehow considered as a superset? Regards, Benoit From j.schoenwaelder@jacobs-university.de Mon Nov 19 07:35:17 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF03121F84D0 for ; Mon, 19 Nov 2012 07:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvMDLl6YiknX for ; Mon, 19 Nov 2012 07:35:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1B41421F84CC for ; Mon, 19 Nov 2012 07:35:17 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CEDCF20D1B; Mon, 19 Nov 2012 16:35:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hyzmMjSAw9JJ; Mon, 19 Nov 2012 16:35:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4845020D17; Mon, 19 Nov 2012 16:35:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6DC1D22E0489; Mon, 19 Nov 2012 16:35:19 +0100 (CET) Date: Mon, 19 Nov 2012 16:35:19 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20121119153519.GA9109@elstar.local> Mail-Followup-To: Benoit Claise , Michelle Cotton , "MIB Doctors (E-mail)" , 'Brian Haberman' References: <50AA4E5E.7050207@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50AA4E5E.7050207@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" , 'Brian Haberman' , Michelle Cotton Subject: Re: [MIB-DOCTORS] ianaaddressfamilynumbers-mib versus address-family-numbers X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:35:17 -0000 On Mon, Nov 19, 2012 at 04:21:02PM +0100, Benoit Claise wrote: > > And third, for the MIB doctors, [3] has not been updated for a long > time. Is this because [2] is somehow considered as a superset? > RFC 4001 is about address formats for the IP layer. And so far, it seems we only have IPv4 and IPv6 as standards-track specifications to care about. My understanding is that the address family registry has a much larger scope. As such, RFC 4001 only deals with supset of the registered address families. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sam.aldrin@gmail.com Tue Nov 20 14:37:04 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B9421F8815 for ; Tue, 20 Nov 2012 14:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxFP2eoBIWsr for ; Tue, 20 Nov 2012 14:37:03 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67321F872D for ; Tue, 20 Nov 2012 14:37:03 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2594187pad.31 for ; Tue, 20 Nov 2012 14:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=959pR6PIFLXULsxklNP7Z1v9Colb3JC8eaBXvTc/ALU=; b=kFmGSCe6bFiFxlxrjhri3yWWw3LDHPFb0frGitotgLC2DrKcK2BsNBQvWd3dpEJpgW 6EOD6JNv8Y1TN5BMPPHBQbx/2FEnG9P9Dmj7e91kIzcZPBp9ODKyILzvYXwxyl/zZk16 XX9d9PwPA+uqCDv3p89WSA3F2AVSsf/zmS1P39lGyLMvdwLKDchXVvlBjhuC2lUMptHo poImciHxnF2FSOJYlxf6m+hqdURB2AbtrGGHnl/Lj2WzTJ1aw4FtCvrdqEPrI4H2DIKR SMi+YX89ljobs7QKr+9KJOhPtMj0htQ74ENN+MYCmHvj8DyRgxQCwK79/RAFCNnNVyYP Ty/w== Received: by 10.68.192.66 with SMTP id he2mr47116763pbc.112.1353451023178; Tue, 20 Nov 2012 14:37:03 -0800 (PST) Received: from [192.168.253.206] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id om10sm8710607pbc.73.2012.11.20.14.37.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 14:37:02 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_261284A4-9686-474B-A26A-6C82D306ADE0" From: Sam Aldrin X-Priority: 3 In-Reply-To: <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> Date: Tue, 20 Nov 2012 14:36:58 -0800 Message-Id: <0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> To: Joan Cucchiara X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:37:04 -0000 --Apple-Mail=_261284A4-9686-474B-A26A-6C82D306ADE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Joan and MIB doctors, I am sure everyone is in the mood of thanksgiving. Sincerely hope that this request doesn't cause any change in your plans = for thanksgiving :D Would appreciate if the document is reviewed and comments provided. Hopeful to close all the issues and finalize the document, soon. thanks in advance and happy thanksgiving. cheers -sam On Oct 11, 2012, at 8:06 AM, Joan Cucchiara = wrote: > Sam, > =20 > Yes, I have been working on this MIB review and sorry for taking so = long. > Getting some interrupts ;) but should be able to finish up within a = week. > =20 > Thanks for your email, > -Joan > =20 > ----- Original Message ----- > From: Sam Aldrin > To: Joan Cucchiara > Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; = venkatesan mahalingam ; Kannan Sampath > Sent: Wednesday, October 10, 2012 8:02 PM > Subject: Re: MPLS TP TE MIB - Edited for review comments >=20 > Hi Joan and MIB doctors, >=20 > I hope you have gotten a chance to review the MIB document. > Kindly let me know if you have any further comments. > Will be glad to address them. >=20 > thanks in advance > -sam > On Sep 21, 2012, at 5:16 AM, Joan Cucchiara = wrote: >=20 >> Sam, >> =20 >> Yes please include MIB Drs on these emails (I have forwarded your = email to them). >> =20 >> I will take a look at the spreadsheet and MIB soon - hopefully next = week. >> =20 >> Thanks for being so organized! >> -Joan >> =20 >> =20 >> =20 >> ----- Original Message ----- >> From: Sam Aldrin >> To: Joan Cucchiara >> Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; = Kannan Sampath >> Sent: Sunday, September 16, 2012 2:16 AM >> Subject: MPLS TP TE MIB - Edited for review comments >>=20 >> Hi Joan, >>=20 >> How are you? thank you in advance for taking time to review the MIB = draft. Appreciate very much. >> Please find attachments of the following >> - New edited version of the draft >> - Excel sheet with all the comments listed and the status and = comments for each of those >> - Emails regarding TP names from AD and WG chair (sent as separate = email) >> - Changes from last version. >>=20 >> Some more details: >>=20 >> We have edited the MIB draft to address the comments. Some of the = comments are not closed till we agree to resolve them with a common = solution or point. They are listed as open in the XLS sheet. Otherwise = most of the comments are addressed. Please do not take this as the = document is complete with LC comments addressed. Only after all are = addressed, we will take it to next level. >>=20 >> W.r.t TP within the MIB object names, I am not sure when we agreed to = change. If we have done it, we might have misspoke. Reason why we do not = want to change is as follows. When we initially started off the MIB, it = had TP within every object name. But AD (Adrian Farell) and WG chair = (Loa) have comeback and gave review comments to remove because MPLS TP = is not another technology rather it is MPLS. And also, the objects could = be used not only for TP but for bidirectional TE etc. Please find more = details in the attached emails(actually forwarding separately) from = them. >>=20 >> I haven't copied the email to MIB Dr's. If you want us to, we could = do that. >>=20 >> Appreciate if you could review and give us your comments, within the = XLS sheet or email. Either way is fine. >> Also do let us know if we have missed any comments to track. >>=20 >> thanks in advance >> -sam >>=20 >> p.s. I'll be out of country for the next 8 days and email access is = sparse. --Apple-Mail=_261284A4-9686-474B-A26A-6C82D306ADE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi Joan and MIB = doctors,

I am sure everyone is in the mood of = thanksgiving.
Sincerely hope that this request doesn't cause = any change in your plans for thanksgiving = :D

Would appreciate if the document is reviewed = and comments provided.
Hopeful to close all the issues and = finalize the document, soon.

thanks in advance = and happy = thanksgiving.

cheers
-sam
On Oct 11, 2012, at 8:06 AM, Joan Cucchiara <jcucchiara@mindspring.com>= ; wrote:

Sam,
 
Yes, I have been working on this MIB review and sorry for = taking so long.
Getting = some interrupts ;)   but should be able to finish up within a = week.
 
Thanks for your email,
  -Joan
 
----- Original Message -----
Sent: Wednesday, October 10, 2012 = 8:02 PM
Subject: Re: MPLS TP TE MIB - Edited = for review comments

Hi Joan and MIB = doctors,

I hope you have gotten a chance to review = the MIB document.
Kindly let me know if you have any further = comments.
Will be glad to address = them.

thanks in = advance
-sam
On Sep 21, 2012, at 5:16 AM, Joan = Cucchiara <jcucchiara@mindspring.com>= ; wrote:

Sam,
 
Yes please include MIB Drs on these emails (I = have forwarded your email to them).
 
I = will take a look at the spreadsheet and MIB soon - hopefully next = week.
 
Thanks for being so organized!
  -Joan
 
 
 
----- Original Message -----
Sent: Sunday, September 16, 2012 = 2:16 AM
Subject: MPLS TP TE MIB - Edited for = review comments

Hi Joan,

How are you? = thank you in advance for taking time to review the MIB draft. Appreciate = very much.
Please find attachments of the following
  - New = edited version of the draft
  - Excel sheet with all the = comments listed and the status and comments for each of those
  = - Emails regarding TP names from AD and WG chair (sent as separate = email)
  - Changes from last version.

Some more = details:

We have edited the MIB draft to address the comments. = Some of the comments are not closed till we agree to resolve them with a = common solution or point. They are listed as open in the XLS sheet. = Otherwise most of the comments are addressed. Please do not take this as = the document is complete with LC comments addressed. Only after all are = addressed, we will take it to next level.

W.r.t TP within the MIB = object names, I am not sure when we agreed to change. If we have done = it, we might have misspoke. Reason why we do not want to change is as = follows. When we initially started off the MIB, it had TP within every = object name. But AD (Adrian Farell) and WG chair (Loa) have comeback and = gave review comments to remove because MPLS TP is not another technology = rather it is MPLS. And also, the objects could be used not only for TP = but for bidirectional TE etc. Please find more details in the attached = emails(actually forwarding separately) from them.

I haven't = copied the email to MIB Dr's. If you want us to, we could do = that.

Appreciate if you could review and give us your comments, = within the XLS sheet or email. Either way is fine.
Also do let us = know if we have missed any comments to track.

thanks in = advance
-sam

p.s. I'll be out of country for the next 8 days = and email access is sparse. <TP-TE-MIB-Comments.= xls><draft-ietf-mpls-tp-te-mib-05.txt>&= lt;Diff  draft-ietf-mpls-tp-te-mib-04.txt - = draft-ietf-mpls-tp-te-mib-05.txt.htm>

= --Apple-Mail=_261284A4-9686-474B-A26A-6C82D306ADE0-- From j.schoenwaelder@jacobs-university.de Wed Nov 21 03:06:02 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EC521F867F for ; Wed, 21 Nov 2012 03:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnOwwNLFFq3X for ; Wed, 21 Nov 2012 03:06:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 180C621F8586 for ; Wed, 21 Nov 2012 03:06:01 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E9AA20C67; Wed, 21 Nov 2012 12:06:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QZ32YutBFT1k; Wed, 21 Nov 2012 12:05:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BE4520C61; Wed, 21 Nov 2012 12:05:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D335822F18E2; Wed, 21 Nov 2012 12:06:04 +0100 (CET) Date: Wed, 21 Nov 2012 12:06:04 +0100 From: Juergen Schoenwaelder To: mib-doctors@ietf.org, Benoit Claise Message-ID: <20121121110604.GB26361@elstar.local> Mail-Followup-To: mib-doctors@ietf.org, Benoit Claise , Martin Bjorklund , Dave Harrington MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Martin Bjorklund Subject: [MIB-DOCTORS] snmpIeee802Domain in the IANA SNMP Transport Domains registry X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 11:06:02 -0000 Hi, Martin Bjorklund discovered that SNMP over IEEE 802 as defined in RFC 4789 is not listed in the SNMP Transport Domains registry maintained by IANA (and which was established by RFC 5590). http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xml#snmp-number-spaces-7 I assume this was an oversight and I think a proper fix is to add | i802 | snmpIeee802Domain | [RFC4789] [RFC5590] | after the prxy and before the ssh entry. This entry really should have been created by RFC 5590 - I think this is where we overlooked this. If we agree that this is the correct fix, I would need advice in getting it implemented. Do we file an errate for RFC 5590 and once that errata is approved we can get IANA to update the registry? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jcucchiara@mindspring.com Wed Nov 21 07:58:40 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C3D21F855E for ; Wed, 21 Nov 2012 07:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh-azI557509 for ; Wed, 21 Nov 2012 07:58:40 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id E2D8C21F8611 for ; Wed, 21 Nov 2012 07:58:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZTxelssvVabOXLNm/yTokiN5hO2BPEU3taqkiIcP5u39k6OvxWX37DX5XUs3KcW0; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TbChD-0001D8-8E; Wed, 21 Nov 2012 10:58:39 -0500 Message-ID: <006c01cdc801$11c81460$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Sam Aldrin" References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> <0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> Date: Wed, 21 Nov 2012 10:58:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654cc1caabae45a6f3f2308f778311a4789548b785378294e88350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:58:40 -0000 MIB Doctors, I would like your guidance. This draft proposes to add support of Transport Profile (TP) for MPLS-TC-STD-MIB [RFC3811], MPLS-LSR-STD-MIB [RFC3813] and MPLS-TE-STD-MIB [RFC3812] c. 2004. Essentially, the mplsTunnelTable from the MPLS-TE-STD-MIB [RFC3812] could have entries created statically (i.e. manually by an operator) or dynamically. MPLS-TE Tunnels are uni-directional while MPLS-TE Tunnels with Transport Profile are bi-direction (modelled as 2 uni-directional tunnels which are related in the proposed new doc.) I think the following 2 DESCRIPTIONs clauses are NOT the same semantically: Original MplsExtendedTunnelId [RFC3811]: MplsExtendedTunnelId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for an MPLS Tunnel. This may represent an IPv4 address of the ingress or egress LSR for the tunnel. This value is derived from the Extended Tunnel Id in RSVP or the Ingress Router ID for CR-LDP." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209]. Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX Unsigned32(0..4294967295) Here is the index's DESCRIPTION which uses the above TC. To me, while syntactically equivalent are not semantically equivalent, so this is where I could use your guidance, please? mplsTunnelExtNodeConfigLocalId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used in accommodating the bigger size Global_Node_ID and/or ICC with lower size LSR identifier in order to index the mplsTunnelTable. The Local Identifier is configured between 0 and 16777215, as valid IP address range starts from 16777216(01.00.00.00). This range is chosen to identify the mplsTunnelTable's Ingress/Egress LSR-id is IP address or Local identifier, if the configured range is not IP address, operator is expected to retrieve the complete information (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. This way, existing mplsTunnelTable is reused for bidirectional tunnel extensions for MPLS based transport networks. This Local Identifier allows the operator to assign a unique identifier to map Global_Node_ID and/or ICC. As this Local Identifier is unique within the node and the same syntax of this object can be used for MPLS TE tunnel also, it is up to the operator/local management entity to choose the non-conflicting value for indexing the MPLS and MPLS-TP tunnel entries." ::= { mplsTunnelExtNodeConfigEntry 1 } The above "guideline" range of "0" to "16777215" is supposed to be a clue to operator that this is an MPLS-TE Tunnel WITH Transport Profile, HOWEVER, there is nothing in the original MIB that disallows operators from manually configuring within this range. One scenario (even if unlikely): An MPLS TP with Transport Profile is configured dynamically, which conflicts with an older legacy NMS which is statically configuring MPLS TE Tunnel, and they both have chosen one of the same indexes (remember that there are 2 MplsExtendedTunnelId values for each tunnel.) So again, while unlikely, seems that there is potential conflict with legacy equipment. I would like other MIB Doctor guidance: Do you think (as I do) that the DESCRIPTION for mplsTunnelExtNodeConfigLocalId (above) semantically redefines the original MplsExtendedTunnelId TC? Thank you, Joan From jcucchiara@mindspring.com Wed Nov 21 08:24:20 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5885A21F86D2 for ; Wed, 21 Nov 2012 08:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL-7yFLSj2Ar for ; Wed, 21 Nov 2012 08:24:19 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id B180621F84E7 for ; Wed, 21 Nov 2012 08:24:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sBq1RtzJz0upjtFY48EtpA++BtV65EOmCRqtv1hS3GmAesfU9IMnxr57WUYbG36Z; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TbD61-0000BE-Lq; Wed, 21 Nov 2012 11:24:17 -0500 Message-ID: <009b01cdc804$a6b979d0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Sam Aldrin" References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> <0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> Date: Wed, 21 Nov 2012 11:24:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01CDC7DA.BDA09C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654cc1caabae45a6f3f48277885f6ce6a72350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 16:24:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0098_01CDC7DA.BDA09C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sam, Thank you for your patience. I have some comments and some compiler output on the MIB. I am going to hold off on my detailed comments for the=20 MPLS-LSR-EXT-STD-MIB and MPLS-TE-EXT-STD-MIB until the MIB Doctors get a chance to give their guidance on the issue MplsTunnelExtendedId's DESCRIPTION in the proposed draft. Please note, that adding REFERENCE clauses which specify the section may seem like a small issue, this would help me to review the draft. Thank you and Happy Thanksgiving also, -Joan General Issues which Apply to Entire Draft -------------------------------------------- 1) Naming....so I am okay with not including TP as part of the MIB Module's name or Managed Objects. I think it may be important to explain why someplace (maybe in the Terminology Section). 2) Several places in this draft, the MIB Module is referred to MPLS-TP MIB, please use the name of the MIB Module, especially since you have made a point that you don't want to include the term, TP, as part of the MIB Module's names or MO's names. 3) In general need more REFERENCES and more specific REFERENCES for TCs = and=20 OBJECTS. Specifying an entire RFC is not very helpful. =20 Please be more specific and include a section or subsection. 4) There are some compiler issues which are noted below for each MIB Module. I think these should be resolved. 5) Inconsistent use of RFC names. For example in Section 3.2 "This document uses terminology from the MPLS architecture document [RFC3031], MPLS Traffic Engineering Management information [RFC3812], MPLS Label Switch Router MIB [RFC3813] and MPLS-TP Identifiers document [RFC6370]." Sometimes a very informal name for document title, sometimes part of a title and sometimes the full title. Please consistently give the full title, so: MPLS Label Switching Architecture [RFC3031],=20 MPLS Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) [RFC3812] and so forth. 6) Similar to the above, please reference MIB Modules by the=20 Module Name. Someplaces do this, but some say MPLS Traffic Engineering = MIB or LSR MIB. Again, please just be consistent. For example: Section 4. Motivations As already mentioned in the above "General Issues Section" Please clarify, "as the existing MIB" to something like "as the existing MPLS-TE-STD-MIB"=20 MPLS-ID-STD-MIB *) MODULE's REVISION DESCRIPTION "MPLS identifiers MIB object extension" What does this mean? What exactly is the 'extension'? *) Node_ID is assigned within the scope of the Global_ID, so can Node_ID be derived from Global_ID ? I'm wondering if this does need to be read-write, or cannot it just be read-only based on what an operator assigns to Global_ID? *) There are only 3 scalars in this MIB Module and these are=20 IMPORTED into the MPLS-TE-EXT-MIB Module, why are they not included in the MPLS-TE-EXT-MIB? In other words, why is there a separate MIB Module for only 3 scalars? (Certainly, this is a design choice and I'm not saying this is incorrect, but am wondering what the benefit = is?) COMPILER OUTPUT -------------------- MPLS-LSR-EXT-STD-MIB.my SMICNG PRO E: f(MPLS-LSR-EXT-STD-MIB.my), (195,10) Item "mplsInterfaceGroup" should = be IMPORTed W: f(MPLS-LSR-EXT-STD-MIB.my), (209,18) For "mplsXCExtTunnelPointer", = syntax is identical W: f(MPLS-LSR-EXT-STD-MIB.my), (208,18) MIN-ACCESS value identical to = access specified for "mplsXCExtTunnelPointer" MPLS-TE-EXT-STD-MIB.my SMICNG PRO E: f(MPLS-TE-EXT-STD-MIB.my), (108,7) Row "mplsTunnelExtNodeConfigEntry" = may not have columns with MAX-ACCESS of read-write if any column is = read-create E: f(MPLS-TE-EXT-STD-MIB.my), (276,17) Index item = "mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that includes = a range ----- Original Message -----=20 From: Sam Aldrin=20 To: Joan Cucchiara=20 Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; = venkatesan mahalingam ; Kannan Sampath=20 Sent: Tuesday, November 20, 2012 5:36 PM Subject: Re: MPLS TP TE MIB - Edited for review comments Hi Joan and MIB doctors, I am sure everyone is in the mood of thanksgiving. Sincerely hope that this request doesn't cause any change in your = plans for thanksgiving :D Would appreciate if the document is reviewed and comments provided. Hopeful to close all the issues and finalize the document, soon. thanks in advance and happy thanksgiving. cheers -sam On Oct 11, 2012, at 8:06 AM, Joan Cucchiara = wrote: Sam, Yes, I have been working on this MIB review and sorry for taking so = long. Getting some interrupts ;) but should be able to finish up within = a week. Thanks for your email, -Joan ----- Original Message ----- From: Sam Aldrin To: Joan Cucchiara Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; = venkatesan mahalingam ; Kannan Sampath Sent: Wednesday, October 10, 2012 8:02 PM Subject: Re: MPLS TP TE MIB - Edited for review comments Hi Joan and MIB doctors, I hope you have gotten a chance to review the MIB document. Kindly let me know if you have any further comments. Will be glad to address them. thanks in advance -sam On Sep 21, 2012, at 5:16 AM, Joan Cucchiara = wrote: Sam, Yes please include MIB Drs on these emails (I have forwarded = your email to them). I will take a look at the spreadsheet and MIB soon - hopefully = next week. Thanks for being so organized! -Joan ----- Original Message ----- From: Sam Aldrin To: Joan Cucchiara Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan = mahalingam ; Kannan Sampath Sent: Sunday, September 16, 2012 2:16 AM Subject: MPLS TP TE MIB - Edited for review comments Hi Joan, How are you? thank you in advance for taking time to review the = MIB draft. Appreciate very much. Please find attachments of the following - New edited version of the draft - Excel sheet with all the comments listed and the status and = comments for each of those - Emails regarding TP names from AD and WG chair (sent as = separate email) - Changes from last version. Some more details: We have edited the MIB draft to address the comments. Some of = the comments are not closed till we agree to resolve them with a common = solution or point. They are listed as open in the XLS sheet. Otherwise = most of the comments are addressed. Please do not take this as the = document is complete with LC comments addressed. Only after all are = addressed, we will take it to next level. W.r.t TP within the MIB object names, I am not sure when we = agreed to change. If we have done it, we might have misspoke. Reason why = we do not want to change is as follows. When we initially started off = the MIB, it had TP within every object name. But AD (Adrian Farell) and = WG chair (Loa) have comeback and gave review comments to remove because = MPLS TP is not another technology rather it is MPLS. And also, the = objects could be used not only for TP but for bidirectional TE etc. = Please find more details in the attached emails(actually forwarding = separately) from them. I haven't copied the email to MIB Dr's. If you want us to, we = could do that. Appreciate if you could review and give us your comments, within = the XLS sheet or email. Either way is fine. Also do let us know if we have missed any comments to track. thanks in advance -sam p.s. I'll be out of country for the next 8 days and email access = is sparse. = ------=_NextPart_000_0098_01CDC7DA.BDA09C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sam,
 
Thank you for your = patience.   I have=20 some comments
and some compiler output on the MIB.  I am going = to=20 hold
off on my detailed comments for the
MPLS-LSR-EXT-STD-MIB and = MPLS-TE-EXT-STD-MIB until the
MIB Doctors get a chance to give their = guidance=20 on the
issue MplsTunnelExtendedId's DESCRIPTION in the proposed=20 draft.
 
Please note, that adding REFERENCE = clauses which=20 specify the section
may seem like a small issue, this would help me = to review=20 the draft.
 
Thank you and Happy Thanksgiving = also,
 =20 -Joan
 
 
 
General Issues which Apply to Entire=20 Draft
--------------------------------------------
 
1) Naming....so I am okay with not = including TP as=20 part of the
MIB Module's name or Managed Objects.  I think it = may be=20 important to
explain why someplace (maybe in the Terminology=20 Section).
 
2) Several places in this draft, the = MIB Module is=20 referred to
MPLS-TP MIB, please use the name of the MIB Module, = especially=20 since
you have made a point that you don't want to include the term,=20 TP,
as part of the MIB Module's names or MO's names.
 
3) In general need more REFERENCES and = more=20 specific REFERENCES for TCs and
OBJECTS.   Specifying an = entire=20 RFC is not very helpful. 
Please be more specific and include a = section=20 or subsection.
 
4) There are some compiler issues which = are noted=20 below for
each MIB Module.   I think these should be=20 resolved.
 
5) Inconsistent use of RFC names.  = For example=20 in Section 3.2
 
"This document uses terminology from = the MPLS=20 architecture document
[RFC3031], MPLS Traffic Engineering Management=20 information [RFC3812],
MPLS Label Switch Router MIB [RFC3813] and = MPLS-TP=20 Identifiers document
[RFC6370]."
 
Sometimes a very informal name for = document title,=20 sometimes part of
a title and sometimes the full title.  Please=20 consistently give
the full title, so:
MPLS Label Switching = Architecture=20 [RFC3031],
MPLS Label Switching (MPLS) Label Switching Router (LSR)=20 Management
Information Base (MIB) [RFC3812] and so = forth.
 

6) Similar to the above, please reference MIB Modules by the =
Module=20 Name.  Someplaces do this, but some say MPLS Traffic Engineering = MIB
or=20 LSR MIB.  Again, please just be consistent.
 
For example:
Section 4. Motivations
 
As already mentioned in the above "General Issues = Section"
Please=20 clarify, "as the existing MIB" to something like
"as the existing=20 MPLS-TE-STD-MIB"
 

MPLS-ID-STD-MIB
 
*) MODULE's REVISION=20 DESCRIPTION
          = "MPLS=20 identifiers MIB object extension"
 
What does this mean?  What exactly is the 'extension'?
 
*) Node_ID is assigned within the scope of the Global_ID, so = can
Node_ID=20 be derived from Global_ID ?   I'm wondering if this does = need
to be=20 read-write, or cannot it just be read-only based on what an
operator = assigns=20 to Global_ID?
 
*) There are only 3 scalars in this MIB Module and these are =
IMPORTED=20 into the MPLS-TE-EXT-MIB Module, why are they not included
in the=20 MPLS-TE-EXT-MIB?   In other words, why is there a = separate
MIB=20 Module for only 3 scalars?  (Certainly, this is a design = choice
and I'm=20 not saying this is incorrect, but am wondering what the benefit = is?)
 
COMPILER OUTPUT
--------------------
 
MPLS-LSR-EXT-STD-MIB.my
 
SMICNG PRO
E: f(MPLS-LSR-EXT-STD-MIB.my), (195,10) Item=20 "mplsInterfaceGroup" should be IMPORTed
W: = f(MPLS-LSR-EXT-STD-MIB.my),=20 (209,18) For "mplsXCExtTunnelPointer", syntax is identical
W:=20 f(MPLS-LSR-EXT-STD-MIB.my), (208,18) MIN-ACCESS value identical to = access=20 specified for "mplsXCExtTunnelPointer"
 

MPLS-TE-EXT-STD-MIB.my
 
SMICNG PRO
E: f(MPLS-TE-EXT-STD-MIB.my), (108,7) Row=20 "mplsTunnelExtNodeConfigEntry" may not have columns with MAX-ACCESS of=20 read-write if any column is read-create
E: f(MPLS-TE-EXT-STD-MIB.my), = (276,17) Index item "mplsTunnelExtNodeIpMapNodeId" must be defined with = syntax=20 that includes a range
 
 
 

 
----- Original Message -----
From:=20 Sam=20 Aldrin
Cc: MIB Doctors (E-mail) ; Thomas = Nadeau=20 ; Venkatesan Mahalingam = ; venkatesan=20 mahalingam ; Kannan Sampath
Sent: Tuesday, November 20, = 2012 5:36=20 PM
Subject: Re: MPLS TP TE MIB - = Edited for=20 review comments

Hi Joan and MIB = doctors,

I am sure everyone is in the mood of thanksgiving.
Sincerely hope that this request doesn't cause any change in your = plans=20 for thanksgiving :D

Would appreciate if the document is reviewed and comments = provided.
Hopeful to close all the issues and finalize the document, = soon.

thanks in advance and happy thanksgiving.

cheers
-sam
On Oct 11, 2012, at 8:06 AM, Joan Cucchiara <jcucchiara@mindspring.com&g= t;=20 wrote:

Sam,
 
Yes, I have been working on this = MIB review and=20 sorry for taking so long.
Getting some interrupts = ;)   but=20 should be able to finish up within a week.
 
Thanks for your email,
  -Joan
 
----- Original Message -----
From: Sam Aldrin
To: Joan Cucchiara
Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan = Mahalingam ; venkatesan = mahalingam ; Kannan Sampath
Sent: Wednesday, October 10, = 2012 8:02=20 PM
Subject: Re: MPLS TP TE MIB - = Edited for=20 review comments

Hi Joan and MIB doctors,

I hope you have gotten a chance to review the MIB = document.
Kindly let me know if you have any further comments.
Will be glad to address them.

thanks in advance
-sam
On Sep 21, 2012, at 5:16 AM, Joan Cucchiara <jcucchiara@mindspring.com&g= t;=20 wrote:

Sam,
 
Yes please include MIB Drs on = these emails=20 (I have forwarded your email to them).
 
I will take a look at the = spreadsheet and=20 MIB soon - hopefully next week.
 
Thanks for being so = organized!
  -Joan
 
 
 
----- Original Message -----
From: Sam Aldrin
To: Joan = Cucchiara
Cc: Thomas=20 Nadeau ; Venkatesan=20 Mahalingam ; venkatesan = mahalingam ; Kannan Sampath
Sent: Sunday,=20 September 16, 2012 2:16 AM
Subject: MPLS=20 TP TE MIB - Edited for review comments

Hi Joan,

How are you? thank you in advance = for=20 taking time to review the MIB draft. Appreciate very = much.
Please=20 find attachments of the following
  - New edited version = of the=20 draft
  - Excel sheet with all the comments listed and = the=20 status and comments for each of those
  - Emails = regarding TP=20 names from AD and WG chair (sent as separate email)
  - = Changes=20 from last version.

Some more details:

We have = edited the=20 MIB draft to address the comments. Some of the comments are not = closed=20 till we agree to resolve them with a common solution or point. = They are=20 listed as open in the XLS sheet. Otherwise most of the comments = are=20 addressed. Please do not take this as the document is complete = with LC=20 comments addressed. Only after all are addressed, we will take = it to=20 next level.

W.r.t TP within the MIB object names, I am = not sure=20 when we agreed to change. If we have done it, we might have = misspoke.=20 Reason why we do not want to change is as follows. When we = initially=20 started off the MIB, it had TP within every object name. But AD = (Adrian=20 Farell) and WG chair (Loa) have comeback and gave review = comments to=20 remove because MPLS TP is not another technology rather it is = MPLS. And=20 also, the objects could be used not only for TP but for = bidirectional TE=20 etc. Please find more details in the attached emails(actually = forwarding=20 separately) from them.

I haven't copied the email to MIB = Dr's. If=20 you want us to, we could do that.

Appreciate if you could = review=20 and give us your comments, within the XLS sheet or email. Either = way is=20 fine.
Also do let us know if we have missed any comments to=20 track.

thanks in advance
-sam

p.s. I'll be out = of=20 country for the next 8 days and email access is sparse. <TP-TE-MIB-Comments.x= ls><draft-ietf-mpls-tp-te-mib-05.txt>&= lt;Diff=20  draft-ietf-mpls-tp-te-mib-04.txt -=20 = draft-ietf-mpls-tp-te-mib-05.txt.htm>
<= /DIV>

= ------=_NextPart_000_0098_01CDC7DA.BDA09C70-- From sam.aldrin@gmail.com Wed Nov 21 08:38:38 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D902021F8757 for ; Wed, 21 Nov 2012 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj21aJ0Zt7Kx for ; Wed, 21 Nov 2012 08:38:37 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 693D521F8755 for ; Wed, 21 Nov 2012 08:38:37 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so355637dae.31 for ; Wed, 21 Nov 2012 08:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=pNbswsfw6JGoixACTRH7IKOrLBMm9UJqxQQyxxHEWR8=; b=A6bLzABHaKKGeBaveEGwP1/jboY9KzNLVidvP23kLzlT0jJNMQkfzihJOvy/5EQiyc JIEl+vRQiTNoF8Y6v2zqHcQM6c7YjwDuedGN5kqxwuVipH+AofbERsDjqnknsXZzNh0t qaX01x4y9WxhvrKMfejq8jL3WnZdp/eONTwDlQJX//o7666DHC4IqfMFw88jvK9VfK/Q 8DLjA4Dwfh2KwGuFmME9VYve6+Dbi1/JkZoMuazyJRWrudEpDCpAEdRYXRU6WceBKtl6 HqIcbf8fkmwex+uIC3zu0diFrQ8qmVZAwZr31iysClKKyyhuqEz+VcdqDhg1I7tSjGMB ousg== Received: by 10.69.0.40 with SMTP id av8mr775879pbd.117.1353515917066; Wed, 21 Nov 2012 08:38:37 -0800 (PST) Received: from [192.168.1.3] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id tm5sm463281pbc.64.2012.11.21.08.38.34 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 08:38:35 -0800 (PST) References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> <0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> <009b01cdc804$a6b979d0$6801a8c0@JoanPC> Mime-Version: 1.0 (1.0) In-Reply-To: <009b01cdc804$a6b979d0$6801a8c0@JoanPC> Content-Type: multipart/alternative; boundary=Apple-Mail-5874C8AF-06C0-45E7-A6A4-3F9C13125A0E Content-Transfer-Encoding: 7bit Message-Id: <9CFA2C83-5C7A-4C97-9741-547FC8234FEC@gmail.com> X-Mailer: iPad Mail (10A523) From: Sam Aldrin Date: Wed, 21 Nov 2012 08:38:32 -0800 To: Joan Cucchiara Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 16:38:39 -0000 --Apple-Mail-5874C8AF-06C0-45E7-A6A4-3F9C13125A0E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thank you, Joan. Really appreciate your comments. Will track and will address each of those. Have a happy Thanksgiving. Cheers Sam Sent from my iPad On Nov 21, 2012, at 8:24 AM, "Joan Cucchiara" wr= ote: > Sam, > =20 > Thank you for your patience. I have some comments > and some compiler output on the MIB. I am going to hold > off on my detailed comments for the=20 > MPLS-LSR-EXT-STD-MIB and MPLS-TE-EXT-STD-MIB until the > MIB Doctors get a chance to give their guidance on the > issue MplsTunnelExtendedId's DESCRIPTION in the proposed draft. > =20 > Please note, that adding REFERENCE clauses which specify the section > may seem like a small issue, this would help me to review the draft. > =20 > Thank you and Happy Thanksgiving also, > -Joan > =20 > =20 > =20 > General Issues which Apply to Entire Draft > -------------------------------------------- > =20 > 1) Naming....so I am okay with not including TP as part of the > MIB Module's name or Managed Objects. I think it may be important to > explain why someplace (maybe in the Terminology Section). > =20 > 2) Several places in this draft, the MIB Module is referred to > MPLS-TP MIB, please use the name of the MIB Module, especially since > you have made a point that you don't want to include the term, TP, > as part of the MIB Module's names or MO's names. > =20 > 3) In general need more REFERENCES and more specific REFERENCES for TCs an= d=20 > OBJECTS. Specifying an entire RFC is not very helpful. =20 > Please be more specific and include a section or subsection. > =20 > 4) There are some compiler issues which are noted below for > each MIB Module. I think these should be resolved. > =20 > 5) Inconsistent use of RFC names. For example in Section 3.2 > =20 > "This document uses terminology from the MPLS architecture document > [RFC3031], MPLS Traffic Engineering Management information [RFC3812], > MPLS Label Switch Router MIB [RFC3813] and MPLS-TP Identifiers document > [RFC6370]." > =20 > Sometimes a very informal name for document title, sometimes part of > a title and sometimes the full title. Please consistently give > the full title, so: > MPLS Label Switching Architecture [RFC3031],=20 > MPLS Label Switching (MPLS) Label Switching Router (LSR) Management > Information Base (MIB) [RFC3812] and so forth. > =20 >=20 > 6) Similar to the above, please reference MIB Modules by the=20 > Module Name. Someplaces do this, but some say MPLS Traffic Engineering MI= B > or LSR MIB. Again, please just be consistent. > =20 > For example: > Section 4. Motivations > =20 > As already mentioned in the above "General Issues Section" > Please clarify, "as the existing MIB" to something like > "as the existing MPLS-TE-STD-MIB" > =20 >=20 > MPLS-ID-STD-MIB > =20 > *) MODULE's REVISION DESCRIPTION > "MPLS identifiers MIB object extension" > =20 > What does this mean? What exactly is the 'extension'? > =20 > *) Node_ID is assigned within the scope of the Global_ID, so can > Node_ID be derived from Global_ID ? I'm wondering if this does need > to be read-write, or cannot it just be read-only based on what an > operator assigns to Global_ID? > =20 > *) There are only 3 scalars in this MIB Module and these are=20 > IMPORTED into the MPLS-TE-EXT-MIB Module, why are they not included > in the MPLS-TE-EXT-MIB? In other words, why is there a separate > MIB Module for only 3 scalars? (Certainly, this is a design choice > and I'm not saying this is incorrect, but am wondering what the benefit is= ?) > =20 > COMPILER OUTPUT > -------------------- > =20 > MPLS-LSR-EXT-STD-MIB.my > =20 > SMICNG PRO > E: f(MPLS-LSR-EXT-STD-MIB.my), (195,10) Item "mplsInterfaceGroup" should b= e IMPORTed > W: f(MPLS-LSR-EXT-STD-MIB.my), (209,18) For "mplsXCExtTunnelPointer", synt= ax is identical > W: f(MPLS-LSR-EXT-STD-MIB.my), (208,18) MIN-ACCESS value identical to acce= ss specified for "mplsXCExtTunnelPointer" > =20 >=20 > MPLS-TE-EXT-STD-MIB.my > =20 > SMICNG PRO > E: f(MPLS-TE-EXT-STD-MIB.my), (108,7) Row "mplsTunnelExtNodeConfigEntry" m= ay not have columns with MAX-ACCESS of read-write if any column is read-crea= te > E: f(MPLS-TE-EXT-STD-MIB.my), (276,17) Index item "mplsTunnelExtNodeIpMapN= odeId" must be defined with syntax that includes a range > =20 > =20 > =20 >=20 > =20 > ----- Original Message ----- > From: Sam Aldrin > To: Joan Cucchiara > Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; venkate= san mahalingam ; Kannan Sampath > Sent: Tuesday, November 20, 2012 5:36 PM > Subject: Re: MPLS TP TE MIB - Edited for review comments >=20 > Hi Joan and MIB doctors, >=20 > I am sure everyone is in the mood of thanksgiving. > Sincerely hope that this request doesn't cause any change in your plans fo= r thanksgiving :D >=20 > Would appreciate if the document is reviewed and comments provided. > Hopeful to close all the issues and finalize the document, soon. >=20 > thanks in advance and happy thanksgiving. >=20 > cheers > -sam > On Oct 11, 2012, at 8:06 AM, Joan Cucchiara wr= ote: >=20 >> Sam, >> =20 >> Yes, I have been working on this MIB review and sorry for taking so long.= >> Getting some interrupts ;) but should be able to finish up within a wee= k. >> =20 >> Thanks for your email, >> -Joan >> =20 >> ----- Original Message ----- >> From: Sam Aldrin >> To: Joan Cucchiara >> Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; venkat= esan mahalingam ; Kannan Sampath >> Sent: Wednesday, October 10, 2012 8:02 PM >> Subject: Re: MPLS TP TE MIB - Edited for review comments >>=20 >> Hi Joan and MIB doctors, >>=20 >> I hope you have gotten a chance to review the MIB document. >> Kindly let me know if you have any further comments. >> Will be glad to address them. >>=20 >> thanks in advance >> -sam >> On Sep 21, 2012, at 5:16 AM, Joan Cucchiara w= rote: >>=20 >>> Sam, >>> =20 >>> Yes please include MIB Drs on these emails (I have forwarded your email t= o them). >>> =20 >>> I will take a look at the spreadsheet and MIB soon - hopefully next week= . >>> =20 >>> Thanks for being so organized! >>> -Joan >>> =20 >>> =20 >>> =20 >>> ----- Original Message ----- >>> From: Sam Aldrin >>> To: Joan Cucchiara >>> Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; Kann= an Sampath >>> Sent: Sunday, September 16, 2012 2:16 AM >>> Subject: MPLS TP TE MIB - Edited for review comments >>>=20 >>> Hi Joan, >>>=20 >>> How are you? thank you in advance for taking time to review the MIB draf= t. Appreciate very much. >>> Please find attachments of the following >>> - New edited version of the draft >>> - Excel sheet with all the comments listed and the status and comments= for each of those >>> - Emails regarding TP names from AD and WG chair (sent as separate ema= il) >>> - Changes from last version. >>>=20 >>> Some more details: >>>=20 >>> We have edited the MIB draft to address the comments. Some of the commen= ts are not closed till we agree to resolve them with a common solution or po= int. They are listed as open in the XLS sheet. Otherwise most of the comment= s are addressed. Please do not take this as the document is complete with LC= comments addressed. Only after all are addressed, we will take it to next l= evel. >>>=20 >>> W.r.t TP within the MIB object names, I am not sure when we agreed to ch= ange. If we have done it, we might have misspoke. Reason why we do not want t= o change is as follows. When we initially started off the MIB, it had TP wit= hin every object name. But AD (Adrian Farell) and WG chair (Loa) have comeba= ck and gave review comments to remove because MPLS TP is not another technol= ogy rather it is MPLS. And also, the objects could be used not only for TP b= ut for bidirectional TE etc. Please find more details in the attached emails= (actually forwarding separately) from them. >>>=20 >>> I haven't copied the email to MIB Dr's. If you want us to, we could do t= hat. >>>=20 >>> Appreciate if you could review and give us your comments, within the XLS= sheet or email. Either way is fine. >>> Also do let us know if we have missed any comments to track. >>>=20 >>> thanks in advance >>> -sam >>>=20 >>> p.s. I'll be out of country for the next 8 days and email access is spar= se. >=20 --Apple-Mail-5874C8AF-06C0-45E7-A6A4-3F9C13125A0E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Thank you, Joan.
Really appreciate your comments.
Will track and will address each of those.

Have a happy Thanksgiving.

Cheers
Sam

Sent from my iPad

On Nov 21, 2012, at 8:24 AM, "Joan Cucchiara" <jcucchiara@mindspring.com> wrote:

Sam,
 
Thank you for your patience.   I have some comments
and some compiler output on the MIB.  I am going to hold
off on my detailed comments for the
MPLS-LSR-EXT-STD-MIB and MPLS-TE-EXT-STD-MIB until the
MIB Doctors get a chance to give their guidance on the
issue MplsTunnelExtendedId's DESCRIPTION in the proposed draft.
 
Please note, that adding REFERENCE clauses which specify the section
may seem like a small issue, this would help me to review the draft.
 
Thank you and Happy Thanksgiving also,
  -Joan
 
 
 
General Issues which Apply to Entire Draft
--------------------------------------------
 
1) Naming....so I am okay with not including TP as part of the
MIB Module's name or Managed Objects.  I think it may be important to
explain why someplace (maybe in the Terminology Section).
 
2) Several places in this draft, the MIB Module is referred to
MPLS-TP MIB, please use the name of the MIB Module, especially since
you have made a point that you don't want to include the term, TP,
as part of the MIB Module's names or MO's names.
 
3) In general need more REFERENCES and more specific REFERENCES for TCs and
OBJECTS.   Specifying an entire RFC is not very helpful. 
Please be more specific and include a section or subsection.
 
4) There are some compiler issues which are noted below for
each MIB Module.   I think these should be resolved.
 
5) Inconsistent use of RFC names.  For example in Section 3.2
 
"This document uses terminology from the MPLS architecture document
[RFC3031], MPLS Traffic Engineering Management information [RFC3812],
MPLS Label Switch Router MIB [RFC3813] and MPLS-TP Identifiers document
[RFC6370]."
 
Sometimes a very informal name for document title, sometimes part of
a title and sometimes the full title.  Please consistently give
the full title, so:
MPLS Label Switching Architecture [RFC3031],
MPLS Label Switching (MPLS) Label Switching Router (LSR) Management
Information Base (MIB) [RFC3812] and so forth.
 

6) Similar to the above, please reference MIB Modules by the
Module Name.  Someplaces do this, but some say MPLS Traffic Engineering MIB
or LSR MIB.  Again, please just be consistent.
 
For example:
Section 4. Motivations
 
As already mentioned in the above "General Issues Section"
Please clarify, "as the existing MIB" to something like
"as the existing MPLS-TE-STD-MIB"
 

MPLS-ID-STD-MIB
 
*) MODULE's REVISION DESCRIPTION
          "MPLS identifiers MIB object extension"
 
What does this mean?  What exactly is the 'extension'?
 
*) Node_ID is assigned within the scope of the Global_ID, so can
Node_ID be derived from Global_ID ?   I'm wondering if this does need
to be read-write, or cannot it just be read-only based on what an
operator assigns to Global_ID?
 
*) There are only 3 scalars in this MIB Module and these are
IMPORTED into the MPLS-TE-EXT-MIB Module, why are they not included
in the MPLS-TE-EXT-MIB?   In other words, why is there a separate
MIB Module for only 3 scalars?  (Certainly, this is a design choice
and I'm not saying this is incorrect, but am wondering what the benefit is?)
 
COMPILER OUTPUT
--------------------
 
MPLS-LSR-EXT-STD-MIB.my
 
SMICNG PRO
E: f(MPLS-LSR-EXT-STD-MIB.my), (195,10) Item "mplsInterfaceGroup" should be IMPORTed
W: f(MPLS-LSR-EXT-STD-MIB.my), (209,18) For "mplsXCExtTunnelPointer", syntax is identical
W: f(MPLS-LSR-EXT-STD-MIB.my), (208,18) MIN-ACCESS value identical to access specified for "mplsXCExtTunnelPointer"
 

MPLS-TE-EXT-STD-MIB.my
 
SMICNG PRO
E: f(MPLS-TE-EXT-STD-MIB.my), (108,7) Row "mplsTunnelExtNodeConfigEntry" may not have columns with MAX-ACCESS of read-write if any column is read-create
E: f(MPLS-TE-EXT-STD-MIB.my), (276,17) Index item "mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that includes a range
 
 
 

 
----- Original Message -----
From: Sam Aldrin
Sent: Tuesday, November 20, 2012 5:36 PM
Subject: Re: MPLS TP TE MIB - Edited for review comments

Hi Joan and MIB doctors,

I am sure everyone is in the mood of thanksgiving.
Sincerely hope that this request doesn't cause any change in your plans for thanksgiving :D

Would appreciate if the document is reviewed and comments provided.
Hopeful to close all the issues and finalize the document, soon.

thanks in advance and happy thanksgiving.

cheers
-sam
On Oct 11, 2012, at 8:06 AM, Joan Cucchiara <jcucchiara@mindspring.com> wrote:

Sam,
 
Yes, I have been working on this MIB review and sorry for taking so long.
Getting some interrupts ;)   but should be able to finish up within a week.
 
Thanks for your email,
  -Joan
 
----- Original Message -----
From: Sam Aldrin
Sent: Wednesday, October 10, 2012 8:02 PM
Subject: Re: MPLS TP TE MIB - Edited for review comments

Hi Joan and MIB doctors,

I hope you have gotten a chance to review the MIB document.
Kindly let me know if you have any further comments.
Will be glad to address them.

thanks in advance
-sam
On Sep 21, 2012, at 5:16 AM, Joan Cucchiara <jcucchiara@mindspring.com> wrote:

Sam,
 
Yes please include MIB Drs on these emails (I have forwarded your email to them).
 
I will take a look at the spreadsheet and MIB soon - hopefully next week.
 
Thanks for being so organized!
  -Joan
 
 
 
----- Original Message -----
From: Sam Aldrin
Sent: Sunday, September 16, 2012 2:16 AM
Subject: MPLS TP TE MIB - Edited for review comments

Hi Joan,

How are you? thank you in advance for taking time to review the MIB draft. Appreciate very much.
Please find attachments of the following
  - New edited version of the draft
  - Excel sheet with all the comments listed and the status and comments for each of those
  - Emails regarding TP names from AD and WG chair (sent as separate email)
  - Changes from last version.

Some more details:

We have edited the MIB draft to address the comments. Some of the comments are not closed till we agree to resolve them with a common solution or point. They are listed as open in the XLS sheet. Otherwise most of the comments are addressed. Please do not take this as the document is complete with LC comments addressed. Only after all are addressed, we will take it to next level.

W.r.t TP within the MIB object names, I am not sure when we agreed to change. If we have done it, we might have misspoke. Reason why we do not want to change is as follows. When we initially started off the MIB, it had TP within every object name. But AD (Adrian Farell) and WG chair (Loa) have comeback and gave review comments to remove because MPLS TP is not another technology rather it is MPLS. And also, the objects could be used not only for TP but for bidirectional TE etc. Please find more details in the attached emails(actually forwarding separately) from them.

I haven't copied the email to MIB Dr's. If you want us to, we could do that.

Appreciate if you could review and give us your comments, within the XLS sheet or email. Either way is fine.
Also do let us know if we have missed any comments to track.

thanks in advance
-sam

p.s. I'll be out of country for the next 8 days and email access is sparse. <TP-TE-MIB-Comments.xls><draft-ietf-mpls-tp-te-mib-05.txt><Diff  draft-ietf-mpls-tp-te-mib-04.txt - draft-ietf-mpls-tp-te-mib-05.txt.htm>

--Apple-Mail-5874C8AF-06C0-45E7-A6A4-3F9C13125A0E-- From j.schoenwaelder@jacobs-university.de Wed Nov 21 08:39:16 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F8121F8757 for ; Wed, 21 Nov 2012 08:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4bRNIJq6xqC for ; Wed, 21 Nov 2012 08:39:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 04C6721F8755 for ; Wed, 21 Nov 2012 08:39:15 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 636F120C8F; Wed, 21 Nov 2012 17:39:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vUeAwoGFufxc; Wed, 21 Nov 2012 17:39:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7DA920C78; Wed, 21 Nov 2012 17:39:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0F2FB22F245F; Wed, 21 Nov 2012 17:39:18 +0100 (CET) Date: Wed, 21 Nov 2012 17:39:18 +0100 From: Juergen Schoenwaelder To: mib-doctors@ietf.org, Benoit Claise , Martin Bjorklund , Dave Harrington Message-ID: <20121121163918.GA27206@elstar.local> Mail-Followup-To: mib-doctors@ietf.org, Benoit Claise , Martin Bjorklund , Dave Harrington References: <20121121110604.GB26361@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121121110604.GB26361@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [MIB-DOCTORS] snmpIeee802Domain in the IANA SNMP Transport Domains registry X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 16:39:16 -0000 Hi, Martin Bjorklund made the point that for SNMP over UDP over IPv6, we actually use the TDomain/TAddress pairs defined in RFC 3419 (see section 3.1.2 of RFC 3419). Now it seems not totally clear whether RFC 5590 really wants a distinction between UDP over IPv4 and UDP over IPv6 but the way the registry has been designed, there is only space for one TDomain per row I think. (Note that for TLS, DTLS and SSH transports, the address format covers both IPv4 and IPv6 addresses.) Or can we have two rows in the registry with the same prefix, that is we would add | udp | transportDomainUdpIpv6 | [RFC3419] [RFC5590] | after declaring an errata that RFC 5590 did leave this out by accident (and I am leaving out the case of transportDomainUdpIpv6z right now, perhaps another mistake). /js On Wed, Nov 21, 2012 at 12:06:04PM +0100, Juergen Schoenwaelder wrote: > Hi, > > Martin Bjorklund discovered that SNMP over IEEE 802 as defined in RFC > 4789 is not listed in the SNMP Transport Domains registry maintained > by IANA (and which was established by RFC 5590). > > http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xml#snmp-number-spaces-7 > > I assume this was an oversight and I think a proper fix is to add > > | i802 | snmpIeee802Domain | [RFC4789] [RFC5590] | > > after the prxy and before the ssh entry. This entry really should > have been created by RFC 5590 - I think this is where we overlooked > this. > > If we agree that this is the correct fix, I would need advice in > getting it implemented. Do we file an errate for RFC 5590 and once > that errata is approved we can get IANA to update the registry? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Wed Nov 21 16:37:39 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0341021E8040 for ; Wed, 21 Nov 2012 16:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.268 X-Spam-Level: X-Spam-Status: No, score=-101.268 tagged_above=-999 required=5 tests=[AWL=1.331, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETT-M3pZkmqf for ; Wed, 21 Nov 2012 16:37:38 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 28F9E21E8034 for ; Wed, 21 Nov 2012 16:37:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cVSTrrXLtYWkdPREGTR20lAX+h5jVqneaPoXv/EEbr3RLbd8+dr6eeNvlkP65fV+; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.226.203] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TbKnQ-0007wS-Af; Wed, 21 Nov 2012 19:37:36 -0500 Message-ID: <002c01cdc849$a55b3c00$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Joan Cucchiara" , "Sam Aldrin" References: <025601cd97f2$fea5c910$6801a8c0@JoanPC><7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com><008701cda7c1$ee69a4c0$6801a8c0@JoanPC><0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> <006c01cdc801$11c81460$6801a8c0@JoanPC> Date: Wed, 21 Nov 2012 16:38:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97edefbb763df95c4cc19ed2f8427fcaa2b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.203 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 00:37:39 -0000 Hi - Although mplsTunnelExtNodeConfigLocalId adds more semantics to what comes from MplsExtendedTunnelId, none of the constraints from the former seem to be in conflict with the latter. Consequently, I don't see a conflict there. It's perfectly reasonable for an object type to add constraints to a textual convention it employs. However, your comments make it sound as though the object type mplsTunnelExtNodeConfigLocalId is an update to an existing object type. If that is the case, and the earlier version lacks those constraints, that could be of some concern, for the reasons you outline. Randy ----- Original Message ----- > From: "Joan Cucchiara" > To: "Sam Aldrin" > Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" > Sent: Wednesday, November 21, 2012 7:58 AM > Subject: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt > > > MIB Doctors, > > I would like your guidance. > > This draft proposes to add support of Transport Profile (TP) > for MPLS-TC-STD-MIB [RFC3811], MPLS-LSR-STD-MIB [RFC3813] > and MPLS-TE-STD-MIB [RFC3812] c. 2004. > > Essentially, the mplsTunnelTable from the MPLS-TE-STD-MIB [RFC3812] > could have entries created statically (i.e. manually by an operator) or > dynamically. MPLS-TE Tunnels are uni-directional while MPLS-TE Tunnels > with Transport Profile are bi-direction (modelled as 2 uni-directional > tunnels which are related in the proposed new doc.) > > I think the following 2 DESCRIPTIONs clauses are NOT the same semantically: > > Original MplsExtendedTunnelId [RFC3811]: > > MplsExtendedTunnelId ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A unique identifier for an MPLS Tunnel. This may > represent an IPv4 address of the ingress or egress > LSR for the tunnel. This value is derived from the > Extended Tunnel Id in RSVP or the Ingress Router ID > for CR-LDP." > REFERENCE > "RSVP-TE: Extensions to RSVP for LSP Tunnels, > [RFC3209]. > > Constraint-Based LSP Setup using LDP, [RFC3212]." > SYNTAX Unsigned32(0..4294967295) > > Here is the index's DESCRIPTION which uses the above TC. > To me, while syntactically equivalent are not > semantically equivalent, so this is > where I could use your guidance, please? > > > mplsTunnelExtNodeConfigLocalId OBJECT-TYPE > SYNTAX MplsExtendedTunnelId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object is used in accommodating the bigger > size Global_Node_ID and/or ICC with lower size LSR > identifier in order to index the mplsTunnelTable. > > The Local Identifier is configured between 0 and 16777215, > as valid IP address range starts from 16777216(01.00.00.00). > This range is chosen to identify the mplsTunnelTable's > Ingress/Egress LSR-id is IP address or Local identifier, > if the configured range is not IP address, operator is > expected to retrieve the complete information > (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. > > This way, existing mplsTunnelTable is reused for > bidirectional tunnel extensions for MPLS based transport > networks. > > This Local Identifier allows the operator to assign > a unique identifier to map Global_Node_ID and/or ICC. > As this Local Identifier is unique within the node and > the same syntax of this object can be used for MPLS TE > tunnel also, it is up to the operator/local management entity to > choose the non-conflicting value for indexing the MPLS and > MPLS-TP tunnel entries." > ::= { mplsTunnelExtNodeConfigEntry 1 } > > > The above "guideline" range of "0" to "16777215" is supposed to be a > clue to operator that this is an MPLS-TE Tunnel WITH Transport Profile, > HOWEVER, there is nothing in the original MIB that disallows operators from > manually configuring within this range. > > One scenario (even if unlikely): > An MPLS TP with Transport Profile is configured dynamically, > which conflicts with an older legacy NMS which is statically configuring > MPLS TE Tunnel, and they both have chosen one of the same indexes (remember > that there are > 2 MplsExtendedTunnelId values for each tunnel.) So again, while unlikely, > seems that there is > potential conflict with legacy equipment. > > I would like other MIB Doctor guidance: > > Do you think (as I do) that the DESCRIPTION for > mplsTunnelExtNodeConfigLocalId (above) semantically redefines > the original MplsExtendedTunnelId TC? > > Thank you, > Joan > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From sam.aldrin@gmail.com Wed Nov 21 17:50:48 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2D21E8048 for ; Wed, 21 Nov 2012 17:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpcHrZ6OO+Ei for ; Wed, 21 Nov 2012 17:50:48 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 06B901F0C44 for ; Wed, 21 Nov 2012 17:50:47 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so3483625pad.31 for ; Wed, 21 Nov 2012 17:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=gpwRm+NZdEZkeZ9Hva7bHNiwHOQlcRwuAL64TRmF92M=; b=EYBR50BwzgVA5CyzL7AYTypEtrz2r92cuB0l3Hf6DQThG+sEAoctrYaY/51C+kbvKF aXmJ53QQzn0KzEkGK4DNQYMRjfDzAmcpw5e08e2PVds2u7HjYEmVlPx/YrER1SpMuMN4 H+YRDTkl7ZWdqXBV9gYspfFRJmKukbS56ejZaQcl9bWyoZlw/xMWXgjyMgibJdToidb6 o+X7afmKrXphBWPyz0LLPAw2Z8Y6veHxLmyrd8CLdoB9+v6ImfO4EQmMWWD8OLlo9d0o tLUQmyNVcL9DjoLTMWj3MVBm7olGoY+FBFzGkBMiEF6CimeU2M6JKfkfsCZd3ICxxQAt 2fCA== Received: by 10.66.84.40 with SMTP id v8mr22531806pay.47.1353549047652; Wed, 21 Nov 2012 17:50:47 -0800 (PST) Received: from [192.168.1.4] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id ni3sm1130459pbc.2.2012.11.21.17.50.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Nov 2012 17:50:46 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <002c01cdc849$a55b3c00$6b01a8c0@oemcomputer> Date: Wed, 21 Nov 2012 17:50:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <025601cd97f2$fea5c910$6801a8c0@JoanPC><7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com><008701cda7c1$ee69a4c0$6801a8c0@JoanPC><0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> <006c01cdc801$11c81460$6801a8c0@JoanPC> <002c01cdc849$a55b3c00$6b01a8c0@oemcomputer> To: "Randy Presuhn" X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 01:50:49 -0000 Hi Randy, Thanks for the comments. Yes, we are not updating the existing definition of the object type. We = are not restricting the value of mplsTunnelExtNodeConfigLocalId either, = instead retains the same range as the original object type. We are open = to suggestions to on modifications to the text.=20 I hope this is ok with Joan as well. -sam On Nov 21, 2012, at 4:38 PM, "Randy Presuhn" = wrote: > Hi - >=20 > Although mplsTunnelExtNodeConfigLocalId adds more semantics to what > comes from MplsExtendedTunnelId, none of the constraints from the = former > seem to be in conflict with the latter. Consequently, I don't see a = conflict > there. It's perfectly reasonable for an object type to add = constraints to a > textual convention it employs. >=20 > However, your comments make it sound as though the object type > mplsTunnelExtNodeConfigLocalId is an update to an existing object = type. > If that is the case, and the earlier version lacks those constraints, = that > could be of some concern, for the reasons you outline. >=20 > Randy >=20 > ----- Original Message -----=20 >> From: "Joan Cucchiara" >> To: "Sam Aldrin" >> Cc: "Venkatesan Mahalingam" ; "MIB = Doctors (E-mail)" ; "venkatesan mahalingam" > ; "Kannan Sampath" >> Sent: Wednesday, November 21, 2012 7:58 AM >> Subject: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt >>=20 >>=20 >> MIB Doctors, >>=20 >> I would like your guidance. >>=20 >> This draft proposes to add support of Transport Profile (TP) >> for MPLS-TC-STD-MIB [RFC3811], MPLS-LSR-STD-MIB [RFC3813] >> and MPLS-TE-STD-MIB [RFC3812] c. 2004. >>=20 >> Essentially, the mplsTunnelTable from the MPLS-TE-STD-MIB [RFC3812] >> could have entries created statically (i.e. manually by an operator) = or >> dynamically. MPLS-TE Tunnels are uni-directional while MPLS-TE = Tunnels >> with Transport Profile are bi-direction (modelled as 2 = uni-directional >> tunnels which are related in the proposed new doc.) >>=20 >> I think the following 2 DESCRIPTIONs clauses are NOT the same = semantically: >>=20 >> Original MplsExtendedTunnelId [RFC3811]: >>=20 >> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "A unique identifier for an MPLS Tunnel. This may >> represent an IPv4 address of the ingress or egress >> LSR for the tunnel. This value is derived from the >> Extended Tunnel Id in RSVP or the Ingress Router ID >> for CR-LDP." >> REFERENCE >> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >> [RFC3209]. >>=20 >> Constraint-Based LSP Setup using LDP, [RFC3212]." >> SYNTAX Unsigned32(0..4294967295) >>=20 >> Here is the index's DESCRIPTION which uses the above TC. >> To me, while syntactically equivalent are not >> semantically equivalent, so this is >> where I could use your guidance, please? >>=20 >>=20 >> mplsTunnelExtNodeConfigLocalId OBJECT-TYPE >> SYNTAX MplsExtendedTunnelId >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "This object is used in accommodating the bigger >> size Global_Node_ID and/or ICC with lower size LSR >> identifier in order to index the mplsTunnelTable. >>=20 >> The Local Identifier is configured between 0 and 16777215, >> as valid IP address range starts from = 16777216(01.00.00.00). >> This range is chosen to identify the mplsTunnelTable's >> Ingress/Egress LSR-id is IP address or Local identifier, >> if the configured range is not IP address, operator is >> expected to retrieve the complete information >> (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. >>=20 >> This way, existing mplsTunnelTable is reused for >> bidirectional tunnel extensions for MPLS based transport >> networks. >>=20 >> This Local Identifier allows the operator to assign >> a unique identifier to map Global_Node_ID and/or ICC. >> As this Local Identifier is unique within the node and >> the same syntax of this object can be used for MPLS TE >> tunnel also, it is up to the operator/local management = entity to >> choose the non-conflicting value for indexing the MPLS and >> MPLS-TP tunnel entries." >> ::=3D { mplsTunnelExtNodeConfigEntry 1 } >>=20 >>=20 >> The above "guideline" range of "0" to "16777215" is supposed to be a >> clue to operator that this is an MPLS-TE Tunnel WITH Transport = Profile, >> HOWEVER, there is nothing in the original MIB that disallows = operators from >> manually configuring within this range. >>=20 >> One scenario (even if unlikely): >> An MPLS TP with Transport Profile is configured dynamically, >> which conflicts with an older legacy NMS which is statically = configuring >> MPLS TE Tunnel, and they both have chosen one of the same indexes = (remember >> that there are >> 2 MplsExtendedTunnelId values for each tunnel.) So again, while = unlikely, >> seems that there is >> potential conflict with legacy equipment. >>=20 >> I would like other MIB Doctor guidance: >>=20 >> Do you think (as I do) that the DESCRIPTION for >> mplsTunnelExtNodeConfigLocalId (above) semantically redefines >> the original MplsExtendedTunnelId TC? >>=20 >> Thank you, >> Joan >>=20 >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >=20 >=20 From randy_presuhn@mindspring.com Wed Nov 21 18:04:39 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1F921E8048 for ; Wed, 21 Nov 2012 18:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.601 X-Spam-Level: X-Spam-Status: No, score=-101.601 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ0A-pwUcRuy for ; Wed, 21 Nov 2012 18:04:38 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA721E8044 for ; Wed, 21 Nov 2012 18:04:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Q8BE2IEP9O8Ig/W5XqrDkKW9NnL6vb6OsMC92bvGlKLGYCn0LS1pffxRj4Euiq1Q; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.226.203] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TbM9c-0005gv-9x; Wed, 21 Nov 2012 21:04:36 -0500 Message-ID: <007e01cdc855$caecbbe0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Sam Aldrin" References: <025601cd97f2$fea5c910$6801a8c0@JoanPC><7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com><008701cda7c1$ee69a4c0$6801a8c0@JoanPC><0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> <006c01cdc801$11c81460$6801a8c0@JoanPC> <002c01cdc849$a55b3c00$6b01a8c0@oemcomputer> Date: Wed, 21 Nov 2012 18:05:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97e6fc36525ed9b345e0e6529e2a123f077350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.203 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 02:04:39 -0000 Hi - > From: "Sam Aldrin" > To: "Randy Presuhn" > Cc: "Joan Cucchiara" ; "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" > Sent: Wednesday, November 21, 2012 5:50 PM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt ... > Yes, we are not updating the existing definition of the object type. Thanks for he clarification. > We are not restricting the value of mplsTunnelExtNodeConfigLocalId either, > instead retains the same range as the original object type. Ok, here's where I think a possible source of confusion might be: when you say "original object type" do you really mean "textual convention"? > We are open to suggestions to on modifications to the text. I don't have any problems with the text, though I haven't looked at it in the depth that Joan has. The object type definition adds semantic constraints to those already inherent in the TC. That's perfectly fine, as long as those constraints don't introduce a contradiction. What you *might* consider is whether these additional constraints would be needed anywhere else. If that is the case, then it might be worthwhile to define a new TC to capture that commonality. But as it stands, I don't have a problem with what you have. > I hope this is ok with Joan as well. She'll have to speak for herself. :-) Randy From sam.aldrin@gmail.com Wed Nov 21 18:36:30 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9B021E8053 for ; Wed, 21 Nov 2012 18:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ-wY69eq8jG for ; Wed, 21 Nov 2012 18:36:29 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A858321E8051 for ; Wed, 21 Nov 2012 18:36:29 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so5471538pbc.31 for ; Wed, 21 Nov 2012 18:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=IclMnWfUhn6jjNQOwprXxkCCaNy54XvrzR0i9AkBivI=; b=L4POoFZAKy1XOfDpx8DNu12ovvQ8XHZM4tbHXklRG6FPAXbBPKxiTJjXEPb+5tSxh7 ogRN4v2T+xr5IUnthBsUL6/OVYmIlCVWqBMwoGW14r1OLUaFAAAZAjjjlDaJD/+0zCk0 IE6rRpkvAxDnGUG3mXyDCbdmPy/jlHUeLvgX54XfPCUm8+YBKQioYVBbi3QL8h8//XP7 N8v69ZvoKimxmpM4h5BhRGjj/2rYsKXWBqIQHy0HkOTjeWDrTvbBYoDHCxa1Um8lStgs Hq/gTQGh47eelf9DKPaHyVrmYxvcwsrbDUZ/YllVmlb/EvMsWxIYjjC2XelHx8fSo4an 8UAQ== Received: by 10.66.85.134 with SMTP id h6mr22784383paz.36.1353551789459; Wed, 21 Nov 2012 18:36:29 -0800 (PST) Received: from [192.168.1.4] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id un16sm1183474pbc.47.2012.11.21.18.36.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Nov 2012 18:36:28 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C364E01C-3653-4B79-96F0-0A87969CA843" From: Sam Aldrin X-Priority: 3 In-Reply-To: <007e01cdc855$caecbbe0$6b01a8c0@oemcomputer> Date: Wed, 21 Nov 2012 18:36:25 -0800 Message-Id: <26601F2D-F9CA-4370-B55D-26C91001A9EF@gmail.com> References: <025601cd97f2$fea5c910$6801a8c0@JoanPC><7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com><008701cda7c1$ee69a4c0$6801a8c0@JoanPC><0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> <006c01cdc801$11c81460$6801a8c0@JoanPC> <002c01cdc849$a55b3c00$6b01a8c0@oemcomputer> <007e01cdc855$caecbbe0$6b01a8c0@oemcomputer> To: "Randy Presuhn" X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 02:36:30 -0000 --Apple-Mail=_C364E01C-3653-4B79-96F0-0A87969CA843 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Randy, Thanks for the email. Comments inline with %sam. On Nov 21, 2012, at 6:05 PM, "Randy Presuhn" = wrote: > Hi - >=20 >> From: "Sam Aldrin" >> To: "Randy Presuhn" >> Cc: "Joan Cucchiara" ; "Venkatesan = Mahalingam" ; "MIB Doctors (E-mail)" > ; "venkatesan mahalingam" = ; "Kannan Sampath" >> Sent: Wednesday, November 21, 2012 5:50 PM >> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt > ... >> Yes, we are not updating the existing definition of the object type. >=20 > Thanks for he clarification. >=20 >> We are not restricting the value of mplsTunnelExtNodeConfigLocalId = either, >> instead retains the same range as the original object type. >=20 > Ok, here's where I think a possible source of confusion might be: when = you > say "original object type" do you really mean "textual convention"? %sam - Correct. i.e. the TC of MplsExtendedTunnelId >=20 >> We are open to suggestions to on modifications to the text. >=20 > I don't have any problems with the text, though I haven't looked at it = in the > depth that Joan has. The object type definition adds semantic = constraints > to those already inherent in the TC. That's perfectly fine, as long = as those > constraints don't introduce a contradiction. %sam - nod. >=20 > What you *might* consider is whether these additional constraints = would > be needed anywhere else. If that is the case, then it might be = worthwhile > to define a new TC to capture that commonality. But as it stands, I = don't > have a problem with what you have. %sam - nod. AFAIK, there are no other places these constraints are = needed. >=20 >> I hope this is ok with Joan as well. >=20 > She'll have to speak for herself. :-) :D thanks -sam >=20 > Randy >=20 >=20 --Apple-Mail=_C364E01C-3653-4B79-96F0-0A87969CA843 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Randy,

Thanks for the email.
Comments = inline with %sam.
On Nov 21, 2012, at 6:05 PM, "Randy = Presuhn" <randy_presuhn@mindspring.com<= /a>> wrote:

Hi -

From: "Sam Aldrin" = <sam.aldrin@gmail.com>
To: = "Randy Presuhn" <randy_presuhn@mindspring.com<= /a>>
Cc: "Joan Cucchiara" <jcucchiara@mindspring.com>= ;; "Venkatesan Mahalingam" <venkat.mahalingams@gmail.com<= /a>>; "MIB Doctors (E-mail)"
<mib-doctors@ietf.org>; = "venkatesan mahalingam" <venkatflex@gmail.com>; = "Kannan Sampath" <kannankvs@gmail.com>
Sent: Wednesday, November 21, 2012 5:50 = PM
Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt
...
Yes, we are not updating the existing definition of the = object type.

Thanks for he = clarification.

We are not restricting = the value of mplsTunnelExtNodeConfigLocalId  either,
instead = retains the same range as the original object = type.

Ok, here's where I think a possible source of = confusion might be: when you
say "original object type" do you really = mean "textual convention"?
%sam - Correct. i.e. the TC = of 
We are open to suggestions = to on modifications to the text.

I don't have any = problems with the text, though I haven't looked at it in the
depth = that Joan has.  The object type definition  adds semantic = constraints
to those already inherent in the TC.  That's = perfectly fine, as long as those
constraints don't introduce a = contradiction.
%sam - nod.

What you *might* consider is whether these additional = constraints would
be needed anywhere else.  If that is the case, = then it might be worthwhile
to define a new TC to capture that = commonality.  But as it stands, I don't
have a problem with what = you have.
%sam - nod. AFAIK, there are no other places = these constraints are needed.

I hope this is ok with Joan as = well.

She'll have to speak for herself. =  :-)

:D

thank= s
-sam

Randy



= --Apple-Mail=_C364E01C-3653-4B79-96F0-0A87969CA843-- From bclaise@cisco.com Fri Nov 23 01:06:10 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB9821F84D2; Fri, 23 Nov 2012 01:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qArgYHQvkxnM; Fri, 23 Nov 2012 01:06:09 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 46ABB21F84BC; Fri, 23 Nov 2012 01:06:09 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAN8l9Id008060; Fri, 23 Nov 2012 09:47:09 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAN8l7lE006647; Fri, 23 Nov 2012 09:47:07 +0100 (CET) Message-ID: <50AF380B.4030505@cisco.com> Date: Fri, 23 Nov 2012 09:47:07 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121123030716.19357.15203.idtracker@ietfa.amsl.com> In-Reply-To: <20121123030716.19357.15203.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121123030716.19357.15203.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040309030009080408080107" Subject: [MIB-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-11-29 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 09:06:10 -0000 This is a multi-part message in MIME format. --------------040309030009080408080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Please find below the agenda of the November 29th IESG telechat. Please send your questions, comments and concerns before Nov 28 COB. Thanks and Regards, Benoit -------- Original Message -------- Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-11-29 IESG Teleconference Date: Thu, 22 Nov 2012 19:07:16 -0800 From: IESG Secretary To: iesg-agenda-dist@ietf.org 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-nfsv4-federated-fs-admin-14 Administration Protocol for Federated Filesystems (Proposed Standard) Note: Spencer Shepler (sshepler@microsoft.com) is the document shepherd. Token: Martin Stiemerling o draft-ietf-nfsv4-federated-fs-protocol-14 NSDB Protocol for Federated Filesystems (Proposed Standard) Note: Spencer Shepler (sshepler@microsoft.com) is the document shepherd. Token: Martin Stiemerling o draft-ietf-softwire-6rd-radius-attrib-07 RADIUS Attribute for 6rd (Proposed Standard) Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the Document Shepherd Token: Ralph Droms o draft-ietf-6man-uri-zoneid-05 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (Proposed Standard) Note: Ole Troan is the document shepherd. Token: Brian Haberman o draft-ietf-netext-pmipv6-sipto-option-07 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 (Proposed Standard) Note: Basavaraj Patil (bpatil1+ietf@gmail.com) is the document shepherd. Token: Brian Haberman o draft-ietf-imapmove-command-03 Internet Message Access Protocol (IMAP) - MOVE Extension (Proposed Standard) Token: Barry Leiba 2.1.2 Returning Items o draft-ietf-nea-pt-tls-08 PT-TLS: A TLS-based Posture Transport (PT) Protocol (Proposed Standard) Note: Steve Hanna (shanna@juniper.net) is the document shephrd. Token: Stephen Farrell o draft-ietf-mpls-ipv6-pw-lsp-ping-03 Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs (Proposed Standard) Note: Loa Andersson (loa.andersson@ericsson.com) is the document shepherd. Token: Adrian Farrel Was deferred by Stewart Bryant on 2012-11-13 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items NONE 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o RADIUS EXTensions (radext) 4.2.2 Proposed for Approval NONE --------------040309030009080408080107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Please find below the agenda of the November 29th  IESG telechat.
Please send your questions, comments and concerns before Nov 28 COB.

Thanks and Regards, Benoit


-------- Original Message --------
Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-11-29 IESG Teleconference
Date: Thu, 22 Nov 2012 19:07:16 -0800
From: IESG Secretary <iesg-secretary@ietf.org>
To: iesg-agenda-dist@ietf.org 



2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-nfsv4-federated-fs-admin-14
    Administration Protocol for Federated Filesystems (Proposed
    Standard)
    Note: Spencer Shepler (sshepler@microsoft.com) is the document
    shepherd.
    Token: Martin Stiemerling

  o draft-ietf-nfsv4-federated-fs-protocol-14
    NSDB Protocol for Federated Filesystems (Proposed Standard)
    Note: Spencer Shepler (sshepler@microsoft.com) is the document
    shepherd.
    Token: Martin Stiemerling

  o draft-ietf-softwire-6rd-radius-attrib-07
    RADIUS Attribute for 6rd (Proposed Standard)
    Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the Document Shepherd
    Token: Ralph Droms

  o draft-ietf-6man-uri-zoneid-05
    Representing IPv6 Zone Identifiers in Address Literals and Uniform
    Resource Identifiers (Proposed Standard)
    Note: Ole Troan is the document shepherd.
    Token: Brian Haberman

  o draft-ietf-netext-pmipv6-sipto-option-07
    IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 (Proposed
    Standard)
    Note: Basavaraj Patil (bpatil1+ietf@gmail.com) is the document
    shepherd.
    Token: Brian Haberman

  o draft-ietf-imapmove-command-03
    Internet Message Access Protocol (IMAP) - MOVE Extension (Proposed
    Standard)
    Token: Barry Leiba

2.1.2 Returning Items

  o draft-ietf-nea-pt-tls-08
    PT-TLS: A TLS-based Posture Transport (PT) Protocol (Proposed
    Standard)
    Note: Steve Hanna (shanna@juniper.net) is the document shephrd.
    Token: Stephen Farrell

  o draft-ietf-mpls-ipv6-pw-lsp-ping-03
    Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs (Proposed
    Standard)
    Note: Loa Andersson (loa.andersson@ericsson.com) is the document
    shepherd.
    Token: Adrian Farrel
    Was deferred by Stewart Bryant on 2012-11-13

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  NONE

3.1.2 Returning Items

  NONE

3.2 Individual Submissions Via AD
3.2.1 New Items

  NONE

3.2.2 Returning Items

  NONE

3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items

  NONE

3.3.2 Returning Items

  NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  NONE

4.1.2 Proposed for Approval

  NONE

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  o RADIUS EXTensions (radext)

4.2.2 Proposed for Approval

  NONE
--------------040309030009080408080107-- From jcucchiara@mindspring.com Mon Nov 26 05:42:52 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEC321F85B0 for ; Mon, 26 Nov 2012 05:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxTvdVCFY8iW for ; Mon, 26 Nov 2012 05:42:51 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2C021F85BB for ; Mon, 26 Nov 2012 05:42:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YUXJYMe3JWTvH8XZrK6Bz6h/q175H2pKKPnXMaH8UXOpjiFsDu3ZByDjEtjl8vpE; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TcyxP-00043I-0z; Mon, 26 Nov 2012 08:42:43 -0500 Message-ID: <44b201cdcbdb$e82f1b10$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Randy Presuhn" , "Sam Aldrin" References: <025601cd97f2$fea5c910$6801a8c0@JoanPC><7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com><008701cda7c1$ee69a4c0$6801a8c0@JoanPC><0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> <006c01cdc801$11c81460$6801a8c0@JoanPC> <002c01cdc849$a55b3c00$6b01a8c0@oemcomputer> Date: Mon, 26 Nov 2012 08:42:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265426d0fdbbe1efa9abf6d218a9317785b1a26b888b88ba812a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 13:42:52 -0000 Randy, Thank you for your very insightful comment. Here is the original object (actually INDEX) DESCRIPTION from rfc3812: "mplsTunnelIngressLSRId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identity of the ingress LSR associated with this tunnel instance. When the MPLS signalling protocol is rsvp(2) this value SHOULD be equal to the Tunnel Sender Address in the Sender Template object and MAY be equal to the Extended Tunnel Id field in the SESSION object. When the MPLS signalling protocol is crldp(3) this value SHOULD be equal to the Ingress LSR Router ID field in the LSPID TLV object." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Constraint-Based LSP Setup using LDP, Jamoussi (Editor), RFC 3212, January 2002" ::= { mplsTunnelEntry 3 } mplsTunnelEgressLSRId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identity of the egress LSR associated with this tunnel instance." ::= { mplsTunnelEntry 4 }" My issue with the proposed draft's mplsTunnelExtNodeConfigLocalId (which is created as an INDEX, but also used as an OBJECT in the proposed draft) is that the value does NOT identify the Ingress/Egress of the MPLS Tunnel as in rfc3812. The value of mplsTunnelExtNodeConfigLocalId is used to MAP the values of Ingress/Egress by a look-up in a new Table. In other words, this value (mplsTunnelExtNodeConfigLocalId) is created so that the SYNTAX meets the criteria of the original, BUT the value is no longer a value which directly identifies an Ingress/Egress of an MPLS Tunnel. The Ingress/Egress is only gotten via a look-up into a Mapping Table. The reason that this is done is because the SYNTAX for an MPLS Tunnel with Transport Profile for Ingress/Egress is not even the same TYPE as the original MPLS Tunnel. Thus, I conclude that this is a redefinition of the original definition because the original has the value of the MPLS Tunnel and the proposed mplsTunnelExtNodeConfigLocalId does NOT (again, the True value of the Ingress/Egress is in a lookup Table). I can see all sorts of issues with legacy applications because these Tunnels would show up in the MplsTunnelTable and legacy apps would attempt to use the values as Ingress/Egress values for the tunnels on the Network, and they are NOT. Thanks, -Joan ----- Original Message ----- From: "Randy Presuhn" To: "Joan Cucchiara" ; "Sam Aldrin" Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" Sent: Wednesday, November 21, 2012 7:38 PM Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt > Hi - > > Although mplsTunnelExtNodeConfigLocalId adds more semantics to what > comes from MplsExtendedTunnelId, none of the constraints from the former > seem to be in conflict with the latter. Consequently, I don't see a > conflict > there. It's perfectly reasonable for an object type to add constraints to > a > textual convention it employs. > > However, your comments make it sound as though the object type > mplsTunnelExtNodeConfigLocalId is an update to an existing object type. > If that is the case, and the earlier version lacks those constraints, that > could be of some concern, for the reasons you outline. > > Randy > > ----- Original Message ----- >> From: "Joan Cucchiara" >> To: "Sam Aldrin" >> Cc: "Venkatesan Mahalingam" ; "MIB Doctors >> (E-mail)" ; "venkatesan mahalingam" > ; "Kannan Sampath" >> Sent: Wednesday, November 21, 2012 7:58 AM >> Subject: [MIB-DOCTORS] Request for MIB Doctor guidance >> ondraft-ietf-mpls-te-tp-mib-05.txt >> >> >> MIB Doctors, >> >> I would like your guidance. >> >> This draft proposes to add support of Transport Profile (TP) >> for MPLS-TC-STD-MIB [RFC3811], MPLS-LSR-STD-MIB [RFC3813] >> and MPLS-TE-STD-MIB [RFC3812] c. 2004. >> >> Essentially, the mplsTunnelTable from the MPLS-TE-STD-MIB [RFC3812] >> could have entries created statically (i.e. manually by an operator) or >> dynamically. MPLS-TE Tunnels are uni-directional while MPLS-TE Tunnels >> with Transport Profile are bi-direction (modelled as 2 uni-directional >> tunnels which are related in the proposed new doc.) >> >> I think the following 2 DESCRIPTIONs clauses are NOT the same >> semantically: >> >> Original MplsExtendedTunnelId [RFC3811]: >> >> MplsExtendedTunnelId ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "A unique identifier for an MPLS Tunnel. This may >> represent an IPv4 address of the ingress or egress >> LSR for the tunnel. This value is derived from the >> Extended Tunnel Id in RSVP or the Ingress Router ID >> for CR-LDP." >> REFERENCE >> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >> [RFC3209]. >> >> Constraint-Based LSP Setup using LDP, [RFC3212]." >> SYNTAX Unsigned32(0..4294967295) >> >> Here is the index's DESCRIPTION which uses the above TC. >> To me, while syntactically equivalent are not >> semantically equivalent, so this is >> where I could use your guidance, please? >> >> >> mplsTunnelExtNodeConfigLocalId OBJECT-TYPE >> SYNTAX MplsExtendedTunnelId >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "This object is used in accommodating the bigger >> size Global_Node_ID and/or ICC with lower size LSR >> identifier in order to index the mplsTunnelTable. >> >> The Local Identifier is configured between 0 and 16777215, >> as valid IP address range starts from 16777216(01.00.00.00). >> This range is chosen to identify the mplsTunnelTable's >> Ingress/Egress LSR-id is IP address or Local identifier, >> if the configured range is not IP address, operator is >> expected to retrieve the complete information >> (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. >> >> This way, existing mplsTunnelTable is reused for >> bidirectional tunnel extensions for MPLS based transport >> networks. >> >> This Local Identifier allows the operator to assign >> a unique identifier to map Global_Node_ID and/or ICC. >> As this Local Identifier is unique within the node and >> the same syntax of this object can be used for MPLS TE >> tunnel also, it is up to the operator/local management entity >> to >> choose the non-conflicting value for indexing the MPLS and >> MPLS-TP tunnel entries." >> ::= { mplsTunnelExtNodeConfigEntry 1 } >> >> >> The above "guideline" range of "0" to "16777215" is supposed to be a >> clue to operator that this is an MPLS-TE Tunnel WITH Transport Profile, >> HOWEVER, there is nothing in the original MIB that disallows operators >> from >> manually configuring within this range. >> >> One scenario (even if unlikely): >> An MPLS TP with Transport Profile is configured dynamically, >> which conflicts with an older legacy NMS which is statically configuring >> MPLS TE Tunnel, and they both have chosen one of the same indexes >> (remember >> that there are >> 2 MplsExtendedTunnelId values for each tunnel.) So again, while >> unlikely, >> seems that there is >> potential conflict with legacy equipment. >> >> I would like other MIB Doctor guidance: >> >> Do you think (as I do) that the DESCRIPTION for >> mplsTunnelExtNodeConfigLocalId (above) semantically redefines >> the original MplsExtendedTunnelId TC? >> >> Thank you, >> Joan >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > > From sam.aldrin@gmail.com Mon Nov 26 07:54:05 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C061F21F85C2 for ; Mon, 26 Nov 2012 07:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VypDe64mHuWp for ; Mon, 26 Nov 2012 07:54:05 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB7521F85BF for ; Mon, 26 Nov 2012 07:54:05 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so7912263pbc.31 for ; Mon, 26 Nov 2012 07:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/53+BJfn+10G+XfirF099qaIK5Aw8eQ9dviigAupbqI=; b=D72NHcRBuyT2BHqvlyTcPrDSwzBHkUvO6b+kZzK4naxF4FNKcScqTmJAtAoQAJ8UMe MYrHJQ6+DERh346/+ViYXl5e9FXryUDTmAGrNhfdK8UE0DiLxvoWLDGeLduGOjNgtddq rq/ihLOBngl1WOxOPDGDLPJtkXM3feEKktaOW5rHF5hF1yT7PG1xBKr7Jqm3xSkZzAhn j2x6lJOFMmq+gJahVYMA3JISqqwazrjveWOYkC+22vlKmg/aCyzfCmMp5y/ifrOunow4 7kP8dPEje/5aXKTUijg9r/kM1SFkVeR0aH3d8M0/fE7WQnjoI3x7PtMqKXbGu78jLBRp gICQ== Received: by 10.66.73.132 with SMTP id l4mr33922677pav.48.1353945245084; Mon, 26 Nov 2012 07:54:05 -0800 (PST) Received: from [192.168.1.4] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id jw10sm8963955pbb.20.2012.11.26.07.54.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 07:54:04 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: Date: Mon, 26 Nov 2012 07:54:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> <0CFD9A22-639B-456A-B8E1-6AABAB62CE17@gmail.com> <006c01cdc801$11c81460$6801a8c0@JoanPC> <002c01cdc849$a55b3c00$6b01a8c0@oemcomputer> <44b201cdcbdb$e82f1b10$6801a8c0@JoanPC> To: Kannan Sampath X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , venkatesan mahalingam , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:54:05 -0000 Thanks, Joan and all. Just to add few more points. When the MIB extension was proposed to WG, we gotten feedback to with = the proposed mode i.e. instead of redefining entirely new MIB, as the = tunnels share same objects, use the same MIB with level of indirection. = Having said that, vendors who have existing TE tunnel MIB = implementations have already implemented this new MIB, without an issue. = Supporting legacy TE tunnels with TP tunnels with the MIB was not at all = an issue. When we proposed to use 'non ip address' value for local index, is the = very reason that the index is not referring to LSR Router ID. So, the = applications cannot consider it as a valid router ID. cheers -sam On Nov 26, 2012, at 6:29 AM, Kannan Sampath wrote: > Hi Joan, > Thanks Joan. You are on the dot. >=20 > I have an opinion regarding your point on "legacy applications ". > If I assume that legacy applications are going to be used only with > those legacy MPLS switches, we can also assume that new applications > should be developed for supporting the MPLSTP systems. > I mean, if we use "legacy application" for legacy MPLS tunnels and use > "new application" for new MPLSTP tunnels, it should not be a problem I > guess. > If you can explain what kind of solution is required for such "legacy > applications", we can try to provide better clarity on this. >=20 > Thanks & Regards, > Kannan >=20 >=20 > On Mon, Nov 26, 2012 at 7:12 PM, Joan Cucchiara > wrote: >> legacy applications From randy_presuhn@mindspring.com Mon Nov 26 11:27:59 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219CE21F8509 for ; Mon, 26 Nov 2012 11:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyn+mBlY+6Q0 for ; Mon, 26 Nov 2012 11:27:58 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 8714221F8517 for ; Mon, 26 Nov 2012 11:27:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gKMBk9AeS6ovTweZZ/tgOt8hnMQrbpEi11pX+oskrAJ8fkhtPznuRAmWq6Qw60Cc; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Td4LU-0005aU-FQ; Mon, 26 Nov 2012 14:27:56 -0500 Received: from 99.33.92.23 by webmail.earthlink.net with HTTP; Mon, 26 Nov 2012 14:27:56 -0500 Message-ID: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Mon, 26 Nov 2012 11:27:56 -0800 (GMT-08:00) From: Randy Presuhn To: Joan Cucchiara , Sam Aldrin Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97e30d7f9bec8ead4fae9d9824f6fad7b0c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:27:59 -0000 Hi - Much good stuff deleted, but before going further, let me see whether I understand the situation correctly. Old MIB has table T1 indexed by I1. New MIB has table T2 indexed by I2, and a mapping table M associating I1 and I2, allowing management software to do a "join" as needed of information from the tables. If that is what they are doing, I don't see a MIB problem, as long as the mapping table works to keep the number of queries reasonable for high-frequency use cases. There's no rule requiring that an indexing structure used in a MIB associated with a particular technology be re-used in all future MIBs related to that technology. One would hope that the initial index structure would anticipate future needs and developments, but there's no requirement to do so. It sounds to me that your concern is that implementors will confuse I1 and I2, despite the differing semantics. If so, I think the concern might by assuaged by an analogy. Consider a hypothetical MIB with an index I'll call fooName, with a UTF-8 string textual convention as its syntax. Its description says it's a person's name, without further elaboration. (Why am I reminded of my old co-worker named "Tyler Martin" and my friend "Lee, Nielson"? :-) Later, another MIB, in order to meet specific requirements may well introduce an index I'll call fooLastCommaFirstName, with a description specifying that is constructed from a family name, a comma, and a list of given names separated by spaces. The difference in the semantics of these indexes is purely in their respective description clauses, yet we don't worry about implementors confusing them. Obviously not ideal (it's a source of possible user confusion), but certainly not *wrong*, and if it supports important use cases the original ones did not, it's still the right thing to do, especially if the new index structure supports use cases that the old one would not. (E.g. access control, partial table retrieval, clustering of related entries, etc., etc.) Randy From sam.aldrin@gmail.com Mon Nov 26 16:28:30 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0D21F851B for ; Mon, 26 Nov 2012 16:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzJKeEo2FLii for ; Mon, 26 Nov 2012 16:28:29 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1121F8446 for ; Mon, 26 Nov 2012 16:28:29 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so8215318pbc.31 for ; Mon, 26 Nov 2012 16:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SJuPQYq6y9mrQ6jF2mePl4L/paJHb1uJtjJPzwk4Dgc=; b=GVcp9/IqO0MO4BK4u73dv7BeQS6JcRoKk3Wy0Ii/AbuS6aSg4ezjG8ilqO58vtrren 6jEpzj517NqtZZw1UPq0vzHjRAbJqGbIS+NuNvKE4axpAvX41XPZEPtYFybFFTiHVvrw rWYsF+H5w2rTyi+Q+6ZCz8K9kqaBRZQTEd3Wrr419J843uGM3tN0M+0MbP+rWMZ+tYc7 XoZHEUADkumAh9KmdIV6bu5zWwVh1Ve3REZufp4pmE80ENvQ3tCJGDJo8Gvm0nLFLoJx tdDZV9fn0Vn1kF0nWttQpcbsfnSNo71kmjm1irT7JJu5FqIVmjAB1DKqxdu/89YMBuyS 3NAg== Received: by 10.66.79.167 with SMTP id k7mr37845399pax.24.1353976109045; Mon, 26 Nov 2012 16:28:29 -0800 (PST) Received: from [192.168.253.206] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id o10sm9573020paz.37.2012.11.26.16.28.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 16:28:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Mon, 26 Nov 2012 16:28:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72867F27-57D7-49F0-B8C7-6A4A520E5972@gmail.com> References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> To: Randy Presuhn X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 00:28:30 -0000 Thanks, Randy for the detailed email with analogy. You pretty much captured the essence of what we are trying to do. Joan, is there something we might be missing here, that should be = addressed in this regard? Thank you, Joan and Randy, for your valuable comments, which are of = often overlooked by MIB developers like me. Much appreciated. cheers -sam On Nov 26, 2012, at 11:27 AM, Randy Presuhn = wrote: > Hi - >=20 > Much good stuff deleted, but before going further, > let me see whether I understand the situation correctly. > Old MIB has table T1 indexed by I1. > New MIB has table T2 indexed by I2, and=20 > a mapping table M associating I1 and I2, > allowing management software to do a "join" > as needed of information from the tables. >=20 > If that is what they are doing, I don't see a MIB problem, > as long as the mapping table works to keep the number of > queries reasonable for high-frequency use cases. >=20 > There's no rule requiring that an indexing structure used > in a MIB associated with a particular technology be re-used > in all future MIBs related to that technology. One would > hope that the initial index structure would anticipate > future needs and developments, but there's no requirement > to do so. >=20 > It sounds to me that your concern is that implementors will > confuse I1 and I2, despite the differing semantics. If so, > I think the concern might by assuaged by an analogy. >=20 > Consider a hypothetical MIB with an index I'll call fooName, > with a UTF-8 string textual convention as its syntax. Its > description says it's a person's name, without further elaboration. > (Why am I reminded of my old co-worker named "Tyler Martin" > and my friend "Lee, Nielson"? :-) Later, another MIB, in order > to meet specific requirements may well introduce an index I'll > call fooLastCommaFirstName, with a description specifying that > is constructed from a family name, a comma, and a list of > given names separated by spaces. The difference in the > semantics of these indexes is purely in their respective > description clauses, yet we don't worry about implementors > confusing them. >=20 > Obviously not ideal (it's a source of possible user confusion), > but certainly not *wrong*, and if it supports important use cases > the original ones did not, it's still the right thing to do, > especially if the new index structure supports use cases that > the old one would not. (E.g. access control, partial table > retrieval, clustering of related entries, etc., etc.) >=20 > Randy From jcucchiara@mindspring.com Mon Nov 26 21:08:07 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BBE21F84CE for ; Mon, 26 Nov 2012 21:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XzXAJZ5pf9A for ; Mon, 26 Nov 2012 21:08:06 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8203C21F84C5 for ; Mon, 26 Nov 2012 21:08:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fDQtiFh2Z+iHHT+sFyPzl2wuSWHdEi1boJCI0CaqiHnHWoYgdmlIheB+galS2Yki; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TdDOu-0005Ly-Lc; Tue, 27 Nov 2012 00:08:04 -0500 Message-ID: <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Randy Presuhn" , "Sam Aldrin" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Tue, 27 Nov 2012 00:08:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26548da85cc6bf26dcc3469221d545e5701a301ee85fcf877b1e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 05:08:07 -0000 ----- Original Message ----- From: "Randy Presuhn" To: "Joan Cucchiara" ; "Sam Aldrin" Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" Sent: Monday, November 26, 2012 2:27 PM Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt > Hi - > > Much good stuff deleted, but before going further, > let me see whether I understand the situation correctly. > Old MIB has table T1 indexed by I1. > New MIB has table T2 indexed by I2, and > a mapping table M associating I1 and I2, > allowing management software to do a "join" > as needed of information from the tables. > > If that is what they are doing, I don't see a MIB problem, > as long as the mapping table works to keep the number of > queries reasonable for high-frequency use cases. > > There's no rule requiring that an indexing structure used > in a MIB associated with a particular technology be re-used > in all future MIBs related to that technology. One would > hope that the initial index structure would anticipate > future needs and developments, but there's no requirement > to do so. > > It sounds to me that your concern is that implementors will > confuse I1 and I2, despite the differing semantics. If so, > I think the concern might by assuaged by an analogy. > > Consider a hypothetical MIB with an index I'll call fooName, > with a UTF-8 string textual convention as its syntax. Its > description says it's a person's name, without further elaboration. > (Why am I reminded of my old co-worker named "Tyler Martin" > and my friend "Lee, Nielson"? :-) Later, another MIB, in order > to meet specific requirements may well introduce an index I'll > call fooLastCommaFirstName, with a description specifying that > is constructed from a family name, a comma, and a list of > given names separated by spaces. The difference in the > semantics of these indexes is purely in their respective > description clauses, yet we don't worry about implementors > confusing them. > Randy, Thanks for the great example! So to carry this example a step further, then the M (mapping) Table in the new MIB associates I1 and I2. So for example, I1 has a value of "John Doe" (fooName) and the new MIB has I2 with a value of "Doe, John" (fooLastCommaFirstName) and an entry is created in M which associates "JohnDoe" with "Doe, John". Is this correct? The draft is doing something different. Using your example above, the draft proposes the following steps, which MUST be in this order: * Create an entry in T2 with I2 in the new MIB. (T2 is the mapping table, M, which maps I2 to the actual ID for the Tunnel with TP). * Create an entry in T1 using I2 as the index. (There is no I1.) * Create additional entries in a few tables in the new draft ('reverse' mapping tables, and also a table which associates the T1 entry to a second T1 entry which is how bi-directional tunnels are represented in the new draft. Bi-directional tunnels are for TP and did not exist in the original MIB.) The original Tunnels represented in T1 were of type Unsigned32 and represented a value that was meaningful on the network. The new Tunnels with TP are either "Global Id" of OCTET (SIZE 4) , or "ICC Id" of OCTET (SIZE 6). Since the new Tunnels with TP, share the same objects (but NOT the index) as the original Tunnels represented in rfc3812, then the goal is to use the original T1. The "gotcha" is that the original MIB is indexed by Unsigned32 value which was unique and meaningful on the network BUT this index (I1) has no meaning wrt these new Tunnels with TP. The new tunnels are identified by Global Id (OCTET STRING (SIZE 4)) or Icc Id (OCTET STRING (SIZE 6)). So the solution being proposed is to create an entry in T2 with I2 (again T2 IS the M (mapping table)), and then create an entry in T1 which MUST use I2 as the index. Keeping in mind that I1 is value which is unique and meaningful on the network, and what is being proposed is just a value within Unsigned32 range, but doesn't appear anywhere on the network, may cause some confusion for legacy apps. An analogy would be to create a T2 which is in the correct format, but is not identifiable as a name. I think your example was quite helpful in highlighting some important details. Thanks, -Joan > Obviously not ideal (it's a source of possible user confusion), > but certainly not *wrong*, and if it supports important use cases > the original ones did not, it's still the right thing to do, > especially if the new index structure supports use cases that > the old one would not. (E.g. access control, partial table > retrieval, clustering of related entries, etc., etc.) > > Randy From sam.aldrin@gmail.com Mon Nov 26 21:52:20 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8921F865F for ; Mon, 26 Nov 2012 21:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTZ7mz2BKqI2 for ; Mon, 26 Nov 2012 21:52:19 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F32A21F8658 for ; Mon, 26 Nov 2012 21:52:19 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2477476dae.31 for ; Mon, 26 Nov 2012 21:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=gJpVuC2o2jW6Cxyx89Oz2GWEYM12wc+hep/bJiNZ62I=; b=KHWOvZ/B2yP1cTRwzNgueB11FhH3tcA8P9b1fFH4RiGU6BbC3mIrWEjg47fkYUqP8+ RW5Ks9S4q181xy43dOfNkMTzDi6psWCkGOlMEgHHBN5bENE41+kWUUF3V0seI5gdlWzx rTMa+UIvYQJmppGALaNNFW0bfbR6J2OmZlNPkBxgVm78TAgj2jtcgktGwSILDwimk4oX /ZOIPCiESwlftT1ttUEDaThr6SmD5m4D8lPAjjVbLgxGjndCRfFKxVJDxXoyDm0+PzY2 EvjflwdkFgFxgRFHFABUsRgVZ1AhmR94fXGofv3G+j0hFGy5LY1V7yYBZI6trXyPnyeK RCFA== Received: by 10.68.191.200 with SMTP id ha8mr44881709pbc.51.1353995538386; Mon, 26 Nov 2012 21:52:18 -0800 (PST) Received: from [192.168.1.3] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id ve6sm10035691pbc.58.2012.11.26.21.52.14 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 21:52:16 -0800 (PST) References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> Mime-Version: 1.0 (1.0) In-Reply-To: <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> X-Mailer: iPad Mail (10A523) From: Sam Aldrin Date: Mon, 26 Nov 2012 21:52:15 -0800 To: Joan Cucchiara Cc: Venkatesan Mahalingam , venkatesan mahalingam , Kannan Sampath , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 05:52:20 -0000 I have couple of comments inline with %sam. Sam Sent from my iPad On Nov 26, 2012, at 9:08 PM, "Joan Cucchiara" wr= ote: >=20 > ----- Original Message ----- From: "Randy Presuhn" > To: "Joan Cucchiara" ; "Sam Aldrin" > Cc: "Venkatesan Mahalingam" ; "MIB Doctors (= E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" > Sent: Monday, November 26, 2012 2:27 PM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mp= ls-te-tp-mib-05.txt >=20 >=20 >> Hi - >>=20 >> Much good stuff deleted, but before going further, >> let me see whether I understand the situation correctly. >> Old MIB has table T1 indexed by I1. >> New MIB has table T2 indexed by I2, and >> a mapping table M associating I1 and I2, >> allowing management software to do a "join" >> as needed of information from the tables. >>=20 >> If that is what they are doing, I don't see a MIB problem, >> as long as the mapping table works to keep the number of >> queries reasonable for high-frequency use cases. >>=20 >> There's no rule requiring that an indexing structure used >> in a MIB associated with a particular technology be re-used >> in all future MIBs related to that technology. One would >> hope that the initial index structure would anticipate >> future needs and developments, but there's no requirement >> to do so. >>=20 >> It sounds to me that your concern is that implementors will >> confuse I1 and I2, despite the differing semantics. If so, >> I think the concern might by assuaged by an analogy. >>=20 >> Consider a hypothetical MIB with an index I'll call fooName, >> with a UTF-8 string textual convention as its syntax. Its >> description says it's a person's name, without further elaboration. >> (Why am I reminded of my old co-worker named "Tyler Martin" >> and my friend "Lee, Nielson"? :-) Later, another MIB, in order >> to meet specific requirements may well introduce an index I'll >> call fooLastCommaFirstName, with a description specifying that >> is constructed from a family name, a comma, and a list of >> given names separated by spaces. The difference in the >> semantics of these indexes is purely in their respective >> description clauses, yet we don't worry about implementors >> confusing them. >>=20 >=20 > Randy, >=20 > Thanks for the great example! >=20 > So to carry this example a step further, then the M (mapping) Table in the= new MIB associates I1 and I2. So for example, > I1 has a value of "John Doe" (fooName) and the new MIB has I2 with a valu= e of "Doe, John" (fooLastCommaFirstName) > and an entry is created in M which associates "JohnDoe" with "Doe, John".= Is this correct? >=20 > The draft is doing something different. Using your example above, the dr= aft proposes the following steps, which MUST be in this order: >=20 > * Create an entry in T2 with I2 in the new MIB. (T2 is the mapping table= , M, which maps I2 to the actual ID for the Tunnel with TP). > * Create an entry in T1 using I2 as the index. (There is no I1.) > * Create additional entries in a few tables in the new draft ('reverse' m= apping tables, and also a table which associates the T1 entry to a second T1= entry which is how bi-directional tunnels are represented in the new draft.= Bi-directional tunnels are for TP and did not exist in the original MIB.) %sam- having bi-directional tunnels could be associated or congruent. So, it= is not necessary that there is always entry will be present all the time. Also, there is an effort to bring TP technologies in to TE land. In that cas= e, the existing MIB has to be redone. This change being proposed will help w= hen that happens as well. >=20 > The original Tunnels represented in T1 were of type Unsigned32 and represe= nted a value that was meaningful on the network. > The new Tunnels with TP are either "Global Id" of OCTET (SIZE 4) , or "IC= C Id" of OCTET (SIZE 6). >=20 > Since the new Tunnels with TP, share the same objects (but NOT the index) a= s the original Tunnels represented in rfc3812, then the goal is to use the o= riginal T1. The "gotcha" is that the original MIB is indexed by Unsigned32= value which was unique and meaningful on the network BUT this index (I1) ha= s no meaning wrt these new Tunnels with TP. The new tunnels are identified b= y Global Id (OCTET STRING (SIZE 4)) or Icc Id (OCTET STRING (SIZE 6)). %sam - which is the reason why mapping table is still needed whether old tun= nel table or new tunnel table is used. >=20 > So the solution being proposed is to create an entry in T2 with I2 (again= T2 IS the M (mapping table)), and then create an entry in T1 which MUST use= I2 as the index. >=20 > Keeping in mind that I1 is value which is unique and meaningful on the net= work, and what is being proposed is just a value within Unsigned32 range, bu= t doesn't appear anywhere on the network, may cause some confusion for legac= y apps. %sam - the value of l1, though unique, having non-ip address value mean noth= ing, even to the legacy application. That is why, re-using the table with no= n-ip value is a perfect choice. As Randy said in his earlier email, this model of reusing the index is not a= gainst the rule, it should be perfectly fine.=20 Cheers Sam > An analogy would be to create a T2 which is in the correct format, but is n= ot identifiable as a name. >=20 > I think your example was quite helpful in highlighting some important deta= ils. >=20 > Thanks, > -Joan >=20 >> Obviously not ideal (it's a source of possible user confusion), >> but certainly not *wrong*, and if it supports important use cases >> the original ones did not, it's still the right thing to do, >> especially if the new index structure supports use cases that >> the old one would not. (E.g. access control, partial table >> retrieval, clustering of related entries, etc., etc.) >>=20 >> Randy=20 >=20 From randy_presuhn@mindspring.com Mon Nov 26 22:10:16 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3621F8690 for ; Mon, 26 Nov 2012 22:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1mt+-njkBVO for ; Mon, 26 Nov 2012 22:10:15 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C66321F868F for ; Mon, 26 Nov 2012 22:10:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=P0idhhjZzlWoS5SV2vbiyfI0kB8CoksXtn+Yze2QWFYfyehKcEDBkM4gsZIUEi6M; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.147] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TdEKV-0007B6-Rc; Tue, 27 Nov 2012 01:07:36 -0500 Message-ID: <001201cdcc65$8d8fff00$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Joan Cucchiara" , "Sam Aldrin" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> Date: Mon, 26 Nov 2012 22:07:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97efbb87635fe596fc107a9e066887bd02c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.147 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 06:10:16 -0000 Hi - > From: "Joan Cucchiara" > To: "Randy Presuhn" ; "Sam Aldrin" > Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" > Sent: Monday, November 26, 2012 9:08 PM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt ... > So to carry this example a step further, then the M (mapping) Table in the > new MIB associates I1 and I2. So for example, > I1 has a value of "John Doe" (fooName) and the new MIB has I2 with a value > of "Doe, John" (fooLastCommaFirstName) > and an entry is created in M which associates "JohnDoe" with "Doe, John". > Is this correct? Yes. "Smith, Mary" <-> "Smith, Mary" is also possible, BTW. *How* mapping M is maintained is a bit of magic. For example, mappings like "Pookie" <-> "Howell, Thurston III" are possible as well, at least in concept. :-) > The draft is doing something different. Using your example above, the > draft proposes the following steps, which MUST be in this order: > > * Create an entry in T2 with I2 in the new MIB. (T2 is the mapping table, > M, which maps I2 to the actual ID for the Tunnel with TP). > * Create an entry in T1 using I2 as the index. (There is no I1.) Uh, I think what they mean here is "Create an entry in T1, using for the value of I1 whatever the value of I2 happens to be, assuming that the normal operation of the system will avoid collisions." > * Create additional entries in a few tables in the new draft ('reverse' > mapping tables, and also a table which associates the T1 entry to a second > T1 entry which is how bi-directional tunnels are represented in the new > draft. Bi-directional tunnels are for TP and did not exist in the original > MIB.) > > The original Tunnels represented in T1 were of type Unsigned32 and > represented a value that was meaningful on the network. I missed the part about "a value that was meaningful on the network" in the earlier discussion. To which entities in the network would a given value have the same meaning? > The new Tunnels with TP are either "Global Id" of OCTET (SIZE 4) , or "ICC > Id" of OCTET (SIZE 6). These are two completely different data types, so confusion should not be an issue... > Since the new Tunnels with TP, share the same objects (but NOT the index) as > the original Tunnels represented in rfc3812, then the goal is to use the > original T1. The "gotcha" is that the original MIB is indexed by > Unsigned32 value which was unique unique within what scope? > and meaningful on the network which network? globally? > BUT this > index (I1) has no meaning wrt these new Tunnels with TP. The new tunnels > are identified by Global Id (OCTET STRING (SIZE 4)) or Icc Id (OCTET STRING > (SIZE 6)). > > So the solution being proposed is to create an entry in T2 with I2 (again > T2 IS the M (mapping table)), and then create an entry in T1 which MUST use > I2 as the index. Again, a nit: if the mapping is simple identity, then it's not T1 *using* I2. T1 still uses I1. What *is* being imposed are some assumptions about how the set of values for I2 is allocated. Specifically, when value is assigned for I2, there's a strong assumption that that value will not collide with another use of that same value in the set of values taken by I1 in that implementation. At this point, it sounds like they're on a potentially risky path. Not necessarily broken, but one that demands careful thought and documentation of the operational assumptions. > Keeping in mind that I1 is value which is unique and meaningful on the > network, and what is being proposed is just a value within Unsigned32 range, > but doesn't appear anywhere on the network, may cause some confusion for > legacy apps. Now this seems to be a quite different understanding of the semantics of the indexes from what I've gleaned from the conversation so far. In particular, up to this point it seemed that the "old" index was *less* semantically constrained, at least as far was the description clauses went. > An analogy would be to create a T2 which is in the correct format, but is > not identifiable as a name. How would something be "not identifiable as a name"? My experience is that if someone says something is their name, there's no point in contradicting them. Consequently, I have trouble with the concept "not identifiable as a name". Saying that something is "a name" gives us an idea what it means, but doesn't provide any help in limiting the set of possible values. Randy From randy_presuhn@mindspring.com Mon Nov 26 22:20:15 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5D21F8670 for ; Mon, 26 Nov 2012 22:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COpaUii08G2X for ; Mon, 26 Nov 2012 22:20:14 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6EC21F877F for ; Mon, 26 Nov 2012 22:20:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KHz0n3DIe9gFA9t902FqnJmapLC5+sj9wh5Um71fJRNqrj2jhwkDe1PEi26CHUIQ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.147] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TdEWi-0006de-CL; Tue, 27 Nov 2012 01:20:12 -0500 Message-ID: <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Sam Aldrin" , "Joan Cucchiara" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> Date: Mon, 26 Nov 2012 22:20:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97ed88c02fd62cd39e8009c1b8aad9dd4b3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.147 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 06:20:15 -0000 Hi - > From: "Sam Aldrin" ... > * Create additional entries in a few tables in the new draft > ('reverse' mapping tables, and also a table which associates > the T1 entry to a second T1 entry which is how bi-directional > tunnels are represented in the new draft. Bi-directional tunnels > are for TP and did not exist in the original MIB.) %sam- having bi-directional tunnels could be associated or congruent. So, it is not necessary that there is always entry will be present all the time. Also, there is an effort to bring TP technologies in to TE land. In that case, the existing MIB has to be redone. This change being proposed will help when that happens as well. Suggestion - if you haven't already done so, it might be helpful to document (in the form of examples) what the most important cases would look like in terms of index structure, giving at least some thought to what things might look like if someone looks at the MIB while a tunnel is still under construction. (This usually entails carving out an index value for "none" or talking about what a reference to a nonexistent row means. Sounds complicated, but from an implementation point of view ends up being simpler that putting in elaborate referential integrity constraints.) ... > The new tunnels are identified by Global Id (OCTET > STRING (SIZE 4)) or Icc Id (OCTET STRING (SIZE 6)). %sam - which is the reason why mapping table is still needed whether old tunnel table or new tunnel table is used. I'm hearing two different narratives regarding the mapping table. :-) ... %sam - the value of l1, though unique, having non-ip address value mean nothing, even to the legacy application. That is why, re-using the table with non-ip value is a perfect choice. This seems to be the key point of disagreement, and is really at the heart of whether there's a potential operational problem. Two different people reading the MIB have come to different understandings of the significance of "I1". Perhaps it would be helpful for both of you to go back to the source documents to understand (1) how you came to your own understanding of the situation, and (2) to look for clues that might have lead the other person to read it another way. Randy From sam.aldrin@gmail.com Mon Nov 26 22:43:55 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD7B21F86F6 for ; Mon, 26 Nov 2012 22:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf2-AwyRtEnG for ; Mon, 26 Nov 2012 22:43:54 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C66521F867E for ; Mon, 26 Nov 2012 22:43:54 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so8424834pbc.31 for ; Mon, 26 Nov 2012 22:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=JfRQSLYtn/KfF4Vsl8f8ygwvHZj8Uco29bU2Jh1xXR0=; b=N9Y1xf3631X2eFmNPGCxYHJPp8gdwAPu75Y9/KRIaZEjdm2/kfNr1mAe9rxtK8aLMR fSNw/0ebTmhsuleP4EoP3dlo49YPU342N2hPvVRhx3rVLz28af7MLDVAUJ+doNZW+Q8H jwd1UEFPQ3bRuAxQ5kvNVZAcn1GefpUHBMP6ANZfQksTu1C8V61Fdk1fUjGdgQGcHdJC nZmhlrxrjxh0ixz8dX91v/fTNikdOcFdbYrsFz1a8TNX1gitZaQPFIR5Ke0GTGN3G6LD tGizRIQoRoDlYx/BJ3wVyPbwhFpY/dNkKpszEzzcdgPb+6oN1iZI9F4kRqyvlyaKlTZK Wh7w== Received: by 10.68.231.97 with SMTP id tf1mr45011746pbc.149.1353998633991; Mon, 26 Nov 2012 22:43:53 -0800 (PST) Received: from [192.168.1.3] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id kb3sm10120787pbc.27.2012.11.26.22.43.52 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 22:43:53 -0800 (PST) References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> Mime-Version: 1.0 (1.0) In-Reply-To: <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> X-Mailer: iPad Mail (10A523) From: Sam Aldrin Date: Mon, 26 Nov 2012 22:43:52 -0800 To: Randy Presuhn Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 06:43:55 -0000 Hi Randy, Thanks for the reply. Find comments in line with %sam2. Sam Sent from my iPad On Nov 26, 2012, at 10:20 PM, "Randy Presuhn" = wrote: > Hi - >=20 >> From: "Sam Aldrin" > ... >> * Create additional entries in a few tables in the new draft=20 >> ('reverse' mapping tables, and also a table which associates >> the T1 entry to a second T1 entry which is how bi-directional >> tunnels are represented in the new draft. Bi-directional tunnels >> are for TP and did not exist in the original MIB.) >=20 > %sam- having bi-directional tunnels could be associated or > congruent. So, it is not necessary that there is always entry > will be present all the time. > Also, there is an effort to bring TP technologies in to TE land. > In that case, the existing MIB has to be redone. This change > being proposed will help when that happens as well. >=20 > Suggestion - if you haven't already done so, it might be > helpful to document (in the form of examples) what the > most important cases would look like in terms of index > structure, giving at least some thought to what things > might look like if someone looks at the MIB while a tunnel > is still under construction. (This usually entails carving out > an index value for "none" or talking about what a reference > to a nonexistent row means. Sounds complicated, but > from an implementation point of view ends up being simpler > that putting in elaborate referential integrity constraints.) %sam2- yes, we have indeed added examples for associated and co-routed tunne= ls, so that there is not much confusion. Let me know if they could be improv= ed in any way. I may not have communicated properly, what I wanted to, in my= earlier comment. All I was saying is, for ex: in the case of associated tun= nels, mid point device may not have reverse direction tunnel, as it could tr= averse via different path.=20 >=20 > ... >> The new tunnels are identified by Global Id (OCTET >> STRING (SIZE 4)) or Icc Id (OCTET STRING (SIZE 6)). >=20 > %sam - which is the reason why mapping table is still > needed whether old tunnel table or new tunnel table is used. >=20 > I'm hearing two different narratives regarding the mapping table. :-) %sam2- ignore my earlier comment for now. Can address later, if needed, and n= ot is things up. >=20 > ... > %sam - the value of l1, though unique, having non-ip address > value mean nothing, even to the legacy application. That is > why, re-using the table with non-ip value is a perfect choice. >=20 > This seems to be the key point of disagreement, and is really > at the heart of whether there's a potential operational problem. > Two different people reading the MIB have come to different > understandings of the significance of "I1". Perhaps it would > be helpful for both of you to go back to the source documents to > understand (1) how you came to your own understanding > of the situation, and (2) to look for clues that might have lead > the other person to read it another way. %sam2- if I understand right, the point of disagreement is, in the existing M= IB, the index value hold router ID, which identifies the device. This requir= es the value to be valid IP address. So, legacy applications, could use it t= o identify the device. What the new MIB extension proposes is, to use the index with value on non-i= p address I.e 0 to 1.0.0.0.0. The value within this range doesn't have globa= l significance, even for legacy applications. So, using it as local identifi= er to find the actual identifiers via map table is a neat way of indirection= . Ideally, we would have liked TE MIB foresee the TP requirements and have had= extensible index :D. Unfortunately it is not the case. Sam >=20 > Randy >=20 From randy_presuhn@mindspring.com Tue Nov 27 00:01:58 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC321F852E for ; Tue, 27 Nov 2012 00:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcGClqDtJMFt for ; Tue, 27 Nov 2012 00:01:57 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 99A8421F8422 for ; Tue, 27 Nov 2012 00:01:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Qv6vGE7BPshHo3JE2paVuKsweljq6Swqreq7Zq5Omga/dOumopn+LkMFNL80x1zv; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.147] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TdG79-0007LS-R6; Tue, 27 Nov 2012 03:01:56 -0500 Message-ID: <000401cdcc75$960bad40$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Sam Aldrin" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> Date: Tue, 27 Nov 2012 00:02:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97ee682765972099b1190c5d313a046ca91350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.147 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 08:01:58 -0000 Hi - > From: "Sam Aldrin" > To: "Randy Presuhn" > Cc: "Joan Cucchiara" ; "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" > Sent: Monday, November 26, 2012 10:43 PM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt ... > %sam2- if I understand right, the point of disagreement is, in the > existing MIB, the index value hold router ID, which identifies the device. > This requires the value to be valid IP address. So, legacy applications, > could use it to identify the device. > > What the new MIB extension proposes is, to use the index with value > on non-ip address I.e 0 to 1.0.0.0.0. The value within this range > doesn't have global significance, even for legacy applications. Would it be fair to say that there is a set of values (i.e 0 to 1.0.0.0) permitted by the syntax and description of the old index, but which, due to the normal operation of implementations, would not be observed in a legacy environment? I think part of Joan's concern is whether anything in the original specification would lead implementors to do something bad with the handling of values from within that range, like trying to do a traceroute to that IP address . That is a legitimate concern. For me, a more callous attitude leads my thinking: If the original specification did nothing to suggest that that range would be "off limits", then I think there's no problem. When implementors read constraints into an OBJECT-TYPE that aren't supported by the SYNTAX or DESCRIPTION, they have only themselves to blame if a later usage of that module doesn't obey the constraints they imagined. Wise designers will recognize the truth in both positions, and consider operational practice and deployed implementations in weighing their decisions. :-) For the original data type to have been Unsigned32, rather than an adress type, biases me towards rejecting the notion that management applications would be justified in casting it to an IPv4 address. But what management applications actually *do* will trump any of my theorizing. > So, using it as local identifier to find the actual identifiers via map > table is a neat way of indirection. > > Ideally, we would have liked TE MIB foresee the TP requirements > and have had extensible index :D. Unfortunately it is not the case. It still sounds like you and Joan need to figure out whether there really *is* a map table or not. :-) Even if it's not part of the final RFC, and E-R diagram might be helpful. Randy From sam.aldrin@gmail.com Tue Nov 27 07:54:59 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F93E21F8504 for ; Tue, 27 Nov 2012 07:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFkEhdGTPGKC for ; Tue, 27 Nov 2012 07:54:58 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C93E821F84C8 for ; Tue, 27 Nov 2012 07:54:58 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2699697dae.31 for ; Tue, 27 Nov 2012 07:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=cAq/schHVWcahNMG/2jgg847IwEoCFBp67qbGt+8gv4=; b=Cwc3smpnBU6zkMLpJDCHPjms5HpwZHG2uiDOmmgzht6PrpmBJJ1suvPs5s9J/lCsoj lR1nUfyhN1JTkrzRvDAfZCqZz2pm/XnZayOFg+qPO50QgsWiG0lAsmQQpXJEORGBqJNw 5Bn6Vcaez6glNs/GsIZhaeSuky7n6ARKEKIhf75bs+5DJXkuRj1z7GvqnLHYk29P80kH o2+yiWx1aMLCZHYPz78r49pdy3/vjQPrbFwv5cb3MQs9obG69Ah2Di0CPKhKZr6Hr3Eg nJkqP4ISLpAXzPQ+C4o0Q4lxSwwivlgfi4CR0FUj6s5MAaz2/kFlmbZnp8JZORd9Cwpf sO0A== Received: by 10.66.85.67 with SMTP id f3mr44005093paz.0.1354031698647; Tue, 27 Nov 2012 07:54:58 -0800 (PST) Received: from [192.168.1.7] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id sw1sm10810924pbc.75.2012.11.27.07.54.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 07:54:57 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <000401cdcc75$960bad40$6b01a8c0@oemcomputer> Date: Tue, 27 Nov 2012 07:54:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <76C1C5DB-901B-4A2C-8B1D-FAA63259B8BC@gmail.com> References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> <000401cdcc75$960bad40$6b01a8c0@oemcomputer> To: Randy Presuhn X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:54:59 -0000 Hi Randy, Comments inline with %sam3. -sam On Nov 27, 2012, at 12:02 AM, Randy Presuhn = wrote: > Hi - >=20 >> From: "Sam Aldrin" >> To: "Randy Presuhn" >> Cc: "Joan Cucchiara" ; "Venkatesan = Mahalingam" ; "MIB Doctors (E-mail)" > ; "venkatesan mahalingam" = ; "Kannan Sampath" >> Sent: Monday, November 26, 2012 10:43 PM >> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt > ... >> %sam2- if I understand right, the point of disagreement is, in the >> existing MIB, the index value hold router ID, which identifies the = device. >> This requires the value to be valid IP address. So, legacy = applications, >> could use it to identify the device. >>=20 >> What the new MIB extension proposes is, to use the index with value >> on non-ip address I.e 0 to 1.0.0.0.0. The value within this range >> doesn't have global significance, even for legacy applications. >=20 > Would it be fair to say that there is a set of values (i.e 0 to = 1.0.0.0) > permitted by the syntax and description of the old index, but which, > due to the normal operation of implementations, would not be observed > in a legacy environment? %sam - Correct. Here is why "mplsTunnelIngressLSRId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identity of the ingress LSR associated with this tunnel instance. When the MPLS signalling protocol is rsvp(2) this value SHOULD be equal to the Tunnel Sender Address in the Sender Template object and MAY be equal to the Extended Tunnel Id field in the SESSION object. When the MPLS signalling protocol is crldp(3) this value SHOULD be equal to the Ingress LSR Router ID field in the LSPID TLV object." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Constraint-Based LSP Setup using LDP, Jamoussi (Editor), RFC 3212, January 2002" ::=3D { mplsTunnelEntry 3 } Though the non-ip value is permitted, the semantics of the object = restrict it to valid router ID.=20 So, the range from 0 - valid ip is implicitly not used. >=20 > I think part of Joan's concern is whether anything in the original > specification would lead implementors to do something bad > with the handling of values from within that range, like > > trying to do a traceroute to that IP address > . %sam3- It is legitimate concern. The question is, how can one perform = trace route to invalid ip address? >=20 > That is a legitimate concern. For me, a more callous attitude > leads my thinking: >=20 > If the original specification did nothing to suggest that that range > would be "off limits", then I think there's no problem. When > implementors read constraints into an OBJECT-TYPE that > aren't supported by the SYNTAX or DESCRIPTION, they > have only themselves to blame if a later usage of that > module doesn't obey the constraints they imagined. >=20 > Wise designers will recognize the truth in both positions, > and consider operational practice and deployed implementations > in weighing their decisions. :-) >=20 > For the original data type to have been Unsigned32, rather than > an adress type, biases me towards rejecting the notion that > management applications would be justified in casting it > to an IPv4 address. But what management applications > actually *do* will trump any of my theorizing. %sam3 - Three implementors of the this MIB have tested this with their = own management applications. None had issue because, when it encounters = invalid-ip as the ingress or egress LSR ID, it identifies that it is not = a legacy TE tunnel. I cannot speak for every application though. >=20 >> So, using it as local identifier to find the actual identifiers via = map >> table is a neat way of indirection. >>=20 >> Ideally, we would have liked TE MIB foresee the TP requirements >> and have had extensible index :D. Unfortunately it is not the case. >=20 > It still sounds like you and Joan need to figure out whether there > really *is* a map table or not. :-) Even if it's not part of the = final > RFC, and E-R diagram might be helpful. %sam3 - Any info needed to clear the confusion, we definitely could add = that. Hopefully, Joan is OK with this. -sam >=20 > Randy >=20 >=20 From jcucchiara@mindspring.com Tue Nov 27 11:29:03 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BC021F86B5 for ; Tue, 27 Nov 2012 11:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOOIG7scNtmE for ; Tue, 27 Nov 2012 11:29:03 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id CEB8A21F8686 for ; Tue, 27 Nov 2012 11:29:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RgucBPmYQ8CzOluXml52/vACpd52UQ2wYYAWzVXnwcCqaT+BFOmCDfPgaxjVJH8U; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TdQq5-0002SI-5l; Tue, 27 Nov 2012 14:29:01 -0500 Message-ID: <00a801cdccd5$73696600$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Randy Presuhn" , "Sam Aldrin" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> <000401cdcc75$960bad40$6b01a8c0@oemcomputer> Date: Tue, 27 Nov 2012 14:28:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654ce51322650586f33fa82786b3c464143a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 19:29:03 -0000 ----- Original Message ----- From: "Randy Presuhn" To: "Sam Aldrin" Cc: "Joan Cucchiara" ; "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" Sent: Tuesday, November 27, 2012 3:02 AM Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt > Hi - > >> From: "Sam Aldrin" >> To: "Randy Presuhn" >> Cc: "Joan Cucchiara" ; "Venkatesan Mahalingam" >> ; "MIB Doctors (E-mail)" > ; "venkatesan mahalingam" ; > "Kannan Sampath" >> Sent: Monday, November 26, 2012 10:43 PM >> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance >> ondraft-ietf-mpls-te-tp-mib-05.txt > ... >> %sam2- if I understand right, the point of disagreement is, in the >> existing MIB, the index value hold router ID, which identifies the >> device. >> This requires the value to be valid IP address. So, legacy applications, >> could use it to identify the device. >> >> What the new MIB extension proposes is, to use the index with value >> on non-ip address I.e 0 to 1.0.0.0.0. The value within this range >> doesn't have global significance, even for legacy applications. > > Would it be fair to say that there is a set of values (i.e 0 to 1.0.0.0) > permitted by the syntax and description of the old index, but which, > due to the normal operation of implementations, would not be observed > in a legacy environment? > > I think part of Joan's concern is whether anything in the original > specification would lead implementors to do something bad > with the handling of values from within that range, like > > trying to do a traceroute to that IP address > . Randy, Yes, you have hit the nail on the head! > > That is a legitimate concern. For me, a more callous attitude > leads my thinking: > > If the original specification did nothing to suggest that that range > would be "off limits", then I think there's no problem. When > implementors read constraints into an OBJECT-TYPE that > aren't supported by the SYNTAX or DESCRIPTION, they > have only themselves to blame if a later usage of that > module doesn't obey the constraints they imagined. > > Wise designers will recognize the truth in both positions, > and consider operational practice and deployed implementations > in weighing their decisions. :-) > > For the original data type to have been Unsigned32, rather than > an adress type, biases me towards rejecting the notion that > management applications would be justified in casting it > to an IPv4 address. But what management applications > actually *do* will trump any of my theorizing. > I am perhaps being too literal. The original MIB says this value is used to "identify" the Ingress/Egress of the LSR (Lable Switch Router). In MPLS every router in the network is given an LSR Id (this is typically the 4 byte Router Id). I think for purposes of this discussion the LSR Id is equivalent to the Router Id. To quote from the original MIB (rfc3812): mplsTunnelIngressLSRId DESCRIPTION "Identity of the ingress LSR associated with this tunnel instance..." mplsTunnelEgressLSRId DESCRIPTION "Identity of the egress LSR associated with this tunnel instance." In other words, the LSR ID of the router which is unique within the LSR's network. I1 contains the LSR ID. (There are actually 2 INDEXES for each Tunnel Entry, one for Ingress and one for Egress, but think using I1 is fine.) (So yes, I am concerned about those legacy apps that use the LSR ID.) The proposed draft is creating a value (I2) in T2, which does NOT identify the LSR of the Ingress/Egress and then creates a Row in T1 with an I1 which is equal to I2 (so now I1 is some non-IP number which is NOT the LSR ID of the Router which has the Ingress/Egress). As far as I can tell (and Sam could confirm this?) Tunnels with TP have an LSR ID also BUT this LSR ID has 2 possible types: (Global_Node_ID which is an OCTET STRING (SIZE 4)) and is related to an ASN, or ICC which is an OCTET STRING(SIZE 1..6)) So this is the question: If the DESCRIPTION specifies that an INDEX has the value of an Identifier (like Router Id, or LSR ID) and the SYNTAX allows for values which are not the Identifier (the non-IP range), can a subsequent MIB come along which defines values (non-IP range) that are not an Identifier, even if the DESCRIPTION says that it is an Identifier? The only way to get the LSR ID for Tunnels with TP is to use the I2 (which == I1) (i.e. the non-IP range) to do a look-up of an Identifier (i.e. one of the new types of LSR ID for Tunnels with TP (Global_Node_ID or ICC_ID)? (I have been calling this map, so map or associate I2 with a value that is a new type of LSR ID.) So, yes, I am definitely concerned about the legacy apps that could be broken, but am also concerned because the DESCRIPTION says that it is an Identifier of a Router, and the proposed draft is assigning a value that is not an Identifier of a Router. >> So, using it as local identifier to find the actual identifiers via map >> table is a neat way of indirection. >> >> Ideally, we would have liked TE MIB foresee the TP requirements >> and have had extensible index :D. Unfortunately it is not the case. > > It still sounds like you and Joan need to figure out whether there > really *is* a map table or not. :-) Even if it's not part of the final > RFC, and E-R diagram might be helpful. > I agree. -Joan > Randy > > From sam.aldrin@gmail.com Tue Nov 27 14:05:06 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9C11E8097 for ; Tue, 27 Nov 2012 14:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7gkftV7EROi for ; Tue, 27 Nov 2012 14:05:05 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5407921F8559 for ; Tue, 27 Nov 2012 14:05:05 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so7060247pad.31 for ; Tue, 27 Nov 2012 14:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=YyuyxBBVjqCG43sxMli6BSiqk8g146m1IGVwwfpfc2k=; b=i1nL58XK1B2Ku1uVg+mIfm6Edp5CDRWER8AwvU9162vOIIDUczdG0WzDy2MYk5IwKB t1H4cNs9kZUaWpLPtC+L3PRZ4/MM4BSFC3teRvig+WFkBRPhwp6AQwWgCURQ2Us2jOsQ I/dlHmtopMtwNHZginhBM2l07MBimB6rKY58i9yj2dbv8wQESjtUAAoZxLnnEgR+gAqT EJj9i5K2h86nQyYEUTr4HhG81qCfaU6zyGQe4spg8oeJ8esNZKMnpTXWP67Q+CRAsyNJ tX+Tz8Cyz5EdpS/JImTvSIJq4qc68TJVkI0D8j8BuKhuGoKH4DATSgQYRQPlgCyA1FTm eZRQ== Received: by 10.68.132.202 with SMTP id ow10mr51243979pbb.139.1354053905108; Tue, 27 Nov 2012 14:05:05 -0800 (PST) Received: from [192.168.253.206] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id uh9sm11246763pbc.5.2012.11.27.14.05.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 14:05:04 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_3EC0D417-E4DF-456D-8828-72A2C252181B" From: Sam Aldrin X-Priority: 3 In-Reply-To: <00a801cdccd5$73696600$6801a8c0@JoanPC> Date: Tue, 27 Nov 2012 14:05:01 -0800 Message-Id: <451CDC4A-985E-42A3-AF46-127FF108D477@gmail.com> References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> <000401cdcc75$960bad40$6b01a8c0@oemcomputer> <00a801cdccd5$73696600$6801a8c0@JoanPC> To: "Joan Cucchiara" X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , venkatesan mahalingam , Kannan Sampath , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:05:06 -0000 --Apple-Mail=_3EC0D417-E4DF-456D-8828-72A2C252181B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Comments inline. On Nov 27, 2012, at 11:28 AM, "Joan Cucchiara" = wrote: >=20 > ----- Original Message ----- From: "Randy Presuhn" = > To: "Sam Aldrin" > Cc: "Joan Cucchiara" ; "Venkatesan = Mahalingam" ; "MIB Doctors (E-mail)" = ; "venkatesan mahalingam" ; = "Kannan Sampath" > Sent: Tuesday, November 27, 2012 3:02 AM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt >=20 >=20 >> Hi - >>=20 >>> From: "Sam Aldrin" >>> To: "Randy Presuhn" >>> Cc: "Joan Cucchiara" ; "Venkatesan = Mahalingam" ; "MIB Doctors (E-mail)" >> ; "venkatesan mahalingam" = ; "Kannan Sampath" >>> Sent: Monday, November 26, 2012 10:43 PM >>> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt >> ... >>> %sam2- if I understand right, the point of disagreement is, in the >>> existing MIB, the index value hold router ID, which identifies the = device. >>> This requires the value to be valid IP address. So, legacy = applications, >>> could use it to identify the device. >>>=20 >>> What the new MIB extension proposes is, to use the index with value >>> on non-ip address I.e 0 to 1.0.0.0.0. The value within this range >>> doesn't have global significance, even for legacy applications. >>=20 >> Would it be fair to say that there is a set of values (i.e 0 to = 1.0.0.0) >> permitted by the syntax and description of the old index, but which, >> due to the normal operation of implementations, would not be observed >> in a legacy environment? >>=20 >> I think part of Joan's concern is whether anything in the original >> specification would lead implementors to do something bad >> with the handling of values from within that range, like >> >> trying to do a traceroute to that IP address >> . >=20 > Randy, >=20 > Yes, you have hit the nail on the head! %sam - I do not think that is an issue. Two reasons 1. In IPv6 network, router ID is explicitly configured as IPv4 address = (for OSPF). Traceroute will fail in legacy applications as well. 2. In the LSR ID is non-ip address, one cannot(should not) perform trace = route. >=20 >=20 >>=20 >> That is a legitimate concern. For me, a more callous attitude >> leads my thinking: >>=20 >> If the original specification did nothing to suggest that that range >> would be "off limits", then I think there's no problem. When >> implementors read constraints into an OBJECT-TYPE that >> aren't supported by the SYNTAX or DESCRIPTION, they >> have only themselves to blame if a later usage of that >> module doesn't obey the constraints they imagined. >>=20 >> Wise designers will recognize the truth in both positions, >> and consider operational practice and deployed implementations >> in weighing their decisions. :-) >>=20 >> For the original data type to have been Unsigned32, rather than >> an adress type, biases me towards rejecting the notion that >> management applications would be justified in casting it >> to an IPv4 address. But what management applications >> actually *do* will trump any of my theorizing. >>=20 >=20 > I am perhaps being too literal. The original MIB says this value is = used to "identify" the Ingress/Egress of the LSR (Lable Switch Router). > In MPLS every router in the network is given an LSR Id (this is = typically the 4 byte Router Id). I think for purposes of this = discussion > the LSR Id is equivalent to the Router Id. >=20 > To quote from the original MIB (rfc3812): >=20 > mplsTunnelIngressLSRId > DESCRIPTION "Identity of the ingress LSR associated with this tunnel = instance..." >=20 > mplsTunnelEgressLSRId > DESCRIPTION "Identity of the egress LSR associated with this tunnel = instance." >=20 > In other words, the LSR ID of the router which is unique within the = LSR's network. >=20 > I1 contains the LSR ID. (There are actually 2 INDEXES for each = Tunnel Entry, one for Ingress and one for Egress, but think using I1 is = fine.) >=20 > (So yes, I am concerned about those legacy apps that use the LSR ID.) %sam - May be it would be helpful if you could list out potential issues = for legacy applications, when non-ip address value is used for the LSR = ID. >=20 > The proposed draft is creating a value (I2) in T2, which does NOT = identify the LSR of the Ingress/Egress and then creates a Row in > T1 with an I1 which is equal to I2 (so now I1 is some non-IP number = which is NOT the LSR ID > of the Router which has the Ingress/Egress). >=20 > As far as I can tell (and Sam could confirm this?) Tunnels with TP = have an LSR ID also BUT this LSR ID has 2 possible types: > (Global_Node_ID which is an OCTET STRING (SIZE 4)) and is related to = an ASN, or ICC which is an OCTET STRING(SIZE 1..6)) %sam - Partially correct. For ICC type, it is Octet string as mentioned. = For IP type, it is made up of (GlobalID+NodeID) +Tunnel Num will = identify the device. >=20 > So this is the question: If the DESCRIPTION specifies > that an INDEX has the value of an Identifier (like Router Id, or LSR = ID) and the SYNTAX allows for values which are not the Identifier (the = non-IP range), can a subsequent MIB come along which defines values = (non-IP range) that are not an Identifier, even if the DESCRIPTION says = that it is an Identifier? %sam - If I understand Randy'e email, it is OK to define value to use = non-ip range. >=20 > The only way to get the LSR ID for Tunnels with TP is to use the I2 = (which =3D=3D I1) (i.e. the non-IP range) to do a look-up of an = Identifier (i.e. one of the new types of LSR ID for Tunnels with TP = (Global_Node_ID or ICC_ID)? (I have been calling this map, so map or = associate I2 with a value that is a new type of LSR ID.) >=20 > So, yes, I am definitely concerned about the legacy apps that could be = broken, but am also concerned because the DESCRIPTION says that it is > an Identifier of a Router, and the proposed draft is assigning a value = that is not an Identifier of a Router. %sam - It is an identifier of a router, which has local significance. = The name of the object, in the NodeConfigTable also emphasize that. = Using the mplsTunnelExtNodeConfigTable, described in sec 8.0, one could = map the TP identifies to a local identifier, which could be used index = into Tunnel table.=20 In order to resolve, may be it is good to table the issues of legacy = applications and discuss about them. Three of the applications I know = off, didn't have the issue dealing with the non-ip value for Tunnel = indices. cheers -sam >=20 >=20 >>> So, using it as local identifier to find the actual identifiers via = map >>> table is a neat way of indirection. >>>=20 >>> Ideally, we would have liked TE MIB foresee the TP requirements >>> and have had extensible index :D. Unfortunately it is not the case. >>=20 >> It still sounds like you and Joan need to figure out whether there >> really *is* a map table or not. :-) Even if it's not part of the = final >> RFC, and E-R diagram might be helpful. >>=20 >=20 > I agree. >=20 > -Joan >=20 >> Randy >>=20 >=20 --Apple-Mail=_3EC0D417-E4DF-456D-8828-72A2C252181B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 jcucchiara@mindspring.com>= ; wrote:

----- Original Message ----- From: "Randy Presuhn" = <randy_presuhn@mindspring.com<= /a>>
To: "Sam Aldrin" <sam.aldrin@gmail.com>
Cc: = "Joan Cucchiara" <jcucchiara@mindspring.com>= ;; "Venkatesan Mahalingam" <venkat.mahalingams@gmail.com<= /a>>; "MIB Doctors (E-mail)" <mib-doctors@ietf.org>; = "venkatesan mahalingam" <venkatflex@gmail.com>; = "Kannan Sampath" <kannankvs@gmail.com>
Sent: = Tuesday, November 27, 2012 3:02 AM
Subject: Re: [MIB-DOCTORS] Request = for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt


Hi= -

From: "Sam Aldrin" <sam.aldrin@gmail.com>
To: = "Randy Presuhn" <randy_presuhn@mindspring.com<= /a>>
Cc: "Joan Cucchiara" <jcucchiara@mindspring.com>= ;; "Venkatesan Mahalingam" <venkat.mahalingams@gmail.com<= /a>>; "MIB Doctors (E-mail)"
<mib-doctors@ietf.org>; = "venkatesan mahalingam" <venkatflex@gmail.com>; = "Kannan Sampath" <kannankvs@gmail.com>
Sent: Monday, November 26, 2012 10:43 PM
Subject: = Re: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt
...
%sam2- if I understand right, the point of disagreement = is, in the
existing MIB, the index value hold router ID, which = identifies the device.
This requires the value to be valid IP = address. So, legacy applications,
could use it to identify the = device.

What the new MIB extension proposes is, to use the index = with value
on non-ip address I.e 0 to 1.0.0.0.0. The value within = this range
doesn't have global significance, even for legacy = applications.

Would it be fair to say that there is = a set of values (i.e 0 to 1.0.0.0)
permitted by the syntax and = description of the old index, but which,
due to the normal operation = of implementations, would not be observed
in a legacy = environment?

I think part of Joan's concern is whether anything = in the original
specification would lead implementors to do something = bad
with the handling of values from within that range, = like
<waving arms>
trying to do a traceroute to that IP = address
</waving arms>.

Randy,

Yes, = you have hit the nail on the head!
%sam - I do not think = that is an issue. Two reasons
1. In IPv6 network, router ID is = explicitly configured as IPv4 address (for OSPF). Traceroute will fail = in legacy applications as well.
2. In the LSR ID is non-ip = address, one cannot(should not) perform trace route.



That is a legitimate = concern.  For me, a more callous attitude
leads my = thinking:

If the original specification did nothing to suggest = that that range
would be "off limits", then I think there's no = problem.  When
implementors read constraints into an OBJECT-TYPE = that
aren't supported by the SYNTAX or DESCRIPTION, they
have only = themselves to blame if a later usage of that
module doesn't obey the = constraints they imagined.

Wise designers will recognize the = truth in both positions,
and consider operational practice and = deployed implementations
in weighing their decisions. =  :-)

For the original data type to have been Unsigned32, = rather than
an adress type, biases me towards rejecting the notion = that
management applications would be justified in casting it
to = an IPv4 address.  But what management applications
actually *do* = will trump any of my theorizing.


I am perhaps = being too literal.   The original MIB says this value is used = to "identify" the Ingress/Egress of the  LSR (Lable Switch = Router).
In MPLS every router in the network is given an LSR Id (this = is typically the 4 byte Router Id).   I think for purposes of = this discussion
the LSR Id is equivalent to the Router Id.

To = quote from the original MIB = (rfc3812):

mplsTunnelIngressLSRId
DESCRIPTION "Identity of the = ingress LSR associated with this tunnel = instance..."

mplsTunnelEgressLSRId
DESCRIPTION "Identity of = the egress LSR associated with this tunnel instance."

In other = words, the LSR ID of the router which is unique within the LSR's = network.

I1  contains the LSR ID.   (There are = actually 2 INDEXES for each Tunnel Entry,  one for Ingress and one = for Egress, but think using I1 is fine.)

(So yes, I am concerned = about those legacy apps that use the LSR ID.)
%sam - May = be it would be helpful if you could list out potential issues for legacy = applications, when non-ip address value is used for the LSR = ID.

The proposed draft is creating a = value (I2) in T2, which does NOT  identify the LSR of the = Ingress/Egress and then creates a Row in
T1 with an I1 which is equal = to I2   (so now I1 is  some non-IP number which is NOT = the LSR ID
of the Router which has the Ingress/Egress).

As far = as I can tell (and Sam could confirm this?) Tunnels with TP have an LSR = ID also BUT this LSR ID has 2 possible types:
(Global_Node_ID which = is an OCTET STRING (SIZE 4)) and is related to an ASN, or ICC which is = an OCTET STRING(SIZE 1..6))
%sam - Partially correct. = For ICC type, it is Octet string as mentioned. For IP type, it is made = up of (GlobalID+NodeID) +Tunnel Num will identify the = device.

So this is the question: =  If the DESCRIPTION specifies
that an INDEX has the value of an = Identifier (like Router Id, or LSR ID) and the SYNTAX allows for values = which are not the Identifier (the non-IP range), can a subsequent MIB = come along which defines values (non-IP range) that are not an = Identifier, even if the DESCRIPTION says that it is an = Identifier?
%sam - If I understand Randy'e email, it is = OK to define value to use non-ip range.

The only way to get the LSR ID for Tunnels with TP is = to use the I2 (which =3D=3D I1) (i.e. the non-IP range)  to do a = look-up of an Identifier (i.e. one of the new types of LSR ID for = Tunnels with TP (Global_Node_ID or ICC_ID)? (I have been calling this = map, so map or associate I2 with a value that is a new type of LSR = ID.)

So, yes, I am definitely concerned about the legacy apps = that could be broken, but am also concerned because the DESCRIPTION says = that it is
an Identifier of a Router, and the proposed draft is = assigning a value that is not an Identifier of a = Router.
%sam - It is an identifier of a router, which = has local significance. The name of the object, in the NodeConfigTable =  also emphasize that. Using the mplsTunnelExtNodeConfigTable, described in = sec 8.0, one could map the TP identifies to a local identifier, which = could be used index into Tunnel table. 
In order to resolve, may = be it is good to table the issues of legacy applications and discuss = about them. Three of the applications I know off, didn't have the issue = dealing with the non-ip value for Tunnel indices.

cheers
-sam



So, using it as local identifier to find the actual = identifiers via map
table is a neat way of = indirection.

Ideally, we would have liked TE MIB foresee the TP = requirements
and have had extensible index :D. Unfortunately it is = not the case.

It still sounds like you and Joan need = to figure out whether there
really *is* a map table or not.  :-) =  Even if it's not part of the final
RFC, and E-R diagram might = be helpful.


I = agree.

-Joan

Randy



<= /body>= --Apple-Mail=_3EC0D417-E4DF-456D-8828-72A2C252181B-- From randy_presuhn@mindspring.com Tue Nov 27 17:17:40 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6656521F87B4 for ; Tue, 27 Nov 2012 17:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbCOUkyBXct8 for ; Tue, 27 Nov 2012 17:17:39 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 933BA21F87B6 for ; Tue, 27 Nov 2012 17:17:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OzwGzmdob9Je4jdKFCrP3mpYA1wMU8zeJD7J7rrbWKE9AsvKMuCorfv1TLlShM6d; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.147] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TdWHR-0007p7-Uy; Tue, 27 Nov 2012 20:17:38 -0500 Message-ID: <000b01cdcd06$468a9ec0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Joan Cucchiara" , "Sam Aldrin" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> <000401cdcc75$960bad40$6b01a8c0@oemcomputer> <00a801cdccd5$73696600$6801a8c0@JoanPC> Date: Tue, 27 Nov 2012 17:18:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97e0427d3c92148697e00bdf713d32a7cfb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.147 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 01:17:40 -0000 Hi - > From: "Joan Cucchiara" > To: "Randy Presuhn" ; "Sam Aldrin" > Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" > Sent: Tuesday, November 27, 2012 11:28 AM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt ... > I am perhaps being too literal. The original MIB says this value is used > to "identify" the Ingress/Egress of the LSR (Lable Switch Router). FWIW, I only understood that to be in the context of the table, rather than as being an externally usable name. The bits of "SHOULD" language cited in this thread (rightly or wrongly) reinforced that impression, since to me a "SHOULD" means "one must not rely on this provision". > In MPLS every router in the network is given an LSR Id (this is typically > the 4 byte Router Id). I think for purposes of this discussion > the LSR Id is equivalent to the Router Id. Here's where we perhaps differ in our thinking. If it "is typically" rather than "MUST be", then code that uses the value outside the scope of the table is employing a fallible heuristic. > To quote from the original MIB (rfc3812): > > mplsTunnelIngressLSRId > DESCRIPTION "Identity of the ingress LSR associated with this tunnel > instance..." For me the rest of the DESCRIPTION is critical in determine the extent to which this value might be usable: When the MPLS signalling protocol is rsvp(2) this value SHOULD be equal to the Tunnel Sender Address in the Sender Template object and MAY be equal to the Extended Tunnel Id field in the SESSION object. When the MPLS signalling protocol is crldp(3) this value SHOULD be equal to the Ingress LSR Router ID field in the LSPID TLV object. I read this as saying that for rsvp(2) and crldp(3) there are heurstics (but NOT guarantees) of what the index value *might* equal, and that for any other signalling protocols, all bets are off. The language says it *might* be equal to Tunnel Sender Address, or it *might* be equal to Extended Tunnel Id, or it *might* be LSR Router ID, or it might be equal to none of these. > mplsTunnelEgressLSRId > DESCRIPTION "Identity of the egress LSR associated with this tunnel > instance." > > In other words, the LSR ID of the router which is unique within the LSR's > network. This one clearly lacks the wiggle room of the other, though the scope of "identity" (unique within this table in this instance of this implementation, or unique within this network?) > I1 contains the LSR ID. (There are actually 2 INDEXES for each Tunnel > Entry, one for Ingress and one for Egress, but think using I1 is fine.) > > (So yes, I am concerned about those legacy apps that use the LSR ID.) > > The proposed draft is creating a value (I2) in T2, which does NOT identify > the LSR of the Ingress/Egress and then creates a Row in > T1 with an I1 which is equal to I2 (so now I1 is some non-IP number which > is NOT the LSR ID > of the Router which has the Ingress/Egress). That depends on how one understandards "identify". If it's merely in a MIB sense (as in INDEX), there's no problem. If it's in the sense of "uniquely name something in the network in a way that non-SNMP infrastructure might use", then there's probably a problem. > As far as I can tell (and Sam could confirm this?) Tunnels with TP have an > LSR ID also BUT this LSR ID has 2 possible types: > (Global_Node_ID which is an OCTET STRING (SIZE 4)) and is related to an ASN, > or ICC which is an OCTET STRING(SIZE 1..6)) > > So this is the question: If the DESCRIPTION specifies > that an INDEX has the value of an Identifier (like Router Id, or LSR ID) > and the SYNTAX allows for values which are not the Identifier (the non-IP > range), can a subsequent MIB come along which defines values (non-IP range) > that are not an Identifier, even if the DESCRIPTION says that it is an > Identifier? That leads me to look at: MplsExtendedTunnelId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for an MPLS Tunnel. This may represent an IPv4 address of the ingress or egress LSR for the tunnel. This value is derived from the Extended Tunnel Id in RSVP or the Ingress Router ID for CR-LDP." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209]. Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX Unsigned32(0..4294967295) Now perhaps I'm reading too much into this, but to me the use of "may", the decision to use the Unsigned32 data type rather than an address data type, and the talk about the value being "derived" all suggest that any reliance on the value actually being equal to a usable IP address would be unwarranted. > The only way to get the LSR ID for Tunnels with TP is to use the I2 (which > == I1) (i.e. the non-IP range) to do a look-up of an Identifier (i.e. one > of the new types of LSR ID for Tunnels with TP (Global_Node_ID or ICC_ID)? > (I have been calling this map, so map or associate I2 with a value that is a > new type of LSR ID.) > > So, yes, I am definitely concerned about the legacy apps that could be > broken, but am also concerned because the DESCRIPTION says that it is > an Identifier of a Router, and the proposed draft is assigning a value that > is not an Identifier of a Router. Bringing us back to the question of whether they intend "identifier" to be of network-wide usability or merely for navigating within the MIB's tables accessed through a particular agent. Randy From jcucchiara@mindspring.com Wed Nov 28 06:38:56 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6E121F8825 for ; Wed, 28 Nov 2012 06:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq7xQfzVGJfI for ; Wed, 28 Nov 2012 06:38:56 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id D50B421F8811 for ; Wed, 28 Nov 2012 06:38:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GMW3PtTV0jZ5kwUcHevaEZSI7B3cvwXLWUl8rUHKjooxp749D7JCxyOHrWfmQJ5y; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Tdimr-0004KK-If; Wed, 28 Nov 2012 09:38:53 -0500 Message-ID: <01aa01cdcd76$15fcdaa0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Randy Presuhn" , "Sam Aldrin" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> <000401cdcc75$960bad40$6b01a8c0@oemcomputer> <00a801cdccd5$73696600$6801a8c0@JoanPC> <000b01cdcd06$468a9ec0$6b01a8c0@oemcomputer> Date: Wed, 28 Nov 2012 09:38:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26542894c7378d275d5b74e4fd177374879350e5dc5ab6323efb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 14:38:56 -0000 ----- Original Message ----- From: "Randy Presuhn" To: "Joan Cucchiara" ; "Sam Aldrin" Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" Sent: Tuesday, November 27, 2012 8:18 PM Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt > Hi - > >> From: "Joan Cucchiara" >> To: "Randy Presuhn" ; "Sam Aldrin" >> >> Cc: "Venkatesan Mahalingam" ; "MIB Doctors >> (E-mail)" ; "venkatesan mahalingam" > ; "Kannan Sampath" >> Sent: Tuesday, November 27, 2012 11:28 AM >> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance >> ondraft-ietf-mpls-te-tp-mib-05.txt > ... >> I am perhaps being too literal. The original MIB says this value is >> used >> to "identify" the Ingress/Egress of the LSR (Lable Switch Router). > > FWIW, I only understood that to be in the context of the table, > rather than as being an externally usable name. The bits of > "SHOULD" language cited in this thread (rightly or wrongly) > reinforced that impression, since to me a "SHOULD" means > "one must not rely on this provision". > >> In MPLS every router in the network is given an LSR Id (this is typically >> the 4 byte Router Id). I think for purposes of this discussion >> the LSR Id is equivalent to the Router Id. > > Here's where we perhaps differ in our thinking. If it "is typically" > rather > than "MUST be", then code that uses the value outside the scope of > the table is employing a fallible heuristic. > >> To quote from the original MIB (rfc3812): >> >> mplsTunnelIngressLSRId >> DESCRIPTION "Identity of the ingress LSR associated with this tunnel >> instance..." > > For me the rest of the DESCRIPTION is critical in determine the extent > to which this value might be usable: > When the MPLS signalling protocol > is rsvp(2) this value SHOULD be equal to the Tunnel > Sender Address in the Sender Template object and MAY > be equal to the Extended Tunnel Id field in the > SESSION object. When the MPLS signalling protocol is > crldp(3) this value SHOULD be equal to the Ingress > LSR Router ID field in the LSPID TLV object. > > I read this as saying that for rsvp(2) and crldp(3) there are heurstics > (but NOT guarantees) of what the index value *might* equal, and that > for any other signalling protocols, all bets are off. The language says > it *might* be equal to Tunnel Sender Address, or it *might* be equal > to Extended Tunnel Id, or it *might* be LSR Router ID, or it might be > equal to none of these. Yes, I can see that. > >> mplsTunnelEgressLSRId >> DESCRIPTION "Identity of the egress LSR associated with this tunnel >> instance." >> >> In other words, the LSR ID of the router which is unique within the LSR's >> network. > > This one clearly lacks the wiggle room of the other, though the scope of > "identity" (unique within this table in this instance of this > implementation, > or unique within this network?) > >> I1 contains the LSR ID. (There are actually 2 INDEXES for each Tunnel >> Entry, one for Ingress and one for Egress, but think using I1 is fine.) >> >> (So yes, I am concerned about those legacy apps that use the LSR ID.) >> >> The proposed draft is creating a value (I2) in T2, which does NOT >> identify >> the LSR of the Ingress/Egress and then creates a Row in >> T1 with an I1 which is equal to I2 (so now I1 is some non-IP number >> which >> is NOT the LSR ID >> of the Router which has the Ingress/Egress). > > That depends on how one understandards "identify". If it's merely in a > MIB sense (as in INDEX), there's no problem. If it's in the sense of > "uniquely name something in the network in a way that non-SNMP > infrastructure might use", then there's probably a problem. > >> As far as I can tell (and Sam could confirm this?) Tunnels with TP have >> an >> LSR ID also BUT this LSR ID has 2 possible types: >> (Global_Node_ID which is an OCTET STRING (SIZE 4)) and is related to an >> ASN, >> or ICC which is an OCTET STRING(SIZE 1..6)) >> >> So this is the question: If the DESCRIPTION specifies >> that an INDEX has the value of an Identifier (like Router Id, or LSR ID) >> and the SYNTAX allows for values which are not the Identifier (the non-IP >> range), can a subsequent MIB come along which defines values (non-IP >> range) >> that are not an Identifier, even if the DESCRIPTION says that it is an >> Identifier? > > That leads me to look at: > > MplsExtendedTunnelId ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A unique identifier for an MPLS Tunnel. This may > represent an IPv4 address of the ingress or egress > LSR for the tunnel. This value is derived from the > Extended Tunnel Id in RSVP or the Ingress Router ID > for CR-LDP." > REFERENCE > "RSVP-TE: Extensions to RSVP for LSP Tunnels, > [RFC3209]. > Constraint-Based LSP Setup using LDP, [RFC3212]." > SYNTAX Unsigned32(0..4294967295) > > Now perhaps I'm reading too much into this, but to me the use of > "may", the decision to use the Unsigned32 data type rather than > an address data type, and the talk about the value being "derived" > all suggest that any reliance on the value actually being equal to a > usable IP address would be unwarranted. > >> The only way to get the LSR ID for Tunnels with TP is to use the I2 >> (which >> == I1) (i.e. the non-IP range) to do a look-up of an Identifier (i.e. >> one >> of the new types of LSR ID for Tunnels with TP (Global_Node_ID or >> ICC_ID)? >> (I have been calling this map, so map or associate I2 with a value that >> is a >> new type of LSR ID.) >> >> So, yes, I am definitely concerned about the legacy apps that could be >> broken, but am also concerned because the DESCRIPTION says that it is >> an Identifier of a Router, and the proposed draft is assigning a value >> that >> is not an Identifier of a Router. > > Bringing us back to the question of whether they intend "identifier" to be > of network-wide usability or merely for navigating within the MIB's tables > accessed through a particular agent. Randy, I think you have some valid points in your analysis of the DESCRIPTION clauses, so Thank you for that. I would think (as you pointed out above) that the use of the word, "may" would indicate that the identifier is for navigating within the MIB's tables, and similar reasoning would be applied if legacy apps break due to the additional 2 new types added by the proposed draft. I think there are far better ways to represent a design which is like a C language switch statement. Adding another "case" which is actually one of two possibilities in hindsight in a different MIB doc, is perhaps unwise, but as you points out, it doesn't seem to break the SMI. Thanks again for your insight, -Joan > > Randy > > From randy_presuhn@mindspring.com Wed Nov 28 12:59:55 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4AD21F8554 for ; Wed, 28 Nov 2012 12:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVId1AcbjR5j for ; Wed, 28 Nov 2012 12:59:55 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id D6EAD21F84C6 for ; Wed, 28 Nov 2012 12:59:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gzTvIwpwyVw6cmzKGeqRrG1oz85eovNKyrPYAs08eZktJvqtWRy0QFM624uzqbmv; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.163.16] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TdojZ-0004n5-4x; Wed, 28 Nov 2012 15:59:53 -0500 Message-ID: <003801cdcdab$6f5426a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Joan Cucchiara" , "Sam Aldrin" References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> <000401cdcc75$960bad40$6b01a8c0@oemcomputer> <00a801cdccd5$73696600$6801a8c0@JoanPC> <000b01cdcd06$468a9ec0$6b01a8c0@oemcomputer> <01aa01cdcd76$15fcdaa0$6801a8c0@JoanPC> Date: Wed, 28 Nov 2012 13:00:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97ea2f29e88a2505b091800dd5f36299e81350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.163.16 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 20:59:55 -0000 Hi - > From: "Joan Cucchiara" > To: "Randy Presuhn" ; "Sam Aldrin" > Cc: "Venkatesan Mahalingam" ; "MIB Doctors (E-mail)" ; "venkatesan mahalingam" ; "Kannan Sampath" > Sent: Wednesday, November 28, 2012 6:38 AM > Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt ... > I think you have some valid points in your analysis of the DESCRIPTION > clauses, so Thank you for that. I would think (as you pointed out above) > that the use of the word, "may" would indicate that the identifier is for > navigating within the MIB's tables, and similar reasoning would be applied > if legacy apps break due to the additional 2 new types added by the proposed > draft. > > I think there are far better ways to represent a design which is like a C > language switch statement. Adding another "case" which is actually one of > two possibilities in hindsight in a different MIB doc, is perhaps unwise, > but as you points out, it doesn't seem to break the SMI. ... I think the thing most clear from this discussion is that the RFCs could have been much clearer about what was intended. In particular, I think this is a cautionary tale about the putting optional algorithms for the derivation of index values into description clauses without making the consequences of the optionality clear. The C construct all this reminds me of is the type cast, rather than the switch, since bit patterns are shoveled around in ways that result in the loss of their semantics, but tempt code maintainers to try to re-assert those semantics. Randy From sam.aldrin@gmail.com Wed Nov 28 14:07:35 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AE021F8923 for ; Wed, 28 Nov 2012 14:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7fxJQ8ChMOr for ; Wed, 28 Nov 2012 14:07:34 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2121F846A for ; Wed, 28 Nov 2012 14:07:34 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so9791881pbc.31 for ; Wed, 28 Nov 2012 14:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=SsJniAvyDTorx2aVCHqc4jeHLRuCIGe1CklalpoU4Ck=; b=UMPH+2ONyawQovhfy/l68fYZn5EmMHaogg9CaTwagOBWcOQZF2YAz452BVRP64LvEm VwAux3vEOBMMpJiSTYE5qhRBxKkz5ftJWoxkhLjgiZHQS8nDetFK2BYNfyzOQFrHKte8 gywWkS2GAovWTPG00fHQA9a++eGNwf5e7QUETOxPkShzpkDrZOTQMDaofp1qPE+nCIwj Q1mJeXAxhs+Zrad73zIDLCZdwo2v913jA+DyO/InXt7IeUrj0K/xAIJ+W6UdEcKwtFRA IQb6TW8ZM6FMh1hok4rZl6uTZauDQosTlm5ulzYBcgW27yvmXUp5ddAc1x3sHYcANcP9 4RsA== Received: by 10.69.16.100 with SMTP id fv4mr61841855pbd.135.1354140454454; Wed, 28 Nov 2012 14:07:34 -0800 (PST) Received: from [192.168.253.206] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id m4sm6553756pav.17.2012.11.28.14.07.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2012 14:07:33 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <003801cdcdab$6f5426a0$6b01a8c0@oemcomputer> Date: Wed, 28 Nov 2012 14:07:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <25421492.1353958076369.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <462f01cdcc5d$2e0162c0$6801a8c0@JoanPC> <59A94718-C0F6-497B-93B7-4665BB9FE118@gmail.com> <001501cdcc67$5f871b00$6b01a8c0@oemcomputer> <3FC29EDB-49ED-48E4-BD26-1169149BAADF@gmail.com> <000401cdcc75$960bad40$6b01a8c0@oemcomputer> <00a801cdccd5$73696600$6801a8c0@JoanPC> <000b01cdcd06$468a9ec0$6b01a8c0@oemcomputer> <01aa01cdcd76$15fcdaa0$6801a8c0@JoanPC> <003801cdcdab$6f5426a0$6b01a8c0@oemcomputer> To: "Randy Presuhn" X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , Kannan Sampath , venkatesan mahalingam Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance ondraft-ietf-mpls-te-tp-mib-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:07:35 -0000 Hi Randy and Joan, Really appreciate all your comments and concerns. Will re-spin a new version and put in more details, which should give = clear picture on what the model and incorporate necessary text to remove = any ambiguity. I will update the tracking excel sheet to incorporate all the received = comments. Feel free to send in any suggestions or comments. Will be happy to = address them and make any changes necessary. cheers -sam On Nov 28, 2012, at 1:00 PM, "Randy Presuhn" = wrote: > Hi - >=20 >> From: "Joan Cucchiara" >> To: "Randy Presuhn" ; "Sam Aldrin" = >> Cc: "Venkatesan Mahalingam" ; "MIB = Doctors (E-mail)" ; "venkatesan mahalingam" > ; "Kannan Sampath" >> Sent: Wednesday, November 28, 2012 6:38 AM >> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance = ondraft-ietf-mpls-te-tp-mib-05.txt > ... >> I think you have some valid points in your analysis of the = DESCRIPTION >> clauses, so Thank you for that. I would think (as you pointed out = above) >> that the use of the word, "may" would indicate that the identifier is = for >> navigating within the MIB's tables, and similar reasoning would be = applied >> if legacy apps break due to the additional 2 new types added by the = proposed >> draft. >>=20 >> I think there are far better ways to represent a design which is like = a C >> language switch statement. Adding another "case" which is actually = one of >> two possibilities in hindsight in a different MIB doc, is perhaps = unwise, >> but as you points out, it doesn't seem to break the SMI. > ... >=20 > I think the thing most clear from this discussion is that the RFCs = could have been > much clearer about what was intended. In particular, I think this is = a cautionary > tale about the putting optional algorithms for the derivation of index = values into > description clauses without making the consequences of the optionality = clear. >=20 > The C construct all this reminds me of is the type cast, rather than = the switch, > since bit patterns are shoveled around in ways that result in the loss = of their > semantics, but tempt code maintainers to try to re-assert those = semantics. >=20 > Randy >=20 >=20