From HaagT@telekom.de Fri Oct 2 07:05:01 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6991E3A683F for ; Fri, 2 Oct 2009 07:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLBStuhqSbm7 for ; Fri, 2 Oct 2009 07:05:00 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 34C133A6810 for ; Fri, 2 Oct 2009 07:04:59 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 02 Oct 2009 16:06:21 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:06:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 16:06:20 +0200 Message-ID: <5661758E3E93364685B91DD8272F287601E8E282@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4ABD73FC.9090805@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] test -- please ignore Thread-Index: Aco+TBsr2Kgbajb5SLi+REiEiW0qkgFHKoTQ References: <4ABD73FC.9090805@rogers.com> From: To: , X-OriginalArrivalTime: 02 Oct 2009 14:06:21.0568 (UTC) FILETIME=[85031800:01CA4369] Subject: Re: [ANCP] test -- please ignore X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 14:05:01 -0000 Hi Tom, It seems so. I'm waiting for more feedback on actions from 27th of = august. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Tom Taylor Gesendet: Samstag, 26. September 2009 03:53 An: ancp@ietf.org Betreff: [ANCP] test -- please ignore Wondering why the list has been dead since August. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From root@core3.amsl.com Mon Oct 5 03:15:01 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8B7B828C14F; Mon, 5 Oct 2009 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091005101501.8B7B828C14F@core3.amsl.com> Date: Mon, 5 Oct 2009 03:15:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-12.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 10:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-12.txt Pages : 55 Date : 2009-10-05 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing Operational Support Systems (OSSes). This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-framework-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-05030916.I-D@ietf.org> --NextPart-- From flefauch@cisco.com Thu Oct 8 07:52:24 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7695428C272 for ; Thu, 8 Oct 2009 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.926 X-Spam-Level: X-Spam-Status: No, score=-9.926 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9oK1Hj55J0H for ; Thu, 8 Oct 2009 07:52:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D8E3428C260 for ; Thu, 8 Oct 2009 07:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=3126; q=dns/txt; s=amsiport01001; t=1255013645; x=1256223245; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Re:=20Changes=20to=20ANCP=20multicast|Date: =20Thu,=208=20Oct=202009=2016:54:02=20+0200|Message-Id: =20<3C937557-C0B9-4C04-8CB9-36588A37CCBE@cisco.com>|To: =20Le=20Faucheur=20Francois=20,=0D=0A =20=20=20=20=20=20=20=20Tom=20Taylor=20|Cc:=20Maglione=20Roberta=20,=0D=0A=20=20=20=20=20=20=20=20Dec=20Wojciech =20,=20ancp@ietf.org|Mime-Version:=201.0 =20(Apple=20Message=20framework=20v1076) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20< 4ACB5AA7.5070807@rogers.com>=20<282BBE8A501E1F4DA9C775F96 4BB21FE3E670E7FCF@GRFMBX704BA020.griffon.local>=20<4ACB5F 01.9020709@rogers.com>=20; bh=cdKIpbERQ8YuEIZUq9VsTNbwOU5A2fVACTPB3e0a2l8=; b=khHmGV4cnbT4Mnssc3kvSEE5rfdpHUSuuLPW44l4COTCnreAfyxITTne Wn9LwaLwQ8kgyV8lL1nUA38nqs0xFCq/GdwnP7RjXMZx/rPsAdB9AQxSY KNZuE0pU8dATj9EH6JsjAtQ8up8ySUY93cpUleWWuOsvuvaY11/5c/5QT Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,525,1249257600"; d="scan'208";a="51292515" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 14:54:04 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n98Er4is019766; Thu, 8 Oct 2009 14:54:03 GMT References: <4ACB5AA7.5070807@rogers.com> <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FCF@GRFMBX704BA020.griffon.local> <4ACB5F01.9020709@rogers.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <3C937557-C0B9-4C04-8CB9-36588A37CCBE@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Thu, 8 Oct 2009 16:54:02 +0200 To: Le Faucheur Francois , Tom Taylor X-Mailer: Apple Mail (2.1076) Cc: ancp@ietf.org Subject: Re: [ANCP] Changes to ANCP multicast X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 14:52:24 -0000 including the ANCP list as others may be interested. Francois On 8 Oct 2009, at 16:53, Francois Le Faucheur wrote: > Hi Tom, > > One question to better understand your proposal: > In http://www.ietf.org/mail-archive/web/ancp/current/msg00955.html > you said: > "Given that that Command TLVs will be present only in a limited set > of message types, and "Cmnd Nmbr" is not one of the fields defined > within the Command TLV, I would also remove "Cmnd Nmbr" from Status- > Info. It can always be specified as part of the failureresponse to a > particular message type." > > I am not sure how to read that. > Are you saying that the Cmnd Nb would not appear in the Generic > Response message because if it is needed we woudl use a more > specific Response message? > For the case of a negative response to a Multicast Replication > Control message: are you proposing that the Generic Response message > be used (and then would it not have to contain the "Cmnd Nb") or are > you saying that we would then use a new "Multicast Replication > Control Response" which woudl contain the Cmnd Nb? > > Thanks > > francois > > > On 6 Oct 2009, at 17:15, Tom Taylor wrote: > >> I'm very happy to do that. Then we can discuss the result. >> >> Maglione Roberta wrote: >>> Hello Tom, >>> in my opinion instead of submitting a new individual draft >>> you should update the current mcast draft and propose your changes >>> as a new version of the draft: >>> draft-ietf-ancp-mc-extensions-01 >>> Meanwhile I can update the protocol draft with the additional >>> changes that you proposed. >>> Best Regards, >>> Roberta >>> -----Original Message----- >>> From: Tom Taylor [mailto:tom.taylor@rogers.com] >>> Sent: Tuesday, October 06, 2009 4:57 PM >>> To: Francois Le Faucheur IMAP; Maglione Roberta; Wojciech Dec >>> Subject: Changes to ANCP multicast >>> I made some major proposals regarding the ANCP protocol drafts at >>> the end of >>> August but have had no feedback. I'm wodering if the best way >>> forward, given all >>> I have in mind, is to submit a new draft-taylor-ancp-mc-extensions >>> incorporating >>> all my proposals, to serve as a basis for discussion that people >>> can relate to. >>> What are your views? >>> Tom >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >>> alle persone indicate. La diffusione, copia o qualsiasi altra >>> azione derivante dalla conoscenza di queste informazioni sono >>> rigorosamente vietate. Qualora abbiate ricevuto questo documento >>> per errore siete cortesemente pregati di darne immediata >>> comunicazione al mittente e di provvedere alla sua distruzione, >>> Grazie. >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>> Dissemination, copying, printing or use by anybody else is >>> unauthorised. If you are not the intended recipient, please delete >>> this message and any attachments and advise the sender by return e- >>> mail, Thanks. > From flefauch@cisco.com Fri Oct 9 05:31:24 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB52928C13F for ; Fri, 9 Oct 2009 05:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.052 X-Spam-Level: X-Spam-Status: No, score=-10.052 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gzF2cNS9kuh for ; Fri, 9 Oct 2009 05:31:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3C9BB28C13D for ; Fri, 9 Oct 2009 05:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=17518; q=dns/txt; s=amsiport01001; t=1255091587; x=1256301187; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Re:=20Changes=20to=20ANCP=20multicast|Date: =20Fri,=209=20Oct=202009=2014:32:56=20+0200|Message-Id: =20|To: =20Tom=20Taylor=20|Cc:=20Francois =20Le=20Faucheur=20,=0D=0A=20=20=20 =20=20=20=20=20Maglione=20Roberta=20,=0D=0A=20=20=20=20=20=20=20=20Dec=20Wojcie ch=20,=20ancp@ietf.org|Mime-Version:=201. 0=20(Apple=20Message=20framework=20v1076)|In-Reply-To:=20 |References:=20<4ACB5AA7.5070807@rogers.com>=20<282BBE8A5 01E1F4DA9C775F964BB21FE3E670E7FCF@GRFMBX704BA020.griffon. local>=20<4ACB5F01.9020709@rogers.com>=20=20<3C937557-C0B9-4C04-8C B9-36588A37CCBE@cisco.com>=20; bh=y2viiEPfPtdJMjnetwLu05fudfyVWau5sL8iTsBtU6A=; b=lwFdySrvIyzB7gVRelJL7KB9TQSm/diD9goP/JLN7goZK9xRPpYFf9Lf 4uPorRaABGup6GRDXsTKCAs3b+wwPwrhLssP+KENtIgpcQS47KaSajYWt RmZQ9Xt9B4nEVAkLd4UeFdPHt+RbxHoqQtynMBi/vMAK5z3F4kdIQkEkH k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,532,1249257600"; d="scan'208,217";a="51379122" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2009 12:32:58 +0000 Received: from [144.254.53.136] ([144.254.53.136]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n99CWvMq002914; Fri, 9 Oct 2009 12:32:57 GMT References: <4ACB5AA7.5070807@rogers.com> <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FCF@GRFMBX704BA020.griffon.local> <4ACB5F01.9020709@rogers.com> <3C937557-C0B9-4C04-8CB9-36588A37CCBE@cisco.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-10--241014110 Message-Id: From: Francois Le Faucheur Date: Fri, 9 Oct 2009 14:32:56 +0200 To: Tom Taylor X-Mailer: Apple Mail (2.1076) Cc: ancp@ietf.org Subject: Re: [ANCP] Changes to ANCP multicast X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 12:31:24 -0000 --Apple-Mail-10--241014110 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Tom, On 9 Oct 2009, at 13:53, Tom Taylor wrote: > Please see below. > > Francois Le Faucheur wrote: >> including the ANCP list as others may be interested. >> Francois >> On 8 Oct 2009, at 16:53, Francois Le Faucheur wrote: >>> Hi Tom, >>> >>> One question to better understand your proposal: >>> In http://www.ietf.org/mail-archive/web/ancp/current/msg00955.html >>> you said: >>> "Given that that Command TLVs will be present only in a limited >>> set of message types, and "Cmnd Nmbr" is not one of the fields >>> defined within the Command TLV, I would also remove "Cmnd Nmbr" >>> from Status-Info. It can always be specified as part of the >>> failureresponse to a particular message type." >>> >>> I am not sure how to read that. >>> Are you saying that the Cmnd Nb would not appear in the Generic >>> Response message because if it is needed we woudl use a more >>> specific Response message? > [PTT] > Yes, that's what I had in mind. > >>> For the case of a negative response to a Multicast Replication >>> Control message: are you proposing that the Generic Response >>> message be used (and then would it not have to contain the "Cmnd >>> Nb") or are you saying that we would then use a new "Multicast >>> Replication Control Response" which woudl contain the Cmnd Nb? > [PTT] > I would recommend a response specific to Multicast Replication > Control. This seems in contradiction with your Email of 27/08/2009 which says: * Change "Multicast Status" to "Generic Response". * "I assume the text should really read that the receiver MUST send a Generic Response message with the appropriate contents if unable to execute the complete Multicast Replication Control message successfully." So, I am a little confused, now. Currently, the Multicast Status message can be used in many scenarios including in responses to: * Multicast REplication Control request * Admission Control message * Bandwidth Reallocation * Delegated Bw Query Request * Multicast Flow Query Could you recap briefly what message you are proposing be used instead in each of these cases? I can see that it would make sense to have a Generic Response message to deal with a number of generic cases (such as when a message is not recognized, or invalid). Other than that, the MUlticast Status message was pretty much used as a multi-purpose response already (only, limited to all multicast use cases). Thanks Francois > However, my E-mail of 27/08/2009 suggested adding a new sub-TLV to > Status-Info. To quote from the earlier message: > > *** command error > -- Needs a new Code value, so add > > 85 Command error > > to base, and define in base a sub-TLV of Status-info to carry the > sequence number of the command within the message. This sub-TLV > could also carry an additional diagnostic code with its own IANA > registry if people think it might be useful. Extensions would define > the actual code values and add them to the registry. Likely > candidates are some of the errors listed in section 4.4: > > - Command not supported > > - Flag set but not supported > > - M Flag set, but no IP Source address provided > > - Unsupported Address Family > > - Unsupported address encoding > > - Malformed flow address > > - Multicast flow does not exist > > >>> >>> Thanks >>> >>> francois >>> >>> >>> On 6 Oct 2009, at 17:15, Tom Taylor wrote: >>> >>>> I'm very happy to do that. Then we can discuss the result. >>>> >>>> Maglione Roberta wrote: >>>>> Hello Tom, >>>>> in my opinion instead of submitting a new individual draft >>>>> you should update the current mcast draft and propose your >>>>> changes as a new version of the draft: >>>>> draft-ietf-ancp-mc-extensions-01 >>>>> Meanwhile I can update the protocol draft with the additional >>>>> changes that you proposed. >>>>> Best Regards, >>>>> Roberta >>>>> -----Original Message----- >>>>> From: Tom Taylor [mailto:tom.taylor@rogers.com] >>>>> Sent: Tuesday, October 06, 2009 4:57 PM >>>>> To: Francois Le Faucheur IMAP; Maglione Roberta; Wojciech Dec >>>>> Subject: Changes to ANCP multicast >>>>> I made some major proposals regarding the ANCP protocol drafts >>>>> at the end of >>>>> August but have had no feedback. I'm wodering if the best way >>>>> forward, given all >>>>> I have in mind, is to submit a new draft-taylor-ancp-mc- >>>>> extensions incorporating >>>>> all my proposals, to serve as a basis for discussion that people >>>>> can relate to. >>>>> What are your views? >>>>> Tom >>>>> Questo messaggio e i suoi allegati sono indirizzati >>>>> esclusivamente alle persone indicate. La diffusione, copia o >>>>> qualsiasi altra azione derivante dalla conoscenza di queste >>>>> informazioni sono rigorosamente vietate. Qualora abbiate >>>>> ricevuto questo documento per errore siete cortesemente pregati >>>>> di darne immediata comunicazione al mittente e di provvedere >>>>> alla sua distruzione, Grazie. >>>>> This e-mail and any attachments is confidential and may contain >>>>> privileged information intended for the addressee(s) only. >>>>> Dissemination, copying, printing or use by anybody else is >>>>> unauthorised. If you are not the intended recipient, please >>>>> delete this message and any attachments and advise the sender by >>>>> return e-mail, Thanks. >>> --Apple-Mail-10--241014110 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Please see below.

Francois Le Faucheur = wrote:
including the ANCP list as others = may be interested.
Francois
On 8 = Oct 2009, at 16:53, Francois Le Faucheur = wrote:
Hi Tom,

One question to better = understand your proposal:
In h= ttp://www.ietf.org/mail-archive/web/ancp/current/msg00955.html you = said:
"Given that that Command TLVs will be present only in a = limited set of message types, and "Cmnd Nmbr" is not one of the fields = defined within the Command TLV, I would also remove "Cmnd Nmbr" from = Status-Info. It can always be specified as part of the failureresponse = to a particular message type."

I am not sure how to read = that.
Are you saying that the Cmnd Nb would not appear in the = Generic Response message because if it is needed we woudl use a more = specific Response message?
[PTT]
Yes, = that's what I had in mind.

For the case of a negative response to a Multicast = Replication Control message: are you proposing that the Generic Response = message be used (and then would it not have to contain the "Cmnd Nb") or = are you saying that we would then use a new "Multicast Replication = Control Response" which woudl contain the Cmnd = Nb?
[PTT]
I would recommend a response = specific to Multicast Replication Control. =

This seems in contradiction with = your Email of 27/08/2009 which says:
* Change "Multicast Status" to "Generic = Response".
* "I assume the text should really read = that the receiver MUST send a Generic Response message = with the appropriate contents if unable to execute the = complete Multicast Replication Control message = successfully."

So, I am a little = confused, now.

Currently, the Multicast Status = message can be used in many scenarios including in responses = to:
= * Multicast REplication Control request
* = Admission Control message
* Bandwidth = Reallocation
  * Delegated Bw Query = Request
* Multicast Flow = Query 

Could you recap briefly what = message you are proposing be used instead in each of these = cases?

I can see that it would make sense to = have a Generic Response message to deal with a number of generic cases = (such as when a message is not recognized, or = invalid).

Other than that, the MUlticast Status = message was pretty much used as a multi-purpose response already (only, = limited to all multicast use = cases).

Thanks

Francois<= /div>

However, my E-mail of = 27/08/2009 suggested adding a new sub-TLV to Status-Info. To quote from = the earlier message:

*** command error
-- Needs a new Code = value, so add

85    Command error

to base, = and define in base a sub-TLV of Status-info to carry the sequence number = of the command within the message. This sub-TLV could also carry an = additional diagnostic code with its own IANA registry if people think it = might be useful. Extensions would define the actual code values and add = them to the registry. Likely candidates are some of the errors listed in = section 4.4:

- Command not supported

- Flag set but not = supported

- M Flag set, but no IP Source address = provided

- Unsupported Address Family

- Unsupported = address encoding

- Malformed flow address

- Multicast flow = does not exist



Thanks

francois


On 6 Oct 2009, at 17:15, Tom = Taylor wrote:

I'm = very happy to do that. Then we can discuss the = result.

Maglione= Roberta wrote:
Hello = Tom,
=      in my opinion instead of submitting a new = individual draft you should update the current mcast draft and propose = your changes as a new version of the = draft:
draft-ietf-ancp-mc-extensions-01
Meanwhile I can update the protocol draft with the = additional changes that you = proposed.
Best = Regards,
Roberta
-----Original = Message-----
From: Tom Taylor = [mailto:tom.taylor@rogers.com]
<= /blockquote>
Sent: = Tuesday, October 06, 2009 4:57 = PM
To: Francois Le Faucheur IMAP; = Maglione Roberta; Wojciech = Dec
Subject: Changes to ANCP = multicast
I made some major proposals = regarding the ANCP protocol drafts at the end = of
August but have had no feedback. = I'm wodering if the best way forward, given = all
I have in mind, is to submit a = new draft-taylor-ancp-mc-extensions = incorporating
all my proposals, to serve as a = basis for discussion that people can relate = to.
What are your = views?
Tom
<= blockquote type=3D"cite">
Questo messaggio e i suoi = allegati sono indirizzati esclusivamente alle persone indicate. La = diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di = queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto = questo documento per errore siete cortesemente pregati di darne = immediata comunicazione al mittente e di provvedere alla sua = distruzione, = Grazie.
This e-mail and any attachments = is confidential and may contain privileged information intended for the = addressee(s) only. Dissemination, copying, printing or use by anybody = else is unauthorised. If you are not the intended recipient, please = delete this message and any attachments and advise the sender by return = e-mail, = Thanks.


<= /div>= --Apple-Mail-10--241014110-- From tom111.taylor@bell.net Sun Oct 11 07:31:02 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5065E3A68D4 for ; Sun, 11 Oct 2009 07:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=0.001, MISSING_HEADERS=1.292, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuecyrTE5QMp for ; Sun, 11 Oct 2009 07:31:01 -0700 (PDT) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by core3.amsl.com (Postfix) with ESMTP id 577823A68B2 for ; Sun, 11 Oct 2009 07:31:01 -0700 (PDT) Received: from BLU0-SMTP54 ([65.55.111.72]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 07:32:51 -0700 X-Originating-IP: [76.64.153.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([76.64.153.89]) by BLU0-SMTP54.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 07:32:50 -0700 Date: Sun, 11 Oct 2009 10:32:47 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: ancp@ietf.org References: <4ACB5AA7.5070807@rogers.com> <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FCF@GRFMBX704BA020.griffon.local> <4ACB5F01.9020709@rogers.com> <3C937557-C0B9-4C04-8CB9-36588A37CCBE@cisco.com> In-Reply-To: <3C937557-C0B9-4C04-8CB9-36588A37CCBE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2009 14:32:50.0925 (UTC) FILETIME=[B60F79D0:01CA4A7F] Subject: Re: [ANCP] Changes to ANCP multicast X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 14:31:02 -0000 I am resending this to the list as a matter of record -- Francois has already replied to it. The original fell into a black hole because I changed my E-mail address. ---- Please see below. Francois Le Faucheur wrote: > including the ANCP list as others may be interested. > Francois > > On 8 Oct 2009, at 16:53, Francois Le Faucheur wrote: > >> Hi Tom, >> >> One question to better understand your proposal: >> In http://www.ietf.org/mail-archive/web/ancp/current/msg00955.html you >> said: >> "Given that that Command TLVs will be present only in a limited set of >> message types, and "Cmnd Nmbr" is not one of the fields defined within >> the Command TLV, I would also remove "Cmnd Nmbr" from Status-Info. It >> can always be specified as part of the failureresponse to a particular >> message type." >> >> I am not sure how to read that. >> Are you saying that the Cmnd Nb would not appear in the Generic >> Response message because if it is needed we woudl use a more specific >> Response message? [PTT] Yes, that's what I had in mind. >> For the case of a negative response to a Multicast Replication Control >> message: are you proposing that the Generic Response message be used >> (and then would it not have to contain the "Cmnd Nb") or are you >> saying that we would then use a new "Multicast Replication Control >> Response" which woudl contain the Cmnd Nb? [PTT] I would recommend a response specific to Multicast Replication Control. However, my E-mail of 27/08/2009 suggested adding a new sub-TLV to Status-Info. To quote from the earlier message: *** command error -- Needs a new Code value, so add 85 Command error to base, and define in base a sub-TLV of Status-info to carry the sequence number of the command within the message. This sub-TLV could also carry an additional diagnostic code with its own IANA registry if people think it might be useful. Extensions would define the actual code values and add them to the registry. Likely candidates are some of the errors listed in section 4.4: - Command not supported - Flag set but not supported - M Flag set, but no IP Source address provided - Unsupported Address Family - Unsupported address encoding - Malformed flow address - Multicast flow does not exist >> >> Thanks >> >> francois >> >> >> On 6 Oct 2009, at 17:15, Tom Taylor wrote: >> >>> I'm very happy to do that. Then we can discuss the result. >>> >>> Maglione Roberta wrote: >>>> Hello Tom, >>>> in my opinion instead of submitting a new individual draft you >>>> should update the current mcast draft and propose your changes as a >>>> new version of the draft: >>>> draft-ietf-ancp-mc-extensions-01 >>>> Meanwhile I can update the protocol draft with the additional >>>> changes that you proposed. >>>> Best Regards, >>>> Roberta >>>> -----Original Message----- >>>> From: Tom Taylor [mailto:tom.taylor@rogers.com] >>>> Sent: Tuesday, October 06, 2009 4:57 PM >>>> To: Francois Le Faucheur IMAP; Maglione Roberta; Wojciech Dec >>>> Subject: Changes to ANCP multicast >>>> I made some major proposals regarding the ANCP protocol drafts at >>>> the end of >>>> August but have had no feedback. I'm wodering if the best way >>>> forward, given all >>>> I have in mind, is to submit a new draft-taylor-ancp-mc-extensions >>>> incorporating >>>> all my proposals, to serve as a basis for discussion that people can >>>> relate to. >>>> What are your views? >>>> Tom >>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >>>> alle persone indicate. La diffusione, copia o qualsiasi altra azione >>>> derivante dalla conoscenza di queste informazioni sono rigorosamente >>>> vietate. Qualora abbiate ricevuto questo documento per errore siete >>>> cortesemente pregati di darne immediata comunicazione al mittente e >>>> di provvedere alla sua distruzione, Grazie. >>>> This e-mail and any attachments is confidential and may contain >>>> privileged information intended for the addressee(s) only. >>>> Dissemination, copying, printing or use by anybody else is >>>> unauthorised. If you are not the intended recipient, please delete >>>> this message and any attachments and advise the sender by return >>>> e-mail, Thanks. >> > > From tom111.taylor@bell.net Sun Oct 11 07:31:59 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5653A6856 for ; Sun, 11 Oct 2009 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.262 X-Spam-Level: * X-Spam-Status: No, score=1.262 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_20=-0.74, MISSING_HEADERS=1.292, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWGFgOr7EOVG for ; Sun, 11 Oct 2009 07:31:58 -0700 (PDT) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by core3.amsl.com (Postfix) with ESMTP id 725013A6822 for ; Sun, 11 Oct 2009 07:31:58 -0700 (PDT) Received: from BLU0-SMTP36 ([65.55.111.72]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 07:33:47 -0700 X-Originating-IP: [76.64.153.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([76.64.153.89]) by BLU0-SMTP36.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 07:33:47 -0700 Date: Sun, 11 Oct 2009 10:33:44 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: ancp@ietf.org References: <4ACB5AA7.5070807@rogers.com> <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FCF@GRFMBX704BA020.griffon.local> <4ACB5F01.9020709@rogers.com> <3C937557-C0B9-4C04-8CB9-36588A37CCBE@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2009 14:33:47.0533 (UTC) FILETIME=[D7CD2BD0:01CA4A7F] Subject: Re: [ANCP] Changes to ANCP multicast X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tom111.taylor@bell.net List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 14:31:59 -0000 Here is another message that got lost. -------- I am looking for some principles here, so I've been dithering a bit myself over the appropriate use of the Generic Response message. It seems fairly evident to me that Generic Response should be used to convey error status that is common to multiple message types, justifying the definition of the error cases in base rather than another document. And I believe strongly that if there is information that should be sent in a response in answer to a particular message type, and that information is specific to that message type, then the response message should be of the same type as the original request. The questions in my mind begin when you have the latter case, but you have a generic type of error to report. Do you report the error in a Generic Response, or in the defined response message using a Status TLV embedded in that response message? I think you do, to simplify the message-processing state machine. And that means some changes in some of the work we have done already. Particularly, my colleague Fortune Huang (18/08/2009) pointed out the complexity of handling Delegated Bandwidth Query. Francois Le Faucheur wrote: > Tom, > > On 9 Oct 2009, at 13:53, Tom Taylor wrote: > >> Please see below. >> >> Francois Le Faucheur wrote: >>> including the ANCP list as others may be interested. >>> Francois >>> On 8 Oct 2009, at 16:53, Francois Le Faucheur wrote: >>>> Hi Tom, >>>> >>>> One question to better understand your proposal: >>>> In http://www.ietf.org/mail-archive/web/ancp/current/msg00955.html >>>> you said: >>>> "Given that that Command TLVs will be present only in a limited set >>>> of message types, and "Cmnd Nmbr" is not one of the fields defined >>>> within the Command TLV, I would also remove "Cmnd Nmbr" from >>>> Status-Info. It can always be specified as part of the >>>> failureresponse to a particular message type." >>>> >>>> I am not sure how to read that. >>>> Are you saying that the Cmnd Nb would not appear in the Generic >>>> Response message because if it is needed we woudl use a more >>>> specific Response message? >> [PTT] >> Yes, that's what I had in mind. >> >>>> For the case of a negative response to a Multicast Replication >>>> Control message: are you proposing that the Generic Response message >>>> be used (and then would it not have to contain the "Cmnd Nb") or are >>>> you saying that we would then use a new "Multicast Replication >>>> Control Response" which woudl contain the Cmnd Nb? >> [PTT] >> I would recommend a response specific to Multicast Replication Control. > > This seems in contradiction with your Email of 27/08/2009 which says: > * Change "Multicast Status" to "Generic Response". > * "I assume the text should really read that the receiver MUST send a > Generic Response message with the appropriate contents if unable to > execute the complete Multicast Replication Control message successfully." > > So, I am a little confused, now. > > Currently, the Multicast Status message can be used in many scenarios > including in responses to: > * Multicast REplication Control request > * Admission Control message > * Bandwidth Reallocation > * Delegated Bw Query Request > * Multicast Flow Query > > Could you recap briefly what message you are proposing be used instead > in each of these cases? > > I can see that it would make sense to have a Generic Response message to > deal with a number of generic cases (such as when a message is not > recognized, or invalid). > > Other than that, the MUlticast Status message was pretty much used as a > multi-purpose response already (only, limited to all multicast use cases). > > Thanks > > Francois > >> However, my E-mail of 27/08/2009 suggested adding a new sub-TLV to >> Status-Info. To quote from the earlier message: >> >> *** command error >> -- Needs a new Code value, so add >> >> 85 Command error >> >> to base, and define in base a sub-TLV of Status-info to carry the >> sequence number of the command within the message. This sub-TLV could >> also carry an additional diagnostic code with its own IANA registry if >> people think it might be useful. Extensions would define the actual >> code values and add them to the registry. Likely candidates are some >> of the errors listed in section 4.4: >> >> - Command not supported >> >> - Flag set but not supported >> >> - M Flag set, but no IP Source address provided >> >> - Unsupported Address Family >> >> - Unsupported address encoding >> >> - Malformed flow address >> >> - Multicast flow does not exist >> >> >>>> >>>> Thanks >>>> >>>> francois >>>> >>>> >>>> On 6 Oct 2009, at 17:15, Tom Taylor wrote: >>>> >>>>> I'm very happy to do that. Then we can discuss the result. >>>>> >>>>> Maglione Roberta wrote: >>>>>> Hello Tom, >>>>>> in my opinion instead of submitting a new individual draft >>>>>> you should update the current mcast draft and propose your changes >>>>>> as a new version of the draft: >>>>>> draft-ietf-ancp-mc-extensions-01 >>>>>> Meanwhile I can update the protocol draft with the additional >>>>>> changes that you proposed. >>>>>> Best Regards, >>>>>> Roberta >>>>>> -----Original Message----- >>>>>> From: Tom Taylor [mailto:tom.taylor@rogers.com] >>>>>> Sent: Tuesday, October 06, 2009 4:57 PM >>>>>> To: Francois Le Faucheur IMAP; Maglione Roberta; Wojciech Dec >>>>>> Subject: Changes to ANCP multicast >>>>>> I made some major proposals regarding the ANCP protocol drafts at >>>>>> the end of >>>>>> August but have had no feedback. I'm wodering if the best way >>>>>> forward, given all >>>>>> I have in mind, is to submit a new draft-taylor-ancp-mc-extensions >>>>>> incorporating >>>>>> all my proposals, to serve as a basis for discussion that people >>>>>> can relate to. >>>>>> What are your views? >>>>>> Tom >>>>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >>>>>> alle persone indicate. La diffusione, copia o qualsiasi altra >>>>>> azione derivante dalla conoscenza di queste informazioni sono >>>>>> rigorosamente vietate. Qualora abbiate ricevuto questo documento >>>>>> per errore siete cortesemente pregati di darne immediata >>>>>> comunicazione al mittente e di provvedere alla sua distruzione, >>>>>> Grazie. >>>>>> This e-mail and any attachments is confidential and may contain >>>>>> privileged information intended for the addressee(s) only. >>>>>> Dissemination, copying, printing or use by anybody else is >>>>>> unauthorised. If you are not the intended recipient, please delete >>>>>> this message and any attachments and advise the sender by return >>>>>> e-mail, Thanks. >>>> > > From tom111.taylor@bell.net Sun Oct 11 09:42:11 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54513A6945 for ; Sun, 11 Oct 2009 09:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knPqXo23RWBu for ; Sun, 11 Oct 2009 09:42:11 -0700 (PDT) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by core3.amsl.com (Postfix) with ESMTP id DDA943A6904 for ; Sun, 11 Oct 2009 09:42:07 -0700 (PDT) Received: from BLU0-SMTP60 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 09:42:07 -0700 X-Originating-IP: [76.64.153.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([76.64.153.89]) by BLU0-SMTP60.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 09:42:07 -0700 Date: Sun, 11 Oct 2009 12:42:04 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2009 16:42:07.0639 (UTC) FILETIME=[C56C1A70:01CA4A91] Subject: [ANCP] Mixing and matching of multicast modes of operation (capabilities) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 16:42:11 -0000 I am currently creating a version of the multicast extensions document implementing the capabilities I described in my August E-mails. Just to review, I saw four multicast capabilities: - NAS-controlled multicast replication; - conditional access with white and black lists; - conditional access with grey lists; - flexible bandwidth sharing, AKA bandwidth delegation. I would like comments on the following statements: 1) If a particular capability is negotiated, it applies to all ports. Thus, for example, if NAS-controlled multicast replication is negotiated between the NAS and AN, it will be used on all of the AN's ports. 2) As a consequence of 1), I believe NAS-controlled multicast is incompatible with (mutually exclusive to) the other multicast capabilities on a specific adjacency. 3) The other three capabilities can operate by themselves or in any combination. They have in common that: -- Join/leave requests are terminated by the AN. -- The AN performs admission control. Where they are operating on their own, these capabilities are defined as follows: Conditional access in general: It is assumed that the AN is configured with per-subscriber bandwidth limits and the bandwidth required for a given multicast channel, by means out of scope of ANCP. Conditional access with white and black lists: --------------------------------------------- The AN accepts white-listed join requests without consulting the NAS, and ignores all other join requests. Conditional access with grey lists: ---------------------------------- For grey-listed join requests only, the AN performs admission control but then requests permission from the NAS before initiating replication. The AN ignores all other join requests. Flexible bandwidth sharing AKA bandwidth delegation: --------------------------------------------------- The AN performs admission control and accepts the request if sufficient multicast bandwidth is available. That is, the AN acts as if every multicast channel is white-listed. Admission control is against a total multicast bandwidth limit negotiated with the NAS, but it is assumed that the AN is configured with the bandwidth required for a given multicast channel by means out of scope of ANCP. When the capabilities are combined, the behaviour is as follows: Conditional access with white and black lists combined with conditional access with grey lists: ------------------------------------------------------------- The rules specified in the framework document for finding best match are applied. If the match is to a white list entry, the AN accepts the request (subject to admission control) without consulting the NAS. If the match is to a grey list entry, the AN performs admission control but then requests permission from the NAS before initiating replication. All other join requests are ignored. Flexible bandwidth sharing AKA bandwidth delegation with any combination of conditional access capabilities: ------------------------------------------------------------- AN behaviour is the same as defined by the conditional access capabilities within the combination, with the additional behaviour of multicast bandwidth negotiation with the NAS. 4) If a capability is negotiated, it is activated. You don't need an explicit activation as we currently have with bandwidth delegation. Tom Taylor From tom111.taylor@bell.net Sun Oct 11 09:59:14 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE753A682C for ; Sun, 11 Oct 2009 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxy521qIKt2n for ; Sun, 11 Oct 2009 09:59:14 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by core3.amsl.com (Postfix) with ESMTP id 0B48B3A6814 for ; Sun, 11 Oct 2009 09:59:13 -0700 (PDT) Received: from BLU0-SMTP56 ([65.55.111.72]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 09:59:13 -0700 X-Originating-IP: [76.64.153.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([76.64.153.89]) by BLU0-SMTP56.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Oct 2009 09:59:13 -0700 Date: Sun, 11 Oct 2009 12:59:10 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2009 16:59:13.0926 (UTC) FILETIME=[29231260:01CA4A94] Subject: [ANCP] Support of multicast information reporting and accounting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 16:59:14 -0000 The requirements listed below come from the framework document. I assume that these requirements are common to all of the capabilities I described in my previous message. Or would someone suggest that they should be separately-negotiated capabilities? R-17 The ANCP MUST allow the AN to send an Information Report message to the NAS whenever replication of a multicast flow on a particular Access Port start or ends. R-18 The ANCP MUST allow the AN to send an Information Report message to the NAS indicating the multicast traffic volume that has been replicated on that port. R-19 The ANCP MUST allow the NAS to indicate to the AN whether or not multicast accounting is needed for a multicast flow on a particular Access Port. R-20 In case multicast accounting is needed for a multicast flow on a particular Access Port, the ANCP MUST allow the NAS to indicate to the AN whether or not additional volume accounting information is required. R-23 The ANCP MUST allow the NAS to query the AN to obtain information on what multicast flows are currently being replicated on a given Access Port, what Access Ports are currently receiving a given multicast flow, or what multicast flows are currently replicated on each Access Port. Tom Taylor From wdec@cisco.com Mon Oct 12 00:57:50 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B96B28C14D for ; Mon, 12 Oct 2009 00:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYTKuKt6WwOi for ; Mon, 12 Oct 2009 00:57:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0460828C14B for ; Mon, 12 Oct 2009 00:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=156; q=dns/txt; s=amsiport01001; t=1255334269; x=1256543869; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20Agenda=20items=20for=20IETF76=20ANCP=20WG=20m eeting=20|Date:=20Mon,=2012=20Oct=202009=2009:57:42=20+02 00|Message-ID:=20|To:=20|Cc:=20"BOCCI =20Matthew"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable; bh=nwmPpY8kQ91mPyJFDt3luyI3zUH0bhgCOw9eZK/8uuY=; b=WuSoLOl4oCluZwTqqsWDhFCAy0WM3WU6Ip/lq/ko3+gSaejZ5SUs/+0H LS/8uQD4dq4M7DuZu7/f2huWQg2BqmuZhSU0lIMxDKkPt2CxJ4pzlhkL/ ug9V2oN8ltolPlKv2EsWUU/uwBzgFgrnB4UNrF8VzFtvc034Vkkj/awvj M=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAALN90kqQ/uCWe2dsb2JhbACbCwEBFiQGo3eWUYQtBIFY X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208";a="51507447" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 07:57:47 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9C7vk5m028539; Mon, 12 Oct 2009 07:57:46 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 09:57:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 09:57:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda items for IETF76 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNg From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 12 Oct 2009 07:57:45.0992 (UTC) FILETIME=[AF3B8080:01CA4B11] Subject: [ANCP] Agenda items for IETF76 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 07:57:50 -0000 Hi All, We're taking requests for agenda slots at our next ANCP WG meeting in Hiroshima. Please respond with any requests. Thanks, Matthew & Woj From roberta.maglione@telecomitalia.it Mon Oct 12 01:36:59 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF823A695F for ; Mon, 12 Oct 2009 01:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S46EPme0VRgA for ; Mon, 12 Oct 2009 01:36:58 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 331D33A684A for ; Mon, 12 Oct 2009 01:36:55 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 12 Oct 2009 10:36:51 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Mon, 12 Oct 2009 10:36:51 +0200 From: Maglione Roberta To: Tom Taylor , "HaagT@telekom.de" Date: Mon, 12 Oct 2009 10:36:51 +0200 Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AconS5+Izw5J0N8kTf6f1ngIC50efgjyfy3g Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FD7@GRFMBX704BA020.griffon.local> References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com><040201ca1987$008a6670$5728460a@china.huawei.com><1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de><35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> <5661758E3E93364685B91DD8272F287601B8E2D3@S4DE8PSAAQC.mitte.t-com.de> <4A96DCB7.7060303@rogers.com> In-Reply-To: <4A96DCB7.7060303@rogers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "B.Witschurke@telekom.de" , "ancp@ietf.org" , "peter.arberg@ericsson.com" , "Robert.Rennison@ecitele.com" , "Peter.Hamacher@telekom.de" Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 08:36:59 -0000 Hello Thomas and All, >> [T.H.:] Note: Implementations which use GSMP and ANCP conventions before >> RFC >> publication must use sub-version 1. > [PTT] By definition, pre-standard versions do not conform to the standard= , so > this text will have no effect. Regarding this point I agree with Tom Taylor, pre-standard versions have no= effect for the standard, thus in my opinion we should not add text that re= fers to pre-standard version in the current protocol draft. In addition according to the meeting minutes, during last meeting the worki= ng group decided to change the version number to 3.2, but only upon publica= tion of the RFC. My understanding from the meeting and from the MM was that this will be don= e by adding an RFC Editor's note to change version from 3.1 to 3.2 upon pub= lication. Best Regards, Roberta -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Tom= Taylor Sent: Thursday, August 27, 2009 9:21 PM To: HaagT@telekom.de Cc: B.Witschurke@telekom.de; ancp@ietf.org; peter.arberg@ericsson.com; Robe= rt.Rennison@ecitele.com; Peter.Hamacher@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning Comments below, marked with [PTT]. HaagT@telekom.de wrote: > All, > > All exchanged arguments are valid. > > I think a protocol draft describes protocol issues, values, TLV, etc. and= not > network element mechanisms. The challenge now would be to cover notes > pointing out how to code pre version and RFC version - that was agreed la= st > meeting. > > But what's missing in that game is a short description that both peers (B= RAS > & AN) need to identify which SW version to choose based on sub version va= lue. > A mechnism in detail for detection and automatic SW load depending on su= b > version is neccessary. > > I'm not sure if that is in scope of a protocol draft or if it should be > described seperately. But keeping the time line of protocol draft and > avoiding delaying ANCP work it may be desirable to identify sections in > protocol draft where notes are useful to detail that issue without changi= ng > sections and order of the document. > >> From my understanding three sections are concerned. I propose adding the >> notes at that sections. > > Please see below the identified sections and added notes taken based on > protocol draft 05 for discussion: > > Regards Thomas > -------------------------------------------------------------------------= -------- > > > Chapter 2 Introduction / page 4: > > ... > > Not all the fields in relevant GSMP messages are used by ANCP. This draf= t > indicates the value that ANCP should set for the fields in these GSMP > messages. > > > > [T.H.:] Note: Implementations which use GSMP and ANCP conventions before = RFC > publication must use sub-version 1. [PTT] By definition, pre-standard versions do not conform to the standard, = so this text will have no effect. > > RFC based implementations must use sub-version 2. For details see chapter= 5. > > ... > > -------------------------------------------------------------------------= ----------- > > > Chapter 5. Access Node Control Protocol (ANCP) / page 15 > > ... > > The 8-bit version field in the base GSMPv3 message header is split > into two 4 bit fields for carrying the version and a sub-version of > the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP > protocol. An ANCP implementation SHOULD always set the version field > to 3, and the sub-version field to 1. The Result field in the > message header has been modified to be 4 bits long, and the Code > field to be 12 bits long. > > Version: > > The version number of the GSMP protocol being used in this > session. ANCP uses version 3. > > Sub-Version: > > The sub-version number of the GSMP protocol being used in this > session. ANCP must use sub-version 2 of the GSMP protocol. [T.H]:Pre RFC > implemtations must use sub-version 1. > [PTT] Same comment as above. > > --------------------------------------------------------------------- > > Chapter 5.1. ANCP/TCP connection establishment / Page 19: > > ... > > NAS listens for incoming connections from the access nodes. Port 6068 is > used for TCP connection. Adjacency protocol messages, which are used to > synchronize the NAS and access-nodes and maintain handshakes, are sent af= ter > the TCP connection is established. ANCP messages other than adjacency > protocol messages may be sent only after the adjacency protocol has achie= ved > synchronization. > > [T.H.]:Note: NAS must detect per peer the sub version and must load and > synchronize with appropriate protocol implementation. > [PTT] I would add "if possible". > ... _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From flefauch@cisco.com Mon Oct 12 02:44:54 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853DB28C161 for ; Mon, 12 Oct 2009 02:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7VVxNI0mlHD for ; Mon, 12 Oct 2009 02:44:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2D7E528C158 for ; Mon, 12 Oct 2009 02:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=483; q=dns/txt; s=amsiport01001; t=1255340688; x=1256550288; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Re:=20[ANCP]=20Agenda=20items=20for=20IETF76 =20ANCP=20WG=20meeting|Date:=20Mon,=2012=20Oct=202009=201 1:44:45=20+0200|Message-Id:=20|To:=20Wojciech=20Dec=20(wdec)=20|Cc:=20Le=20Faucheur=20Francois=20,=20ancp@ietf.org|Mime-Version:=201.0=20(Apple =20Message=20framework=20v1076) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20; bh=PJmUe+CdpVCixLhFHKt4e38s0zy/IYwlkxfFxAo7Q6w=; b=q+XPeOGO+193XDVSKnsdA8uG89OprLXYWy2eFgg2u94drb3Iv/9trJ+j p4LOjrQvznYZYMauEappYq3WiBsZ21hvB8OmfmLy90TvSTnT734DSQpxR 5y28AvcD/vfduQX1tbWhi2np5nu3RF9/r/O5RfeQfvkaDxuyCa3ATI+hz w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208";a="51521415" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 09:44:46 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9C9ij1k006767; Mon, 12 Oct 2009 09:44:46 GMT References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Mon, 12 Oct 2009 11:44:45 +0200 To: Wojciech Dec (wdec) X-Mailer: Apple Mail (2.1076) Cc: ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 09:44:58 -0000 Woj, We'll have a new version of ancp-mc-extensions that we'd like discussed. Presenter(s) is TBD. Francois On 12 Oct 2009, at 09:57, Wojciech Dec (wdec) wrote: > Hi All, > > > We're taking requests for agenda slots at our next ANCP WG meeting in > Hiroshima. Please respond with any requests. > > Thanks, > Matthew & Woj > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From lihy@huawei.com Mon Oct 12 02:45:08 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5BC28C163 for ; Mon, 12 Oct 2009 02:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC0agipWZpSd for ; Mon, 12 Oct 2009 02:45:07 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 131A628C162 for ; Mon, 12 Oct 2009 02:45:07 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRE00C3ZB2UOL@szxga02-in.huawei.com> for ancp@ietf.org; Mon, 12 Oct 2009 17:44:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRE00E6AB2U6Q@szxga02-in.huawei.com> for ancp@ietf.org; Mon, 12 Oct 2009 17:44:54 +0800 (CST) Received: from L26465 ([10.70.40.87]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRE00819B2TTL@szxml04-in.huawei.com> for ancp@ietf.org; Mon, 12 Oct 2009 17:44:54 +0800 (CST) Date: Mon, 12 Oct 2009 17:44:50 +0800 From: Hongyu Li In-reply-to: To: "'Wojciech Dec (wdec)'" , ancp@ietf.org Message-id: <030101ca4b20$a6ca1a60$5728460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNgAANxziA= Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 09:45:08 -0000 Hi Woj, I need 10 minutes for an informational slides stating gap between TR-147 and current work in ANCP. Thanks. Best regards, Hongyu Li > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On > Behalf Of Wojciech Dec (wdec) > Sent: Monday, October 12, 2009 3:58 PM > To: ancp@ietf.org > Subject: [ANCP] Agenda items for IETF76 ANCP WG meeting > > Hi All, > > > We're taking requests for agenda slots at our next ANCP WG > meeting in Hiroshima. Please respond with any requests. > > Thanks, > Matthew & Woj > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > From flefauch@cisco.com Mon Oct 12 05:28:28 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36323A67AA for ; Mon, 12 Oct 2009 05:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52+FIJqdR00R for ; Mon, 12 Oct 2009 05:28:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B7FE63A69BC for ; Mon, 12 Oct 2009 05:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=29175; q=dns/txt; s=amsiport01001; t=1255350506; x=1256560106; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Re:=20[ANCP]=20Changes=20to=20ANCP=20multicas t|Date:=20Mon,=2012=20Oct=202009=2014:28:18=20+0200 |Message-Id:=20<3814A669-D74B-4BB7-BD72-C819FC8BA392@cisc o.com>|To:=20tom111.taylor@bell.net|Cc:=20Francois=20Le =20Faucheur=20,=20ancp@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v10 76)|In-Reply-To:=20|References:=20<4ACB5AA7.5070807@rogers.com>=20<2 82BBE8A501E1F4DA9C775F964BB21FE3E670E7FCF@GRFMBX704BA020. griffon.local>=20<4ACB5F01.9020709@rogers.com>=20=20<3C937557-C0B9 -4C04-8CB9-36588A37CCBE@cisco.com>=20=20=20; bh=qMmnjQcZMhbxfVCDdnu6hbjZ0yg3HmOHRnB0Y+zBnFE=; b=emQwMzAH0iOSIDYNdWRroojYRE2mv5nNEg3dQ0thjJ0Ne5zJAQLaRBf0 uWXdzHP7G7h8b3dm7+CemFyx+qOCuVM3bmx+gU2phi9KbYnqsSNHXYedH +Z/hHju/XGgApaLUkWNB6oFMbQL0j3jmLvJk07ves+OZ/H8JD/DV9vN3s Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,545,1249257600"; d="scan'208,217";a="51541645" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 12:28:24 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CCSMIg002876; Mon, 12 Oct 2009 12:28:22 GMT References: <4ACB5AA7.5070807@rogers.com> <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FCF@GRFMBX704BA020.griffon.local> <4ACB5F01.9020709@rogers.com> <3C937557-C0B9-4C04-8CB9-36588A37CCBE@cisco.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-20-17908541 Message-Id: <3814A669-D74B-4BB7-BD72-C819FC8BA392@cisco.com> From: Francois Le Faucheur Date: Mon, 12 Oct 2009 14:28:18 +0200 To: tom111.taylor@bell.net X-Mailer: Apple Mail (2.1076) Cc: ancp@ietf.org Subject: Re: [ANCP] Changes to ANCP multicast X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:28:28 -0000 --Apple-Mail-20-17908541 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi Tom, On 11 Oct 2009, at 16:33, Tom Taylor wrote: > > I am looking for some principles here, so I've been dithering a bit > myself over > the appropriate use of the Generic Response message. I see. > It seems fairly evident to > me that Generic Response should be used to convey error status that > is common to > multiple message types, justifying the definition of the error cases > in base > rather than another document. The simple case is for "unrecognized/invalid message" where we need a generic message. > And I believe strongly that if there is > information that should be sent in a response in answer to a > particular message > type, and that information is specific to that message type, then > the response > message should be of the same type as the original request. > > The questions in my mind begin when you have the latter case, but > you have a > generic type of error to report. Agreed. > Do you report the error in a Generic Response, > or in the defined response message using a Status TLV embedded in > that response > message? I think you do, to simplify the message-processing state > machine. And > that means some changes in some of the work we have done already. > Particularly, > my colleague Fortune Huang (18/08/2009) pointed out the complexity > of handling > Delegated Bandwidth Query That's probably a good case to look at. There are some errors that are fairly specific to the Delegated Bandwidth Query (for example"Bandwidth Delegation not activated"). I understand you're saying you'd like to see those conveyed inside the "Delegated Bandwidth Query Response". There are also some errors that are independent of the actual query type (for example "invalid Target"). I understand you're suggesting those also get conveyed via a type-specific response. One even more interesting case is when we don't have a response defined already (eg for Multicast Replication Control message). Then should we create a new type-specific response (eg Multicast Replication Control response) or should we use the generic response (to avoid creating new message types)? Francois > . > > > Francois Le Faucheur wrote: >> Tom, >> On 9 Oct 2009, at 13:53, Tom Taylor wrote: >>> Please see below. >>> >>> Francois Le Faucheur wrote: >>>> including the ANCP list as others may be interested. >>>> Francois >>>> On 8 Oct 2009, at 16:53, Francois Le Faucheur wrote: >>>>> Hi Tom, >>>>> >>>>> One question to better understand your proposal: >>>>> In http://www.ietf.org/mail-archive/web/ancp/current/ >>>>> msg00955.html you said: >>>>> "Given that that Command TLVs will be present only in a limited >>>>> set of message types, and "Cmnd Nmbr" is not one of the fields >>>>> defined within the Command TLV, I would also remove "Cmnd Nmbr" >>>>> from Status-Info. It can always be specified as part of the >>>>> failureresponse to a particular message type." >>>>> >>>>> I am not sure how to read that. >>>>> Are you saying that the Cmnd Nb would not appear in the Generic >>>>> Response message because if it is needed we woudl use a more >>>>> specific Response message? >>> [PTT] >>> Yes, that's what I had in mind. >>> >>>>> For the case of a negative response to a Multicast Replication >>>>> Control message: are you proposing that the Generic Response >>>>> message be used (and then would it not have to contain the "Cmnd >>>>> Nb") or are you saying that we would then use a new "Multicast >>>>> Replication Control Response" which woudl contain the Cmnd Nb? >>> [PTT] >>> I would recommend a response specific to Multicast Replication >>> Control. >> This seems in contradiction with your Email of 27/08/2009 which says: >> * Change "Multicast Status" to "Generic Response". >> * "I assume the text should really read that the receiver MUST send >> a Generic Response message with the appropriate contents if unable >> to execute the complete Multicast Replication Control message >> successfully." >> So, I am a little confused, now. >> Currently, the Multicast Status message can be used in many >> scenarios including in responses to: >> * Multicast REplication Control request >> * Admission Control message >> * Bandwidth Reallocation >> * Delegated Bw Query Request >> * Multicast Flow Query >> Could you recap briefly what message you are proposing be used >> instead in each of these cases? >> I can see that it would make sense to have a Generic Response >> message to deal with a number of generic cases (such as when a >> message is not recognized, or invalid). >> Other than that, the MUlticast Status message was pretty much used >> as a multi-purpose response already (only, limited to all multicast >> use cases). >> Thanks >> Francois >>> However, my E-mail of 27/08/2009 suggested adding a new sub-TLV to >>> Status-Info. To quote from the earlier message: >>> >>> *** command error >>> -- Needs a new Code value, so add >>> >>> 85 Command error >>> >>> to base, and define in base a sub-TLV of Status-info to carry the >>> sequence number of the command within the message. This sub-TLV >>> could also carry an additional diagnostic code with its own IANA >>> registry if people think it might be useful. Extensions would >>> define the actual code values and add them to the registry. Likely >>> candidates are some of the errors listed in section 4.4: >>> >>> - Command not supported >>> >>> - Flag set but not supported >>> >>> - M Flag set, but no IP Source address provided >>> >>> - Unsupported Address Family >>> >>> - Unsupported address encoding >>> >>> - Malformed flow address >>> >>> - Multicast flow does not exist >>> >>> >>>>> >>>>> Thanks >>>>> >>>>> francois >>>>> >>>>> >>>>> On 6 Oct 2009, at 17:15, Tom Taylor wrote: >>>>> >>>>>> I'm very happy to do that. Then we can discuss the result. >>>>>> >>>>>> Maglione Roberta wrote: >>>>>>> Hello Tom, >>>>>>> in my opinion instead of submitting a new individual draft >>>>>>> you should update the current mcast draft and propose your >>>>>>> changes as a new version of the draft: >>>>>>> draft-ietf-ancp-mc-extensions-01 >>>>>>> Meanwhile I can update the protocol draft with the additional >>>>>>> changes that you proposed. >>>>>>> Best Regards, >>>>>>> Roberta >>>>>>> -----Original Message----- >>>>>>> From: Tom Taylor [mailto:tom.taylor@rogers.com] >>>>>>> Sent: Tuesday, October 06, 2009 4:57 PM >>>>>>> To: Francois Le Faucheur IMAP; Maglione Roberta; Wojciech Dec >>>>>>> Subject: Changes to ANCP multicast >>>>>>> I made some major proposals regarding the ANCP protocol drafts >>>>>>> at the end of >>>>>>> August but have had no feedback. I'm wodering if the best way >>>>>>> forward, given all >>>>>>> I have in mind, is to submit a new draft-taylor-ancp-mc- >>>>>>> extensions incorporating >>>>>>> all my proposals, to serve as a basis for discussion that >>>>>>> people can relate to. >>>>>>> What are your views? >>>>>>> Tom >>>>>>> Questo messaggio e i suoi allegati sono indirizzati >>>>>>> esclusivamente alle persone indicate. La diffusione, copia o >>>>>>> qualsiasi altra azione derivante dalla conoscenza di queste >>>>>>> informazioni sono rigorosamente vietate. Qualora abbiate >>>>>>> ricevuto questo documento per errore siete cortesemente >>>>>>> pregati di darne immediata comunicazione al mittente e di >>>>>>> provvedere alla sua distruzione, Grazie. >>>>>>> This e-mail and any attachments is confidential and may >>>>>>> contain privileged information intended for the addressee(s) >>>>>>> only. Dissemination, copying, printing or use by anybody else >>>>>>> is unauthorised. If you are not the intended recipient, please >>>>>>> delete this message and any attachments and advise the sender >>>>>>> by return e-mail, Thanks. >>>>> > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp --Apple-Mail-20-17908541 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Tom,

On 11 Oct 2009, at 16:33, Tom Taylor = wrote:

I am looking for = some principles here, so I've been dithering a bit myself over
the = appropriate use of the Generic Response = message.

I = see. 

It seems fairly = evident to
me that Generic Response should be used to convey error = status that is common to
multiple message types, justifying the = definition of the error cases in base
rather than another = document.

The simple case is for = "unrecognized/invalid message" where we need a generic = message.

And I = believe strongly that if there is
information that should be sent in = a response in answer to a particular message
type, and that = information is specific to that message type, then the = response
message should be of the same type as the original = request.

The questions in my mind begin when you have the latter = case, but you have a
generic type of error to = report.

Agreed.

Do you report the error in a Generic = Response,
or in the defined response message using a Status TLV = embedded in that response
message? I think you do, to simplify the = message-processing state machine. And
that means some changes in some = of the work we have done already. Particularly,
my colleague Fortune = Huang (18/08/2009) pointed out the complexity of handling
Delegated = Bandwidth Query

That's probably a = good case to look at.

There are some errors = that are fairly specific to the Delegated Bandwidth Query (for = example"Bandwidth Delegation not activated"). I understand you're saying = you'd like to see those conveyed inside the "Delegated Bandwidth Query = Response".

There are also some errors that are = independent of the actual query type (for example "invalid Target"). I = understand you're suggesting those also get conveyed via a type-specific = response. 

One even more interesting case = is when we don't have a response defined already (eg for Multicast = Replication Control message). Then should we create a new type-specific = response (eg Multicast Replication Control response) or should we use = the generic response (to avoid creating new message = types)?

Francois


.


Francois Le Faucheur = wrote:
Tom,
On 9 Oct 2009, at 13:53, Tom Taylor = wrote:
Please see below.

Francois Le Faucheur = wrote:
including the ANCP list as = others may be = interested.
Francois
On = 8 Oct 2009, at 16:53, Francois Le Faucheur = wrote:
Hi = Tom,

One question to better = understand your = proposal:
In h= ttp://www.ietf.org/mail-archive/web/ancp/current/msg00955.html you = said:
"Given that that Command TLVs = will be present only in a limited set of message types, and "Cmnd Nmbr" = is not one of the fields defined within the Command TLV, I would also = remove "Cmnd Nmbr" from Status-Info. It can always be specified as part = of the failureresponse to a particular message = type."

I am not sure how to read = that.
Are you saying that the Cmnd Nb = would not appear in the Generic Response message because if it is needed = we woudl use a more specific Response = message?
[PTT]
Yes, that's what I had in = mind.

For the case of a negative = response to a Multicast Replication Control message: are you proposing = that the Generic Response message be used (and then would it not have to = contain the "Cmnd Nb") or are you saying that we would then use a new = "Multicast Replication Control Response" which woudl contain the Cmnd = Nb?
[PTT]
I would recommend a response = specific to Multicast Replication = Control.
This = seems in contradiction with your Email of 27/08/2009 which = says:
* Change "Multicast = Status" to "Generic Response".
*= "I assume the text should really read that the receiver MUST send a = Generic Response message with the appropriate contents if unable to = execute the complete Multicast Replication Control message = successfully."
So, I am a = little confused, now.
Currently,= the Multicast Status message can be used in many scenarios including in = responses to:
=    * Multicast REplication Control = request
   * = Admission Control message
=    * Bandwidth Reallocation
    * Delegated Bw Query = Request
   * = Multicast Flow Query
Could you = recap briefly what message you are proposing be used instead in each of = these cases?
I can see that it = would make sense to have a Generic Response message to deal with a = number of generic cases (such as when a message is not recognized, or = invalid).
Other than that, the = MUlticast Status message was pretty much used as a multi-purpose = response already (only, limited to all multicast use = cases).
Thanks
Francois
However, my E-mail of 27/08/2009 = suggested adding a new sub-TLV to Status-Info. To quote from the earlier = message:

*** command = error
-- Needs a new Code value, so = add

85    Command = error

to base, and define in base a = sub-TLV of Status-info to carry the sequence number of the command = within the message. This sub-TLV could also carry an additional = diagnostic code with its own IANA registry if people think it might be = useful. Extensions would define the actual code values and add them to = the registry. Likely candidates are some of the errors listed in section = 4.4:

- Command not = supported

- Flag set but not = supported

- M Flag set, but no IP Source = address provided

- Unsupported Address = Family

- Unsupported address = encoding

- Malformed flow = address

- Multicast flow does not = exist



Thanks

francois


On 6 Oct 2009, at 17:15, Tom = Taylor = wrote:

I'm = very happy to do that. Then we can discuss the = result.

Maglione= Roberta = wrote:
Hello = Tom,
<= /blockquote>
=     in my opinion instead of submitting a new = individual draft you should update the current mcast draft and propose = your changes as a new version of the = draft:
draft-ietf-ancp-mc-extensions-01
Meanwhile I can update the = protocol draft with the additional changes that you = proposed.
Best = Regards,
Roberta
-----Original = Message-----
From: = Tom Taylor = [mailto:tom.taylor@rogers.com]
<= /blockquote>
Sent: Tuesday, October 06, 2009 = 4:57 = PM
To: Francois Le Faucheur IMAP; = Maglione Roberta; Wojciech = Dec
Subject: Changes to ANCP = multicast
I made = some major proposals regarding the ANCP protocol drafts at the end = of
August but have had no feedback. = I'm wodering if the best way forward, given = all
I have in mind, is to submit a = new draft-taylor-ancp-mc-extensions = incorporating
all my = proposals, to serve as a basis for discussion that people can relate = to.
What are your = views?
Tom
<= /blockquote>
Questo = messaggio e i suoi allegati sono indirizzati esclusivamente alle persone = indicate. La diffusione, copia o qualsiasi altra azione derivante dalla = conoscenza di queste informazioni sono rigorosamente vietate. Qualora = abbiate ricevuto questo documento per errore siete cortesemente pregati = di darne immediata comunicazione al mittente e di provvedere alla sua = distruzione, = Grazie.
This = e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, = printing or use by anybody else is unauthorised. If you are not the = intended recipient, please delete this message and any attachments and = advise the sender by return e-mail, = Thanks.


= _______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ancp

= --Apple-Mail-20-17908541-- From flefauch@cisco.com Mon Oct 12 08:10:58 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3153A690B for ; Mon, 12 Oct 2009 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYcAaKOrqi7e for ; Mon, 12 Oct 2009 08:10:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 36C273A68EC for ; Mon, 12 Oct 2009 08:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=512; q=dns/txt; s=amsiport01001; t=1255360258; x=1256569858; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Status-Info=20TLV=20Type|Date:=20Mon,=2012=20 Oct=202009=2017:10:55=20+0200|Message-Id:=20|To:=20ancp@ietf.org |Cc:=20Francois=20Le=20Faucheur=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v10 76)|Content-Transfer-Encoding:=207bit; bh=X+7DxCc852xGZCXCyzYdLH1HPZkXp5CWuuaXVPuk9ls=; b=dlAa5ISb6PL76gFKk3cuB8vZSkFeFlNOmSCQ4KNoxmWLV/hVzaGjer7m cTshdvkXUN11Q5ED8m1fohWbIWWGZqJLvOJCKKwaio489LiXfZEBkzik7 cD5D7cW1cV9dpM2IVOhB/cL7kHX0sFKHCRZhYUXQuQyzRhZpEOGT1cQxe U=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="51560794" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 15:10:56 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CFAuuY026865; Mon, 12 Oct 2009 15:10:56 GMT Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: Date: Mon, 12 Oct 2009 17:10:55 +0200 To: ancp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [ANCP] Status-Info TLV Type X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 15:10:58 -0000 Folks, When the Status-Info TLV was introduced there was a proposal for using 0x106 as the TLV Type. The official TLV Type remained "TBD" for a long while and the value 0x10 was eventually allocated. While trying to use the 0x10 value, we run into interop issues with an earlier implementation that worked off 0x106. Could we allocate 0x106 as the Status-Info TLV (instead of 0x10) to minimize interop issues with implementations that worked off the earlier value? Thanks Francois From Sidd.Aanand@ecitele.com Mon Oct 12 08:17:30 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C203028C229 for ; Mon, 12 Oct 2009 08:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwd8olc5WA1d for ; Mon, 12 Oct 2009 08:17:30 -0700 (PDT) Received: from uspitiron01.ecitele.com (uspitiron01.ecitele.com [63.94.127.135]) by core3.amsl.com (Postfix) with ESMTP id F194E28C228 for ; Mon, 12 Oct 2009 08:17:29 -0700 (PDT) Received: from nat-33.laurelnetworks.com (HELO uspitexch01.ecitele.com) ([63.94.127.33]) by uspitiron01-out.ecitele.com with ESMTP; 12 Oct 2009 11:10:53 -0500 Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Mon, 12 Oct 2009 11:17:30 -0400 From: Sidd Aanand To: Francois Le Faucheur , "ancp@ietf.org" Date: Mon, 12 Oct 2009 11:17:29 -0400 Thread-Topic: [ANCP] Status-Info TLV Type Thread-Index: AcpLTjhyl+nItnmzQ5SGfG4zUvOY2QAAM9hw Message-ID: <047B8373FDE6CE4BBAC116646F35479201312C0D23@USPITMAIL01.ecitele.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] Status-Info TLV Type X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 15:17:30 -0000 I strongly vote for using 0x106. We have enough mess already dealing with T= LVs being re-used between wadhwa-00 and later versions of ANCP drafts. Thanks, Sidd=20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: Monday, October 12, 2009 11:11 AM To: ancp@ietf.org Subject: [ANCP] Status-Info TLV Type Folks, When the Status-Info TLV was introduced there was a proposal for using 0x106 as the TLV Type. The official TLV Type remained "TBD" for a long whil= e and the value 0x10 was eventually allocated. While trying to use the 0x10= value, we run into interop issues with an earlier implementation that work= ed off 0x106. Could we allocate 0x106 as the Status-Info TLV (instead of 0x10) to minimiz= e interop issues with implementations that worked off the earlier value? Thanks Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From roberta.maglione@telecomitalia.it Tue Oct 13 01:08:18 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E4A3A677C for ; Tue, 13 Oct 2009 01:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bINRgWViMufL for ; Tue, 13 Oct 2009 01:08:17 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 42A1428C0E6 for ; Tue, 13 Oct 2009 01:08:17 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 13 Oct 2009 10:08:16 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 13 Oct 2009 10:08:16 +0200 From: Maglione Roberta To: "ancp@ietf.org" Date: Tue, 13 Oct 2009 10:08:15 +0200 Thread-Topic: Proposal to use Tech Type 0x01 for PON Thread-Index: AcpLQ9Cc5wovaia5TCKpN5+DrgsGJAAXA64AAA7Y/NA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FE5@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ANCP] Proposal to use Tech Type 0x01 for PON X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 08:08:18 -0000 Hi All, Fortune suggested allocating Tech Type 0x01 for PON technology. Today = the only value used for Tech Type is 0x05 for DSL. Does anybody see any problem with this proposal? If not I'm going to make t= his change and include it in version 07 of the protocol draft. Please let me know. Thanks and best regards. Roberta -----Original Message----- From: Fortune HUANG [mailto:fqhuang@huawei.com] Sent: Tuesday, October 13, 2009 3:05 AM To: Maglione Roberta; 'Tom Taylor'; 'Francois Le Faucheur'; HaagT@telekom.d= e; swadhwa@juniper.net Cc: 'Dec Wojciech'; 'BOCCI Matthew' Subject: RE: New version of ancp-protocol draft Hi Roberta, Thanks for releasing the used values 0x01 - 0x04 Tech Type. I also suggest allocating a Tech Type (e.g. 0x01) for PON in this -07 draft directly, as this is an obvious requirement. Or else we may need to do that in a -08 or later draft. Best regards, Fortune Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From roberta.maglione@telecomitalia.it Tue Oct 13 01:27:44 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCE628C1AD for ; Tue, 13 Oct 2009 01:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.325 X-Spam-Level: * X-Spam-Status: No, score=1.325 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuwD2R8jXG8n for ; Tue, 13 Oct 2009 01:27:42 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 3282A3A6926 for ; Tue, 13 Oct 2009 01:27:42 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 13 Oct 2009 10:27:41 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 13 Oct 2009 10:27:42 +0200 From: Maglione Roberta To: Sidd Aanand , Francois Le Faucheur , "ancp@ietf.org" Date: Tue, 13 Oct 2009 10:27:41 +0200 Thread-Topic: [ANCP] Status-Info TLV Type Thread-Index: AcpLTjhyl+nItnmzQ5SGfG4zUvOY2QAAM9hwACOy6rA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FE6@GRFMBX704BA020.griffon.local> References: <047B8373FDE6CE4BBAC116646F35479201312C0D23@USPITMAIL01.ecitele.com> In-Reply-To: <047B8373FDE6CE4BBAC116646F35479201312C0D23@USPITMAIL01.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] Status-Info TLV Type X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 08:27:44 -0000 Hello Francois, Sidd and All, I don't recall we select the value 0x0106 for Status-Info; anyway if bo= th of you already have implementations using this value, and nobody else ha= s any objections, in order to facilitate interoperability, I can update the= protocol draft allocating 0x106 for Status info. Best Regards, Roberta -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Sid= d Aanand Sent: Monday, October 12, 2009 5:17 PM To: Francois Le Faucheur; ancp@ietf.org Subject: Re: [ANCP] Status-Info TLV Type I strongly vote for using 0x106. We have enough mess already dealing with T= LVs being re-used between wadhwa-00 and later versions of ANCP drafts. Thanks, Sidd -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: Monday, October 12, 2009 11:11 AM To: ancp@ietf.org Subject: [ANCP] Status-Info TLV Type Folks, When the Status-Info TLV was introduced there was a proposal for using 0x106 as the TLV Type. The official TLV Type remained "TBD" for a long whil= e and the value 0x10 was eventually allocated. While trying to use the 0x10= value, we run into interop issues with an earlier implementation that work= ed off 0x106. Could we allocate 0x106 as the Status-Info TLV (instead of 0x10) to minimiz= e interop issues with implementations that worked off the earlier value? Thanks Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Sidd.Aanand@ecitele.com Tue Oct 13 06:49:27 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794BE28C1E7 for ; Tue, 13 Oct 2009 06:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNI5DgYPsl2l for ; Tue, 13 Oct 2009 06:49:26 -0700 (PDT) Received: from uspitiron01.ecitele.com (uspitiron01.ecitele.com [63.94.127.135]) by core3.amsl.com (Postfix) with ESMTP id 8BA5128C0D9 for ; Tue, 13 Oct 2009 06:49:26 -0700 (PDT) Received: from nat-33.laurelnetworks.com (HELO uspitexch02.ecitele.com) ([63.94.127.33]) by uspitiron01-out.ecitele.com with ESMTP; 13 Oct 2009 09:42:47 -0500 Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Tue, 13 Oct 2009 09:49:27 -0400 From: Sidd Aanand To: Maglione Roberta , "ancp@ietf.org" Date: Tue, 13 Oct 2009 09:49:26 -0400 Thread-Topic: Proposal to use Tech Type 0x01 for PON Thread-Index: AcpLQ9Cc5wovaia5TCKpN5+DrgsGJAAXA64AAA7Y/NAADCwqkA== Message-ID: <047B8373FDE6CE4BBAC116646F35479201312C0EE9@USPITMAIL01.ecitele.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FE5@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FE5@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] Proposal to use Tech Type 0x01 for PON X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:49:27 -0000 I don't have any issues with this. Thanks, Sidd=20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Mag= lione Roberta Sent: Tuesday, October 13, 2009 4:08 AM To: ancp@ietf.org Subject: [ANCP] Proposal to use Tech Type 0x01 for PON Hi All, Fortune suggested allocating Tech Type 0x01 for PON technology. Today = the only value used for Tech Type is 0x05 for DSL. Does anybody see any problem with this proposal? If not I'm going to make t= his change and include it in version 07 of the protocol draft. Please let me know. Thanks and best regards. Roberta -----Original Message----- From: Fortune HUANG [mailto:fqhuang@huawei.com] Sent: Tuesday, October 13, 2009 3:05 AM To: Maglione Roberta; 'Tom Taylor'; 'Francois Le Faucheur'; HaagT@telekom.d= e; swadhwa@juniper.net Cc: 'Dec Wojciech'; 'BOCCI Matthew' Subject: RE: New version of ancp-protocol draft Hi Roberta, Thanks for releasing the used values 0x01 - 0x04 Tech Type. I also suggest allocating a Tech Type (e.g. 0x01) for PON in this -07 draft= directly, as this is an obvious requirement. Or else we may need to do tha= t in a -08 or later draft. Best regards, Fortune Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From root@core3.amsl.com Tue Oct 13 16:00:01 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DD6A73A68A5; Tue, 13 Oct 2009 16:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091013230001.DD6A73A68A5@core3.amsl.com> Date: Tue, 13 Oct 2009 16:00:01 -0700 (PDT) Cc: matthew.bocci@alcatel-lucent.com, ancp@ietf.org Subject: [ANCP] WG Action: RECHARTER: Access Node Control Protocol (ancp) X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 23:00:02 -0000 The charter of the Access Node Control Protocol (ancp) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Access Node Control Protocol (ancp) ----------------------------------- Current Status: Active Working Group Chair(s): Wojciech Dec Matthew Bocci Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion: ancp@ietf.org To Subscribe: ancp-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Goals and Milestones: Done Accept WG I-D for ANCP Framework and Requirements Done Accept WG I-D for Access Node Control Protocol (ANCP) Done Accept WG ID for Security Threats analysis Done Accept WG I-D for ANCP MIB Done Security Threats Analysis last call Done Framework and Requirements last call Done Accept WG I-D for ANCP Multicast Extensions Nov 2009 Accept WG I-D for ANCP applicability to PON Jan 2010 Access Node Control Protocol (ANCP) Last Call Jan 2010 ANCP Multicast Extensions last call Jan 2010 ANCP MIB Last Call Apr 2010 ANCP applicability to PON last call Jul 2010 Re-charter or conclude Working Group From wdec@cisco.com Wed Oct 14 04:07:09 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAF128C127 for ; Wed, 14 Oct 2009 04:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CH7zfrlfSBj for ; Wed, 14 Oct 2009 04:07:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 24D493A6997 for ; Wed, 14 Oct 2009 04:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=13866; q=dns/txt; s=amsiport01001; t=1255518429; x=1256728029; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20FW:=20ANCP=20Versioning=20-=20next=20steps |Date:=20Wed,=2014=20Oct=202009=2013:06:38=20+0200 |Message-ID:=20|To:=20|Cc:=20"BOCCI =20Matthew"=20 |MIME-Version:=201.0; bh=/s/sm9Gr2wWVaIQJSc1BNRPtZsS4ucY2czKxjvz/sEI=; b=iwlEfUo7H9uXY8gbmGK7WheuE140C8jStKUuY5NQaHFpqqxQYbNHCFLa 5ES2dmVJlvDEcQdxvqQTZTqQYw0Rq+3cxLviWwSQc/4gLiOzJn/emi4GW pyBv949a2GKX+zAj8QqWdghQJdow4qSHNHeHtCxtieA5ZDdAwA3paHvs6 Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwAAAtN1UqQ/uCWe2dsb2JhbACCJi6YMwEBFiQGpF2YVoIwgX0EgVs X-IronPort-AV: E=Sophos;i="4.44,557,1249257600"; d="scan'208,217";a="51755751" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 11:07:07 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EB77Fx021882; Wed, 14 Oct 2009 11:07:07 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 13:06:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4CBE.69926BA9" Date: Wed, 14 Oct 2009 13:06:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Versioning - next steps Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMg From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 14 Oct 2009 11:06:43.0059 (UTC) FILETIME=[697A2430:01CA4CBE] Subject: [ANCP] FW: ANCP Versioning - next steps X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:07:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4CBE.69926BA9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hi All, >=20 > During the ITEF75 WG meeting a discussion was had on ANCP protocol > versioning and the need to revise the protocol version. A follow-up > e-mail discussion on the WG alias took place and it seems appropriate > now (if not overdue) to draw up a set of recommendations and settle > the issue: >=20 > Recommended protocol draft changes and WG actions >=20 > - The currently used ANCP version 3.1 is to change to 3.2 at the time > of publishing as an RFC. An instruction to execute such a change > should be placed as part of an editors' note in the next revision of > draft-ietf-ancp-protocol. This instruction is expected to only come > into effect at the time of final review past a WG last-call, which > means that until then v3.1 will be in evidence. Current implementers > should make a note of this fact. >=20 > - Another note (not editorial though) should be placed in an > appropriate section, possibly Section 2 or Section 5, to convey > in-brief the historic aspect of GSMP/ANCP v3.1 implementations, which > are (were?) based on early versions of the ANCP protocol draft. The > note should be clear in offering no guarantees in terms of backwards > compatibility of the RFC spec to those early-draft implementations. > The note must also not be seen as passing a normative reference to the > early protocol draft.=20 >=20 > - Along with the above note, the existing GSMP/ANCP version > negotiation mechanisms could be highlighted, indicating that it > provides a way to distinguish between the different versions if the > adjacency establishment negotiation mechanism followed by all is as > per GSMPv3 (rfc3292). >=20 > - For the sake of clarity it is recommended that the adjacency > negotiation be more fully described in the ANCP protocol draft instead > of the current reference to rfc3292. Specifically, it would appear > reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP > protocol spec, with the re-edit describing the version negotiation > behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text > or logic statements as to the expected behaviour in case of version > differences, but such text is in evidence in the descriptive part of > Section 11.1. >=20 - The WG should identify what version of the ANCP protocol draft specification constitutes v3.1. A non-normative reference to such a reference could be passed in the v3.2 spec. > Rationale >=20 > From a technical point of view, given that a "current" (i.e. > draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) > protocols are identical, with any newly added functions covered as > negotiable capabilities, the version change does not appear to be > fully warranted and not fully in line with the guidelines previously > laid down > (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). > That said, from an operational perspective a reasonable case for such > a version change has made based and presented in > https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_doc > ument.htm.=20 Now, given that normative compliance to an interim draft (such as draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text which may be perceived as mandating or claiming compatibility to such interim drafts needs to be avoided. > In the case of vendors and operators that already support/use v3.1 and > have plans for v3.2, the version negotiation mechanism that ANCP > inherited from GSMPv3 provides a way to disambiguate the two protocols > and thus allows in theory for supporting running a pre-standard (v3.1) > and a standards compliant v3.2 on any given ANCP node. The issue of > where v3.1 is documented can be solved by using non-normative > references to one of the interim drafts. The issue of what rev of > draft-ietf-ancp is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending the protocol spec to cover issues around protocol version negotiation or remediation of incompatibilities of draft implementations. As such no such work is expected. We welcome clarification questions on the above. > Regards, > Wojciech & Matthew. >=20 ------_=_NextPart_001_01CA4CBE.69926BA9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: ANCP Versioning - next steps

Hi = All,

During the ITEF75 = WG meeting a discussion was had on ANCP protocol versioning and the need = to revise the protocol version. A follow-up e-mail discussion on the WG = alias took place and it seems appropriate now (if not overdue) to draw up a set of recommendations and settle = the issue:

Recommended = protocol draft changes and WG = actions

- The currently = used ANCP version 3.1 is to change to 3.2 at the time of publishing as = an RFC. An instruction to execute such a change should be placed as part = of an editors' note in the next revision of draft-ietf-ancp-protocol. = This instruction is expected to only come into effect at the time of = final review past a WG last-call, which means that until then v3.1 will = be in evidence. Current implementers should make a note of this = fact.

- Another note = (not editorial though) should be placed in an appropriate section, = possibly Section 2 or Section 5, to convey in-brief the historic aspect = of GSMP/ANCP v3.1 implementations, which are (were?) based on early = versions of the ANCP protocol draft. The note should be clear in = offering no guarantees in terms of backwards compatibility of the RFC = spec to those early-draft implementations. The note must also not be = seen as passing a normative reference to the early protocol draft. =

- Along with the = above note, the existing GSMP/ANCP version negotiation mechanisms could = be highlighted, indicating that it provides a way to distinguish between = the different versions if the adjacency establishment negotiation = mechanism followed by all is as per GSMPv3 (rfc3292).

- For the sake of = clarity it is recommended that the adjacency negotiation be more fully = described in the ANCP protocol draft instead of the current reference to = rfc3292. Specifically, it would appear reasonable to adopt and re-edit = Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-edit = describing the version negotiation behaviour. Rather confusingly Rfc3292 = Section 11.2 does not carry text or logic statements as to the expected = behaviour in case of version differences, but such text is in evidence = in the descriptive part of Section 11.1.

- The WG should identify what version of the ANCP = protocol draft specification constitutes v3.1. A non-normative reference = to such a reference could be passed in the v3.2 spec.

Rationale

From a technical = point of view, given that a "current" (i.e. draft-ietf-protocol-06 based) and = future (i.e. ANCP = RFC = based) protocols are identical, = with any = newly added = functions = covered as negotiable capabilities, the version change does not appear to be fully warranted and = not fully in line with the guidelines previously laid down = (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152= .html). That said, from an operational perspective a reasonable case for such a version change has made based = and presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_= files/v3_document.htm.

Now, given that = normative compliance to an interim draft (such as draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text which may be perceived as mandating or claiming compatibility to = such  = interim drafts needs to be = avoided.

In the case = of vendors and operators that already support/use v3.1 and have plans for v3.2, the = version negotiation mechanism that ANCP inherited from GSMPv3 provides a = way to disambiguate the two protocols and thus allows in theory for supporting running a = pre-standard (v3.1) and a standards compliant v3.2 on any given ANCP = node. The issue = of where v3.1 is documented can be solved by using non-normative = references to one of the interim drafts. The issue of what rev of = draft-ietf-ancp is considered to be v3.1 needs to be = clarified.

Other than the = above the WG is currently not chartered to be = extending the protocol spec to cover issues around protocol version = negotiation or remediation of incompatibilities of draft = implementations. = As such no such work is expected.

We welcome clarification questions on the = above.

Regards,
Wojciech & = Matthew.

------_=_NextPart_001_01CA4CBE.69926BA9-- From alan.kavanagh@ericsson.com Wed Oct 14 10:51:21 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA1C28C172 for ; Wed, 14 Oct 2009 10:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1I1UMzZXwf2 for ; Wed, 14 Oct 2009 10:51:19 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 7A4763A672E for ; Wed, 14 Oct 2009 10:51:19 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9EHorgn011365; Wed, 14 Oct 2009 12:50:55 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:49:55 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:49:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 14 Oct 2009 13:49:54 -0400 From: Alan Kavanagh To: "Wojciech Dec (wdec)" , "ancp@ietf.org" Date: Wed, 14 Oct 2009 13:49:53 -0400 Thread-Topic: ANCP Versioning - next steps Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAAmvg1A= Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D59A582629@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1B6D0317D3AD964FBF3956DEFA3524D59A582629EUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2009 17:49:54.0654 (UTC) FILETIME=[BCCA97E0:01CA4CF6] Subject: Re: [ANCP] ANCP Versioning - next steps X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 17:51:21 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D59A582629EUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In general i support this way forward by adding "Informative Reference" to = the ANCP Protocol Draft when going to WG last call. Just for clarification, what is the reason for not offering guarantess for = backward compatibility? Alan ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: October 14, 2009 7:07 AM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps Hi All, During the ITEF75 WG meeting a discussion was had on ANCP protocol versioni= ng and the need to revise the protocol version. A follow-up e-mail discussi= on on the WG alias took place and it seems appropriate now (if not overdue)= to draw up a set of recommendations and settle the issue: Recommended protocol draft changes and WG actions - The currently used ANCP version 3.1 is to change to 3.2 at the time of pu= blishing as an RFC. An instruction to execute such a change should be place= d as part of an editors' note in the next revision of draft-ietf-ancp-proto= col. This instruction is expected to only come into effect at the time of f= inal review past a WG last-call, which means that until then v3.1 will be i= n evidence. Current implementers should make a note of this fact.[Alan Kava= nagh] Agree it makes sense to include the noted change of ANCP Version/Sub-= version to 3.2 and agree that this should be captured in the current draft = as an editors note. - Another note (not editorial though) should be placed in an appropriate se= ction, possibly Section 2 or Section 5, to convey in-brief the historic asp= ect of GSMP/ANCP v3.1 implementations, which are (were?) based on early ver= sions of the ANCP protocol draft. The note should be clear in offering no g= uarantees in terms of backwards compatibility of the RFC spec to those earl= y-draft implementations. The note must also not be seen as passing a normat= ive reference to the early protocol draft. [Alan Kavanagh] Agree an Normat= ive Reference should note the reason for change from 3.1 to 3.2 and I suppo= rt the recommendation here, the most appropiate section i believe is Sectio= n 5 imho. - Along with the above note, the existing GSMP/ANCP version negotiation mec= hanisms could be highlighted, indicating that it provides a way to distingu= ish between the different versions if the adjacency establishment negotiati= on mechanism followed by all is as per GSMPv3 (rfc3292). [Alan Kavanagh] Agree, though RFC 3292 does not have sub-version. - For the sake of clarity it is recommended that the adjacency negotiation = be more fully described in the ANCP protocol draft instead of the current r= eference to rfc3292. Specifically, it would appear reasonable to adopt and = re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-ed= it describing the version negotiation behaviour. [Alan Kavanagh] Agree, and this is what I proposed sometime back, though 32= 92 does currently not cover sub-version and this must be covered in the re-= edited section to be included in the ancp protocol spec, For clarification,= what is your recommendation for the adjacency negotiation? Is it to includ= e the sub-version also?. Rather confusingly Rfc3292 Section 11.2 does not c= arry text or logic statements as to the expected behaviour in case of versi= on differences, but such text is in evidence in the descriptive part of Sec= tion 11.1.[Alan Kavanagh] Therefore are you noting we should include text = in the ANCP protocol draft as to what expected behaviour should be in the e= vent of Version/sub-version differences? - The WG should identify what version of the ANCP protocol draft specificat= ion constitutes v3.1. A non-normative reference to such a reference could b= e passed in the v3.2 spec. Rationale >From a technical point of view, given that a "current" (i.e. draft-ietf-pro= tocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, w= ith any newly added functions covered as negotiable capabilities, the versi= on change does not appear to be fully warranted and not fully in line with = the guidelines previously laid down (http://www.ietf.org/mail-archive/web/a= ncp/current/msg00152.html). That said, from an operational perspective a re= asonable case for such a version change has made based and presented in htt= ps://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.ht= m. Now, given that normative compliance to an interim draft (such as draft-iet= f-protocol-06 based) cannot be passed by the ANCP RFC, text which may be pe= rceived as mandating or claiming compatibility to such interim drafts need= s to be avoided. In the case of vendors and operators that already support/use v3.1 and have= plans for v3.2, the version negotiation mechanism that ANCP inherited from= GSMPv3 provides a way to disambiguate the two protocols and thus allows in= theory for supporting running a pre-standard (v3.1) and a standards compli= ant v3.2 on any given ANCP node. [Alan Kavanagh] Agree, will this be noted= in the ANCP protocol draft as opposed to a reference pointer to RFC3292? T= he issue of where v3.1 is documented can be solved by using non-normative r= eferences to one of the interim drafts. The issue of what rev of draft-ietf= -ancp is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending the = protocol spec to cover issues around protocol version negotiation or remedi= ation of incompatibilities of draft implementations. As such no such work i= s expected. We welcome clarification questions on the above. Regards, Wojciech & Matthew. --_000_1B6D0317D3AD964FBF3956DEFA3524D59A582629EUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: ANCP Versioning - next steps
In general i support this way forward by adding=20 "Informative Reference" to the ANCP Protocol Draft when going to WG la= st=20 call. 
 
Just for clarification, what is the reason for not= offering=20 guarantess for backward compatibility?
 
Alan

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: October 14, 2009 7:07 AM
To:=20 ancp@ietf.org
Subject: [ANCP] FW: ANCP Versioning - next=20 steps


Hi All,

During the ITEF75 WG meet= ing a=20 discussion was had on ANCP protocol versioning and the need to revise the=20 protocol version. A follow-up e-mail discussion on the WG alias took place = and=20 it seems appropriate now= (if not=20 overdue) to draw up a set of recommendat= ions and=20 settle the issue:

Recommended protocol d= raft=20 changes and WG=20 actions

- The currently use= d ANCP=20 version 3.1 is to change to 3.2 at the time of publishing as an RFC. An=20 instruction to execute such a change should be placed as part of an editors= '=20 note in the next revision of draft-ietf-ancp-protocol. This instruction is= =20 expected to only come into effect at the time of final review past a WG=20 last-call, which means that until then v3.1 will be in evidence. Current=20 implementers should make a note of this fact.[Alan Kavanagh] Agree=  it=20 makes sense to include the noted change of ANCP Version/Sub-version to= 3.2=20 and agree that this should be captured in the current draft as an editors=20 note. 

- Another note (not= editorial=20 though) should be placed in an appropriate section, possibly Section 2 or=20 Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1=20 implementations, which are (were?) based on early versions of the ANCP prot= ocol=20 draft. The note should be clear in offering no guarantees in terms of backw= ards=20 compatibility of the RFC spec to those early-draft implementations. The not= e=20 must also not be seen as passing a normative reference to the early protoco= l=20 draft. [Alan Kavanag= h] =20 Agree an Normative Reference should note the reason for change fr= om=20 3.1 to 3.2 and I support the recommendation here, the most appropiate secti= on i=20 believe is Section 5 imho.

- Along with the ab= ove note,=20 the existing GSMP/ANCP version negotiation mechanisms could be highlighted,= =20 indicating that it provides a way to distinguish between the different vers= ions=20 if the adjacency establishment negotiation mechanism followed by all is as = per=20 GSMPv3 (rfc3292).
[Alan=20 Kavanagh]  Agree, though RFC 3292 does not have=20 sub-version.

- For the sake of c= larity it=20 is recommended that the adjacency negotiation be more fully described in th= e=20 ANCP protocol draft instead of the current reference to rfc3292. Specifical= ly,=20 it would appear reasonable to adopt and re-edit Section 11.2 of rfc3292 int= o the=20 ANCP protocol spec, with the re-edit describing the version negotiation=20 behaviour.
[Alan= =20 Kavanagh] Agree, and this is what I proposed sometime back, thoug= h=20 3292 does currently not cover sub-version and this must be covered in the=20 re-edited section to be included in the ancp protocol spec, For clarificati= on,=20 what is your recommendation for the adjacency negotiation? Is it to include= the=20 sub-version also?. Rather confusingly Rfc3292 Section 11= .2=20 does not carry text or logic statements as to the expected behaviour in cas= e of=20 version differences, but such text is in evidence in the descriptive part o= f=20 Section 11.1.[Alan=20 Kavanagh]  Therefore are you noting we should include text in the= ANCP=20 protocol draft as to what expected behaviour should be in the event of=20 Version/sub-version differences? 

- The WG = should=20 identify what version of the ANCP protocol draft specification constitutes = v3.1.=20 A non-normative reference to such a reference could be passed in the v3.2=20 spec.

Rationale

From a technical point of= view,=20 given that a "current" (= i.e.=20 draft-ietf-protocol-06 based) and fut= ure=20 (i.e. ANCP RFC based<= /FONT>) protocols are identical, with any new<= FONT=20 face=3DArial color=3D#000000 size=3D2>ly added=20 functions covered as negotiable capabilities, the version change does not appear=20 to be fully warranted and not fully in line with the guidelines previously lai= d down=20 (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from an operational p= erspective a=20 reasonable case for such= =20 a version change has made based and presented i= n=20 https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm.

Now, given that normative compliance to an interim draft=20 (such as draft-ietf-protocol-06=20 based) cannot be passed by the ANCP RFC,= text=20 which may be perceived as mandating or claiming compatibility to such  interim drafts needs to be avoided.

In the case of vendors and = operators=20 that already support/use v3.1 and have plans for v3.2, the version nego= tiation=20 mechanism that ANCP inherited from GSMPv3 provides a way to disambiguate th= e two=20 protocols and thus allows in theory for supporting running a pre-standard (v3.1) and a standards co= mpliant=20 v3.2 on any given ANCP node. [Alan Kavanagh]  Agree, will this be noted in the ANCP= =20 protocol draft as opposed to a reference pointer to=20 RFC3292? The issue of where v3.1 i= s=20 documented can be solved by using non-normative references to one of the in= terim=20 drafts. The issue of what rev of draft-ietf-ancp is considered to be v3.1 n= eeds=20 to be clarified.

Other than the above the = WG is=20 currently not chartered = to=20 be extending the protocol spec to cover = issues=20 around protocol version negotiation or remediation of incompatibilities of = draft=20 implementations. As such= no such=20 work is expected.

We welcom= e=20 clarification questions on the above.

Regards, Wojciech & Matthew.

--_000_1B6D0317D3AD964FBF3956DEFA3524D59A582629EUSAACMS0701eam_-- From alan.kavanagh@ericsson.com Wed Oct 14 10:59:06 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC633A6767 for ; Wed, 14 Oct 2009 10:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJEG0oeheRbu for ; Wed, 14 Oct 2009 10:59:05 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D7F6F3A672E for ; Wed, 14 Oct 2009 10:59:04 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9EHwbmQ015985; Wed, 14 Oct 2009 12:58:38 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:57:50 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:57:50 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 14 Oct 2009 13:57:50 -0400 From: Alan Kavanagh To: Tom Taylor , "HaagT@telekom.de" Date: Wed, 14 Oct 2009 13:57:48 -0400 Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AconS5rIB3anKyxqRNCdIM6DSrHEVghqTAZg Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D59A582637@EUSAACMS0701.eamcs.ericsson.se> References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com><040201ca1987$008a6670$5728460a@china.huawei.com><1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de><35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> <5661758E3E93364685B91DD8272F287601B8E2D3@S4DE8PSAAQC.mitte.t-com.de> <4A96DCB7.7060303@rogers.com> In-Reply-To: <4A96DCB7.7060303@rogers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2009 17:57:50.0315 (UTC) FILETIME=[D84EB3B0:01CA4CF7] Cc: "B.Witschurke@telekom.de" , "ancp@ietf.org" , Peter Arberg , "Robert.Rennison@ecitele.com" , "Peter.Hamacher@telekom.de" Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 17:59:06 -0000 Hi Tom and Thomas >From a recent email sent by Woj, I support Thomas Haag's text as input into= the re-edited sections for clarifying the ANCP Protocol versioning number = issue and I agree with Thomas' proposed text. Additional text is required f= or clarifying the Adjacency Protocol negotiation in ANCP as noted by the Wo= j's email.=20 Alan -----Original Message----- From: Tom Taylor [mailto:tom.taylor@rogers.com]=20 Sent: August 27, 2009 3:21 PM To: HaagT@telekom.de Cc: Robert.Rennison@ecitele.com; Alan Kavanagh; lihy@huawei.com; Peter Arbe= rg; wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org; B.Witschurke@teleko= m.de; Peter.Hamacher@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning Comments below, marked with [PTT]. HaagT@telekom.de wrote: > All, >=20 > All exchanged arguments are valid. >=20 > I think a protocol draft describes protocol issues, values, TLV, etc.=20 > and not network element mechanisms. The challenge now would be to=20 > cover notes pointing out how to code pre version and RFC version -=20 > that was agreed last meeting. >=20 > But what's missing in that game is a short description that both peers=20 > (BRAS & AN) need to identify which SW version to choose based on sub vers= ion value. > A mechnism in detail for detection and automatic SW load depending on=20 > sub version is neccessary. >=20 > I'm not sure if that is in scope of a protocol draft or if it should=20 > be described seperately. But keeping the time line of protocol draft=20 > and avoiding delaying ANCP work it may be desirable to identify=20 > sections in protocol draft where notes are useful to detail that issue=20 > without changing sections and order of the document. >=20 >> From my understanding three sections are concerned. I propose adding=20 >> the notes at that sections. >=20 > Please see below the identified sections and added notes taken based=20 > on protocol draft 05 for discussion: >=20 > Regards Thomas > ---------------------------------------------------------------------- > ----------- >=20 >=20 > Chapter 2 Introduction / page 4: >=20 > ... >=20 > Not all the fields in relevant GSMP messages are used by ANCP. This=20 > draft indicates the value that ANCP should set for the fields in these=20 > GSMP messages. >=20 >=20 >=20 > [T.H.:] Note: Implementations which use GSMP and ANCP conventions=20 > before RFC publication must use sub-version 1. [PTT] By definition, pre-standard versions do not conform to the standard, = so this text will have no effect. >=20 > RFC based implementations must use sub-version 2. For details see chapter= 5. >=20 > ... >=20 > ---------------------------------------------------------------------- > -------------- >=20 >=20 > Chapter 5. Access Node Control Protocol (ANCP) / page 15 >=20 > ... >=20 > The 8-bit version field in the base GSMPv3 message header is split=20 > into two 4 bit fields for carrying the version and a sub-version of=20 > the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP=20 > protocol. An ANCP implementation SHOULD always set the version field=20 > to 3, and the sub-version field to 1. The Result field in the message=20 > header has been modified to be 4 bits long, and the Code field to be=20 > 12 bits long. >=20 > Version: >=20 > The version number of the GSMP protocol being used in this session. =20 > ANCP uses version 3. >=20 > Sub-Version: >=20 > The sub-version number of the GSMP protocol being used in this=20 > session. ANCP must use sub-version 2 of the GSMP protocol. [T.H]:Pre=20 > RFC implemtations must use sub-version 1. >=20 [PTT] Same comment as above. >=20 > --------------------------------------------------------------------- >=20 > Chapter 5.1. ANCP/TCP connection establishment / Page 19: >=20 > ... >=20 > NAS listens for incoming connections from the access nodes. Port 6068=20 > is used for TCP connection. Adjacency protocol messages, which are=20 > used to synchronize the NAS and access-nodes and maintain handshakes,=20 > are sent after the TCP connection is established. ANCP messages other=20 > than adjacency protocol messages may be sent only after the adjacency=20 > protocol has achieved synchronization. >=20 > [T.H.]:Note: NAS must detect per peer the sub version and must load=20 > and synchronize with appropriate protocol implementation. >=20 [PTT] I would add "if possible". > ... From wdec@cisco.com Thu Oct 15 02:26:03 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8933F3A6872 for ; Thu, 15 Oct 2009 02:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpAkqKJMKZuq for ; Thu, 15 Oct 2009 02:26:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B1B5D3A67FC for ; Thu, 15 Oct 2009 02:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=5588; q=dns/txt; s=amsiport01001; t=1255598765; x=1256808365; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20[ANCP]=20ANCP=20Protocol=20Versioning |Date:=20Thu,=2015=20Oct=202009=2011:25:58=20+0200 |Message-ID:=20|To:=20"Alan=20Kavanagh"=20,=0D=0A=20=20=20=20=20=20=20=20"Tom=20T aylor"=20,=20, =0D=0A=20=20=20=20=20=20=20=20,=20|Cc:=20,=20,=0D=0A=20=20=20=20=20 =20=20=20"Peter=20Arberg"=20, =20,=0D=0A=20=20=20=20=20=20=20=20,=20,=0D=0A=20=20 =20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<1B6D0317D3AD964FBF3956DEFA3524D 59A582637@EUSAACMS0701.eamcs.ericsson.se>|References:=20< 48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redba ck.com><040201ca1987$008a6670$5728460a@china.huawei.com>< 1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitt e.t-com.de><35815C929B41D2479A224FE098A2722707A2C493@ecam lmw720.eamcs.ericsson.se><786AD2EC3D80A1428B921CDC9BE9EE5 4012ABBE448@USPITMAIL01.ecitele.com>=20<5661758E3E9336468 5B91DD8272F287601B8E2D3@S4DE8PSAAQC.mitte.t-com.de>=20<4A 96DCB7.7060303@rogers.com>=20<1B6D0317D3AD964FBF3956DEFA3 524D59A582637@EUSAACMS0701.eamcs.ericsson.se>; bh=MEeNpPAJBetx0NpYpD8TnHn1G9ASA41ByHGf6Q78k+c=; b=H06uP9WD7j27QXPep+dtLRqU7a+6kSPSpyttlNnSYir00Bhgmf2vooG6 Wm5vwV+4kHJbcmqVmRDSK3IcC3HAuufTZlrGHR6sas2ZrHElifcWxMJAW zXXau4vtmNB+0cabs9h+pAFSD5iyZQ9jNUePy/kbVnnTuTCzGiHQJpc3B I=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAAIaH1kqQ/uCWe2dsb2JhbACbFQEBFiQGpR6YYYIygX4EgVs X-IronPort-AV: E=Sophos;i="4.44,565,1249257600"; d="scan'208";a="51865346" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2009 09:26:03 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9F9Q3qt016227; Thu, 15 Oct 2009 09:26:03 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:26:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 11:25:58 +0200 Message-ID: In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D59A582637@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AconS5rIB3anKyxqRNCdIM6DSrHEVghqTAZgASCxOvA= References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com><040201ca1987$008a6670$5728460a@china.huawei.com><1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de><35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se><786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> <5661758E3E93364685B91DD8272F287601B8E2D3@S4DE8PSAAQC.mitte.t-com.de> <4A96DCB7.7060303@rogers.com> <1B6D0317D3AD964FBF3956DEFA3524D59A582637@EUSAACMS0701.eamcs.ericsson.se> From: "Wojciech Dec (wdec)" To: "Alan Kavanagh" , "Tom Taylor" , , , X-OriginalArrivalTime: 15 Oct 2009 09:26:02.0666 (UTC) FILETIME=[838910A0:01CA4D79] Cc: B.Witschurke@telekom.de, ancp@ietf.org, Peter Arberg , Robert.Rennison@ecitele.com, Peter.Hamacher@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:26:03 -0000 Please note that the text proposed largely has no effect (as also observed by Tom), and is actually worded in normative terms (MUST..., etc). As such I'd advise the editors to use any of the text at their down discretion and likely come up with alternative wording. -Woj. > -----Original Message----- > From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 > Sent: 14 October 2009 19:58 > To: Tom Taylor; HaagT@telekom.de > Cc: Robert.Rennison@ecitele.com; lihy@huawei.com; Peter=20 > Arberg; Wojciech Dec (wdec); swadhwa@juniper.net;=20 > ancp@ietf.org; B.Witschurke@telekom.de; Peter.Hamacher@telekom.de > Subject: RE: [ANCP] ANCP Protocol Versioning >=20 > Hi Tom and Thomas >=20 > From a recent email sent by Woj, I support Thomas Haag's text=20 > as input into the re-edited sections for clarifying the ANCP=20 > Protocol versioning number issue and I agree with Thomas'=20 > proposed text. Additional text is required for clarifying the=20 > Adjacency Protocol negotiation in ANCP as noted by the Woj's email.=20 >=20 > Alan >=20 >=20 > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: August 27, 2009 3:21 PM > To: HaagT@telekom.de > Cc: Robert.Rennison@ecitele.com; Alan Kavanagh;=20 > lihy@huawei.com; Peter Arberg; wdec@cisco.com;=20 > swadhwa@juniper.net; ancp@ietf.org; B.Witschurke@telekom.de;=20 > Peter.Hamacher@telekom.de > Subject: Re: [ANCP] ANCP Protocol Versioning >=20 > Comments below, marked with [PTT]. >=20 > HaagT@telekom.de wrote: > > All, > >=20 > > All exchanged arguments are valid. > >=20 > > I think a protocol draft describes protocol issues, values,=20 > TLV, etc.=20 > > and not network element mechanisms. The challenge now would be to=20 > > cover notes pointing out how to code pre version and RFC version -=20 > > that was agreed last meeting. > >=20 > > But what's missing in that game is a short description that=20 > both peers=20 > > (BRAS & AN) need to identify which SW version to choose=20 > based on sub version value. > > A mechnism in detail for detection and automatic SW load=20 > depending on=20 > > sub version is neccessary. > >=20 > > I'm not sure if that is in scope of a protocol draft or if=20 > it should=20 > > be described seperately. But keeping the time line of=20 > protocol draft=20 > > and avoiding delaying ANCP work it may be desirable to identify=20 > > sections in protocol draft where notes are useful to detail=20 > that issue=20 > > without changing sections and order of the document. > >=20 > >> From my understanding three sections are concerned. I=20 > propose adding=20 > >> the notes at that sections. > >=20 > > Please see below the identified sections and added notes=20 > taken based=20 > > on protocol draft 05 for discussion: > >=20 > > Regards Thomas > >=20 > ---------------------------------------------------------------------- > > ----------- > >=20 > >=20 > > Chapter 2 Introduction / page 4: > >=20 > > ... > >=20 > > Not all the fields in relevant GSMP messages are used by=20 > ANCP. This=20 > > draft indicates the value that ANCP should set for the=20 > fields in these=20 > > GSMP messages. > >=20 > >=20 > >=20 > > [T.H.:] Note: Implementations which use GSMP and ANCP conventions=20 > > before RFC publication must use sub-version 1. >=20 > [PTT] By definition, pre-standard versions do not conform to=20 > the standard, so this text will have no effect. > >=20 > > RFC based implementations must use sub-version 2. For=20 > details see chapter 5. > >=20 > > ... > >=20 > >=20 > ---------------------------------------------------------------------- > > -------------- > >=20 > >=20 > > Chapter 5. Access Node Control Protocol (ANCP) / page 15 > >=20 > > ... > >=20 > > The 8-bit version field in the base GSMPv3 message header is split=20 > > into two 4 bit fields for carrying the version and a sub-version of=20 > > the GSMP protocol. ANCP uses version 3 and sub-version 1=20 > of the GSMP=20 > > protocol. An ANCP implementation SHOULD always set the=20 > version field=20 > > to 3, and the sub-version field to 1. The Result field in=20 > the message=20 > > header has been modified to be 4 bits long, and the Code field to be > > 12 bits long. > >=20 > > Version: > >=20 > > The version number of the GSMP protocol being used in this=20 > session. =20 > > ANCP uses version 3. > >=20 > > Sub-Version: > >=20 > > The sub-version number of the GSMP protocol being used in this=20 > > session. ANCP must use sub-version 2 of the GSMP protocol.=20 > [T.H]:Pre=20 > > RFC implemtations must use sub-version 1. > >=20 > [PTT] Same comment as above. > >=20 > >=20 > --------------------------------------------------------------------- > >=20 > > Chapter 5.1. ANCP/TCP connection establishment / Page 19: > >=20 > > ... > >=20 > > NAS listens for incoming connections from the access nodes.=20 > Port 6068=20 > > is used for TCP connection. Adjacency protocol messages, which are=20 > > used to synchronize the NAS and access-nodes and maintain=20 > handshakes,=20 > > are sent after the TCP connection is established. ANCP=20 > messages other=20 > > than adjacency protocol messages may be sent only after the=20 > adjacency=20 > > protocol has achieved synchronization. > >=20 > > [T.H.]:Note: NAS must detect per peer the sub version and must load=20 > > and synchronize with appropriate protocol implementation. > >=20 > [PTT] I would add "if possible". > > ... >=20 From wdec@cisco.com Thu Oct 15 02:26:08 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652BD3A6879 for ; Thu, 15 Oct 2009 02:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYFp2-vn1R1a for ; Thu, 15 Oct 2009 02:26:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A57193A6860 for ; Thu, 15 Oct 2009 02:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=21127; q=dns/txt; s=amsiport01001; t=1255598766; x=1256808366; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20ANCP=20Versioning=20-=20next=20steps |Date:=20Thu,=2015=20Oct=202009=2011:26:02=20+0200 |Message-ID:=20|To:=20"Alan=20Kavanagh"=20,=20|MIME-Version:=201.0 |In-Reply-To:=20<1B6D0317D3AD964FBF3956DEFA3524D59A582629 @EUSAACMS0701.eamcs.ericsson.se>|References:=20=20<1 B6D0317D3AD964FBF3956DEFA3524D59A582629@EUSAACMS0701.eamc s.ericsson.se>; bh=9EWiMOWYMw/dJa9yX5UevQ/cCSDjaFlVexgzVlNJRLc=; b=EbQRzOi6BeKGSENFhfk9I9Vki/nJ2IlO9VrLvCDVFHfHGVmcf9h4uEba huP37Rk0dvlQrjcBugslY50DB1GM/1D2aysZ4KA0QB34ETGyfUTsZX1C/ 4Y+q4tXAm0FQAS/SzaRENM8ir4OEqxIOWlzLNDh0UJ3AtJ07jtLnB5oJ5 Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIAAIaH1kqQ/uCWe2dsb2JhbACCJy6YQAEBFiQGpR6YYYIygX4EgVs X-IronPort-AV: E=Sophos;i="4.44,565,1249257600"; d="scan'208,217";a="51865345" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2009 09:26:03 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9F9Q3qr016227; Thu, 15 Oct 2009 09:26:03 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:26:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4D79.8349CBCB" Date: Thu, 15 Oct 2009 11:26:02 +0200 Message-ID: In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D59A582629@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Versioning - next steps Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAAmvg1AAJK0TwA== References: <1B6D0317D3AD964FBF3956DEFA3524D59A582629@EUSAACMS0701.eamcs.ericsson.se> From: "Wojciech Dec (wdec)" To: "Alan Kavanagh" , X-OriginalArrivalTime: 15 Oct 2009 09:26:02.0556 (UTC) FILETIME=[837847C0:01CA4D79] Subject: Re: [ANCP] ANCP Versioning - next steps X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:26:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4D79.8349CBCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 14 October 2009 19:50 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: ANCP Versioning - next steps =09 =09 In general i support this way forward by adding "Informative Reference" to the ANCP Protocol Draft when going to WG last call.=20 =20 Just for clarification, what is the reason for not offering guarantess for backward compatibility?=20 =20 Woj> Since there in effect is no standard for v3.1, and there won't be one, it's unclear as to how any form of backwards compatibility could be guaranteed=20 =20 -Woj. =20 Alan ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: October 14, 2009 7:07 AM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =09 =09 =09 =09 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol versioning and the need to revise the protocol version. A follow-up e-mail discussion on the WG alias took place and it seems appropriate now (if not overdue) to draw up a set of recommendations and settle the issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the time of publishing as an RFC. An instruction to execute such a change should be placed as part of an editors' note in the next revision of draft-ietf-ancp-protocol. This instruction is expected to only come into effect at the time of final review past a WG last-call, which means that until then v3.1 will be in evidence. Current implementers should make a note of this fact.[Alan Kavanagh] Agree it makes sense to include the noted change of ANCP Version/Sub-version to 3.2 and agree that this should be captured in the current draft as an editors note.=20 - Another note (not editorial though) should be placed in an appropriate section, possibly Section 2 or Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) based on early versions of the ANCP protocol draft. The note should be clear in offering no guarantees in terms of backwards compatibility of the RFC spec to those early-draft implementations. The note must also not be seen as passing a normative reference to the early protocol draft. [Alan Kavanagh] Agree an Normative Reference should note the reason for change from 3.1 to 3.2 and I support the recommendation here, the most appropiate section i believe is Section 5 imho. - Along with the above note, the existing GSMP/ANCP version negotiation mechanisms could be highlighted, indicating that it provides a way to distinguish between the different versions if the adjacency establishment negotiation mechanism followed by all is as per GSMPv3 (rfc3292). [Alan Kavanagh] Agree, though RFC 3292 does not have sub-version. - For the sake of clarity it is recommended that the adjacency negotiation be more fully described in the ANCP protocol draft instead of the current reference to rfc3292. Specifically, it would appear reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-edit describing the version negotiation behaviour.=20 [Alan Kavanagh] Agree, and this is what I proposed sometime back, though 3292 does currently not cover sub-version and this must be covered in the re-edited section to be included in the ancp protocol spec, For clarification, what is your recommendation for the adjacency negotiation? Is it to include the sub-version also?. Rather confusingly Rfc3292 Section 11.2 does not carry text or logic statements as to the expected behaviour in case of version differences, but such text is in evidence in the descriptive part of Section 11.1.[Alan Kavanagh] Therefore are you noting we should include text in the ANCP protocol draft as to what expected behaviour should be in the event of Version/sub-version differences?=20 - The WG should identify what version of the ANCP protocol draft specification constitutes v3.1. A non-normative reference to such a reference could be passed in the v3.2 spec. Rationale=20 From a technical point of view, given that a "current" (i.e. draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, with any newly added functions covered as negotiable capabilities, the version change does not appear to be fully warranted and not fully in line with the guidelines previously laid down (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html ). That said, from an operational perspective a reasonable case for such a version change has made based and presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docum ent.htm .=20 Now, given that normative compliance to an interim draft (such as draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text which may be perceived as mandating or claiming compatibility to such interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and have plans for v3.2, the version negotiation mechanism that ANCP inherited from GSMPv3 provides a way to disambiguate the two protocols and thus allows in theory for supporting running a pre-standard (v3.1) and a standards compliant v3.2 on any given ANCP node. [Alan Kavanagh] Agree, will this be noted in the ANCP protocol draft as opposed to a reference pointer to RFC3292? The issue of where v3.1 is documented can be solved by using non-normative references to one of the interim drafts. The issue of what rev of draft-ietf-ancp is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending the protocol spec to cover issues around protocol version negotiation or remediation of incompatibilities of draft implementations. As such no such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 ------_=_NextPart_001_01CA4D79.8349CBCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: ANCP Versioning - next steps
 

From: Alan Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]
Sent: 14 October 2009=20 19:50
To: Wojciech Dec (wdec); = ancp@ietf.org
Subject: RE:=20 ANCP Versioning - next steps

In general i support this way forward by = adding=20 "Informative Reference" to the ANCP Protocol Draft when going to = WG last=20 call. 
 
Just for = clarification, what is=20 the reason for not offering guarantess for backward = compatibility? 
 
Woj> Since there = in effect is=20 no standard for v3.1, and there won't be one, it's unclear as to = how any=20 form of backwards compatibility could be=20 guaranteed 
 
-Woj.
=
 
Alan

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: October 14, 2009 7:07 AM
To:=20 ancp@ietf.org
Subject: [ANCP] FW: ANCP Versioning - next=20 steps


Hi = All,

During the ITEF75 WG = meeting a=20 discussion was had on ANCP protocol versioning and the need to revise = the=20 protocol version. A follow-up e-mail discussion on the WG alias took = place and=20 it seems appropriate now (if not=20 overdue) to draw up a set of = recommendations=20 and settle the issue:

Recommended = protocol draft=20 changes and = WG=20 actions

- The = currently used ANCP=20 version 3.1 is to change to 3.2 at the time of publishing as an RFC. = An=20 instruction to execute such a change should be placed as part of an = editors'=20 note in the next revision of draft-ietf-ancp-protocol. This = instruction is=20 expected to only come into effect at the time of final review past a = WG=20 last-call, which means that until then v3.1 will be in evidence. = Current=20 implementers should make a note of this fact.[Alan=20 Kavanagh] Agree it makes sense to include the noted = change of=20 ANCP Version/Sub-version to 3.2 and agree that this should be captured = in the=20 current draft as an editors = note. 

- Another note = (not=20 editorial though) should be placed in an appropriate section, possibly = Section=20 2 or Section 5, to convey in-brief the historic aspect of GSMP/ANCP = v3.1=20 implementations, which are (were?) based on early versions of the ANCP = protocol draft. The note should be clear in offering no guarantees in = terms of=20 backwards compatibility of the RFC spec to those early-draft = implementations.=20 The note must also not be seen as passing a normative reference to the = early=20 protocol draft. [Alan=20 Kavanagh]  Agree an Normative Reference should note the = reason=20 for change from 3.1 to 3.2 and I support the recommendation here, the = most=20 appropiate section i believe is Section 5=20 imho.

- Along with = the above note,=20 the existing GSMP/ANCP version negotiation mechanisms could be = highlighted,=20 indicating that it provides a way to distinguish between the different = versions if the adjacency establishment negotiation mechanism followed = by all=20 is as per GSMPv3 (rfc3292).
[Alan Kavanagh]  Agree, though RFC 3292 does = not have=20 sub-version.

- For the sake = of clarity it=20 is recommended that the adjacency negotiation be more fully described = in the=20 ANCP protocol draft instead of the current reference to rfc3292. = Specifically,=20 it would appear reasonable to adopt and re-edit Section 11.2 of = rfc3292 into=20 the ANCP protocol spec, with the re-edit describing the version = negotiation=20 behaviour.
[Alan=20 Kavanagh] Agree, and this is what I proposed sometime = back, though=20 3292 does currently not cover sub-version and this must be covered in = the=20 re-edited section to be included in the ancp protocol spec, For = clarification,=20 what is your recommendation for the adjacency negotiation? Is it to = include=20 the sub-version also?. Rather confusingly Rfc3292 = Section=20 11.2 does not carry text or logic statements as to the expected = behaviour in=20 case of version differences, but such text is in evidence in the = descriptive=20 part of Section 11.1.[Alan=20 Kavanagh]  Therefore are you noting we should include text = in the=20 ANCP protocol draft as to what expected behaviour should be in the = event of=20 Version/sub-version = differences? 

- = The WG should=20 identify what version of the ANCP protocol draft specification = constitutes=20 v3.1. A non-normative reference to such a reference could be passed in = the=20 v3.2 spec.

Rationale=20

From a technical = point of view,=20 given that a "current" (i.e. draft-ietf-protocol-06 based) and=20 future (i.e. = ANCP RFC=20 based) protocols are identical, = with=20 any newly = added functions covered = as negotiable=20 capabilities, the version change=20 does not appear to be fully warranted and not=20 fully in line with the guidelines previously laid down = (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html<= /FONT>). That said, from = an operational perspective=20 a reasonable case for such=20 a version change has made based = and = presented in=20 https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/= v3_document.htm.

Now, = given that normative compliance to an interim = draft=20 (such as = draft-ietf-protocol-06=20 based) cannot be passed by the ANCP = RFC, text=20 which may = be perceived as mandating or claiming compatibility to = such  interim = drafts needs to be avoided.

In the case = of vendors and=20 operators that already support/use v3.1 and have plans for = v3.2, the=20 version negotiation mechanism that ANCP inherited from GSMPv3 provides = a way=20 to disambiguate the two protocols and thus allows = in theory for supporting running a = pre-standard (v3.1) and=20 a standards compliant v3.2 on any given ANCP node. [Alan Kavanagh]  = Agree, will=20 this be noted in the ANCP protocol draft as opposed to a reference = pointer to=20 RFC3292? The issue of where = v3.1 is=20 documented can be solved by using non-normative references to one of = the=20 interim drafts. The issue of what rev of draft-ietf-ancp is considered = to be=20 v3.1 needs to be clarified.

Other than the above = the WG is=20 currently not chartered to=20 be extending the protocol spec to = cover issues=20 around protocol version negotiation or remediation of = incompatibilities of=20 draft implementations. As such no=20 such work is expected.

We = welcome=20 clarification questions on the above.

Regards,
Wojciech & Matthew. =

------_=_NextPart_001_01CA4D79.8349CBCB-- From alan.kavanagh@ericsson.com Thu Oct 15 07:53:14 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2783A685B for ; Thu, 15 Oct 2009 07:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmtnksTTk9jw for ; Thu, 15 Oct 2009 07:53:13 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B8B483A67F5 for ; Thu, 15 Oct 2009 07:53:13 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9FErDl6002241; Thu, 15 Oct 2009 09:53:16 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 09:52:17 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 09:52:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 15 Oct 2009 10:52:16 -0400 From: Alan Kavanagh To: Maglione Roberta , "ancp@ietf.org" Date: Thu, 15 Oct 2009 10:52:15 -0400 Thread-Topic: Proposal to use Tech Type 0x01 for PON Thread-Index: AcpLQ9Cc5wovaia5TCKpN5+DrgsGJAAXA64AAA7Y/NAAcu6hsA== Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D59A582A29@EUSAACMS0701.eamcs.ericsson.se> References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FE5@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E670E7FE5@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Oct 2009 14:52:16.0996 (UTC) FILETIME=[16BECA40:01CA4DA7] Subject: Re: [ANCP] Proposal to use Tech Type 0x01 for PON X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 14:53:14 -0000 Hi Roberta I support this change. Alan=20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Mag= lione Roberta Sent: October 13, 2009 4:08 AM To: ancp@ietf.org Subject: [ANCP] Proposal to use Tech Type 0x01 for PON Hi All, Fortune suggested allocating Tech Type 0x01 for PON technology. Today = the only value used for Tech Type is 0x05 for DSL. Does anybody see any problem with this proposal? If not I'm going to make t= his change and include it in version 07 of the protocol draft. Please let me know. Thanks and best regards. Roberta -----Original Message----- From: Fortune HUANG [mailto:fqhuang@huawei.com] Sent: Tuesday, October 13, 2009 3:05 AM To: Maglione Roberta; 'Tom Taylor'; 'Francois Le Faucheur'; HaagT@telekom.d= e; swadhwa@juniper.net Cc: 'Dec Wojciech'; 'BOCCI Matthew' Subject: RE: New version of ancp-protocol draft Hi Roberta, Thanks for releasing the used values 0x01 - 0x04 Tech Type. I also suggest allocating a Tech Type (e.g. 0x01) for PON in this -07 draft= directly, as this is an obvious requirement. Or else we may need to do tha= t in a -08 or later draft. Best regards, Fortune Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From wwwrun@core3.amsl.com Thu Oct 15 09:35:08 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 17A773A68A6; Thu, 15 Oct 2009 09:35:07 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091015163508.17A773A68A6@core3.amsl.com> Date: Thu, 15 Oct 2009 09:35:08 -0700 (PDT) Cc: Internet Architecture Board , ancp mailing list , ancp chair , RFC Editor Subject: [ANCP] Document Action: 'Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)' to Informational RFC X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 16:35:08 -0000 The IESG has approved the following document: - 'Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) ' as an Informational RFC This document is the product of the Access Node Control Protocol Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-08.txt Technical Summary The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. This document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. Working Group Summary The origin of the working group can be traced back to the WT-147 "Layer 2 Control Protocol" document from the Broadband Forum. The ANCP protocol being developed in the ANCP working group as a result of that document is typically used in the access and aggregation portions of a broadband access network, and also in inter-provider environments. It was therefore decided as a part of the creation of the working group to document the security threats that this protocol could encounter to ensure that they were fully accounted for in the protocol design and that operators deploying the protocol were aware of any security threats. This draft is the result of that work. Document Quality The document is a security threats analysis, with the protocol being specified in a separate WG draft (draft-ietf-ancp-protocol). The latter has a number of implementations. Personnel Document Shepherd: Matthew Bocci (matthew.bocci@alcatel-lucent.com) Responsible Area Director? Ralph Droms (rdroms@cisco.com) From shrirao@cisco.com Sat Oct 17 13:33:13 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C883A3A6839 for ; Sat, 17 Oct 2009 13:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp8n7toeavVm for ; Sat, 17 Oct 2009 13:33:12 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 73C283A6996 for ; Sat, 17 Oct 2009 13:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shrirao@cisco.com; l=691; q=dns/txt; s=sydiport01001; t=1255811601; x=1257021201; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Shridhar=20Rao=20(shrirao)"=20|Subject:=20RE:=20[ANCP]=20Agenda=20items=20for=20IETF7 6=20ANCP=20WG=20meeting|Date:=20Sun,=2018=20Oct=202009=20 02:03:10=20+0530|Message-ID:=20|To:=20"Wojciech=20De c=20(wdec)"=20,=20|Cc:=20" Alexandre=20Cassen"=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20; bh=V5fl9Q15a53kxm/JNtFj5Z+xG/zzdWNiyn8dhLqjZBw=; b=FwtdR4uy+RtMgibTjBGbBhKyukvJ1Vr3inPSMG4H8fjZGj3obfyvItv4 moJ87tdmm5DIhw1MzoRVPW2JrDRgsQZ8fbs4BJDgqWi+efVlZSafY0tRa yOnXyK0LW6n//rjpu8F3oh3Jur5sSApBVWG3Tv1yHPXwS/+ruOrpQwoc2 Y=; Authentication-Results: syd-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACvG2UpAaHte/2dsb2JhbAC/DZcyhDEEgVtr X-IronPort-AV: E=Sophos;i="4.44,578,1249257600"; d="scan'208";a="62309769" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by syd-iport-1.cisco.com with ESMTP; 17 Oct 2009 20:33:17 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9HKXDwm020315; Sat, 17 Oct 2009 20:33:14 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Oct 2009 02:03:14 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Oct 2009 02:03:10 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF76 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNgARVzr+A= References: From: "Shridhar Rao (shrirao)" To: "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 17 Oct 2009 20:33:14.0067 (UTC) FILETIME=[0CEF9A30:01CA4F69] Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 20:33:13 -0000 Hi Woj, We like to request a slot for discussing the graceful restart extension draft to ANCP (a draft is submitted to IETF). Thanks, Shridhar & Alexandre =20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday, October 12, 2009 1:28 PM To: ancp@ietf.org Subject: [ANCP] Agenda items for IETF76 ANCP WG meeting Hi All, We're taking requests for agenda slots at our next ANCP WG meeting in Hiroshima. Please respond with any requests. Thanks, Matthew & Woj _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From shrirao@cisco.com Sat Oct 17 13:44:50 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E1E3A63D3 for ; Sat, 17 Oct 2009 13:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVtxxIMfQMxj for ; Sat, 17 Oct 2009 13:44:49 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id A14EB3A635F for ; Sat, 17 Oct 2009 13:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shrirao@cisco.com; l=1025; q=dns/txt; s=sydiport01001; t=1255812296; x=1257021896; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Shridhar=20Rao=20(shrirao)"=20|Subject:=20RE:=20[ANCP]=20Agenda=20items=20for=20IETF7 6=20ANCP=20WG=20meeting|Date:=20Sun,=2018=20Oct=202009=20 02:14:47=20+0530|Message-ID:=20|To:=20"Shridhar=20Ra o=20(shrirao)"=20,=0D=0A=20=20=20=20 =20=20=20=20"Wojciech=20Dec=20(wdec)"=20, =20|Cc:=20"Alexandre=20Cassen"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |References:=20=20; bh=i+8+rpvyr5X/lnXZFm82ujdQZ6e5GTivgtGtIRJUnAk=; b=EjFx6e18BEXXR+nPWD3Zs+JBgwd992l5NtZoyJjcxa5iLL6+RA6U0w+U teGwy+RXgxxhp/1VAgMzqRm+VtewOTSUie1O1BEQihdPrSAGvS++J/2Gc o9if4/MOIQN6Bd0n0FihW4sLixX//3KLq+cO/ueURT6oHgmQf9JF1ZIGo Y=; Authentication-Results: syd-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF3H2UpAaHte/2dsb2JhbAC/EpczhDEEgVtr X-IronPort-AV: E=Sophos;i="4.44,578,1249257600"; d="scan'208";a="62310153" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by syd-iport-1.cisco.com with ESMTP; 17 Oct 2009 20:44:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9HKikwn021936; Sat, 17 Oct 2009 20:44:51 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Oct 2009 02:14:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Oct 2009 02:14:47 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF76 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNgARVzr+AAAMHlIA== References: From: "Shridhar Rao (shrirao)" To: "Shridhar Rao (shrirao)" , "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 17 Oct 2009 20:44:51.0687 (UTC) FILETIME=[ACBFF770:01CA4F6A] Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 20:44:50 -0000 Here's the link to the draft : http://www.ietf.org/id/draft-ancp-restart-00.txt=20 Thanks, -shridhar- -----Original Message----- From: Shridhar Rao (shrirao)=20 Sent: Sunday, October 18, 2009 2:03 AM To: Wojciech Dec (wdec); ancp@ietf.org Cc: Alexandre Cassen Subject: RE: [ANCP] Agenda items for IETF76 ANCP WG meeting Hi Woj, We like to request a slot for discussing the graceful restart extension draft to ANCP (a draft is submitted to IETF). Thanks, Shridhar & Alexandre =20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday, October 12, 2009 1:28 PM To: ancp@ietf.org Subject: [ANCP] Agenda items for IETF76 ANCP WG meeting Hi All, We're taking requests for agenda slots at our next ANCP WG meeting in Hiroshima. Please respond with any requests. Thanks, Matthew & Woj _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From roberta.maglione@telecomitalia.it Mon Oct 19 07:17:24 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4244A3A67BD for ; Mon, 19 Oct 2009 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.013 X-Spam-Level: *** X-Spam-Status: No, score=3.013 tagged_above=-999 required=5 tests=[AWL=-1.502, BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXniPRi4a6XW for ; Mon, 19 Oct 2009 07:16:26 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 712943A6836 for ; Mon, 19 Oct 2009 07:16:22 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 19 Oct 2009 16:16:25 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Mon, 19 Oct 2009 16:16:25 +0200 From: Maglione Roberta To: "'Wojciech Dec (wdec)'" , "ancp@ietf.org" , "HaagT@telekom.de" , "alan.kavanagh@ericsson.com" , "Robert.Rennison@ecitele.com" , "swadhwa@juniper.net" , BOCCI Matthew , "'tom111.taylor@bell.net'" Date: Mon, 19 Oct 2009 16:16:24 +0200 Thread-Topic: ANCP Versioning - next steps Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local> References: In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: multipart/mixed; boundary="_004_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_" MIME-Version: 1.0 Subject: Re: [ANCP] ANCP Versioning - next steps X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:17:24 -0000 --_004_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I updated the ancp protocol draft following the chairs' recommendation= s on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end of = section 2: "At the time of writing of this specification some implementations of the = ANCP protocol, based on pre-standards drafts are already available. All th= ese early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations." 1. I explained the version/sub-version negotiation process in section 5.2= : "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP version/s= ub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields." 1. I added a non-normative appendix. This appendix will contain a clarifi= cation of what version of the ANCP protocol draft specification constitutes= version 3.1 as soon as the WG decides on 3.1 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol This appendix is non normative. Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved." Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or if y= ou have additional comments please let me know. Best Regards, Roberta ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps Hi All, During the ITEF75 WG meeting a discussion was had on ANCP protocol versioni= ng and the need to revise the protocol version. A follow-up e-mail discussi= on on the WG alias took place and it seems appropriate now (if not overdue)= to draw up a set of recommendations and settle the issue: Recommended protocol draft changes and WG actions - The currently used ANCP version 3.1 is to change to 3.2 at the time of pu= blishing as an RFC. An instruction to execute such a change should be place= d as part of an editors' note in the next revision of draft-ietf-ancp-proto= col. This instruction is expected to only come into effect at the time of f= inal review past a WG last-call, which means that until then v3.1 will be i= n evidence. Current implementers should make a note of this fact. - Another note (not editorial though) should be placed in an appropriate se= ction, possibly Section 2 or Section 5, to convey in-brief the historic asp= ect of GSMP/ANCP v3.1 implementations, which are (were?) based on early ver= sions of the ANCP protocol draft. The note should be clear in offering no g= uarantees in terms of backwards compatibility of the RFC spec to those earl= y-draft implementations. The note must also not be seen as passing a normat= ive reference to the early protocol draft. - Along with the above note, the existing GSMP/ANCP version negotiation mec= hanisms could be highlighted, indicating that it provides a way to distingu= ish between the different versions if the adjacency establishment negotiati= on mechanism followed by all is as per GSMPv3 (rfc3292). - For the sake of clarity it is recommended that the adjacency negotiation = be more fully described in the ANCP protocol draft instead of the current r= eference to rfc3292. Specifically, it would appear reasonable to adopt and = re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-ed= it describing the version negotiation behaviour. Rather confusingly Rfc3292= Section 11.2 does not carry text or logic statements as to the expected be= haviour in case of version differences, but such text is in evidence in the= descriptive part of Section 11.1. - The WG should identify what version of the ANCP protocol draft specificat= ion constitutes v3.1. A non-normative reference to such a reference could b= e passed in the v3.2 spec. Rationale >From a technical point of view, given that a "current" (i.e. draft-ietf-pro= tocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, w= ith any newly added functions covered as negotiable capabilities, the versi= on change does not appear to be fully warranted and not fully in line with = the guidelines previously laid down (http://www.ietf.org/mail-archive/web/a= ncp/current/msg00152.html). That said, from an operational perspective a re= asonable case for such a version change has made based and presented in htt= ps://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.ht= m. Now, given that normative compliance to an interim draft (such as draft-iet= f-protocol-06 based) cannot be passed by the ANCP RFC, text which may be pe= rceived as mandating or claiming compatibility to such interim drafts need= s to be avoided. In the case of vendors and operators that already support/use v3.1 and have= plans for v3.2, the version negotiation mechanism that ANCP inherited from= GSMPv3 provides a way to disambiguate the two protocols and thus allows in= theory for supporting running a pre-standard (v3.1) and a standards compli= ant v3.2 on any given ANCP node. The issue of where v3.1 is documented can = be solved by using non-normative references to one of the interim drafts. T= he issue of what rev of draft-ietf-ancp is considered to be v3.1 needs to b= e clarified. Other than the above the WG is currently not chartered to be extending the = protocol spec to cover issues around protocol version negotiation or remedi= ation of incompatibilities of draft implementations. As such no such work i= s expected. We welcome clarification questions on the above. Regards, Wojciech & Matthew. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: ANCP Versioning - next steps

Hi = All,

&nb= sp;    I updated the ancp protocol draft following the chair= s’ recommendations on the ANCP versioning.

In = particular:

  1. I added some text to explain the history and rationale, at the = end of section 2:

 “At the time of writing of this specification some implementations of the ANCP= protocol, based on pre-standards drafts are already available.  All t= hese early-draft implementations use protocol

   version/sub-version 3.1; standard ANCP protocol wi= ll use version/

   sub-version 3.2 [Editor's note: sub-version needs = to be changed from

   1 to 2 upon publication.]  Adopting a new sub= -version value provides

   a way to disambiguate the two protocols and allows= for supporting

   running a pre-standard and a standards compliant A= NCP implementation

   on any given ANCP node.  The mechanism used t= o identify the protocol

   version/sub-version is part of the adjacency negot= iation process and

   it is described in details in Section 5.2.  I= t is important to note

   that this mechanism does not guarantee backwards c= ompatibility of the

   ANCP RFC specification to those early-draft implem= entations.”

  1. I explained the version/sub-version negotiation process in sect= ion 5.2:<= /o:p>

“ANCP uses version 3 and sub-version 1 of GSMP protocol.<= o:p>

   [RFC Editor's note: sub-version needs to be change= d from 1 to 2 upon

   publication.]  In the adjacency protocol the = version and the sub-

   version fields are used for version negotiation.&n= bsp; The version

   negotiation is performed before synchronisation is= achieved.  In a

   SYN message the version/sub-version fields always = contain the highest

   version understood by the sender.  A receiver= receiving a SYN message

   with a version/sub-version higher than understood = will ignore that

   message.  A receiver receiving a SYN message = with a version/

   sub-vresion lower than its own highest version/sub= -version, but a

   version/sub-version that it understands, will repl= y with a SYNACK

   with the version/sub-version from the received SYN= in its ANCP version/sub-version fields.  This defines the version/sub-version of

   the ANCP protocol to be used while the adjacency p= rotocol remains

   synchronised.  All other messages will use th= e agreed version in the

   version/sub-version fields.”

 

  1. I added a non-normative appendix. This appendix will contain a clarifica= tion of what version of the ANCP protocol draft specification constitutes v= ersion 3.1 as soon as the WG decides on 3.1

“6.  Appendix: Handling of pre-RFC deployments of th= e ANCP  protocol

 

   This appendix is non normative.<= /font>

 

   Prior to completion of this document, several pre-= RFC versions of the

   protocol were documented and implemented.  Th= ere were numerous pre-

   standard versions of the protocol all using a vers= ion/sub-version

   fields set to 3.1.

 

   A NAS implementing the ANCP protocol as defined in= this document may,

   on a peer basis, use the version and sub-version f= ields to detect a

   pre-RFC implementation of the protocol and choose = to work with such

   pre-RFC peers.  The version and sub-version n= egotiation phase is part

   of the adjacency protocol and is performed before = synchronisation is

   achieved.”

 

Please find new version of draft attached.

I hope I’ve captured most of your feedback in the new dra= ft, if not or if you have additional comments please let me know.

 

Best Regards,

Roberta

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, October 14,= 2009 1:07 PM
To: ancp@ietf.org
Subject: [ANCP] FW: ANCP Ver= sioning - next steps

 

 

Hi All,

During the ITEF75 WG meeting a discussion was had on ANCP protocol v= ersioning and the need to revise the protocol version. A follow-up e-mail d= iscussion on the WG alias took place and it seems appropriate now (if not overdue) to draw up a set of re= commendations and settle the issue:

Recommended protocol draft changes and WG actions=

- The currently used ANCP version 3.1 is to change to 3.2 at the tim= e of publishing as an RFC. An instruction to execute such a change should b= e placed as part of an editors' note in the next revision of draft-ietf-ancp-protocol. This in= struction is expected to only come into effect at the time of final review = past a WG last-call, which means that until then v3.1 will be in evidence. = Current implementers should make a note of this fact.

- Another note (not editorial though) should be placed in an appropr= iate section, possibly Section 2 or Section 5, to convey in-brief the histo= ric aspect of GSMP/ANCP v3.1 implementations, which are (were?) based on early versions of the ANC= P protocol draft. The note should be clear in offering no guarantees in ter= ms of backwards compatibility of the RFC spec to those early-draft implemen= tations. The note must also not be seen as passing a normative reference to the early protocol draft.

- Along with the above note, the existing GSMP/ANCP version negotiat= ion mechanisms could be highlighted, indicating that it provides a way to d= istinguish between the different versions if the adjacency establishment negotiation mechanis= m followed by all is as per GSMPv3 (rfc3292).

- For the sake of clarity it is recommended that the adjacency negot= iation be more fully described in the ANCP protocol draft instead of the cu= rrent reference to rfc3292. Specifically, it would appear reasonable to adopt and re-edit Sec= tion 11.2 of rfc3292 into the ANCP protocol spec, with the re-edit describi= ng the version negotiation behaviour. Rather confusingly Rfc3292 Section 11= .2 does not carry text or logic statements as to the expected behaviour in case of version differences, bu= t such text is in evidence in the descriptive part of Section 11.1.<= /font>

- The WG should identify what version of the= ANCP protocol draft specification constitutes v3.1. A non-normative refere= nce to such a reference could be passed in the v3.2 spec.

Rationale

From a technical point of view, given that a "current" (i.e. draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, with any<= /font> newly added functions covered as negotiable capabilities, the version change does not appear = to be fully warranted and not fully in line with the guidelin= es previously laid down (http://www.i= etf.org/mail-archive/web/ancp/current/msg00152.html). That said, from an opera= tional perspective a reasonable case for such= a version change has<= /font> made based and present= ed in https://svn.tools.ietf.org/a= genda/75/slides/ancp-3/ancp-3_files/v3_document.htm.

Now, gi= ven that normative compliance to an interim draft (suc= h as draft-ietf-protocol-06<= span style=3D"color:black"> based) cannot be passed by the ANCP RFC, text which may<= /font> be perceived as mandating or claiming compatibili= ty to such  interim drafts= needs to be avoided.

In the case of vendors and operators that= already support/use v3.1 and have plans for v= 3.2, the version negotiation mechanism that ANCP inherited from GSMPv3 prov= ides a way to disambiguate the two protocols and thus allows in theory for supporting running a pre-standard (v3.1) and a standards com= pliant v3.2 on any given ANCP node. The issue of where v3.1 i= s documented can be solved by using non-normative references to one of the = interim drafts. The issue of what rev of draft-ietf-ancp is considered to b= e v3.1 needs to be clarified.

Other than the above the WG is currently not chartered to be extending the protocol spec to cover issues around protocol version ne= gotiation or remediation of incompatibilities of draft implementations. As such no such work is expected.

We welcome clarification questions on the ab= ove.

Regards,
Wojciech & Mat= thew.

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_-- --_004_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_ Content-Type: text/plain; name="draft-ietf-ancp-protocol-07.txt" Content-Description: draft-ietf-ancp-protocol-07.txt Content-Disposition: attachment; filename="draft-ietf-ancp-protocol-07.txt"; size=128652; creation-date="Mon, 12 Oct 2009 11:57:39 GMT"; modification-date="Mon, 19 Oct 2009 15:57:27 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTLiAgV2FkaHdhCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gTW9pc2FuZApJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gU3VicmFtYW5pYW4KRXhwaXJl czogQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVy IE5ldHdvcmtzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBULiAgSGFhZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULXN5c3RlbXMKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4uIFZvaWd0 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgU2llbWVucwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUi4gTWFnbGlvbmUKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRlbGVjb20gSXRhbGlhCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAy MiwgMjAwOQoKCiAgICBQcm90b2NvbCBmb3IgQWNjZXNzIE5vZGUgQ29udHJvbCBNZWNoYW5pc20g aW4gQnJvYWRiYW5kIE5ldHdvcmtzCiAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWFu Y3AtcHJvdG9jb2wtMDcKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgaXMgc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBw cm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3Jj ZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdAog ICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRp bWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJl bmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHBy b2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBh Y2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQu CgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJl IGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlz IEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDI1LCAyMDEwLgoKQ29weXJpZ2h0 IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDA5IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25z IGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2Vy dmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYg VHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIGlu IGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50ICho dHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pLgogICBQbGVhc2UgcmV2aWV3IHRo ZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMKCgoK IFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90 b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgYW5kIHJlc3RyaWN0aW9ucyB3 aXRoIHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4KCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBwcm9wb3NlZCBleHRlbnNpb25zIHRvIHRoZSBHU01QdjMgcHJvdG9jb2wgdG8K ICAgYWxsb3cgaXRzIHVzZSBpbiBhIGJyb2FkYmFuZCBlbnZpcm9ubWVudCwgYXMgYSBjb250cm9s IHBsYW5lIGJldHdlZW4KICAgQWNjZXNzIE5vZGVzIChlLmcuICBEU0xBTSkgYW5kIEJyb2FkYmFu ZCBOZXR3b3JrIEdhdGV3YXlzIChlLmcuCiAgIE5BUykuICBUaGVzZSBwcm9wb3NlZCBleHRlbnNp b25zIGFyZSByZXF1aXJlZCB0byByZWFsaXplIGEgcHJvdG9jb2wKICAgZm9yICJBY2Nlc3MgTm9k ZSBDb250cm9sIiBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluIFtBTkNQLUZSQU1FV09SS10uCiAg IFRoZSByZXN1bHRpbmcgcHJvdG9jb2wgd2l0aCB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucyB0byBH U01QdjMKICAgW1JGQzMyOTJdIGlzIHJlZmVycmVkIHRvIGFzICJBY2Nlc3MgTm9kZSBDb250cm9s IFByb3RvY29sIiAoQU5DUCkuCiAgIFRoaXMgZG9jdW1lbnQgY3VycmVudGx5IGZvY3VzZXMgb24g c3BlY2lmaWMgdXNlIGNhc2VzIG9mIGFjY2VzcyBub2RlCiAgIGNvbnRyb2wgbWVjaGFuaXNtIGZv ciB0b3BvbG9neSBkaXNjb3ZlcnksIGxpbmUgY29uZmlndXJhdGlvbiwgYW5kIE9BTQogICBhcyBk ZXNjcmliZWQgaW4gQU5DUCBmcmFtZXdvcmsgZG9jdW1lbnQgW0FOQ1AtRlJBTUVXT1JLXS4gIEl0 IGlzCiAgIGludGVuZGVkIHRvIGJlIGF1Z21lbnRlZCBieSBhZGRpdGlvbmFsIHByb3RvY29sIHNw ZWNpZmljYXRpb24gZm9yCiAgIGZ1dHVyZSB1c2UgY2FzZXMgY29uc2lkZXJlZCBpbiBzY29wZSBi eSB0aGUgQU5DUCBjaGFydGVyLgoKICAgQU5DUCBmcmFtZXdvcmsgZG9jdW1lbnQgW0FOQ1AtRlJB TUVXT1JLXSBkZXNjcmliZXMgdGhlIEFOQ1AgdXNlLWNhc2VzCiAgIGluIGRldGFpbC4gIElsbHVz dHJhdGl2ZSB0ZXh0IGZvciB0aGUgdXNlLWNhc2VzIGlzIGluY2x1ZGVkIGhlcmUgdG8KICAgaGVs cCB0aGUgcHJvdG9jb2wgaW1wbGVtZW50ZXIgdW5kZXJzdGFuZCB0aGUgZ3JlYXRlciBjb250ZXh0 IG9mIEFOQ1AKICAgcHJvdG9jb2wgaW50ZXJhY3Rpb25zLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAg ICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBh bmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgpUYWJsZSBvZiBDb250 ZW50cwoKICAgMS4gIFNwZWNpZmljYXRpb24gUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDIuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDIuMS4gIFRlcm1pbm9s b2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAg My4gIEJyb2FkYmFuZCBBY2Nlc3MgQWdncmVnYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA2CiAgICAgMy4xLiAgQVRNLWJhc2VkIGJyb2FkYmFuZCBhZ2dyZWdhdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDMuMi4gIEV0aGVybmV0LWJhc2VkIGJy b2FkYmFuZCBhZ2dyZWdhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgNC4gIEFjY2Vz cyBOb2RlIENvbnRyb2wgUHJvdG9jb2wgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA3CiAgICAgNC4xLiAgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOAogICAgIDQuMi4gIEFOQ1AgYmFzZWQgQWNjZXNzIFRvcG9sb2d5 IERpc2NvdmVyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICAgIDQuMi4xLiAgR29hbHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAg ICA0LjIuMi4gIE1lc3NhZ2UgRmxvdyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgOQogICAgIDQuMy4gIEFOQ1AgYmFzZWQgTGluZSBDb25maWd1cmF0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgICAgIDQuMy4xLiAgR29hbHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgICA0LjMuMi4g IE1lc3NhZ2UgRmxvdyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx MQogICAgIDQuNC4gIEFOQ1AgYmFzZWQgT0FNIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTMKICAgICAgIDQuNC4xLiAgTWVzc2FnZSBGbG93IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgIDUuICBBY2Nlc3MgTm9kZSBDb250 cm9sIFByb3RvY29sIChBTkNQKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICAgIDUu MS4gIEFOQ1AvVENQIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjAKICAgICA1LjIuICBBTkNQIENvbm5lY3Rpb24ga2VlcGFsaXZlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIxCiAgICAgNS4zLiAgQ2FwYWJpbGl0eSBuZWdvdGlhdGlv biAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMgogICAgIDUuNC4gIEdTTVAg TWVzc2FnZSBFeHRlbnNpb25zIGZvciBBY2Nlc3MgTm9kZSBDb250cm9sICAuIC4gLiAuIC4gMjUK ICAgICAgIDUuNC4xLiAgR2VuZXJhbCBFeHRlbnNpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDI1CiAgICAgICA1LjQuMi4gIFRvcG9sb2d5IERpc2NvdmVyeSBFeHRlbnNp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNgogICAgICAgNS40LjMuICBMaW5lIENvbmZp Z3VyYXRpb24gRXh0ZW5zaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYKICAgICAgIDUu NC40LiAgT0FNIEV4dGVuc2lvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDM5CiAgICAgICA1LjQuNS4gIEFkZGl0aW9uYWwgR1NNUCBFeHRlbnNpb25zIGZvciBmdXR1 cmUgdXNlIGNhc2VzICAuIC4gLiA0MgogICAgICAgICA1LjQuNS4xLiAgR2VuZXJhbCB3ZWxsIGtu b3duIFRMVnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDMKICAgICAgICAgICA1LjQuNS4x LjEuICBUYXJnZXQgVExWIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQzCiAg ICAgICAgICAgNS40LjUuMS4yLiAgQ29tbWFuZCBUTFYgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA0NAogICAgICAgICAgIDUuNC41LjEuMy4gIFN0YXR1cy1pbmZvIFRMViAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDYKICAgICAgICAgNS40LjUuMi4gIEdlbmVyaWMg UmVzcG9uc2UgTWVzc2FnZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ3CiAgICAgNS41LiAg QVRNLXNwZWNpZmljIGNvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA0OQogICAgIDUuNi4gIEV0aGVybmV0LXNwZWNpZmljIGNvbnNpZGVyYXRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDkKICAgNi4gIEFwcGVuZGl4OiBIYW5kbGluZyBvZiBwcmUtUkZD IGRlcGxveW1lbnRzIG9mIHRoZSBBTkNQCiAgICAgICBwcm90b2NvbCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MAogICA3LiAgSUFOQSBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTAK ICAgOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDU1CiAgIDkuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NgogICAxMC4gUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTYKICAgICAxMC4x LiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDU2CiAgICAgMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1NgogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTcKCgoKCgoKCiBXYWRod2EsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgICBbUGFn ZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAg ICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCjEuICBTcGVjaWZpY2F0aW9uIFJlcXVpcmVtZW50cwoK ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIs ICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCgoyLiAgSW50cm9kdWN0aW9uCgogICBE U0wgaXMgYSB3aWRlbHkgZGVwbG95ZWQgYWNjZXNzIHRlY2hub2xvZ3kgZm9yIEJyb2FkYmFuZCBB Y2Nlc3MgZm9yCiAgIE5leHQgR2VuZXJhdGlvbiBOZXR3b3Jrcy4gIFNldmVyYWwgc3BlY2lmaWNh dGlvbnMgbGlrZSBbVFItMDU5XSwKICAgW1RSLTA1OF0sIFtUUi0wOTJdIGRlc2NyaWJlIHBvc3Np YmxlIGFyY2hpdGVjdHVyZXMgZm9yIHRoZXNlIGFjY2VzcwogICBuZXR3b3Jrcy4gIEluIHRoZSBz Y29wZSBvZiB0aGVzZSBzcGVjaWZpY2F0aW9ucyBhcmUgdGhlIGRlbGl2ZXJ5IG9mCiAgIHZvaWNl LCB2aWRlbyBhbmQgZGF0YSBzZXJ2aWNlcy4KCiAgIFdoZW4gZGVwbG95aW5nIHZhbHVlLWFkZGVk IHNlcnZpY2VzIGFjcm9zcyBEU0wgYWNjZXNzIG5ldHdvcmtzLAogICBzcGVjaWFsIGF0dGVudGlv biByZWdhcmRpbmcgcXVhbGl0eSBvZiBzZXJ2aWNlIGFuZCBzZXJ2aWNlIGNvbnRyb2wgaXMKICAg cmVxdWlyZWQsIHdoaWNoIGltcGxpZXMgYSB0aWdodGVyIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIG5l dHdvcmsKICAgZWxlbWVudHMgaW4gdGhlIGJyb2FkYmFuZCBhY2Nlc3MgbmV0d29yayB3aXRob3V0 IGJ1cmRlbmluZyB0aGUgT1NTCiAgIGxheWVyLgoKICAgVGhpcyBkcmFmdCBkZWZpbmVzIGV4dGVu c2lvbnMgYW5kIG1vZGlmaWNhdGlvbnMgdG8gR1NNUHYzIChzcGVjaWZpZWQKICAgaW4gW1JGQzMy OTJdKSBhbmQgY2VydGFpbiBuZXcgbWVjaGFuaXNtcyB0byByZWFsaXplIGEgY29udHJvbCBwbGFu ZQogICBiZXR3ZWVuIGEgc2VydmljZS1vcmllbnRlZCBsYXllciAzIGVkZ2UgZGV2aWNlICh0aGUg TkFTKSBhbmQgYSBsYXllcjIKICAgQWNjZXNzIE5vZGUgKGUuZy4gIERTTEFNKSBpbiBvcmRlciB0 byBwZXJmb3JtIFFvUy1yZWxhdGVkLCBzZXJ2aWNlLQogICByZWxhdGVkIGFuZCBzdWJzY3JpYmVy LXJlbGF0ZWQgb3BlcmF0aW9ucy4gIFRoZSBjb250cm9sIHByb3RvY29sIGFzIGEKICAgcmVzdWx0 IG9mIHRoZXNlIGV4dGVuc2lvbnMgYW5kIG1lY2hhbmlzbXMgaXMgcmVmZXJyZWQgdG8gYXMgIkFj Y2VzcwogICBOb2RlIENvbnRyb2wgUHJvdG9jb2wiIChBTkNQKS4gIEFsdGhvdWdoIEFOQ1AgaXMg YmFzZWQgb24gR1NNUHYzLCBpdAogICBpcyBub3QgaW50ZXJvcGVyYWJsZSB3aXRoIEdTTVB2MyBk ZWZpbmVkIGluIFtSRkMzMjkyXS4KCiAgIEFOQ1AgdXNlcyB0aGUgb3B0aW9uIG9mIHRyYW5zcG9y dGluZyBHU01QdjMgb3ZlciBUQ1AvSVAuICBUQ1AKICAgZW5jYXBzdWxhdGlvbiBmb3IgR1NNUHYz IGlzIGRlZmluZWQgaW4gW1JGQzMyOTNdLiAgR1NNUHYzCiAgIGVuY2Fwc3VsYXRpb24gZGlyZWN0 bHkgb3ZlciBFdGhlcm5ldCBhbmQgQVRNIGFzIGRlZmluZWQgaW4gW1JGQzMyOTNdCiAgIGlzIG5v dCBjb25zaWRlcmVkIGZvciBBTkNQLgoKICAgQU5DUCB1c2VzIGEgc3Vic2V0IG9mIEdTTVB2MyBt ZXNzYWdlcyB0byBpbXBsZW1lbnQgY3VycmVudGx5IGRlZmluZWQKICAgdXNlLWNhc2VzLiAgVGhl c2UgcmVsZXZhbnQgR1NNUHYzIG1lc3NhZ2VzIGFyZSBpZGVudGlmaWVkIGluIHNlY3Rpb24KICAg U2VjdGlvbiA1LiAgR1NNUHYzIHByb2NlZHVyZXMgd2l0aCBzdWl0YWJsZSBleHRlbnNpb25zLCBh cyB1c2VkIGJ5CiAgIEFOQ1AsIGFyZSBkZXNjcmliZWQgaW4gc2VjdGlvbnMgU2VjdGlvbiA1LjEs IFNlY3Rpb24gNS4yIGFuZAogICBTZWN0aW9uIDUuMy4gIEdTTVB2MyBnZW5lcmFsIGV4dGVuc2lv bnMgYW5kIEdTTVB2MyBtZXNzYWdlIHNwZWNpZmljCiAgIGV4dGVuc2lvbnMgcmVxdWlyZWQgYnkg QU5DUCBhcmUgZGVzY3JpYmVkIGluIHN1Yi1zZWN0aW9ucyBvZgogICBTZWN0aW9uIDUuNC4gIElu IGFkZGl0aW9uIHRvIHNwZWNpZnlpbmcgZXh0ZW5zaW9ucyBhbmQgbW9kaWZpY2F0aW9ucwogICB0 byByZWxldmFudCBHU01QIG1lc3NhZ2VzIGFwcGxpY2FibGUgdG8gQU5DUCwgdGhpcyBkcmFmdCBh bHNvIGRlZmluZXMKICAgdGhlIHVzYWdlIG9mIHRoZXNlIG1lc3NhZ2VzIGJ5IEFOQ1AuICBOb3Qg YWxsIHRoZSBmaWVsZHMgaW4gcmVsZXZhbnQKICAgR1NNUCBtZXNzYWdlcyBhcmUgdXNlZCBieSBB TkNQLiAgVGhpcyBkcmFmdCBpbmRpY2F0ZXMgdGhlIHZhbHVlIHRoYXQKICAgQU5DUCBzaG91bGQg c2V0IGZvciB0aGUgZmllbGRzIGluIHRoZXNlIEdTTVAgbWVzc2FnZXMuCgogICBBdCB0aGUgdGlt ZSBvZiB3cml0aW5nIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBzb21lIGltcGxlbWVudGF0aW9ucyBv ZgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAg ICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBhbmNw IHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICB0aGUgQU5DUCBwcm90 b2NvbCwgYmFzZWQgb24gcHJlLXN0YW5kYXJkcyBkcmFmdHMgYXJlIGFscmVhZHkKICAgYXZhaWxh YmxlLiAgQWxsIHRoZXNlIGVhcmx5LWRyYWZ0IGltcGxlbWVudGF0aW9ucyB1c2UgcHJvdG9jb2wK ICAgdmVyc2lvbi9zdWItdmVyc2lvbiAzLjE7IHN0YW5kYXJkIEFOQ1AgcHJvdG9jb2wgd2lsbCB1 c2UgdmVyc2lvbi8KICAgc3ViLXZlcnNpb24gMy4yIFtFZGl0b3IncyBub3RlOiBzdWItdmVyc2lv biBuZWVkcyB0byBiZSBjaGFuZ2VkIGZyb20KICAgMSB0byAyIHVwb24gcHVibGljYXRpb24uXSAg QWRvcHRpbmcgYSBuZXcgc3ViLXZlcnNpb24gdmFsdWUgcHJvdmlkZXMKICAgYSB3YXkgdG8gZGlz YW1iaWd1YXRlIHRoZSB0d28gcHJvdG9jb2xzIGFuZCBhbGxvd3MgZm9yIHN1cHBvcnRpbmcKICAg cnVubmluZyBhIHByZS1zdGFuZGFyZCBhbmQgYSBzdGFuZGFyZHMgY29tcGxpYW50IEFOQ1AgaW1w bGVtZW50YXRpb24KICAgb24gYW55IGdpdmVuIEFOQ1Agbm9kZS4gIFRoZSBtZWNoYW5pc20gdXNl ZCB0byBpZGVudGlmeSB0aGUgcHJvdG9jb2wKICAgdmVyc2lvbi9zdWItdmVyc2lvbiBpcyBwYXJ0 IG9mIHRoZSBhZGphY2VuY3kgbmVnb3RpYXRpb24gcHJvY2VzcyBhbmQKICAgaXQgaXMgZGVzY3Jp YmVkIGluIGRldGFpbHMgaW4gU2VjdGlvbiA1LjIuICBJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZQog ICB0aGF0IHRoaXMgbWVjaGFuaXNtIGRvZXMgbm90IGd1YXJhbnRlZSBiYWNrd2FyZHMgY29tcGF0 aWJpbGl0eSBvZiB0aGUKICAgQU5DUCBSRkMgc3BlY2lmaWNhdGlvbiB0byB0aG9zZSBlYXJseS1k cmFmdCBpbXBsZW1lbnRhdGlvbnMuCgoyLjEuICBUZXJtaW5vbG9neQoKICAgbyAgQWNjZXNzIE5v ZGUgKEFOKTogTmV0d29yayBkZXZpY2UsIHVzdWFsbHkgbG9jYXRlZCBhdCBhIHNlcnZpY2UKICAg ICAgcHJvdmlkZXIgY2VudHJhbCBvZmZpY2Ugb3Igc3RyZWV0IGNhYmluZXQgdGhhdCB0ZXJtaW5h dGVzIGFjY2VzcwogICAgICAobG9jYWwpIGxvb3AgY29ubmVjdGlvbnMgZnJvbSBzdWJzY3JpYmVy cy4gIEluIGNhc2UgdGhlIGFjY2VzcwogICAgICBsb29wIGlzIGEgRGlnaXRhbCBTdWJzY3JpYmVy IExpbmUgKERTTCksIHRoZSBBY2Nlc3MgTm9kZSBwcm92aWRlcwogICAgICBEU0wgc2lnbmFsIHRl cm1pbmF0aW9uLCBhbmQgaXMgcmVmZXJyZWQgdG8gYXMgRFNMIEFjY2VzcwogICAgICBNdWx0aXBs ZXhlciAoRFNMQU0pLgoKICAgbyAgTmV0d29yayBBY2Nlc3MgU2VydmVyIChOQVMpOiBOZXR3b3Jr IGVsZW1lbnQgd2hpY2ggYWdncmVnYXRlcwogICAgICBzdWJzY3JpYmVyIHRyYWZmaWMgZnJvbSBh IG51bWJlciBvZiBBY2Nlc3MgTm9kZXMuICBUaGUgTkFTIGlzIGFuCiAgICAgIGluamVjdGlvbiBw b2ludCBmb3IgcG9saWN5IG1hbmFnZW1lbnQgYW5kIElQIFFvUyBpbiB0aGUgYWNjZXNzCiAgICAg IG5ldHdvcmsuICBJVCBpcyBhbHNvIHJlZmVycmVkIHRvIGFzIEJyb2FkYmFuZCBOZXR3b3JrIEdh dGV3YXkKICAgICAgKEJORykgb3IgQnJvYWRiYW5kIFJlbW90ZSBBY2Nlc3MgU2VydmVyIChCUkFT KS4KCiAgIG8gIEhvbWUgR2F0ZXdheSAoSEdXKTogTmV0d29yayBlbGVtZW50IHRoYXQgY29ubmVj dHMgc3Vic2NyaWJlcgogICAgICBkZXZpY2VzIHRvIHRoZSBBY2Nlc3MgTm9kZSBhbmQgdGhlIGFj Y2VzcyBuZXR3b3JrLiAgSW4gY2FzZSBvZgogICAgICBEU0wsIHRoZSBIb21lIEdhdGV3YXkgaXMg YSBEU0wgbmV0d29yayB0ZXJtaW5hdGlvbiB0aGF0IGNvdWxkCiAgICAgIGVpdGhlciBvcGVyYXRl IGFzIGEgbGF5ZXIgMiBicmlkZ2Ugb3IgYXMgYSBsYXllciAzIHJvdXRlci4gIEluIHRoZQogICAg ICBsYXR0ZXIgY2FzZSwgc3VjaCBhIGRldmljZSBpcyBhbHNvIHJlZmVycmVkIHRvIGFzIGEgUm91 dGluZwogICAgICBHYXRld2F5IChSRykuCgogICBvICBOZXQgRGF0YSBSYXRlOiBwb3J0aW9uIG9m IHRoZSB0b3RhbCBkYXRhIHJhdGUgb2YgdGhlIERTTCBsaW5lIHRoYXQKICAgICAgY2FuIGJlIHVz ZWQgdG8gdHJhbnNtaXQgYWN0dWFsIHVzZXIgaW5mb3JtYXRpb24gKGUuZy4gIEFUTSBjZWxscwog ICAgICBvZiBFdGhlcm5ldCBmcmFtZXMpLiAgSXQgZXhjbHVkZXMgb3ZlcmhlYWQgdGhhdCBwZXJ0 YWlucyB0byB0aGUKICAgICAgcGh5c2ljYWwgdHJhbnNtaXNzaW9uIG1lY2hhbmlzbSAoZS5nLiB0 cmVsbGlzIGNvZGluZyBpbiBjYXNlIG9mCiAgICAgIERTTCkuICBUaGlzIGlzIGRlZmluZWQgaW4g c2VjdGlvbiAzLjM5IG9mIElUVS1UIEcuOTkzLjIuCgogICBvICBEU0wgbGluZSAoc3luY2gpIHJh dGU6IHRoZSB0b3RhbCBkYXRhIHJhdGUgb2YgdGhlIERTTCBsaW5lLAogICAgICBpbmNsdWRpbmcg dGhlIG92ZXJoZWFkIGF0dHJpYnV0YWJsZSB0byB0aGUgcGh5c2ljYWwgdHJhbnNtaXNzaW9uCiAg ICAgIG1lY2hhbmlzbS4KCiAgIG8gIERTTCBtdWx0aS1wYWlyIGJvbmRpbmc6IG1ldGhvZCBmb3Ig Ym9uZGluZyAob3IgYWdncmVnYXRpbmcpCiAgICAgIG11bHRpcGxlIHhEU0wgbGluZXMgaW50byBh IHNpbmdsZSBiaS1kaXJlY3Rpb25hbCBsb2dpY2FsIGxpbmssCiAgICAgIGhlbmNlZm9ydGggcmVm ZXJyZWQgdG8gaW4gdGhpcyBkcmFmdCBhcyAiRFNMIGJvbmRlZCBjaXJjdWl0Ii4gIERTTAoKCgog V2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAg ICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3Rv Y29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICAgICAibXVsdGktcGFpciIgYm9u ZGluZyBhbGxvd3MgYW4gb3BlcmF0b3IgdG8gY29tYmluZSB0aGUgZGF0YSByYXRlcwogICAgICBv biB0d28gb3IgbW9yZSBjb3BwZXIgcGFpcnMsIGFuZCBkZWxpdmVyIHRoZSBhZ2dyZWdhdGUgZGF0 YSByYXRlCiAgICAgIHRvIGEgc2luZ2xlIGN1c3RvbWVyLiAgSVRVLVQgcmVjb21tZW5kYXRpb25z IEcuOTk4LjEgYW5kIEcuOTk4LjIKICAgICAgcmVzcGVjdGl2ZWx5IGRlc2NyaWJlIEFUTSBhbmQg RXRoZXJuZXQgYmFzZWQgbXVsdGktcGFpciBib25kaW5nLgoKCjMuICAgQnJvYWRiYW5kIEFjY2Vz cyBBZ2dyZWdhdGlvbgoKMy4xLiAgQVRNLWJhc2VkIGJyb2FkYmFuZCBhZ2dyZWdhdGlvbgoKICAg RW5kIHRvIGVuZCBEU0wgbmV0d29yayBjb25zaXN0cyBvZiBuZXR3b3JrIGFuZCBhcHBsaWNhdGlv biBzZXJ2aWNlCiAgIHByb3ZpZGVyIG5ldHdvcmtzIChOU1AgYW5kIEFTUCBuZXR3b3JrcyksIHJl Z2lvbmFsL2FjY2VzcyBuZXR3b3JrLAogICBhbmQgY3VzdG9tZXIgcHJlbWlzZXMgbmV0d29yay4g IEZpZ3VyZSAxIHNob3dzIEFUTSBicm9hZGJhbmQgYWNjZXNzCiAgIG5ldHdvcmsgY29tcG9uZW50 cy4KCiAgIFRoZSBSZWdpb25hbC9BY2Nlc3MgTmV0d29yayBjb25zaXN0cyBvZiB0aGUgUmVnaW9u YWwgTmV0d29yaywgTmV0d29yawogICBBY2Nlc3MgU2VydmVyLCBhbmQgdGhlIEFjY2VzcyBOZXR3 b3JrIGFzIHNob3cgaW4gRmlndXJlIDEuICBJdHMKICAgcHJpbWFyeSBmdW5jdGlvbiBpcyB0byBw cm92aWRlIGVuZC10by1lbmQgdHJhbnNwb3J0IGJldHdlZW4gdGhlCiAgIGN1c3RvbWVyIHByZW1p c2VzIGFuZCB0aGUgTlNQIG9yIEFTUC4gIFRoZSBBY2Nlc3MgTm9kZSB0ZXJtaW5hdGVzIHRoZQog ICBEU0wgc2lnbmFsLiAgSXQgY291bGQgY29uc2lzdCBvZiBEU0xBTSBpbiB0aGUgY2VudHJhbCBv ZmZpY2UsIG9yCiAgIHJlbW90ZSBEU0xBTSwgb3IgYSBSZW1vdGUgQWNjZXNzIE11bHRpcGxleGVy IChSQU0pLiAgQWNjZXNzIG5vZGUgaXMKICAgdGhlIGZpcnN0IHBvaW50IGluIHRoZSBuZXR3b3Jr IHdoZXJlIHRyYWZmaWMgb24gbXVsdGlwbGUgRFNMIGxpbmVzCiAgIHdpbGwgYmUgYWdncmVnYXRl ZCBvbnRvIGEgc2luZ2xlIG5ldHdvcmsuICBUaGUgTkFTIHBlcmZvcm1zIG11bHRpcGxlCiAgIGZ1 bmN0aW9ucyBpbiB0aGUgbmV0d29yay4KCiAgIFRoZSBOQVMgaXMgdGhlIGFnZ3JlZ2F0aW9uIHBv aW50IGZvciB0aGUgc3Vic2NyaWJlciB0cmFmZmljLiAgSXQKICAgcHJvdmlkZXMgYWdncmVnYXRp b24gY2FwYWJpbGl0aWVzIChlLmcuICBJUCwgUFBQLCBBVE0pIGJldHdlZW4gdGhlCiAgIFJlZ2lv bmFsL0FjY2VzcyBOZXR3b3JrIGFuZCB0aGUgTlNQIG9yIEFTUC4gIFRoZXNlIGluY2x1ZGUKICAg dHJhZGl0aW9uYWwgQVRNLWJhc2VkIG9mZmVyaW5ncyBhbmQgbmV3ZXIsIG1vcmUgbmF0aXZlIElQ LWJhc2VkCiAgIHNlcnZpY2VzLiAgVGhpcyBpbmNsdWRlcyBzdXBwb3J0IGZvciBQb2ludC10by1Q b2ludCBQcm90b2NvbCBvdmVyIEFUTQogICAoUFBQb0EpIGFuZCBQUFAgb3ZlciBFdGhlcm5ldCAo UFBQb0UpLCBhcyB3ZWxsIGFzIGRpcmVjdCBJUCBzZXJ2aWNlcwogICBlbmNhcHN1bGF0ZWQgb3Zl ciBhbiBhcHByb3ByaWF0ZSBsYXllciAyIHRyYW5zcG9ydC4KCiAgIEJleW9uZCBhZ2dyZWdhdGlv biwgTkFTIGlzIGFsc28gdGhlIGluamVjdGlvbiBwb2ludCBmb3IgcG9saWN5CiAgIG1hbmFnZW1l bnQgYW5kIElQIFFvUyBpbiB0aGUgUmVnaW9uYWwvQWNjZXNzIE5ldHdvcmtzLiAgSW4gb3JkZXIg dG8KICAgYWxsb3cgSVAgUW9TIHN1cHBvcnQgb3ZlciBhbiBleGlzdGluZyBub24tSVAtYXdhcmUg bGF5ZXIgMiBhY2Nlc3MKICAgbmV0d29yayB3aXRob3V0IHVzaW5nIG11bHRpcGxlIGxheWVyIDIg UW9TIGNsYXNzZXMsIGEgbWVjaGFuaXNtIGJhc2VkCiAgIG9uIGhpZXJhcmNoaWNhbCBzY2hlZHVs aW5nIGlzIHVzZWQuICBUaGlzIG1lY2hhbmlzbSBkZWZpbmVkIGluCiAgIFtUUi0wNTldLCBwcmVz ZXJ2ZXMgSVAgUW9TIG92ZXIgdGhlIEFUTSBuZXR3b3JrIGJldHdlZW4gdGhlIE5BUyBhbmQKICAg dGhlIFJHcyBieSBjYXJlZnVsbHkgY29udHJvbGxpbmcgZG93bnN0cmVhbSB0cmFmZmljIGluIHRo ZSBOQVMsIHNvCiAgIHRoYXQgc2lnbmlmaWNhbnQgcXVldWluZyBhbmQgY29uZ2VzdGlvbiBkb2Vz IG5vdCBvY2N1ciBmdXJ0aGVyIGRvd24KICAgdGhlIEFUTSBuZXR3b3JrLiAgVGhpcyBpcyBhY2hp ZXZlZCBieSB1c2luZyBhIGRpZmZzZXJ2LWF3YXJlCiAgIGhpZXJhcmNoaWNhbCBzY2hlZHVsZXIg aW4gdGhlIE5BUyB0aGF0IHdpbGwgYWNjb3VudCBmb3IgZG93bnN0cmVhbQogICB0cnVuayBiYW5k d2lkdGhzIGFuZCBEU0wgc3luY2ggcmF0ZXMuCgogICBbQU5DUC1GUkFNRVdPUktdIHByb3ZpZGVz IGRldGFpbGVkIGRlZmluaXRpb24gYW5kIGZ1bmN0aW9ucyBvZiBlYWNoCiAgIG5ldHdvcmsgZWxl bWVudCBpbiB0aGUgYnJvYWRiYW5kIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUuCgoKCgogV2FkaHdh LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICAg W1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAg ICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICAgIEFjY2VzcyAgICAgICAgICAgICAgICAg ICBDdXN0b21lcgogICAgICAgICAgICAgICAgICAgICAgIDwtLS0gQWdncmVnYXRpb24gLS0+ICA8 LS0tLS0tLSBQcmVtaXNlcyAtLS0tLS0tPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBO ZXR3b3JrICAgICAgICAgICAgICAgICAgIE5ldHdvcmsKCiAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICArLS0t LS0tLS0tKyAgICstLS0rIHwgKy0tLS0tKyArLS0tLS0tKyB8LXwrLS0tLS0rICstLS0rICstLS0t LS0tLS0rIHwKTlNQfCAgICAgICAgIHwgKy18TkFTfC18IHxBVE0gIHwtfEFjY2Vzc3wgfCB8fERT TCAgfC18SEdXfC18U3Vic2NyaWJlcnx8Ci0tLSsgUmVnaW9uYWx8IHwgKy0tLSsgfCArLS0tLS0r IHwgTm9kZSB8IHwgfHxNb2RlbXwgKy0tLSsgfERldmljZXMgICB8fAogICB8QnJvYWRiYW5kfCB8 ICstLS0rIHwgICAgICAgICArLS0tLS0tKyB8IHwrLS0tLS0rICAgICAgICstLS0tLS0tLS0tK3wK QVNQfE5ldHdvcmsgIHwtKy18TkFTfCArLS0tLS0tLS0tLS0tLS18LS0tKyArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rCi0tLSsgICAgICAgICB8IHwgKy0tLSsgICAgICAgICAgICAgICAgfCAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8ICAgICAgICAgfCB8ICstLS0rICAg ICAgICAgICAgICAgIHwgICAgIHwrLS0tLS0rICstLS0rICstLS0tLS0tLS0tK3wKICAgKy0tLS0t LS0tLSsgKy18TkFTfCAgICAgICAgICAgICAgICArLS0tLS18fCBEU0wgfC18SEdXfC18U3Vic2Ny aWJlcnx8CiAgICAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgICAgICAgICAgfHxNb2Rl bXwgKy0tLSsgfERldmljZXMgICB8fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwrLS0tLS0rICAgICAgICstLS0tLS0tLS0tK3wKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiBI R1cgICA6IEhvbWUgR2F0ZXdheQogTkFTICAgOiBOZXR3b3JrIEFjY2VzcyBTZXJ2ZXIKCgogICAg ICAgICAgICAgICBGaWd1cmUgMTogQVRNIEJyb2FkYmFuZCBBZ2dyZWdhdGlvbiBUb3BvbG9neQoK My4yLiAgRXRoZXJuZXQtYmFzZWQgYnJvYWRiYW5kIGFnZ3JlZ2F0aW9uCgogICBUaGUgRXRoZXJu ZXQgYWdncmVnYXRpb24gbmV0d29yayBhcmNoaXRlY3R1cmUgYnVpbGRzIG9uIHRoZSBFdGhlcm5l dAogICBicmlkZ2luZy9zd2l0Y2hpbmcgY29uY2VwdHMgZGVmaW5lZCBpbiBJRUVFIDgwMi4gIFRo ZSBFdGhlcm5ldAogICBhZ2dyZWdhdGlvbiBuZXR3b3JrIHByb3ZpZGVzIHRyYWZmaWMgYWdncmVn YXRpb24sIGNsYXNzIG9mIHNlcnZpY2UKICAgZGlzdGluY3Rpb24sIGFuZCBjdXN0b21lciBzZXBh cmF0aW9uIGFuZCB0cmFjZWFiaWxpdHkuICBWTEFOIHRhZ2dpbmcKICAgZGVmaW5lZCBpbiBJRUVF IDgwMi4xUSBhbmQgYmVpbmcgZW5oYW5jZWQgYnkgSUVFRSA4MDIuMWFkIGlzIHVzZWQgYXMKICAg c3RhbmRhcmQgdmlydHVhbGl6YXRpb24gbWVjaGFuaXNtIGluIHRoZSBFdGhlcm5ldCBhZ2dyZWdh dGlvbgogICBuZXR3b3JrLiAgVGhlIGFnZ3JlZ2F0aW9uIGRldmljZXMgYXJlICJwcm92aWRlciBl ZGdlIGJyaWRnZXMiIGRlZmluZWQKICAgaW4gSUVFRSA4MDIuYWQuICBTdGFja2VkIFZMQU4gdGFn cyBwcm92aWRlIG9uZSBwb3NzaWJsZSB3YXkgdG8gY3JlYXRlCiAgIGVxdWl2YWxlbnQgb2YgInZp cnR1YWwgcGF0aHMiIGFuZCAidmlydHVhbCBjaXJjdWl0cyIgaW4gdGhlCiAgIGFnZ3JlZ2F0aW9u IG5ldHdvcmsuICBUaGUgIm91dGVyIiB2bGFuIGNvdWxkIGJlIHVzZWQgdG8gY3JlYXRlIGEgZm9y bQogICBvZiAidmlydHVhbCBwYXRoIiBiZXR3ZWVuIGEgZ2l2ZW4gRFNMQU0gYW5kIGEgZ2l2ZW4g TkFTLiAgQW5kICJpbm5lciIKICAgVkxBTiB0YWdzIHRvIGNyZWF0ZSBhIGZvcm0gb2YgInZpcnR1 YWwgY2lyY3VpdCIgb24gYSBwZXIgRFNMIGxpbmUKICAgYmFzaXMuICBUaGlzIGlzIDE6MSBWTEFO IGFsbG9jYXRpb24gbW9kZWwuICBBbiBhbHRlcm5hdGl2ZSBtb2RlbCBpcwogICB0byBicmlkZ2Ug c2Vzc2lvbnMgZnJvbSBtdWx0aXBsZSBzdWJzY3JpYmVycyBiZWhpbmQgYSBEU0xBTSBpbnRvIGEK ICAgc2luZ2xlIFZMQU4gaW4gdGhlIGFnZ3JlZ2F0aW9uIG5ldHdvcmsuICBUaGlzIGlzIE46MSBW TEFOIGFsbG9jYXRpb24KICAgbW9kZWwuICBBcmNoaXRlY3R1cmFsIGFuZCB0b3BvbG9naWNhbCBt b2RlbHMgb2YgYW4gRXRoZXJuZXQKICAgYWdncmVnYXRpb24gbmV0d29yayBpbiBjb250ZXh0IG9m IERTTCBhZ2dyZWdhdGlvbiBhcmUgZGVmaW5lZCBpbgogICBbVFItMTAxXQoKCjQuICBBY2Nlc3Mg Tm9kZSBDb250cm9sIFByb3RvY29sCgoKCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIg MjAwOQoKCjQuMS4gICBPdmVydmlldwoKICAgQSBkZWRpY2F0ZWQgY29udHJvbCBwcm90b2NvbCBi ZXR3ZWVuIE5BUyBhbmQgYWNjZXNzIG5vZGVzIGNhbgogICBmYWNpbGl0YXRlICJOQVMgbWFuYWdl ZCIgdGlnaHQgUU9TIGNvbnRyb2wgaW4gdGhlIGFjY2VzcyBuZXR3b3JrLAogICBzaW1wbGlmaWVk IE9TUyBpbmZyYXN0cnVjdHVyZSBmb3Igc2VydmljZSBtYW5hZ2VtZW50LCBvcHRpbWl6ZWQKICAg bXVsdGljYXN0IHJlcGxpY2F0aW9uIHRvIGVuYWJsZSB2aWRlbyBzZXJ2aWNlcyBvdmVyIERTTCwg c3Vic2NyaWJlcgogICBzdGF0aXN0aWNzIHJldHJpZXZhbCBvbiB0aGUgTkFTIGZvciBhY2NvdW50 aW5nIHB1cnBvc2VzLCBhbmQgZmF1bHQKICAgaXNvbGF0aW9uIGNhcGFiaWxpdHkgb24gdGhlIE5B UyBmb3IgdGhlIHVuZGVybHlpbmcgYWNjZXNzIHRlY2hub2xvZ3kuCiAgIFRoaXMgZGVkaWNhdGVk IGNvbnRyb2wgcGxhbmUgaXMgcmVmZXJyZWQgdG8gYXMgIkFjY2VzcyBOb2RlIENvbnRyb2wKICAg UHJvdG9jb2wiIChBTkNQKS4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlbGV2YW50IGV4dGVu c2lvbnMgdG8KICAgR1NNUHYzIGFzIGRlZmluZWQgW1JGQzMyOTJdIHRvIHJlYWxpemUgQU5DUC4K CiAgIEZvbGxvd2luZyBzZWN0aW9ucyBkaXNjdXNzIHRoZSB1c2Ugb2YgQU5DUCBmb3IgaW1wbGVt ZW50aW5nOgoKICAgbyAgRHluYW1pYyBkaXNjb3Zlcnkgb2YgYWNjZXNzIHRvcG9sb2d5IGJ5IHRo ZSBOQVMgdG8gcHJvdmlkZSB0aWdodAogICAgICBRT1MgY29udHJvbCBpbiB0aGUgYWNjZXNzIG5l dHdvcmsuCgogICBvICBQdXNoaW5nIHRvIHRoZSBhY2Nlc3Mtbm9kZXMsIHN1YnNjcmliZXIgYW5k IHNlcnZpY2UgZGF0YSByZXRyaWV2ZWQKICAgICAgYnkgdGhlIE5BUyBmcm9tIGFuIE9TUyBzeXN0 ZW0gKGUuZy4gcmFkaXVzIHNlcnZlciksIHRvIHNpbXBsaWZ5CiAgICAgIE9TUyBpbmZyYXN0cnVj dHVyZSBmb3Igc2VydmljZSBtYW5hZ2VtZW50LgoKICAgbyAgT3B0aW1pemVkLCAiTkFTIGNvbnRy b2xsZWQgYW5kIG1hbmFnZWQiIG11bHRpY2FzdCByZXBsaWNhdGlvbiBieQogICAgICBhY2Nlc3Mt bm9kZXMgYXQgTDIgbGF5ZXIuCgogICBvICBOQVMgY29udHJvbGxlZCwgb24tZGVtYW5kIGFjY2Vz cy1saW5lIHRlc3QgY2FwYWJpbGl0eSAocnVkaW1lbnRhcnkKICAgICAgZW5kLXRvLWVuZCBPQU0p LgoKICAgSW4gYWRkaXRpb24gdG8gRFNMLCBhbHRlcm5hdGUgYnJvYWRiYW5kIGFjY2VzcyB0ZWNo bm9sb2dpZXMgKGUuZy4KICAgTWV0cm8tRXRoZXJuZXQsIFBhc3NpdmUgT3B0aWNhbCBOZXR3b3Jr aW5nLCBXaU1heCkgd2lsbCBoYXZlIHNpbWlsYXIKICAgY2hhbGxlbmdlcyB0byBhZGRyZXNzLCBh bmQgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBzYW1lIGFwcHJvYWNoIG9mIGEKICAgY29udHJvbCBw bGFuZSBiZXR3ZWVuIGEgTkFTIGFuZCBhbiBBY2Nlc3MgTm9kZSAoZS5nLiAgT0xUKSwgcHJvdmlk aW5nCiAgIGEgdW5pZmllZCBjb250cm9sIGFuZCBtYW5hZ2VtZW50IGFyY2hpdGVjdHVyZSBmb3Ig bXVsdGlwbGUgYWNjZXNzCiAgIHRlY2hub2xvZ2llcywgaGVuY2UgZmFjaWxpdGF0aW5nIG1pZ3Jh dGlvbiBmcm9tIG9uZSB0byB0aGUgb3RoZXIKICAgYW5kL29yIHBhcmFsbGVsIGRlcGxveW1lbnRz LgoKICAgR1NNUHYzIGlzIGFuIGlkZWFsIGZpdCBmb3IgaW1wbGVtZW50aW5nIEFOQ1AuICBJdCBp cyBleHRlbnNpYmxlIGFuZAogICBjYW4gYmUgcnVuIG92ZXIgVENQL0lQLCB3aGljaCBtYWtlcyBp dCBwb3NzaWJsZSB0byBydW4gb3ZlciBkaWZmZXJlbnQKICAgYWNjZXNzIHRlY2hub2xvZ2llcy4K CjQuMi4gIEFOQ1AgYmFzZWQgQWNjZXNzIFRvcG9sb2d5IERpc2NvdmVyeQoKNC4yLjEuICAgR29h bHMKCiAgIFtUUi0wNTldIGRpc2N1c3NlcyB2YXJpb3VzIHF1ZXVpbmcvc2NoZWR1bGluZyBtZWNo YW5pc21zIHRvIGF2b2lkCiAgIGNvbmdlc3Rpb24gaW4gdGhlIGFjY2VzcyBuZXR3b3JrIHdoaWxl IGRlYWxpbmcgd2l0aCBtdWx0aXBsZSBmbG93cwogICB3aXRoIGRpc3RpbmN0IFFvUyByZXF1aXJl bWVudHMuICBTdWNoIG1lY2hhbmlzbXMgcmVxdWlyZSB0aGF0IHRoZSBOQVMKICAgZ2FpbnMga25v d2xlZGdlIGFib3V0IHRoZSB0b3BvbG9neSBvZiB0aGUgYWNjZXNzIG5ldHdvcmssIHRoZSB2YXJp b3VzCiAgIGxpbmtzIGJlaW5nIHVzZWQgYW5kIHRoZWlyIHJlc3BlY3RpdmUgbmV0IGRhdGEgcmF0 ZXMuICBTb21lIG9mIHRoZQoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJp bCAyNSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgog ICBpbmZvcm1hdGlvbiByZXF1aXJlZCBpcyBzb21ld2hhdCBkeW5hbWljIGluIG5hdHVyZSAoZS5n LiAgRFNMIHN5bmMKICAgcmF0ZSwgYW5kIHRoZXJlZm9yZSBhbHNvIHRoZSBuZXQgZGF0YSByYXRl KSwgaGVuY2UgY2Fubm90IGNvbWUgZnJvbSBhCiAgIHByb3Zpc2lvbmluZyBhbmQvb3IgaW52ZW50 b3J5IG1hbmFnZW1lbnQgT1NTIHN5c3RlbS4gIFNvbWUgb2YgdGhlCiAgIGluZm9ybWF0aW9uIHZh cmllcyBsZXNzIGZyZXF1ZW50bHkgKGUuZy4gY2FwYWNpdHkgb2YgYSBEU0xBTSB1cGxpbmspLAog ICBidXQgbmV2ZXJ0aGVsZXNzIG5lZWRzIHRvIGJlIGtlcHQgc3RyaWN0bHkgaW4gc3luYyBiZXR3 ZWVuIHRoZSBhY3R1YWwKICAgY2FwYWNpdHkgb2YgdGhlIHVwbGluayBhbmQgdGhlIGltYWdlIHRo ZSBOQVMgaGFzIG9mIGl0LgoKICAgRm9sbG93aW5nIHNlY3Rpb24gZGVzY3JpYmVzIEFOQ1AgbWVz c2FnZXMgdGhhdCBhbGxvdyB0aGUgQWNjZXNzIE5vZGUKICAgKGUuZy4gIERTTEFNKSB0byBjb21t dW5pY2F0ZSB0byB0aGUgTkFTLCBhY2Nlc3MgbmV0d29yayB0b3BvbG9neQogICBpbmZvcm1hdGlv biBhbmQgYW55IGNvcnJlc3BvbmRpbmcgdXBkYXRlcy4KCiAgIFNvbWUgb2YgdGhlIHBhcmFtZXRl cnMgdGhhdCBjYW4gYmUgY29tbXVuaWNhdGVkIGZyb20gdGhlIERTTEFNIHRvIHRoZQogICBOQVMg aW5jbHVkZSBEU0wgbGluZSBzdGF0ZSwgYWN0dWFsIHVwc3RyZWFtIGFuZCBkb3duc3RyZWFtIG5l dCBkYXRhCiAgIHJhdGVzIG9mIGEgc3luY2hyb25pemVkIERTTCBsaW5rLCBtYXhpbXVtIGF0dGFp bmFibGUgdXBzdHJlYW0gYW5kCiAgIGRvd25zdHJlYW0gbmV0IGRhdGEgcmF0ZXMsIGludGVybGVh dmluZyBkZWxheSBldGMuICBUb3BvbG9neQogICBkaXNjb3ZlcnkgaXMgc3BlY2lmaWNhbGx5IGlt cG9ydGFudCBpbiBjYXNlIHRoZSBuZXQgZGF0YSByYXRlIG9mIHRoZQogICBEU0wgbGluZSBjaGFu Z2VzIG92ZXIgdGltZS4gIFRoZSBEU0wgbmV0IGRhdGEgcmF0ZSBtYXkgYmUgZGlmZmVyZW50CiAg IGV2ZXJ5IHRpbWUgdGhlIERTTCBtb2RlbSBpcyB0dXJuZWQgb24uICBBZGRpdGlvbmFsbHksIGR1 cmluZyB0aGUgdGltZQogICB0aGUgRFNMIG1vZGVtIGlzIGFjdGl2ZSwgZGF0YSByYXRlIGNoYW5n ZXMgY2FuIG9jY3VyIGR1ZSB0bwogICBlbnZpcm9ubWVudGFsIGNvbmRpdGlvbnMgKHRoZSBEU0wg bGluZSBjYW4gZ2V0ICJvdXQgb2Ygc3luYyIgYW5kIGNhbgogICByZXRyYWluIHRvIGEgbG93ZXIg dmFsdWUpLgoKNC4yLjIuICBNZXNzYWdlIEZsb3cKCiAgIFdoZW4gYSBEU0wgbGluZSBpbml0aWFs bHkgY29tZXMgdXAgb3IgcmVzeW5jaHJvbml6ZXMgdG8gYSBkaWZmZXJlbnQKICAgcmF0ZSwgdGhl IERTTEFNIGdlbmVyYXRlcyBhbmQgdHJhbnNtaXRzIGEgR1NNUCBQT1JUIFVQIEVWRU5UIG1lc3Nh Z2UKICAgdG8gdGhlIE5BUy4gIFRoZSBleHRlbnNpb24gZmllbGQgaW4gdGhlIG1lc3NhZ2UgY2Fy cmllcyB0aGUgVExWcwogICBjb250YWluaW5nIERTTCBsaW5lIHNwZWNpZmljIHBhcmFtZXRlcnMu ICBPbiBhIGxvc3Mgb2Ygc2lnbmFsIG9uIHRoZQogICBEU0wgbGluZSwgYSBHU01QIFBPUlQgRE9X TiBtZXNzYWdlIGlzIGdlbmVyYXRlZCBieSB0aGUgRFNMQU0gdG8gdGhlCiAgIE5BUy4gIEluIG9y ZGVyIHRvIHByb3ZpZGUgZXhwZWN0ZWQgc2VydmljZSBsZXZlbCwgTkFTIG5lZWRzIHRvIGxlYXJu CiAgIHRoZSBpbml0aWFsIGF0dHJpYnV0ZXMgb2YgdGhlIERTTCBsaW5lIGJlZm9yZSB0aGUgc3Vi c2NyaWJlciBjYW4gbG9nCiAgIGluIGFuZCBhY2Nlc3MgdGhlIHByb3Zpc2lvbmVkIHNlcnZpY2Vz IGZvciB0aGUgc3Vic2NyaWJlci4gIEZpZ3VyZSAyCiAgIHN1bW1hcml6ZXMgdGhlIGludGVyYWN0 aW9uLgoKCgoKCgoKCgoKCgoKCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBB cHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkK CgogICAgICAgICAgICA8LS0tLS0gUG9ydCBVUChFVkVOVCBNZXNzYWdlKSAgPC0tLS0tIERTTAog ICAgICAgICAgICAgICAgIChkZWZhdWx0IGxpbmUgcGFyYW1ldGVycykgICAgICAgU2lnbmFsCgog ICAxLiAgTkFTIC0tLS0tLS0tLS0tLS0tLS0tLSBBY2Nlc3MgLS0tLS0tLS0tLS0gIEhvbWUgLS0t LS0gU3Vic2NyaWJlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9kZSAgICAgICAg ICAgICAgR2F0ZXdheQoKCiAgICAgICAgICAgIDwtLS0tLSBQb3J0IFVQIChFVkVOVCBNZXNzYWdl KSAgPC0tLS0tIERTTAogICAgICAgICAgICAgICAgICAodXBkYXRlZCBsaW5lIHBhcmFtZXRlcnMp ICAgICAgUmVzeW5jaAogICAyLiAgTkFTIC0tLS0tLS0tLS0tLS0tLS0tLSBBY2Nlc3MgLS0tLS0t LS0tLS0gSG9tZSAtLS0tLS0gU3Vic2NyaWJlcgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTm9kZSAgICAgICAgICAgICBHYXRld2F5CgogICAgICAgICAgIDwtLS0gUG9ydCBET1dOIChF VkVOVCBNZXNzYWdlKSA8LS0tLSBEU0wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIExvc3Mgb2YgU2lnbmFsCgogICAzLiAgTkFTIC0tLS0tLS0tLS0tLS0tLS0t IEFjY2VzcyAtLS0tLS0tLS0tLS0tIEhvbWUgLS0tLS0gU3Vic2NyaWJlcgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOb2RlICAgICAgICAgICAgICBHYXRld2F5CgogICAgICAgRmlndXJl IDI6IE1lc3NhZ2UgZmxvdyAoQU5DUCBtYXBwaW5nKSBmb3IgdG9wb2xvZ3kgZGlzY292ZXJ5Cgog ICBUaGUgRXZlbnQgbWVzc2FnZSB3aXRoIFBPUlQgVVAgbWVzc2FnZSB0eXBlICg4MCkgaXMgdXNl ZCBmb3IKICAgY29udmV5aW5nIERTTCBsaW5lIGF0dHJpYnV0ZXMgdG8gdGhlIE5BUy4gIFRoaXMg bWVzc2FnZSB3aXRoIHJlbGV2YW50CiAgIGV4dGVuc2lvbnMgaXMgZGVmaW5lZCBpbiBzZWN0aW9u IFNlY3Rpb24gNS40LjIuCgo0LjMuICBBTkNQIGJhc2VkIExpbmUgQ29uZmlndXJhdGlvbgoKNC4z LjEuICAgR29hbHMKCiAgIEZvbGxvd2luZyBkeW5hbWljIGRpc2NvdmVyeSBvZiBhY2Nlc3MgdG9w b2xvZ3kgKGlkZW50aWZpY2F0aW9uIG9mIERTTAogICBsaW5lIGFuZCBpdHMgYXR0cmlidXRlcykg YXMgYXNzaXN0ZWQgYnkgdGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4KICAgdGhlIHByZXZpb3Vz IHNlY3Rpb24gKHRvcG9sb2d5IGRpc2NvdmVyeSksIHRoZSBOQVMgY291bGQgdGhlbiBxdWVyeSBh CiAgIHN1YnNjcmliZXIgbWFuYWdlbWVudCBPU1Mgc3lzdGVtIChlLmcuICBSQURJVVMgc2VydmVy KSB0byByZXRyaWV2ZQogICBzdWJzY3JpYmVyIGF1dGhvcml6YXRpb24gZGF0YSAoc2VydmljZSBw cm9maWxlcywgYWthIHVzZXIKICAgZW50aXRsZW1lbnQpLiAgTW9zdCBvZiBzdWNoIHNlcnZpY2Ug bWVjaGFuaXNtcyBhcmUgdHlwaWNhbGx5IGVuZm9yY2VkCiAgIGJ5IHRoZSBOQVMgaXRzZWxmLCBi dXQgdGhlcmUgYXJlIGEgZmV3IGNhc2VzIHdoZXJlIGl0IG1pZ2h0IGJlIHVzZWZ1bAogICB0byBw dXNoIHN1Y2ggc2VydmljZSBwYXJhbWV0ZXIgdG8gdGhlIERTTEFNIGZvciBsb2NhbCBlbmZvcmNl bWVudCBvZgogICBhIG1lY2hhbmlzbSAoZS5nLiAgRFNMLXJlbGF0ZWQpIG9uIHRoZSBjb3JyZXNw b25kaW5nIHN1YnNjcmliZXIgbGluZS4KICAgT25lIHN1Y2ggZXhhbXBsZSBvZiBhIHNlcnZpY2Ug cGFyYW1ldGVyIHRoYXQgY2FuIGJlIHB1c2hlZCB0byB0aGUKICAgRFNMQU0gZm9yIGxvY2FsIGVu Zm9yY2VtZW50IGlzIERTTCAiaW50ZXJsZWF2aW5nIGRlbGF5Ii4gIExvbmdlcgogICBpbnRlcmxl YXZpbmcgZGVsYXkgKGFuZCBoZW5jZSBzdHJpbmdlbnQgZXJyb3IgY29ycmVjdGlvbikgaXMgcmVx dWlyZWQKICAgZm9yIGEgdmlkZW8gc2VydmljZSB0byBlbnN1cmUgYmV0dGVyIHZpZGVvICJxdWFs aXR5IG9mIGV4cGVyaWVuY2UiLAogICB3aGVyZWFzIGZvciBhIFZvSVAgc2VydmljZSBvciBmb3Ig InNob290IGZpcnN0IiBnYW1pbmcgc2VydmljZSwgYQogICB2ZXJ5IHNob3J0IGludGVybGVhdmlu ZyBkZWxheSBpcyBtb3JlIGFwcHJvcHJpYXRlLiAgQW5vdGhlciByZWxldmFudAogICBhcHBsaWNh dGlvbiBpcyBkb3dubG9hZGluZyBwZXIgc3Vic2NyaWJlciBtdWx0aWNhc3QgY2hhbm5lbAogICBl bnRpdGxlbWVudCBpbmZvcm1hdGlvbiBpbiBJUFRWIGFwcGxpY2F0aW9ucyB3aGVyZSB0aGUgRFNM QU0gaXMKICAgcGVyZm9ybWluZyBJR01QIHNub29waW5nIG9yIElHTVAgcHJveHkgZnVuY3Rpb24u ICBVc2luZyBBTkNQLCB0aGUgTkFTCiAgIGNvdWxkIGFjaGlldmUgdGhlIGdvYWwgb2YgcHVzaGlu ZyBsaW5lIGNvbmZpZ3VyYXRpb24gdG8gdGhlIERTTEFNIGJ5CiAgIGFuIGludGVyb3BlcmFibGUg YW5kIHN0YW5kYXJkaXplZCBwcm90b2NvbC4KCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0b2Jl ciAyMDA5CgoKICAgSWYgYSBzdWJzY3JpYmVyIHdhbnRzIHRvIGNob29zZSBhIGRpZmZlcmVudCBz ZXJ2aWNlLCBpdCBjYW4gcmVxdWlyZQogICBhbiBPUEVYIGludGVuc2l2ZSByZWNvbmZpZ3VyYXRp b24gb2YgdGhlIGxpbmUgdmlhIGEgbmV0d29yayBvcGVyYXRvciwKICAgcG9zc2libHkgaW1wbHlp bmcgYSBidXNpbmVzcy10by1idXNpbmVzcyB0cmFuc2FjdGlvbiBiZXR3ZWVuIGFuIElTUAogICBh bmQgYW4gYWNjZXNzIHByb3ZpZGVyLiAgVXNpbmcgQU5DUCBmb3IgbGluZSBjb25maWd1cmF0aW9u IGZyb20gdGhlCiAgIE5BUyBkcmFtYXRpY2FsbHkgc2ltcGxpZmllcyB0aGUgT1NTIGluZnJhc3Ry dWN0dXJlIGZvciBzZXJ2aWNlCiAgIG1hbmFnZW1lbnQsIGFsbG93aW5nIGZ1bGx5IGNlbnRyYWxp emVkIHN1YnNjcmliZXItcmVsYXRlZCBzZXJ2aWNlCiAgIGRhdGEgKGUuZy4gIFJBRElVUyBzZXJ2 ZXIgYmFjay1lbmQpIGFuZCBhdm9pZGluZyBjb21wbGV4IGNyb3NzLQogICBvcmdhbml6YXRpb24g QjJCIGludGVyYWN0aW9ucy4KCiAgIFRoZSBiZXN0IHdheSB0byBjaGFuZ2UgbGluZSBwYXJhbWV0 ZXJzIHdvdWxkIGJlIGJ5IHVzaW5nIHByb2ZpbGVzLgogICBUaGVzZSBwcm9maWxlcyAoRFNMIHBy b2ZpbGVzIGZvciBkaWZmZXJlbnQgc2VydmljZXMpIGFyZSBwcmUtCiAgIGNvbmZpZ3VyZWQgb24g dGhlIERTTEFNcy4gIFRoZSBOQVMgY2FuIHRoZW4gaW5kaWNhdGUgYSByZWZlcmVuY2UgdG8KICAg dGhlIHJpZ2h0IERTTCBwcm9maWxlIHZpYSBBTkNQLiAgQWx0ZXJuYXRpdmVseSwgZGlzY3JldGUg RFNMCiAgIHBhcmFtZXRlcnMgY2FuIGFsc28gYmUgY29udmV5ZWQgYnkgdGhlIE5BUyBpbiBBTkNQ LgoKNC4zLjIuICBNZXNzYWdlIEZsb3cKCiAgIFRyaWdnZXJlZCBieSB0b3BvbG9neSBpbmZvcm1h dGlvbiByZXBvcnRpbmcgYSBuZXcgRFNMIGxpbmUgb3IKICAgdHJpZ2dlcmVkIGJ5IGEgc3Vic2Vx dWVudCB1c2VyIHNlc3Npb24gZXN0YWJsaXNobWVudCAoUFBQIG9yIERIQ1ApLAogICB0aGUgTkFT IG1heSBzZW5kIGxpbmUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiAoZS5nLiByZWZlcmVuY2Ug dG8gYQogICBEU0wgcHJvZmlsZSkgdG8gdGhlIERTTEFNIHVzaW5nIEdTTVAgUG9ydCBNYW5hZ2Vt ZW50IG1lc3NhZ2VzLiAgVGhlCiAgIE5BUyBtYXkgZ2V0IHN1Y2ggbGluZSBjb25maWd1cmF0aW9u IGRhdGEgZnJvbSBhIHBvbGljeSBzZXJ2ZXIgKGUuZy4KICAgUkFESVVTKS4gIEZpZ3VyZSAzIHN1 bW1hcml6ZXMgdGhlIGludGVyYWN0aW9uLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIFdh ZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAg ICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2Nv bCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDEuRFNMIFNpZ25hbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwtLS0tLS0tLS0tLQogICAgICAgICAgIDIuIFBvcnQgVVAgKEVWRU5UIE1lc3NhZ2UpCiAgICAg ICAgICAoQWNjZXNzIFRvcG9sb2d5IERpc2NvdmVyeSkKICAgICAgICAgICAgICAgICAgPC0tLS0t LS0tLS0tLS0tLS0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMy4gUFBQL0RIQ1AgU2Vz c2lvbgogICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQogICAgIDQuIEF1dGhvcml6YXRpb24KICAgICYgQXV0aGVudGljYXRpb24KICAgICA8LS0tLS0t LS0tLS0tLS0tLS0tLQogICAgICAgICAgICAgICAgICAgIFBvcnQgTWFuYWdlbWVudCBNZXNzYWdl CiAgICAgICAgICAgICAgICAgICAgKExpbmUgQ29uZmlndXJhdGlvbikKICAgICAgICAgICAgICAg ICAgNS4gLS0tLS0tLS0+CiAgICstLS0tLS0tLS0tKyAgICstLS0tLSsgICAgICstLS0tLSsgICAg Ky0tLS0tLS0rICAgICstLS0tLS0tLS0tLSsKICAgfFJhZGl1cy9BQUF8LS0tfCBOQVMgfC0tLS0t fCBBTiAgfC0tLS18ICBIb21lIHwtLS0tfFN1YnNjcmliZXIgfAogICB8UG9saWN5ICAgIHwgICAr LS0tLS0rICAgICArLS0tLS0rICAgIHxHYXRld2F5fCAgICArLS0tLS0tLS0tLS0rCiAgIHxTZXJ2 ZXIgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rCiAgICstLS0tLS0tLS0t KwoKCgoKICAgRmlndXJlIDM6IE1lc3NhZ2UgZmxvdyAtIEFOQ1AgbWFwcGluZyBmb3IgSW5pdGlh bCBMaW5lIENvbmZpZ3VyYXRpb24KCiAgIFRoZSBOQVMgbWF5IHVwZGF0ZSB0aGUgbGluZSBjb25m aWd1cmF0aW9uIGR1ZSB0byBhIHN1YnNjcmliZXIgc2VydmljZQogICBjaGFuZ2UgKGUuZy4gdHJp Z2dlcmVkIGJ5IHRoZSBwb2xpY3kgc2VydmVyKS4gIEZpZ3VyZSA0IHN1bW1hcml6ZXMKICAgdGhl IGludGVyYWN0aW9uLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogV2FkaHdhLCBldCBhbC4gICAg ICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAg ICBPY3RvYmVyIDIwMDkKCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMS4gUFBQL0RIQ1AgU2Vzc2lvbgogICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICAgKy0tLS0tLS0tLS0tKyAg ICAgICAgICAgICAgICAgICAgICAyLiBTZXJ2aWNlIE9uIERlbWFuZAogICAgIHwgICAgICAgICAg IHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgICB8 IFdlYiBwb3J0YWx8CiAgICAgfCAgT1NTIGV0YyAgfCAzLkNoYW5nZSBvZiAgIDQuUG9ydCBNYW5h Z2VtZW50CiAgICAgfCAgICAgICAgICAgfCBBdXRob3JpemF0aW9uICAgTWVzc2FnZQogICAgIHxS YWRpdXMgQUFBIHwgLS0tLS0tLS0+ICAgICAoVXBkYXRlZCBMaW5lCiAgICAgfCAgUG9saWN5ICAg fCAgICAgICAgICAgICAgICBDb25maWcgLSBOZXcgUHJvZmlsZSkKICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgIC0tLS0tLS0tLS0tLS0+CiAgICAgfCAgICAgICAgICAgfCAgICArLS0tLS0tKyAg ICAgKy0tLS0tLS0rICAgKy0tLS0tLS0tLSsgICstLS0tLS0tLS0tKwogICAgIHwgICAgICAgICAg IHwtLS0tfCBOQVMgIHwtLS0tLXwgIEFOICAgfC0tLXwgIEhvbWUgICB8LS18U3Vic2NyaWJlcnwK ICAgICB8ICAgICAgICAgICB8ICAgICstLS0tLS0rICAgICArLS0tLS0tLSsgICB8IEdhdGV3YXkg fCAgKy0tLS0tLS0tLS0rCiAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLSsKCiAgIEZpZ3VyZSA0OiBNZXNzYWdlIGZsb3cgLSBBTkNQIG1hcHBp bmcgZm9yIFVwZGF0ZWQgTGluZSBDb25maWd1cmF0aW9uCgogICBUaGUgZm9ybWF0IG9mIHJlbGV2 YW50IGV4dGVuc2lvbnMgdG8gcG9ydCBtYW5hZ2VtZW50IG1lc3NhZ2UgaXMKICAgZGVmaW5lZCBp biBzZWN0aW9uIFNlY3Rpb24gNS40LjMuICBUaGUgbGluZSBjb25maWd1cmF0aW9uIG1vZGVscwog ICBjb3VsZCBiZSB2aWV3ZWQgYXMgYSBmb3JtIG9mIGRlbGVnYXRpb24gb2YgYXV0aG9yaXphdGlv biBmcm9tIHRoZSBOQVMKICAgdG8gdGhlIERTTEFNLgoKNC40LiAgQU5DUCBiYXNlZCBPQU0KCiAg IEluIGEgbWl4ZWQgRXRoZXJuZXQgYW5kIEFUTSBhY2Nlc3MgbmV0d29yayAoaW5jbHVkaW5nIHRo ZSBsb2NhbAogICBsb29wKSwgaXQgaXMgZGVzaXJhYmxlIHRvIHByb3ZpZGUgc2ltaWxhciBtZWNo YW5pc21zIGZvciBjb25uZWN0aXZpdHkKICAgY2hlY2tzIGFuZCBmYXVsdCBpc29sYXRpb24sIGFz IHRob3NlIHVzZWQgaW4gYW4gQVRNIGJhc2VkCiAgIGFyY2hpdGVjdHVyZS4gIFRoaXMgY2FuIGJl IGFjaGlldmVkIHVzaW5nIGFuIEFOQ1AgYmFzZWQgbWVjaGFuaXNtCiAgIHVudGlsIGVuZC10by1l bmQgRXRoZXJuZXQgT0FNIG1lY2hhbmlzbXMgYXJlIG1vcmUgd2lkZWx5IGltcGxlbWVudGVkCiAg IGluIHZhcmlvdXMgbmV0d29yayBlbGVtZW50cy4KCiAgIEEgc2ltcGxlIHNvbHV0aW9uIGJhc2Vk IG9uIEFOQ1AgY2FuIHByb3ZpZGUgTkFTIHdpdGggYW4gYWNjZXNzLWxpbmUKICAgdGVzdCBjYXBh YmlsaXR5IGFuZCB0byBzb21lIGV4dGVudCBmYXVsdCBpc29sYXRpb24uICBDb250cm9sbGVkIGJ5 IGEKICAgbG9jYWwgbWFuYWdlbWVudCBpbnRlcmZhY2UgdGhlIE5BUyBjYW4gdXNlIGFuIEFOQ1Ag b3BlcmF0aW9uIHRvCiAgIHRyaWdnZXIgdGhlIGFjY2Vzcy1ub2RlIHRvIHBlcmZvcm0gYSBsb29w YmFjayB0ZXN0IG9uIHRoZSBsb2NhbC1sb29wCiAgIChiZXR3ZWVuIHRoZSBhY2Nlc3Mtbm9kZSBh bmQgdGhlIENQRSkuICBUaGUgYWNjZXNzLW5vZGUgY2FuIHJlc3BvbmQKICAgdmlhIGFub3RoZXIg QU5DUCBvcGVyYXRpb24gdGhlIHJlc3VsdCBvZiB0aGUgdHJpZ2dlcmVkIGxvb3BiYWNrIHRlc3Qu CiAgIEluIGNhc2Ugb2YgQVRNIGJhc2VkIGxvY2FsLWxvb3AgdGhlIEFOQ1Agb3BlcmF0aW9uIGNh biB0cmlnZ2VyIHRoZQogICBhY2Nlc3Mtbm9kZSB0byBnZW5lcmF0ZSBBVE0gKEY0L0Y1KSBsb29w YmFjayBjZWxscyBvbiB0aGUgbG9jYWwgbG9vcC4KICAgSW4gY2FzZSBvZiBFdGhlcm5ldCwgdGhl IGFjY2Vzcy1ub2RlIGNhbiB0cmlnZ2VyIGFuIEV0aGVybmV0IGxvb3BiYWNrCiAgIG1lc3NhZ2Uo cGVyIEVGTSBPQU0pIG9uIHRoZSBsb2NhbC1sb29wLgoKNC40LjEuICBNZXNzYWdlIEZsb3cKCiAg ICJQb3J0IE1hbmFnZW1lbnQiIG1lc3NhZ2UgY2FuIGJlIHVzZWQgYnkgdGhlIE5BUyB0byByZXF1 ZXN0IGFjY2VzcwogICBub2RlIHRvIHRyaWdnZXIgYSAicmVtb3RlIGxvb3BiYWNrIiB0ZXN0IG9u IHRoZSBsb2NhbCBsb29wLiAgVGhlCiAgIHJlc3VsdCBvZiB0aGUgbG9vcGJhY2sgdGVzdCBjYW4g YmUgYXN5bmNocm9ub3VzbHkgY29udmV5ZWQgYnkgdGhlCgoKCiBXYWRod2EsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAg IE9jdG9iZXIgMjAwOQoKCiAgIGFjY2VzcyBub2RlIHRvIHRoZSBOQVMgaW4gYSAiUG9ydCBNYW5h Z2VtZW50IiByZXNwb25zZSBtZXNzYWdlLiAgVGhlCiAgIGZvcm1hdCBvZiByZWxldmFudCBleHRl bnNpb25zIHRvIHBvcnQgbWFuYWdlbWVudCBtZXNzYWdlIGlzIGRlZmluZWQKICAgaW4gc2VjdGlv biBUaGUgZm9ybWF0IG9mIHJlbGV2YW50IGV4dGVuc2lvbnMgdG8gcG9ydCBtYW5hZ2VtZW50CiAg IG1lc3NhZ2UgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIFNlY3Rpb24gNS40LjQuICBGaWd1cmUgNSBz dW1tYXJpemVzIHRoZQogICBpbnRlcmFjdGlvbi4KCiAgICAgICAgICAgICAgICAgIFBvcnQgTWFu YWdlbWVudCBNZXNzYWdlCiAgICAgICAgICAgICAgICAgIChSZW1vdGUgTG9vcGJhY2sgICAgICAg ICAgQVRNIGxvb3BiYWNrCiAgICAgICAgICAgICAgICAgICBUcmlnZ2VyIFJlcXVlc3QpICAgICAg ICAgT1IgRUZNIExvb3BiYWNrCiAgICAgICAgICAgICAgICAxLiAgLS0tLS0tLS0tLS0tLS0tLT4g ICAgIDIuIC0tLS0tLS0tLT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC0tLS0tLS0tKwogKy0tLS0tLS0tLS0tLS0rICAgICstLS0tLSsgICAgICAgKy0tLS0t LS0rICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsKIHxSYWRpdXMvQUFBICAgfC0tLS18TkFT ICB8LS0tLS0tLXwgRFNMQU0gfC0tLS0tLS0tLS0tfCAgICBDUEUgICAgICAgICB8CiB8UG9saWN5 IFNlcnZlcnwgICAgKy0tLS0tKyAgICAgICArLS0tLS0tLSsgICAgICAgICAgIHwgKERTTCBNb2Rl bSArICAgfAogKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8Um91dGluZyBHYXRld2F5KXwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAg ICAgIDMuIDwtLS0tLS0tLS0tLS0tLS0KICAgICAgICAgICAgICAgICAgICAgUG9ydCBNYW5hZ2Vt ZW50IE1lc3NhZ2UKICAgICAgICAgICAgICAgIChSZW1vdGUgTG9vcGJhY2sgVGVzdCBSZXNwb25z ZSkKCgogICAgICAgICAgICAgICAgICBGaWd1cmUgNTogTWVzc2FnZSBGbG93OiBBTkNQIGJhc2Vk IE9BTQoKCjUuICBBY2Nlc3MgTm9kZSBDb250cm9sIFByb3RvY29sIChBTkNQKQoKICAgQU5DUCB1 c2VzIGEgc3Vic2V0IG9mIEdTTVB2MyBtZXNzYWdlcyBkZXNjcmliZWQgaW4gW1JGQzMyOTJdIHRv CiAgIGltcGxlbWVudCBjdXJyZW50bHkgZGVmaW5lZCB1c2UtY2FzZXMuICBHU01QdjMgZ2VuZXJh bCBtZXNzYWdlCiAgIGZvcm1hdCwgdXNlZCBieSBhbGwgR1NNUCBtZXNzYWdlcyBvdGhlciB0aGFu IGFkamFjZW5jeSBwcm90b2NvbAogICBtZXNzYWdlcywgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMu MS4xIG9mIEdTTVB2MyBbUkZDMzI5Ml0uICBBTkNQCiAgIG1vZGlmaWVzIHRoaXMgYmFzZSBHU01Q djMgbWVzc2FnZSBmb3JtYXQuICBUaGUgbW9kaWZpZWQgR1NNUHYzCiAgIG1lc3NhZ2UgZm9ybWF0 IGlzIGRlZmluZWQgYXMgZm9sbG93czoKCgoKCgoKCgoKCgoKCgoKCgoKCiBXYWRod2EsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDE0 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAg ICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgICAgfCBWZXJzICB8ICBTdWIgIHwgTWVzc2FnZSBUeXBlICB8IFJlc3VsdHwgICAg ICAgIENvZGUgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCBQYXJ0aXRpb24gSUQg IHwgICAgICAgICAgICBUcmFuc2FjdGlvbiBJZGVudGlmaWVyICAgICAgICAgICAgIHwKICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsKICAgICAgfEl8ICAgICAgU3ViTWVzc2FnZSBOdW1iZXIgICAgICB8ICAgICAgICAg ICBMZW5ndGggICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZSBQYXlsb2FkICAgICAgICAgICAg ICAgICAgICAgIH4KICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCgogICAgICAgICAgICAg ICAgIEZpZ3VyZSA2OiBNb2RpZmllZCBHU01QdjMgbWVzc2FnZSBmb3JtYXQKCiAgIFRoZSA4LWJp dCB2ZXJzaW9uIGZpZWxkIGluIHRoZSBiYXNlIEdTTVB2MyBtZXNzYWdlIGhlYWRlciBpcyBzcGxp dAogICBpbnRvIHR3byA0IGJpdCBmaWVsZHMgZm9yIGNhcnJ5aW5nIHRoZSB2ZXJzaW9uIGFuZCBh IHN1Yi12ZXJzaW9uIG9mCiAgIHRoZSBHU01QIHByb3RvY29sLiAgQU5DUCB1c2VzIHZlcnNpb24g MyBhbmQgc3ViLXZlcnNpb24gMSBvZiB0aGUgR1NNUAogICBwcm90b2NvbC4gIEFuIEFOQ1AgaW1w bGVtZW50YXRpb24gU0hPVUxEIGFsd2F5cyBzZXQgdGhlIHZlcnNpb24gZmllbGQKICAgdG8gMywg YW5kIHRoZSBzdWItdmVyc2lvbiBmaWVsZCB0byAxLiAgVGhlIFJlc3VsdCBmaWVsZCBpbiB0aGUK ICAgbWVzc2FnZSBoZWFkZXIgaGFzIGJlZW4gbW9kaWZpZWQgdG8gYmUgNCBiaXRzIGxvbmcsIGFu ZCB0aGUgQ29kZQogICBmaWVsZCB0byBiZSAxMiBiaXRzIGxvbmcuCgogICBWZXJzaW9uOgoKICAg ICAgICBUaGUgdmVyc2lvbiBudW1iZXIgb2YgdGhlIEdTTVAgcHJvdG9jb2wgYmVpbmcgdXNlZCBp biB0aGlzCiAgICAgICAgc2Vzc2lvbi4gIEFOQ1AgdXNlcyB2ZXJzaW9uIDMuCgogICBTdWItVmVy c2lvbjoKCiAgICAgICAgVGhlIHN1Yi12ZXJzaW9uIG51bWJlciBvZiB0aGUgR1NNUCBwcm90b2Nv bCBiZWluZyB1c2VkIGluIHRoaXMKICAgICAgICBzZXNzaW9uLiAgQU5DUCB1c2VzIHN1Yi12ZXJz aW9uIDEgb2YgdGhlIEdTTVAgcHJvdG9jb2wuICBbUkZDCiAgICAgICAgRWRpdG9yJ3Mgbm90ZTog c3ViLXZlcnNpb24gbmVlZHMgdG8gYmUgY2hhbmdlZCBmcm9tIDEgdG8gMiB1cG9uCiAgICAgICAg cHVibGljYXRpb25dCgogICBSZXN1bHQ6CgogICAgICBUaGUgUmVzdWx0IGZpZWxkIGRlcml2ZWQg ZnJvbSBHU01QIFtSRkMzMjkyXSBoYXMgdGhlIGZvbGxvd2luZwogICAgICBjb2RlczoKCgoKICAg ICAgICAgSWdub3JlOgoKCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJp bCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgog ICAgICAgICAgICBSZXMgPSAweDAwIC0gSWdub3JlIHRoaXMgZmllbGQgb24gcmVjZWlwdCBhbmQg Zm9sbG93IHRoZQogICAgICAgICAgICBwcm9jZWR1cmVzIHNwZWNpZmllZCBmb3IgdGhlIHJlY2Vp dmVkIG1lc3NhZ2UgdHlwZS4KCiAgICAgICAgIE5hY2s6CgogICAgICAgICAgICBSZXMgPSAweDAx IC0gUmVzdWx0IGNvZGUgaW5kaWNhdGluZyB0aGF0IG5vIHJlc3BvbnNlIGlzCiAgICAgICAgICAg IGV4cGVjdGVkIHRvIHRoZSBtZXNzYWdlIG90aGVyIHRoYW4gaW4gY2FzZXMgb2YgZmFpbHVyZQog ICAgICAgICAgICBjYXVzZWQgZHVyaW5nIHRoZSBwcm9jZXNzaW5nIG9mIHRoZSBtZXNzYWdlIGNv bnRlbnRzIG9yIHRoYXQKICAgICAgICAgICAgb2YgdGhlIGNvbnRhaW5lZCBkaXJlY3RpdmUocyku CgoKCiAgICAgICAgIEFja0FsbDoKCgoKICAgICAgICAgICAgUmVzID0gMHgwMiAtIFJlc3VsdCBj b2RlIGluZGljYXRpbmcgdGhhdCBhIHJlc3BvbnNlIHRvIHRoZQogICAgICAgICAgICBtZXNzYWdl IGlzIHJlcXVlc3RlZCBpbiBhbGwgY2FzZXMuICBJdCBpcyBzcGVjaWZpY2FsbHkKICAgICAgICAg ICAgaW50ZW5kZWQgdG8gYmUgdXNlZCBpbiBzb21lIGNhc2VzIGZvciBSZXF1ZXN0IG1lc3NhZ2Vz IG9ubHksCiAgICAgICAgICAgIGFuZCBpcyBub3QgdG8gYmUgdXNlZCBpbiBFdmVudCBtZXNzYWdl cy4KCgoKICAgICAgICAgU3VjY2VzczoKCgoKICAgICAgICAgICAgUmVzID0gMHgwMyAtIFNldCBi eSByZWNlaXZlciB0byBpbmRpY2F0ZSBzdWNjZXNzZnVsCiAgICAgICAgICAgIGV4ZWN1dGlvbiBv ZiBhbGwgZGlyZWN0aXZlcyBpbiB0aGUgY29ycmVzcG9uZGluZyBSZXF1ZXN0CiAgICAgICAgICAg IG1lc3NhZ2UuCgoKCiAgICAgICAgIEZhaWx1cmU6CgoKCiAgICAgICAgICAgIFJlcyA9IDB4NCAt IFNldCBieSByZWNlaXZlciBpbiB0aGUgUmVzcG9uc2UgbWVzc2FnZSBpZiBvbmUKICAgICAgICAg ICAgb3IgbW9yZSBkaXJlY3RpdmVzIGluIHRoZSBjb3JyZXNwb25kaW5nIFJlcXVlc3QgbWVzc2Fn ZQogICAgICAgICAgICBmYWlscy4KCgoKICAgTWVzc2FnZS1UeXBlOgoKCgoKCgoKIFdhZGh3YSwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1Bh Z2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAg ICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgICAgVGhlIEdTTVAgYW5kIEFOQ1AgbWVzc2Fn ZSB0eXBlLgoKICAgQ29kZToKCiAgICAgIFRoaXMgZmllbGQgZ2l2ZXMgZnVydGhlciBpbmZvcm1h dGlvbiBjb25jZXJuaW5nIHRoZSByZXN1bHQgaW4gYQogICAgICByZXNwb25zZSBtZXNzYWdlLiAg SXQgaXMgbW9zdGx5IHVzZWQgdG8gcGFzcyBhbiBlcnJvciBjb2RlIGluIGEKICAgICAgZmFpbHVy ZSByZXNwb25zZSBidXQgY2FuIGFsc28gYmUgdXNlZCB0byBnaXZlIGZ1cnRoZXIgaW5mb3JtYXRp b24KICAgICAgaW4gYSBzdWNjZXNzIHJlc3BvbnNlIG1lc3NhZ2Ugb3IgYW4gZXZlbnQgbWVzc2Fn ZS4gIEluIGEgcmVxdWVzdAogICAgICBtZXNzYWdlLCB0aGUgY29kZSBmaWVsZCBpcyBub3QgdXNl ZCBhbmQgaXMgc2V0IHRvIHplcm8uICBJbiBhbgogICAgICBhZGphY2VuY3kgcHJvdG9jb2wgbWVz c2FnZSwgdGhlIENvZGUgZmllbGQgaXMgdXNlZCB0byBkZXRlcm1pbmUKICAgICAgdGhlIGZ1bmN0 aW9uIG9mIHRoZSBtZXNzYWdlLgoKICAgICAgQU5DUCBpbXBsZW1lbnRhdGlvbnMgTUFZIHVzZSBh bnkgb2YgdGhlIENvZGUgdmFsdWVzIHNwZWNpZmllZCBpbgogICAgICB0aGUgSUFOQSByZWdpc3Ry eSAiR2xvYmFsIFN3aXRjaCBNYW5hZ2VtZW50IFByb3RvY29sIHZlcnNpb24gMwogICAgICAoR1NN UHYzKSBGYWlsdXJlIFJlc3BvbnNlIE1lc3NhZ2UgTmFtZSBTcGFjZSIgaWYgdGhleSBhcHBlYXIK ICAgICAgYXBwbGljYWJsZS4gIEluIHBhcnRpY3VsYXIsIHRoZSB2YWx1ZXM6CgogICAgICAyICBJ bnZhbGlkIHJlcXVlc3QgbWVzc2FnZSAoaS5lLiwgYSBwcm9wZXJseSBmb3JtZWQgbWVzc2FnZSB3 aGljaAogICAgICAgICB2aW9sYXRlcyB0aGUgcHJvdG9jb2wgdGhyb3VnaCBpdHMgdGltaW5nIG9y IGRpcmVjdGlvbiBvZgogICAgICAgICB0cmFuc21pc3Npb24pCgogICAgICA0ICBPbmUgb3IgbW9y ZSBvZiB0aGUgc3BlY2lmaWVkIHBvcnRzIGRvIG5vdCBleGlzdAoKICAgICAgNiAgT25lIG9yIG1v cmUgb2YgdGhlIHNwZWNpZmllZCBwb3J0cyBhcmUgZG93bgoKICAgICAgNyAgSW52YWxpZCBQYXJ0 aXRpb24gSUQKCiAgICAgIDE5IE91dCBvZiByZXNvdXJjZXMgKGUuZy4gbWVtb3J5IGV4aGF1c3Rl ZCwgZXRjLikKCiAgICAgIDMwIFRoZSBsaW1pdCBvbiB0aGUgbWF4aW11bSBudW1iZXIgb2YgcG9p bnQtdG8tIG11bHRpcG9pbnQKICAgICAgICAgY29ubmVjdGlvbnMgdGhhdCB0aGUgc3dpdGNoIGNh biBzdXBwb3J0IGhhcyBiZWVuIHJlYWNoZWQKCiAgICAgIDMxIFRoZSBsaW1pdCBvbiB0aGUgbWF4 aW11bSBudW1iZXIgb2YgYnJhbmNoZXMgdGhhdCB0aGUgc3BlY2lmaWVkCiAgICAgICAgIHBvaW50 LXRvLW11bHRpcG9pbnQgY29ubmVjdGlvbiBjYW4gc3VwcG9ydCBoYXMgYmVlbiByZWFjaGVkCgog ICBtYXkgdW5mb3J0dW5hdGVseSBhcHBseSB0byBBTkNQIHVzYWdlLCBpbmNsdWRpbmcgdGhlIGNh c2Ugd2hlcmUKICAgIlBvcnQiIGlzIGludGVycHJldGVkIHRvIG1lYW4gVGFyZ2V0IGFzIGRlZmlu ZWQgaW4gc2VjdGlvbgogICBTZWN0aW9uIDUuNC41LjEuMQoKICAgSW5zdGVhZCBvZiB0aGUgdmFs dWU6CgogICAzICBUaGUgc3BlY2lmaWVkIHJlcXVlc3QgaXMgbm90IGltcGxlbWVudGVkIG9uIHRo aXMgc3dpdGNoCgogICBzcGVjaWZpZWQgYnkgW1JGQzMyOTJdLCB0aGlzIHNwZWNpZmljYXRpb24g ZGVmaW5lcyBhIG5ldyB2YWx1ZToKCgoKCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIg MjAwOQoKCiAgIDgxIFJlcXVlc3QgbWVzc2FnZSB0eXBlIG5vdCBpbXBsZW1lbnRlZAoKICAgVGhp cyB2YWx1ZSBNQVkgYmUgc2VudCBpbiBhIGZhaWx1cmUgcmVzcG9uc2UgZnJvbSBlaXRoZXIgdGhl IEFOIG9yCiAgIHRoZSBOQVMuICBUaGlzIHNwZWNpZmljYXRpb24gYWxzbyBkZWZpbmVzIHRoZSBh ZGRpdGlvbmFsIHZhbHVlczoKCiAgIDgyIFRyYW5zYWN0aW9uIGlkZW50aWZpZXIgb3V0IG9mIHNl cXVlbmNlCgogICA4MyBNYWxmb3JtZWQgbWVzc2FnZQoKICAgODQgVExWIG9yIHZhbHVlIG5vdCBz dXBwb3J0ZWQgYnkgbmVnb3RpYXRlZCBjYXBhYmlsaXR5IHNldAoKICAgQU5DUCBleHRlbnNpb25z IGRlZmluaW5nIG5ldyBjb2RlIHZhbHVlcyBTSE9VTEQgdXNlIHRoZSByYW5nZSAweDAxMDAKICAg dGhyb3VnaCAweDAxZmYgZm9yIHRoaXMgcHVycG9zZS4KCiAgIFBhcnRpdGlvbiBJRDoKCiAgICAg IFRoaXMgZmllbGQgaXMgYSA4IGJpdCBudW1iZXIgd2hpY2ggc2lnbmlmaWVzIGEgcGFydGl0aW9u IG9uIHRoZQogICAgICBBTi4KCgoKICAgVHJhbnNhY3Rpb24gSUQ6CgogICAgICAyNC1iaXQgZmll bGQgc2V0IGJ5IHRoZSBzZW5kZXIgb2YgYSBSZXF1ZXN0IG1lc3NhZ2UgdG8gYXNzb2NpYXRlIGEK ICAgICAgUmVzcG9uc2UgbWVzc2FnZSB3aXRoIHRoZSBvcmlnaW5hbCBSZXF1ZXN0IG1lc3NhZ2Uu ICBUaGUgcmVjZWl2ZXIKICAgICAgb2YgYSBSZXF1ZXN0IG1lc3NhZ2UgcmVmbGVjdHMgdGhlIHRy YW5zYWN0aW9uIElEIGZyb20gdGhlIFJlcXVlc3QKICAgICAgbWVzc2FnZSBpbiB0aGUgY29ycmVz cG9uZGluZyBSZXNwb25zZSBtZXNzYWdlLiAgRm9yIGV2ZW50CiAgICAgIG1lc3NhZ2VzLCB0aGUg dHJhbnNhY3Rpb24gaWRlbnRpZmllciBTSE9VTEQgYmUgc2V0IHRvIHplcm8uICBUaGUKICAgICAg VHJhbnNhY3Rpb24gSWRlbnRpZmllciBpcyBub3QgdXNlZCwgYW5kIHRoZSBmaWVsZCBpcyBub3Qg cHJlc2VudCwKICAgICAgaW4gdGhlIGFkamFjZW5jeSBwcm90b2NvbC4KCiAgIEkgZmxhZzoKCiAg ICAgIEFuIEFOQ1AgaW1wbGVtZW50YXRpb24gU0hPVUxEIHNldCAiSSIgYW5kIHN1Yk1lc3NhZ2Ug ZmllbGRzIHRvIDEKICAgICAgdG8gc2lnbmlmeSBubyBmcmFnbWVudGF0aW9uLgoKICAgTGVuZ3Ro OgoKICAgICAgTGVuZ3RoIG9mIHRoZSBHU01QIG1lc3NhZ2UgaW5jbHVkaW5nIGl0cyBoZWFkZXIg ZmllbGRzIGFuZCBkZWZpbmVkCiAgICAgIEdTTVAgbWVzc2FnZSBib2R5LgoKICAgQWRkaXRpb25h bCBHZW5lcmFsIE1lc3NhZ2UgSW5mb3JtYXRpb246CgogICBvICBBbnkgZmllbGQgaW4gYSBHU01Q IG1lc3NhZ2UgdGhhdCBpcyB1bnVzZWQgb3IgZGVmaW5lZCBhcwogICAgICAicmVzZXJ2ZWQiIE1V U1QgYmUgc2V0IHRvIHplcm8gYnkgdGhlIHNlbmRlciBhbmQgaWdub3JlZCBieSB0aGUKICAgICAg cmVjZWl2ZXI7CgoKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUs IDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgbyAg RmxhZ3MgdGhhdCBhcmUgdW5kZWZpbmVkIHdpbGwgYmUgZGVzaWduYXRlZCBhczogeDogcmVzZXJ2 ZWQuCgogICBGb2xsb3dpbmcgYXJlIHRoZSByZWxldmFudCBHU01QdjMgbWVzc2FnZXMgZGVmaW5l ZCBpbiBbUkZDMzI5Ml0sIHRoYXQKICAgYXJlIGN1cnJlbnRseSB1c2VkIGJ5IEFOQ1AuICBPdGhl ciB0aGFuIHRoZSBtZXNzYWdlIHR5cGVzIGV4cGxpY2l0bHkKICAgbGlzdGVkIGJlbG93LCBubyBv dGhlciBHU01QdjMgbWVzc2FnZXMgYXJlIHVzZWQgYnkgQU5DUCBjdXJyZW50bHkuCgogICBvICBF dmVudCBNZXNzYWdlcwoKICAgICAgKiAgUG9ydCBVUCBNZXNzYWdlCgogICAgICAqICBQb3J0IERP V04gTWVzc2FnZQoKICAgICAgVGhlc2UgbWVzc2FnZXMgYXJlIHVzZWQgYnkgQU5DUCB0b3BvbG9n eSBkaXNjb3ZlcnkgdXNlLWNhc2UuCgogICBvICBQb3J0IE1hbmFnZW1lbnQgTWVzc2FnZXMKCiAg ICAgICogIFRoZXNlIG1lc3NhZ2VzIGFyZSB1c2VkIGJ5IEFOQ1AgImxpbmUgY29uZmlndXJhdGlv biIgdXNlLWNhc2UKICAgICAgICAgYW5kIEFOQ1AgT0FNIHVzZS1jYXNlLgoKICAgbyAgQWRqYWNl bmN5IFByb3RvY29sIE1lc3NhZ2VzCgogICAgICAqICBUaGVzZSBtZXNzYWdlcyBhcmUgdXNlZCB0 byBicmluZyB1cCBhIHByb3RvY29sIGFkamFjZW5jeQogICAgICAgICBiZXR3ZWVuIGEgTkFTIGFu ZCBhbiBBTi4KCiAgIEFOQ1AgbW9kaWZpZXMgYW5kIGV4dGVuZHMgZmV3IGJhc2ljIEdTTVB2MyBw cm9jZWR1cmVzLiAgVGhlc2UKICAgbW9kaWZpY2F0aW9ucyBhbmQgZXh0ZW5zaW9ucyBhcmUgc3Vt bWFyaXplZCBiZWxvdywgYW5kIGRlc2NyaWJlZCBpbgogICBtb3JlIGRldGFpbCBpbiB0aGUgc3Vj Y2VlZGluZyBzZWN0aW9ucy4KCiAgIG8gIEFOQ1AgcHJvdmlkZXMgc3VwcG9ydCBmb3IgYSBjYXBh YmlsaXR5IG5lZ290aWF0aW9uIG1lY2hhbmlzbQogICAgICBiZXR3ZWVuIEFOQ1AgcGVlcnMgYnkg ZXh0ZW5kaW5nIHRoZSBHU01QdjMgYWRqYWNlbmN5IHByb3RvY29sLgogICAgICBUaGlzIG1lY2hh bmlzbSBhbmQgY29ycmVzcG9uZGluZyBhZGphY2VuY3kgbWVzc2FnZSBleHRlbnNpb25zIGFyZQog ICAgICBkZWZpbmVkIGluIHNlY3Rpb24gU2VjdGlvbiA1LjMKCiAgIG8gIFRDUCBjb25uZWN0aW9u IGVzdGFibGlzaG1lbnQgcHJvY2VkdXJlIGluIEFOQ1AgZGV2aWF0ZXMgc2xpZ2h0bHkKICAgICAg ZnJvbSB0aGUgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IGluIEdTTVB2MyBhcyBzcGVjaWZpZWQg aW4KICAgICAgW1JGQzMyOTNdLiAgVGhpcyBpcyBkZXNjcmliZWQgaW4gc2VjdGlvbiBTZWN0aW9u IDUuMQoKICAgbyAgQU5DUCBtYWtlcyBHU01QdjMgbWVzc2FnZXMgZXh0ZW5zaWJsZSBhbmQgZmxl eGlibGUgYnkgYWRkaW5nIGEKICAgICAgZ2VuZXJhbCAiZXh0ZW5zaW9uIGJsb2NrIiB0byB0aGUg ZW5kIG9mIHRoZSByZWxldmFudCBHU01QdjMKICAgICAgbWVzc2FnZXMuICBUaGUgImV4dGVuc2lv biBibG9jayIgY29udGFpbnMgYSBUTFYgc3RydWN0dXJlIHRvIGNhcnJ5CiAgICAgIGluZm9ybWF0 aW9uIHJlbGV2YW50IHRvIGVhY2ggQU5DUCB1c2UtY2FzZS4gIFRoZSBmb3JtYXQgb2YgdGhlCiAg ICAgICJleHRlbnNpb24gYmxvY2siIGlzIGRlZmluZWQgaW4gc2VjdGlvbiBTZWN0aW9uIDUuNC4x LjEuCgogICBvCgoKCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAy NSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgo1LjEu ICBBTkNQL1RDUCBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQKCiAgIEFOQ1Agd2lsbCB1c2UgVENQ IGZvciBleGNoYW5naW5nIHByb3RvY29sIG1lc3NhZ2VzIFtSRkMzMjkzXS4gZGVmaW5lcwogICB0 aGUgR1NNUCBtZXNzYWdlIGVuY2Fwc3VsYXRpb24gZm9yIFRDUC4gIFRoZSBUQ1Agc2Vzc2lvbiBp cyBpbml0aWF0ZWQKICAgZnJvbSB0aGUgRFNMQU0gKGFjY2VzcyBub2RlKSB0byB0aGUgTkFTIChj b250cm9sbGVyKS4gIFRoaXMgaXMKICAgbmVjZXNzYXJ5IHRvIGF2b2lkIHN0YXRpYyBwcm92aXNp b25pbmcgb24gdGhlIE5BUyBmb3IgYWxsIHRoZSBEU0xBTXMKICAgdGhhdCBhcmUgYmVpbmcgc2Vy dmVkIGJ5IHRoZSBOQVMuICBJdCBpcyBlYXNpZXIgdG8gY29uZmlndXJlIGEgZ2l2ZW4KICAgRFNM QU0gd2l0aCB0aGUgc2luZ2xlIElQIGFkZHJlc3Mgb2YgdGhlIE5BUyB0aGF0IHNlcnZlcyB0aGUg RFNMQU0uCiAgIFRoaXMgaXMgYSBkZXZpYXRpb24gZnJvbSBbUkZDMzI5M10gd2hpY2ggaW5kaWNh dGVzIHRoYXQgdGhlCiAgIGNvbnRyb2xsZXIgaW5pdGlhdGVzIHRoZSBUQ1AgY29ubmVjdGlvbiB0 byB0aGUgc3dpdGNoLgoKICAgV2hlbiBHU01QIG1lc3NhZ2VzIGFyZSBzZW50IG92ZXIgYSBUQ1Ag Y29ubmVjdGlvbiBhIGZvdXItYnl0ZSBUTFYKICAgaGVhZGVyIGZpZWxkIGlzIHByZXBlbmRlZCB0 byB0aGUgR1NNUCBtZXNzYWdlIHRvIHByb3ZpZGUgZGVsaW5lYXRpb24KICAgb2YgR1NNUCBtZXNz YWdlcyB3aXRoaW4gdGhlIFRDUCBzdHJlYW0uCgogICAgICAgMCAgICAgICAgICAgICAgICAgICAx ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgIFR5cGUgKDB4ODgtMEMpICAgICAgICAgfCAgICAg ICAgICAgTGVuZ3RoICAgICAgICAgICAgICB8CiAgICAgIHwtKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgR1NNUCBNZXNzYWdlICAgICAgICAgICAg ICAgICAgICAgICAgICB+CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoKICAgICAgICAg RmlndXJlIDc6IEdTTVB2MyB3aXRoIFRDUC9JUCBFbmNhcHN1bGF0aW9uIG1lc3NhZ2UgZm9ybWF0 CgogICBUeXBlCgogICAgICAgIFRoaXMgMi1ieXRlIGZpZWxkIGluZGljYXRlcyB0aGUgdHlwZSBj b2RlIG9mIHRoZSBmb2xsb3dpbmcKICAgICAgICBtZXNzYWdlLiAgVGhlIHR5cGUgY29kZSBmb3Ig R1NNUCBtZXNzYWdlcyBpcyAweDg4LTBDIChpLmUuLCB0aGUKICAgICAgICBzYW1lIGFzIEdTTVAn cyBFdGhlcnR5cGUpLgoKICAgTGVuZ3RoCgogICAgICAgIFRoaXMgMi1ieXRlIHVuc2lnbmVkIGlu dGVnZXIgaW5kaWNhdGVzIHRoZSB0b3RhbCBsZW5ndGggb2YgdGhlCiAgICAgICAgR1NNUCBtZXNz YWdlIG9ubHkuICBJdCBkb2VzIG5vdCBpbmNsdWRlIHRoZSA0LWJ5dGUgVExWIGhlYWRlci4KCiAg IE5BUyBsaXN0ZW5zIGZvciBpbmNvbWluZyBjb25uZWN0aW9ucyBmcm9tIHRoZSBhY2Nlc3Mgbm9k ZXMuICBQb3J0CiAgIDYwNjggaXMgdXNlZCBmb3IgVENQIGNvbm5lY3Rpb24uICBBZGphY2VuY3kg cHJvdG9jb2wgbWVzc2FnZXMsIHdoaWNoCiAgIGFyZSB1c2VkIHRvIHN5bmNocm9uaXplIHRoZSBO QVMgYW5kIGFjY2Vzcy1ub2RlcyBhbmQgbWFpbnRhaW4KICAgaGFuZHNoYWtlcywgYXJlIHNlbnQg YWZ0ZXIgdGhlIFRDUCBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVkLiAgQU5DUAogICBtZXNzYWdl cyBvdGhlciB0aGFuIGFkamFjZW5jeSBwcm90b2NvbCBtZXNzYWdlcyBtYXkgYmUgc2VudCBvbmx5 CiAgIGFmdGVyIHRoZSBhZGphY2VuY3kgcHJvdG9jb2wgaGFzIGFjaGlldmVkIHN5bmNocm9uaXph dGlvbi4KCiAgIEluIHRoZSBjYXNlIG9mIEFUTSBhY2Nlc3MsIGEgc2VwYXJhdGUgUFZDIChjb250 cm9sIGNoYW5uZWwpIGNhcGFibGUKICAgb2YgdHJhbnNwb3J0aW5nIElQIHdvdWxkIGJlIGNvbmZp Z3VyZWQgYmV0d2VlbiBOQVMgYW5kIHRoZSBEU0xBTSBmb3IKCgoKIFdhZGh3YSwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAg ICAgT2N0b2JlciAyMDA5CgoKICAgQU5DUCBtZXNzYWdlcy4KCiAgIEluIGNhc2Ugb2YgYW4gRXRo ZXJuZXQgYWNjZXNzL2FnZ3JlZ2F0aW9uIG5ldHdvcmssIGEgdHlwaWNhbCBwcmFjdGljZQogICBp cyB0byBzZW5kIHRoZSBBY2Nlc3MgTm9kZSBDb250cm9sIFByb3RvY29sIG1lc3NhZ2VzIG92ZXIg YSBkZWRpY2F0ZWQKICAgRXRoZXJuZXQgVmlydHVhbCBMQU4gKFZMQU4pIHVzaW5nIGEgc2VwYXJh dGUgVkxBTiBpZGVudGlmaWVyIChWTEFOCiAgIElEKS4KCjUuMi4gIEFOQ1AgQ29ubmVjdGlvbiBr ZWVwYWxpdmUKCiAgIEdTTVB2MyBkZWZpbmVzIGFuIGFkamFjZW5jeSBwcm90b2NvbC4gIFRoZSBh ZGphY2VuY3kgcHJvdG9jb2wgaXMgdXNlZAogICB0byBzeW5jaHJvbml6ZSBzdGF0ZXMgYWNyb3Nz IHRoZSBsaW5rLCB0byBuZWdvdGlhdGUgd2hpY2ggdmVyc2lvbiBvZgogICB0aGUgR1NNUCBwcm90 b2NvbCB0byB1c2UsIHRvIGRpc2NvdmVyIHRoZSBpZGVudGl0eSBvZiB0aGUgZW50aXR5IGF0CiAg IHRoZSBvdGhlciBlbmQgb2YgYSBsaW5rLCBhbmQgdG8gZGV0ZWN0IHdoZW4gaXQgY2hhbmdlcy4g IEdTTVAgaXMgYQogICBoYXJkIHN0YXRlIHByb3RvY29sLiAgSXQgaXMgdGhlcmVmb3JlIGltcG9y dGFudCB0byBkZXRlY3QgbG9zcyBvZgogICBjb250YWN0IGJldHdlZW4gc3dpdGNoIGFuZCBjb250 cm9sbGVyLCBhbmQgdG8gZGV0ZWN0IGFueSBjaGFuZ2Ugb2YKICAgaWRlbnRpdHkgb2Ygc3dpdGNo IG9yIGNvbnRyb2xsZXIuICBObyBwcm90b2NvbCBtZXNzYWdlcyBvdGhlciB0aGFuCiAgIHRob3Nl IG9mIHRoZSBhZGphY2VuY3kgcHJvdG9jb2wgbWF5IGJlIHNlbnQgYWNyb3NzIHRoZSBsaW5rIHVu dGlsIHRoZQogICBhZGphY2VuY3kgcHJvdG9jb2wgaGFzIGFjaGlldmVkIHN5bmNocm9uaXphdGlv bi4gIFRoZXJlIGFyZSBubwogICBjaGFuZ2VzIHRvIHRoZSBiYXNlIEdTTVAgYWRqYWNlbmN5IHBy b3RvY29sIGZvciBpbXBsZW1lbnRpbmcgQU5DUC4KCiAgIFRoZSBOQVMgd2lsbCBzZXQgdGhlIE0t ZmxhZyBpbiB0aGUgU1lOIG1lc3NhZ2UgKHNpZ25pZnlpbmcgaXQgaXMgdGhlCiAgIG1hc3Rlciku ICBPbmNlIHRoZSBhZGphY2VuY3kgaXMgZXN0YWJsaXNoZWQsIHBlcmlvZGljIGFkamFjZW5jeQog ICBtZXNzYWdlcyAodHlwZSBBQ0spIGFyZSBleGNoYW5nZWQuICBUaGUgZGVmYXVsdCBBQ0sgaW50 ZXJ2YWwgYXMKICAgYWR2ZXJ0aXNlZCBpbiB0aGUgYWRqYWNlbmN5IG1lc3NhZ2VzIGlzIDEwIHNl YyBmb3IgQU5DUC4gIEl0IFNIT1VMRAogICBiZSBjb25maWd1cmFibGUgYW5kIGlzIGFuIGltcGxl bWVudGF0aW9uIGNob2ljZS4gIEl0IGlzIHJlY29tbWVuZGVkCiAgIHRoYXQgYm90aCBlbmRzIHNw ZWNpZnkgdGhlIHNhbWUgdGltZXIgdmFsdWUsIGluIG9yZGVyIHRvIGFjaGlldmUgdGhpcwogICBi ZWhhdmlvciBib3RoIGVuZHMgbG9vayBhdCB0aGUgdGltZXIgdmFsdWVzIGluIHRoZSByZWNlaXZl ZCAoaW5pdGlhbCkKICAgYWRqYWNlbmN5IG1lc3NhZ2UgYW5kIGFncmVlIHRvIHVzZSB0aGUgaGln aGVyIG9mIHRoZSB0d28gdmFsdWVzLgogICBUaGF0IGlzLCB0aGUgbm9kZSB0aGF0IHJlY2VpdmVz IGEgaGlnaGVyIHRpbWVyIHZhbHVlIHRoYW4gaXRzIG93biwKICAgd2lsbCByZXBseSBpbiBpdHMg c3Vic2VxdWVudCBhZGphY2VuY3kgbWVzc2FnZXMgKHN1Y2ggYXMgU1lOQUNLLCBBQ0spCiAgIHdp dGggdGhlIGhpZ2hlciB0aW1lciB2YWx1ZS4KCiAgIFRoZSBHU01QIGFkamFjZW5jeSBtZXNzYWdl IGRlZmluZWQgaW4gW1JGQzMyOTJdIGlzIGV4dGVuZGVkIGZvciBBTkNQCiAgIGFuZCBpcyBzaG93 biBpbiBzZWN0aW9uIDUuMyBpbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhpcyBzZWN0aW9uLiAgVGhl CiAgIDgtYml0ICJ2ZXJzaW9uIiBmaWVsZCBpbiB0aGUgYWRqYWNlbmN5IHByb3RvY29sIG1lc3Nh Z2VzIGlzIG1vZGlmaWVkCiAgIHRvIGNhcnJ5IHRoZSB2ZXJzaW9uIGFuZCBzdWItdmVyc2lvbiBv ZiB0aGUgR1NNUCBwcm90b2NvbCBmb3IgdmVyc2lvbgogICBuZWdvdGlhdGlvbi4gIEFOQ1AgdXNl cyB2ZXJzaW9uIDMgYW5kIHN1Yi12ZXJzaW9uIDEgb2YgR1NNUCBwcm90b2NvbC4KICAgW1JGQyBF ZGl0b3IncyBub3RlOiBzdWItdmVyc2lvbiBuZWVkcyB0byBiZSBjaGFuZ2VkIGZyb20gMSB0byAy IHVwb24KICAgcHVibGljYXRpb24uXSAgSW4gdGhlIGFkamFjZW5jeSBwcm90b2NvbCB0aGUgdmVy c2lvbiBhbmQgdGhlIHN1Yi0KICAgdmVyc2lvbiBmaWVsZHMgYXJlIHVzZWQgZm9yIHZlcnNpb24g bmVnb3RpYXRpb24uICBUaGUgdmVyc2lvbgogICBuZWdvdGlhdGlvbiBpcyBwZXJmb3JtZWQgYmVm b3JlIHN5bmNocm9uaXNhdGlvbiBpcyBhY2hpZXZlZC4gIEluIGEKICAgU1lOIG1lc3NhZ2UgdGhl IHZlcnNpb24vc3ViLXZlcnNpb24gZmllbGRzIGFsd2F5cyBjb250YWluIHRoZSBoaWdoZXN0CiAg IHZlcnNpb24gdW5kZXJzdG9vZCBieSB0aGUgc2VuZGVyLiAgQSByZWNlaXZlciByZWNlaXZpbmcg YSBTWU4gbWVzc2FnZQogICB3aXRoIGEgdmVyc2lvbi9zdWItdmVyc2lvbiBoaWdoZXIgdGhhbiB1 bmRlcnN0b29kIHdpbGwgaWdub3JlIHRoYXQKICAgbWVzc2FnZS4gIEEgcmVjZWl2ZXIgcmVjZWl2 aW5nIGEgU1lOIG1lc3NhZ2Ugd2l0aCBhIHZlcnNpb24vCiAgIHN1Yi12cmVzaW9uIGxvd2VyIHRo YW4gaXRzIG93biBoaWdoZXN0IHZlcnNpb24vc3ViLXZlcnNpb24sIGJ1dCBhCiAgIHZlcnNpb24v c3ViLXZlcnNpb24gdGhhdCBpdCB1bmRlcnN0YW5kcywgd2lsbCByZXBseSB3aXRoIGEgU1lOQUNL CiAgIHdpdGggdGhlIHZlcnNpb24vc3ViLXZlcnNpb24gZnJvbSB0aGUgcmVjZWl2ZWQgU1lOIGlu IGl0cyBBTkNQCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAy MDEwICAgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgIHZlcnNp b24vc3ViLXZlcnNpb24gZmllbGRzLiAgVGhpcyBkZWZpbmVzIHRoZSB2ZXJzaW9uL3N1Yi12ZXJz aW9uIG9mCiAgIHRoZSBBTkNQIHByb3RvY29sIHRvIGJlIHVzZWQgd2hpbGUgdGhlIGFkamFjZW5j eSBwcm90b2NvbCByZW1haW5zCiAgIHN5bmNocm9uaXNlZC4gIEFsbCBvdGhlciBtZXNzYWdlcyB3 aWxsIHVzZSB0aGUgYWdyZWVkIHZlcnNpb24gaW4gdGhlCiAgIHZlcnNpb24vc3ViLXZlcnNpb24g ZmllbGRzLgoKICAgVGhlIHNlbWFudGljcyBhbmQgc3VnZ2VzdGVkIHZhbHVlcyBmb3IgQ29kZSwg IlNlbmRlciBOYW1lIiwgIlJlY2VpdmVyCiAgIE5hbWUiLCAiU2VuZGVyIEluc3RhbmNlIiwgYW5k ICJSZWNlaXZlciBJbnN0YW5jZSIgZmllbGRzIGFyZSBhcwogICBkZWZpbmVkIGluIFtSRkMzMjky XS4gIFRoZSAiU2VuZGVyIFBvcnQiLCBhbmQgIlJlY2VpdmVyIFBvcnQiIHNob3VsZAogICBiZSBz ZXQgdG8gMCBieSBib3RoIGVuZHMuICBUaGUgcFR5cGUgZmllbGQgc2hvdWxkIGJlIHNldCB0byAw LiAgVGhlCiAgIHBGbGFnIHNob3VsZCBiZSBzZXQgdG8gMS4KCiAgIElmIHRoZSBhZGphY2VuY3kg dGltZXMgb3V0IG9uIGVpdGhlciBlbmQsIGR1ZSB0byBub3QgcmVjZWl2aW5nIGFuCiAgIGFkamFj ZW5jeSBtZXNzYWdlIGZvciBhIGR1cmF0aW9uIG9mICgzICogVGltZXIgdmFsdWUpLCB3aGVyZSB0 aGUKICAgdGltZXIgdmFsdWUgaXMgc3BlY2lmaWVkIGluIHRoZSBhZGphY2VuY3kgbWVzc2FnZSwg YWxsIHRoZSBzdGF0ZQogICByZWNlaXZlZCBmcm9tIHRoZSBBTkNQIG5laWdoYm9yIHNob3VsZCBi ZSBjbGVhbmVkIHVwLCBhbmQgdGhlIFRDUAogICBjb25uZWN0aW9uIHNob3VsZCBiZSBjbG9zZWQu ICBUaGUgTkFTIHdvdWxkIGNvbnRpbnVlIHRvIGxpc3RlbiBmb3IKICAgbmV3IGNvbm5lY3Rpb24g cmVxdWVzdHMuICBUaGUgRFNMQU0gd2lsbCB0cnkgdG8gcmUtZXN0YWJsaXNoIHRoZSBUQ1AKICAg Y29ubmVjdGlvbiBhbmQgYm90aCBzaWRlcyB3aWxsIGF0dGVtcHQgdG8gcmUtZXN0YWJsaXNoIHRo ZSBhZGphY2VuY3kuCgogICBUaGUgaGFuZGxpbmcgZGVmaW5lZCBhYm92ZSB3aWxsIG5lZWQgc29t ZSBtb2RpZmljYXRpb25zIHdoZW4gQU5DUAogICBncmFjZWZ1bCByZXN0YXJ0IHByb2NlZHVyZXMg YXJlIGRlZmluZWQuICBUaGVzZSBwcm9jZWR1cmVzIHdpbGwgYmUKICAgZGVmaW5lZCBpbiBhIHNl cGFyYXRlIGRyYWZ0LgoKNS4zLiAgQ2FwYWJpbGl0eSBuZWdvdGlhdGlvbgoKICAgVGhlIGFkamFj ZW5jeSBtZXNzYWdlIGFzIGRlZmluZWQgaW4gW1JGQzMyOTJdIGlzIGV4dGVuZGVkIHRvIGNhcnJ5 CiAgICJDYXBhYmlsaXR5IFRMVnMiLiAgQm90aCB0aGUgTkFTIGFuZCB0aGUgYWNjZXNzIG5vZGUg d2lsbCBhZHZlcnRpc2UKICAgc3VwcG9ydGVkIGNhcGFiaWxpdGllcyBpbiB0aGUgb3JpZ2luYXRl ZCBhZGphY2VuY3kgbWVzc2FnZXMuICBJZiBhCiAgIHJlY2VpdmVkIGFkamFjZW5jeSBtZXNzYWdl IGluZGljYXRlcyBhYnNlbmNlIG9mIHN1cHBvcnQgZm9yIGEKICAgY2FwYWJpbGl0eSB0aGF0IGlz IHN1cHBvcnRlZCBieSB0aGUgcmVjZWl2aW5nIGRldmljZSwgaXQgd2lsbCB0dXJuCiAgIG9mZiB0 aGUgY2FwYWJpbGl0eSBsb2NhbGx5IGFuZCB3aWxsIHNlbmQgYW4gdXBkYXRlZCBhZGphY2VuY3kg bWVzc2FnZQogICB3aXRoIHRoZSBjYXBhYmlsaXR5IHR1cm5lZCBvZmYgdG8gbWF0Y2ggdGhlIHJl Y2VpdmVkIGNhcGFiaWxpdHkgc2V0LgogICBUaGlzIHByb2Nlc3Mgd2lsbCBldmVudHVhbGx5IHJl c3VsdCBpbiBib3RoIHNpZGVzIGFncmVlaW5nIG9uIHRoZQogICBtaW5pbWFsIHNldCBvZiBzdXBw b3J0ZWQgY2FwYWJpbGl0aWVzLiAgVGhlIGFkamFjZW5jeSB3aWxsIG5vdCBjb21lCiAgIHVwIHVu bGVzcyB0aGUgY2FwYWJpbGl0aWVzIGFkdmVydGlzZWQgYnkgdGhlIGNvbnRyb2xsZXIgYW5kIHRo ZQogICBjb250cm9sbGVkIGRldmljZSBtYXRjaC4KCiAgIEFmdGVyIGluaXRpYWwgc3luY2hyb25p emF0aW9uLCBpZiBhdCBhbnl0aW1lIGEgY2FwYWJpbGl0eSBtaXNtYXRjaCBpcwogICBkZXRlY3Rl ZCwgdGhlIGFkamFjZW5jeSB3aWxsIGJlIGJyb3VnaHQgZG93biAoUlNUQUNLIHdpbGwgYmUKICAg Z2VuZXJhdGVkIGJ5IHRoZSBkZXZpY2UgZGV0ZWN0aW5nIHRoZSBtaXNtYXRjaCksIGFuZCBzeW5j aHJvbml6YXRpb24KICAgd2lsbCBiZSByZS1hdHRlbXB0ZWQuCgoKCgoKCgoKCgogV2FkaHdhLCBl dCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFn ZSAyMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAg ICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgICAgIHwgICBWZXIgfCAgU3ViICB8IE1lc3NhZ2UgVHlwZSAgfCAgICAgVGlt ZXIgICAgIHxNfCAgICAgQ29kZSAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgIFNlbmRlciBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgUmVjZWl2ZXIgTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBQ b3J0ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgUmVjZWl2ZXIgUG9ydCAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgUFR5cGUgfCBQRmxhZyB8ICAgICAgICAgICAgICAg U2VuZGVyIEluc3RhbmNlICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwg UGFydGl0aW9uIElEICB8ICAgICAgICAgICAgICBSZWNlaXZlciBJbnN0YW5jZSAgICAgICAgICAg ICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgVGVjaCBUeXBlICAgICB8ICMgb2YgVExWcyAg ICAgfCBUb3RhbCBMZW5ndGggICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgIH4gICAgICAgICAgICAgICAgICAgQ2FwYWJpbGl0eSBUTFZzICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB+CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDgKCiAgIFRoZSBmb3JtYXQg b2YgY2FwYWJpbGl0eSBUTFYgaXM6CgogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICBDYXBhYmls aXR5IFR5cGUgICAgICAgICB8ICAgQ2FwYWJpbGl0eSBMZW5ndGggICAgICAgICAgICAgfAogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgICB+ICAgICAgICAg ICAgICAgICAgIENhcGFiaWxpdHkgRGF0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfgog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwoKCiAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgOTogQ2FwYWJp bGl0eSBUTFYKCiAgIFRoZSBUZWNoIFR5cGUgZmllbGQgdHlwZSBpbmRpY2F0ZXMgdGhlIHRlY2hu b2xvZ3kgdG8gd2hpY2ggdGhlCiAgIGNhcGFiaWxpdHkgZXh0ZW5zaW9uIGFwcGxpZXMuICBGb3Ig YWNjZXNzIG5vZGUgY29udHJvbCBpbiBjYXNlIG9mIERTTAogICBuZXR3b3JrcywgbmV3IHR5cGUg IkRTTCIgaXMgcHJvcG9zZWQuICBUaGUgdmFsdWUgZm9yIHRoaXMgZmllbGQgaXMKICAgMHgwNS4g IFRoaXMgaXMgdGhlIGZpcnN0IGF2YWlsYWJsZSB2YWx1ZSBpbiB0aGUgcmFuZ2UgdGhhdCBpcyBu b3QKICAgY3VycmVudGx5IGFsbG9jYXRlZC4gIEl0IHdpbGwgbmVlZCB0byBiZSByZXNlcnZlZCB3 aXRoIElBTkEuCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwg MjAxMCAgICAgICAgICAgICAgICBbUGFnZSAyM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICBDYXBh YmlsaXR5IGxlbmd0aCBpcyB0aGUgbnVtYmVyIG9mIGFjdHVhbCBieXRlcyBjb250YWluZWQgaW4g dGhlCiAgIHZhbHVlIHBvcnRpb24gb2YgdGhlIFRMVi4gIFRoZSBUTFYgaXMgcGFkZGVkIHRvIGEg NC1vY3RldCBhbGlnbm1lbnQuCiAgIFRoZXJlZm9yZSwgYSBUTFYgd2l0aCBubyBkYXRhIHdpbGwg Y29udGFpbiBhIHplcm8gaW4gdGhlIGxlbmd0aCBmaWVsZAogICAoaWYgY2FwYWJpbGl0eSBkYXRh IGlzIHRocmVlIG9jdGV0cywgdGhlIGxlbmd0aCBmaWVsZCB3aWxsIGNvbnRhaW4gYQogICB0aHJl ZSwgYnV0IHRoZSBzaXplIG9mIHRoZSBhY3R1YWwgVExWIGlzIGVpZ2h0IG9jdGV0cykuICBDYXBh YmlsaXR5CiAgIGRhdGEgZmllbGQgY2FuIGJlIGVtcHR5IGlmIHRoZSBjYXBhYmlsaXR5IGlzIGp1 c3QgYSBib29sZWFuLiAgSW4gY2FzZQogICB0aGUgY2FwYWJpbGl0eSBpcyBhIGJvb2xlYW4sIGl0 IGlzIGluZmVycmVkIGZyb20gdGhlIHByZXNlbmNlIG9mIHRoZQogICBUTFYgKHdpdGggbm8gZGF0 YSkuCgogICBDYXBhYmlsaXR5IGRhdGEgcHJvdmlkZXMgdGhlIGZsZXhpYmlsaXR5IHRvIGFkdmVy dGlzZSBtb3JlIHRoYW4gbWVyZQogICBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIGEgY2FwYWJpbGl0 eS4gIENhcGFiaWxpdHkgdHlwZXMgY2FuIGJlCiAgIHJlZ2lzdGVyZWQgd2l0aCBJQU5BLiAgRm9s bG93aW5nIGNhcGFiaWxpdGllcyBhcmUgZGVmaW5lZCBmb3IgQU5DUCBhcwogICBhcHBsaWVkIHRv IERTTCBhY2Nlc3M6CgogICAxLiAgQ2FwYWJpbGl0eSBUeXBlIDogRHluYW1pYy1Ub3BvbG9neS1E aXNjb3ZlcnkgPSAweDAxCgogICAgICAgICAgTGVuZ3RoIChpbiBieXRlcykgOiAwCgogICAgICAg ICAgQ2FwYWJpbGl0eSBEYXRhIDogTlVMTAoKICAgMi4gIENhcGFiaWxpdHkgVHlwZSA6IExpbmUt Q29uZmlndXJhdGlvbiA9IDB4MDIKCiAgICAgICAgICBMZW5ndGggKGluIGJ5dGVzKSA6IDAKCiAg ICAgICAgICBDYXBhYmlsaXR5IERhdGEgOiBOVUxMCgogICAzLiAgQ2FwYWJpbGl0eSBUeXBlIDog VHJhbnNhY3Rpb25hbC1NdWx0aWNhc3QgPSAweDAzIChjb250cm9sbGVyIGkuZS4KICAgICAgIE5B UyB0ZXJtaW5hdGVzIElHTVAgbWVzc2FnZXMgZnJvbSBzdWJzY3JpYmVycywgYW5kIHZpYSBsMiBj b250cm9sCiAgICAgICBwcm90b2NvbCwgc2lnbmFscyBzdGF0ZSB0byB0aGUgYWNjZXNzLW5vZGVz IChlLmcuICBEU0xBTXMpIHRvCiAgICAgICBlbmFibGUgbGF5ZXIyIHJlcGxpY2F0aW9uIG9mIG11 bHRpY2FzdCBzdHJlYW1zLiAgSW4gQVRNIGFjY2VzcwogICAgICAgbmV0d29yayB0aGlzIGltcGxp ZXMgdGhhdCBOQVMgaW5zdHJ1Y3RzIHRoZSBhY2Nlc3Mtbm9kZSB0byBzZXR1cAogICAgICAgYSBQ Mk1QIGNyb3NzLWNvbm5lY3QuICBUaGUgZGV0YWlscyBvZiB0aGlzIHdpbGwgYmUgY292ZXJlZCBp biBhCiAgICAgICBzZXBhcmF0ZSBJRC4KCiAgICAgICAgICBMZW5ndGggKGluIGJ5dGVzKSA6IDAK CiAgICAgICAgICBDYXBhYmlsaXR5IERhdGEgOiBOVUxMCgogICA0LiAgQ2FwYWJpbGl0eSBUeXBl IDogT0FNID0gMHgwNAoKICAgICAgICAgIExlbmd0aCAoaW4gYnl0ZXMpIDogMAoKICAgICAgICAg IENhcGFiaWxpdHkgRGF0YSA6IE5VTEwKCgoKCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3Rv YmVyIDIwMDkKCgo1LjQuICBHU01QIE1lc3NhZ2UgRXh0ZW5zaW9ucyBmb3IgQWNjZXNzIE5vZGUg Q29udHJvbAoKNS40LjEuICBHZW5lcmFsIEV4dGVuc2lvbnMKCiAgIEV4dGVuc2lvbnMgdG8gR1NN UCBtZXNzYWdlcyBmb3IgdmFyaW91cyB1c2UtY2FzZXMgb2YgIkFjY2VzcyBOb2RlCiAgIENvbnRy b2wiIG1lY2hhbmlzbSBhcmUgZGVmaW5lZCBpbiBzZWN0aW9ucyBTZWN0aW9uIDUuNC4yIHRvCiAg IFNlY3Rpb24gNS40LjQuICBIb3dldmVyLCBzdWItc2VjdGlvblNlY3Rpb24gNS40LjEuMSBiZWxv dyBkZWZpbmVzCiAgIGV4dGVuc2lvbnMgdG8gR1NNUCB0aGF0IGhhdmUgZ2VuZXJhbCBhcHBsaWNh YmlsaXR5IGFuZCBzZWN0aW9uCiAgIFNlY3Rpb24gNS40LjUgaW50cm9kdWNlcyBhbm90aG9yIG1l c3NhZ2luZyBwcmluY2lwbGUgYW5kIGFkZGl0aW9uYWwKICAgZ2VuZXJhbCBwdXJwb3NlIFRMVnMg dGhhdCBjb3VsZCBiZSB1c2VkIHRvIGRldmVsb3AgbmV3IHVzZSBjYXNlcyBpbgogICBmdXR1cmUu Cgo1LjQuMS4xLiAgRXh0ZW5zaW9uIFRMVgoKICAgSW4gb3JkZXIgdG8gcHJvdmlkZSBmbGV4aWJp bGl0eSBhbmQgZXh0ZW5zaWJpbGl0eSBjZXJ0YWluIEdTTVAKICAgbWVzc2FnZXMgc3VjaCBhcyAi UE9SVCBNQU5BR0VNRU5UIiBhbmQgIkVWRU5UIiBtZXNzYWdlcyBkZWZpbmVkIGluCiAgIFtSRkMz MjkyXSBoYXZlIGJlZW4gbW9kaWZpZWQgdG8gaW5jbHVkZSBhbiBleHRlbnNpb24gYmxvY2sgdGhh dAogICBmb2xsb3dzIGEgVExWIHN0cnVjdHVyZS4gIEluZGl2aWR1YWwgbWVzc2FnZXMgaW4gdGhl IGZvbGxvd2luZwogICBzZWN0aW9ucyBkZXNjcmliZSB0aGUgdXNhZ2UgYW5kIGZvcm1hdCBvZiB0 aGUgZXh0ZW5zaW9uIGJsb2NrLgoKICAgQWxsIEV4dGVuc2lvbiBUTFZzIHdpbGwgYmUgZGVzaWdu YXRlZCBhcyBmb2xsb3c6CgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHx4fHh8 eHx4fHh8eHx4fHh8IE1lc3NhZ2UgVHlwZSAgfCAgIFRlY2ggVHlwZSAgIHwgQmxvY2sgTGVuZ3Ro ICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIH4gICAgICAgICAgICAgICAgICAgICAgICAg RXh0ZW5zaW9uIFZhbHVlICAgICAgICAgICAgICAgICAgICAgICB+CiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCgogICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEwOiBFeHRlbnNpb24gVExW CgogICAgICB4OiBSZXNlcnZlZCBGbGFncwoKICAgICAgICAgVGhlc2UgYXJlIGdlbmVyYWxseSB1 c2VkIGJ5IHNwZWNpZmljIG1lc3NhZ2VzIGFuZCB3aWxsIGJlCiAgICAgICAgIGRlZmluZWQgaW4g dGhvc2UgbWVzc2FnZXMuCgogICAgICBNZXNzYWdlIFR5cGUKCiAgICAgICAgIEFuIDgtYml0IGZp ZWxkIGNvcnJlc3BvbmRpbmcgdG8gdGhlIG1lc3NhZ2UgdHlwZSB3aGVyZSB0aGUKICAgICAgICAg ZXh0ZW5zaW9uIGJsb2NrIGlzIHVzZWQuCgogICAgICBUZWNoIFR5cGUKCgoKCgoKIFdhZGh3YSwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1Bh Z2UgMjVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAg ICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgICAgICAgQW4gOC1iaXQgZmllbGQgaW5kaWNh dGluZyB0aGUgYXBwbGljYWJsZSB0ZWNobm9sb2d5IHR5cGUgdmFsdWUuCiAgICAgICAgIFRoZSBN ZXNzYWdlIFR5cGUgcGx1cyB0aGUgVGVjaCBWYWx1ZSB1bmlxdWVseSBkZWZpbmUgYSBzaW5nbGUK ICAgICAgICAgRXh0ZW5zaW9uIFR5cGUgYW5kIGNhbiBiZSB0cmVhdGVkIGFzIGEgc2luZ2xlIDE2 IGJpdCBleHRlbnNpb24KICAgICAgICAgdHlwZS4gICJUZWNoIFR5cGUiIHZhbHVlIG9mIDB4MDUg U0hPVUxEIGJlIHVzZWQgYnkgQU5DUCBmb3IgRFNMCiAgICAgICAgIHRlY2hub2xvZ3kgYW5kIDB4 MDEgZm9yIFBPTiB0ZWNobm9sb2d5LgoKICAgICAgICAgICAgMHgwMCBFeHRlbnNpb24gYmxvY2sg bm90IGluIHVzZQoKICAgICAgICAgICAgMHgwMSBQT04KCiAgICAgICAgICAgIDB4MDUgRFNMCgog ICAgICAgICAgICAweDA2IC0gMHhGRSBSZXNlcnZlZAoKICAgICAgICAgICAgMHhGRiBCYXNlIFNw ZWNpZmljYXRpb24gVXNlCgogICAgICBCbG9jayBMZW5ndGgKCiAgICAgICAgIEEgOC1iaXQgZmll bGQgaW5kaWNhdGluZyB0aGUgbGVuZ3RoIG9mIHRoZSBFeHRlbnNpb24gVmFsdWUKICAgICAgICAg ZmllbGQgaW4gYnl0ZXMuICBXaGVuIHRoZSBUZWNoIFR5cGUgPSAweDAwLCB0aGUgbGVuZ3RoIHZh bHVlCiAgICAgICAgIE1VU1QgYmUgc2V0IHRvIDAuCgogICAgICBFeHRlbnNpb24gVmFsdWUKCiAg ICAgICAgIEEgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIHRoYXQgaXMgYW4gaW50ZWdlciBudW1iZXIg b2YgMzIgYml0CiAgICAgICAgIHdvcmRzIGxvbmcuICBUaGUgRXh0ZW5zaW9uIFZhbHVlIGZpZWxk IGlzIGludGVycHJldGVkIGFjY29yZGluZwogICAgICAgICB0byB0aGUgc3BlY2lmaWMgZGVmaW5p dGlvbnMgcHJvdmlkZWQgYnkgdGhlIG1lc3NhZ2VzIGluIHRoZQogICAgICAgICBmb2xsb3dpbmcg c2VjdGlvbnMuLgoKCgo1LjQuMi4gIFRvcG9sb2d5IERpc2NvdmVyeSBFeHRlbnNpb25zCgogICBU aGUgR1NNUCBFdmVudCBtZXNzYWdlIHdpdGggUE9SVCBVUCBtZXNzYWdlIHR5cGUgKDgwKSBpcyB1 c2VkIGZvcgogICBjb252ZXlpbmcgRFNMIGxpbmUgYXR0cmlidXRlcyB0byB0aGUgTkFTLiAgVGhl IG1lc3NhZ2UgU0hPVUxEIGJlCiAgIGdlbmVyYXRlZCB3aGVuIGEgbGluZSBmaXJzdCBjb21lcyBV UCwgb3IgYW55IG9mIHRoZSBhdHRyaWJ1dGVzIG9mIHRoZQogICBsaW5lIGNoYW5nZSBlLmcuIHRo ZSBsaW5lIHJlLXRyYWlucyB0byBhIGRpZmZlcmVudCByYXRlIG9yIG9uZSBvcgogICBtb3JlIG9m IHRoZSBjb25maWd1cmVkIGxpbmUgYXR0cmlidXRlcyBhcmUgYWRtaW5pc3RyYXRpdmVseSBtb2Rp ZmllZC4KICAgQWxzbywgd2hlbiB0aGUgQU5DUCBzZXNzaW9uIGZpcnN0IGNvbWVzIHVwLCB0aGUg RFNMQU0gU0hPVUxEIHRyYW5zbWl0CiAgIGEgUE9SVCBVUCBtZXNzYWdlIHRvIHRoZSBOQVMgZm9y IGVhY2ggbGluZSB0aGF0IGlzIHVwLiAgV2hlbiBhIERTTAogICBsaW5lIGdvZXMgZG93biAoaWRs ZSBvciBzaWxlbnQpLCB0aGUgRFNMQU0gU0hPVUxEIHRyYW5zbWl0IGFuIEV2ZW50CiAgIG1lc3Nh Z2Ugd2l0aCBQT1JUIERPV04gbWVzc2FnZSB0eXBlICg4MSkgdG8gdGhlIE5BUy4gIEl0IGlzCiAg IHJlY29tbWVuZGVkIHRoYXQgdGhlIERTTEFNcyB1c2UgYSBkYW1wZW5pbmcgbWVjaGFuaXNtIHBl ciBEU0wgbGluZSB0bwogICBjb250cm9sIHRoZSByYXRlIG9mIHN0YXRlIGNoYW5nZXMgcGVyIERT TCBsaW5lLCBjb21tdW5pY2F0ZWQgdG8gdGhlCiAgIE5BUy4KCiAgIE5vdCBhbGwgdGhlIGZpZWxk cyBpbiBHU01QIEV2ZW50IG1lc3NhZ2UgYXJlIGFwcGxpY2FibGUgdG8gQU5DUC4gIFRoZQogICBm aWVsZHMgdGhhdCBhcmUgbm90IGFwcGxpY2FibGUgTVVTVCBiZSBzZXQgdG8gemVybyBieSB0aGUg QU5DUCBzZW5kZXIKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUs IDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgYW5k IGlnbm9yZWQgYnkgdGhlIEFOQ1AgcmVjZWl2ZXIuICBUaGUgZmllbGRzIGluIHRoZSBQT1JUIFVQ IGFuZCBQT1JUCiAgIERPV04gbWVzc2FnZXMgdG8gYmUgc2V0IGJ5IHRoZSBBTkNQIHNlbmRlciwg YW5kIGNvcnJlc3BvbmRpbmcKICAgaGFuZGxpbmcgYnkgdGhlIEFOQ1AgcmVjZWl2ZXIgaXMgZGVz Y3JpYmVkIGJlbG93LgoKICAgVGhlIHZlcnNpb24gZmllbGQgTVVTVCBiZSBzZXQgdG8gMywgYW5k IHRoZSBzdWIgZmllbGQgTVVTVCBiZSBzZXQgdG8KICAgMS4gIEFzIGRlZmluZWQgaW4gW1JGQzMy OTJdLCB0aGUgb25lIGJ5dGUgTWVzc2FnZSBUeXBlIGZpZWxkIE1VU1QgYmUKICAgc2V0IHRvIDgw IGZvciBQT1JUIFVQIEV2ZW50IG1lc3NhZ2UsIGFuZCB0byA4MSBmb3IgUE9SVCBET1dOIEV2ZW50 CiAgIE1lc3NhZ2UuICBUaGUgMTIgYml0IENvZGUgZmllbGQgTVVTVCBiZSBzZXQgdG8gMC4gIFRo ZSA0IGJpdCBSZXN1bHQKICAgZmllbGQgTVVTVCBiZSBzZXQgdG8gMCAoc2lnbmlmeWluZyBJZ25v cmUuKSAgSWYgYSBQT1JUIFVQIG1lc3NhZ2UKICAgd2l0aCBhIFJlc3VsdCBmaWVsZCBzZXQgdG8g MCBpcyByZWNlaXZlZCBieSB0aGUgTkFTIGFuZCB0aGUgTkFTIGlzCiAgIGFibGUgdG8gcHJvY2Vz cyB0aGUgbWVzc2FnZSBjb3JyZWN0bHksIHRoZSBOQVMgTVVTVCBOT1QgZ2VuZXJhdGUgYW55CiAg IEFOQ1AgbWVzc2FnZSBpbiByZXNwb25zZSB0byB0aGUgUE9SVCBVUC4gIElmIHRoZSBQT1JUIFVQ IG1lc3NhZ2UKICAgcmVjZWl2ZWQgY2Fubm90IGJlIHByb2Nlc3NlZCBjb3JyZWN0bHkgYnkgdGhl IE5BUyAoZS5nLiB0aGUgbWVzc2FnZQogICBpcyBtYWxmb3JtZWQpIHRoZSBOQVMgTUFZIHJlc3Bv bmQgd2l0aCBhbiBBTkNQIEVycm9yIE1lc3NhZ2UgKFRCRCkKICAgY29udGFpbmluZyB0aGUgcmVh c29uIG9mIHRoZSBmYWlsdXJlLiAgVGhlIDI0LWJpdCBUcmFuc2FjdGlvbgogICBJZGVudGlmaWVy IGZpZWxkIE1VU1QgYmUgc2V0IHRvIDAuICBUaGUgIkkiIGJpdCBhbmQgdGhlIFN1Yk1lc3NhZ2UK ICAgZmllbGQgTVVTVCBiZSBzZXQgdG8gMSB0byBzaWduaWZ5IG5vIGZyYWdtZW50YXRpb24uICBU aGUgTGVuZ3RoIGZpZWxkCiAgIGlzIHR3byBieXRlcyBhbmQgTVVTVCBjb250YWluIHRoZSBsZW5n dGggb2YgdGhlIG1lc3NhZ2UgKGluY2x1ZGluZwogICBoZWFkZXIgYW5kIHRoZSBwYXlsb2FkKSBp biBieXRlcy4KCiAgIFRoZSAiUG9ydCIgZmllbGQsICJQb3J0IFNlc3Npb24gTnVtYmVyIiBmaWVs ZCBhbmQgIkV2ZW50IFNlcXVlbmNlCiAgIE51bWJlciIgZmllbGQgYXJlIDQgYnl0ZXMgZWFjaCwg YW5kIE1VU1QgYmUgc2V0IHRvIDAgYnkgdGhlIEFOQ1AKICAgc2VuZGVyLiAgTEFCRUwgZmllbGQg aW4gZXZlbnQgbWVzc2FnZXMgaXMgZGVmaW5lZCBhcyBhIFRMViBpbgogICBbUkZDMzI5Ml0uICBB TkNQIGRvZXMgTk9UIHVzZSB0aGUgTGFiZWwgVExWLiAgSW4gYm90aCBQT1JUIFVQIGFuZAogICBQ T1JUIERPV04gZXZlbnQgbWVzc2FnZXMgYW4gQU5DUCBzZW5kZXIgTVVTVCB0cmVhdCB0aGUgTGFi ZWwgZmllbGQsCiAgIGltbWVkaWF0ZWx5IGZvbGxvd2luZyB0aGUgIkV2ZW50IFNlcXVlbmNlIE51 bWJlciIgZmllbGQsIGFzIGEgZml4ZWQgOAogICBieXRlIGZpZWxkLCBhbmQgTVVTVCBzZXQgdGhl c2UgOCBieXRlcyB0byAwLiAgVGhlIHJlY2VpdmVyIE1VU1QgTk9UCiAgIGludGVycHJldCB0aGUg TEFCRUwgZmllbGQgYXMgYSBUTFYgYW5kIE1VU1QgaWdub3JlIHRoZSA4IGJ5dGVzCiAgIGltbWVk aWF0ZWx5IGZvbGxvd2luZyB0aGUgIkV2ZW50IFNlcXVlbmNlIE51bWJlciIgZmllbGQuICBJbiBm dXR1cmUKICAgdmVyc2lvbnMgb2YgQU5DUCwgaWYgbmVjZXNzYXJ5LCB0aGUgdW4tdXNlZCBmaWVs ZHMgaW4gR1NNUCBFdmVudAogICBtZXNzYWdlLCB3aGljaCBkbyBub3QgaGF2ZSBBTkNQIHNwZWNp ZmljIHNlbWFudGljcywgY2FuIGJlIHVzZWQKICAgcGFydGlhbGx5IG9yIGNvbXBsZXRlbHksIGJ5 IHJlLW5hbWluZyBhcHByb3ByaWF0ZWx5LCBhbmQgYXNzb2NpYXRpbmcKICAgdmFsaWQgc2VtYW50 aWNzIHdpdGggdGhlc2UgZmllbGRzLgoKICAgVGhlIFRlY2ggVHlwZSBmaWVsZCBpcyBleHRlbmRl ZCB3aXRoIG5ldyB0eXBlICJEU0wiLiAgVGhlIHZhbHVlIGZvcgogICB0aGlzIGZpZWxkIGlzIDB4 MDUuCgogICBJbiBjYXNlIG9mIGJvbmRlZCBjb3BwZXIgbG9vcHMgdG8gdGhlIGN1c3RvbWVyIHBy ZW1pc2UgKGFzIHBlciBEU0wKICAgbXVsdGktcGFpciBib25kaW5nIGRlc2NyaWJlZCBieSBbRy45 ODguMV0gYW5kIFtHLjk4OC4yXSksIHRoZSBEU0xBTQogICBNVVNUIHJlcG9ydCB0aGUgYWdncmVn YXRlIG5ldCBkYXRhIHJhdGUgYW5kIG90aGVyIGF0dHJpYnV0ZXMgZm9yIHRoZQogICAiRFNMIGJv bmRlZCBjaXJjdWl0IiAocmVwcmVzZW50ZWQgYXMgYSBzaW5nbGUgbG9naWNhbCBwb3J0KSB0byB0 aGUKICAgTkFTIGluIGEgUE9SVCBVUCBtZXNzYWdlLiAgQW55IGNoYW5nZSBpbiB0aGUgYWdncmVn YXRlIG5ldCBkYXRhIHJhdGUKICAgb2YgdGhlICJEU0wgYm9uZGVkIGNpcmN1aXQiIChkdWUgdG8g YSBjaGFuZ2UgaW4gbmV0IGRhdGEgcmF0ZSBvZgogICBpbmRpdmlkdWFsIGNvbnN0aXR1ZW50IERT TCBsaW5lcyBvciBkdWUgdG8gY2hhbmdlIGluIHN0YXRlIG9mIHRoZQogICBpbmRpdmlkdWFsIGNv bnN0aXR1ZW50IERTTCBsaW5lcykgTVVTVCBiZSByZXBvcnRlZCBieSB0aGUgRFNMQU0gdG8KICAg dGhlIE5BUyBpbiBhIFBPUlQgVVAgbWVzc2FnZS4gIFRoZSBEU0xBTSBNVVNUIGFsc28gcmVwb3J0 IHRoZQogICAiYWdncmVnYXRlIiBzdGF0ZSBvZiB0aGUgIkRTTCBib25kZWQgY2lyY3VpdCIgdG8g dGhlIE5BUyB2aWEgUE9SVCBVUAogICBhbmQgUE9SVCBET1dOIG1lc3NhZ2VzLgoKCgogV2FkaHdh LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBb UGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAg ICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHwgVmVycyAgfCAgU3ViICB8IE1lc3NhZ2UgVHlwZSAgfCBSZXN1bHR8ICAgICAgICBD b2RlICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgUGFydGl0aW9uIElEICB8ICAgICAgICAg ICAgVHJhbnNhY3Rpb24gSWRlbnRpZmllciAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxJ fCAgICAgIFN1Yk1lc3NhZ2UgTnVtYmVyICAgICAgfCAgICAgICAgICAgTGVuZ3RoICAgICAgICAg ICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBvcnQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgUG9ydCBTZXNzaW9uIE51bWJlciAgICAgICAgICAgICAgICAgICAgICB8CiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICBFdmVudCBTZXF1ZW5jZSBOdW1iZXIg ICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIExhYmVsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHx4fHh8eHx4fHh8eHx4fHh8IE1lc3NhZ2UgVHlw ZSAgfCAgIFRlY2ggVHlwZSAgIHwgQmxvY2sgTGVuZ3RoICB8CiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgRXh0ZW5zaW9uIFZhbHVlICAgICAgICAg ICAgICAgICAgICAgICB+CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGaWd1cmUgMTEKCiAgIFRoZSBmb3JtYXQgb2YgdGhlICJFeHRlbnNp b24gVmFsdWUiIGZpZWxkIGZvciBUZWNoIFR5cGUgIkRTTCIgaXMgYXMKICAgZm9sbG93cyA6CgoK ICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEKICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgICB8ICAgICAjIG9mIFRMVnMgICAg ICAgICAgICAgICB8IEV4dGVuc2lvbiBCbG9jayBsZW5ndGggKGJ5dGVzKSAgfAogICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRMVnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgICAgfiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4KICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDEyOiBFeHRlbnNpb24gVmFsdWUKCiAgIFRoZSAiRXh0ZW5zaW9uIFZhbHVlIiBjb250YWlu cyBvbmUgb3IgbW9yZSBUTFZzIHRvIGlkZW50aWZ5IGEgRFNMCiAgIGxpbmUgYW5kIGRlZmluZSBp dHMgY2hhcmFjdGVyaXN0aWNzLiAgQSBUTFYgY2FuIGNvbnNpc3Qgb2YgbXVsdGlwbGUKICAgc3Vi LVRMVnMuICBGaXJzdCAyIGJ5dGUgb2YgdGhlICJFeHRlbnNpb24gVmFsdWUiIGNvbnRhaW5zIHRo ZSBudW1iZXIKICAgb2YgVExWcyB0aGF0IGZvbGxvdy4gIFRoZSBuZXh0IDIgYnl0ZXMgY29udGFp biB0aGUgdG90YWwgbGVuZ3RoIG9mCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDI4XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAw OQoKCiAgIHRoZSBUTFZzIGNhcnJpZWQgaW4gdGhlIGV4dGVuc2lvbiBibG9jayBpbiBieXRlcyAo ZXhpc3RpbmcgIkJsb2NrCiAgIExlbmd0aCIgZmllbGQgaW4gdGhlIEdTTVAgbWVzc2FnZSBpcyBs aW1pdGVkIHRvIDI1NSBieXRlcyBhbmQgaXMgbm90CiAgIHN1ZmZpY2llbnQpLgoKICAgR2VuZXJh bCBmb3JtYXQgb2YgYSBUTFYgaXMgOgoKCiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgICAgfCAgICAgICAgIFR5cGUgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIExlbmd0aCAg ICAgICAgICAgICAgIHwKICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgfiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIH4KICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB+CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEzOiAgR2VuZXJhbCBUTFYKCiAgIFRoZSB2 YWx1ZSBmaWVsZCBpbiBlYWNoIFRMViBpcyBwYWRkZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVudC4g IFRoZQogICBMZW5ndGggZmllbGQgaW4gZWFjaCBUTFYgY29udGFpbnMgdGhlIGFjdHVhbCBudW1i ZXIgb2YgYnl0ZXMgaW4gdGhlCiAgIFRMViAobm90IGluY2x1ZGluZyB0aGUgcGFkZGluZyBpZiBw cmVzZW50KS4gIElmIGEgVExWIGlzIG5vdAogICB1bmRlcnN0b29kIGJ5IHRoZSBOQVMsIGl0IGlz IHNpbGVudGx5IGlnbm9yZWQuICBDdXJyZW50bHkgZGVmaW5lZAogICB0eXBlcyBzdGFydCBmcm9t IDB4MDEuCgogICBGb2xsb3dpbmcgVExWcyBhcmUgY3VycmVudGx5IGRlZmluZWQ6CgogICAxLiAg VHlwZSAoQWNjZXNzLUxvb3AtQ2lyY3VpdC1JRCA9IDB4MDEpOiBUaGlzIGlzIGEgbWFuZGF0b3J5 IFRMViBhbmQKICAgICAgIGNvbnRhaW5zIGFuIGlkZW50aWZpZXIgb2YgdGhlIHN1YnNjcmliZXIn cyBjb25uZWN0aW9uIHRvIHRoZQogICAgICAgYWNjZXNzIG5vZGUgKGkuZS4gImxvY2FsIGxvb3Ai KS4gIFRoZSAibG9jYWwgbG9vcCIgY2FuIGJlIEFUTQogICAgICAgYmFzZWQgb3IgRXRoZXJuZXQg YmFzZWQuICBUaGUgIkFjY2VzcyBMb29wIENpcmN1aXQgSUQiIGhhcyBsb2NhbAogICAgICAgc2ln bmlmaWNhbmNlIGF0IHRoZSBhY2Nlc3Mgbm9kZS4gIFRoZSBleGFjdCB1c2FnZSBvbiB0aGUgTkFT IGlzCiAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBUaGUgZm9ybWF0 IHVzZWQgZm9yICJsb2NhbAogICAgICAgbG9vcCIgaWRlbnRpZmljYXRpb24gaW4gQU5DUCBtZXNz YWdlcyBNVVNUIGJlIGlkZW50aWNhbCB0byB3aGF0CiAgICAgICBpcyB1c2VkIGJ5IHRoZSBhY2Nl c3Mgbm9kZXMgaW4gc3Vic2NyaWJlciBzaWduYWxpbmcgbWVzc2FnZXMgd2hlbgogICAgICAgdGhl IGFjY2VzcyBub2RlcyBhY3QgYXMgInNpZ25hbGluZyByZWxheSBhZ2VudHMiIGFzIG91dGxpbmVk IGluCiAgICAgICBbUkZDMzA0Nl0gYW5kIFtUUi0xMDFdLgoKICAgICAgICAgIExlbmd0aCA6ICh1 cCB0byA2MyBieXRlcykKCiAgICAgICAgICBWYWx1ZSA6IEFTQ0lJIHN0cmluZwoKICAgICAgICAg IEZvciBhbiBBVE0gYmFzZWQgbG9jYWwgbG9vcCB0aGUgc3RyaW5nIGNvbnNpc3RzIG9mIHNsb3Qv cG9ydAogICAgICAgICAgYW5kIFZQSS9WQ0kgaW5mb3JtYXRpb24gY29ycmVzcG9uZGluZyB0byB0 aGUgc3Vic2NyaWJlcidzIERTTAogICAgICAgICAgY29ubmVjdGlvbi4gIERlZmF1bHQgc3ludGF4 IGZvciB0aGUgc3RyaW5nIGluc2VydGVkIGJ5IHRoZQogICAgICAgICAgYWNjZXNzIG5vZGUgYXMg cGVyIFtUUi0xMDFdIGlzOgoKCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFw cmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDI5XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoK CiAgICAgICAgICAgICAiQWNjZXNzLU5vZGUtSWRlbnRpZmllciBhdG0gc2xvdC9wb3J0OnZwaS52 Y2kiCgogICAgICAgICAgVGhlIEFjY2Vzcy1Ob2RlLUlkZW50aWZpZXIgdW5pcXVlbHkgaWRlbnRp ZmllcyB0aGUgYWNjZXNzIG5vZGUKICAgICAgICAgIGluIHRoZSBhY2Nlc3MgbmV0d29yay4gIFRo ZSBzbG90L3BvcnQgYW5kIFZQSS9WQ0kgdW5pcXVlbHkKICAgICAgICAgIGlkZW50aWZpZXMgdGhl IERTTCBsaW5lIG9uIHRoZSBhY2Nlc3Mgbm9kZS4gIEFsc28sIHRoZXJlIGlzCiAgICAgICAgICBv bmUgdG8gb25lIGNvcnJlc3BvbmRlbmNlIGJldHdlZW4gRFNMIGxpbmUgYW5kIHRoZSBWQyBiZXR3 ZWVuCiAgICAgICAgICB0aGUgYWNjZXNzIG5vZGUgYW5kIHRoZSBOQVMuCgogICAgICAgICAgRm9y IGxvY2FsIGxvb3Agd2hpY2ggaXMgRXRoZXJuZXQgYmFzZWQgKGFuZCB0YWdnZWQpLCB0aGUKICAg ICAgICAgIHN0cmluZyBjb25zaXN0cyBvZiBzbG90L3BvcnQgYW5kIFZMQU4gdGFnIGNvcnJlc3Bv bmRpbmcgdG8gdGhlCiAgICAgICAgICBzdWJzY3JpYmVyLiAgRGVmYXVsdCBzeW50YXggZm9yIHRo ZSBzdHJpbmcgaW5zZXJ0ZWQgYnkgdGhlCiAgICAgICAgICBhY2Nlc3Mgbm9kZSBhcyBwZXIgW1RS LTEwMV0gaXM6CgogICAgICAgICAgICAgIkFjY2Vzcy1Ob2RlLUlkZW50aWZpZXIgZXRoIHNsb3Qv cG9ydFs6dmxhbi1pZF0iCgogICAyLiAgVHlwZSAoQWNjZXNzLUxvb3AtUmVtb3RlLUlkID0gMHgw Mik6IFRoaXMgaXMgYW4gb3B0aW9uYWwgVExWIGFuZAogICAgICAgY29udGFpbnMgYW4gaWRlbnRp ZmllciB0byB1bmlxdWVseSBpZGVudGlmeSBhIHVzZXIgb24gYSBsb2NhbAogICAgICAgbG9vcCBv biB0aGUgYWNjZXNzIG5vZGUuICBUaGUgZXhhY3QgdXNhZ2Ugb24gdGhlIE5BUyBpcyBvdXQgb2YK ICAgICAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBJdCBpcyBkZXNpcmFibGUgdGhhdCB0aGUg Zm9ybWF0IHVzZWQgZm9yCiAgICAgICB0aGUgZmllbGQgaXMgc2ltaWxhciB0byB3aGF0IGlzIHVz ZWQgYnkgdGhlIGFjY2VzcyBub2RlcyBpbgogICAgICAgc3Vic2NyaWJlciBzaWduYWxpbmcgbWVz c2FnZXMgd2hlbiB0aGUgYWNjZXNzIG5vZGVzIGFjdCBhcwogICAgICAgInNpZ25hbGluZyByZWxh eSBhZ2VudHMiIGFzIG91dGxpbmVkIGluIFtSRkMzMDQ2XSBhbmQgW1RSLTEwMV0uCgogICAgICAg ICAgTGVuZ3RoIDogKHVwIHRvIDYzIGJ5dGVzKQoKICAgICAgICAgIFZhbHVlIDogQVNDSUkgc3Ry aW5nCgogICAzLiAgVHlwZSAoQWNjZXNzLUFnZ3JlZ2F0aW9uLUNpcmN1aXQtSUQtQmluYXJ5ID0g MHgwNikKCiAgICAgICAgICBMZW5ndGggOiAoOCBieXRlcykKCiAgICAgICAgICBWYWx1ZSA6IHR3 byAzMiBiaXQgaW50ZWdlcnMKCiAgICAgICAgICBGb3IgZXRoZXJuZXQgYWNjZXNzIGFnZ3JlZ2F0 aW9uLCB3aGVyZSBhIHBlci1zdWJzY3JpYmVyCiAgICAgICAgICAoc3RhY2tlZCkgVkxBTiBjYW4g YmUgYXBwbGllZCAoMToxIG1vZGVsIGRlZmluZWQgaW4gW1RSLTEwMV0pLAogICAgICAgICAgdGhl IFZMQU4gc3RhY2sgcHJvdmlkZXMgYSBjb252ZW5pZW50IHdheSB0byB1bmlxdWVseSBpZGVudGlm eQogICAgICAgICAgdGhlIERTTCBsaW5lLiAgVGhlIG91dGVyIFZMQU4gaXMgZXF1aXZhbGVudCB0 byB2aXJ0dWFsIHBhdGgKICAgICAgICAgIGJldHdlZW4gYSBEU0xBTSBhbmQgdGhlIE5BUyBhbmQg aW5uZXIgVkxBTiBpcyBlcXVpdmFsZW50IHRvIGEKICAgICAgICAgIHZpcnR1YWwgY2lyY3VpdCBv biBhIHBlciBEU0wgbGluZSBiYXNpcy4gIEluIHRoaXMgc2NlbmFyaW8sCiAgICAgICAgICBhbnkg c3Vic2NyaWJlciBkYXRhIHJlY2VpdmVkIGJ5IHRoZSBhY2Nlc3Mgbm9kZSBhbmQKICAgICAgICAg IHRyYW5zbWl0dGVkIG91dCB0aGUgdXBsaW5rIHRvIHRoZSBhZ2dyZWdhdGlvbiBuZXR3b3JrIHdp bGwgYmUKICAgICAgICAgIHRhZ2dlZCB3aXRoIHRoZSBWTEFOIHN0YWNrIGFzc2lnbmVkIGJ5IHRo ZSBhY2Nlc3Mgbm9kZQoKICAgICAgICAgIFRoaXMgVExWIGNhbiBjYXJyeSB0aGUgVkxBTiB0YWdz IGFzc2lnbmVkIGJ5IHRoZSBhY2Nlc3Mgbm9kZQogICAgICAgICAgaW4gdGhlIEFOQ1AgbWVzc2Fn ZXMuICBUaGUgVkxBTiB0YWdzIGNhbiB1bmlxdWVseSBpZGVudGlmeSB0aGUKICAgICAgICAgIERT TCBsaW5lIGJlaW5nIHJlZmVycmVkIHRvIGluIHRoZSBBTkNQIG1lc3NhZ2VzLCBhc3N1bWluZyB0 aGUKICAgICAgICAgIFZMQU4gdGFncyBhcmUgbm90IGluIGFueSB3YXkgdHJhbnNsYXRlZCBpbiB0 aGUgYWdncmVnYXRpb24KICAgICAgICAgIG5ldHdvcmsgYW5kIGFyZSB1bmlxdWUgYWNyb3NzIHBo eXNpY2FsIHBvcnRzLiAgRWFjaCAzMiBiaXQKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMzBdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0b2Jl ciAyMDA5CgoKICAgICAgICAgIGludGVnZXIgKGxlYXN0IHNpZ25pZmljYW50IGJpdHMpIGNvbnRh aW5zIGEgMTIgYml0IFZMQU4KICAgICAgICAgIGlkZW50aWZpZXIgKHdoaWNoIGlzIHBhcnQgb2Yg dGhlIFZMQU4gdGFnIGRlZmluZWQgYnkgSUVFRQogICAgICAgICAgODAyLjFRKS4KCiAgICAgICAg ICBBbHNvLCBpbiBjYXNlIG9mIGFuIEFUTSBhZ2dyZWdhdGlvbiBuZXR3b3JrLCB3aGVyZSB0aGUg RFNMQU0KICAgICAgICAgIGlzIGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgTkFTICh3aXRob3V0 IGFuIGludGVybWVkaWF0ZSBBVE0KICAgICAgICAgIHN3aXRjaCksIHRoZSB0d28gdmFsdWVzIGNh biBjb250YWluIFZQSSBhbmQgVkNJIG9uIHRoZSBEU0xBTQogICAgICAgICAgdXBsaW5rIChhbmQg Y2FuIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBEU0wgbGluZSBvbiB0aGUgRFNMQU0pLgoKICAgICAg ICAgIFRoaXMgaXMgb3B0aW9uYWwuCgogICA0LiAgVHlwZSAoQWNjZXNzLUFnZ3JlZ2F0aW9uLUNp cmN1aXQtSUQtQVNDSUkgPSAweDAzKQoKICAgICAgICAgIExlbmd0aCA6ICh1cCB0byA2MyBieXRl cykKCiAgICAgICAgICBWYWx1ZSA6IEFTQ0lJIHN0cmluZwoKICAgICAgICAgIFRoaXMgZmllbGQg Y29udGFpbnMgaW5mb3JtYXRpb24gcGVydGFpbmluZyB0byBhbiB1cGxpbmsgb24gdGhlCiAgICAg ICAgICBhY2Nlc3Mgbm9kZS4gIEZvciBFdGhlcm5ldCBhY2Nlc3MgYWdncmVnYXRpb24sIGFzc3Vt aW5nIHRoZQogICAgICAgICAgYWNjZXNzIG5vZGUgYXNzaWducyBWTEFOIHRhZ3MgKDE6MSBtb2Rl bCksIHR5cGljYWwgZm9ybWF0IGZvcgogICAgICAgICAgdGhlIHN0cmluZyBpczoKCiAgICAgICAg ICAgICAiQWNjZXNzLU5vZGUtSWRlbnRpZmllciBldGggc2xvdC9wb3J0IFs6aW5uZXItdmxhbi0K ICAgICAgICAgICAgIGlkXVs6b3V0ZXItdmxhbi1pZF0iCgogICAgICAgICAgVGhlIHNsb3QvcG9y dCBjb3JyZXNwb25kcyB0byB0aGUgZXRoZXJuZXQgdXBsaW5rIG9uIHRoZSBhY2Nlc3MKICAgICAg ICAgIG5vZGUgdG93YXJkcyB0aGUgTkFTLgoKICAgICAgICAgIEZvciBhbiBBVE0gYWdncmVnYXRp b24gbmV0d29yaywgdHlwaWNhbCBmb3JtYXQgZm9yIHRoZSBzdHJpbmcKICAgICAgICAgIGlzOgoK ICAgICAgICAgICAgICJBY2Nlc3MtTm9kZS1JZGVudGlmaWVyIGF0bSBzbG90L3BvcnQ6dnBpLnZj aSIKCiAgICAgICAgICBUaGlzIFRMViBhbGxvd3MgdGhlIE5BUyB0byBhc3NvY2lhdGUgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZAogICAgICAgICAgaW4gdGhlIEFOQ1AgbWVzc2FnZXMgdG8gdGhl IERTTCBsaW5lIG9uIHRoZSBhY2Nlc3Mgbm9kZS4KCiAgICAgICAgICBJZiB0aGUgYWNjZXNzIG5v ZGUgaW5zZXJ0cyB0aGlzIHN0cmluZyBpbiB0aGUgQU5DUCBtZXNzYWdlcywKICAgICAgICAgIHdo ZW4gcmVmZXJyaW5nIHRvIGxvY2FsIGxvb3AgY2hhcmFjdGVyaXN0aWNzIChlLmcuICBEU0wgbGlu ZQogICAgICAgICAgaW4gY2FzZSBvZiBhIERTTEFNKSwgdGhlbiBpdCBzaG91bGQgYmUgYWJsZSB0 byBtYXAgdGhlCiAgICAgICAgICBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhlIHN0cmluZyB1 bmlxdWVseSB0byB0aGUgbG9jYWwgbG9vcAogICAgICAgICAgKGUuZy4gIERTTCBsaW5lKS4KCiAg ICAgICAgICBPbiB0aGUgTkFTLCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgc3Ry aW5nIGNhbiBiZQogICAgICAgICAgdXNlZCB0byBkZXJpdmUgYW4gImFnZ3JlZ2F0aW9uIG5ldHdv cmsiIGZhY2luZyBjb25zdHJ1Y3QgKGUuZy4KICAgICAgICAgIGFuIElQIGludGVyZmFjZSkgY29y cmVzcG9uZGluZyB0byB0aGUgbG9jYWwgbG9vcCAoZS5nLiAgRFNMCiAgICAgICAgICBsaW5lKS4g IFRoZSBhc3NvY2lhdGlvbiBjb3VsZCBiZSBiYXNlZCBvbiAibG9jYWwKICAgICAgICAgIGNvbmZp Z3VyYXRpb24iIG9uIHRoZSBOQVMuCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIw MDkKCgogICAgICAgICAgVGhlIGFjY2VzcyBub2RlIGNhbiBhbHNvIGNvbnZleSB0byB0aGUgTkFT LCB0aGUKICAgICAgICAgIGNoYXJhY3RlcmlzdGljcyAoZS5nLiBiYW5kd2lkdGgpIG9mIHRoZSB1 cGxpbmsgb24gdGhlIGFjY2VzcwogICAgICAgICAgbm9kZS4gIFRoaXMgVExWIHRoZW4gc2VydmVz IHRoZSBwdXJwb3NlIG9mIHVuaXF1ZWx5CiAgICAgICAgICBpZGVudGlmeWluZyB0aGUgdXBsaW5r IHdob3NlIGNoYXJhY3RlcmlzdGljcyBhcmUgYmVpbmcKICAgICAgICAgIGRlZmluZWQuICBBIHNl cGFyYXRlIHNldCBvZiBzdWItVExWcyB3aWxsIGJlIGRlZmluZWQgZm9yIHRoZQogICAgICAgICAg dXBsaW5rIGNoYXJhY3RlcmlzdGljcyAoVEJEKS4KCiAgICAgICAgICBUaGlzIFRMViBpcyBvcHRp b25hbC4KCiAgIDUuICBUeXBlIChEU0wgTGluZSBBdHRyaWJ1dGVzID0gMHgwNCk6CgogICAgICAg ICAgTGVuZ3RoIDogdmFyaWFibGUgKHVwIHRvIDEwMjQgYnl0ZXMpCgogICAgICAgICAgVmFsdWUg OiBUaGlzIGlzIGEgbWFuZGF0b3J5IFRMViBhbmQgY29uc2lzdHMgb2Ygb25lIG9yIG1vcmUKICAg ICAgICAgIFN1Yi1UTFZzIGNvcnJlc3BvbmRpbmcgdG8gRFNMIGxpbmUgYXR0cmlidXRlcy4gIE5v IHN1Yi1UTFZzCiAgICAgICAgICBvdGhlciB0aGFuIHRoZSAiRFNMIHR5cGUiIGFuZCAiRFNMIGxp bmUgc3RhdGUiIFNIT1VMRCBiZQogICAgICAgICAgaW5jbHVkZWQgaW4gYSBQT1JUIERPV04gbWVz c2FnZS4KCiAgICAgICAgICBUaGUgZ2VuZXJhbCBmb3JtYXQgb2YgdGhlIHN1Yi1UTFZzIGlzIGlk ZW50aWNhbCB0byB0aGUgZ2VuZXJhbAogICAgICAgICAgVExWIGZvcm1hdC4gIFRoZSB2YWx1ZSBm aWVsZCBpbiBlYWNoIHN1Yi1UTFYgaXMgcGFkZGVkIHRvIGEKICAgICAgICAgIDQtb2N0ZXQgYWxp Z25tZW50LiAgVGhlIExlbmd0aCBmaWVsZCBpbiBlYWNoIHN1Yi1UTFYgY29udGFpbnMKICAgICAg ICAgIHRoZSBhY3R1YWwgbnVtYmVyIG9mIGJ5dGVzIGluIHRoZSBUTFYgKG5vdCBpbmNsdWRpbmcg dGhlCiAgICAgICAgICBwYWRkaW5nIGlmIHByZXNlbnQpLiAgQ3VycmVudCBkZWZpbmVkIHN1Yi1U TFYgdHlwZXMgYXJlIHN0YXJ0CiAgICAgICAgICBmcm9tIDB4ODEuCgogICAgICAgICAgRm9sbG93 aW5nIHN1Yi1UTFZzIGFyZSBjdXJyZW50bHkgZGVmaW5lZCA6CgogICAgICAgICAgKyAgVHlwZSAo RFNMLVR5cGUgPSAweDkxKSA6IERlZmluZXMgdGhlIHR5cGUgb2YgdHJhbnNtaXNzaW9uCiAgICAg ICAgICAgICBzeXN0ZW0gaW4gdXNlLiAgVGhpcyBpcyBhIG1hbmRhdG9yeSBUTFYuCgogICAgICAg ICAgICAgICAgTGVuZ3RoIDogKDQgYnl0ZXMpCgogICAgICAgICAgICAgICAgVmFsdWUgOiAoVHJh bnNtaXNzaW9uIHN5c3RlbSA6IEFEU0wxID0gMHgwMSwgQURTTDIgPQogICAgICAgICAgICAgICAg MHgwMiwgQURTTDIrID0gMHgwMywgVkRTTDEgPSAweDA0LCBWRFNMMiA9IDB4MDUsIFNEU0wgPQog ICAgICAgICAgICAgICAgMHgwNiwgVU5LTk9XTiA9IDB4MDcpLgoKICAgICAgICAgICsgIFR5cGUg KEFjdHVhbC1OZXQtRGF0YS1VcHN0cmVhbSA9IDB4ODEpOiBBY3R1YWwgdXBzdHJlYW0gbmV0CiAg ICAgICAgICAgICBkYXRhIHJhdGUgb24gYSBEU0wgbGluZS4gIFRoaXMgaXMgYSBtYW5kYXRvcnkg VExWLgoKICAgICAgICAgICAgICAgIExlbmd0aCA6ICg0IGJ5dGVzKQoKICAgICAgICAgICAgICAg IFZhbHVlIDogKFJhdGUgaW4gS2Ivc2VjKQoKICAgICAgICAgICsgIFR5cGUgKEFjdHVhbC1OZXQt RGF0YS1SYXRlLURvd25zdHJlYW0gPSAweDgyKSA6IEFjdHVhbAogICAgICAgICAgICAgZG93bnN0 cmVhbSBuZXQgZGF0YSByYXRlIG9uIGEgRFNMIGxpbmUuICBUaGlzIGlzIGEKICAgICAgICAgICAg IG1hbmRhdG9yeSBUTFYuCgoKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXBy aWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMzJdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoK ICAgICAgICAgICAgICAgIExlbmd0aCA6ICg0IGJ5dGVzKQoKICAgICAgICAgICAgICAgIFZhbHVl IDogKFJhdGUgaW4gS2Ivc2VjKQoKICAgICAgICAgICsgIFR5cGUgKE1pbmltdW0tTmV0LURhdGEt UmF0ZS1VcHN0cmVhbSA9IDB4ODMpIDogTWluaW11bSBuZXQKICAgICAgICAgICAgIGRhdGEgcmF0 ZSBkZXNpcmVkIGJ5IHRoZSBvcGVyYXRvci4gIFRoaXMgaXMgb3B0aW9uYWwuCgogICAgICAgICAg ICAgICAgTGVuZ3RoIDogKDQgYnl0ZXMpCgogICAgICAgICAgICAgICAgVmFsdWUgOiAoUmF0ZSBp biBLYi9zZWMpCgogICAgICAgICAgKyAgVHlwZSAoTWluaW11bS1OZXQtRGF0YS1SYXRlLURvd25z dHJlYW0gPSAweDg0KSA6IE1pbmltdW0KICAgICAgICAgICAgIG5ldCBkYXRhIHJhdGUgZGVzaXJl ZCBieSB0aGUgb3BlcmF0b3IuICBUaGlzIGlzIG9wdGlvbmFsLgoKICAgICAgICAgICAgICAgIExl bmd0aCA6ICg0IGJ5dGVzKQoKICAgICAgICAgICAgICAgIFZhbHVlIDogKFJhdGUgaW4gS2Ivc2Vj KQoKICAgICAgICAgICsgIFR5cGUgKEF0dGFpbmFibGUtTmV0LURhdGEtUmF0ZS1VcHN0cmVhbSA9 IDB4ODUpIDogTWF4aW11bQogICAgICAgICAgICAgbmV0IHVwc3RyZWFtIHJhdGUgdGhhdCBjYW4g YmUgYXR0YWluZWQgb24gdGhlIERTTCBsaW5lLgogICAgICAgICAgICAgVGhpcyBpcyBhbiBvcHRp b25hbCBUTFYuCgogICAgICAgICAgICAgICAgTGVuZ3RoIDogKDQgYnl0ZXMpCgogICAgICAgICAg ICAgICAgVmFsdWUgOiAoUmF0ZSBpbiBLYi9zZWMpCgogICAgICAgICAgKyAgVHlwZSAoQXR0YWlu YWJsZS1OZXQtRGF0YS1SYXRlLURvd25zdHJlYW0gPSAweDg2KSA6IE1heGltdW0KICAgICAgICAg ICAgIG5ldCBkb3duc3RyZWFtIHJhdGUgdGhhdCBjYW4gYmUgYXR0YWluZWQgb24gdGhlIERTTCBs aW5lLgogICAgICAgICAgICAgVGhpcyBpcyBhbiBvcHRpb25hbCBUTFYuCgogICAgICAgICAgICAg ICAgTGVuZ3RoIDogKDQgYnl0ZXMpCgogICAgICAgICAgICAgICAgVmFsdWUgOiAoUmF0ZSBpbiBL Yi9zZWMpCgogICAgICAgICAgKyAgVHlwZSAoTWF4aW11bS1OZXQtRGF0YS1SYXRlLVVwc3RyZWFt ID0gMHg4NykgOiBNYXhpbXVtIG5ldAogICAgICAgICAgICAgZGF0YSByYXRlIGRlc2lyZWQgYnkg dGhlIG9wZXJhdG9yLiAgVGhpcyBpcyBvcHRpb25hbC4KCiAgICAgICAgICAgICAgICBMZW5ndGgg OiAoNCBieXRlcykKCiAgICAgICAgICAgICAgICBWYWx1ZSA6IChSYXRlIGluIEtiL3NlYykKCiAg ICAgICAgICArICBUeXBlIChNYXhpbXVtLU5ldC1EYXRhLVJhdGUtRG93bnN0cmVhbSA9IDB4ODgp IDogTWF4aW11bQogICAgICAgICAgICAgbmV0IGRhdGEgcmF0ZSBkZXNpcmVkIGJ5IHRoZSBvcGVy YXRvci4gIFRoaXMgaXMgb3B0aW9uYWwuCgogICAgICAgICAgICAgICAgTGVuZ3RoIDogKDQgYnl0 ZXMpCgoKCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEw ICAgICAgICAgICAgICAgIFtQYWdlIDMzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg IGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgICAgICAgICAg ICAgICBWYWx1ZSA6IChSYXRlIGluIEtiL3NlYykKCiAgICAgICAgICArICBUeXBlIChNaW5pbXVt LU5ldC1Mb3ctUG93ZXItRGF0YS1SYXRlLVVwc3RyZWFtID0gMHg4OSkgOgogICAgICAgICAgICAg TWluaW11bSBuZXQgZGF0YSByYXRlIGRlc2lyZWQgYnkgdGhlIG9wZXJhdG9yIGluIGxvdyBwb3dl cgogICAgICAgICAgICAgc3RhdGUuICBUaGlzIGlzIG9wdGlvbmFsLgoKICAgICAgICAgICAgICAg IExlbmd0aCA6ICg0IGJ5dGVzKQoKICAgICAgICAgICAgICAgIFZhbHVlIDogKFJhdGUgaW4gS2Iv c2VjKQoKICAgICAgICAgICsgIFR5cGUgKE1pbmltdW0tTmV0LUxvdy1Qb3dlci1EYXRhLVJhdGUt RG93bnN0cmVhbSA9IDB4OEEpIDoKICAgICAgICAgICAgIE1pbmltdW0gbmV0IGRhdGEgcmF0ZSBk ZXNpcmVkIGJ5IHRoZSBvcGVyYXRvciBpbiBsb3cgcG93ZXIKICAgICAgICAgICAgIHN0YXRlLiAg VGhpcyBpcyBvcHRpb25hbC4KCiAgICAgICAgICAgICAgICBMZW5ndGggOiAoNCBieXRlcykKCiAg ICAgICAgICAgICAgICBWYWx1ZSA6IChSYXRlIGluIEtiL3NlYykKCiAgICAgICAgICArICBUeXBl IChNYXhpbXVtLUludGVybGVhdmluZy1EZWxheS1VcHN0cmVhbSA9IDB4OEIpIDogbWF4aW11bQog ICAgICAgICAgICAgb25lIHdheSBpbnRlcmxlYXZpbmcgZGVsYXkuICBUaGlzIGlzIG9wdGlvbmFs LgoKICAgICAgICAgICAgICAgIExlbmd0aCA6ICg0IGJ5dGVzKQoKICAgICAgICAgICAgICAgIFZh bHVlIDogKFRpbWUgaW4gbXNlYykKCiAgICAgICAgICArICBUeXBlIChBY3R1YWwtSW50ZXJsZWF2 aW5nLURlbGF5LVVwc3RyZWFtID0gMHg4QykgOiBWYWx1ZQogICAgICAgICAgICAgY29ycmVzcG9u ZGluZyB0byB0aGUgaW50ZXJsZWF2ZXIgc2V0dGluZy4gIFRoaXMgaXMKICAgICAgICAgICAgIG9w dGlvbmFsLgoKICAgICAgICAgICAgICAgIExlbmd0aCA6ICg0IGJ5dGVzKQoKICAgICAgICAgICAg ICAgIFZhbHVlIDogKFRpbWUgaW4gbXNlYykKCiAgICAgICAgICArICBUeXBlIChNYXhpbXVtLUlu dGVybGVhdmluZy1EZWxheS1Eb3duc3RyZWFtID0gMHg4RCkgOgogICAgICAgICAgICAgbWF4aW11 bSBvbmUgd2F5IGludGVybGVhdmluZyBkZWxheS4gIFRoaXMgaXMgb3B0aW9uYWwuCgogICAgICAg ICAgICAgICAgTGVuZ3RoIDogKDQgYnl0ZXMpCgogICAgICAgICAgICAgICAgVmFsdWUgOiAoVGlt ZSBpbiBtc2VjKQoKICAgICAgICAgICsgIFR5cGUgKEFjdHVhbC1JbnRlcmxlYXZpbmctRGVsYXkt RG93bnN0cmVhbSA9IDB4OEUpIDogVmFsdWUKICAgICAgICAgICAgIGNvcnJlc3BvbmRpbmcgdG8g dGhlIGludGVybGVhdmVyIHNldHRpbmcuICBUaGlzIGlzCiAgICAgICAgICAgICBvcHRpb25hbC4K CiAgICAgICAgICAgICAgICBMZW5ndGggOiAoNCBieXRlcykKCgoKCgoKIFdhZGh3YSwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMzRd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAg ICAgICAgT2N0b2JlciAyMDA5CgoKICAgICAgICAgICAgICAgIFZhbHVlIDogKFRpbWUgaW4gbXNl YykKCiAgICAgICAgICArICBUeXBlIChEU0wgbGluZSBzdGF0ZSA9IDB4OEYpIDogVGhlIHN0YXRl IG9mIHRoZSBEU0wgbGluZS4KICAgICAgICAgICAgIEZvciBQT1JUIFVQIG1lc3NhZ2UsIGF0IHRo aXMgdGltZSwgdGhlIFRMViBpcyBvcHRpb25hbAogICAgICAgICAgICAgKHNpbmNlIHRoZSBtZXNz YWdlIHR5cGUgaW1wbGljaXRseSBjb252ZXlzIHRoZSBzdGF0ZSBvZiB0aGUKICAgICAgICAgICAg IGxpbmUpLiAgRm9yIFBPUlQgRE9XTiwgdGhlIFRMViBpcyBtYW5kYXRvcnksIHNpbmNlIGl0CiAg ICAgICAgICAgICBmdXJ0aGVyIGNvbW11bmljYXRlcyB0aGUgc3RhdGUgb2YgdGhlIGxpbmUgYXMg SURMRSBvcgogICAgICAgICAgICAgU0lMRU5ULgoKICAgICAgICAgICAgICAgIExlbmd0aCA6ICg0 IGJ5dGVzKQoKICAgICAgICAgICAgICAgIFZhbHVlIDogeyBTSE9XVElNRSA9IDB4MDEsIElETEUg PSAweDAyLCBTSUxFTlQgPSAweDAzIH0KCiAgICAgICAgICArICBUeXBlIChBY2Nlc3MgTG9vcCBF bmNhcHN1bGF0aW9uID0gMHg5MCkgOiBUaGUgZGF0YSBsaW5rCiAgICAgICAgICAgICBwcm90b2Nv bCBhbmQsIG9wdGlvbmFsbHkgdGhlIGVuY2Fwc3VsYXRpb24gb3ZlcmhlYWQgb24gdGhlCiAgICAg ICAgICAgICBhY2Nlc3MgbG9vcC4gIFRoaXMgaXMgYW4gb3B0aW9uYWwgVExWLiAgSG93ZXZlciwg d2hlbiB0aGlzCiAgICAgICAgICAgICBUTFYgaXMgcHJlc2VudCwgdGhlIGRhdGEgbGluayBwcm90 b2NvbCBNVVNUIG1pbmltYWxseSBiZQogICAgICAgICAgICAgaW5kaWNhdGVkLiAgVGhlIGVuY2Fw c3VsYXRpb24gb3ZlcmhlYWQgY2FuIGJlIG9wdGlvbmFsbHkKICAgICAgICAgICAgIGluZGljYXRl ZC4KCiAgICAgICAgICAgICAgICBMZW5ndGggOiAoMyBieXRlcykKCiAgICAgICAgICAgICAgICBW YWx1ZSA6IFRoZSB0aHJlZSBieXRlcyAobW9zdCB0byBsZWFzdCBzaWduaWZpY2FudCkgYW5kCiAg ICAgICAgICAgICAgICB2YWxpZCBzZXQgb2YgdmFsdWVzIGZvciBlYWNoIGJ5dGUgYXJlIGRlZmlu ZWQgYmVsb3cuCgogICAgICAgICAgICAgICAgICAgRGF0YSBMaW5rICgxIGJ5dGUpOiB7QVRNIEFB TDUgPSAwLCBFVEhFUk5FVCA9IDF9CgogICAgICAgICAgICAgICAgICAgRW5jYXBzIDEgKDEgYnl0 ZSk6IHsKCiAgICAgICAgICAgICAgICAgICAgICBOQSA9IDAsCgogICAgICAgICAgICAgICAgICAg ICAgVW50YWdnZWQgRXRoZXJuZXQgPSAxLAoKICAgICAgICAgICAgICAgICAgICAgIFNpbmdsZS10 YWdnZWQgRXRoZXJuZXQgPSAyfQoKICAgICAgICAgICAgICAgICAgIEVuY2FwcyAyICgxIGJ5dGUp OnsKCiAgICAgICAgICAgICAgICAgICAgICBOQSA9IDAsCgogICAgICAgICAgICAgICAgICAgICAg UFBQb0EgTExDID0gMQoKICAgICAgICAgICAgICAgICAgICAgIFBQUG9BIE5VTEwgPSAyLAoKICAg ICAgICAgICAgICAgICAgICAgIElQb0EgTExDID0gMywKCgoKCgoKCiBXYWRod2EsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDM1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAg ICAgIE9jdG9iZXIgMjAwOQoKCiAgICAgICAgICAgICAgICAgICAgICBJUG9BIE51TEwgPSA0LAoK ICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IG92ZXIgQUFMNSBMTEMgd2l0aCBGQ1MgPSA1 LAoKICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IG92ZXIgQUFMNSBMTEMgd2l0aG91dCBG Q1MgPSA2LAoKICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IG92ZXIgQUFMNSBOVUxMIHdp dGggRkNTID0gNywKCiAgICAgICAgICAgICAgICAgICAgICBFdGhlcm5ldCBvdmVyIEFBTDUgTlVM TCB3aXRob3V0IEZDUyA9IDh9CgogICAgICAgICAgICAgSWYgdGhpcyBUTFYgaXMgcHJlc2VudCwg dGhlIERhdGEgTGluayBwcm90b2NvbCBNVVNUIGJlCiAgICAgICAgICAgICBpbmRpY2F0ZWQgYXMg ZGVmaW5lZCBhYm92ZS4gIEhvd2V2ZXIsIHRoZSBBY2Nlc3MgTm9kZSBjYW4KICAgICAgICAgICAg IGNob29zZSB0byBub3QgY29udmV5IHRoZSBlbmNhcHN1bGF0aW9uIG9uIHRoZSBhY2Nlc3MgbG9v cAogICAgICAgICAgICAgYnkgc3BlY2lmeWluZyBhIHZhbHVlIG9mIDAgKE5BKSBmb3IgdGhlIHR3 byBlbmNhcHN1bGF0aW9uCiAgICAgICAgICAgICBmaWVsZHMKCjUuNC4zLiAgTGluZSBDb25maWd1 cmF0aW9uIEV4dGVuc2lvbnMKCiAgIFRoZSBQb3J0IE1hbmFnZW1lbnQgbWVzc2FnZSBmb3JtYXQg ZGVmaW5lZCBpbiBbUkZDMzI5Ml0gaGFzIGJlZW4KICAgbW9kaWZpZWQgdG8gY29udGFpbiBhbiBl eHRlbnNpb24gYmxvY2sgKGRlc2NyaWJlZCBhYm92ZSBpbiBzZWN0aW9uCiAgIFNlY3Rpb24gNS40 LjEuMSkgYXQgdGhlIGVuZCBvZiB0aGUgbWVzc2FnZS4gIEFsc28sIHRoZSBvcmlnaW5hbCB0d28K ICAgYnl0ZSBGdW5jdGlvbiBmaWVsZCBoYXMgYmVlbiBtb2RpZmllZCB0byBjb250YWluIG9uZSBi eXRlIGZvciB0aGUKICAgRnVuY3Rpb24gZmllbGQgaW5kaWNhdGluZyBhIHNwZWNpZmljIGFjdGlv biB0byBiZSB0YWtlbiBieSB0aGUKICAgcmVjaXBpZW50IG9mIHRoZSBtZXNzYWdlLCBhbmQgb25l IGJ5dGUgZm9yIFgtRnVuY3Rpb24gZmllbGQsIHdoaWNoCiAgIGNvdWxkIGZ1cnRoZXIgcXVhbGlm eSB0aGUgYWN0aW9uIHNwZWNpZmllZCBpbiB0aGUgRnVuY3Rpb24gZmllbGQuCiAgIEFueSBGdW5j dGlvbiBzcGVjaWZpYyBkYXRhIE1VU1QgYmUgY2FycmllZCBpbiB0aGUgZXh0ZW5zaW9uIGJsb2Nr LgoKICAgTm90IGFsbCB0aGUgZmllbGRzIGluIEdTTVAgUG9ydCBNYW5hZ2VtZW50IG1lc3NhZ2Ug YXJlIGFwcGxpY2FibGUgdG8KICAgQU5DUC4gIFRoZSBmaWVsZHMgdGhhdCBhcmUgbm90IGFwcGxp Y2FibGUgTVVTVCBiZSBzZXQgdG8gemVybyBieSB0aGUKICAgQU5DUCBzZW5kZXIgYW5kIGlnbm9y ZWQgYnkgdGhlIEFOQ1AgcmVjZWl2ZXIuCgogICBUaGUgTkFTIHVzZXMgdGhlIGV4dGVuc2lvbiBi bG9jayBpbiB0aGUgUG9ydCBNYW5hZ2VtZW50IG1lc3NhZ2VzIHRvCiAgIGNvbnZleSBzZXJ2aWNl IGF0dHJpYnV0ZXMgb2YgdGhlIERTTCBsaW5lcyB0byB0aGUgRFNMQU0uICBUTFZzIGFyZQogICBk ZWZpbmVkIGZvciBEU0wgbGluZSBpZGVudGlmaWNhdGlvbiBhbmQgc2VydmljZSBkYXRhIGZvciB0 aGUgRFNMCiAgIGxpbmVzLiAgUG9ydCBudW1iZXIgaXMgc2V0IHRvIDAgaW4gdGhlIG1lc3NhZ2Uu ICBBIG5ldyBhY3Rpb24gdHlwZQogICAiQ29uZmlndXJlIENvbm5lY3Rpb24gU2VydmljZSBEYXRh IiAodmFsdWUgMHg4KSBpcyBkZWZpbmVkLiAgVGhlCiAgICJGdW5jdGlvbiIgZmllbGQgaXMgc2V0 IHRvIHRoZSBhY3Rpb24gdHlwZS4gIFRoaXMgYWN0aW9uIHR5cGUKICAgaW5kaWNhdGVzIHRvIHRo ZSBkZXZpY2UgYmVpbmcgY29udHJvbGxlZCAoQWNjZXNzIE5vZGUgaS5lLiAgRFNMQU0pIHRvCiAg IGFwcGx5IHNlcnZpY2UgY29uZmlndXJhdGlvbiBkYXRhIGNvbnRhaW5lZCBpbiB0aGUgZXh0ZW5z aW9uIHZhbHVlCiAgIChUTFZzKSwgdG8gdGhlIERTTCBsaW5lIChpZGVudGlmaWVkIGJ5IG9uZSBv ZiB0aGUgVExWcyBpbiB0aGUKICAgZXh0ZW5zaW9uIHZhbHVlKS4gIEZvciB0aGUgYWN0aW9uIHR5 cGUgIkNvbmZpZ3VyZSBDb25uZWN0aW9uIFNlcnZpY2UKICAgRGF0YSIsIFgtRnVuY3Rpb24gZmll bGQgTVVTVCBiZSBzZXQgdG8gMC4gIFRoZSBUZWNoIFR5cGUgZmllbGQgaXMKICAgZXh0ZW5kZWQg d2l0aCBuZXcgdHlwZSAiRFNMIi4gIFRoZSB2YWx1ZSBmb3IgdGhpcyBmaWVsZCBpcyAweDA1LgoK CgoKCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEwICAg ICAgICAgICAgICAgIFtQYWdlIDM2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGFu Y3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgICAwICAgICAgICAg ICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgfCBWZXJzICB8ICBTdWIgIHwgTWVzc2FnZSBUeXBlICB8IFJl c3VsdHwgICAgICAgIENvZGUgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCBQYXJ0aXRpb24g SUQgIHwgICAgICAgICAgICBUcmFuc2FjdGlvbiBJZGVudGlmaWVyICAgICAgICAgICAgIHwKICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsKICAgfEl8ICAgICAgU3ViTWVzc2FnZSBOdW1iZXIgICAgICB8ICAgICAgICAgICBM ZW5ndGggICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUG9ydCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK ICAgfCAgICAgICAgICAgICAgICAgICAgICBQb3J0IFNlc3Npb24gTnVtYmVyICAgICAgICAgICAg ICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAgIEV2ZW50IFNl cXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfFJ8eHx4 fHh8eHx4fHh8eHwgICBEdXJhdGlvbiAgICB8ICAgIEZ1bmN0aW9uICAgfCBYLUZ1bmN0aW9uICAg IHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgRXZlbnQgRmxhZ3MgICAgICAgICB8ICAgICAg ICBGbG93IENvbnRyb2wgRmxhZ3MgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfHh8eHx4fHh8eHx4fHh8 eHwgTWVzc2FnZSBUeXBlICB8ICAgVGVjaCBUeXBlICAgfCBCbG9jayBMZW5ndGggIHwKICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgfiAgICAgICAgICAgICAgICAgICAgICAgICBFeHRlbnNpb24g VmFsdWUgICAgICAgICAgICAgICAgICAgICAgIH4KICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxNAoKICAgVGhlIGZvcm1hdCBv ZiB0aGUgIkV4dGVuc2lvbiBWYWx1ZSIgZmllbGQgaXMgYXMgZm9sbG93czoKCgogICAgICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgIHwgICAgICMgb2YgVExWcyAgICAgICAgICAgICAg IHwgRXh0ZW5zaW9uIEJsb2NrIGxlbmd0aCAoYnl0ZXMpICB8CiAgICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgVExWcyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB+CiAgICAgICB+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCgogICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTU6IEV4 dGVuc2lvbiBWYWx1ZQoKICAgVGhlICJFeHRlbnNpb24gVmFsdWUiIGZpZWxkIGNvbnRhaW5zIG9u ZSBvciBtb3JlIFRMVnMgY29udGFpbmluZyBEU0wKICAgbGluZSBpZGVudGlmaWVyIGFuZCBkZXNp cmVkIHNlcnZpY2UgYXR0cmlidXRlcyBvZiB0aGUgdGhlIERTTCBsaW5lLgogICBGaXJzdCAyIGJ5 dGUgb2YgdGhlICJFeHRlbnNpb24gVmFsdWUiIGNvbnRhaW5zIHRoZSBudW1iZXIgb2YgVExWcwog ICB0aGF0IGZvbGxvdy4gIFRoZSBuZXh0IDIgYnl0ZXMgY29udGFpbiB0aGUgdG90YWwgbGVuZ3Ro IG9mIHRoZQogICBleHRlbnNpb24gYmxvY2sgaW4gYnl0ZXMgKGV4aXN0aW5nICJCbG9jayBMZW5n dGgiIGZpZWxkIGluIHRoZSBHU01QCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDM3XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAw OQoKCiAgIG1lc3NhZ2UgaXMgbGltaXRlZCB0byAyNTUgYnl0ZXMgYW5kIGlzIG5vdCBzdWZmaWNp ZW50KS4KCiAgIEdlbmVyYWwgZm9ybWF0IG9mIGEgVExWIGlzOgoKCiAgICAgICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAg ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwogICAgICAgfCAgICAgICAgIFR5cGUgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgIExlbmd0aCAgICAgICAgICAgICAgIHwKICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIH4KICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+CiAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE2OiAgR2VuZXJh bCBUTFYKCiAgIFRoZSB2YWx1ZSBmaWVsZCBpcyBwYWRkZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVu dC4gIFRoZSBMZW5ndGggZmllbGQKICAgaW4gZWFjaCBUTFYgY29udGFpbnMgdGhlIGFjdHVhbCBu dW1iZXIgb2YgYnl0ZXMgaW4gdGhlIFRMViAobm90CiAgIGluY2x1ZGluZyB0aGUgcGFkZGluZyBp ZiBwcmVzZW50KS4gIElmIGEgVExWIGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRoZQogICBhY2Nlc3Mt bm9kZSwgaXQgaXMgc2lsZW50bHkgaWdub3JlZC4gIERlcGVuZGluZyB1cG9uIHRoZSBkZXBsb3lt ZW50CiAgIHNjZW5hcmlvLCB0aGUgTkFTIG1heSBzcGVjaWZ5ICJBY2Nlc3MgTG9vcCBDaXJjdWl0 LUlEIiBvciB0aGUgIkFjY2VzcwogICBBZ2dyZWdhdGlvbiBDaXJjdWl0LUlEIikgYXMgZGVmaW5l ZCBpbiBzZWN0aW9uIFNlY3Rpb24gNS40LjEuCiAgIEZvbGxvd2luZyBUTFZzIGNhbiBhcHBlYXIg aW4gdGhpcyBtZXNzYWdlOgoKICAgbyAgVHlwZSAoQWNjZXNzLUxvb3AtQ2lyY3VpdC1JRCA9IDB4 MDEpIDogZGVmaW5lZCBpbiBzZWN0aW9uCiAgICAgIFNlY3Rpb24gNS40LjEKCiAgIG8gIFR5cGUg KEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlELUJpbmFyeSA9IDB4MDYpOiBkZWZpbmVkIGlu CiAgICAgIHNlY3Rpb24gU2VjdGlvbiA1LjQuMQoKICAgbyAgVHlwZSAoQWNjZXNzLUFnZ3JlZ2F0 aW9uLUNpcmN1aXQtSUQtQVNDSUkgPSAweDAzKTogZGVmaW5lZCBpbgogICAgICBzZWN0aW9uIFNl Y3Rpb24gNS40LjEKCiAgIG8gIFR5cGUgKFNlcnZpY2UtUHJvZmlsZS1OYW1lID0gMHgwNSk6IFJl ZmVyZW5jZSB0byBhIHByZS1jb25maWd1cmVkCiAgICAgIHByb2ZpbGUgb24gdGhlIERTTEFNIHRo YXQgY29udGFpbnMgc2VydmljZSBzcGVjaWZpYyBkYXRhIGZvciB0aGUKICAgICAgc3Vic2NyaWJl ci4KCiAgICAgICAgIExlbmd0aCA6ICh1cCB0byA2NCBieXRlcykKCiAgICAgICAgIFZhbHVlIDog QVNDSUkgc3RyaW5nIGNvbnRhaW5pbmcgdGhlIHByb2ZpbGUgbmFtZSAoTkFTIGxlYXJucwogICAg ICAgICBmcm9tIGEgcG9saWN5IHNlcnZlciBhZnRlciBhIHN1YnNjcmliZXIgaXMgYXV0aG9yaXpl ZCkuCgogICAgICBJbiBmdXR1cmUsIG1vcmUgVExWcyBNQVkgYmUgZGVmaW5lZCBmb3IgaW5kaXZp ZHVhbCBzZXJ2aWNlCiAgICAgIGF0dHJpYnV0ZXMgb2YgYSBEU0wgbGluZSAoZS5nLiByYXRlcywg aW50ZXJsZWF2aW5nIGRlbGF5LAogICAgICBtdWx0aWNhc3QgY2hhbm5lbCBlbnRpdGxlbWVudCBh Y2Nlc3MtbGlzdCBldGMpCgoKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXBy aWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMzhdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoK NS40LjMuMS4gIFByb3Zpc2lvbmluZyBNZXNzYWdlCgogICBUaGUgUHJvdmlzaW9uaW5nIG1lc3Nh Z2UgaXMgc2VudCBieSB0aGUgTkFTIHRvIHRoZSBBTiB0byBwcm92aXNpb24KICAgaW5mb3JtYXRp b24gaW4gdGhlIEFOLiAgVGhpcyBtZXNzYWdlIGNhbiBiZSB1c2VkIHRvIHByb3Zpc2lvbiBnbG9i YWwKICAgc2NvcGUgaW5mb3JtYXRpb24gb24gdGhlIEFjY2VzcyBOb2RlLgoKICAgVGhlIE1lc3Nh Z2UgVHlwZSBmb3IgdGhlIFByb3Zpc2lvbmluZyBtZXNzYWdlIGlzIDkzLgoKICAgVGhlIE5BUyBz ZW5kaW5nIHRoZSBQcm92aXNpb25pbmcgbWVzc2FnZSBNVVNUIHNldCB0aGUgUmVzdWx0IGZpZWxk IHRvCiAgIDB4MDAuCgogICBUaGUgTkFTIE1VU1QgcG9wdWxhdGUgdGhlIEFOQ1AgVHJhbnNhY3Rp b24gSWRlbnRpZmllciBmaWVsZCB3aXRoIGEKICAgZGlzdGluY3Qgbm9uLXplcm8sIGxpbmVhcmx5 IGluY3JlbWVudGluZyB2YWx1ZSBmb3IgZWFjaCByZXF1ZXN0IHBlcgogICBhZGphY2VuY3ksIGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuNC41IC4KCiAgIFRoZSBBTkNQIFByb3Zpc2lvbmluZyBt ZXNzYWdlIHBheWxvYWQgTUFZIGNvbnRhaW4gZGlmZmVyZW50IFRMVnMsCiAgIGxpa2UgZm9yIGV4 YW1wbGUgU2VydmljZS1Qcm9maWxlLU5hbWUgVExWLiAgVGhlIFNlcnZpY2UtUHJvZmlsZS1OYW1l CiAgIFRMViBNQVkgYXBwZWFyIHplcm8sIG9uZSBvciBtdWx0aXBsZSB0aW1lcy4KCiAgIE9uIHJl Y2VpcHQgb2YgdGhlIFByb3Zpc2lvbmluZyBtZXNzYWdlLCB0aGUgQU4gTVVTVDoKCiAgIG8gIGln bm9yZSB0aGUgUmVzdWx0IGZpZWxkCgogICBvICBpZiB0aGUgQU4gY2FuIHByb2Nlc3MgdGhlIG1l c3NhZ2Ugc3VjY2Vzc2Z1bGx5IGFuZCBhY2NlcHQgYWxsIHRoZQogICAgICBwcm92aXNpb25pbmcg ZGlyZWN0aXZlcyBjb250YWluZWQgaW4gaXQsIHRoZSBBTiBNVVNUIE5PVCBzZW5kIGFueQogICAg ICByZXNwb25zZS4KCjUuNC40LiAgT0FNIEV4dGVuc2lvbnMKCiAgIEdTTVAgIlBvcnQgTWFuYWdl bWVudCIgbWVzc2FnZSAodHlwZSAzMikgU0hPVUxEIGJlIHVzZWQgYnkgdGhlIE5BUyB0bwogICB0 cmlnZ2VyIGFjY2VzcyBub2RlIHRvIHJ1biBhIGxvb3BiYWNrIHRlc3Qgb24gdGhlIGxvY2FsIGxv b3AuICBUaGUKICAgbWVzc2FnZSBmb3JtYXQgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIFNlY3Rpb24g NS40LjIuICBUaGUgdmVyc2lvbgogICBmaWVsZCBTSE9VTEQgYmUgc2V0IHRvIDMgYW5kIHN1Yi12 ZXJzaW9uIGZpZWxkIFNIT1VMRCBiZSBzZXQgdG8gMS4KICAgVGhlIHJlbWFpbmluZyBmaWVsZHMg aW4gdGhlIEdTTVAgaGVhZGVyIGhhdmUgc3RhbmRhcmQgc2VtYW50aWNzLiAgVGhlCiAgIGZ1bmN0 aW9uIHR5cGUgdXNlZCBpbiB0aGUgcmVxdWVzdCBtZXNzYWdlIFNIT1VMRCBiZSBzZXQgdG8gInJl bW90ZQogICBsb29wYmFjayIgKHR5cGUgPSAweDA5KS4gIFRoZSBwb3J0LCAicG9ydCBzZXNzaW9u IG51bWJlciIsICJldmVudAogICBzZXF1ZW5jZSBudW1iZXIiLCBkdXJhdGlvbiwgImV2ZW50IGZs YWdzIiwgImZsb3cgY29udHJvbCBmbGFncyIgYW5kCiAgIGNvZGUgZmllbGRzIFNIT1VMRCBhbGwg YmUgc2V0IHRvIDAuICBUaGUgcmVzdWx0IGZpZWxkIFNIT1VMRCBiZSBzZXQKICAgdG8gIkFja0Fs bCIgdG8gaW5kaWNhdGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBhY2Nlc3Mgbm9kZSB0byBzZW5kIGEK ICAgc3VjY2VzcyBvciBmYWlsdXJlIHJlc3BvbnNlLiAgVGhlIHRyYW5zYWN0aW9uIElEIFNIT1VM RCBjb250YWluIGEKICAgc2VxdWVuY2UgbnVtYmVyIGluc2VydGVkIGJ5IHRoZSBOQVMgaW4gZWFj aCByZXF1ZXN0IHRoYXQgaXQKICAgZ2VuZXJhdGVzLgoKICAgTm90IGFsbCB0aGUgZmllbGRzIGlu IEdTTVAgUG9ydCBNYW5hZ2VtZW50IG1lc3NhZ2UgYXJlIGFwcGxpY2FibGUgdG8KICAgQU5DUC4g IFRoZSBmaWVsZHMgdGhhdCBhcmUgbm90IGFwcGxpY2FibGUgTVVTVCBiZSBzZXQgdG8gemVybyBi eSB0aGUKICAgQU5DUCBzZW5kZXIgYW5kIGlnbm9yZWQgYnkgdGhlIEFOQ1AgcmVjZWl2ZXIuCgog ICBUaGUgZXh0ZW5zaW9uIGZpZWxkIGZvcm1hdCBpcyBhbHNvIGRlZmluZWQgYWJvdmUgaW4gc2Vj dGlvbgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAg ICAgICAgICAgICAgICBbUGFnZSAzOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBh bmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICBTZWN0aW9uIDUu NC4yLiAgVGhlIGV4dGVuc2lvbiB2YWx1ZSBmaWVsZCBjYW4gY29udGFpbiBvbmUgb3IgbW9yZQog ICBUTFZzIGluY2x1ZGluZyB0aGUgYWNjZXNzLWxpbmUgaWRlbnRpZmllciBvbiB0aGUgRFNMQU0g YW5kIE9BTSB0ZXN0CiAgIGNoYXJhY3RlcmlzdGljcyBkZXNpcmVkIGJ5IHRoZSBOQVMuCgogICBU aGUgVExWIGZvcm1hdCBpcyBkZWZpbmVkIGFib3ZlIGluIHNlY3Rpb24gU2VjdGlvbiA1LjQuMi4g IFRoZSB2YWx1ZQogICBmaWVsZCBpcyBwYWRkZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVudC4gIFRo ZSBMZW5ndGggZmllbGQgaW4gZWFjaCBUTFYKICAgY29udGFpbnMgdGhlIGFjdHVhbCBudW1iZXIg b2YgYnl0ZXMgaW4gdGhlIFRMViAobm90IGluY2x1ZGluZyB0aGUKICAgcGFkZGluZyBpZiBwcmVz ZW50KS4gIElmIGEgVExWIGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRoZSBOQVMsIGl0IGlzCiAgIHNp bGVudGx5IGlnbm9yZWQuICBEZXBlbmRpbmcgdXBvbiB0aGUgZGVwbG95bWVudCBzY2VuYXJpbywg dGhlIE5BUwogICBtYXkgc3BlY2lmeSAiQWNjZXNzIExvb3AgQ2lyY3VpdC1JRCIgb3IgdGhlICJB Y2Nlc3MgQWdncmVnYXRpb24KICAgQ2lyY3VpdC1JRCIpIGFzIGRlZmluZWQgaW4gc2VjdGlvbiBT ZWN0aW9uIDUuNC4xLiAgRm9sbG93aW5nIFRMVnMgY2FuCiAgIGFwcGVhciBpbiB0aGlzIG1lc3Nh Z2U6CgogICBvICBUeXBlIChBY2Nlc3MtTG9vcC1DaXJjdWl0LUlEID0gMHgwMSkgOiBkZWZpbmVk IGluIHNlY3Rpb24KICAgICAgU2VjdGlvbiA1LjQuMQoKICAgbyAgVHlwZSAoQWNjZXNzLUFnZ3Jl Z2F0aW9uLUNpcmN1aXQtSUQtQmluYXJ5ID0gMHgwNik6IGRlZmluZWQgaW4KICAgICAgc2VjdGlv biBTZWN0aW9uIDUuNC4xCgogICBvICBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3VpdC1J RC1BU0NJSSA9IDB4MDMpOiBkZWZpbmVkIGluCiAgICAgIHNlY3Rpb24gU2VjdGlvbiA1LjQuMQoK ICAgbyAgVHlwZSAoT0FNLUxvb3BiYWNrLVRlc3QtUGFyYW1ldGVycyA9IDB4MDcpOiBQYXJhbWV0 ZXJzIHJlbGF0ZWQgdG8KICAgICAgbG9vcGJhY2sgdGVzdC4gIFRoaXMgaXMgYW4gb3B0aW9uYWwg VExWLiAgSWYgdGhpcyBUTFYgaXMgbm90CiAgICAgIHByZXNlbnQgaW4gdGhlIHJlcXVlc3QgbWVz c2FnZSwgdGhlIERTTEFNIFNIT1VMRCB1c2UgbG9jYWxseQogICAgICBkZXRlcm1pbmVkIGRlZmF1 bHQgdmFsdWVzIGZvciB0aGUgdGVzdCBwYXJhbWV0ZXJzLgoKICAgICAgICAgTGVuZ3RoIDogKDQg Ynl0ZXMpCgogICAgICAgICBWYWx1ZSA6IHR3byAxIGJ5dGUgbnVtYmVycyBkZXNjcmliZWQgYmVs b3cgKGxpc3RlZCBpbiBvcmRlciBvZgogICAgICAgICBtb3N0IHRvIGxlYXN0IHNpZ25pZmljYW50 KS4gIFRodXMsIHRoZSA0IGJ5dGVzIGNvbnNpc3Qgb2YgMQogICAgICAgICBieXRlIG9mIENvdW50 LCBmb2xsb3dlZCBieSAxIGJ5dGUgb2YgVGltZW91dCwgZm9sbG93ZWQgYnkgdHdvCiAgICAgICAg IHBhZCBieXRlcyBvZiB6ZXJvLgoKICAgICAgICAgKyAgQ291bnQgKDEgYnl0ZSkgOiBOdW1iZXIg b2YgbG9vcGJhY2sgY2VsbHMvbWVzc2FnZXMgdGhhdAogICAgICAgICAgICBzaG91bGQgYmUgZ2Vu ZXJhdGVkIG9uIHRoZSBsb2NhbCBsb29wIGFzIHBhcnQgb2YgdGhlCiAgICAgICAgICAgIGxvb3Bi YWNrIHRlc3QuICBUaGUgTkFTIFNIT1VMRCByZXN0cmljdCB0aGUgImNvdW50IiB0byBiZQogICAg ICAgICAgICBncmVhdGVyIHRoYW4gMCBhbmQgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDMyLiAgVGhl IERTTEFNCiAgICAgICAgICAgIFNIT1VMRCBkaXNjYXJkIHRoZSByZXF1ZXN0IGZvciBhIGxvb3Bi YWNrIHRlc3QsIGlmIHRoZQogICAgICAgICAgICByZWNlaXZlZCB0ZXN0IHBhcmFtZXRlcnMgY29u dGFpbiBhbiBvdXQgb2YgcmFuZ2UgdmFsdWUgZm9yCiAgICAgICAgICAgIHRoZSAiY291bnQiIGZp ZWxkLiAgVGhlIERTTEFNIE1BWSBvcHRpb25hbGx5IHNlbmQgYSBmYWlsdXJlCiAgICAgICAgICAg IHJlc3BvbnNlIHRvIHRoZSBOQVMgd2l0aCB0aGUgY29kZSAiaW52YWxpZCB0ZXN0IHBhcmFtZXRl ciIuCgogICAgICAgICArICBUaW1lb3V0ICgxIGJ5dGUpIDogVXBwZXIgYm91bmQgb24gdGhlIHRp bWUgaW4gc2Vjb25kcyB0aGF0CiAgICAgICAgICAgIHRoZSBOQVMgd291bGQgd2FpdCBmb3IgYSBy ZXNwb25zZSBmcm9tIHRoZSBEU0xBTS4gIElmIHRoZQogICAgICAgICAgICB0b3RhbCB0aW1lIHRh a2VuIGJ5IHRoZSBEU0xBTSB0byBjb21wbGV0ZSBhIHRlc3Qgd2l0aAogICAgICAgICAgICByZXF1 ZXN0ZWQgcGFyYW1ldGVycywgZXhjZWVkcyB0aGUgc3BlY2lmaWVkICJ0aW1lb3V0IiB2YWx1ZSwK ICAgICAgICAgICAgaXQgY2FuIGNob29zZSB0byBvbWl0IHRoZSBnZW5lcmF0aW9uIG9mIGEgcmVz cG9uc2UgdG8gdGhlCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1 LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDQwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgICAg ICAgICAgIE5BUy4gIERTTEFNIFNIT1VMRCB1c2UgYSBsb2NhbGx5IGRldGVybWluZWQgdmFsdWUg Zm9yIHRoZQogICAgICAgICAgICAidGltZW91dCIsIGlmIHRoZSByZWNlaXZlZCB2YWx1ZSBvZiB0 aGUgInRpbWVvdXQiIHBhcmFtZXRlcgogICAgICAgICAgICBpcyAwLgoKICAgbyAgVHlwZSAoT3Bh cXVlLURhdGEgPSAweDA4KSA6IFRoaXMgaXMgYW4gb3B0aW9uYWwgVExWLiAgSWYgcHJlc2VudAog ICAgICBpbiB0aGUgcmVxdWVzdCBtZXNzYWdlLCB0aGUgRFNMQU0gU0hPVUxEIHJlZmxlY3QgaXQg YmFjayBpbiB0aGUKICAgICAgcmVzcG9uc2UgdW5tb2RpZmllZAoKICAgICAgICAgTGVuZ3RoIDog KDggYnl0ZXMpCgogICAgICAgICBWYWx1ZSA6IFR3byAzMiBiaXQgaW50ZWdlcnMgaW5zZXJ0ZWQg YnkgdGhlIE5BUyAobm90IHRvIGJlCiAgICAgICAgIGludGVycHJldGVkIGJ5IHRoZSBEU0xBTSwg YnV0IGp1c3QgcmVmbGVjdGVkIGJhY2sgaW4gdGhlCiAgICAgICAgIHJlc3BvbnNlKS4KCiAgIFRo ZSBhY2Nlc3Mgbm9kZSBnZW5lcmF0ZXMgYSBzdWNjZXNzIG9yIGZhaWx1cmUgcmVzcG9uc2Ugd2hl biBpdCBkZWVtcwogICB0aGUgbG9vcGJhY2sgdGVzdCB0byBiZSBjb21wbGV0ZS4gICJQb3J0IE1h bmFnZW1lbnQiIG1lc3NhZ2UgKHR5cGUKICAgMzIpIGlzIHVzZWQuICBUaGUgcmVzdWx0IGZpZWxk IFNIT1VMRCBiZSBzZXQgdG8gc3VjY2VzcyBvciBmYWlsdXJlLgogICBUaGUgZnVuY3Rpb24gdHlw ZSBTSE9VTEQgYmUgc2V0IHRvIDB4MDkuICBUaGUgdHJhbnNhY3Rpb24gSUQgU0hPVUxECiAgIGJl IGNvcGllZCBmcm9tIHRoZSBzZXF1ZW5jZSBudW1iZXIgY29udGFpbmVkIGluIHRoZSBjb3JyZXNw b25kaW5nCiAgIHJlcXVlc3QuICBUaGUgb3RoZXIgcGFyYW1ldGVycyBub3QgZXhwbGljaXRseSBk ZWZpbmVkIGhlcmUgU0hPVUxEIGJlCiAgIHNldCBhcyBzcGVjaWZpZWQgaW4gdGhlIHJlcXVlc3Qg bWVzc2FnZSBhYm92ZS4gIFRoZSBjb2RlIGZpZWxkIFNIT1VMRAogICBiZSBzZXQgdG8gYSB2YWx1 ZSBpbiB0aGUgcmFuZ2UgMHg1MDAgdG8gMHg1ZmYgKHRvIGJlIHJlc2VydmVkIHdpdGgKICAgSUFO QSkgdG8gaW5kaWNhdGUgdGhlIHN0YXR1cyBvZiB0aGUgZXhlY3V0ZWQgdGVzdC4gIFRoZSB2YWxp ZCB2YWx1ZXMKICAgZGVmaW5lZCBhcmUgKGNhbiBiZSBleHRlbmRlZCBpbiBmdXR1cmUpOgoKICAg ICAgMHg1MDAgOiBTcGVjaWZpZWQgYWNjZXNzIGxpbmUgZG9lcyBub3QgZXhpc3QKCiAgICAgIDB4 NTAxIDogTG9vcGJhY2sgdGVzdCB0aW1lZCBvdXQKCiAgICAgIDB4NTAyIDogUmVzZXJ2ZWQKCiAg ICAgIDB4NTAzIDogRFNMIGxpbmUgc3RhdHVzIHNob3d0aW1lCgogICAgICAweDUwNCA6IERTTCBs aW5lIHN0YXR1cyBpZGxlCgogICAgICAweDUwNSA6IERTTCBsaW5lIHN0YXR1cyBzaWxlbnQKCiAg ICAgIDB4NTA2IDogRFNMIGxpbmUgc3RhdHVzIHRyYWluaW5nCgogICAgICAweDUwNyA6IERTTCBs aW5lIGludGVncml0eSBlcnJvcgoKICAgICAgMHg1MDggOiBEU0xBTSByZXNvdXJjZSBub3QgYXZh aWxhYmxlCgogICAgICAweDUwOSA6IEludmFsaWQgdGVzdCBwYXJhbWV0ZXIKCiAgIFRoZSBFeHRl bnNpb24gdmFsdWUgY2FuIGNvbnRhaW4gb25lIG9yIG1vcmUgVExWcyBpbmNsdWRpbmcgdGhlIFRM ViB0bwogICBpZGVudGlmeSB0aGUgYWNjZXNzIGxpbmUgb24gd2hpY2ggdGhlIHRlc3Qgd2FzIHBl cmZvcm1lZCwgYW5kIGRldGFpbHMKICAgZnJvbSBleGVjdXRpbmcgdGhlIHRlc3QuICBUaGUgYWNj ZXNzIGxpbmUgaWRlbnRpZmllciBTSE9VTEQgYmUKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNDFdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0 b2JlciAyMDA5CgoKICAgaWRlbnRpY2FsIHRvIHdoYXQgd2FzIGNvbnRhaW5lZCBpbiB0aGUgcmVx dWVzdC4gIFRoZSByZWxldmFudCBUTFZzCiAgIGFyZToKCiAgIG8gIFR5cGUgKEFjY2Vzcy1Mb29w LUNpcmN1aXQtSUQgPSAweDAxKSA6IGRlZmluZWQgaW4gc2VjdGlvbgogICAgICBTZWN0aW9uIDUu NC4xCgogICBvICBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3VpdC1JRC1CaW5hcnkgPSAw eDA2KTogZGVmaW5lZCBpbgogICAgICBzZWN0aW9uIFNlY3Rpb24gNS40LjEKCiAgIG8gIFR5cGUg KEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlELUFTQ0lJID0gMHgwMyk6IGRlZmluZWQgaW4K ICAgICAgc2VjdGlvbiBTZWN0aW9uIDUuNC4xCgogICBvICBUeXBlIChPcGFxdWUtRGF0YSA9IDB4 MDgpIDogRGF0YSBpbnNlcnRlZCBieSB0aGUgTkFTIGluIHRoZQogICAgICByZXF1ZXN0IHJlZmxl Y3RlZCBiYWNrIGJ5IHRoZSBEU0xBTS4KCiAgICAgICAgIExlbmd0aCA6ICh1cCB0byA4IGJ5dGVz KQoKICAgICAgICAgVmFsdWUgOiBUd28gMzIgYml0IGludGVnZXJzIGFzIHJlY2VpdmVkIGluIHRo ZSByZXF1ZXN0IChvcGFxdWUKICAgICAgICAgdG8gdGhlIERTTEFNKS4KCiAgIG8gIFR5cGUgKE9B TS1Mb29wYmFjay1UZXN0LVJlc3BvbnNlLVN0cmluZyA9IDB4MDkpCgogICAgICAgICBMZW5ndGgg OiAodXAgdG8gMTI4IGJ5dGVzKQoKICAgICAgICAgVmFsdWUgOiBTdWl0YWJseSBmb3JtYXR0ZWQg QVNDSUkgc3RyaW5nIGNvbnRhaW5pbmcgdXNlZnVsCiAgICAgICAgIGRldGFpbHMgYWJvdXQgdGhl IHRlc3QgdGhhdCB0aGUgTkFTIHdpbGwgZGlzcGxheSBmb3IgdGhlCiAgICAgICAgIG9wZXJhdG9y LCBleGFjdGx5IGFzIHJlY2VpdmVkIGZyb20gdGhlIERTTEFNIChubyBtYW5pcHVsYXRpb24vCiAg ICAgICAgIGludGVycHJldGF0aW9uIGJ5IHRoZSBOQVMpLiAgVGhpcyBpcyBhbiBvcHRpb25hbCBU TFYsIGJ1dCBpdCBpcwogICAgICAgICBzdHJvbmdseSByZWNvbW1lbmRlZCwgdGhhdCBpbiBjYXNl IG9mIEFUTSBiYXNlZCBsb2NhbCBsb29wLCB0aGUKICAgICAgICAgRFNMQU0gYXQgdGhlIHZlcnkg bGVhc3QgaW5kaWNhdGVzIHZpYSB0aGlzIFRMViwgdGhlIHRvdGFsCiAgICAgICAgIGxvb3BiYWNr IGNlbGxzIGdlbmVyYXRlZCBhbmQgdGhlIHRvdGFsIGxvb3BiYWNrIGNlbGxzCiAgICAgICAgIHN1 Y2Nlc3NmdWxseSByZWNlaXZlZCBhcyBwYXJ0IG9mIGV4ZWN1dGluZyB0aGUgcmVxdWVzdGVkCiAg ICAgICAgIGxvb3BiYWNrIHRlc3QuCgo1LjQuNS4gIEFkZGl0aW9uYWwgR1NNUCBFeHRlbnNpb25z IGZvciBmdXR1cmUgdXNlIGNhc2VzCgogICBHU01QIHByb3RvY29sIGRlZmluZWQgaW4gW1JGQzMy OTJdIGFsbG93cyBmb3IgdHdvIG1lc3NhZ2luZwogICBwcmluY2lwbGVzIGluIGNhc2Ugb2YgUmVx dWVzdC9SZXNwb25zZSBpbnRlcmFjdGlvbjoKCiAgIG8gIFRoZSBzYW1lIG1lc3NhZ2UgdHlwZSB1 c2VkIGZvciBib3RoIHJlcXVlc3QgbWVzc2FnZSBhbmQgcmVzcG9uc2UKICAgICAgbWVzc2FnZSB3 aGVyZSByZXN1bHQgZmllbGQgYW5kIGNvZGUgZmllbGQgc2V0dGluZ3MgYXJlIHVzZWQgdG8KICAg ICAgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzOwoK ICAgbyAgVHdvIGRpZmZlcmVudCBtZXNzYWdlIHR5cGVzIGZvciByZXF1ZXN0IG1lc3NhZ2UgYW5k IHJlc3BvbnNlCiAgICAgIG1lc3NhZ2VzLgoKICAgRmlyc3QgbWVzc2FnZSBwcmluY2lwbGUgaGFz IGJlZW4gYWRvcHRlZCBmb3IgdXNlIGNhc2VzIGRlZmluZWQgaW4KICAgc2VjdGlvbnMgU2VjdGlv biA1LjQuMiB0byBTZWN0aW9uIDUuNC40LCB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3Rpb24KCgoK IFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAg ICAgICAgW1BhZ2UgNDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90 b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgaXMgdG8gc3BlY2lmeSB0aGUg c2Vjb25kIHR5cGUgb2YgYXBwcm9hY2ggaW4gb3JkZXIgdG8gYWxsb3cgdGhlIHVzZQogICBvZiB0 aGlzIG1lc3NhZ2UgcHJpbmNpcGxlIGZvciB0aGUgZGV2ZWxvcG1lbnQgb2YgZnV0dXJlIHVzZSBj YXNlcy4KCiAgIEluIHRoZSBuZXcgbWVzc2FnZSBwYXJhZGlnbSBkaWZmZXJlbnQgbWVzc2FnZSB0 eXBlcyBhcmUgdXNlZCBhcyBBTkNQCiAgIFJlcXVlc3QgTWVzc2FnZSBhbmQgQU5DUCBSZXNwb25z ZSBNZXNzYWdlOiB0aGUgZm9ybWF0IG9mIGEgZ2VuZXJpYwogICBBTkNQIG1lc3NhZ2Ugc3RhcnRz IHdpdGggdGhlIGNvbW1vbiBHU01QIGhlYWRlciBhcyBpbiB0aGUgY2FzZSBvZiB0aGUKICAgZXhp c3RpbmcgQU5DUCBpbXBsZW1lbnRhdGlvbiwgYnV0IHRoZSBSZXN1bHQgZmllbGQgaXMgc2V0IHRv IElnbm9yZQogICBpbiBvcmRlciB0byBpbnN0cnVjdCB0aGUgcmVjZWlwdCB0byBpZ25vcmUgdGhp cyBmaWVsZCBhbmQgZm9sbG93IHRoZQogICBwcm9jZWR1cmVzIHNwZWNpZmllZCBmb3IgdGhlIHJl Y2VpdmVkIG1lc3NhZ2UgdHlwZS4gIFRoZSBUcmFuc2FjdGlvbgogICBJZGVudGlmaWVyIGZpZWxk IGlzIHVzZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiByZXF1ZXN0IG1lc3NhZ2VzIGFuZAogICB0 byBhc3NvY2lhdGUgYSByZXNwb25zZSBtZXNzYWdlIHRvIGEgcmVxdWVzdC4gIEFwcGxpY2F0aW9u cyB0aGF0CiAgIHJlcXVpcmUgc3VjaCByZXNwb25zZSBjb3JyZWxhdGlvbiBNVVNUIHNldCB0aGUg VHJhbnNhY3Rpb24gSWRlbnRpZmllcgogICB0byBhIHZhbHVlIGluIHRoZSByYW5nZSAoMSwgMl4y NCAtIDEpLiAgV2hlbiB1c2VkIGluIHRoaXMgbWFubmVyLCB0aGUKICAgVHJhbnNhY3Rpb24gSWRl bnRpZmllciBzZXF1ZW5jaW5nIE1VU1QgYmUgbWFpbnRhaW5lZCBpbmRlcGVuZGVudGx5CiAgIGZv ciBlYWNoIEFOQ1AgYWRqYWNlbmN5IGFuZCBwZXIgbWVzc2FnZSB0eXBlLiAgRnVydGhlcm1vcmUs IGl0IFNIT1VMRAogICBiZSBpbmNyZW1lbnRlZCBsaW5lYXJseSBmb3IgZWFjaCBuZXcgbWVzc2Fn ZSBvZiB0aGUgZ2l2ZW4gdHlwZSwKICAgY3ljbGluZyBiYWNrIHRvIDEgYWZ0ZXIgcnVubmluZyB0 aGUgZnVsbCByYW5nZS4gIE1lc3NhZ2UgdHlwZXMgbm90CiAgIHJlcXVpcmluZyByZXNwb25zZSBt ZXNzYWdlIGNvcnJlbGF0aW9uIFNIT1VMRCBzZXQgdGhlIFRyYW5zYWN0aW9uIElkCiAgIGZpZWxk IHRvIDB4MC4gIEluIHRoZSBldmVudCBvZiBhbiBBTkNQIHRyYW5zcG9ydCBwcm90b2NvbCBmYWls dXJlLAogICBhbGwgcGVuZGluZyBBTkNQIG1lc3NhZ2VzIGRlc3RpbmVkIHRvIHRoZSBkaXNjb25u ZWN0ZWQgcmVjaXBpZW50IGNhbgogICBiZSBkaXNjYXJkZWQgdW50aWwgdGhlIHRyYW5zcG9ydCBp cyByZS0gZXN0YWJsaXNoZWQgZm9sbG93aW5nIHdoaWNoCiAgIHRoZSBUcmFuc2FjdGlvbiBJZGVu dGlmaWVyIGlzIHJlLSBpbml0aWFsaXplZC4KCiAgIFRoZSB2YWx1ZSBvZiB0aGUgVHJhbnNhY3Rp b24gSWRlbnRpZmllciBpbiBhIFJlc3BvbnNlIG1lc3NhZ2UgTVVTVCBiZQogICBzZXQgdG8gdGhh dCBvZiB0aGUgcmVzcGVjdGl2ZSBSZXF1ZXN0IG1lc3NhZ2UuICBUaGlzIGFsbG93cyB0aGUKICAg UmVxdWVzdGVyIHRvIGNvcnJlbGF0ZSB0aGUgUmVzcG9uc2UgdG8gdGhlIG9yaWdpbmFsIFJlcXVl c3QuICBUaGUKICAgVHJhbnNhY3Rpb24gSWRlbnRpZmllciBpcyBub3QgdXNlZCBpbiBBTkNQIGFk amFjZW5jeSBtZXNzYWdlcy4gIEFsc28sCiAgIG90aGVyIEFOQ1AgYXBwbGljYXRpb25zIG5vdCBy ZXF1aXJpbmcgaXQgU0hPVUxEIHNldCB0aGUgVHJhbnNhY3Rpb24KICAgSWRlbnRpZmllciB0byAw eDAgaW4gdGhlaXIgbWVzc2FnZXMuCgogICBBbGwgVExWcyB3aXRoaW4gdGhlIEFOQ1AgbWVzc2Fn ZSBoYXZlIHRvIGJlIDMyIGJpdCBhbGlnbmVkLCBhbmQgd2hlbgogICBuZWNlc3NhcnkgcGFkZGVk IHdpdGggMHMgdG8gdGhlIDMyIGJpdCBib3VuZGFyeS4gIFRoZSBwYWRkaW5nIGlzIG5vdAogICBy ZWZsZWN0ZWQgaW4gdGhlIG1lc3NhZ2UgbGVuZ3RoIGZpZWxkLgoKNS40LjUuMS4gIEdlbmVyYWwg d2VsbCBrbm93biBUTFZzCgogICBUaGlzIHNlY3Rpb24gY29udGFpbnMgdGhlIGRlZmluaXRpb25z IG9mIHRocmVlIGdlbmVyYWwgd2VsbCBrbm93bgogICBUTFZzLiAgVGhlc2UgVExWcyBhcmUgaW50 ZW5kZWQgdG8gYmUgcmUtdXNhYmxlIGFjcm9zcyBkaWZmZXJlbnQKICAgbWVzc2FnZXMuCgo1LjQu NS4xLjEuICBUYXJnZXQgVExWCgogICBUaGUgVGFyZ2V0IFRMViAoMHgxMDAwIC0gMHgwMTAyMCkg aXMgaW50ZW5kZWQgdG8gYmUgYSBnZW5lcmFsIHdlbGwKICAga25vd24gVExWIGFsbG93aW5nIHRo ZSByZXByZXNlbnRhdGlvbiBvZiBkaWZmZXJlbnQgdHlwZXMgb2Ygb2JqZWN0cy4KICAgSXRzIHVz ZSBpcyBub3QgcmVzdHJpY3RlZCB0byBhbnkgc3BlY2lmaWMgTWVzc2FnZSBUeXBlLgoKCgoKCgog V2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAg ICAgICBbUGFnZSA0M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3Rv Y29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsKICAgICAgIHwgICAgVExWIFR5cGUgPSBUYXJnZXQgICAgICAgICAgfCAgICAgICAg VGFyZ2V0LVRMViBMZW5ndGggICAgICB8CiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgVGFyZ2V0IEluZm8gICAgICAgICAgICAg ICAgICAgICAgICAgICB+CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIFRhcmdl dCBUTFY6CgogICAgICAgICAgICAgVExWICgweDEwMDAgLSAweDEwMjApIGluZGljYXRpbmcgdGhl IHR5cGUgb2YgdGFyZ2V0IGJlaW5nCiAgICAgICAgICAgICBhZGRyZXNzZWQuICBUYXJnZXQgVFZM IDB4MTAwMCBpbmRpY2F0ZXMgYSBzaW5nbGUgQWNjZXNzLQogICAgICAgICAgICAgUG9ydC4KCiAg IFRhcmdldCBUTFYgTGVuZ3RoOgoKICAgICAgICAgICAgIExlbmd0aCBpbiBieXRlcyBvZiBUYXJn ZXQgSW5mby4gIEV4Y2x1ZGVzIFRMViBoZWFkZXIKCiAgIFRhcmdldCBJbmZvOgoKICAgICAgICAg ICAgIFRhcmdldCBpbmZvcm1hdGlvbiBhcyBkZWZpbmVkIGZvciBlYWNoIHRoZSBnaXZlbiB0YXJn ZXQuCiAgICAgICAgICAgICBUaGUgZmllbGQgY2FuIGNvbnNpc3Qgb2Ygc3ViLVRMVnMuCgogICBJ biBpdHMgc2ltcGxlc3QgZm9ybSwgd2hlbiB0YXJnZXRpbmcgYSBzaW5nbGUgYWNjZXNzIGxpbmUg dGhlIFRhcmdldC0KICAgVExWIHdpbGwgYmUgc2V0IHRvIGEgdmFsdWUgb2YgKDB4MTAwMCksIGFu ZCBjYXJyeSBpbiBpdHMgcGF5bG9hZCBvbmUKICAgb3IgbW9yZSBzdWItVExWcyBpZGVudGlmeWlu ZyB0aGUgdGFyZ2V0LiAgVGhlIGZvbGxvd2luZyBleGFtcGxlCiAgIGlsbHVzdHJhdGVzIHRoZSBt ZXNzYWdlIGZvcm1hdCBmb3IgYSBzaW5nbGUgcG9ydCBpZGVudGlmaWVkIGJ5IGFuCiAgIEFjY2Vz cy1Mb29wLUNpcmN1aXQtSUQgVExWICgweDAwMDEpIHRoYXQgY291bGQgYmUgZGVyaXZlZCBmcm9t IGEKICAgUG9ydC1VUCBtZXNzYWdlOgoKICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg ICAgICB8ICAgIFRMViBUeXBlID0gVGFyZ2V0ICAgICAgICAgIHwgICAgICAgIFRhcmdldC1UTFYg TGVuZ3RoICAgICAgfAogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgIHwgQWNjZXNzLUxvb3AtQ2lyY3Vp dC1JRD0weDAwMDEgfCAgICAgICBDaXJjdWl0LUlEIExlbmd0aCAgICAgICB8CiAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgICAgIH4gICAgICAgICAgICAgICAgICAgIEFjY2VzcyBM b29wIENpcmN1aXQgSUQgICAgICAgICAgICAgICAgICAgICB+CiAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKCjUuNC41LjEuMi4gICBDb21tYW5kIFRMVgoKICAgVGhlIENvbW1hbmQgVExW ICgweDExKSBpcyBpbnRlbmRlZCB0byBiZSBhIGdlbmVyYWwgd2VsbCBrbm93biBUTFYKICAgYWxs b3dpbmcgdGhlIGVuY2Fwc3VsYXRpb24gb2Ygb25lIG9yIG1vcmUgY29tbWFuZCBkaXJlY3RpdmVz IGluIGEgVExWCiAgIG9yaWVudGVkIG1lc3NhZ2UuICBUaGUgc2VtYW50aWNzIG9mIHRoZSBjb21t YW5kIGFyZSBhbGxvd2VkIHRvIGJlCiAgIHNwZWNpZmllZCBmb3IgZWFjaCBtZXNzYWdlIHR5cGUs IGllIGRpZmZlcmVudCBtZXNzYWdlIHR5cGVzIHRoYXQKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNDRdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAg T2N0b2JlciAyMDA5CgoKICAgY2hvb3NlIHRvIGNhcnJ5IHRoZSBDb21tYW5kIFRMViBhcmUgZXhw ZWN0ZWQgdG8gZGVmaW5lIHRoZSBtZWFuaW5nIG9mCiAgIHRoZSBjb250ZW50IG9mIHRoZSBwYXls b2FkLCB3aGljaCBjb3VsZCBiZSByZS11c2VkIGZyb20gdGhvc2UgYWxyZWFkeQogICBkZWZpbmVk IGVsc2V3aGVyZSBpZiBhcHByb3ByaWF0ZS4KCgogICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgICAgIHwgICAgIFRMViBUeXBlID0gQ29tbWFuZCAgICAgICAgfCAgICAgICBDb21tYW5k LVRMViBMZW5ndGggICAgICB8CiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg IH4gICAgICAgICAgICAgICAgICAgICAgICAgQ29tbWFuZCBJbmZvICAgICAgICAgICAgICAgICAg ICAgICAgICB+CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgIHwgICAgIEFk ZGl0aW9uYWwgc3ViLVRMViBUeXBlICAgfCAgIEFkZGl0aW9uYWwgc3ViLVRMViBMZW5ndGggICB8 CiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgIH4gICAgICAgICAgICAgICAg ICAgQWRkaXRpb25hbCBzdWItVExWIGRhdGEgICAgICAgICAgICAgICAgICAgICB+CiAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIENvbW1hbmQgVExWOgoKICAgICAgICAgICAgIFRM ViAoMHgxMSkgaW5kaWNhdGluZyB0aGUgY29udGVudHMgdG8gYmUgb25lIG9yIG1vcmUKICAgICAg ICAgICAgIGNvbW1hbmQgZGlyZWN0aXZlcy4KCiAgIENvbW1hbmQgVExWIExlbmd0aDoKCiAgICAg ICAgICAgICBDb21iaW5lZCBsZW5ndGggaW4gYnl0ZXMgb2YgdGhlIGRhdGEgaW4gQ29tbWFuZCBJ bmZvIGFuZAogICAgICAgICAgICAgc3ViLVRMVi4gIEV4Y2x1ZGVzIHRoZSBDb21tYW5kIFRMViBo ZWFkZXIKCiAgIENvbW1hZC1JbmZvOgoKICAgICAgICAgICAgIENvbW1hbmQgaW5mb3JtYXRpb24g YXMgZGVmaW5lZCBmb3IgZWFjaCBtZXNzYWdlIHR5cGUuICBUaGUKICAgICAgICAgICAgIGZpZWxk IGNhbiBjb25zaXN0IG9mIHN1Yi1UTFZzLgoKICAgQWRkaXRpb25hbCBzdWItVExWOgoKICAgICAg ICAgICAgIEFkZGl0aW9uYWwgc3ViLVRMVnMgY2FuIGJlIHByZXNlbnQgaW4gYSBjb21tYW5kIFRM Vi4gIEFueQogICAgICAgICAgICAgc3VjaCBzdWItVExWcyBtdXN0IGRpcmVjdGx5IGZvbGxvdyBl YWNoIGNvbW1hbmQuCgogICBBZGRpdGlvbmFsIHN1Yi1UTFYgTGVuZ3RoOgoKICAgICAgICAgICAg IE51bWJlciBvZiBhY3R1YWwgYnl0ZXMgY29udGFpbmVkIGluIHRoZSB2YWx1ZSBwb3J0aW9uIG9m CiAgICAgICAgICAgICBlYWNoIGFkZGl0aW9uYWwgc3ViLVRMVgoKCgoKCgoKIFdhZGh3YSwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2Ug NDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAg ICAgICAgICAgT2N0b2JlciAyMDA5CgoKNS40LjUuMS4zLiAgU3RhdHVzLWluZm8gVExWCgogICBU aGUgU3RhdHVzLWluZm8tVExWIGlzIGludGVuZGVkIHRvIGJlIGEgZ2VuZXJhbCB3ZWxsIGtub3du IFRMViB1c2VkCiAgIHRvIGNvbnZleSB0aGUgc3RhdHVzIGNvZGUgcmVnYXJkaW5nIGNvbW1hbmRz IGFuZC9vciByZXF1ZXN0cy4gIFRoZQogICBmb3JtYXQgb2YgdGhlIFN0YXR1cy1pbmZvLVRMViAo MHgwMTA2KSBpcyBzaG93biBiZWxvdy4KCiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgICAgfCAgICBUTFYgVHlwZSA9IFN0YXR1cy1pbmZvICAgICB8ICAgICAgICBTdGF0dXMgVExW IExlbmd0aCAgICAgIHwKICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgICB8ICAgIFJlc2VydmVkICAgfCAg TXNnIFR5cGUgICAgIHwgICAgICBFcnJvciBNZXNzYWdlIExlbmd0aCAgICAgfAogICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgICAgIHwgICAgICAgIEVycm9yIE1lc3NhZ2UgKGFsaWduZWQgdG8gNCBieXRlcyBs ZW5ndGgpICAgICAgICAgICAgICB8CiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICAgfCAgICAgICAgICAg c3ViLVRMVnMuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0KCiAgIFN0YXR1cy1pbmZvIFRMVjoKCiAgICAgICAgICAgICBUTFYgKDB4MTA2 KSBjb252ZXlpbmcgdGhlIHN0YXR1cyBvciBlcnJvciByZXNwb25zZSBvZiBhCiAgICAgICAgICAg ICBjb21tYW5kCgogICBTdGF0dXMgVExWIExlbmd0aDoKCiAgICAgICAgICAgICBTcGVjaWZpZXMg dGhlIGxlbmd0aCBpbiBieXRlcyBvZiB0aGUgU3RhdHVzIEluZm8gVExWCiAgICAgICAgICAgICBw YXlsb2FkLiAgRXhjbHVkZXMgdGhlIFRMViBoZWFkZXIKCiAgIFJlc2VydmVkOgoKICAgICAgICAg ICAgIFRoaXMgZmllbGQgTVVTVCBiZSBzZXQgdG8gYWxsIHplcm9lcyBieSB0aGUgc2VuZGVyIGFu ZAogICAgICAgICAgICAgaWdub3JlZCBieSB0aGUgcmVjZWl2ZXIuCgogICBNc2cgVHlwZToKCiAg ICAgICAgICAgICBUaGUgbWVzc2FnZSB0eXBlIHZhbHVlIG9mIHRoZSBtZXNzYWdlIHRoZSBTdGF0 dXMtaW5mbyBUTFYKICAgICAgICAgICAgIGlzIHJlcG9ydGluZyBvbgoKICAgRXJyb3IgTWVzc2Fn ZSBMZW5ndGg6CgogICAgICAgICAgICAgSXQgY29udGFpbnMgdGhlIGxlbmd0aCBvZiBhbiBvcHRp b25hbCBlcnJvciBtZXNzYWdlIG9yIDAgaWYKICAgICAgICAgICAgIG5vbmUuCgogICBFcnJvciBt ZXNzYWdlOgoKICAgICAgICAgICAgIEl0IGNvbnRhaW5zIGEgaHVtYW4tcmVhZGFibGUgZGVzY3Jp cHRpb24gb2YgdGhlIGVycm9yIGJlaW5nCiAgICAgICAgICAgICByZXBvcnRlZCBieSB0aGUgU3Rh dHVzLWluZm8gZmllbGQuCgogICBUTFZzOgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA0Nl0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVy IDIwMDkKCgogICAgICAgICAgICAgVGhpcyBmaWVsZCBpcyBvZiBpbmRldGVybWluYXRlIGxlbmd0 aCwgYW5kIGNvbnRhaW5zIHplcm8gb3IKICAgICAgICAgICAgIG1vcmUgb2YgdGhlIFRMVnMgYXNz b2NpYXRlZCB3aXRoIHRoZSBTdGF0dXMtaW5mbyBUTFYuICBUaGUKICAgICAgICAgICAgIGZvbGxv d2luZyBUTFZzIGFyZSBSRUNPTU1FTkRFRCB0byBiZSBwcm92aWRlZCBpZiB0aGUKICAgICAgICAg ICAgIGluZGljYXRlZCBDb2RlIHZhbHVlcyBhcmUgZ2l2ZW4gaW4gdGhlIGhlYWRlciBvZiB0aGUK ICAgICAgICAgICAgIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgU3RhdHVzLWluZm8gVExWOgoKICAg ICAgICAgICAgIENvZGUgdmFsdWUgNCBvciA1OiB0aGUgVGFyZ2V0IG9yIG90aGVyIFRMViBpZGVu dGlmeWluZyB0aGUKICAgICAgICAgICAgIHVua25vd24gb3IgdW5hdmFpbGFibGUgcG9ydC4KCiAg ICAgICAgICAgICBDb2RlIHZhbHVlIDg0OiB0aGUgVExWIHRoYXQgaXMgdW5zdXBwb3J0ZWQgb3Ig Y29udGFpbnMgdGhlCiAgICAgICAgICAgICB1bnN1cHBvcnRlZCB2YWx1ZS4KCjUuNC41LjIuICBH ZW5lcmljIFJlc3BvbnNlIE1lc3NhZ2UKCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBHZW5l cmljIFJlc3BvbnNlIG1lc3NhZ2UuICBUaGUgR2VuZXJpYwogICBSZXNwb25zZSBtZXNzYWdlIG1h eSBiZSBzcGVjaWZpZWQgYXMgdGhlIGFwcHJvcHJpYXRlIHJlc3BvbnNlIHRvIGEKICAgbWVzc2Fn ZSBkZWZpbmVkIGluIGFuIGV4dGVuc2lvbiB0byBBTkNQLCBpbnN0ZWFkIG9mIGEgbW9yZSBzcGVj aWZpYwogICByZXNwb25zZSBtZXNzYWdlLiAgQXMgYSBnZW5lcmFsIGd1aWRlbGluZSwgc3BlY2lm aWNhdGlvbiBvZiB0aGUKICAgR2VuZXJpYyBSZXNwb25zZSBtZXNzYWdlIGFzIGEgcmVzcG9uc2Ug aXMgYXBwcm9wcmlhdGUgd2hlcmUgbm8gZGF0YQogICBuZWVkcyB0byBiZSByZXR1cm5lZCB0byB0 aGUgcGVlciBvdGhlciB0aGFuIGEgcmVzdWx0IChzdWNjZXNzIG9yCiAgIGZhaWx1cmUpLCBwbHVz LCBpbiB0aGUgY2FzZSBvZiBhIGZhaWx1cmUsIGEgY29kZSBpbmRpY2F0aW5nIHRoZQogICByZWFz b24gZm9yIGZhaWx1cmUgYW5kIGEgbGltaXRlZCBhbW91bnQgb2YgZGlhZ25vc3RpYyBkYXRhLgog ICBEZXBlbmRpbmcgb24gdGhlIHBhcnRpY3VsYXIgdXNlIGNhc2UsIHRoZSBHZW5lcmljIFJlc3Bv bnNlIG1lc3NhZ2UKICAgTUFZIGJlIHNlbnQgYnkgZWl0aGVyIHRoZSBOQVMgb3IgdGhlIEFOLgoK ICAgVGhlIEFOIG9yIE5BUyBNQVkgc2VuZCBhIEdlbmVyaWMgUmVzcG9uc2UgbWVzc2FnZSBpbmRp Y2F0aW5nIGEKICAgZmFpbHVyZSBjb25kaXRpb24gaW5kZXBlbmRlbnRseSBvZiBhIHNwZWNpZmlj IHJlcXVlc3QgYmVmb3JlIGNsb3NpbmcKICAgdGhlIGFkamFjZW5jeSBhcyBhIGNvbnNlcXVlbmNl IG9mIHRoYXQgZmFpbHVyZSBjb25kaXRpb24uICBJbiB0aGlzCiAgIGNhc2UsIHRoZSBzZW5kZXIg TVVTVCBzZXQgdGhlIFRyYW5zYWN0aW9uIElkZW50aWZpZXIgZmllbGQgaW4gdGhlCiAgIGhlYWRl ciBhbmQgdGhlIE1lc3NhZ2UgVHlwZSBmaWVsZCB3aXRoaW4gdGhlIFN0YXR1cy1pbmZvIFRMViB0 bwogICB6ZXJvZXMuICBUaGUgcmVjZWl2ZXIgTUFZIHJlY29yZCB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoZQogICBTdGF0dXMtaW5mbyBUTFYgZm9yIG1hbmFnZW1lbnQgdXNlLgoKICAg VGhlIGZvcm1hdCBvZiB0aGUgR2VuZXJpYyBSZXNwb25zZSBtZXNzYWdlIGlzIHNob3duIGluIEZp Z3VyZSAxNwoKCgoKCgoKCgoKCgoKCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDQ3XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAw OQoKCiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgICAgfCAgICAgICAgVHlwZSAo MHg4OC0wQykgICAgICAgICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHwKICAgICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICAgICAgIHwgVmVycyAgfCAgU3ViICB8TWVzc2FnZVR5cGU9OTEgfFJlc3Vs dCB8ICAgICAgICBDb2RlICAgICAgICAgICB8CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgICB8IFBh cnRpdGlvbiBJRCAgfCAgICAgICAgICAgIFRyYW5zYWN0aW9uIElkZW50aWZpZXIgICAgICAgICAg ICAgfAogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgICAgfEl8ICAgICAgU3ViTWVzc2FnZSBOdW1iZXIg ICAgICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHwKICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgICAgIHwgICAgICAgIFN0YXR1cy1pbmZvLVRMVj0weDEwNiAgfCAgICAgIFN0YXR1cy1UTFYt TGVuZ3RoICAgICAgICB8CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgICB8ICBSZXNlcnZlZCAgICAg fCAgTXNnIHR5cGUgICAgIHwgICAgRXJyb3IgTWVzc2FnZSBMZW5ndGggICAgICAgfAogICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgICAgICAgfCAgICAgICAgICAgRXJyb3IgTWVzc2FnZSAocGFkZGVkIHRvIDQp IGlmIExlbmd0aCA+IDAgICAgICAgICAgIHwKICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgIHwgICAg ICAgICAgIHN1Yi1UTFZzLi4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICAgRmlndXJlIDE3OiBTdHJ1Y3R1cmUgb2Yg dGhlIEdlbmVyaWMgUmVzcG9uc2UgTWVzc2FnZQoKICAgTWVzc2FnZSBUeXBlOgoKICAgICAgVGhl IG1lc3NhZ2UgdHlwZSB2YWx1ZSBmb3IgdGhlIEdlbmVyaWMgUmVzcG9uc2UgbWVzc2FnZSBpcyAw eDkxLgoKICAgUmVzdWx0OgoKICAgICAgVGhlIHZhbHVlIG9mIHRoZSBSZXN1bHQgZmllbGQgZm9y IHRoZSBHZW5lcmljIFJlc3BvbnNlIG1lc3NhZ2UKICAgICAgTVVTVCBiZSBlaXRoZXIgU3VjY2Vz cyAoMHgwMykgb3IgRmFpbHVyZSAoMHgwNCkuCgogICBDb2RlOgoKICAgICAgVGhlIENvZGUgZmll bGQgTVVTVCBoYXZlIHZhbHVlIHplcm8gaWYgUmVzdWx0IGlzIHNldCB0byBTdWNjZXNzCiAgICAg ICgweDAzKS4gIEl0IE1VU1QgaGF2ZSBhbiBhcHByb3ByaWF0ZSBub24temVybyB2YWx1ZSBpZiBS ZXN1bHQgaXMKICAgICAgc2V0IHRvIEZhaWx1cmUgKDB4MDQpLiAgQXMgZGlzY3Vzc2VkIGluIHNl Y3Rpb24gNSwgZXh0ZW5zaW9ucyB0bwogICAgICBBTkNQIE1BWSBkZWZpbmUgbmV3IENvZGUgdmFs dWVzIGZvciB1c2UgaW4gZmFpbHVyZSByZXNwb25zZXMgZm9yCiAgICAgIHNwZWNpZmljIHJlcXVl c3QgbWVzc2FnZSB0eXBlcy4KCiAgIFBhcnRpdGlvbiBJRDoKCiAgICAgIEFzIHNwZWNpZmllZCBp biBzZWN0aW9uIFNlY3Rpb24gNS4KCiAgIFRyYW5zYWN0aW9uIElkZW50aWZpZXI6CgoKCgoKCgoK IFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAg ICAgICAgW1BhZ2UgNDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90 b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgICAgVGhlIFRyYW5zYWN0aW9u IElkZW50aWZpZXIgTVVTVCBiZSBjb3BpZWQgZnJvbSB0aGUgcmVxdWVzdCB0bwogICAgICB3aGlj aCB0aGUgR2VuZXJpYyBSZXNwb25zZSBtZXNzYWdlIGlzIHJlc3BvbmRpbmcuCgogICBJLCBTdWIt bWVzc2FnZSBOdW1iZXIsIExlbmd0aDoKCiAgICAgIEFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDUu CgogICBTdGF0dXMtaW5mbyBUTFY6CgogICAgICBNQVkgYmUgcHJlc2VudCBpbiBhIHN1Y2Nlc3Mg cmVzcG9uc2UsIHRvIHByb3ZpZGUgYSB3YXJuaW5nIGFzCiAgICAgIGRlZmluZWQgZm9yIGEgc3Bl Y2lmaWMgcmVxdWVzdCBtZXNzYWdlIHR5cGUuICBNVVNUIGJlIHByZXNlbnQgaW4gYQogICAgICBm YWlsdXJlIHJlc3BvbnNlLiAgVGhlIE1lc3NhZ2UgVHlwZSBmaWVsZCB2YWx1ZSBpcyBjb3BpZWQg ZnJvbSB0aGUKICAgICAgaGVhZGVyIG9mIHRoZSByZXF1ZXN0IG1lc3NhZ2UuICBUaGUgRXJyb3Ig TWVzc2FnZSBmaWVsZCBjb250YWlucwogICAgICBodW1hbi1yZWFkYWJsZSBkaWFnbm9zdGljIHRl eHQuICBUaGUgZGVzY3JpcHRpb24gb2YgdGhlIHJlc3BvbnNlCiAgICAgIGZvciBhIHBhcnRpY3Vs YXIgcmVxdWVzdCBtZXNzYWdlIHR5cGUgTUFZIHNwZWNpZnkgZnVydGhlciBzdWItVExWcwogICAg ICB0byBiZSBpbmNsdWRlZCBpbiBTdGF0dXMtaW5mbywgZWl0aGVyIGdlbmVyYWxseSBvciBmb3Ig c3BlY2lmaWMKICAgICAgZmFpbHVyZSBDb2RlIHZhbHVlcy4KCjUuNS4gIEFUTS1zcGVjaWZpYyBj b25zaWRlcmF0aW9ucwoKICAgVGhlIHRvcG9sb2d5IGRpc2NvdmVyeSBhbmQgbGluZSBjb25maWd1 cmF0aW9uIGludm9sdmUgdGhlIERTTCBsaW5lCiAgIGF0dHJpYnV0ZXMuICBGb3IgQVRNIGJhc2Vk IGFjY2VzcyBuZXR3b3JrcywgdGhlIERTTCBsaW5lIG9uIHRoZSBEU0xBTQogICBpcyBpZGVudGlm aWVkIGJ5IHRoZSBwb3J0IGFuZCBQVlAvUFZDIGNvcnJlc3BvbmRpbmcgdG8gdGhlCiAgIHN1YnNj cmliZXIuICBUaGUgRFNMQU1zIGFyZSBjb25uZWN0ZWQgdG8gdGhlIE5BUyB2aWEgYW4gQVRNIGFj Y2VzcwogICBhZ2dyZWdhdGlvbiBuZXR3b3JrLiAgU2luY2UsIHRoZSBEU0xBTSAoYWNjZXNzLW5v ZGUpIGlzIG5vdCBkaXJlY3RseQogICBjb25uZWN0ZWQgdG8gdGhlIE5BUywgdGhlIE5BUyBuZWVk cyBhIG1lY2hhbmlzbSB0byBsZWFybiB0aGUgRFNMIGxpbmUKICAgaWRlbnRpZmllciAobW9yZSBn ZW5lcmFsbHkgcmVmZXJyZWQgdG8gYXMgIkFjY2VzcyBMb29wIENpcmN1aXQtSUQiKQogICBjb3Jy ZXNwb25kaW5nIHRvIGEgc3Vic2NyaWJlci4gIFRoZSAiQWNjZXNzIGxvb3AgY2lyY3VpdC1JRCIg aGFzIG5vCiAgIGxvY2FsIHNpZ25pZmljYW5jZSBvbiB0aGUgTkFTLiAgVGhlIEFOQ1AgbWVzc2Fn ZXMgZm9yIHRvcG9sb2d5CiAgIGRpc2NvdmVyeSBhbmQgbGluZSBjb25maWd1cmF0aW9uIGNhcnJ5 IG9wYXF1ZSAiQWNjZXNzIGxvb3AKICAgQ2lyY3VpdC1JRCIgd2hpY2ggaGFzIG9ubHkgbG9jYWwg c2lnbmlmaWNhbmNlIG9uIHRoZSBEU0xBTXMuCgogICBUaGUgYWNjZXNzIGxvb3AgY2lyY3VpdCBp ZGVudGlmaWVyIGNhbiBiZSBjYXJyaWVkIGFzIGFuIEFTQ0lJIHN0cmluZwogICBpbiB0aGUgQU5D UCBtZXNzYWdlcy4gIFRoaXMgYWxsb3dzIEFOQ1AgdG8gYmUgZGVjb3VwbGVkIGZyb20gdGhlCiAg IHNwZWNpZmljcyBvZiB0aGUgdW5kZXJseWluZyBhY2Nlc3MgdGVjaG5vbG9neSBiZWluZyBjb250 cm9sbGVkLiAgT24KICAgdGhlIG90aGVyIGhhbmQsIHRoaXMgcmVxdWlyZXMgYSBOQVMgbWVjaGFu aXNtIGJ5IHdoaWNoIHN1Y2gKICAgaWRlbnRpZmllciBjYW4gYmUgY29ycmVsYXRlZCB0byB0aGUg Y29udGV4dCBvZiBhbiAiYWdncmVnYXRpb24KICAgbmV0d29yayIgZmFjaW5nIElQIGludGVyZmFj ZSAoY29ycmVzcG9uZGluZyB0byB0aGUgc3Vic2NyaWJlcikgb24gdGhlCiAgIE5BUy4gIFRoaXMg d291bGQgdHlwaWNhbGx5IHJlcXVpcmUgbG9jYWwgY29uZmlndXJhdGlvbiBvZiBzdWNoIElQCiAg IGludGVyZmFjZXMsIG9yIG9mIHRoZSB1bmRlcmx5aW5nIEFUTSBpbnRlcmZhY2VzLgoKNS42LiAg RXRoZXJuZXQtc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMKCiAgIE9uZSBwb3NzaWJsZSB3YXkgb2Yg YXBwcm9hY2hpbmcgdGhlIHVzZSBvZiBFdGhlcm5ldCB0ZWNobm9sb2d5IGluIHRoZQogICBhY2Nl c3MgYWdncmVnYXRpb24gbmV0d29yayBpcyB0byByZWNyZWF0ZSB0aGUgZXF1aXZhbGVudCBvZiBW aXJ0dWFsCiAgIFBhdGhzIChWUHMpIGFuZCBWaXJ0dWFsIENpcmN1aXRzIChWQ3MpIGJ5IHVzaW5n IHN0YWNrZWQgVmlydHVhbCBMQU4KICAgdGFncy4gIEFzIGFuIGV4YW1wbGUsIG9uZSBjb3VsZCB1 c2UgYW4gIm91dGVyIiBWTEFOIHRvIGNyZWF0ZSBhIGZvcm0KICAgb2YgInZpcnR1YWwgcGF0aCIg YmV0d2VlbiBhIGdpdmVuIERTTEFNIGFuZCBhIGdpdmVuIE5BUy4gIEFuZCB0aGVuCgoKCiBXYWRo d2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAg IFtQYWdlIDQ5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wg ICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgIHVzZSAiaW5uZXIiIFZMQU4gdGFncyB0 byBjcmVhdGUgYSBmb3JtIG9mICJ2aXJ0dWFsIGNpcmN1aXQiIG9uIGEgcGVyCiAgIERTTCBsaW5l IGJhc2lzLiAgSW4gdGhpcyBjYXNlLCBWTEFOIHRhZ3MgY29udmV5ZWQgaW4gdG9wb2xvZ3kKICAg ZGlzY292ZXJ5IGFuZCBsaW5lIGNvbmZpZ3VyYXRpb24gbWVzc2FnZXMgd2lsbCBhbGxvdyB0byB1 bmlxdWVseQogICBpZGVudGlmeSB0aGUgRFNMIGxpbmUgaW4gYSBzdHJhaWdodGZvcndhcmQgbWFu bmVyLCBhc3N1bWluZyB0aGUgVkxBTgogICB0YWdzIGFyZSBub3QgdHJhbnNsYXRlZCBpbiBzb21l IHdheSBieSB0aGUgYWdncmVnYXRpb24gbmV0d29yaywgYW5kCiAgIGFyZSB1bmlxdWUgYWNyb3Nz IHBoeXNpY2FsIHBvcnRzLgoKICAgSG93ZXZlciwgc29tZSBjYXJyaWVycyBkbyBub3Qgd2lzaCB0 byB1c2UgdGhpcyAiY29ubmVjdGlvbiBvcmllbnRlZCIKICAgYXBwcm9hY2guICBUaGVyZWZvcmUs IGFuIGFsdGVybmF0aXZlIG1vZGVsIGlzIHRvIGJyaWRnZSBzZXNzaW9ucyBmcm9tCiAgIG11bHRp cGxlIHN1YnNjcmliZXJzIGJlaGluZCBhIERTTEFNIHRvIGEgc2luZ2xlIFZMQU4gaW4gdGhlCiAg IGFnZ3JlZ2F0aW9uIG5ldHdvcmsuICBUaGlzIGlzIHRoZSBOOjEgbW9kZWwuICBJbiB0aGlzIG1v ZGVsLCBvciBpbgogICB0aGUgY2FzZSB3aGVyZSB1c2VyIHRyYWZmaWMgaXMgc2VudCB1bnRhZ2dl ZCwgdGhlIGFjY2VzcyBub2RlIG5lZWRzCiAgIHRvIGluc2VydCB0aGUgZXhhY3QgaWRlbnRpdHkg b2YgdGhlIERTTCBsaW5lIGluIHRoZSB0b3BvbG9neQogICBkaXNjb3ZlcnkgYW5kIGxpbmUgY29u ZmlndXJhdGlvbiBtZXNzYWdlcywgYW5kIHRoZW4gaHZlIGEgbWVjaGFuaXNtCiAgIGJ5IHdoaWNo IHRoaXMgY2FuIGJlIGNvcnJlbGF0ZWQgdG8gdGhlIGNvbnRleHQgb2YgYW4gImFnZ3JlZ2F0aW9u CiAgIG5ldHdvcmsiIGZhY2luZyBJUCBpbnRlcmZhY2UgKGZvciB0aGUgc3Vic2NyaWJlcikgb24g dGhlIE5BUy4gIFRoaXMKICAgY2FuIGVpdGhlciBiZSBiYXNlZCBvbiBsb2NhbCBjb25maWd1cmF0 aW9uIG9uIHRoZSBOQVMsIG9yIG9uIHRoZSBmYWN0CiAgIHRoYXQgc3VjaCBEU0xBTSAoYWNjZXNz IG5vZGUpIHR5cGljYWxseSBpbnNlcnRzIHRoZSAiQWNjZXNzIExvb3AKICAgQ2lyY3VpdCBJRCIg aW4gc3Vic2NyaWJlciBzaWduYWxpbmcgbWVzc2FnZXMgcmVsYXllZCB0byB0aGUgTkFTIChpLmUu CiAgIERIQ1Agb3IgUFBQb0UgZGlzY292ZXJ5IG1lc3NhZ2VzKS4KCiAgIFNlY3Rpb24gU2VjdGlv biA1LjQuMSBkZWZpbmVzICJBY2Nlc3MgTG9vcCBDaXJjdWl0IElEIi4KCgo2LiAgQXBwZW5kaXg6 IEhhbmRsaW5nIG9mIHByZS1SRkMgZGVwbG95bWVudHMgb2YgdGhlIEFOQ1AgIHByb3RvY29sCgog ICBUaGlzIGFwcGVuZGl4IGlzIG5vbiBub3JtYXRpdmUuCgogICBQcmlvciB0byBjb21wbGV0aW9u IG9mIHRoaXMgZG9jdW1lbnQsIHNldmVyYWwgcHJlLVJGQyB2ZXJzaW9ucyBvZiB0aGUKICAgcHJv dG9jb2wgd2VyZSBkb2N1bWVudGVkIGFuZCBpbXBsZW1lbnRlZC4gIFRoZXJlIHdlcmUgbnVtZXJv dXMgcHJlLQogICBzdGFuZGFyZCB2ZXJzaW9ucyBvZiB0aGUgcHJvdG9jb2wgYWxsIHVzaW5nIGEg dmVyc2lvbi9zdWItdmVyc2lvbgogICBmaWVsZHMgc2V0IHRvIDMuMS4KCiAgIEEgTkFTIGltcGxl bWVudGluZyB0aGUgQU5DUCBwcm90b2NvbCBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgbWF5 LAogICBvbiBhIHBlZXIgYmFzaXMsIHVzZSB0aGUgdmVyc2lvbiBhbmQgc3ViLXZlcnNpb24gZmll bGRzIHRvIGRldGVjdCBhCiAgIHByZS1SRkMgaW1wbGVtZW50YXRpb24gb2YgdGhlIHByb3RvY29s IGFuZCBjaG9vc2UgdG8gd29yayB3aXRoIHN1Y2gKICAgcHJlLVJGQyBwZWVycy4gIFRoZSB2ZXJz aW9uIGFuZCBzdWItdmVyc2lvbiBuZWdvdGlhdGlvbiBwaGFzZSBpcyBwYXJ0CiAgIG9mIHRoZSBh ZGphY2VuY3kgcHJvdG9jb2wgYW5kIGlzIHBlcmZvcm1lZCBiZWZvcmUgc3luY2hyb25pc2F0aW9u IGlzCiAgIGFjaGlldmVkLgoKCjcuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgdGhlIGZvbGxvd2luZyBhZGRpdGlvbnMgdG8gdGhlIEdTTVB2MyBNZXNzYWdl CiAgIFR5cGUgTmFtZSBTcGFjZSByZWdpc3RyeToKCgoKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNTBdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAg T2N0b2JlciAyMDA5CgoKICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgIHwgTWVzc2FnZSAgICAgIHwgTnVtYmVy IHwgU291cmNlICAgICAgICB8CiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICB8IFByb3Zpc2lvbmluZyB8IDkz ICAgICB8IFRoaXMgZG9jdW1lbnQgfAogICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGZv bGxvd2luZyBtb2RpZmljYXRpb24gdG8gdGhlIEdlbmVyYWwKICAgU3dpdGNoIE1hbmFnZW1lbnQg UHJvdG9jb2wgdmVyc2lvbiAzIChHU01QdjMpIFJlc3VsdCBUeXBlIE5hbWUgU3BhY2UKICAgcmVn aXN0cnk6CgogICAgICAgICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgfCBSZXN1bHQgVmFsdWUgfCBSZXN1bHQgVHlwZSBO YW1lICAgICAgIHwgUmVmZXJlbmNlICAgICB8CiAgICAgICAgICstLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICB8IDAgICAgICAg ICAgICB8IElnbm9yZSAoZnJvbSBSZXNlcnZlZCkgfCBUaGlzIGRvY3VtZW50IHwKICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r CgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGZvbGxvd2luZyBhZGRpdGlvbiB0byB0aGUg R1NNUHYzIE1lc3NhZ2UKICAgRnVuY3Rpb24gTmFtZSBTcGFjZSByZWdpc3RyeSBbZWRpdG9yJ3Mg bm90ZSBHTVNQdjMgZGlkIG5vdCBkZWZpbmUgYQogICBOYW1lIFNwYWNlIGZvciBGdW5jdGlvbiBl dmVuIGlmIFJGQzMyOTIgZGVmaW5lcyB2YWx1ZXMgZm9yIGZ1bmN0aW9uCiAgIGZpZWxkXToKCiAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tKwogICAgICAgICAgIHwgRnVuY3Rpb24gVmFsdWUgfCBGdW5jdGlvbiBOYW1lICAgfCBSZWZl cmVuY2UgICAgIHwKICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgfCAweDA5ICAgICAgICAgICB8IFJlbW90ZSBs b29wYmFjayB8IFRoaXMgZG9jdW1lbnQgfAogICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKCiAgIFRoaXMgZG9jdW1lbnQgcmVzZXJ2 ZXMgdGhlIHJhbmdlIDB4NTAwIHRvIDB4NWZmIG9mIEdTTVB2MyBGYWlsdXJlCiAgIFJlc3BvbnNl IE1lc3NhZ2UgTmFtZSBTcGFjZSByZWdpc3RyeSB0byBpbmRpY2F0ZSB0aGUgc3RhdHVzIG9mIHRo ZQogICBleGVjdXRlZCB0ZXN0IGZvciBPQU0gdXNlIGNhc2UgZGVzY3JpYmVkIGluIFNlY3Rpb24g NS40LjQuICBUaGUKICAgaW5pdGlhbCBlbnRyaWVzIGFyZSBhcyBmb2xsb3dzOgoKICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0rCiAgIHwgRmFpbHVyZSBSZXNwb25zZSAgICAgICAgfCBGYWlsdXJlIFJlc3BvbnNlIE1l c3NhZ2UgICB8IFJlZmVyZW5jZSAgfAogICB8IE1lc3NhZ2UgVmFsdWUgICAgICAgICAgIHwgTmFt ZSAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rCiAg IHwgMHg1MDAgICAgICAgICAgICAgICAgICAgfCBTcGVjaWZpZWQgYWNjZXNzIGxpbmUgZG9lcyB8 IFRoaXMgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgbm90IGV4aXN0ICAg ICAgICAgICAgICAgICAgfCBkb2N1bWVudCAgIHwKICAgfCAweDUwMSAgICAgICAgICAgICAgICAg ICB8IExvb3BiYWNrIHRlc3QgdGltZWQgb3V0ICAgIHwgVGhpcyAgICAgICB8CiAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGRvY3VtZW50 ICAgfAogICB8IDB4NTAyICAgICAgICAgICAgICAgICAgIHwgUmVzZXJ2ZWQgICAgICAgICAgICAg ICAgICAgfCBUaGlzICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgZG9jdW1lbnQgICB8CiAgIHwgMHg1MDMgICAgICAgICAg ICAgICAgICAgfCBEU0wgbGluZSBzdGF0dXMgc2hvd3RpbWUgICB8IFRoaXMgICAgICAgfAogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBk b2N1bWVudCAgIHwKICAgfCAweDA1MDQgICAgICAgICAgICAgICAgICB8IERTTCBsaW5lIHN0YXR1 cyBpZGxlICAgICAgIHwgVGhpcyAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGRvY3VtZW50ICAgfAogICB8IDB4MDUwNSAg ICAgICAgICAgICAgICAgIHwgRFNMIGxpbmUgc3RhdHVzIHNpbGVudCAgICAgfCBUaGlzICAgICAg IHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgZG9jdW1lbnQgICB8CgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFw cmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDUxXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoK CiAgIHwgMHgwNTA2ICAgICAgICAgICAgICAgICAgfCBEU0wgbGluZSBzdGF0dXMgdHJhaW5pbmcg ICB8IFRoaXMgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCBkb2N1bWVudCAgIHwKICAgfCAweDUwNyAgICAgICAgICAgICAg ICAgICB8IERTTCBsaW5lIGludGVncml0eSBlcnJvciAgIHwgVGhpcyAgICAgICB8CiAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGRvY3Vt ZW50ICAgfAogICB8IDB4MDUwOCAgICAgICAgICAgICAgICAgIHwgRFNMQU0gcmVzb3VyY2Ugbm90 ICAgICAgICAgfCBUaGlzICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8IGF2 YWlsYWJsZSAgICAgICAgICAgICAgICAgIHwgZG9jdW1lbnQgICB8CiAgIHwgMHg1MDkgICAgICAg ICAgICAgICAgICAgfCBJbnZhbGlkIHRlc3QgcGFyYW1ldGVyICAgICB8IFRoaXMgICAgICAgfAog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCBkb2N1bWVudCAgIHwKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMg YSBuZXcgQU5DUCBWZXJzaW9uIFNwYWNlIHJlZ2lzdHJ5LiAgVGhlIGluaXRpYWwKICAgZW50cnkg aXMgYXMgZm9sbG93czoKCiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKwogICAgICAgIHwgQU5DUCBWZXJzaW9uIFZhbHVlIHwg QU5DUCBWZXJzaW9uIE5hbWUgfCBSZWZlcmVuY2UgICAgIHwKICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgfCAz ICAgICAgICAgICAgICAgICAgfCBBTkNQIFZlcnNpb24gICAgICB8IFRoaXMgZG9jdW1lbnQgfAog ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSsKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBBTkNQIFN1Yi1WZXJzaW9u IFNwYWNlIHJlZ2lzdHJ5LiAgVGhlCiAgIGluaXRpYWwgZW50cnkgaXMgYXMgZm9sbG93czoKCiAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLSsKICAgIHwgQU5DUCBTdWItVmVyc2lvbiBWYWx1ZSB8IEFOQ1AgU3ViLVZlcnNp b24gTmFtZSB8IFJlZmVyZW5jZSAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICB8IDEgWypdICAgICAg ICAgICAgICAgICAgfCBBTkNQIFN1Yi1WZXJzaW9uICAgICAgfCBUaGlzIGRvY3VtZW50IHwKICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKwoKICAgWypdIEVkaXRvcidzIG5vdGU6IHN1Yi12ZXJzaW9uIG5lZWRzIHRvIGJl IGNoYW5nZWQgZnJvbSAxIHRvIDIgdXBvbgogICBwdWJsaWNhdGlvbgoKICAgVGhpcyBkb2N1bWVu dCBkZWZpbmVzIGEgbmV3IEFOQ1AgVGVjaCBUeXBlIE5hbWUgU3BhY2UgcmVnaXN0cnkuICBUaGUK ICAgaW5pdGlhbCBlbnRyaWVzIGFyZSBhcyBmb2xsb3dzOgoKICAgICArLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCBU ZWNoIFR5cGUgVmFsdWUgfCBUZWNoIFR5cGUgTmFtZSAgICAgICAgICAgICB8IFJlZmVyZW5jZSAg ICAgfAogICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsKICAgICB8IDB4MDAgICAgICAgICAgICB8IEV4dGVuc2lvbiBibG9j ayBub3QgaW4gdXNlIHwgVGhpcyBkb2N1bWVudCB8CiAgICAgfCAweDAxICAgICAgICAgICAgfCBQ T04gICAgICAgICAgICAgICAgICAgICAgICB8IFRoaXMgZG9jdW1lbnQgfAogICAgIHwgMHgwNSAg ICAgICAgICAgIHwgRFNMICAgICAgICAgICAgICAgICAgICAgICAgfCBUaGlzIGRvY3VtZW50IHwK ICAgICB8IDB4MDYgLSAweEZFICAgICB8IFJlc2VydmVkICAgICAgICAgICAgICAgICAgIHwgVGhp cyBkb2N1bWVudCB8CiAgICAgfCAweEZGICAgICAgICAgICAgfCBCYXNlIFNwZWNpZmljYXRpb24g VXNlICAgICB8IFRoaXMgZG9jdW1lbnQgfAogICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKCiAgIFRoaXMgZG9jdW1lbnQg cmVzZXJ2ZXMgdGhlIHJhbmdlIDB4NTAwIHRvIDB4NWZmIG9mIEdTTVB2MyBGYWlsdXJlCiAgIFJl c3BvbnNlIE1lc3NhZ2UgTmFtZSBTcGFjZSByZWdpc3RyeS4KCiAgIFRoaXMgZG9jdW1lbnQgYWRk cyB0aGUgZm9sbG93aW5nIHZhbHVlcyB0byB0aGUgR1NNUHYzIEZhaWx1cmUKCgoKIFdhZGh3YSwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMTAgICAgICAgICAgICAgICAgW1Bh Z2UgNTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgYW5jcCBwcm90b2NvbCAgICAg ICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgUmVzcG9uc2UgTWVzc2FnZSBOYW1lIFNwYWNl IHJlZ2lzdHJ5OgoKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgIHwgQ29tbWFuZCBDb2RlIERpcmVjdGl2ZSBO YW1lICAgICAgICAgICB8IENvbW1hbmQgQ29kZSAgfCBSZWZlcmVuY2UgfAogICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBWYWx1ZSAgICAgICAgIHwgICAgICAgICAg IHwKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0rCiAgIHwgUmVxdWVzdCBtZXNzYWdlIHR5cGUgbm90IGltcGxlbWVu dGVkICB8IDB4ODEgICAgICAgICAgfCBUaGlzICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgZG9jdW1lbnQgIHwKICAgfCBU cmFuc2FjdGlvbiBpZGVudGlmaWVyIG91dCBvZiAgICAgICAgIHwgMHg4MiAgICAgICAgICB8IFRo aXMgICAgICB8CiAgIHwgc2VxdWVuY2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgfCBkb2N1bWVudCAgfAogICB8IE1hbGZvcm1lZCBtZXNzYWdlICAgICAgICAg ICAgICAgICAgICAgfCAweDgzICAgICAgICAgIHwgVGhpcyAgICAgIHwKICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8IGRvY3VtZW50ICB8 CiAgIHwgVExWIG9yIHZhbHVlIG5vdCBzdXBwb3J0ZWQgYnkgICAgICAgICB8IDB4ODQgICAgICAg ICAgfCBUaGlzICAgICAgfAogICB8IG5lZ290aWF0ZWQgY2FwYWJpbGl0eSBzZXQgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwgZG9jdW1lbnQgIHwKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCgogICBUaGlz IGRvY3VtZW50IHJlc2VydmVzIHRoZSB2YWx1ZXMgMHgxMDAgdG8gMHgxZmYgKDI1NiB0byA1MTEp IHdpdGhpbgogICB0aGUgR1NNUHYzIEZhaWx1cmUgUmVzcG9uc2UgTWVzc2FnZSBOYW1lIFNwYWNl IHJlZ2lzdHJ5IGZvciB1c2UgYnkKICAgZXh0ZW5zaW9ucyB0byB0aGUgQWNjZXNzIE5vZGUgQ29u dHJvbCBQcm90b2NvbCAoQU5DUCkuCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgQU5D UCBDb21tYW5kIENvZGUgcmVnaXN0cnkuICBUaGUgaW5pdGlhbAogICBlbnRyaWVzIGFyZSBhcyBm b2xsb3dzOgoKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKICAgfCBDb21tYW5kIENvZGUgRGlyZWN0aXZlIE5hbWUg fCBDb21tYW5kIENvZGUgVmFsdWUgfCBSZWZlcmVuY2UgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKICAg fCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgfCAweDAwICAgICAgICAgICAgICAgfCBUaGlz IGRvY3VtZW50IHwKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5l dyBBTkNQIFRMViBUeXBlIHJlZ2lzdHJ5LiAgVGhlIGluaXRpYWwKICAgZW50cmllcyBhcmUgYXMg Zm9sbG93czoKCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKwogICB8IFRMViBOYW1lICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IFR5cGUgQ29kZSAgICB8IFJlZmVyZW5jZSAgIHwKICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0r CiAgIHwgQWNjZXNzLUxvb3AtQ2lyY3VpdC1JRCAgICAgICAgICAgICAgIHwgMHgwMSAgICAgICAg IHwgVGhpcyAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICB8IGRvY3VtZW50ICAgIHwKICAgfCBBY2Nlc3MtTG9vcC1SZW1vdGUt SWQgICAgICAgICAgICAgICAgfCAweDAyICAgICAgICAgfCBUaGlzICAgICAgICB8CiAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgZG9jdW1l bnQgICAgfAogICB8IEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlELUFTQ0lJICB8IDB4MDMg ICAgICAgICB8IFRoaXMgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgfCBkb2N1bWVudCAgICB8CiAgIHwgRFNMIExpbmUgQXR0 cmlidXRlcyAgICAgICAgICAgICAgICAgIHwgMHgwNCAgICAgICAgIHwgVGhpcyAgICAgICAgfAog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8 IGRvY3VtZW50ICAgIHwKICAgfCBTZXJ2aWNlLVByb2ZpbGUtTmFtZSAgICAgICAgICAgICAgICAg fCAweDA1ICAgICAgICAgfCBUaGlzICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgZG9jdW1lbnQgICAgfAogICB8IEFjY2Vz cy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlELUJpbmFyeSB8IDB4MDYgICAgICAgICB8IFRoaXMgICAg ICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgfCBkb2N1bWVudCAgICB8CgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA1M10KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIw MDkKCgogICB8IE9BTS1Mb29wYmFjay1UZXN0LVBhcmFtZXRlcnMgICAgICAgICB8IDB4MDcgICAg ICAgICB8IFRoaXMgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgfCBkb2N1bWVudCAgICB8CiAgIHwgT3BhcXVlLURhdGEgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgMHgwOCAgICAgICAgIHwgVGhpcyAgICAgICAgfAogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IGRv Y3VtZW50ICAgIHwKICAgfCBPQU0tTG9vcGJhY2stVGVzdC1SZXNwb25zZS1TdHJpbmcgICAgfCAw eDA5ICAgICAgICAgfCBUaGlzICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgZG9jdW1lbnQgICAgfAogICB8IFJlc2VydmVk ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDB4MGEtMHgwZiAgICB8IFRoaXMgICAgICAg IHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgfCBkb2N1bWVudCAgICB8CiAgIHwgVGFyZ2V0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgMHgxMDAwIC0gICAgIHwgVGhpcyAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IDBYMTAyMCAgICAgICB8IGRvY3VtZW50ICAgIHwKICAgfCBD b21tYW5kICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAweDExICAgICAgICAgfCBUaGlz ICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgIHwgZG9jdW1lbnQgICAgfAogICB8IFN0YXR1cy1pbmZvICAgICAgICAgICAgICAg ICAgICAgICAgICB8IDB4MDEwNiAgICAgICB8IFRoaXMgICAgICAgIHwKICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCBkb2N1bWVudCAgICB8 CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tKwoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEFOQ1AgQ2Fw YWJpbGl0eSByZWdpc3RyeS4gIFRoZSBpbml0aWFsCiAgIGVudHJpZXMgYXJlIGFzIGZvbGxvd3M6 CgogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsKICAgfCBDYXBhYmlsaXR5IFR5cGUgTmFtZSAgICAgICB8IENhcGFi aWxpdHkgVHlwZSBDb2RlIHwgUmVmZXJlbmNlICAgICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKwogICB8IER5 bmFtaWMtVG9wb2xvZ3ktRGlzY292ZXJ5IHwgMHgwMSAgICAgICAgICAgICAgICAgfCBUaGlzIGRv Y3VtZW50IHwKICAgfCBMaW5lLUNvbmZpZ3VyYXRpb24gICAgICAgICB8IDB4MDIgICAgICAgICAg ICAgICAgIHwgVGhpcyBkb2N1bWVudCB8CiAgIHwgVHJhbnNhY3Rpb25hbC1NdWx0aWNhc3QgICAg fCAweDAzICAgICAgICAgICAgICAgICB8IFRoaXMgZG9jdW1lbnQgfAogICB8IE9BTSAgICAgICAg ICAgICAgICAgICAgICAgIHwgMHgwNCAgICAgICAgICAgICAgICAgfCBUaGlzIGRvY3VtZW50IHwK ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgQU5DUCBzdWIt VExWIFR5cGUgcmVnaXN0cnkuICBUaGUgaW5pdGlhbAogICBlbnRyaWVzIGFyZSBhcyBmb2xsb3dz OgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogV2FkaHdhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBB cHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA1NF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICBhbmNwIHByb3RvY29sICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkK CgogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0rLS0tLS0tLS0tLS0tLSsKICAgfCBzdWItVExWIE5hbWUgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCBUeXBlICAgfCBSZWZlcmVuY2UgICB8CiAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ29kZSAgIHwgICAgICAgICAgICAgfAogICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0t LS0tLS0tLSsKICAgfCBBY3R1YWwtTmV0LURhdGEtVXBzdHJlYW0gICAgICAgICAgICAgICAgICAg fCAweDgxICAgfCBUaGlzICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgIHwgZG9jdW1lbnQgICAgfAogICB8IEFjdHVhbC1OZXQt RGF0YS1SYXRlLURvd25zdHJlYW0gICAgICAgICAgICB8IDB4ODIgICB8IFRoaXMgICAgICAgIHwK ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg fCBkb2N1bWVudCAgICB8CiAgIHwgTWluaW11bS1OZXQtRGF0YS1SYXRlLVVwc3RyZWFtICAgICAg ICAgICAgIHwgMHg4MyAgIHwgVGhpcyAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8IGRvY3VtZW50ICAgIHwKICAgfCBNaW5p bXVtLU5ldC1EYXRhLVJhdGUtRG93bnN0cmVhbSAgICAgICAgICAgfCAweDg0ICAgfCBUaGlzICAg ICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgIHwgZG9jdW1lbnQgICAgfAogICB8IEF0dGFpbmFibGUtTmV0LURhdGEtUmF0ZS1VcHN0 cmVhbSAgICAgICAgICB8IDB4ODUgICB8IFRoaXMgICAgICAgIHwKICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCBkb2N1bWVudCAgICB8CiAg IHwgQXR0YWluYWJsZS1OZXQtRGF0YS1SYXRlLURvd25zdHJlYW0gICAgICAgIHwgMHg4NiAgIHwg VGhpcyAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICB8IGRvY3VtZW50ICAgIHwKICAgfCBNYXhpbXVtLU5ldC1EYXRhLVJhdGUt VXBzdHJlYW0gICAgICAgICAgICAgfCAweDg3ICAgfCBUaGlzICAgICAgICB8CiAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgZG9jdW1lbnQg ICAgfAogICB8IE1heGltdW0tTmV0LURhdGEtUmF0ZS1Eb3duc3RyZWFtICAgICAgICAgICB8IDB4 ODggICB8IFRoaXMgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgfCBkb2N1bWVudCAgICB8CiAgIHwgTWluaW11bS1OZXQtTG93 LVBvd2VyLURhdGEtUmF0ZS1VcHN0cmVhbSAgIHwgMHg4OSAgIHwgVGhpcyAgICAgICAgfAogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8IGRv Y3VtZW50ICAgIHwKICAgfCBNaW5pbXVtLU5ldC1Mb3ctUG93ZXItRGF0YS1SYXRlLURvd25zdHJl YW0gfCAweDhBICAgfCBUaGlzICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgZG9jdW1lbnQgICAgfAogICB8IE1heGltdW0t SW50ZXJsZWF2aW5nLURlbGF5LVVwc3RyZWFtICAgICAgICB8IDB4OEIgICB8IFRoaXMgICAgICAg IHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgfCBkb2N1bWVudCAgICB8CiAgIHwgQWN0dWFsLUludGVybGVhdmluZy1EZWxheS1VcHN0cmVh bSAgICAgICAgIHwgMHg4QyAgIHwgVGhpcyAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8IGRvY3VtZW50ICAgIHwKICAgfCBN YXhpbXVtLUludGVybGVhdmluZy1EZWxheS1Eb3duc3RyZWFtICAgICAgfCAweDhEICAgfCBUaGlz ICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgIHwgZG9jdW1lbnQgICAgfAogICB8IEFjdHVhbC1JbnRlcmxlYXZpbmctRGVsYXkt RG93bnN0cmVhbSAgICAgICB8IDB4OEUgICB8IFRoaXMgICAgICAgIHwKICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCBkb2N1bWVudCAgICB8 CiAgIHwgRFNMIGxpbmUgc3RhdGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgMHg4RiAg IHwgVGhpcyAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICB8IGRvY3VtZW50ICAgIHwKICAgfCBBY2Nlc3MgTG9vcCBFbmNhcHN1 bGF0aW9uICAgICAgICAgICAgICAgICAgfCAweDkwICAgfCBUaGlzICAgICAgICB8CiAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgZG9jdW1l bnQgICAgfAogICB8IERTTC1UeXBlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 IDB4OTEgICB8IFRoaXMgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgfCBkb2N1bWVudCAgICB8CiAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tKwoK CjguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgU2VjdXJpdHkgb2YgdGhlIEFOQ1AgcHJv dG9jb2wgaXMgZGlzY3Vzc2VkIGluIFtBTkNQLVNFQ10KCgoKCgoKCiBXYWRod2EsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDU1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAg ICAgIE9jdG9iZXIgMjAwOQoKCjkuICBBY2tub3dsZWRnZW1lbnRzCgogICBUaGUgYXV0aG9ycyB3 b3VsZCBsaWtlIHRvIHRoYW5rIGV2ZXJ5b25lIHRoYXQgaGFzIHByb3ZpZGVkIGNvbW1lbnRzCiAg IG9yIGlucHV0cyB0byB0aGlzIGRvY3VtZW50LiAgSW4gcGFydGljdWxhciwgdGhlIGF1dGhvcnMg YWNrbm93bGVkZ2UKICAgdGhlIGlucHV0cyBwcm92aWRlZCBieSBXb2pjaWVjaCBEZWMsIFBldGVy IEFyYmVyZywgSm9zZWYgRnJvZWhsZXIsCiAgIERlcmVrIEhhcmtuZXNzLCBLaW0gSHlsZGdhYXJk LCBTYW5keSBOZywgUm9iZXJ0IFBlc2NoaSwgTWljaGVsCiAgIFBsYXRuaWMgYW5kIFRvbSBUYXls b3IuCgoKMTAuICBSZWZlcmVuY2VzCgoxMC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtS RkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwg TWFyY2ggMTk5Ny4KCiAgIFtSRkMzMDQ2XSAgUGF0cmljaywgTS4sICJESENQIFJlbGF5IEFnZW50 IEluZm9ybWF0aW9uIE9wdGlvbiIsCiAgICAgICAgICAgICAgSmFudWFyeSAyMDAxLgoKICAgW1JG QzMyOTJdICBEb3JpYSwgQS4gYW5kIGV0IGFsbCwgIkdlbmVyYWwgU3dpdGNoIE1hbmFnZW1lbnQg UHJvdG9jb2wKICAgICAgICAgICAgICAoR1NNUCkgVjMiLCBKdW5lIDIwMDIuCgogICBbUkZDMzI5 M10gIFdvcnN0ZXIsIFQuLCBEb3JpYSwgQS4sIGFuZCBhbmQgSi4gQnVlcmtsZSwgIkdlbmVyYWwK ICAgICAgICAgICAgICBTd2l0Y2ggTWFuYWdlbWVudCBQcm90b2NvbCAoR1NNUCkgUGFja2V0IEVu Y2Fwc3VsYXRpb25zCiAgICAgICAgICAgICAgZm9yIEFzeW5jaHJvbm91cyBUcmFuc2ZlciBNb2Rl IChBVE0pLCBFdGhlcm5ldCBhbmQKICAgICAgICAgICAgICBUcmFuc21pc3Npb24gQ29udHJvbCBQ cm90b2NvbCAoVENQKSIsIEp1bmUgMjAwMi4KCjEwLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz CgogICBbQU5DUC1GUkFNRVdPUktdCiAgICAgICAgICAgICAgT29naGUsIFMuLCBWb2lndCwgTi4s IFBsYXRuaWMsIE0uLCBIYWFnLCBULiwgYW5kIFMuCiAgICAgICAgICAgICAgV2FkaHdhLCAiRnJh bWV3b3JrIGFuZCBSZXF1aXJlbWVudHMgZm9yIGFuIEFjY2VzcyBOb2RlCiAgICAgICAgICAgICAg Q29udHJvbCBNZWNoYW5pc20gaW4gQnJvYWRiYW5kIE11bHRpLVNlcnZpY2UgTmV0d29ya3MiLAog ICAgICAgICAgICAgIGRyYWZ0LWlldGYtYW5jcC1mcmFtZXdvcmstMTIudHh0LCB3b3JrIGluIHBy b2dyZXNzLAogICAgICAgICAgICAgIE9jdG9iZXIgMjAwOS4KCiAgIFtBTkNQLVNFQ10KICAgICAg ICAgICAgICBNb3VzdGFmYSwgSC4sIFRzY2hvZmVuaWcsIFQuLCBhbmQgUy4gRGUgQ25vZGRlciwg IlNlY3VyaXR5CiAgICAgICAgICAgICAgVGhyZWF0cyBhbmQgU2VjdXJpdHkgUmVxdWlyZW1lbnRz IGZvciB0aGUgQWNjZXNzIE5vZGUKICAgICAgICAgICAgICBDb250cm9sIFByb3RvY29sIChBTkNQ KSIsCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1hbmNwLXNlY3VyaXR5LXRocmVhdHMtMDgudHh0 IHdvcmsgaW4gcHJvZ3Jlc3MsCiAgICAgICAgICAgICAgSnVseSAyMDA5LgoKICAgW0cuOTg4LjFd ICAiSVRVLVQgcmVjb21tZW5kYXRpb24gRy45OTguMSwgQVRNLWJhc2VkIG11bHRpLXBhaXIKICAg ICAgICAgICAgICBib25kaW5nIiwgMjAwNS4KCiAgIFtHLjk4OC4yXSAgIklUVS1UIHJlY29tbWVu ZGF0aW9uIEcuOTk4LjIsIEV0aGVybmV0LWJhc2VkIG11bHRpLXBhaXIKICAgICAgICAgICAgICBi b25kaW5nLCIsIDIwMDUuCgoKCiBXYWRod2EsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmls IDI1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDU2XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgIGFuY3AgcHJvdG9jb2wgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAg IFtUUi0wNThdICAgRWxpYXMsIE0uIGFuZCBTLiBPb2doZSwgIkRTTCBGb3J1bSBUUi0wNTgsIE11 bHRpLVNlcnZpY2UKICAgICAgICAgICAgICBBcmNoaXRlY3R1cmUgJiBGcmFtZXdvcmsgUmVxdWly ZW1lbnRzIiwgU2VwdGVtYmVyIDIwMDMuCgogICBbVFItMDU5XSAgIEFuc2NodXR6LCBULiwgIkRT TCBGb3J1bSBUUi0wNTksIERTTCBFdm9sdXRpb24gLQogICAgICAgICAgICAgIEFyY2hpdGVjdHVy ZSBSZXF1aXJlbWVudHMgZm9yIHRoZSBTdXBwb3J0IG9mIFFvUy1FbmFibGVkCiAgICAgICAgICAg ICAgSVAgU2VydmljZXMiLCBTZXB0ZW1iZXIgMjAwMy4KCiAgIFtUUi0wOTJdICAgIkRTTCBGb3J1 bSBUUi0wOTIsIEJyb2FkYmFuZCBSZW1vdGUgYWNjZXNzIHNlcnZlcgogICAgICAgICAgICAgIHJl cXVpcmVtZW50cyBkb2N1bWVudCIsIDIwMDUuCgogICBbVFItMTAxXSAgIENvaGVuIGV0IGFsLCAi QXJjaGl0ZWN0dXJlICYgVHJhbnNwb3J0OiAiTWlncmF0aW9uIHRvCiAgICAgICAgICAgICAgRXRo ZXJuZXQgQmFzZWQgRFNMIEFnZ3JlZ2F0aW9uIiwgRFNMIEZvcnVtIFRSLTEwMSIsIDIwMDUuCgoK QXV0aG9ycycgQWRkcmVzc2VzCgogICBTYW5qYXkgV2FkaHdhCiAgIEp1bmlwZXIgTmV0d29ya3MK ICAgMTAgVGVjaG5vbG9neSBQYXJrIERyaXZlCiAgIFdlc3Rmb3JkLCBNQSAgMDE4ODYKICAgVVNB CgogICBQaG9uZToKICAgRmF4OgogICBFbWFpbDogc3dhZGh3YUBqdW5pcGVyLm5ldAoKCiAgIEpl cm9tZSBNb2lzYW5kCiAgIEp1bmlwZXIgTmV0d29ya3MKICAgMTAgVGVjaG5vbG9neSBQYXJrIERy aXZlCiAgIFdlc3Rmb3JkLCBNQSAgMDE4ODYKICAgVVNBCgogICBQaG9uZToKICAgRmF4OgogICBF bWFpbDogam1vaXNhbmRAanVuaXBlci5uZXQKCgogICBTd2FtaSBTdWJyYW1hbmlhbgogICBKdW5p cGVyIE5ldHdvcmtzCiAgIDEwIFRlY2hub2xvZ3kgUGFyayBEcml2ZQogICBXZXN0Zm9yZCwgTUEg IDAxODg2CiAgIFVTQQoKICAgUGhvbmU6CiAgIEZheDoKICAgRW1haWw6IHNzdWJyYW1hbmlhbkBq dW5pcGVyLm5ldAoKCgoKIFdhZGh3YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUs IDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNTddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgYW5jcCBwcm90b2NvbCAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgVGhv bWFzIEhhYWcKICAgVC1zeXN0ZW1zCgoKICAgUGhvbmU6CiAgIEZheDoKICAgRW1haWw6IHRob21h cy5oYWFnQHQtc3lzdGVtcy5jb20KCgogICBOb3JiZXIgVm9pZ3QKICAgU2llbWVucwoKCiAgIFBo b25lOgogICBGYXg6CiAgIEVtYWlsOiBub3JiZXJ0LnZvaWd0QHNpZW1lbnMuY29tCgoKICAgUm9i ZXJ0YSBNYWdsaW9uZQogICBUZWxlY29tIEl0YWxpYQogICB2aWEgUmVpc3MgUm9tb2xpIDI3NAog ICBUb3Jpbm8KICAgSXRhbHkKCiAgIFBob25lOgogICBFbWFpbDogcm9iZXJ0YS5tYWdsaW9uZUB0 ZWxlY29taXRhbGlhLml0CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogV2FkaHdhLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA1OF0K DAoK --_004_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_282BBE8A501E1F4DA9C775F964BB21FE3E670E8000GRFMBX704BA02_-- From tom111.taylor@bell.net Tue Oct 20 06:48:58 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5F93A69A7 for ; Tue, 20 Oct 2009 06:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXlhzxmp2Anf for ; Tue, 20 Oct 2009 06:48:58 -0700 (PDT) Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by core3.amsl.com (Postfix) with ESMTP id F057E28C0DB for ; Tue, 20 Oct 2009 06:48:57 -0700 (PDT) Received: from BLU0-SMTP11 ([65.55.111.72]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 06:49:05 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP11.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 06:49:04 -0700 Date: Tue, 20 Oct 2009 09:49:03 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 13:49:04.0533 (UTC) FILETIME=[16539C50:01CA518C] Subject: [ANCP] Range of values of the Code field X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 13:48:58 -0000 The IANA registry for the GSMPv3 failure codes currently implies that the range of values is restricted to 8 bits. However, we have defined the field to occupy 12 bits. A simple solution is to add the specification that the range of values from 256 to 4095 is reserved for IETF use. Tom From roberta.maglione@telecomitalia.it Wed Oct 21 02:17:42 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1096E3A695C for ; Wed, 21 Oct 2009 02:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.071 X-Spam-Level: ** X-Spam-Status: No, score=2.071 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT+F7td2uLcW for ; Wed, 21 Oct 2009 02:17:41 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id D8AA93A69F7 for ; Wed, 21 Oct 2009 02:17:40 -0700 (PDT) Received: from grfhub706ba020.griffon.local (10.188.101.119) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 21 Oct 2009 11:17:46 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub706ba020.griffon.local ([10.188.101.119]) with mapi; Wed, 21 Oct 2009 11:17:46 +0200 From: Maglione Roberta To: Tom Taylor Date: Wed, 21 Oct 2009 11:17:46 +0200 Thread-Topic: [ANCP] Range of values of the Code field Thread-Index: AcpRjCJRN6l4YpGkQ4iCiFQa/C73sgAovimQ Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E670E800E@GRFMBX704BA020.griffon.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Range of values of the Code field X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 09:17:42 -0000 Hi Tom, in my opinion this is a good suggestion, if nobody has any issue wi= th this proposal I can add it in the new version of the ancp protocol draft= . Regards, Roberta -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Tom= Taylor Sent: Tuesday, October 20, 2009 3:49 PM To: ancp@ietf.org Subject: [ANCP] Range of values of the Code field The IANA registry for the GSMPv3 failure codes currently implies that the r= ange of values is restricted to 8 bits. However, we have defined the field to oc= cupy 12 bits. A simple solution is to add the specification that the range of va= lues from 256 to 4095 is reserved for IETF use. Tom _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From root@core3.amsl.com Thu Oct 22 05:45:01 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C34893A68E5; Thu, 22 Oct 2009 05:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091022124501.C34893A68E5@core3.amsl.com> Date: Thu, 22 Oct 2009 05:45:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-07.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 12:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-07.txt Pages : 58 Date : 2009-10-22 This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The resulting protocol with the proposed extensions to GSMPv3 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [ANCP-FRAMEWORK]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-protocol-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22053358.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Oct 27 09:45:01 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8078F3A69D1; Tue, 27 Oct 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091027164501.8078F3A69D1@core3.amsl.com> Date: Tue, 27 Oct 2009 09:45:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Additional Multicast Control Extensions for ANCP Author(s) : F. Le Faucheur, R. Maglione, T. Taylor Filename : draft-ietf-ancp-mc-extensions-01.txt Pages : 91 Date : 2009-10-27 This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document. Those use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation. These capabilities may be combined according to the rules given in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-mc-extensions-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-mc-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-27094015.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Tue Oct 27 10:01:30 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C966F3A6A57 for ; Tue, 27 Oct 2009 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj6yRuPoYuVG for ; Tue, 27 Oct 2009 10:01:30 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by core3.amsl.com (Postfix) with ESMTP id 006993A6A03 for ; Tue, 27 Oct 2009 10:01:29 -0700 (PDT) Received: from BLU0-SMTP57 ([65.55.111.73]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:01:44 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP57.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:01:44 -0700 Date: Tue, 27 Oct 2009 13:01:41 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 17:01:44.0611 (UTC) FILETIME=[298FC730:01CA5727] Subject: [ANCP] [Fwd: I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt] X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:01:30 -0000 This was a major rewrite. One part is evidenced by the abstract -- the modification of the capabilities. The Multicast Status message was removed and put into the base protocol as the Generic response message. We refined the control of admission control at the AN for different classes of stream. I can provide a detailed list of changes, but this will take a little while. Francois had a hand in getting the main ideas into shape, but due to circumstances on my side he didn't have a chance to read and approve the final version of the draft. Roberta is not currently accessible. So I take responsibility for any deficiencies and stand ready to correct them as directed by the WG. Tom Taylor -------- Original Message -------- Subject: [ANCP] I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt Date: Tue, 27 Oct 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: ancp@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Additional Multicast Control Extensions for ANCP Author(s) : F. Le Faucheur, R. Maglione, T. Taylor Filename : draft-ietf-ancp-mc-extensions-01.txt Pages : 91 Date : 2009-10-27 This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document. Those use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation. These capabilities may be combined according to the rules given in this specification. From HaagT@telekom.de Wed Oct 28 07:52:28 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37D628B56A for ; Wed, 28 Oct 2009 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSe43zzgjvz6 for ; Wed, 28 Oct 2009 07:52:16 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 41B133A686A for ; Wed, 28 Oct 2009 07:52:11 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 28 Oct 2009 15:52:17 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 15:52:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA57DE.3DE7582C" Date: Wed, 28 Oct 2009 15:52:11 +0100 Message-ID: <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UA== References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local> From: To: , , , , , , , , , X-OriginalArrivalTime: 28 Oct 2009 14:52:17.0619 (UTC) FILETIME=[3E7C9A30:01CA57DE] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:52:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57DE.3DE7582C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA57DE.3DE7582C" ------_=_NextPart_002_01CA57DE.3DE7582C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding versioning, = tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. >From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 So we had consensus not to remove and keep partion ID. But I didn't find = it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there = any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting keeping = partition ID. =20 Regards =20 Thomas .=20 =20 _____ =20 Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end of = section 2:=20 "At the time of writing of this specification some implementations of = the ANCP protocol, based on pre-standards drafts are already available. = All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in section = 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or = if you have additional comments please let me know. =20 Best Regards, Roberta =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the time of = publishing as an RFC. An instruction to execute such a change should be = placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an appropriate = section, possibly Section 2 or Section 5, to convey in-brief the = historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version negotiation = mechanisms could be highlighted, indicating that it provides a way to = distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 >From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down ( = = http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That = said, from an operational perspective a reasonable case for such a = version change has made based and presented in = = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm.=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and = have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending = the protocol spec to cover issues around protocol version negotiation or = remediation of incompatibilities of draft implementations. As such no = such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non = =E8 necessario.=20 ------_=_NextPart_002_01CA57DE.3DE7582C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP Versioning - next steps
Hi Roberta, all,
 
thanks for providing the updated protocol=20 draft.
 
So far I recognized that the update covers = issues regarding=20 versioning, tech Type for GPON and Range of values of the code=20 field.
 
But I notice on page 17 of version 07 that the = whole=20 section of partition ID including definition is = deleted.
From my understanding (and as result from = the minutes)=20 it was agreed during 75th IETF meeting to keep the partition=20 ID.
 
Extract from 75th IETF minutes: =
 
(1)=20 Partition-id
    ------------
Sanjay: concerned = that=20 removing the partition-id reduces extensibility.
Thomas Haag: need = multiple=20 partition-ids because one might need to distinguish
between BRASs = when=20 expanding the network.
Woj: send e-mail. Thomas: already did. Makes = for=20 operational problems
if partition-id not available.
No one felt = strongly=20 -- will keep "as is".
 
So we had consensus not to remove and keep = partion ID.=20 But I didn't find it in the whole document any more.
Based=20 on that agreements I wonder why this issue is deleted. Are there any reasons for doing=20 this?
 
So I recommend update the protocol draft before = upcoming=20 meeting keeping partition ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Gesendet: Montag, = 19.=20 Oktober 2009 16:16
An: 'Wojciech Dec (wdec)'; ancp@ietf.org; = Haag,=20 Thomas; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; BOCCI Matthew; = 'tom111.taylor@bell.net'
Betreff:=20 RE: ANCP Versioning - next steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs’ = recommendations on the=20 ANCP versioning.

In=20 particular:

  1. I added some text to = explain the=20 history and rationale, at the end of section = 2:=20

 “At the time of=20 writing of this specification some implementations of the ANCP protocol, = based=20 on pre-standards drafts are already available.  All these = early-draft=20 implementations use protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be changed=20 from

   1=20 to 2 upon publication.]  Adopting a new sub-version value=20 provides

   a=20 way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

   on=20 any given ANCP node.  The mechanism used to identify the=20 protocol

  =20 version/sub-version is part of the adjacency negotiation process=20 and

   it=20 is described in details in Section 5.2.  It is important to=20 note

  =20 that this mechanism does not guarantee backwards compatibility of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.”

  1. I explained the=20 version/sub-version negotiation process in section = 5.2:=20

“ANCP uses=20 version 3 and sub-version 1 of GSMP = protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 to 2=20 upon

  =20 publication.]  In the adjacency protocol the version and the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is achieved.  In=20 a

  =20 SYN message the version/sub-version fields always contain the=20 highest

  =20 version understood by the sender.  A receiver receiving a SYN=20 message

  =20 with a version/sub-version higher than understood will ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its ANCP=20 version/sub-version fields.  This defines the version/sub-version=20 of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed version in=20 the

  =20 version/sub-version fields.”

 

  1. I added a non-normative = appendix.=20 This appendix will = contain a=20 clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on = 3.1=20

“6. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC versions of=20 the

  =20 protocol were documented and implemented.  There were numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

   A=20 NAS implementing the ANCP protocol as defined in this document=20 may,

   on=20 a peer basis, use the version and sub-version fields to detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work with=20 such

  =20 pre-RFC peers.  The version and sub-version negotiation phase is=20 part

   of=20 the adjacency protocol and is performed before synchronisation=20 is

  =20 achieved.”

 

Please find = new version=20 of draft attached.

I hope = I’ve captured=20 most of your feedback in the new draft, if not or if you have additional = comments please let me know.

 

Best=20 Regards,

Roberta

 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On = Behalf Of=20 Wojciech Dec (wdec)
Sent: Wednesday, October 14, 2009 = 1:07=20 PM
To: = ancp@ietf.org
Subject: [ANCP] FW: ANCP = Versioning - next=20 steps

 

 

Hi All,

During the ITEF75 WG = meeting a=20 discussion was had on ANCP protocol versioning and the need to revise = the=20 protocol version. A follow-up e-mail discussion on the WG alias took = place and=20 it seems appropriate now (if not=20 overdue) to draw up a set of recommendations and settle = the=20 issue:

Recommended protocol draft = changes and WG=20 actions =

- The currently used ANCP = version=20 3.1 is to change to 3.2 at the time of publishing as an RFC. An = instruction to=20 execute such a change should be placed as part of an editors' note in = the next=20 revision of draft-ietf-ancp-protocol. This instruction is expected to = only come=20 into effect at the time of final review past a WG last-call, which means = that=20 until then v3.1 will be in evidence. Current implementers should make a = note of=20 this fact.

- Another note (not = editorial=20 though) should be placed in an appropriate section, possibly Section 2 = or=20 Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1=20 implementations, which are (were?) based on early versions of the ANCP = protocol=20 draft. The note should be clear in offering no guarantees in terms of = backwards=20 compatibility of the RFC spec to those early-draft implementations. The = note=20 must also not be seen as passing a normative reference to the early = protocol=20 draft.

- Along with the above = note, the=20 existing GSMP/ANCP version negotiation mechanisms could be highlighted,=20 indicating that it provides a way to distinguish between the different = versions=20 if the adjacency establishment negotiation mechanism followed by all is = as per=20 GSMPv3 (rfc3292).

- For the sake of clarity = it is=20 recommended that the adjacency negotiation be more fully described in = the ANCP=20 protocol draft instead of the current reference to rfc3292. = Specifically, it=20 would appear reasonable to adopt and re-edit Section 11.2 of rfc3292 = into the=20 ANCP protocol spec, with the re-edit describing the version negotiation=20 behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic=20 statements as to the expected behaviour in case of version differences, = but such=20 text is in evidence in the descriptive part of Section=20 11.1.

- The WG = should=20 identify what version of the ANCP protocol draft specification = constitutes v3.1.=20 A non-normative reference to such a reference could be passed in the = v3.2=20 spec.

Rationale

From a technical point of = view,=20 given that a "current" (i.e.=20 draft-ietf-protocol-06 based) and = future (i.e. ANCP RFC based) protocols are identical, = with any newly added functions=20 covered as = negotiable capabilities, = the version=20 change does = not=20 appear to be=20 fully warranted=20 and not fully in line with the guidelines previously laid down = (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from an=20 operational perspective=20 a reasonable case for such=20 a version change has made based and presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm.=20

Now,=20 given that normative = compliance to an=20 interim draft (such=20 as draft-ietf-protocol-06 = based) cannot be passed by the = ANCP RFC,=20 text which may=20 be perceived as mandating = or=20 claiming compatibility to such  interim drafts needs to = be=20 avoided.

In the case of = vendors and operators = that already support/use v3.1 = and have=20 plans for v3.2, the version negotiation mechanism that ANCP inherited = from=20 GSMPv3 provides a way to disambiguate the two protocols and thus allows in theory for=20 supporting running a pre-standard (v3.1) = and a=20 standards compliant v3.2 on any given ANCP node. The issue of where v3.1 is documented can be = solved by=20 using non-normative references to one of the interim drafts. The issue = of what=20 rev of draft-ietf-ancp is considered to be v3.1 needs to be=20 clarified.

Other than the above the = WG is=20 currently not chartered = to=20 be extending the protocol spec to cover issues around = protocol=20 version negotiation or remediation of incompatibilities of draft=20 implementations. As = such no such=20 work is expected.

We welcome=20 clarification questions on the above.=20

Regards, =
Wojciech & = Matthew.

Questo messaggio = e i suoi=20 allegati sono indirizzati esclusivamente alle persone indicate. La = diffusione, copia o qualsiasi altra azione derivante dalla = conoscenza di=20 queste informazioni sono rigorosamente vietate. Qualora abbiate = ricevuto=20 questo documento per errore siete cortesemente pregati di darne = immediata=20 comunicazione al mittente e di provvedere alla sua distruzione, = Grazie.=20

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the = addressee(s) only.=20 Dissemination, copying, printing or use by anybody else is = unauthorised.=20 If you are not the intended recipient, please delete this message = and any=20 attachments and advise the sender by return e-mail,=20 Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa mail se non = =E8=20 necessario.=20

------_=_NextPart_002_01CA57DE.3DE7582C-- ------_=_NextPart_001_01CA57DE.3DE7582C Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <906131214@28102009-136B> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA57DE.3DE7582C-- From flefauch@cisco.com Wed Oct 28 08:43:37 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BAB3A69C9 for ; Wed, 28 Oct 2009 08:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IWlldktfdwP for ; Wed, 28 Oct 2009 08:43:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CC3E63A682B for ; Wed, 28 Oct 2009 08:43:23 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208";a="53013473" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 15:43:30 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SFhSRf025929; Wed, 28 Oct 2009 15:43:29 GMT References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Wed, 28 Oct 2009 16:43:27 +0100 To: Tom Taylor X-Mailer: Apple Mail (2.1076) Cc: ancp@ietf.org Subject: Re: [ANCP] [Fwd: I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt] X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 15:43:37 -0000 Tom and all, > Francois had a hand in getting the main ideas into shape, but due to > circumstances on my side he didn't have a chance to read and approve > the final version of the draft. I reviewed the final text of section 6. In general, it is in line with the discussions & conclusions Tom and I had. Below are a the most important comments that I'd like to make sure we agree on: * 6.2.1. The case where CAC is done on NAS is clearly implied but not explicit. I think we want to be explicit about it. So I propose: REPLACE: "The NAS MAY enable admission control at the AN for Nas-initiated replication. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. It MUST also include a Bandwidth- Allocation TLV in a Port Management message for each access line. " BY: "The NAS MAY perform admission control of the NAS-initiated replication. Alternatively, the NAS MAY enable admission control at the AN for NAS-initiated replication. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN and it MUST include a Bandwidth-Allocation TLV in a Port Management message for each access line. " * 6.2.3.1. The case where CAC is done on NAS is clearly implied but not explicit. I think we want to be explicit about it. So I propose: REPLACE: "The NAS can enable admission control at the AN for Grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. It MUST also provide a Bandwidth-Allocation TLV in a Port Management message for each access line. " BY: "The NAS MAY perform admission control for grey-listed flows. Alternatively, the NAS MAY enable admission control at the AN for Grey- listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST also provide a Bandwidth- Allocation TLV in a Port Management message for each access line. " * Result Codes On Tom's proposal, -01 reverted to using Result values AckAll & NAck instead of Ignore (as was done in previous versions) with a few commands where AckAll & NAck seem ed to match teh desired response behavior. I don't feel strongly about that, but want to point out this is a departure from what was agreed before and I am requesting WG opinions on that. * Response to Multicast Replication Control: This comment assumes that the WG agrees that Results AckAll & NAck is the right approach for some commands like Multicast Replication Control. Tom and I agreed that the NAS decides whether to use AckAll or NAck. This has been reflected correctly in 4.3.1: "In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1) according to its requirements." But it has not yet been reflected in the multiple relevant subsections under section 6. For example, section 6.2.3.2 says: " It MUST then send a Multicast Admission Control message to the NAS indicating the deletion." While this should depend on Result Code. Also, section 6.3.2 says: "If the flow was Grey-listed, the AN MUST then send a Multicast Admission Control message to the NAS indicating the deletion. Thus the AN needs to retain the fact that the flow was Grey-listed for the life of the flow." Again, I think responding would depend on the Result field. And I think the AN need not retain the fact that the flow was Grey-Listed. * section 6.3.3: it says: "If either or both conditional access capabilities are combined with the delegated bandwidth capability, the AN always does admission control. " I think this text is not correct and needs to be updated to reflect the White-List-CAC TLV and the MRepCtl-CAC TLV There is also a bunch of editos I will share off-line with co-authors for next rev. Francois From flefauch@cisco.com Wed Oct 28 08:51:34 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2675B28C1F5 for ; Wed, 28 Oct 2009 08:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.406 X-Spam-Level: X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKhOGTow85am for ; Wed, 28 Oct 2009 08:51:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 22F5428C1EC for ; Wed, 28 Oct 2009 08:51:31 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208,217";a="53014813" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 15:51:38 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SFpb1G028495; Wed, 28 Oct 2009 15:51:38 GMT References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-15--734977010 Message-Id: <3DA866A8-8894-4C88-8AAA-BF9812AC3ECD@cisco.com> From: Francois Le Faucheur Date: Wed, 28 Oct 2009 16:51:37 +0100 To: Le Faucheur Francois , Tom Taylor X-Mailer: Apple Mail (2.1076) Cc: ancp@ietf.org Subject: Re: [ANCP] [Fwd: I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt] X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 15:51:34 -0000 --Apple-Mail-15--734977010 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes One additional comment: In section 6.2.4.2 (Delegated Bandwidth), I think we need to add a =20 statement along the lines of "The NAS MAY at any time change the =20 allocated bandwidth using =85" Francois that the NAS On 28 Oct 2009, at 16:43, Francois Le Faucheur wrote: > Tom and all, > >> Francois had a hand in getting the main ideas into shape, but due =20 >> to circumstances on my side he didn't have a chance to read and =20 >> approve the final version of the draft. > > I reviewed the final text of section 6. In general, it is in line =20 > with the discussions & conclusions Tom and I had. > > Below are a the most important comments that I'd like to make sure =20 > we agree on: > > * 6.2.1. The case where CAC is done on NAS is clearly implied but =20 > not explicit. I think we want to be explicit about it. So I propose: > REPLACE: > "The NAS MAY enable admission control at the AN for Nas-initiated =20 > replication. To do this, it MUST include the MRepCtl-CAC TLV in a =20 > Provisioning message sent to the AN. It MUST also include a =20 > Bandwidth-Allocation TLV in a Port Management message for each =20 > access line. > " > BY: > "The NAS MAY perform admission control of the NAS-initiated =20 > replication. Alternatively, the NAS MAY enable admission control at =20= > the AN for NAS-initiated replication. To do this, it MUST include =20 > the MRepCtl-CAC TLV in a Provisioning message sent to the AN and it =20= > MUST include a Bandwidth-Allocation TLV in a Port Management message =20= > for each access line. > " > > * 6.2.3.1. The case where CAC is done on NAS is clearly implied but =20= > not explicit. I think we want to be explicit about it. So I propose: > REPLACE: > "The NAS can enable admission control at the AN for Grey-listed =20 > flows. To do this, it MUST include the MRepCtl-CAC TLV in a =20 > Provisioning message sent to the AN. It MUST also provide a =20 > Bandwidth-Allocation TLV in a Port Management message for each =20 > access line. > " > BY: > "The NAS MAY perform admission control for grey-listed flows. =20 > Alternatively, the NAS MAY enable admission control at the AN for =20 > Grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV =20 > in a Provisioning message sent to the AN and MUST also provide a =20 > Bandwidth-Allocation TLV in a Port Management message for each =20 > access line. > " > > > * Result Codes > On Tom's proposal, -01 reverted to using Result values AckAll & NAck =20= > instead of Ignore (as was done in previous versions) with a few =20 > commands where AckAll & NAck seem ed to match teh desired response =20 > behavior. I don't feel strongly about that, but want to point out =20 > this is a departure from what was agreed before and I am requesting =20= > WG opinions on that. > > > * Response to Multicast Replication Control: > This comment assumes that the WG agrees that Results AckAll & NAck =20 > is the right approach for some commands like Multicast Replication =20 > Control. > Tom and I agreed that the NAS decides whether to use AckAll or NAck. > This has been reflected correctly in 4.3.1: > "In that case, the NAS MUST set the Result field to AckAll (0x2) or =20= > Nack (0x1) according to its requirements." > But it has not yet been reflected in the multiple relevant =20 > subsections under section 6. > For example, section 6.2.3.2 says: > " It MUST then send a Multicast Admission Control message to the NAS =20= > indicating the deletion." > While this should depend on Result Code. > Also, section 6.3.2 says: > "If the flow was Grey-listed, the AN MUST then send a Multicast =20 > Admission Control message to the NAS indicating the deletion. Thus =20= > the AN needs to retain the fact that > the flow was Grey-listed for the life of the flow." > Again, I think responding would depend on the Result field. And I =20 > think the AN need not retain the fact that the flow was Grey-Listed. > > > * section 6.3.3: > it says: > "If either or both conditional access capabilities are combined with =20= > the delegated bandwidth capability, the AN always does admission > control. " > I think this text is not correct and needs to be updated to reflect =20= > the White-List-CAC TLV and the MRepCtl-CAC TLV > > > There is also a bunch of editos I will share off-line with co-=20 > authors for next rev. > > Francois --Apple-Mail-15--734977010 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Francois

 

that the NAS 


On 28 Oct = 2009, at 16:43, Francois Le Faucheur wrote:

Tom = and all,

Francois had a hand in getting = the main ideas into shape, but due to circumstances on my side he didn't = have a chance to read and approve the final version of the = draft.

I reviewed the final text of section 6. In = general, it is in line with the discussions & conclusions Tom and I = had.

Below are a the most important comments that I'd like to = make sure we agree on:

* 6.2.1. The case where CAC is done on NAS = is clearly implied but not explicit. I think we want to be explicit = about it. So I propose:
REPLACE:
"The NAS MAY enable admission = control at the AN for Nas-initiated replication.  To do this, it = MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the = AN.  It MUST also include a Bandwidth-Allocation TLV in a Port = Management message for each access line.
"
BY:
"The NAS MAY = perform admission control of the NAS-initiated replication. = Alternatively, the NAS MAY enable admission control at the AN for = NAS-initiated replication.  To do this, it MUST include the = MRepCtl-CAC TLV in a Provisioning message sent to the AN and it MUST = include a Bandwidth-Allocation TLV in a Port Management message for each = access line.
"

* 6.2.3.1. The case where CAC is done on NAS is = clearly implied but not explicit. I think we want to be explicit about = it. So I propose:
REPLACE:
"The NAS can enable admission control = at the AN for Grey-listed flows. To do this, it MUST include the = MRepCtl-CAC TLV in a Provisioning message sent to the AN.  It MUST = also provide a Bandwidth-Allocation TLV in a Port Management message for = each access line.
"
BY:
"The NAS MAY perform admission control = for grey-listed flows. Alternatively, the NAS MAY enable admission = control at the AN for Grey-listed flows. To do this, it MUST include the = MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST also = provide a Bandwidth-Allocation TLV in a Port Management message for each = access line.
"


* Result Codes
On Tom's proposal, -01 = reverted to using Result values AckAll & NAck instead of Ignore (as = was done in previous versions) with a few commands where AckAll & = NAck seem ed to match teh desired response behavior. I don't feel = strongly about that, but want to point out this is a departure from what = was agreed before and I am requesting WG opinions on that.


* = Response to Multicast Replication Control:
This comment assumes that = the WG agrees that Results AckAll & NAck is the right approach for = some commands like Multicast Replication Control.
Tom and I agreed = that the NAS decides whether to use AckAll or NAck.
This has been = reflected correctly in 4.3.1:
"In that case, the NAS MUST set the = Result field to AckAll (0x2) or Nack (0x1) according to its = requirements."
But it has not yet been reflected in the multiple = relevant subsections under section 6.
For example, section 6.2.3.2 = says:
" It MUST then send a Multicast Admission Control message to = the NAS indicating the deletion."
While this should depend on Result = Code.
Also, section 6.3.2 says:
"If the flow was Grey-listed, the = AN MUST then send a Multicast Admission Control message to the NAS = indicating the deletion.  Thus the AN needs to retain the fact = that
  the flow was Grey-listed for the life of the = flow."
Again, I think responding would depend on the Result field. = And I think the AN need not retain the fact that the flow was = Grey-Listed.


* section 6.3.3:
it says:
"If either or = both conditional access capabilities are combined with the delegated = bandwidth capability, the AN always does admission
=   control. "
I think this text is not correct and needs to = be updated to reflect the White-List-CAC TLV and the MRepCtl-CAC = TLV


There is also a bunch of editos I will share off-line = with co-authors for next = rev.

Francois

= --Apple-Mail-15--734977010-- From tom111.taylor@bell.net Wed Oct 28 12:26:13 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E103A6778 for ; Wed, 28 Oct 2009 12:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.418 X-Spam-Level: X-Spam-Status: No, score=0.418 tagged_above=-999 required=5 tests=[AWL=2.214, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV7xJP7KQhyW for ; Wed, 28 Oct 2009 12:26:12 -0700 (PDT) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by core3.amsl.com (Postfix) with ESMTP id DB47828C206 for ; Wed, 28 Oct 2009 12:26:11 -0700 (PDT) Received: from BLU0-SMTP44 ([65.55.111.71]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 12:26:27 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP44.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 12:26:27 -0700 Date: Wed, 28 Oct 2009 15:26:23 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Francois Le Faucheur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 19:26:27.0358 (UTC) FILETIME=[8B4B93E0:01CA5804] Cc: ancp@ietf.org Subject: Re: [ANCP] [Fwd: I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt] X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:26:13 -0000 My comments to Francois' proposals below. Francois Le Faucheur wrote: > Tom and all, > >> Francois had a hand in getting the main ideas into shape, but due to >> circumstances on my side he didn't have a chance to read and approve >> the final version of the draft. > > I reviewed the final text of section 6. In general, it is in line with > the discussions & conclusions Tom and I had. > > Below are a the most important comments that I'd like to make sure we > agree on: > > * 6.2.1. The case where CAC is done on NAS is clearly implied but not > explicit. I think we want to be explicit about it. So I propose: > REPLACE: > "The NAS MAY enable admission control at the AN for Nas-initiated > replication. To do this, it MUST include the MRepCtl-CAC TLV in a > Provisioning message sent to the AN. It MUST also include a > Bandwidth-Allocation TLV in a Port Management message for each access line. > " > BY: > "The NAS MAY perform admission control of the NAS-initiated replication. > Alternatively, the NAS MAY enable admission control at the AN for > NAS-initiated replication. To do this, it MUST include the MRepCtl-CAC > TLV in a Provisioning message sent to the AN and it MUST include a > Bandwidth-Allocation TLV in a Port Management message for each access line. > " > > * 6.2.3.1. The case where CAC is done on NAS is clearly implied but not > explicit. I think we want to be explicit about it. So I propose: > REPLACE: > "The NAS can enable admission control at the AN for Grey-listed flows. > To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning > message sent to the AN. It MUST also provide a Bandwidth-Allocation TLV > in a Port Management message for each access line. > " > BY: > "The NAS MAY perform admission control for grey-listed flows. > Alternatively, the NAS MAY enable admission control at the AN for > Grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a > Provisioning message sent to the AN and MUST also provide a > Bandwidth-Allocation TLV in a Port Management message for each access line. > " > [PTT] OK with all above. You brought up the point privately that we could now drop the R flag from the Multicast Replication Control message. I agree with you -- we now have explicit controls at AN-level and don't need a control per flow too. > > * Result Codes > On Tom's proposal, -01 reverted to using Result values AckAll & NAck > instead of Ignore (as was done in previous versions) with a few commands > where AckAll & NAck seem ed to match teh desired response behavior. I > don't feel strongly about that, but want to point out this is a > departure from what was agreed before and I am requesting WG opinions on > that. > > > * Response to Multicast Replication Control: > This comment assumes that the WG agrees that Results AckAll & NAck is > the right approach for some commands like Multicast Replication Control. > Tom and I agreed that the NAS decides whether to use AckAll or NAck. > This has been reflected correctly in 4.3.1: > "In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack > (0x1) according to its requirements." > But it has not yet been reflected in the multiple relevant subsections > under section 6. > For example, section 6.2.3.2 says: > " It MUST then send a Multicast Admission Control message to the NAS > indicating the deletion." > While this should depend on Result Code. > Also, section 6.3.2 says: > "If the flow was Grey-listed, the AN MUST then send a Multicast > Admission Control message to the NAS indicating the deletion. Thus the > AN needs to retain the fact that > the flow was Grey-listed for the life of the flow." > Again, I think responding would depend on the Result field. And I think > the AN need not retain the fact that the flow was Grey-Listed. > [PTT] I think you have the order wrong here. The Multicast Replication Control message is a response to the Multicast Admission Control message, not the other way around. > > * section 6.3.3: > it says: > "If either or both conditional access capabilities are combined with the > delegated bandwidth capability, the AN always does admission > control. " > I think this text is not correct and needs to be updated to reflect the > White-List-CAC TLV and the MRepCtl-CAC TLV > [PTT] OK. I guess I saw the possibility that the NAS ended up choosing to do admission control for everything, in which case why bother to enable bandwidth delegation? But that isn't really a protocol issue. > > There is also a bunch of editos I will share off-line with co-authors > for next rev. > > Francois > > From tom111.taylor@bell.net Wed Oct 28 13:46:32 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCCD3A686C for ; Wed, 28 Oct 2009 13:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.44 X-Spam-Level: * X-Spam-Status: No, score=1.44 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeH4B4Mu7p5J for ; Wed, 28 Oct 2009 13:46:32 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id 31BFE3A6A6A for ; Wed, 28 Oct 2009 13:46:32 -0700 (PDT) Received: from BLU0-SMTP23 ([65.55.111.72]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:46:47 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP23.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:46:47 -0700 Date: Wed, 28 Oct 2009 16:46:43 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 20:46:47.0217 (UTC) FILETIME=[C427B210:01CA580F] Subject: [ANCP] Thoughts on the R flag X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:46:33 -0000 The R flag is used in the Command TLV in the Multicast replication Control message to indicate to the AN whether CAC for a particular added multicast flow was done at the NAS or must be done by the AN. If we get rid of the R flag, we no longer have per-flow control. All NAS-initiated flows and all Grey-listed flows are admitted either by the NAS or by the AN. Is this reasonable, or will there ever be an operational requirement for the NAS and AN to both have a multicast bandwidth budget, applicable to different classes of service (e.g. broadcast video vs. games)? Tom From flefauch@cisco.com Thu Oct 29 04:58:51 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6FC3A68C6 for ; Thu, 29 Oct 2009 04:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XhGYEw0WcdH for ; Thu, 29 Oct 2009 04:58:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8A94B3A687B for ; Thu, 29 Oct 2009 04:58:49 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,645,1249257600"; d="scan'208";a="53093160" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 11:59:04 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TBx2wg001132; Thu, 29 Oct 2009 11:59:03 GMT References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Thu, 29 Oct 2009 12:59:01 +0100 To: Tom Taylor X-Mailer: Apple Mail (2.1076) Cc: ancp@ietf.org Subject: Re: [ANCP] [Fwd: I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt] X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 11:58:51 -0000 On 28 Oct 2009, at 20:26, Tom Taylor wrote: > My comments to Francois' proposals below. > > Francois Le Faucheur wrote: >> Tom and all, >>> Francois had a hand in getting the main ideas into shape, but due >>> to circumstances on my side he didn't have a chance to read and >>> approve the final version of the draft. >> I reviewed the final text of section 6. In general, it is in line >> with the discussions & conclusions Tom and I had. >> Below are a the most important comments that I'd like to make sure >> we agree on: >> * 6.2.1. The case where CAC is done on NAS is clearly implied but >> not explicit. I think we want to be explicit about it. So I propose: >> REPLACE: >> "The NAS MAY enable admission control at the AN for Nas-initiated >> replication. To do this, it MUST include the MRepCtl-CAC TLV in a >> Provisioning message sent to the AN. It MUST also include a >> Bandwidth-Allocation TLV in a Port Management message for each >> access line. >> " >> BY: >> "The NAS MAY perform admission control of the NAS-initiated >> replication. Alternatively, the NAS MAY enable admission control at >> the AN for NAS-initiated replication. To do this, it MUST include >> the MRepCtl-CAC TLV in a Provisioning message sent to the AN and it >> MUST include a Bandwidth-Allocation TLV in a Port Management >> message for each access line. >> " >> * 6.2.3.1. The case where CAC is done on NAS is clearly implied but >> not explicit. I think we want to be explicit about it. So I propose: >> REPLACE: >> "The NAS can enable admission control at the AN for Grey-listed >> flows. To do this, it MUST include the MRepCtl-CAC TLV in a >> Provisioning message sent to the AN. It MUST also provide a >> Bandwidth-Allocation TLV in a Port Management message for each >> access line. >> " >> BY: >> "The NAS MAY perform admission control for grey-listed flows. >> Alternatively, the NAS MAY enable admission control at the AN for >> Grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV >> in a Provisioning message sent to the AN and MUST also provide a >> Bandwidth-Allocation TLV in a Port Management message for each >> access line. >> " > [PTT] OK with all above. Ack. > You brought up the point privately that we could now drop the R flag > from the Multicast Replication Control message. I agree with you -- > we now have explicit controls at AN-level and don't need a control > per flow too. Right. That should simplify operations quite a bit. >> * Result Codes >> On Tom's proposal, -01 reverted to using Result values AckAll & >> NAck instead of Ignore (as was done in previous versions) with a >> few commands where AckAll & NAck seem ed to match teh desired >> response behavior. I don't feel strongly about that, but want to >> point out this is a departure from what was agreed before and I am >> requesting WG opinions on that. >> * Response to Multicast Replication Control: >> This comment assumes that the WG agrees that Results AckAll & NAck >> is the right approach for some commands like Multicast Replication >> Control. >> Tom and I agreed that the NAS decides whether to use AckAll or NAck. >> This has been reflected correctly in 4.3.1: >> "In that case, the NAS MUST set the Result field to AckAll (0x2) or >> Nack (0x1) according to its requirements." >> But it has not yet been reflected in the multiple relevant >> subsections under section 6. >> For example, section 6.2.3.2 says: >> " It MUST then send a Multicast Admission Control message to the >> NAS indicating the deletion." >> While this should depend on Result Code. >> Also, section 6.3.2 says: >> "If the flow was Grey-listed, the AN MUST then send a Multicast >> Admission Control message to the NAS indicating the deletion. Thus >> the AN needs to retain the fact that >> the flow was Grey-listed for the life of the flow." >> Again, I think responding would depend on the Result field. And I >> think the AN need not retain the fact that the flow was Grey-Listed. > [PTT] I think you have the order wrong here. The Multicast > Replication Control message is a response to the Multicast Admission > Control message, not the other way around. My mistake. I got confused by the phrase "the AN receives a leave". This means that the AN receives an IGMP leave, and I thought it meant the AN receives a Multicast Replication Control message with a delete (as per NAS-initiated which is not applicable to these sections). Anyways, ignore my comment. Regarding: "Thus the AN needs to retain the fact that the flow was Grey-listed for the life of the flow." While a given AN implementation may "retain the fact", I think an AN implementation could potentially decide to re-subjects the "leave" to the White/Grey-List matching (and then it does not need to "retain the fact"). No? I am not arguing it is a better approach, just that we may not want to be overly prescriptive. So perhaps we should change that sentence into something like : ""To that end the AN may retain the fact that the flow was Grey-listed for the life of the flow. Alternatively, it may subject the "leave" requests to Grey/White list matching". >> * section 6.3.3: >> it says: >> "If either or both conditional access capabilities are combined >> with the delegated bandwidth capability, the AN always does admission >> control. " >> I think this text is not correct and needs to be updated to reflect >> the White-List-CAC TLV and the MRepCtl-CAC TLV > [PTT] OK. I guess I saw the possibility that the NAS ended up > choosing to do admission control for everything, That is one scenario. > in which case why bother to enable bandwidth delegation? True. > But that isn't really a protocol issue. And there are other scenarios we want to allow. In particular, where the NAS decides to do admission control for Grey (and unicast) and requests the AN to do admission control for white, and bandwidth delegation is used to coordinate bandwidth between AN/White and NAS/ Grey&unicast. So I would propose that for "White/Black + Grey + Bandwidth- Delegation" the distribution/control of admission control works the same as when we have "White/Black + Grey" (only the AN and NAS can now dynamically share bandwidth if/when appropriate). Does that work for you (and all)? Francois >> There is also a bunch of editos I will share off-line with co- >> authors for next rev. >> Francois From alan.kavanagh@ericsson.com Thu Oct 29 10:37:46 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A1F28C10D for ; Thu, 29 Oct 2009 10:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.99 X-Spam-Level: X-Spam-Status: No, score=-4.99 tagged_above=-999 required=5 tests=[AWL=-1.608, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRHD6e1eyVbh for ; Thu, 29 Oct 2009 10:37:44 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id CCB833A67B5 for ; Thu, 29 Oct 2009 10:37:43 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9THbhWL023712; Thu, 29 Oct 2009 12:37:43 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 12:36:38 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 12:36:37 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 29 Oct 2009 13:36:17 -0400 From: Alan Kavanagh To: "HaagT@telekom.de" , "roberta.maglione@telecomitalia.it" , "wdec@cisco.com" , "ancp@ietf.org" , "Robert.Rennison@ecitele.com" , "swadhwa@juniper.net" , "matthew.bocci@alcatel-lucent.co.uk" , "tom111.taylor@bell.net" , "Manuel.Paul@telekom.de" , "B.Witschurke@telekom.de" Date: Thu, 29 Oct 2009 13:36:16 -0400 Thread-Topic: ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA5YRjA Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D50112734B86@EUSAACMS0701.eamcs.ericsson.se> References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local> <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Oct 2009 17:36:37.0615 (UTC) FILETIME=[5DEA57F0:01CA58BE] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 17:37:46 -0000 --_004_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_ Content-Type: multipart/alternative; boundary="_000_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_" --_000_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roberta et.al Thomas is correct, from the notes of the San Fran meeting we agreed to keep= the Partition ID section, so can you please reinsert this. BR Alan ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de] Sent: October 28, 2009 10:52 AM To: roberta.maglione@telecomitalia.it; wdec@cisco.com; ancp@ietf.org; Alan = Kavanagh; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@a= lcatel-lucent.co.uk; tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Wits= churke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID Hi Roberta, all, thanks for providing the updated protocol draft. So far I recognized that the update covers issues regarding versioning, tec= h Type for GPON and Range of values of the code field. But I notice on page 17 of version 07 that the whole section of partition I= D including definition is deleted. >From my understanding (and as result from the minutes) it was agreed during= 75th IETF meeting to keep the partition ID. Extract from 75th IETF minutes: (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to distingu= ish between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems if partition-id not available. No one felt strongly -- will keep "as is". So we had consensus not to remove and keep partion ID. But I didn't find it= in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there any = reasons for doing this? So I recommend update the protocol draft before upcoming meeting keeping pa= rtition ID. Regards Thomas . ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; alan.kavanagh@erics= son.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI Matthew; '= tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps Hi All, I updated the ancp protocol draft following the chairs' recommendation= s on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end of = section 2: "At the time of writing of this specification some implementations of the = ANCP protocol, based on pre-standards drafts are already available. All th= ese early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations." 1. I explained the version/sub-version negotiation process in section 5.2= : "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP version/s= ub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields." 1. I added a non-normative appendix. This appendix will contain a clarifi= cation of what version of the ANCP protocol draft specification constitutes= version 3.1 as soon as the WG decides on 3.1 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol This appendix is non normative. Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved." Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or if y= ou have additional comments please let me know. Best Regards, Roberta ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps Hi All, During the ITEF75 WG meeting a discussion was had on ANCP protocol versioni= ng and the need to revise the protocol version. A follow-up e-mail discussi= on on the WG alias took place and it seems appropriate now (if not overdue)= to draw up a set of recommendations and settle the issue: Recommended protocol draft changes and WG actions - The currently used ANCP version 3.1 is to change to 3.2 at the time of pu= blishing as an RFC. An instruction to execute such a change should be place= d as part of an editors' note in the next revision of draft-ietf-ancp-proto= col. This instruction is expected to only come into effect at the time of f= inal review past a WG last-call, which means that until then v3.1 will be i= n evidence. Current implementers should make a note of this fact. - Another note (not editorial though) should be placed in an appropriate se= ction, possibly Section 2 or Section 5, to convey in-brief the historic asp= ect of GSMP/ANCP v3.1 implementations, which are (were?) based on early ver= sions of the ANCP protocol draft. The note should be clear in offering no g= uarantees in terms of backwards compatibility of the RFC spec to those earl= y-draft implementations. The note must also not be seen as passing a normat= ive reference to the early protocol draft. - Along with the above note, the existing GSMP/ANCP version negotiation mec= hanisms could be highlighted, indicating that it provides a way to distingu= ish between the different versions if the adjacency establishment negotiati= on mechanism followed by all is as per GSMPv3 (rfc3292). - For the sake of clarity it is recommended that the adjacency negotiation = be more fully described in the ANCP protocol draft instead of the current r= eference to rfc3292. Specifically, it would appear reasonable to adopt and = re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-ed= it describing the version negotiation behaviour. Rather confusingly Rfc3292= Section 11.2 does not carry text or logic statements as to the expected be= haviour in case of version differences, but such text is in evidence in the= descriptive part of Section 11.1. - The WG should identify what version of the ANCP protocol draft specificat= ion constitutes v3.1. A non-normative reference to such a reference could b= e passed in the v3.2 spec. Rationale >From a technical point of view, given that a "current" (i.e. draft-ietf-pro= tocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, w= ith any newly added functions covered as negotiable capabilities, the versi= on change does not appear to be fully warranted and not fully in line with = the guidelines previously laid down (http://www.ietf.org/mail-archive/web/a= ncp/current/msg00152.html). That said, from an operational perspective a re= asonable case for such a version change has made based and presented in htt= ps://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.ht= m. Now, given that normative compliance to an interim draft (such as draft-iet= f-protocol-06 based) cannot be passed by the ANCP RFC, text which may be pe= rceived as mandating or claiming compatibility to such interim drafts need= s to be avoided. In the case of vendors and operators that already support/use v3.1 and have= plans for v3.2, the version negotiation mechanism that ANCP inherited from= GSMPv3 provides a way to disambiguate the two protocols and thus allows in= theory for supporting running a pre-standard (v3.1) and a standards compli= ant v3.2 on any given ANCP node. The issue of where v3.1 is documented can = be solved by using non-normative references to one of the interim drafts. T= he issue of what rev of draft-ietf-ancp is considered to be v3.1 needs to b= e clarified. Other than the above the WG is currently not chartered to be extending the = protocol spec to cover issues around protocol version negotiation or remedi= ation of incompatibilities of draft implementations. As such no such work i= s expected. We welcome clarification questions on the above. Regards, Wojciech & Matthew. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:021103517@29102009-2D6C]Rispetta l'ambiente. Non stampare questa mail = se non =E8 necessario. --_000_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP Versioni= ng - next steps
Hi Roberta et.al
 
Thomas is correct, from the notes of the San Fran = meeting=20 we agreed to keep the Partition ID section, so can you please reinsert this= .=20
 
BR
Alan

From: HaagT@telekom.de [mailto:HaagT@te= lekom.de]=20
Sent: October 28, 2009 10:52 AM
To:=20 roberta.maglione@telecomitalia.it; wdec@cisco.com; ancp@ietf.org; Alan Kava= nagh;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; B.Witschurke@telekom.de
Subject: AW: ANCP= =20 Versioning - next steps; partition ID

Hi Roberta, all,
 
thanks for providing the updated protocol=20 draft.
 
So far I recognized that the update covers issues = regarding=20 versioning, tech Type for GPON and Range of values of the code=20 field.
 
But I notice on page 17 of version 07 that the who= le=20 section of partition ID including definition is deleted.
From my understanding (and as result from the= minutes)=20 it was agreed during 75th IETF meeting to keep the partition=20 ID.
 
Extract from 75th IETF minutes:
 
(1)=20 Partition-id
    ------------
Sanjay: concerned that=20 removing the partition-id reduces extensibility.
Thomas Haag: need multi= ple=20 partition-ids because one might need to distinguish
between BRASs when= =20 expanding the network.
Woj: send e-mail. Thomas: already did. Makes for= =20 operational problems
if partition-id not available.
No one felt str= ongly=20 -- will keep "as is".
 
So we had consensus not to remove and keep pa= rtion ID.=20 But I didn't find it in the whole document any more.
Based=20 on that agreements I wonder why this issue is deleted. Are there any reasons for doing=20 this?
 
So I recommend update the protocol draft before up= coming=20 meeting keeping partition ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Gesendet: Montag, 19.= =20 Oktober 2009 16:16
An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag= ,=20 Thomas; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net'
Betreff:= =20 RE: ANCP Versioning - next steps

Hi=20 All,

  &nbs= p; =20 I updated the ancp protocol draft following the chairs=92 recommendations o= n the=20 ANCP versioning.

In=20 particular:

  1. I added some text to explai= n the=20 history and rationale, at the end of section 2:= =20

 =93At th= e time of=20 writing of this specification some implementations of the ANCP protocol, ba= sed=20 on pre-standards drafts are already available.  All these early-draft= =20 implementations use protocol

 &n= bsp;=20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

 &n= bsp;=20 sub-version 3.2 [Editor's note: sub-version needs to be changed=20 from

 &n= bsp; 1=20 to 2 upon publication.]  Adopting a new sub-version value=20 provides

 &n= bsp; a=20 way to disambiguate the two protocols and allows for=20 supporting

 &n= bsp;=20 running a pre-standard and a standards compliant ANCP=20 implementation

 &n= bsp; on=20 any given ANCP node.  The mechanism used to identify the=20 protocol

 &n= bsp;=20 version/sub-version is part of the adjacency negotiation process=20 and

 &n= bsp; it=20 is described in details in Section 5.2.  It is important to=20 note

 &n= bsp;=20 that this mechanism does not guarantee backwards compatibility of=20 the

 &n= bsp;=20 ANCP RFC specification to those early-draft=20 implementations.=94

  1. I explained the=20 version/sub-version negotiation process in section 5.2:<= /FONT>=20

=93ANCP = uses=20 version 3 and sub-version 1 of GSMP protocol.

 &n= bsp;=20 [RFC Editor's note: sub-version needs to be changed from 1 to 2=20 upon

 &n= bsp;=20 publication.]  In the adjacency protocol the version and the=20 sub-

 &n= bsp;=20 version fields are used for version negotiation.  The=20 version

 &n= bsp;=20 negotiation is performed before synchronisation is achieved.  In=20 a

 &n= bsp;=20 SYN message the version/sub-version fields always contain the=20 highest

 &n= bsp;=20 version understood by the sender.  A receiver receiving a SYN=20 message

 &n= bsp;=20 with a version/sub-version higher than understood will ignore=20 that

 &n= bsp;=20 message.  A receiver receiving a SYN message with a=20 version/

 &n= bsp;=20 sub-vresion lower than its own highest version/sub-version, but=20 a

 &n= bsp;=20 version/sub-version that it understands, will reply with a=20 SYNACK

 &n= bsp;=20 with the version/sub-version from the received SYN in its ANCP=20 version/sub-version fields.  This defines the version/sub-version=20 of

 &n= bsp;=20 the ANCP protocol to be used while the adjacency protocol=20 remains

 &n= bsp;=20 synchronised.  All other messages will use the agreed version in=20 the

 &n= bsp;=20 version/sub-version fields.=94<= /SPAN>

 

  1. I added a non-normative app= endix.=20 This appendix will contain = a=20 clarification of what version of the ANCP protocol draft specification=20 constitutes version 3.1 as soon as the WG decides on 3.1<= /FONT>=20

=936.&nb= sp;=20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

&nb= sp;

 &n= bsp;=20 This appendix is non normative.

&nb= sp;

 &n= bsp;=20 Prior to completion of this document, several pre-RFC versions of=20 the

 &n= bsp;=20 protocol were documented and implemented.  There were numerous=20 pre-

 &n= bsp;=20 standard versions of the protocol all using a=20 version/sub-version

 &n= bsp;=20 fields set to 3.1.

&nb= sp;

 &n= bsp; A=20 NAS implementing the ANCP protocol as defined in this document=20 may,

 &n= bsp; on=20 a peer basis, use the version and sub-version fields to detect=20 a

 &n= bsp;=20 pre-RFC implementation of the protocol and choose to work with=20 such

 &n= bsp;=20 pre-RFC peers.  The version and sub-version negotiation phase is=20 part

 &n= bsp; of=20 the adjacency protocol and is performed before synchronisation=20 is

 &n= bsp;=20 achieved.=94

&nb= sp;

Please find new = version=20 of draft attached.

I hope I=92ve ca= ptured=20 most of your feedback in the new draft, if not or if you have additional=20 comments please let me know.

 

Best=20 Regards,

Roberta

 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Beha= lf Of=20 Wojciech Dec (wdec)
Sent: Wednesday, October 14, 2009 1:= 07=20 PM
To: ancp@ietf.org
Subject: [ANCP] FW: ANCP Versioning = - next=20 steps

 

 

Hi All,

During the ITEF75 WG meeting = a=20 discussion was had on ANCP protocol versioning and the need to revise the=20 protocol version. A follow-up e-mail discussion on the WG alias took place = and=20 it seems appropriate now (= if not=20 overdue) to draw up a set of recommendations and settle the=20 issue:

Recommended protocol draft changes and WG=20 actions

- The currently used ANCP ver= sion=20 3.1 is to change to 3.2 at the time of publishing as an RFC. An instruction= to=20 execute such a change should be placed as part of an editors' note in the n= ext=20 revision of draft-ietf-ancp-protocol. This instruction is expected to only = come=20 into effect at the time of final review past a WG last-call, which means th= at=20 until then v3.1 will be in evidence. Current implementers should make a not= e of=20 this fact.

- Another note (not editorial= =20 though) should be placed in an appropriate section, possibly Section 2 or=20 Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1=20 implementations, which are (were?) based on early versions of the ANCP prot= ocol=20 draft. The note should be clear in offering no guarantees in terms of backw= ards=20 compatibility of the RFC spec to those early-draft implementations. The not= e=20 must also not be seen as passing a normative reference to the early protoco= l=20 draft.

- Along with the above note, = the=20 existing GSMP/ANCP version negotiation mechanisms could be highlighted,=20 indicating that it provides a way to distinguish between the different vers= ions=20 if the adjacency establishment negotiation mechanism followed by all is as = per=20 GSMPv3 (rfc3292).

- For the sake of clarity it = is=20 recommended that the adjacency negotiation be more fully described in the A= NCP=20 protocol draft instead of the current reference to rfc3292. Specifically, i= t=20 would appear reasonable to adopt and re-edit Section 11.2 of rfc3292 into t= he=20 ANCP protocol spec, with the re-edit describing the version negotiation=20 behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text or l= ogic=20 statements as to the expected behaviour in case of version differences, but= such=20 text is in evidence in the descriptive part of Section=20 11.1.

- The WG should= =20 identify what version of the ANCP protocol draft specification constitutes = v3.1.=20 A non-normative reference to such a reference could be passed in the v3.2=20 spec.

Rationale

From a technical point of vie= w,=20 given that a "current" (i.e.= =20 draft-ietf-protocol-06 based) and future= (i.e.= ANCP RFC<= SPAN=20 style=3D"COLOR: black"> based) protocols are identical, with = any<= SPAN=20 lang=3DEN-GB> newly added functions=20 covered <= SPAN=20 style=3D"COLOR: black">as=20 negotiable capabilities, the = version=20 change does not=20 appear to be=20 fully w= arranted=20 and not fully in line with the guidelines previously laid down (http://www.ietf.org/mail-arch= ive/web/ancp/current/msg00152.html). That said, from an=20 operational p= erspective=20 a reasonable case for such= =20 a version change has<= SPAN=20 lang=3DEN-GB> made based and presented in https://svn.tools.ietf.org/ag= enda/75/slides/ancp-3/ancp-3_files/v3_document.htm.=20

Now,=20 given that normative complianc= e to an=20 interim draft (such=20 as draft-ietf-protocol-06 based) cannot be passed by the ANCP = RFC,=20 text which may=20 be perceived as mandating or= =20 claiming compatibility to such  interim drafts needs to be= =20 avoided.

In the case of=20 vendors and operators that= already support/use v3.1 and = have=20 plans for v3.2, the version negotiation mechanism that ANCP inherited from= =20 GSMPv3 provides a way to disambiguate the two protocols and thus= allows in theory for=20 supporting running a pre-standard (v3.1) and = a=20 standards compliant v3.2 on any given ANCP node. The issue of where v3.1 is documented can be solved = by=20 using non-normative references to one of the interim drafts. The issue of w= hat=20 rev of draft-ietf-ancp is considered to be v3.1 needs to be=20 clarified.

Other than the above the WG i= s=20 currently not chartered to= =20 be extending the protocol spec to cover issues around protoco= l=20 version negotiation or remediation of incompatibilities of draft=20 implementations. As such n= o such=20 work is expected.

We welcome=20 clarification questions on the above.=20

Regards,
Wojciech & Matthew.

Questo messaggio e i= suoi=20 allegati sono indirizzati esclusivamente alle persone indicate. La=20 diffusione, copia o qualsiasi altra azione derivante dalla conoscenza= di=20 queste informazioni sono rigorosamente vietate. Qualora abbiate ricev= uto=20 questo documento per errore siete cortesemente pregati di darne immed= iata=20 comunicazione al mittente e di provvedere alla sua distruzione, Grazi= e.=20

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the addressee(s) = only.=20 Dissemination, copying, printing or use by anybody else is unauthoris= ed.=20 If you are not the intended recipient, please delete this message and= any=20 attachments and advise the sender by return e-mail,=20 Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8=20 necessario.=20

--_000_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_-- --_004_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_ Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Description: logo Ambiente_foglia.jpg Content-Disposition: inline; filename="logo Ambiente_foglia.jpg"; size=677; creation-date="Thu, 29 Oct 2009 13:36:17 GMT"; modification-date="Thu, 29 Oct 2009 13:36:17 GMT" Content-ID: <021103517@29102009-2D6C> Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_1B6D0317D3AD964FBF3956DEFA3524D50112734B86EUSAACMS0701e_-- From wdec@cisco.com Thu Oct 29 11:45:17 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BD93A685E for ; Thu, 29 Oct 2009 11:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.839 X-Spam-Level: X-Spam-Status: No, score=-8.839 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faLNgE0N7odu for ; Thu, 29 Oct 2009 11:45:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8E5013A67D7 for ; Thu, 29 Oct 2009 11:45:12 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo Ambiente_foglia.jpg : 677 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkAAAOA6UqQ/uCWe2dsb2JhbACCJiwhhFQ2k0sBARYkBqtGmByCOIIFBIFi X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="jpg'147?scan'147,208,217,147";a="53135334" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 18:45:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TIjR8e028393; Thu, 29 Oct 2009 18:45:27 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 19:45:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA58C7.FB165D63" Date: Thu, 29 Oct 2009 19:45:22 +0100 Message-ID: In-Reply-To: <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FA References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local> <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: , , , , , , , , , X-OriginalArrivalTime: 29 Oct 2009 18:45:27.0197 (UTC) FILETIME=[FB568CD0:01CA58C7] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:45:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA58C7.FB165D63 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA58C7.FB165D63" ------_=_NextPart_002_01CA58C7.FB165D63 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While keeping the GSMP derived partition-id in the protocol spec "as is" = is fine, a note should perhaps also be inserted stating that this field = is effectively not currently used by ANCP. At least this is my = recollection of the discussion on this matter, ie partition-id is fine, = but we don't really have a use for it now given that functional = partitioning is not covered and that an AN will have 1 adjacency to each = NAS/controller. =20 -Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID =09 =09 Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding versioning, = tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 =09 So we had consensus not to remove and keep partion ID. But I didn't = find it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there = any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting = keeping partition ID. =20 Regards =20 Thomas .=20 =20 ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps =09 =09 Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end = of section 2:=20 "At the time of writing of this specification some implementations of = the ANCP protocol, based on pre-standards drafts are already available. = All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of = the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in section = 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the = highest version understood by the sender. A receiver receiving a SYN = message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions of = the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document = may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is = part of the adjacency protocol and is performed before synchronisation is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or = if you have additional comments please let me know. =20 Best Regards, Roberta =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the time = of publishing as an RFC. An instruction to execute such a change should = be placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an = appropriate section, possibly Section 2 or Section 5, to convey in-brief = the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version negotiation = mechanisms could be highlighted, indicating that it provides a way to = distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html = ). = That said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm = .=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and = have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending = the protocol spec to cover issues around protocol version negotiation or = remediation of incompatibilities of draft implementations. As such no = such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 ------_=_NextPart_002_01CA58C7.FB165D63 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP = Versioning - next steps
While keeping the GSMP derived partition-id in the = protocol spec "as=20 is" is fine, a note should perhaps also be inserted stating that this = field is=20 effectively not currently used by ANCP. At least this is my recollection = of the=20 discussion on this matter, ie partition-id is fine, but we don't really = have a=20 use for it now given that functional partitioning is not covered and = that an AN=20 will have 1 adjacency to each NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009 = 15:52
To:=20 roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; B.Witschurke@telekom.de
Subject: AW: = ANCP=20 Versioning - next steps; partition ID

Hi Roberta, all,
 
thanks for providing the updated protocol=20 draft.
 
So far I recognized that the update covers = issues=20 regarding versioning, tech Type for GPON and Range of values of the = code=20 field.
 
But I notice on page 17 of version 07 that = the whole=20 section of partition ID including definition is = deleted.
From my understanding (and as = result from the=20 minutes) it was agreed during 75th IETF meeting to keep the partition=20 ID.
 
Extract from 75th IETF minutes: =
 
(1)=20 Partition-id
    ------------
Sanjay: concerned = that=20 removing the partition-id reduces extensibility.
Thomas Haag: need = multiple=20 partition-ids because one might need to distinguish
between BRASs = when=20 expanding the network.
Woj: send e-mail. Thomas: already did. Makes = for=20 operational problems
if partition-id not available.
No one = felt=20 strongly -- will keep "as is".
 
So we had consensus not to remove and = keep partion=20 ID. But I didn't find it in the whole document any = more.
Based on that agreements I wonder why this issue is = deleted. Are there any reasons for doing=20 this?
 
So I recommend update the protocol draft = before upcoming=20 meeting keeping partition ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Gesendet: = Montag, 19.=20 Oktober 2009 16:16
An: 'Wojciech Dec (wdec)'; ancp@ietf.org; = Haag,=20 Thomas; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; BOCCI Matthew;=20 'tom111.taylor@bell.net'
Betreff: RE: ANCP Versioning - next = steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs=92 = recommendations on the=20 ANCP versioning.

In=20 particular:

  1. I added some text to = explain the=20 history and rationale, at the end of section = 2:=20

 =93At the time=20 of writing of this specification some implementations of the ANCP = protocol,=20 based on pre-standards drafts are already available.  All these=20 early-draft implementations use protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be changed=20 from

  =20 1 to 2 upon publication.]  Adopting a new sub-version value=20 provides

  =20 a way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

  =20 on any given ANCP node.  The mechanism used to identify the=20 protocol

  =20 version/sub-version is part of the adjacency negotiation process=20 and

  =20 it is described in details in Section 5.2.  It is important to=20 note

  =20 that this mechanism does not guarantee backwards compatibility of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.=94

  1. I explained the=20 version/sub-version negotiation process in section = 5.2:=20

=93ANCP uses=20 version 3 and sub-version 1 of GSMP = protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 to 2=20 upon

  =20 publication.]  In the adjacency protocol the version and the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is achieved.  In=20 a

  =20 SYN message the version/sub-version fields always contain the=20 highest

  =20 version understood by the sender.  A receiver receiving a SYN=20 message

  =20 with a version/sub-version higher than understood will ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its ANCP=20 version/sub-version fields.  This defines the version/sub-version = of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed version in=20 the

  =20 version/sub-version fields.=94

 

  1. I added a = non-normative=20 appendix. This appendix will = contain a=20 clarification of what version of the ANCP protocol draft = specification=20 constitutes version 3.1 as soon as the WG decides on = 3.1=20

=936. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC versions of=20 the

  =20 protocol were documented and implemented.  There were numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

  =20 A NAS implementing the ANCP protocol as defined in this document=20 may,

  =20 on a peer basis, use the version and sub-version fields to detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work with=20 such

  =20 pre-RFC peers.  The version and sub-version negotiation phase is=20 part

  =20 of the adjacency protocol and is performed before synchronisation=20 is

  =20 achieved.=94

 

Please find = new=20 version of draft attached.

I hope = I=92ve captured=20 most of your feedback in the new draft, if not or if you have = additional=20 comments please let me know.

 

Best=20 Regards,

Roberta

 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On = Behalf Of=20 Wojciech Dec (wdec)
Sent: Wednesday, October 14, = 2009 1:07=20 PM
To: = ancp@ietf.org
Subject: [ANCP] FW: ANCP = Versioning -=20 next steps

 

 

Hi = All,

During the ITEF75 WG = meeting a=20 discussion was had on ANCP protocol versioning and the need to revise = the=20 protocol version. A follow-up e-mail discussion on the WG alias took = place and=20 it seems appropriate now (if not=20 overdue) to draw up a set of recommendations and settle = the=20 issue:

Recommended protocol = draft changes and WG=20 actions=20

- The currently used = ANCP version=20 3.1 is to change to 3.2 at the time of publishing as an RFC. An = instruction to=20 execute such a change should be placed as part of an editors' note in = the next=20 revision of draft-ietf-ancp-protocol. This instruction is expected to = only=20 come into effect at the time of final review past a WG last-call, = which means=20 that until then v3.1 will be in evidence. Current implementers should = make a=20 note of this fact.

- Another note (not = editorial=20 though) should be placed in an appropriate section, possibly Section 2 = or=20 Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1=20 implementations, which are (were?) based on early versions of the ANCP = protocol draft. The note should be clear in offering no guarantees in = terms of=20 backwards compatibility of the RFC spec to those early-draft = implementations.=20 The note must also not be seen as passing a normative reference to the = early=20 protocol draft.

- Along with the above = note, the=20 existing GSMP/ANCP version negotiation mechanisms could be = highlighted,=20 indicating that it provides a way to distinguish between the different = versions if the adjacency establishment negotiation mechanism followed = by all=20 is as per GSMPv3 (rfc3292).

- For the sake of = clarity it is=20 recommended that the adjacency negotiation be more fully described in = the ANCP=20 protocol draft instead of the current reference to rfc3292. = Specifically, it=20 would appear reasonable to adopt and re-edit Section 11.2 of rfc3292 = into the=20 ANCP protocol spec, with the re-edit describing the version = negotiation=20 behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or=20 logic statements as to the expected behaviour in case of version = differences,=20 but such text is in evidence in the descriptive part of Section=20 11.1.

- The WG = should=20 identify what version of the ANCP protocol draft specification = constitutes=20 v3.1. A non-normative reference to such a reference could be passed in = the=20 v3.2 spec.

Rationale

From a technical point = of view,=20 given that a "current" (i.e.=20 draft-ietf-protocol-06 based) and = future (i.e. ANCP RFC based) protocols are identical, = with any newly added functions=20 covered as=20 negotiable capabilities, = the=20 version change does=20 not appear to be=20 fully warranted=20 and not fully in line with the guidelines previously laid down=20 (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from = an=20 operational = perspective a reasonable = case for=20 such=20 a version change has made based and presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm. =

Now,=20 given that normative = compliance to=20 an interim draft (such=20 as draft-ietf-protocol-06=20 based) cannot be=20 passed by the ANCP RFC, text which may=20 be perceived as = mandating or=20 claiming compatibility to such  interim drafts needs = to be=20 avoided.

In the case of vendors and operators = that already support/use v3.1 = and have=20 plans for v3.2, the version negotiation mechanism that ANCP inherited = from=20 GSMPv3 provides a way to disambiguate the two protocols and thus allows in theory for supporting running a pre-standard (v3.1) = and a=20 standards compliant v3.2 on any given ANCP node. The issue of where v3.1 is documented can be = solved by=20 using non-normative references to one of the interim drafts. The issue = of what=20 rev of draft-ietf-ancp is considered to be v3.1 needs to be=20 clarified.

Other than the above the = WG is=20 currently not chartered to=20 be extending the protocol spec to cover issues around = protocol=20 version negotiation or remediation of incompatibilities of draft=20 implementations. As = such no such=20 work is expected.

We welcome = clarification questions on the above. =

Regards, =
Wojciech & = Matthew.

Questo = messaggio e i suoi=20 allegati sono indirizzati esclusivamente alle persone indicate. = La=20 diffusione, copia o qualsiasi altra azione derivante dalla = conoscenza di=20 queste informazioni sono rigorosamente vietate. Qualora abbiate = ricevuto=20 questo documento per errore siete cortesemente pregati di darne=20 immediata comunicazione al mittente e di provvedere alla sua=20 distruzione, Grazie.

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the = addressee(s)=20 only. Dissemination, copying, printing or use by anybody else is = unauthorised. If you are not the intended recipient, please = delete this=20 message and any attachments and advise the sender by return = e-mail,=20 Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa mail se non = =E8=20 necessario.=20

------_=_NextPart_002_01CA58C7.FB165D63-- ------_=_NextPart_001_01CA58C7.FB165D63 Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <010283918@29102009-2384> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA58C7.FB165D63-- From Lothar.Reith@detecon.com Fri Oct 30 09:16:55 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E7F3A68AB for ; Fri, 30 Oct 2009 09:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXZLheX2uyun for ; Fri, 30 Oct 2009 09:16:53 -0700 (PDT) Received: from dtc035.detecon.net (dtc035.detecon.net [194.25.60.135]) by core3.amsl.com (Postfix) with ESMTP id 24C003A682A for ; Fri, 30 Oct 2009 09:16:50 -0700 (PDT) Received: from unknown (HELO dc00356.detecon.com) ([172.16.10.106]) by relay.dtc035.detecon.net with ESMTP; 30 Oct 2009 17:16:56 +0100 Received: from DC00331.detecon.com ([172.16.10.78]) by dc00356.detecon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 17:16:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA597C.6602C444" Date: Fri, 30 Oct 2009 17:16:50 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FAACxIQTA= References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local><5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> From: "Reith, Lothar" To: "Wojciech Dec \(wdec\)" , "Haag, Thomas" , , , , , , , , "Paul, Manuel" , "Witschurke, Birgit" X-OriginalArrivalTime: 30 Oct 2009 16:16:56.0631 (UTC) FILETIME=[66A3D470:01CA597C] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:16:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA597C.6602C444 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA597C.6602C444" ------_=_NextPart_002_01CA597C.6602C444 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, dear all, =20 I fully support Thomas Haag`s point in his mail. =20 I also noticed that the following section is no longer present in the = current version, and propose to re-include: =20 Partition ID: This field is a 8 bit number which signifies a partition on the AN. [ TBD How AN and NAS agree on the partition numbers. Possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information.] =20 =20 I further suggest to enhance the text as follows: =20 Partition ID: This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information. =20 =20 A potential use case could be in assurance, e.g. to enable verification = that the proper (intended) partition ID is used over a particular = adjacency in cases where the AN has multiple adjacencies to different = NAS/Controller.=20 =20 Best Regards, Lothar Reith =20 Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Donnerstag, 29. Oktober 2009 19:45 An: Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 While keeping the GSMP derived partition-id in the protocol spec "as = is" is fine, a note should perhaps also be inserted stating that this = field is effectively not currently used by ANCP. At least this is my = recollection of the discussion on this matter, ie partition-id is fine, = but we don't really have a use for it now given that functional = partitioning is not covered and that an AN will have 1 adjacency to each = NAS/controller. =20 -Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID =09 =09 Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding = versioning, tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces = extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 =09 So we had consensus not to remove and keep partion ID. But I didn't = find it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there = any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting = keeping partition ID. =20 Regards =20 Thomas .=20 =20 ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps =09 =09 Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end = of section 2:=20 "At the time of writing of this specification some implementations of = the ANCP protocol, based on pre-standards drafts are already available. = All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed = from 1 to 2 upon publication.] Adopting a new sub-version value = provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP = implementation on any given ANCP node. The mechanism used to identify the = protocol version/sub-version is part of the adjacency negotiation process = and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of = the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in section = 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 = upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the = highest version understood by the sender. A receiver receiving a SYN = message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in = the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions of = the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document = may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is = part of the adjacency protocol and is performed before synchronisation = is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or = if you have additional comments please let me know. =20 Best Regards, Roberta =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the time = of publishing as an RFC. An instruction to execute such a change should = be placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an = appropriate section, possibly Section 2 or Section 5, to convey in-brief = the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version = negotiation mechanisms could be highlighted, indicating that it provides = a way to distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html = ). = That said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm = .=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and = have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending = the protocol spec to cover issues around protocol version negotiation or = remediation of incompatibilities of draft implementations. As such no = such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 ------_=_NextPart_002_01CA597C.6602C444 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP = Versioning - next steps
Hi Woj, = dear=20 all,
 
I fully support Thomas Haag`s point in his=20 mail.
 
I also noticed that the following section is no = longer=20 present in the current version, and propose to = re-include:
 
Partition=20 ID:

      This field is a 8 bit number = which=20 signifies a partition on the
      AN. [ TBD = How AN=20 and NAS agree on the partition numbers. =20 Possible
     =20 options:

      1 - The partition ID = could be=20 configured on the AN and learnt by
      NAS = in the=20 adjacency message;

      2 - The = partition ID=20 could be statically configured on the NAS = as
     =20 part of configuring the neighbor information.]
 
 
I further suggest to enhance the text as=20 follows:
 
Partition=20 ID:

      This field is a 8 bit number = which=20 signifies a partition on the
      AN.  = AN and=20 NAS MAY agree on the partition ID using one of the=20 following possible
     =20 options:

      1 - The partition ID = could be=20 configured on the AN and learnt by
      NAS = in the=20 adjacency message;

      2 - The = partition ID=20 could be statically configured on the NAS = as
     =20 part of configuring the neighbor information.
 
 
A potential use case could be in assurance,=20 e.g. to enable verification that the proper = (intended) partition ID is=20 used over a particular adjacency in cases where the AN has = multiple=20 adjacencies to different NAS/Controller. 
 
 Best Regards, Lothar = Reith
 
Detecon International GmbH (Deutsche Telekom=20 Group)

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Donnerstag, 29. Oktober 2009 = 19:45
An:=20 Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Betreff: Re: [ANCP] ANCP Versioning - = next steps;=20 partition ID

While keeping the GSMP derived partition-id in the = protocol spec=20 "as is" is fine, a note should perhaps also be inserted stating that = this=20 field is effectively not currently used by ANCP. At least this is my=20 recollection of the discussion on this matter, ie partition-id is = fine, but we=20 don't really have a use for it now given that functional partitioning = is not=20 covered and that an AN will have 1 adjacency to each=20 NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009=20 15:52
To: roberta.maglione@telecomitalia.it; Wojciech Dec = (wdec);=20 ancp@ietf.org; alan.kavanagh@ericsson.com; = Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Manuel.Paul@telekom.de;=20 B.Witschurke@telekom.de
Subject: AW: ANCP Versioning - = next steps;=20 partition ID

Hi Roberta, all,
 
thanks for providing the updated protocol=20 draft.
 
So far I recognized that the update covers = issues=20 regarding versioning, tech Type for GPON and Range of values of the = code=20 field.
 
But I notice on page 17 of version 07 that = the whole=20 section of partition ID including definition is = deleted.
From my understanding (and as = result from the=20 minutes) it was agreed during 75th IETF meeting to keep the = partition=20 ID.
 
Extract from 75th IETF minutes:=20
 
(1)=20 Partition-id
    ------------
Sanjay: concerned = that=20 removing the partition-id reduces extensibility.
Thomas Haag: = need=20 multiple partition-ids because one might need to distinguish =
between=20 BRASs when expanding the network.
Woj: send e-mail. Thomas: = already did.=20 Makes for operational problems
if partition-id not available. =
No one=20 felt strongly -- will keep "as is".
 
So we had consensus not to remove and = keep partion=20 ID. But I didn't find it in the whole document any = more.
Based on that agreements I wonder why this issue is = deleted. Are there any reasons for doing=20 this?
 
So I recommend update the protocol draft = before=20 upcoming meeting keeping partition ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Gesendet: = Montag, 19.=20 Oktober 2009 16:16
An: 'Wojciech Dec (wdec)'; = ancp@ietf.org; Haag,=20 Thomas; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; BOCCI Matthew;=20 'tom111.taylor@bell.net'
Betreff: RE: ANCP Versioning - = next=20 steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs=92 = recommendations on=20 the ANCP versioning.

In=20 particular:

  1. I added some text to = explain=20 the history and rationale, at the end of section=20 2:

 =93At the=20 time of writing of this specification some implementations of the = ANCP=20 protocol, based on pre-standards drafts are already available.  = All=20 these early-draft implementations use = protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be changed=20 from

  =20 1 to 2 upon publication.]  Adopting a new sub-version value=20 provides

  =20 a way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

  =20 on any given ANCP node.  The mechanism used to identify the=20 protocol

  =20 version/sub-version is part of the adjacency negotiation process=20 and

  =20 it is described in details in Section 5.2.  It is important to=20 note

  =20 that this mechanism does not guarantee backwards compatibility of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.=94

  1. I explained the=20 version/sub-version negotiation process in section = 5.2:=20

=93ANCP uses=20 version 3 and sub-version 1 of GSMP = protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 to 2=20 upon

  =20 publication.]  In the adjacency protocol the version and the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is achieved.  = In=20 a

  =20 SYN message the version/sub-version fields always contain the=20 highest

  =20 version understood by the sender.  A receiver receiving a SYN=20 message

  =20 with a version/sub-version higher than understood will ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its ANCP=20 version/sub-version fields.  This defines the = version/sub-version=20 of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed version = in=20 the

  =20 version/sub-version fields.=94

 

  1. I added a = non-normative=20 appendix. This appendix will = contain a=20 clarification of what version of the ANCP protocol draft = specification=20 constitutes version 3.1 as soon as the WG decides on=20 3.1=20

=936. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC versions of=20 the

  =20 protocol were documented and implemented.  There were numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

  =20 A NAS implementing the ANCP protocol as defined in this document=20 may,

  =20 on a peer basis, use the version and sub-version fields to detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work with=20 such

  =20 pre-RFC peers.  The version and sub-version negotiation phase = is=20 part

  =20 of the adjacency protocol and is performed before synchronisation=20 is

  =20 achieved.=94

 

Please = find new=20 version of draft attached.

I hope = I=92ve=20 captured most of your feedback in the new draft, if not or if you = have=20 additional comments please let me know.

 

Best=20 Regards,

Roberta

 

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf=20 Of Wojciech Dec (wdec)
Sent: Wednesday, October 14, = 2009 1:07=20 PM
To: = ancp@ietf.org
Subject: [ANCP] FW: ANCP = Versioning -=20 next steps

 

 

Hi = All,

During the ITEF75 WG = meeting a=20 discussion was had on ANCP protocol versioning and the need to = revise the=20 protocol version. A follow-up e-mail discussion on the WG alias took = place=20 and it seems appropriate now=20 (if not overdue) to draw up a set of recommendations = and=20 settle the issue:

Recommended protocol = draft changes and WG=20 actions=20

- The currently used = ANCP=20 version 3.1 is to change to 3.2 at the time of publishing as an RFC. = An=20 instruction to execute such a change should be placed as part of an = editors'=20 note in the next revision of draft-ietf-ancp-protocol. This = instruction is=20 expected to only come into effect at the time of final review past a = WG=20 last-call, which means that until then v3.1 will be in evidence. = Current=20 implementers should make a note of this = fact.

- Another note (not = editorial=20 though) should be placed in an appropriate section, possibly Section = 2 or=20 Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1=20 implementations, which are (were?) based on early versions of the = ANCP=20 protocol draft. The note should be clear in offering no guarantees = in terms=20 of backwards compatibility of the RFC spec to those early-draft=20 implementations. The note must also not be seen as passing a = normative=20 reference to the early protocol draft.

- Along with the above = note, the=20 existing GSMP/ANCP version negotiation mechanisms could be = highlighted,=20 indicating that it provides a way to distinguish between the = different=20 versions if the adjacency establishment negotiation mechanism = followed by=20 all is as per GSMPv3 (rfc3292).

- For the sake of = clarity it is=20 recommended that the adjacency negotiation be more fully described = in the=20 ANCP protocol draft instead of the current reference to rfc3292.=20 Specifically, it would appear reasonable to adopt and re-edit = Section 11.2=20 of rfc3292 into the ANCP protocol spec, with the re-edit describing = the=20 version negotiation behaviour. Rather confusingly Rfc3292 Section = 11.2 does=20 not carry text or logic statements as to the expected behaviour in = case of=20 version differences, but such text is in evidence in the descriptive = part of=20 Section 11.1.

- The WG = should=20 identify what version of the ANCP protocol draft specification = constitutes=20 v3.1. A non-normative reference to such a reference could be passed = in the=20 v3.2 spec.

Rationale

From a technical point = of view,=20 given that a "current" (i.e.=20 draft-ietf-protocol-06 based) and = future=20 (i.e.=20 ANCP RFC based) protocols are = identical, with=20 any=20 newly added functions=20 covered as=20 negotiable = capabilities, the=20 version change does = not appear to be=20 fully warranted and not = fully in line=20 with the guidelines previously laid down (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from = an=20 operational = perspective a = reasonable case=20 for such=20 a version change has made based and = presented in=20 https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm. =

Now,=20 given that normative = compliance=20 to an interim draft (such=20 as draft-ietf-protocol-06=20 based) cannot=20 be passed by the ANCP RFC, text which may=20 be perceived as = mandating or=20 claiming compatibility to such  interim drafts needs = to be=20 avoided.

In the case of vendors and operators = that already support/use = v3.1 and=20 have plans for v3.2, the version negotiation mechanism that ANCP = inherited=20 from GSMPv3 provides a way to disambiguate the two protocols and = thus allows in theory = for supporting running a pre-standard = (v3.1) and a=20 standards compliant v3.2 on any given ANCP node. The issue of where v3.1 is documented can be = solved by=20 using non-normative references to one of the interim drafts. The = issue of=20 what rev of draft-ietf-ancp is considered to be v3.1 needs to be=20 clarified.

Other than the above = the WG is=20 currently not chartered to=20 be extending the protocol spec to cover issues around = protocol=20 version negotiation or remediation of incompatibilities of draft=20 implementations. As = such no=20 such work is expected.

We = welcome=20 clarification questions on the above.=20

Regards, =
Wojciech & = Matthew.

Questo = messaggio e i=20 suoi allegati sono indirizzati esclusivamente alle persone = indicate.=20 La diffusione, copia o qualsiasi altra azione derivante dalla=20 conoscenza di queste informazioni sono rigorosamente vietate. = Qualora=20 abbiate ricevuto questo documento per errore siete = cortesemente=20 pregati di darne immediata comunicazione al mittente e di = provvedere=20 alla sua distruzione, Grazie.

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the = addressee(s)=20 only. Dissemination, copying, printing or use by anybody else = is=20 unauthorised. If you are not the intended recipient, please = delete=20 this message and any attachments and advise the sender by = return=20 e-mail, Thanks.

3D"rispettaRispetta l'ambiente. Non stampare questa mail se = non =E8=20 necessario.=20 =

= ------_=_NextPart_002_01CA597C.6602C444-- ------_=_NextPart_001_01CA597C.6602C444 Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <107244715@30102009-1DCF> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA597C.6602C444-- From wdec@cisco.com Fri Oct 30 10:19:13 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4262D3A67D1 for ; Fri, 30 Oct 2009 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.732 X-Spam-Level: X-Spam-Status: No, score=-8.732 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFsD3e85Hueg for ; Fri, 30 Oct 2009 10:19:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 868F73A67BD for ; Fri, 30 Oct 2009 10:19:08 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo Ambiente_foglia.jpg : 677 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIAAHC86kqQ/uCWe2dsb2JhbACCJiwhhFQ2k1gBARYkBq0fmC+COA+BdgSBYooe X-IronPort-AV: E=Sophos;i="4.44,654,1249257600"; d="jpg'147?scan'147,208,217,147";a="53234384" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2009 17:19:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UHJOYU009480; Fri, 30 Oct 2009 17:19:24 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 18:19:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5985.20786DD9" Date: Fri, 30 Oct 2009 18:19:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FAACxIQTAAAdj3kA== References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local><5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: "Reith, Lothar" , "Haag, Thomas" , , , , , , , , "Paul, Manuel" , "Witschurke, Birgit" X-OriginalArrivalTime: 30 Oct 2009 17:19:23.0947 (UTC) FILETIME=[2036DFB0:01CA5985] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 17:19:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5985.20786DD9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5985.20786DD9" ------_=_NextPart_002_01CA5985.20786DD9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lothar, =20 Having the NAS/controller verify the sender-name (as is done today), = with each partition using a different sender name, would accomplish the = use-case below, without partition-id. Any problem with this? =20 Thanks, Woj. =20 ________________________________ From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 30 October 2009 17:17 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Woj, dear all, =20 I fully support Thomas Haag`s point in his mail. =20 I also noticed that the following section is no longer present in the = current version, and propose to re-include: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on the AN. [ TBD How AN and NAS agree on the partition numbers. = Possible options: =09 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information.] =20 =20 I further suggest to enhance the text as follows: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: =09 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information. =20 =20 A potential use case could be in assurance, e.g. to enable verification = that the proper (intended) partition ID is used over a particular = adjacency in cases where the AN has multiple adjacencies to different = NAS/Controller.=20 =20 Best Regards, Lothar Reith =20 Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Donnerstag, 29. Oktober 2009 19:45 An: Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 While keeping the GSMP derived partition-id in the protocol spec "as = is" is fine, a note should perhaps also be inserted stating that this = field is effectively not currently used by ANCP. At least this is my = recollection of the discussion on this matter, ie partition-id is fine, = but we don't really have a use for it now given that functional = partitioning is not covered and that an AN will have 1 adjacency to each = NAS/controller. =20 -Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID =09 =09 Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding = versioning, tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces = extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems = if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 =09 So we had consensus not to remove and keep partion ID. But I didn't = find it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are = there any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting = keeping partition ID. =20 Regards =20 Thomas .=20 =20 ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps =09 =09 Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end = of section 2:=20 "At the time of writing of this specification some implementations = of the ANCP protocol, based on pre-standards drafts are already = available. All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed = from 1 to 2 upon publication.] Adopting a new sub-version value = provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP = implementation on any given ANCP node. The mechanism used to identify the = protocol version/sub-version is part of the adjacency negotiation process = and it is described in details in Section 5.2. It is important to = note that this mechanism does not guarantee backwards compatibility of = the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in section = 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 = upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the = highest version understood by the sender. A receiver receiving a SYN = message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in = the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions of = the protocol were documented and implemented. There were numerous = pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document = may, on a peer basis, use the version and sub-version fields to detect = a pre-RFC implementation of the protocol and choose to work with = such pre-RFC peers. The version and sub-version negotiation phase is = part of the adjacency protocol and is performed before synchronisation = is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not = or if you have additional comments please let me know. =20 Best Regards, Roberta =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the time = of publishing as an RFC. An instruction to execute such a change should = be placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an = appropriate section, possibly Section 2 or Section 5, to convey in-brief = the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version = negotiation mechanisms could be highlighted, indicating that it provides = a way to distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html = ). = That said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm = .=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 = and have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be = extending the protocol spec to cover issues around protocol version = negotiation or remediation of incompatibilities of draft = implementations. As such no such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 ------_=_NextPart_002_01CA5985.20786DD9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP = Versioning - next steps
Hi Lothar,
 
=20 Having the NAS/controller verify the sender-name (as is done today),=20 with each partition using a different sender name, would accomplish = the=20 use-case below, without partition-id. Any problem with = this?
 
Thanks,
Woj.
 

From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 30 October 2009=20 17:17
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Subject: AW: [ANCP] ANCP Versioning - = next steps;=20 partition ID

Hi Woj, = dear=20 all,
 
I fully support Thomas Haag`s point in his=20 mail.
 
I also noticed that the following section is = no longer=20 present in the current version, and propose to = re-include:
 
Partition=20 ID:

      This field is a 8 bit number = which=20 signifies a partition on the
      AN. [ = TBD How=20 AN and NAS agree on the partition numbers. =20 Possible
     =20 options:

      1 - The partition ID = could be=20 configured on the AN and learnt by
      = NAS in=20 the adjacency message;

      2 - The = partition=20 ID could be statically configured on the NAS=20 as
      part of configuring the neighbor=20 information.]
 
 
I further suggest to enhance the text as=20 follows:
 
Partition=20 ID:

      This field is a 8 bit number = which=20 signifies a partition on the
      = AN.  AN=20 and NAS MAY agree on the partition ID using one of the=20 following possible
     =20 options:

      1 - The partition ID = could be=20 configured on the AN and learnt by
      = NAS in=20 the adjacency message;

      2 - The = partition=20 ID could be statically configured on the NAS=20 as
      part of configuring the neighbor=20 information.
 
 
A potential use case could be in assurance, = e.g. to enable verification that the proper = (intended) partition ID=20 is used over a particular adjacency in cases where the AN = has=20 multiple adjacencies to different = NAS/Controller. 
 
 Best Regards, Lothar = Reith
 
Detecon International GmbH (Deutsche = Telekom=20 Group)

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Donnerstag, 29. Oktober 2009 = 19:45
An:=20 Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke, = Birgit
Betreff:=20 Re: [ANCP] ANCP Versioning - next steps; partition = ID

While keeping the GSMP derived partition-id in the = protocol spec=20 "as is" is fine, a note should perhaps also be inserted stating that = this=20 field is effectively not currently used by ANCP. At least this is my = recollection of the discussion on this matter, ie partition-id is = fine, but=20 we don't really have a use for it now given that functional = partitioning is=20 not covered and that an AN will have 1 adjacency to each=20 NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009=20 15:52
To: roberta.maglione@telecomitalia.it; Wojciech = Dec=20 (wdec); ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; B.Witschurke@telekom.de
Subject: = AW:=20 ANCP Versioning - next steps; partition ID

Hi Roberta, all,
 
thanks for providing the updated protocol = draft.
 
So far I recognized that the update = covers issues=20 regarding versioning, tech Type for GPON and Range of values of = the code=20 field.
 
But I notice on page 17 of version 07 = that the whole=20 section of partition ID including definition is=20 deleted.
From my understanding (and as = result from the=20 minutes) it was agreed during 75th IETF meeting to keep the = partition=20 ID.
 
Extract from 75th IETF minutes:=20
 
(1)=20 Partition-id
    ------------
Sanjay: = concerned that=20 removing the partition-id reduces extensibility.
Thomas Haag: = need=20 multiple partition-ids because one might need to distinguish =
between=20 BRASs when expanding the network.
Woj: send e-mail. Thomas: = already=20 did. Makes for operational problems
if partition-id not = available.=20
No one felt strongly -- will keep "as is".
 
So we had consensus not to remove = and keep=20 partion ID. But I didn't find it in the whole document any=20 more.
Based on that agreements I wonder why this issue is = deleted. Are there any reasons for doing=20 this?
 
So I recommend update the protocol draft = before=20 upcoming meeting keeping partition ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Gesendet: = Montag,=20 19. Oktober 2009 16:16
An: 'Wojciech Dec (wdec)'; = ancp@ietf.org;=20 Haag, Thomas; alan.kavanagh@ericsson.com; = Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; BOCCI Matthew;=20 'tom111.taylor@bell.net'
Betreff: RE: ANCP Versioning - = next=20 steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs=92 = recommendations on=20 the ANCP versioning.

In=20 particular:

  1. I added some text = to explain=20 the history and rationale, at the end of section=20 2:

 =93At the=20 time of writing of this specification some implementations of the = ANCP=20 protocol, based on pre-standards drafts are already = available.  All=20 these early-draft implementations use=20 protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be changed=20 from

  =20 1 to 2 upon publication.]  Adopting a new sub-version value=20 provides

  =20 a way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

  =20 on any given ANCP node.  The mechanism used to identify the=20 protocol

  =20 version/sub-version is part of the adjacency negotiation process=20 and

  =20 it is described in details in Section 5.2.  It is important = to=20 note

  =20 that this mechanism does not guarantee backwards compatibility of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.=94

  1. I explained the=20 version/sub-version negotiation process in section=20 5.2:=20

=93ANCP=20 uses version 3 and sub-version 1 of GSMP=20 protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 to 2=20 upon

  =20 publication.]  In the adjacency protocol the version and the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is achieved.  = In=20 a

  =20 SYN message the version/sub-version fields always contain the=20 highest

  =20 version understood by the sender.  A receiver receiving a SYN = message

  =20 with a version/sub-version higher than understood will ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its ANCP=20 version/sub-version fields.  This defines the = version/sub-version=20 of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed version = in=20 the

  =20 version/sub-version fields.=94

 

  1. I added a = non-normative=20 appendix. This appendix will = contain a=20 clarification of what version of the ANCP protocol draft = specification=20 constitutes version 3.1 as soon as the WG decides on=20 3.1=20

=936. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC versions of=20 the

  =20 protocol were documented and implemented.  There were = numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

  =20 A NAS implementing the ANCP protocol as defined in this document=20 may,

  =20 on a peer basis, use the version and sub-version fields to detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work with=20 such

  =20 pre-RFC peers.  The version and sub-version negotiation phase = is=20 part

  =20 of the adjacency protocol and is performed before synchronisation=20 is

  =20 achieved.=94

 

Please = find new=20 version of draft attached.

I hope = I=92ve=20 captured most of your feedback in the new draft, if not or if you = have=20 additional comments please let me = know.

 

Best=20 Regards,

Roberta

 

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On=20 Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, October = 14, 2009=20 1:07 PM
To:=20 ancp@ietf.org
Subject: [ANCP] FW: ANCP = Versioning -=20 next steps

 

 

Hi = All,

During the ITEF75 WG = meeting a=20 discussion was had on ANCP protocol versioning and the need to = revise the=20 protocol version. A follow-up e-mail discussion on the WG alias = took place=20 and it seems appropriate now=20 (if not overdue) to draw up a set of recommendations = and=20 settle the issue:

Recommended protocol = draft=20 changes and WG=20 actions=20

- The currently used = ANCP=20 version 3.1 is to change to 3.2 at the time of publishing as an = RFC. An=20 instruction to execute such a change should be placed as part of = an=20 editors' note in the next revision of draft-ietf-ancp-protocol. = This=20 instruction is expected to only come into effect at the time of = final=20 review past a WG last-call, which means that until then v3.1 will = be in=20 evidence. Current implementers should make a note of this=20 fact.

- Another note (not = editorial=20 though) should be placed in an appropriate section, possibly = Section 2 or=20 Section 5, to convey in-brief the historic aspect of GSMP/ANCP = v3.1=20 implementations, which are (were?) based on early versions of the = ANCP=20 protocol draft. The note should be clear in offering no guarantees = in=20 terms of backwards compatibility of the RFC spec to those = early-draft=20 implementations. The note must also not be seen as passing a = normative=20 reference to the early protocol draft. =

- Along with the = above note,=20 the existing GSMP/ANCP version negotiation mechanisms could be=20 highlighted, indicating that it provides a way to distinguish = between the=20 different versions if the adjacency establishment negotiation = mechanism=20 followed by all is as per GSMPv3 = (rfc3292).

- For the sake of = clarity it=20 is recommended that the adjacency negotiation be more fully = described in=20 the ANCP protocol draft instead of the current reference to = rfc3292.=20 Specifically, it would appear reasonable to adopt and re-edit = Section 11.2=20 of rfc3292 into the ANCP protocol spec, with the re-edit = describing the=20 version negotiation behaviour. Rather confusingly Rfc3292 Section = 11.2=20 does not carry text or logic statements as to the expected = behaviour in=20 case of version differences, but such text is in evidence in the=20 descriptive part of Section 11.1.

- The = WG should=20 identify what version of the ANCP protocol draft specification = constitutes=20 v3.1. A non-normative reference to such a reference could be = passed in the=20 v3.2 spec.

Rationale

From a technical = point of=20 view, given that a "current" (i.e.=20 draft-ietf-protocol-06 based) = and future=20 (i.e.=20 ANCP RFC based) = protocols are=20 identical, with any=20 newly added functions covered as negotiable = capabilities, the=20 version change = does=20 not appear to be fully=20 warranted and not = fully in=20 line with the guidelines previously laid down (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from = an=20 operational = perspective a = reasonable case=20 for such=20 a version change = has=20 made based and = presented in=20 https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm.=20

Now,=20 given that normative = compliance=20 to an interim draft (such=20 as draft-ietf-protocol-06=20 based) cannot be passed by = the ANCP=20 RFC, text which may=20 be perceived as = mandating or=20 claiming compatibility to such  interim drafts = needs to be=20 avoided.

In the case of vendors and = operators that=20 already support/use = v3.1 and=20 have plans for v3.2, the version negotiation mechanism that ANCP = inherited=20 from GSMPv3 provides a way to disambiguate the two protocols and = thus=20 allows in theory = for supporting running a pre-standard = (v3.1) and a=20 standards compliant v3.2 on any given ANCP node. The issue of where v3.1 is documented can = be solved=20 by using non-normative references to one of the interim drafts. = The issue=20 of what rev of draft-ietf-ancp is considered to be v3.1 needs to = be=20 clarified.

Other than the above = the WG is=20 currently not chartered to=20 be extending the protocol spec to cover issues = around=20 protocol version negotiation or remediation of incompatibilities = of draft=20 implementations. = As such no=20 such work is expected.

We = welcome=20 clarification questions on the above.=20

Regards,=20
Wojciech & = Matthew.

Questo = messaggio e i=20 suoi allegati sono indirizzati esclusivamente alle persone = indicate.=20 La diffusione, copia o qualsiasi altra azione derivante = dalla=20 conoscenza di queste informazioni sono rigorosamente = vietate.=20 Qualora abbiate ricevuto questo documento per errore siete=20 cortesemente pregati di darne immediata comunicazione al = mittente e=20 di provvedere alla sua distruzione, Grazie. =

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the = addressee(s)=20 only. Dissemination, copying, printing or use by anybody = else is=20 unauthorised. If you are not the intended recipient, please = delete=20 this message and any attachments and advise the sender by = return=20 e-mail, Thanks. =

3D"rispettaRispetta l'ambiente. Non stampare questa mail se = non =E8=20 necessario.=20 =

<= /BODY> ------_=_NextPart_002_01CA5985.20786DD9-- ------_=_NextPart_001_01CA5985.20786DD9 Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <144184016@30102009-238B> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA5985.20786DD9-- From wdec@cisco.com Fri Oct 30 11:33:03 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090B03A68DD for ; Fri, 30 Oct 2009 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.957 X-Spam-Level: X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifa0KGUElOaQ for ; Fri, 30 Oct 2009 11:33:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B63A03A6917 for ; Fri, 30 Oct 2009 11:33:01 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkAAP/N6kqQ/uCWe2dsb2JhbACbVgEBFiQGrGSYOYQ9BIFi X-IronPort-AV: E=Sophos;i="4.44,655,1249257600"; d="scan'208";a="53239327" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2009 18:33:17 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UIXHhd025432 for ; Fri, 30 Oct 2009 18:33:17 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 19:33:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 19:33:13 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF76 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNgA59idbA= References: From: "Wojciech Dec (wdec)" To: "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 30 Oct 2009 18:33:17.0592 (UTC) FILETIME=[72DF6980:01CA598F] Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:33:03 -0000 Hi All, So far the agenda looks as follows: - TR-147 gaps ; Hongyu Li - ANCP Restart ; Shridhar Rao - ancp-mc-extensions ; Francois Le Faucheur Did we miss anyone's request? Thanks, Woj. =20 > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On=20 > Behalf Of Wojciech Dec (wdec) > Sent: 12 October 2009 09:58 > To: ancp@ietf.org > Subject: [ANCP] Agenda items for IETF76 ANCP WG meeting >=20 > Hi All, >=20 >=20 > We're taking requests for agenda slots at our next ANCP WG=20 > meeting in Hiroshima. Please respond with any requests. >=20 > Thanks, > Matthew & Woj >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp >=20