From cheshire@apple.com Wed Sep 1 10:32:58 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEE83A69C6 for ; Wed, 1 Sep 2010 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.202 X-Spam-Level: X-Spam-Status: No, score=-105.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 cgNb7wTPi0+w for ; Wed, 1 Sep 2010 10:32:55 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 6D9AA3A6830 for ; Wed, 1 Sep 2010 10:32:55 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id DADF7A59D9AD for ; Wed, 1 Sep 2010 10:33:25 -0700 (PDT) X-AuditID: 11807136-b7b3eae0000066cf-78-4c7e8e6518e1 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 4C.3C.26319.56E8E7C4; Wed, 1 Sep 2010 10:33:25 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9el8+SB8QeeLtxv7XFQudg)" Received: from [10.33.60.140] (166-205-136-211.mobile.mymmode.com [166.205.136.211]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8200CDGWRMEB50@elliott.apple.com> for port-srv-reg@ietf.org; Wed, 01 Sep 2010 10:33:25 -0700 (PDT) References: In-reply-to: Message-id: <182E1BE4-C808-4884-B798-7876AF350813@apple.com> X-Mailer: iPhone Mail (8A400) From: Stuart Cheshire Date: Wed, 01 Sep 2010 10:33:50 -0700 To: Michelle Cotton X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 17:32:59 -0000 --Boundary_(ID_9el8+SB8QeeLtxv7XFQudg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable On Aug 31, 2010, at 11:33, Michelle Cotton wrote= : > I=E2=80=99ll be working with Mark McFadden this afternoon on getting the I= ANA updates in the document. >=20 > Thanks, >=20 > Michelle Are all those changes checked into the svn repository now? Stuart --Boundary_(ID_9el8+SB8QeeLtxv7XFQudg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
On Aug 31, 2010, at 11:33, Michelle Cotton <michelle.cotton@icann.org> wrote:

I’ll be working with Mark McFadden this afternoon on getting the IANA updates in the document.

Thanks,

Michelle

Are all those changes checked into the svn repository now?

Stuart

--Boundary_(ID_9el8+SB8QeeLtxv7XFQudg)-- From michelle.cotton@icann.org Wed Sep 1 10:53:34 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189713A689B for ; Wed, 1 Sep 2010 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.126 X-Spam-Level: X-Spam-Status: No, score=-106.126 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 w7jPhTHvVKBP for ; Wed, 1 Sep 2010 10:53:27 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 9E85B3A690F for ; Wed, 1 Sep 2010 10:53:03 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 1 Sep 2010 10:53:34 -0700 From: Michelle Cotton To: Stuart Cheshire Date: Wed, 1 Sep 2010 10:53:32 -0700 Thread-Topic: [port-srv-reg] we need to make progress Thread-Index: ActJ/kqamYNVut72TzaigzQpD2/OoAAAEzCo Message-ID: In-Reply-To: <182E1BE4-C808-4884-B798-7876AF350813@apple.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8A3E12C28154michellecottonicannorg_" MIME-Version: 1.0 Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 17:53:34 -0000 --_000_C8A3E12C28154michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark will be adding them today or tomorrow. He'll confirm with the port-srv-reg list when completed. Thanks, Michelle On 9/1/10 10:33 AM, "Stuart Cheshire" wrote: On Aug 31, 2010, at 11:33, Michelle Cotton wrot= e: I'll be working with Mark McFadden this afternoon on getting the IANA updat= es in the document. Thanks, Michelle Are all those changes checked into the svn repository now? Stuart --_000_C8A3E12C28154michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [port-srv-reg] we need to make progress Mark will be adding them today or tomorrow.
He’ll confirm with the port-srv-reg list when completed.

Thanks,

Michelle



On 9/1/10 10:33 AM, "Stuart Cheshire" <cheshire@apple.com> wrote:

On Aug 31, 2010, at 11:33, Michelle Cotton = <michelle.cotton@icann.org>= wrote:

I’ll be working with Mark McFadden th= is afternoon on getting the IANA updates in the document.

Thanks,

Michelle
Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 18:58:07 -0000 Stuart: I've got the changes ready to go, but when I try to commit them, the svn se= rver won't accept my authentication credential. It's supposed to just be y= our IETF tools pages login, right? mark Mark McFadden mark.mcfadden@icann.org IANA Resource Specialist ________________________________________ From: port-srv-reg-bounces@ietf.org [port-srv-reg-bounces@ietf.org] On Beha= lf Of Stuart Cheshire [cheshire@apple.com] Sent: Wednesday, September 01, 2010 12:33 PM To: Michelle Cotton Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress On Aug 31, 2010, at 11:33, Michelle Cotton > wrote: I=92ll be working with Mark McFadden this afternoon on getting the IANA upd= ates in the document. Thanks, Michelle Are all those changes checked into the svn repository now? Stuart From cheshire@apple.com Thu Sep 2 23:49:20 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298363A67F6 for ; Thu, 2 Sep 2010 23:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 27+Y87Wx3a8S for ; Thu, 2 Sep 2010 23:49:18 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 008353A67E3 for ; Thu, 2 Sep 2010 23:49:17 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id C49F5A5F82F8 for ; Thu, 2 Sep 2010 23:49:47 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-38-4c809a8b7a49 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id 57.5C.22738.B8A908C4; Thu, 2 Sep 2010 23:49:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.99.3] (208-106-97-96.dsl.static.sonic.net [208.106.97.96]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8500FF2SAZLZ80@elliott.apple.com> for port-srv-reg@ietf.org; Thu, 02 Sep 2010 23:49:47 -0700 (PDT) From: Stuart Cheshire In-reply-to: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> Date: Thu, 02 Sep 2010 23:49:47 -0700 Message-id: <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> To: port-srv-reg@ietf.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 06:49:20 -0000 On 26 Aug 2010, at 2:53, Lars Eggert wrote: > Hi, > > in Maastricht, both Stuart and Michelle/Pearl said they had pending changes against -5 (or even -04). > > Can you all please edit them into the XML on our subversion server ASAP, so we know what they are? > > This document needs to get published. I just checked in a bunch of minor grammatical fixes and wordsmithing, which is great. Unfortunately, what concerns me is that since the last time I looked at this document a while ago, a bunch of new text has been added, much of which makes no sense to me. Just when I thought we were close to being finished we seem to be going backwards. If we keep adding bad text we're never going to finish. I'll include the text blocks in question below. What I request is that, unless someone can explain clearly what they mean and why they have to be there, they should be deleted, and then we can be finished. For each service name, there may exist zero or more associated port number assignments. A port number assignment associated with a service name contains the transport protocol, port number and possibly additional data, such as a DCCP Service Code. This implies that a given service name can have *different* port numbers assigned for different transport protocols. If we really want that then a lot of the rest of the document will have to change too. I propose we just delete it. For aliases that do not indicate a primary alias, a server is expected to register itself under all aliased service names. This is a terrible idea. Why do we want to advocate that? For aliases that do not indicate a primary alias they just can't do service discovery until the developers make up their minds and pick a primary. (And in any case, I think it's a moot point. How many aliases do we actually have in reality?) If the registration request is for a service name alias (see ), IANA needs to confirm with the administrative contact for the existing service name whether the registration of the alias is appropriate. This is a worse idea. We should not be allowing registration of new alias names at all. The service name syntax MAY be used to validate a service name string, but MUST NOT be used for any other purpose (e.g., delineation). Any system that includes a service name inside a longer string is itself responsible for delineating the service name. Such systems MUST NOT rely on the syntax of a service name alone for such delineation. I have no idea what that is talking about. It gives the sense of referring to something in particular, but doesn't actually say what. Regardless, I did my PhD in message framing and the syntax of marking boundaries, and I know of no basis for the claim that paragraph is making. SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) / (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM)) ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN = %x2d ; "-" ALPHA = DIGIT = Why do we have BNF in this document? It's certainly a lot less clear than the plain-English explanation. It's also wrong. I found at least one class of strings that it allows that the plain-English rules do not, and it prohibits at least one class of strings that the plain-English rules allow. The fact that no one else noticed this just proves my point that BNF is impenetrable to normal human beings and almost no one can read that BNF description and understand it. We should delete it. The details of how applications make use of DNS SRV should be specified in the documentation set of the application/service. In the absence of such specification, prospective clients of a given service should not assume the existence of SRV RRs for this service or, if they have indications that this will be the case (e.g., by configuration), must assume the unextended naming scheme from for service discovery with DNS SRV, i.e., the Service Label is constructed from the Service Name registered in by prepending a single underscore character ("_"). This is nonsense and must go. What is "the unextended naming scheme"? There's no mention in RFC 2782 of "extended" or "unextended" naming. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Fri Sep 3 00:16:15 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B653A6807 for ; Fri, 3 Sep 2010 00:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.855 X-Spam-Level: X-Spam-Status: No, score=-105.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DUTVKzKzAFIe for ; Fri, 3 Sep 2010 00:16:05 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 8F0AC3A67FD for ; Fri, 3 Sep 2010 00:16:04 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 1D29EACF4B15 for ; Fri, 3 Sep 2010 00:16:26 -0700 (PDT) X-AuditID: 11807137-b7b43ae00000547d-80-4c80a0c9f605 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay16.apple.com (Apple SCV relay) with SMTP id 65.47.21629.9C0A08C4; Fri, 3 Sep 2010 00:16:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.99.3] (208-106-97-96.dsl.static.sonic.net [208.106.97.96]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L850049UTJD85B0@et.apple.com> for port-srv-reg@ietf.org; Fri, 03 Sep 2010 00:16:25 -0700 (PDT) From: Stuart Cheshire In-reply-to: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> Date: Fri, 03 Sep 2010 00:16:25 -0700 Message-id: <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> To: port-srv-reg@ietf.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Subject: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 07:16:19 -0000 I have four final points for discussion 1. Name of the Registry Right now the document calls it: Transport Protocol Port Number and Service Name Registry However, Section 5 says: Service names are the unique key in the Port and Service Name registry. Since Service names really are the primary identifier, and the port number is optional, and we expect to see more and more registrations without port numbers, would it make sense to switch the order of the words, and make it: Registry of Service Names and Transport Protocol Port Numbers 2. Service Name Rules I liked Joe's earlier suggestion to disallow all-numeric service names, to avoid service names that look like a numeric port number. However, even with that rule, we still allow service names like this: "6000-6063" (looks like the X Window System port range). Do we care? We could prevent that by requiring that all service names contain at least one alphabetic character. 3. Inconsistent terminology. We use the term "Registered Ports" in some places to mean "ports in the range 1024-49151", and in other places to mean any "port recorded by IANA in the Registry". For example, the first meaning: the Well Known Ports, also known as the System Ports, from 0-1023 (assigned by IANA) the Registered Ports, also known as the User Ports, from 1024-49151 (assigned by IANA) the Dynamic Ports, also known as the Private Ports, from 49152-65535 (never assigned) and now the second: It is important to note that ownership of registered port numbers and service names remains with IANA. For protocols developed by IETF working Thousands of applications and application-level protocols have registered ports and service names for their use, and there is every reason to believe that this trend will continue into the future. Would it be better to strictly use the terms "System Ports" and "User Ports" to denote the ranges, and keep the term "registered port" to just mean generically, "recorded by IANA in the Registry"? 4. Aliases The document says: IANA is also instructed to indicate which service name aliases in the existing registry are the primary aliases (see ). Why should we burden IANA with this decision making? I bet there aren't that many. Let's just work it out ourselves, and list them in the document. I'll grep the IANA ports page and send a followup email with the list of aliased names. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Fri Sep 3 00:27:09 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF7E3A6804 for ; Fri, 3 Sep 2010 00:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OYFuuYdl64rO for ; Fri, 3 Sep 2010 00:27:07 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 759A43A67FD for ; Fri, 3 Sep 2010 00:27:07 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 64F88A5F9903 for ; Fri, 3 Sep 2010 00:27:37 -0700 (PDT) X-AuditID: 11807134-b7cacae0000058e0-d2-4c80a3697dfd Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 67.84.22752.963A08C4; Fri, 3 Sep 2010 00:27:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.99.3] (208-106-97-96.dsl.static.sonic.net [208.106.97.96]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L85004CXU2085B0@et.apple.com> for port-srv-reg@ietf.org; Fri, 03 Sep 2010 00:27:37 -0700 (PDT) From: Stuart Cheshire In-reply-to: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> Date: Fri, 03 Sep 2010 00:27:37 -0700 Message-id: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> To: port-srv-reg@ietf.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Subject: [port-srv-reg] Aliased service names X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 07:27:09 -0000 Below is the list of every service I found where more than one name is listed for a port number. In most cases I believe these are *not* aliases. They're two different services inadvertently colliding on the port number. The service names are *not* aliases of each other in these cases because they're not the same service. In this whole list I only see four names that look like aliases to me: "name" looks like an alias for "nameserver". "www" and "www-http" are aliases for "http". "auth" may be an alias for "ident". So it looks like we have a total of THREE service names that have aliases. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org -- List of aliased service names: name 42/tcp Host Name Server nameserver 42/tcp Host Name Server http 80/tcp World Wide Web HTTP www 80/tcp World Wide Web HTTP www-http 80/tcp World Wide Web HTTP cso 105/tcp CCSO name server protocol csnet-ns 105/tcp Mailbox Name Nameserver ident 113/tcp auth 113/tcp Authentication Service comsat 512/udp biff 512/udp used by mail system to notify users mdqs 666/tcp doom 666/tcp doom Id Software loadav 750/udp kerberos-iv 750/udp kerberos version iv accessbuilder 888/tcp AccessBuilder cddbp 888/tcp CD Database Protocol orasrv 1525/tcp oracle prospero-np 1525/tcp Prospero Directory Service non-priv tr-rsrb-p3 1989/tcp cisco RSRB Priority 3 port mshnet 1989/tcp MHSnet system stun-p3 1992/tcp cisco STUN Priority 3 port ipsendmsg 1992/tcp IPsendmsg hbci 3000/tcp HBCI remoteware-cl 3000/tcp RemoteWare Client exlm-agent 3002/tcp EXLM Agent remoteware-srv 3002/tcp RemoteWare Server stun 3478/udp Session Traversal Utilities for NAT (STUN) port turn 3478/udp TURN over UDP stun-behavior 3478/udp STUN Behavior Discovery over UDP stun 3478/tcp Session Traversal Utilities for NAT (STUN) port turn 3478/tcp TURN over TCP stun-behavior 3478/tcp STUN Behavior Discovery over TCP krb524 4444/tcp KRB524 nv-video 4444/tcp NV Video default stuns 5349/tcp STUN over TLS turns 5349/tcp TURN over TLS stun-behaviors 5349/tcp STUN Behavior Discovery over TLS hp-pdl-datastr 9100/tcp PDL Data Streaming Port pdl-datastream 9100/tcp Printer PDL Data Stream From lars.eggert@nokia.com Fri Sep 3 01:15:28 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8183A681F for ; Fri, 3 Sep 2010 01:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.625 X-Spam-Level: X-Spam-Status: No, score=-103.625 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 IUT3Lsdk2tRP for ; Fri, 3 Sep 2010 01:15:12 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id DAD133A682C for ; Fri, 3 Sep 2010 01:15:02 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o838FS1S017776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2010 11:15:28 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-118-251842425; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> Date: Fri, 3 Sep 2010 11:15:20 +0300 Message-Id: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> To: Stuart Cheshire X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 08:15:29 -0000 --Apple-Mail-118-251842425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-9-3, at 9:49, Stuart Cheshire wrote: > Unfortunately, what concerns me is that since the last time I looked = at this document a while ago, a bunch of new text has been added, much = of which makes no sense to me. Just when I thought we were close to = being finished we seem to be going backwards. If we keep adding bad text = we're never going to finish. it was probably me who added that text, based on the notes from Anaheim. = Sorry if I messed up. > I'll include the text blocks in question below. What I request is = that, unless someone can explain clearly what they mean and why they = have to be there, they should be deleted, and then we can be finished. >=20 > For each service name, there may exist zero or more associated = port > number assignments. A port number assignment associated with a = service > name contains the transport protocol, port number and possibly = additional > data, such as a DCCP Service Code. >=20 > This implies that a given service name can have *different* port = numbers assigned for different transport protocols. If we really want = that then a lot of the rest of the document will have to change too. I = propose we just delete it. Agreed. > For aliases that do not indicate a primary alias, a server is = expected > to register itself under all aliased service names. >=20 > This is a terrible idea. Why do we want to advocate that? For aliases = that do not indicate a primary alias they just can't do service = discovery until the developers make up their minds and pick a primary. = (And in any case, I think it's a moot point. How many aliases do we = actually have in reality?) General comment: This entire text on aliases is new, and I was not = extremely happy even when I wrote it, because it seemed so clumsy. I'm = VERY OPEN for a different way of addressing aliases. Like not permitting = them for the future and only acknowledge that there are a few existing = legacy ones. Specifically for the issue you mention above, are we going to handle = "www" and its aliases? If a web server doesn't register all aliases, it = cannot be found by clients that e.g. look up "http". > If the registration request is for a service name alias (see = target=3D"srvname"/>), IANA needs to confirm with the = administrative > contact for the existing service name whether the registration = of the > alias is appropriate. >=20 > This is a worse idea. We should not be allowing registration of new = alias names at all. I'm fine with not allowing aliases going forward. > The service name syntax MAY be used to validate a service name=20= > string, but MUST NOT be used for any other purpose (e.g.,=20 > delineation). Any system that includes a service name inside a=20 > longer string is itself responsible for delineating the service=20= > name. Such systems MUST NOT rely on the syntax of a service name=20= > alone for such delineation. >=20 > I have no idea what that is talking about. It gives the sense of = referring to something in particular, but doesn't actually say what. = Regardless, I did my PhD in message framing and the syntax of marking = boundaries, and I know of no basis for the claim that paragraph is = making. (No idea either.) > SRVNAME =3D (ALPHA / *([HYPHEN] ALNUM)) / > (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM)) > ALNUM =3D ALPHA / DIGIT ; A-Z, a-z, 0-9 > HYPHEN =3D %x2d ; "-"=20 > ALPHA =3D > DIGIT =3D >=20 > Why do we have BNF in this document? It's certainly a lot less clear = than the plain-English explanation. It's also wrong. I found at least = one class of strings that it allows that the plain-English rules do not, = and it prohibits at least one class of strings that the plain-English = rules allow. The fact that no one else noticed this just proves my point = that BNF is impenetrable to normal human beings and almost no one can = read that BNF description and understand it. We should delete it. We added it based one a community comment that said we should. I don't = care very much if it remains or not, but if it does, it absolutely needs = to be fixed. > The details of how applications make use of DNS SRV should be=20= > specified in the documentation set of the application/service. = In=20 > the absence of such specification, prospective clients of a given=20= > service should not assume the existence of SRV RRs for this=20 > service or, if they have indications that this will be the case=20= > (e.g., by configuration), must assume the unextended naming = scheme=20 > from for service discovery with DNS = SRV,=20 > i.e., the Service Label is constructed from the Service Name=20 > registered in by prepending a single=20= > underscore character ("_"). >=20 > This is nonsense and must go. What is "the unextended naming scheme"? = There's no mention in RFC 2782 of "extended" or "unextended" naming. >=20 (No idea either.) Lars --Apple-Mail-118-251842425 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwMzA4 MTUyMFowIwYJKoZIhvcNAQkEMRYEFLGmHM0KzqHyFIe7OPLrGTWdCyNsMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAChah8qSpA+edQFsVAF5RtQax+UaWN7hB8baNLBg4uL0LKlCNQvm MrJ/2OJFZhw+GxTUiGbR1nrpx8XbLZREQ/eKkgMM1zkdxlv7oMKULp7uOKdNVN29aUujcFZM6/3v PNtog0K2QX34Wy6MWWTeOEcnAysN0CKbcKmDLVsdEC0rsecvMRAisFys2IfXLeSHjkqVqeUJhqjk MI8MuX1p+RRp/XcjJ3GqTaMafHh2Y6PLC1URTsyxSx8dvFAaSQPFUmSBEXvlwKAon04PdCVoP8gW cuVyurkhEbvTFSfUuYXebHIK8rk9ynmqRZRlcmNq3zKQq8HL3hlQIpfwD+uGuY4AAAAAAAA= --Apple-Mail-118-251842425-- From lars.eggert@nokia.com Fri Sep 3 01:17:44 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8391E3A682D for ; Fri, 3 Sep 2010 01:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.618 X-Spam-Level: X-Spam-Status: No, score=-103.618 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 NxALsWmt8pSs for ; Fri, 3 Sep 2010 01:17:40 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 77A433A682E for ; Fri, 3 Sep 2010 01:17:34 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o838HvMK029897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2010 11:17:57 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-119-251993028; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> Date: Fri, 3 Sep 2010 11:17:50 +0300 Message-Id: <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> To: Stuart Cheshire X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 08:17:47 -0000 --Apple-Mail-119-251993028 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-9-3, at 10:16, Stuart Cheshire wrote: > 1. Name of the Registry >=20 > Right now the document calls it: >=20 > Transport Protocol Port Number and Service Name Registry >=20 > However, Section 5 says: >=20 > Service names are the unique key in the Port and Service Name = registry. >=20 > Since Service names really are the primary identifier, and the port = number is optional, and we expect to see more and more registrations = without port numbers, would it make sense to switch the order of the = words, and make it: >=20 > Registry of Service Names and Transport Protocol Port Numbers agree that we should use one name for the registry throughout. Am OK = with your proposal; the main reason I put port numbers first in the = title was that historically, that was what the registry was known as, = and I didn't want to confuse people. > 2. Service Name Rules >=20 > I liked Joe's earlier suggestion to disallow all-numeric service = names, to avoid service names that look like a numeric port number. = However, even with that rule, we still allow service names like this: = "6000-6063" (looks like the X Window System port range). Do we care? We = could prevent that by requiring that all service names contain at least = one alphabetic character. I like that proposal. > 3. Inconsistent terminology. >=20 > We use the term "Registered Ports" in some places to mean "ports in = the range 1024-49151", and in other places to mean any "port recorded by = IANA in the Registry". >=20 > For example, the first meaning: >=20 > the Well Known Ports, also known as the System Ports, from = 0-1023 > (assigned by IANA) >=20 > the Registered Ports, also known as the User Ports, from > 1024-49151 (assigned by IANA) >=20 > the Dynamic Ports, also known as the Private Ports, from > 49152-65535 (never assigned) >=20 > and now the second: >=20 > It is important to note that ownership of registered port = numbers and > service names remains with IANA. For protocols developed by IETF = working >=20 > Thousands of applications and application-level > protocols have registered ports and service names for their use, = and > there is every reason to believe that this trend will continue = into the > future. >=20 > Would it be better to strictly use the terms "System Ports" and "User = Ports" to denote the ranges, and keep the term "registered port" to just = mean generically, "recorded by IANA in the Registry"? We can also use the term "assigned" instead of "registered" in the = second case. > 4. Aliases >=20 > The document says: >=20 > IANA is also instructed to indicate which service name aliases = in the > existing registry are the primary aliases (see ). >=20 > Why should we burden IANA with this decision making? I bet there = aren't that many. Let's just work it out ourselves, and list them in the = document. I'll grep the IANA ports page and send a followup email with = the list of aliased names. OK. Lars= --Apple-Mail-119-251993028 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwMzA4 MTc1MVowIwYJKoZIhvcNAQkEMRYEFF+hPWKmZxUUcKQTzV+ob0QfXOgdMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAHXfMGFYZvuEYKrI6Yuysyj7qfgIoVdsN48qmtEf4VX6GBqTTAVU KjJHicbpfk76XbHLu7zNYjzzX1byNdBQXz29SJQESZSCiOFUKcI1eoRRaU+kUpBEFGTADCsMyRQm pO0g++x8kiA0riJ5SfdASSGeUStGy+sEf2b9zMB1yAHgHyJBe3+aeT25E5hhIFhUJOdDHy584ePR diAYqdrtxRSlT8wCx9o1A9eeYqUQ578nFSMBFhXmHbZD4fd+1u8nssQCSIQQ+Rh+d0jv4rwxA7XC pP8pDTzYy+K0KrVoQa4yxZnJazYejWPLOHnGlU/PjMLNbttUaprrBzebUlcAZ98AAAAAAAA= --Apple-Mail-119-251993028-- From lars.eggert@nokia.com Fri Sep 3 01:20:44 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F7F3A6821 for ; Fri, 3 Sep 2010 01:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.611 X-Spam-Level: X-Spam-Status: No, score=-103.611 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 heIvz6NtXwgs for ; Fri, 3 Sep 2010 01:20:43 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 0BADB3A681A for ; Fri, 3 Sep 2010 01:20:42 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o838L8HO027447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2010 11:21:08 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-120-252184201; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Fri, 3 Sep 2010 11:21:02 +0300 Message-Id: <1229C0AB-C21C-44C2-BE13-082307B5E3CE@nokia.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> To: Stuart Cheshire X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Aliased service names X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 08:20:44 -0000 --Apple-Mail-120-252184201 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-9-3, at 10:27, Stuart Cheshire wrote: > In most cases I believe these are *not* aliases. They're two different = services inadvertently colliding on the port number. The service names = are *not* aliases of each other in these cases because they're not the = same service. >=20 > In this whole list I only see four names that look like aliases to me: >=20 > "name" looks like an alias for "nameserver". >=20 > "www" and "www-http" are aliases for "http". >=20 > "auth" may be an alias for "ident". >=20 > So it looks like we have a total of THREE service names that have = aliases. Not sure. For example: > stun 3478/udp Session Traversal Utilities for NAT (STUN) = port > turn 3478/udp TURN over UDP > stun-behavior 3478/udp STUN Behavior Discovery over UDP >=20 > stun 3478/tcp Session Traversal Utilities for NAT (STUN) = port > turn 3478/tcp TURN over TCP > stun-behavior 3478/tcp STUN Behavior Discovery over TCP ... > stuns 5349/tcp STUN over TLS > turns 5349/tcp TURN over TLS > stun-behaviors 5349/tcp STUN Behavior Discovery over TLS TURN is a backward-compatible extension of STUN. So if a client looks up = "stun", a TURN server can offer service to that client. So a TURN server = that wanted to support STUN would need to register both service names. (Similarly, stun-behavior is backwards compatible with stun.) Lars= --Apple-Mail-120-252184201 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwMzA4 MjEwMlowIwYJKoZIhvcNAQkEMRYEFJ3pE69Df6Be3mW/Ncs5D+YCVpiPMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAGiZqqr4DtQS26Hqxjbo3ybmMdINxrki63oM8LvNFr9d8vq1hFQ3 yH6Wz7RBq3AaicDf5rfHKBv1jB6g0ut7Lzi/sJYxiyLEf8M5gfgOifIlzhHz0xMyxH7dW7SuZIS5 VyIdTRfC3bsVdxZN55dMtX07ctmm24NdjgS/WLVg0pv+dREhwNCwcD0b4kaewivoY5Alz+i7wAFZ zjnDk8DwmJbddbokXeuuJDG0c4J5jTi27MwXFHR4iAomavMTk7iOVh4aLoqeXQeMLJDdRC5ti0AI BCeP5lbc4AxvN19WiFc7ADzZBhLuMOJw9JO6eCaKZecqVVvPAdSRJmWSttrZL5UAAAAAAAA= --Apple-Mail-120-252184201-- From alexey.melnikov@isode.com Fri Sep 3 01:31:12 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3137D3A67FF for ; Fri, 3 Sep 2010 01:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 l3Z7-mLPQzNA for ; Fri, 3 Sep 2010 01:31:10 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 51C5D3A67FB for ; Fri, 3 Sep 2010 01:31:10 -0700 (PDT) Received: from [188.28.97.130] (188.28.97.130.threembb.co.uk [188.28.97.130]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 3 Sep 2010 09:31:38 +0100 Message-ID: <4C80B256.3090007@isode.com> Date: Fri, 03 Sep 2010 09:31:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lars Eggert , Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com> In-Reply-To: <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 08:31:12 -0000 Lars Eggert wrote: >Hi, > >On 2010-9-3, at 10:16, Stuart Cheshire wrote: > > >>1. Name of the Registry >> >>Right now the document calls it: >> >> Transport Protocol Port Number and Service Name Registry >> >>However, Section 5 says: >> >> Service names are the unique key in the Port and Service Name registry. >> >>Since Service names really are the primary identifier, and the port number is optional, and we expect to see more and more registrations without port numbers, would it make sense to switch the order of the words, and make it: >> >> Registry of Service Names and Transport Protocol Port Numbers >> >> >agree that we should use one name for the registry throughout. Am OK with your proposal; the main reason I put port numbers first in the title was that historically, that was what the registry was known as, and I didn't want to confuse people. > > BTW, Alfred also raised this point, so changing the registry name would keep him happier. >>2. Service Name Rules >> >>I liked Joe's earlier suggestion to disallow all-numeric service names, to avoid service names that look like a numeric port number. However, even with that rule, we still allow service names like this: "6000-6063" (looks like the X Window System port range). Do we care? We could prevent that by requiring that all service names contain at least one alphabetic character. >> >> >I like that proposal. > > Fine with me. >>3. Inconsistent terminology. >> >>We use the term "Registered Ports" in some places to mean "ports in the range 1024-49151", and in other places to mean any "port recorded by IANA in the Registry". >> >>For example, the first meaning: >> >> the Well Known Ports, also known as the System Ports, from 0-1023 >> (assigned by IANA) >> >> the Registered Ports, also known as the User Ports, from >> 1024-49151 (assigned by IANA) >> >> the Dynamic Ports, also known as the Private Ports, from >> 49152-65535 (never assigned) >> >>and now the second: >> >> It is important to note that ownership of registered port numbers and >> service names remains with IANA. For protocols developed by IETF working >> >> Thousands of applications and application-level >> protocols have registered ports and service names for their use, and >> there is every reason to believe that this trend will continue into the >> future. >> >>Would it be better to strictly use the terms "System Ports" and "User Ports" to denote the ranges, and keep the term "registered port" to just mean generically, "recorded by IANA in the Registry"? >> >> >We can also use the term "assigned" instead of "registered" in the second case. > > Works for me. >>4. Aliases >> >>The document says: >> >> IANA is also instructed to indicate which service name aliases in the >> existing registry are the primary aliases (see ). >> >>Why should we burden IANA with this decision making? I bet there aren't that many. Let's just work it out ourselves, and list them in the document. I'll grep the IANA ports page and send a followup email with the list of aliased names. >> >> >OK. > Is this text talking about future registrations as well? I.e. if there are future requests to register an alias, this requires IANA to show in the registry which is primary. IANA doesn't necessarily needs to make the decision, IANA just needs to show this somehow. From touch@isi.edu Fri Sep 3 10:06:42 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271183A6947 for ; Fri, 3 Sep 2010 10:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.537 X-Spam-Level: X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 PQh7YCBZdI9i for ; Fri, 3 Sep 2010 10:06:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 90B3E3A6943 for ; Fri, 3 Sep 2010 10:06:40 -0700 (PDT) Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o83H73rE000447; Fri, 3 Sep 2010 10:07:03 -0700 (PDT) Message-ID: <4C812B37.1030504@isi.edu> Date: Fri, 03 Sep 2010 10:07:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> In-Reply-To: <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 17:06:42 -0000 Stuart Cheshire wrote: ... > For each service name, there may exist zero or more associated port > number assignments. A port number assignment associated with a service > name contains the transport protocol, port number and possibly additional > data, such as a DCCP Service Code. > > This implies that a given service name can have *different* port > numbers assigned for different transport protocols. That is correct, and always has been. > If we really want that then a lot of the rest of the document will > have to change too. I propose we just delete it. Not sure it needs to be called out specifically. OK to delete, but with the understanding that we're already allowed to do this and it shouldn't affect anything. > For aliases that do not indicate a primary alias, a server is expected > to register itself under all aliased service names. > > numbers assigned for different transport protocols. If we really want > that then a lot of the rest of the document will have to change too. I > propose we just delete it. I don't like the idea of a primary alias either; there's no notion of it in the way users interact with port indices (/etc/ports or SRVs). However, since aliases *do* exist, I would say we should keep the latter part, i.e.: -- A a server is expected to register itself under all aliased service names. -- > If the registration request is for a service name alias (see target="srvname"/>), IANA needs to confirm with the administrative > contact for the existing service name whether the registration of the > alias is appropriate. > > This is a worse idea. We should not be allowing registration of new alias names at all. Agreed. However, note that the document itself creates a number of aliases for names that don't follow the new syntax. > The service name syntax MAY be used to validate a service name > string, but MUST NOT be used for any other purpose (e.g., > delineation). Any system that includes a service name inside a > longer string is itself responsible for delineating the service > name. Such systems MUST NOT rely on the syntax of a service name > alone for such delineation. > > I have no idea what that is talking about. It gives the sense of > referring to something in particular, but doesn't actually say what. Basically, it's intended to prevent attempts to parse the part between "_" and "." in a DNS SRV record, or to parse the string of a lookup in /etc/ports. It's specifically intended to prevent any attempt to create hierarchical naming within the current assignments. E.g., to prevent someone from declaring that "--" delineates sub-names in a service name, and that "soap--http" is "http" over "soap". It was discussed in mid-Dec 2009 on this list. You were included in that thread (search for "syntax" in the subject line). Overall, the point is that the namespace of service names is flat. Perhaps that's a better way to say it: -- Service names represent a flat, unstructured namespace, and MUST NOT be parsed to interpret components therein. -- > SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) / > (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM)) > ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 > HYPHEN = %x2d ; "-" > ALPHA = > DIGIT = > > Why do we have BNF in this document? Because we are declaring a syntax, and BNF is the only unabiguous way to do so. > It's certainly a lot less clear than the plain-English explanation. > It's also wrong. I found at least one class of strings that it allows > that the plain-English rules do not, and it prohibits at least one > class of strings that the plain-English rules allow. Can you be more specific and indicate what those each are? I can see the error that it currently doesn't allow multiple hyphens in a row, but that's easily fixed: SRVNAME = (ALPHA / *(*HYPHEN ALNUM)) / (1*DIGIT ((1*HYPHEN ALNUM) / ALPHA) *(*HYPHEN ALNUM)) ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN = %x2d ; "-" ALPHA = DIGIT = The only other omission is to limit the length to 15, but that's very difficult except as a separate BNF rule (which we could add if useful). The current English text (as context) is: Valid service names MUST contain only these US-ASCII [ANSI.X3-4.1986] characters: letters from A to Z and a to z, digits from 0 to 9, and hyphens ("-", ASCII 0x2D or decimal 45). They MUST be at least one character and no more than fifteen characters long, MUST NOT begin or end with a hyphen, and MUST NOT consist of only digits (in order to be distinguishable from port numbers, which are typically written as all digits). What's missing? > The fact that no one else noticed this just proves my point > that BNF is impenetrable to normal human beings and almost no one can > read that BNF description and understand it. The English has required multiple rounds of refinement as well. Arguably, in later email, you raise this point by asking whether the following example should be valid: 6000-6063 IMO, that's valid as a name because it cannot represent a single port. If we disallow that, then we need to emend the English too. > > The details of how applications make use of DNS SRV should be > specified in the documentation set of the application/service. In > the absence of such specification, prospective clients of a given > service should not assume the existence of SRV RRs for this > service or, if they have indications that this will be the case > (e.g., by configuration), must assume the unextended naming scheme > from for service discovery with DNS SRV, > i.e., the Service Label is constructed from the Service Name > registered in by prepending a single > underscore character ("_"). > > This is nonsense and must go. What is "the unextended naming scheme"? There's no mention in RFC 2782 of "extended" or "unextended" naming. This refers to the appendix of the gudmundsson-dnsext-srv-clarify, and I would agree it should be removed too. Joe From touch@isi.edu Fri Sep 3 10:20:44 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2E53A68D3 for ; Fri, 3 Sep 2010 10:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD4ZItxMFnm5 for ; Fri, 3 Sep 2010 10:20:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 962003A6803 for ; Fri, 3 Sep 2010 10:20:42 -0700 (PDT) Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o83HK8Ve003551; Fri, 3 Sep 2010 10:20:08 -0700 (PDT) Message-ID: <4C812E47.6050000@isi.edu> Date: Fri, 03 Sep 2010 10:20:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> In-Reply-To: <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 17:20:44 -0000 Stuart Cheshire wrote: > I have four final points for discussion > > 1. Name of the Registry > > Right now the document calls it: > > Transport Protocol Port Number and Service Name Registry > > However, Section 5 says: > > Service names are the unique key in the Port and Service Name registry. > > Since Service names really are the primary identifier, and the port number is optional, and we expect to see more and more registrations without port numbers, would it make sense to switch the order of the words, and make it: > > Registry of Service Names and Transport Protocol Port Numbers Sounds better. > > 2. Service Name Rules > > I liked Joe's earlier suggestion to disallow all-numeric service > names, to avoid service names that look like a numeric port number. > However, even with that rule, we still allow service names like this: > "6000-6063" (looks like the X Window System port range). Do we care? We > could prevent that by requiring that all service names contain at least > one alphabetic character. The point is only that a service name cannot be confused with a port number and used in its place without lookup. If we want to require an alpha - which would be fine - both the English and BNF would need to be revised, AND we would need to re-scrub the current table and create a new list of corrective aliases for legacy names that wouldn't work, if any (I don't think there are). > 3. Inconsistent terminology. > > We use the term "Registered Ports" in some places to mean "ports in > the range 1024-49151", and in other places to mean any "port recorded by > IANA in the Registry". The problem arises from numerous previous documents that refer to the ports as quoted: > For example, the first meaning: > > the Well Known Ports, also known as the System Ports, from 0-1023 > (assigned by IANA) > > the Registered Ports, also known as the User Ports, from > 1024-49151 (assigned by IANA) > > the Dynamic Ports, also known as the Private Ports, from > 49152-65535 (never assigned) We can't fix the problem with the word "registered". We ought to avoid using it for the IANA process. Perhaps the word "reserved" or "assigned" for the IANA process? I.e.: IANA Reservations / Assignments reserved ports (0-49151) > and now the second: > > It is important to note that ownership of registered port numbers and > service names remains with IANA. For protocols developed by IETF working > > Thousands of applications and application-level > protocols have registered ports and service names for their use, and > there is every reason to believe that this trend will continue into the > future. > > Would it be better to strictly use the terms "System Ports" and "User > Ports" to denote the ranges, Yes. That would help reduce the ambiguity. > and keep the term "registered port" to just > mean generically, "recorded by IANA in the Registry"? We can't use that term; it's already out there to mean 'user ports'. We should use a different term - either as suggested above or something else. > 4. Aliases > > The document says: > > IANA is also instructed to indicate which service name aliases in the > existing registry are the primary aliases (see ). > > Why should we burden IANA with this decision making? I bet there > aren't that many. Let's just work it out ourselves, and list them in the > document. I'll grep the IANA ports page and send a followup email with > the list of aliased names. Agreed. Joe From touch@isi.edu Fri Sep 3 10:22:45 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1E13A692D for ; Fri, 3 Sep 2010 10:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZIK8qyvEwulN for ; Fri, 3 Sep 2010 10:22:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9C43B3A6909 for ; Fri, 3 Sep 2010 10:22:44 -0700 (PDT) Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o83HMlvA003948; Fri, 3 Sep 2010 10:22:47 -0700 (PDT) Message-ID: <4C812EE7.50005@isi.edu> Date: Fri, 03 Sep 2010 10:22:47 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] Aliased service names X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 17:22:45 -0000 Stuart Cheshire wrote: > Below is the list of every service I found where more than one name is listed for a port number. > > In most cases I believe these are *not* aliases. They're two different services inadvertently colliding on the port number. The service names are *not* aliases of each other in these cases because they're not the same service. > > In this whole list I only see four names that look like aliases to me: > > "name" looks like an alias for "nameserver". > > "www" and "www-http" are aliases for "http". > > "auth" may be an alias for "ident". > > So it looks like we have a total of THREE service names that have aliases. Note that we also allowed aliases where the protocol in use can be determined in-band (as per STUN/TURN), typically where one is legacy and the other is the newer, backward-compatible version. We probably want to discourage that in the future. > -- > > List of aliased service names: For the rest of these, IANA should determine which was actually assigned and what are just squatters, and update the list accordingly. Joe From michelle.cotton@icann.org Fri Sep 3 12:01:23 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867073A6960 for ; Fri, 3 Sep 2010 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 af2Xp+G67aAp for ; Fri, 3 Sep 2010 12:01:22 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 020DB3A6902 for ; Fri, 3 Sep 2010 12:01:22 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 3 Sep 2010 12:01:51 -0700 From: Michelle Cotton To: Alexey Melnikov , Lars Eggert , Stuart Cheshire Date: Fri, 3 Sep 2010 12:01:49 -0700 Thread-Topic: [port-srv-reg] Four final points for discussion Thread-Index: ActLQn6PKUCq8JxiRY274UB/wmZb2wAV/efH Message-ID: In-Reply-To: <4C80B256.3090007@isode.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8A6942D282AFmichellecottonicannorg_" MIME-Version: 1.0 Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 19:01:23 -0000 --_000_C8A6942D282AFmichellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with all the changes below. Regarding the last point, can the service name aliases for future registrat= ions go in the notes column? Michelle On 9/3/10 1:31 AM, "Alexey Melnikov" wrote: Lars Eggert wrote: >Hi, > >On 2010-9-3, at 10:16, Stuart Cheshire wrote: > > >>1. Name of the Registry >> >>Right now the document calls it: >> >> Transport Protocol Port Number and Service Name Registry >> >>However, Section 5 says: >> >> Service names are the unique key in the Port and Service Name registry. >> >>Since Service names really are the primary identifier, and the port numbe= r is optional, and we expect to see more and more registrations without por= t numbers, would it make sense to switch the order of the words, and make i= t: >> >> Registry of Service Names and Transport Protocol Port Numbers >> >> >agree that we should use one name for the registry throughout. Am OK with = your proposal; the main reason I put port numbers first in the title was th= at historically, that was what the registry was known as, and I didn't want= to confuse people. > > BTW, Alfred also raised this point, so changing the registry name would keep him happier. >>2. Service Name Rules >> >>I liked Joe's earlier suggestion to disallow all-numeric service names, t= o avoid service names that look like a numeric port number. However, even w= ith that rule, we still allow service names like this: "6000-6063" (looks l= ike the X Window System port range). Do we care? We could prevent that by r= equiring that all service names contain at least one alphabetic character. >> >> >I like that proposal. > > Fine with me. >>3. Inconsistent terminology. >> >>We use the term "Registered Ports" in some places to mean "ports in the r= ange 1024-49151", and in other places to mean any "port recorded by IANA in= the Registry". >> >>For example, the first meaning: >> >> the Well Known Ports, also known as the System Ports, from 0-= 1023 >> (assigned by IANA) >> >> the Registered Ports, also known as the User Ports, from >> 1024-49151 (assigned by IANA) >> >> the Dynamic Ports, also known as the Private Ports, from >> 49152-65535 (never assigned) >> >>and now the second: >> >> It is important to note that ownership of registered port numbers= and >> service names remains with IANA. For protocols developed by IETF wor= king >> >> Thousands of applications and application-level >> protocols have registered ports and service names for their use, and >> there is every reason to believe that this trend will continue into = the >> future. >> >>Would it be better to strictly use the terms "System Ports" and "User Por= ts" to denote the ranges, and keep the term "registered port" to just mean = generically, "recorded by IANA in the Registry"? >> >> >We can also use the term "assigned" instead of "registered" in the second = case. > > Works for me. >>4. Aliases >> >>The document says: >> >> IANA is also instructed to indicate which service name aliases in= the >> existing registry are the primary aliases (see ). >> >>Why should we burden IANA with this decision making? I bet there aren't t= hat many. Let's just work it out ourselves, and list them in the document. = I'll grep the IANA ports page and send a followup email with the list of al= iased names. >> >> >OK. > Is this text talking about future registrations as well? I.e. if there are future requests to register an alias, this requires IANA to show in the registry which is primary. IANA doesn't necessarily needs to make the decision, IANA just needs to show this somehow. _______________________________________________ Port-srv-reg mailing list Port-srv-reg@ietf.org https://www.ietf.org/mailman/listinfo/port-srv-reg --_000_C8A6942D282AFmichellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [port-srv-reg] Four final points for discussion I agree with all the changes below.
Regarding the last point, can the service name aliases for future registrat= ions go in the notes column?

Michelle


On 9/3/10 1:31 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:

Lars Eggert wrote:

>Hi,
>
>On 2010-9-3, at 10:16, Stuart Cheshire wrote:
>
>
>>1. Name of the Registry
>>
>>Right now the document calls it:
>>
>>  Transport Protocol Port Number and Service Name Registry
>>
>>However, Section 5 says:
>>
>>  Service names are the unique key in the Port and Service Nam= e registry.
>>
>>Since Service names really are the primary identifier, and the port= number is optional, and we expect to see more and more registrations witho= ut port numbers, would it make sense to switch the order of the words, and = make it:
>>
>>  Registry of Service Names and Transport Protocol Port Number= s
>>   
>>
>agree that we should use one name for the registry throughout. Am OK wi= th your proposal; the main reason I put port numbers first in the title was= that historically, that was what the registry was known as, and I didn't w= ant to confuse people.
>
>
BTW, Alfred also raised this point, so changing the registry name would
keep him happier.

>>2. Service Name Rules
>>
>>I liked Joe's earlier suggestion to disallow all-numeric service na= mes, to avoid service names that look like a numeric port number. However, = even with that rule, we still allow service names like this: "6000-606= 3" (looks like the X Window System port range). Do we care? We could p= revent that by requiring that all service names contain at least one alphab= etic character.
>>   
>>
>I like that proposal.
>
>
Fine with me.

>>3. Inconsistent terminology.
>>
>>We use the term "Registered Ports" in some places to mean= "ports in the range 1024-49151", and in other places to mean any= "port recorded by IANA in the Registry".
>>
>>For example, the first meaning:
>>
>>         <t>the Well = Known Ports, also known as the System Ports, from 0-1023
>>         (assigned by IANA)= </t>
>>
>>         <t>the Regis= tered Ports, also known as the User Ports, from
>>         1024-49151 (assign= ed by IANA)</t>
>>
>>         <t>the Dynam= ic Ports, also known as the Private Ports, from
>>         49152-65535 (never= assigned)</t>
>>
>>and now the second:
>>
>>     <t>It is important to note that owne= rship of registered port numbers and
>>     service names remains with IANA. For proto= cols developed by IETF working
>>
>>     Thousands of applications and application-= level
>>     protocols have registered ports and servic= e names for their use, and
>>     there is every reason to believe that this= trend will continue into the
>>     future.
>>
>>Would it be better to strictly use the terms "System Ports&quo= t; and "User Ports" to denote the ranges, and keep the term "= ;registered port" to just mean generically, "recorded by IANA in = the Registry"?
>>   
>>
>We can also use the term "assigned" instead of "register= ed" in the second case.
>
>
Works for me.

>>4. Aliases
>>
>>The document says:
>>
>>     <t>IANA is also instructed to indica= te which service name aliases in the
>>     existing registry are the primary aliases = (see <xref target=3D"srvname"/>).</t>
>>
>>Why should we burden IANA with this decision making? I bet there ar= en't that many. Let's just work it out ourselves, and list them in the docu= ment. I'll grep the IANA ports page and send a followup email with the list= of aliased names.
>>   
>>
>OK.
>
Is this text talking about future registrations as well? I.e. if there
are future requests to register an alias, this requires IANA to show in
the registry which is primary. IANA doesn't necessarily needs to make
the decision, IANA just needs to show this somehow.

_______________________________________________
Port-srv-reg mailing list
Port-srv-reg@ietf.org
https://www.= ietf.org/mailman/listinfo/port-srv-reg

--_000_C8A6942D282AFmichellecottonicannorg_-- From cheshire@apple.com Sat Sep 4 00:18:16 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2953D3A6948 for ; Sat, 4 Sep 2010 00:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 sjQaUcvJ6hPq for ; Sat, 4 Sep 2010 00:18:14 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id B0E4D3A6940 for ; Sat, 4 Sep 2010 00:18:14 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 1AF9CA63271B for ; Sat, 4 Sep 2010 00:18:44 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-52-4c81f2d3ba59 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id E2.99.22738.3D2F18C4; Sat, 4 Sep 2010 00:18:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.43] (c-24-6-164-127.hsd1.ca.comcast.net [24.6.164.127]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8700J0KOB77560@elliott.apple.com> for port-srv-reg@ietf.org; Sat, 04 Sep 2010 00:18:43 -0700 (PDT) From: Stuart Cheshire In-reply-to: <1229C0AB-C21C-44C2-BE13-082307B5E3CE@nokia.com> Date: Sat, 04 Sep 2010 00:18:43 -0700 Message-id: <6774BA34-4CDC-4C83-885E-41986A5A8952@apple.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <1229C0AB-C21C-44C2-BE13-082307B5E3CE@nokia.com> To: Lars Eggert X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Aliased service names X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 07:18:16 -0000 On 3 Sep 2010, at 1:21, Lars Eggert wrote: > TURN is a backward-compatible extension of STUN. So if a client looks up "stun", a TURN server can offer service to that client. So a TURN server that wanted to support STUN would need to register both service names. Right, and that's okay. In this case TURN is not simply an alias for STUN. It's an extension. A server that offers TURN on a given port also offers STUN on that port, so it should advertise both. My point is that there's nothing to be gained by allowing variant names that are merely aliases for the exact same service. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Sat Sep 4 00:20:36 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36ED23A685E for ; Sat, 4 Sep 2010 00:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.351 X-Spam-Level: X-Spam-Status: No, score=-106.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 UNvm+G2NVLEL for ; Sat, 4 Sep 2010 00:20:35 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4F3E23A67F9 for ; Sat, 4 Sep 2010 00:20:35 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 19EFBA632759 for ; Sat, 4 Sep 2010 00:21:05 -0700 (PDT) X-AuditID: 11807136-b7b3eae0000066cf-51-4c81f360664e Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 4E.9A.26319.063F18C4; Sat, 4 Sep 2010 00:21:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.43] (c-24-6-164-127.hsd1.ca.comcast.net [24.6.164.127]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8700J1KOF47560@elliott.apple.com> for port-srv-reg@ietf.org; Sat, 04 Sep 2010 00:21:04 -0700 (PDT) From: Stuart Cheshire In-reply-to: Date: Sat, 04 Sep 2010 00:21:04 -0700 Message-id: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> To: Lars Eggert X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 07:20:36 -0000 On 3 Sep 2010, at 1:15, Lars Eggert wrote: > Specifically for the issue you mention above, are we going to handle "www" and its aliases? If a web server doesn't register all aliases, it cannot be found by clients that e.g. look up "http". In that case, the ship has already sailed. Network printers with embedded web servers advertise "_http._tcp" Safari and other web browsers look for "_http._tcp" The primary service name is "_http._tcp", and "www" is merely an alias. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Sat Sep 4 00:32:39 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5AD3A67C2 for ; Sat, 4 Sep 2010 00:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xOyLRcG5l1fh for ; Sat, 4 Sep 2010 00:32:36 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id DE6953A6403 for ; Sat, 4 Sep 2010 00:32:35 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id A9F12A632C25 for ; Sat, 4 Sep 2010 00:33:05 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-1b-4c81f631c783 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 2F.6B.22738.136F18C4; Sat, 4 Sep 2010 00:33:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.43] (c-24-6-164-127.hsd1.ca.comcast.net [24.6.164.127]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L87003IGOZ49190@et.apple.com> for port-srv-reg@ietf.org; Sat, 04 Sep 2010 00:33:05 -0700 (PDT) From: Stuart Cheshire In-reply-to: <4C812B37.1030504@isi.edu> Date: Sat, 04 Sep 2010 00:33:04 -0700 Message-id: <675AFB53-CFEC-4BC1-9C9E-EF6D12529E37@apple.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 07:32:39 -0000 On 3 Sep 2010, at 10:07, Joe Touch wrote: >> This implies that a given service name can have *different* port >> numbers assigned for different transport protocols. > > That is correct, and always has been. Can you give an example? In reality, almost no application protocol actually runs over multiple transport protocols. The only example I know that people tend to cite is DNS, and even that is not strictly the same application protocol over different transport protocols -- over TCP DNS has a two-byte length; over UDP it does not. > I don't like the idea of a primary alias either; there's no notion of it > in the way users interact with port indices (/etc/ports or SRVs). Yes, there is. Safari browses for _http._tcp. Nothing browses for _www._tcp. If your web server advertises _www._tcp then nothing will find it. There's no reason to ever advertise or browse for _www._tcp. > Agreed. However, note that the document itself creates a number of > aliases for names that don't follow the new syntax. And the new names are all the "primary" name to be used in SRV records and similar. >> Why do we have BNF in this document? > > Because we are declaring a syntax, and BNF is the only unabiguous way to > do so. Not true. There are many ways to explain things unambiguously. BNF is good for describing languages with recursive structure. For example, in C, an "if" statement contains an expression, and a statement. That statement can itself be another "if" statement, and so on, without limit. BNF is good at expressing this. Our service name syntax has no such recursive structure, which makes BNF a poor way of describing it. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Mon Sep 6 14:46:31 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F0D3A6990 for ; Mon, 6 Sep 2010 14:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.051 X-Spam-Level: X-Spam-Status: No, score=-105.051 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 eNNsxs4MwsAA for ; Mon, 6 Sep 2010 14:46:27 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 783D33A6826 for ; Mon, 6 Sep 2010 14:46:27 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id F005AA6A50CB for ; Mon, 6 Sep 2010 14:46:55 -0700 (PDT) X-AuditID: 11807136-b7b3eae0000066cf-14-4c85614f9529 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id BA.D2.26319.F41658C4; Mon, 6 Sep 2010 14:46:55 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.99.3] (208-106-97-96.dsl.static.sonic.net [208.106.97.96]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8C000ATHU73V90@elliott.apple.com> for port-srv-reg@ietf.org; Mon, 06 Sep 2010 14:46:55 -0700 (PDT) From: Stuart Cheshire In-reply-to: <4C812B37.1030504@isi.edu> Date: Mon, 06 Sep 2010 14:46:55 -0700 Message-id: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> To: port-srv-reg@ietf.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 21:46:31 -0000 On 3 Sep 2010, at 10:07, Joe Touch wrote: >> It's certainly a lot less clear than the plain-English explanation. >> It's also wrong. I found at least one class of strings that it allows >> that the plain-English rules do not, and it prohibits at least one >> class of strings that the plain-English rules allow. > > Can you be more specific and indicate what those each are? > > I can see the error that it currently doesn't allow multiple hyphens in > a row, but that's easily fixed: Now I'm less tired I'm going to be more blunt about my opinion here. I don't know who added the ABNF, and it doesn't really matter, but if anyone feels like I'm picking on them specifically then I apologise. Sometimes ABNF is appropriate, but many times when I see ABNF in an IETF document it reminds me of the pretentious people who use latin in cocktail party conversations. They're not doing it because it's a clearer way to communicate, on the contrary, they're doing it precisely because they hope the listener will have to ask to have it explained, thereby making the speaker feel smug and intellectually superior. Of course that doesn't work when (a) the speaker gets the latin wrong, and (b) the listener does actually understand latin well enough to know that. In this case the plain English text is easier to understand than the ABNF. I have asserted that the ABNF has a mistake in it, but I'm not going to say what. Perhaps I'm bluffing? The fact that no one is really sure whether I'm bluffing makes my point: that the ABNF is hard enough to understand that no one is really confident that they truly understand what it's saying. That makes it not very helpful text to have in the document. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From touch@isi.edu Mon Sep 6 16:01:47 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4383A69A7 for ; Mon, 6 Sep 2010 16:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4MZdMuBQ3PxD for ; Mon, 6 Sep 2010 16:01:46 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 25CC13A686E for ; Mon, 6 Sep 2010 16:01:45 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o86N1hYu001344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Sep 2010 16:01:54 -0700 (PDT) From: Joe Touch To: Stuart Cheshire In-Reply-To: X-Mailer: iPad Mail (7B500) References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> Message-Id: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 7B500) Date: Mon, 6 Sep 2010 16:02:35 -0700 X-MailScanner-ID: o86N1hYu001344 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 23:01:48 -0000 On Sep 6, 2010, at 2:46 PM, Stuart Cheshire wrote: > On 3 Sep 2010, at 10:07, Joe Touch wrote: >=20 >>> It's certainly a lot less clear than the plain-English explanation.=20= >>> It's also wrong. I found at least one class of strings that it = allows >>> that the plain-English rules do not, and it prohibits at least one >>> class of strings that the plain-English rules allow. >>=20 >> Can you be more specific and indicate what those each are? >>=20 >> I can see the error that it currently doesn't allow multiple hyphens = in >> a row, but that's easily fixed: >=20 > Now I'm less tired I'm going to be more blunt about my opinion here. >=20 > I don't know who added the ABNF, and it doesn't really matter, but if = anyone feels like I'm picking on them specifically then I apologise. >=20 > Sometimes ABNF is appropriate, but many times when I see ABNF in an = IETF document it reminds me of the pretentious people who use latin in = cocktail party conversations. They're not doing it because it's a = clearer way to communicate, on the contrary, they're doing it precisely = because they hope the listener will have to ask to have it explained, = thereby making the speaker feel smug and intellectually superior. Of = course that doesn't work when (a) the speaker gets the latin wrong, and = (b) the listener does actually understand latin well enough to know = that. >=20 > In this case the plain English text is easier to understand than the = ABNF. I have asserted that the ABNF has a mistake in it, but I'm not = going to say what. Perhaps I'm bluffing? If you think there is an error, either you are right or you are not. If = you won't tell us what it is, we can't tell which.=20 ABNF may be hard for you to understand, but for others - e.g., = non-native speakers of English - it can be less ambiguous.=20 It was placed in our ID to avoid the "clarify" draft from putting their = interpretation in their doc, rather than citing definitive ABNF in ours. Threatening not to tell us what you think you've found as 'blackmail' to = get us to remove the abnf isn't helping either us or your argument.=20 Joe From cheshire@apple.com Mon Sep 6 22:59:45 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF50E3A659B for ; Mon, 6 Sep 2010 22:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Szjt3thZ+VVf for ; Mon, 6 Sep 2010 22:59:39 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B38BE3A6782 for ; Mon, 6 Sep 2010 22:59:39 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 43FD1AD9B39A for ; Mon, 6 Sep 2010 23:00:08 -0700 (PDT) X-AuditID: 1180711d-b7b8eae0000035ac-d2-4c85d4e86534 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 26.94.13740.8E4D58C4; Mon, 6 Sep 2010 23:00:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.43] (c-24-6-164-127.hsd1.ca.comcast.net [24.6.164.127]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8D007J84O78510@gertie.apple.com> for port-srv-reg@ietf.org; Mon, 06 Sep 2010 23:00:08 -0700 (PDT) From: Stuart Cheshire In-reply-to: Date: Mon, 06 Sep 2010 23:00:07 -0700 Message-id: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> To: port-srv-reg@ietf.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 05:59:46 -0000 On 6 Sep 2010, at 16:02, Joe Touch wrote: > ABNF may be hard for you to understand I heard someone say once that an algorithm (or protocol) design can be so simple that it obviously has no errors, or so complicated that it has no obvious errors. The issue I'm trying to raise is not the particular error I may (or may not) have found, but the deeper concern that I'm not confident that it does not have more errors in addition to that. The issue is that unless a reasonable proportion of the IETF community can look at the ABNF definition and state with confidence that it is obviously right, then we may publish something that's not right. Processing a computer language generally consists of tokenizing followed by parsing. Tokenizing consists of turning text into logical units; parsing consists of turning those tokens into the language's structure. ABNF is a good way of expressing parsing rules; it is often not a good way of expressing tokenizing rules. The rules for stating what's a valid service name is a tokenizing problem, not a parsing problem. The awkward and convoluted ABNF in the document reflects this poor fit. I suspect that most people reading this document skip over the ABNF bit, so it has not had good scrutiny. It's also not adding much to the document if it's text that most readers skip over. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Mon Sep 6 23:33:30 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874E43A6782 for ; Mon, 6 Sep 2010 23:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.475 X-Spam-Level: X-Spam-Status: No, score=-107.475 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 j36jT+I84vpV for ; Mon, 6 Sep 2010 23:33:29 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4BD493A659B for ; Mon, 6 Sep 2010 23:33:29 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id B30ACA6B4975 for ; Mon, 6 Sep 2010 23:33:57 -0700 (PDT) X-AuditID: 11807136-b7b3eae0000066cf-86-4c85dcd54ad3 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 86.54.26319.5DCD58C4; Mon, 6 Sep 2010 23:33:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.43] (c-24-6-164-127.hsd1.ca.comcast.net [24.6.164.127]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8D007W568L8510@gertie.apple.com> for port-srv-reg@ietf.org; Mon, 06 Sep 2010 23:33:57 -0700 (PDT) From: Stuart Cheshire In-reply-to: <4C812E47.6050000@isi.edu> Date: Mon, 06 Sep 2010 23:33:56 -0700 Message-id: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <4C812E47.6050000@isi.edu> To: port-srv-reg@ietf.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 06:33:30 -0000 On 3 Sep 2010, at 10:20, Joe Touch wrote: > If we want to require an alpha - which would be fine - both the English > and BNF would need to be revised, AND we would need to re-scrub the > current table and create a new list of corrective aliases for legacy > names that wouldn't work, if any (I don't think there are). I just checked the current ports list for any service names containing text of the form "number-number", and found only three: mil-2045-47001 ecovisiong6-1 802-11-iapp All contain other letters as well, so it's not a problem. I don't think this is a big shock to any of us. I would have been surprised if there were any short name that was just "number-number", and indeed there is not. That no one has registered a short name like this in the decades leading up to now is also a good sign that it would not be not an unreasonable limitation to prohibit such names in the future. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From touch@isi.edu Tue Sep 7 08:25:31 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9395C3A6955 for ; Tue, 7 Sep 2010 08:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 QUEQIwmFFcoU for ; Tue, 7 Sep 2010 08:25:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id DBF7E3A6A1A for ; Tue, 7 Sep 2010 08:25:29 -0700 (PDT) Received: from [75.217.225.25] (25.sub-75-217-225.myvzw.com [75.217.225.25]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o87FPBYT016349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 08:25:21 -0700 (PDT) Message-ID: <4C865958.907@isi.edu> Date: Tue, 07 Sep 2010 08:25:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <4C812E47.6050000@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o87FPBYT016349 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 15:25:31 -0000 On 9/6/2010 11:33 PM, Stuart Cheshire wrote: > On 3 Sep 2010, at 10:20, Joe Touch wrote: > >> If we want to require an alpha - which would be fine - both the English >> and BNF would need to be revised, AND we would need to re-scrub the >> current table and create a new list of corrective aliases for legacy >> names that wouldn't work, if any (I don't think there are). > > I just checked the current ports list for any service names containing text of the form "number-number", and found only three: > > mil-2045-47001 > ecovisiong6-1 > 802-11-iapp > > All contain other letters as well, so it's not a problem. > > I don't think this is a big shock to any of us. I would have been > surprised if there were any short name that was just "number-number", > and indeed there is not. That no one has registered a short name like > this in the decades leading up to now is also a good sign that it > would not be not an unreasonable limitation to prohibit such names in > the future. IMO, we should decide the acceptable syntax based on what we require, not necessarily just what has been used in the past (otherwise we'd be allowing ".", "+", and a few others). The sole reason for excluding numbers-only was to require the translation step between service name and port number. There's no similar reason to exclude the "number*-number*" format. Joe From touch@isi.edu Tue Sep 7 09:08:03 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1A03A6A5D for ; Tue, 7 Sep 2010 09:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UEIH8juKjXlc for ; Tue, 7 Sep 2010 09:08:03 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 03C823A67D0 for ; Tue, 7 Sep 2010 09:08:02 -0700 (PDT) Received: from [75.217.225.25] (25.sub-75-217-225.myvzw.com [75.217.225.25]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o87G85rS023935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 09:08:16 -0700 (PDT) Message-ID: <4C866366.4010104@isi.edu> Date: Tue, 07 Sep 2010 09:08:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o87G85rS023935 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 16:08:04 -0000 On 9/6/2010 11:00 PM, Stuart Cheshire wrote: >> On 6 Sep 2010, at 16:02, Joe Touch wrote: >> >> ABNF may be hard for you to understand ... > The issue I'm trying to raise is not the particular error I may (or > may not) have found, but the deeper concern that I'm not confident that > it does not have more errors in addition to that. The issue is that > unless a reasonable proportion of the IETF community can look at the > ABNF definition and state with confidence that it is obviously right, > then we may publish something that's not right. I believe we need to publish something, esp. since some programmers will want to use what we publish - or a derivation thereof - as code to validate the strings. > Processing a computer language generally consists of tokenizing > followed by parsing. Tokenizing consists of turning text into logical > units; parsing consists of turning those tokens into the language's > structure. ABNF is a good way of expressing parsing rules; it is often > not a good way of expressing tokenizing rules. The ABNF we are using includes regular expressions, which is the common way to express tokens. > The rules for stating > what's a valid service name is a tokenizing problem, not a parsing > problem. The awkward and convoluted ABNF in the document reflects this > poor fit. It describes attempts to over-optimize the description to make it compact - which happened back in mid-Dec, and you were cc'd in that discussion. I checked that thread, and we had been developing the ABNF up to a point, then Olafur suggested we paste in the copy from the "clarify" doc, which introduced the error (indicated below). SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) / ^ (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM)) ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN = %x2d ; "-" ALPHA = DIGIT = From our discussions back in Dec, and correcting to make this easier to read (From RFC5234), the intended ABNF would have been: SRVNAME = ALPHA *([HYPHEN] ALNUM) SRVNAME =/ 1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM) ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN = %x2d ; "-" ALPHA = DIGIT = This missed the multiple hyphen case, which can be corrected easily: SRVNAME = ALPHA *(*HYPHEN ALNUM) SRVNAME =/ 1*DIGIT ((HYPHEN ALNUM) / ALPHA) *(*HYPHEN ALNUM) Joe From alexey.melnikov@isode.com Tue Sep 7 09:13:11 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595E23A6A55 for ; Tue, 7 Sep 2010 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5kBK6CaILYkt for ; Tue, 7 Sep 2010 09:13:08 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 392863A68BF for ; Tue, 7 Sep 2010 09:13:07 -0700 (PDT) Received: from [172.16.2.195] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 7 Sep 2010 17:13:34 +0100 Message-ID: <4C866485.3040605@isode.com> Date: Tue, 07 Sep 2010 17:12:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 16:13:12 -0000 Stuart Cheshire wrote: >On 3 Sep 2010, at 10:07, Joe Touch wrote: > > >>>It's certainly a lot less clear than the plain-English explanation. >>>It's also wrong. I found at least one class of strings that it allows >>>that the plain-English rules do not, and it prohibits at least one >>>class of strings that the plain-English rules allow. >>> >>Can you be more specific and indicate what those each are? >> >>I can see the error that it currently doesn't allow multiple hyphens in >>a row, but that's easily fixed: >> >> > >Now I'm less tired I'm going to be more blunt about my opinion here. > >I don't know who added the ABNF, and it doesn't really matter, but if anyone feels like I'm picking on them specifically then I apologise. > >Sometimes ABNF is appropriate, but many times when I see ABNF in an IETF document it reminds me of the pretentious people who use latin in cocktail party conversations. They're not doing it because it's a clearer way to communicate, on the contrary, they're doing it precisely because they hope the listener will have to ask to have it explained, thereby making the speaker feel smug and intellectually superior. Of course that doesn't work when (a) the speaker gets the latin wrong, and (b) the listener does actually understand latin well enough to know that. > >In this case the plain English text is easier to understand than the ABNF. I have asserted that the ABNF has a mistake in it, but I'm not going to say what. Perhaps I'm bluffing? The fact that no one is really sure whether I'm bluffing makes my point: that the ABNF is hard enough to understand that no one is really confident that they truly understand what it's saying. That makes it not very helpful text to have in the document. > Stuart, I am not going to insist on having ABNF in the document if rough consensus is against me, but I think documents I care about (in the Apps Area, mostly) would need to reference ABNF for service names. Of course the ABNF needs to be correct, if included. From touch@isi.edu Tue Sep 7 11:52:05 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA33D3A6893 for ; Tue, 7 Sep 2010 11:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 BqQQ3w84sAlk for ; Tue, 7 Sep 2010 11:52:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0067E3A6956 for ; Tue, 7 Sep 2010 11:52:00 -0700 (PDT) Received: from [75.217.225.25] (25.sub-75-217-225.myvzw.com [75.217.225.25]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o87IpnRB023295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 11:51:59 -0700 (PDT) Message-ID: <4C8689C6.7080000@isi.edu> Date: Tue, 07 Sep 2010 11:51:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> <675AFB53-CFEC-4BC1-9C9E-EF6D12529E37@apple.com> In-Reply-To: <675AFB53-CFEC-4BC1-9C9E-EF6D12529E37@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 18:52:06 -0000 On 9/4/2010 12:33 AM, Stuart Cheshire wrote: > On 3 Sep 2010, at 10:07, Joe Touch wrote: > >>> This implies that a given service name can have *different* port >>> numbers assigned for different transport protocols. >> >> That is correct, and always has been. > > Can you give an example? DNS and NFS. We review requests regularly for other numbers that do the same (except for formatting differences to deal with transport differences) in port reviews for IANA. ... > The only example I know that people tend to cite is DNS, and even > that is not strictly the same application protocol over different > transport protocols -- over TCP DNS has a two-byte length; over UDP > it does not. The "same service" doesn't require the same packet format. Sequence numbers and other information needed to deal with UDP's unreliable nature (lossy, out of order, can duplicate) are often omitted, and some framing information may be added to deal with TCP's lack of framing. <> I don't like the idea of a primary alias either; there's no notion of it >> in the way users interact with port indices (/etc/ports or SRVs). > > Yes, there is. Safari browses for _http._tcp. Nothing browses for _www._tcp. We only know that nobody registered "www" in your database; we cannot know whether there are no apps that browse for this string. >> Agreed. However, note that the document itself creates a number of >> aliases for names that don't follow the new syntax. > > And the new names are all the "primary" name to be used in SRV records and similar. IMO, there is no such thing as primary. It's ALL and ANY - register ALL, lookup ANY. That's the only way we know things will work. If we are to continue to use the term "primary", we need to define what it is and what it means; IMO, that's a can of worms we should avoid. Joe From mark.mcfadden@icann.org Tue Sep 7 13:55:04 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E41D3A6983 for ; Tue, 7 Sep 2010 13:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 XSj9yT5767Y5 for ; Tue, 7 Sep 2010 13:55:01 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 293623A6A7A for ; Tue, 7 Sep 2010 13:55:01 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 7 Sep 2010 13:55:29 -0700 From: Mark Mcfadden To: Joe Touch , Stuart Cheshire Date: Tue, 7 Sep 2010 13:51:10 -0700 Thread-Topic: Making progress Thread-Index: AQHLTs8BwYf6xng+Mkm2h9VSXV3Hsw== Message-ID: <05B243F724B2284986522B6ACD0504D7D341083169@EXVPMBX100-1.exc.icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_05B243F724B2284986522B6ACD0504D7D341083169EXVPMBX1001ex_" MIME-Version: 1.0 Cc: "port-srv-reg@ietf.org" Subject: [port-srv-reg] Making progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 20:55:04 -0000 --_002_05B243F724B2284986522B6ACD0504D7D341083169EXVPMBX1001ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The most recent version in the repository has the changes suggested by Mich= elle and Pearl. The attachment has the before and after language. Of cour= se, a simple diff is also going to provide you with a view of the small cha= nges that were made. They were: - clarity in the introduction about the authority for registering port numb= ers and service names; - the need to prohibit multiple consecutive hyphens in the service name; an= d, - consistency of the contact and registration language in Section 8. mark Mark McFadden mark.mcfadden@icann.org IANA Resource Specialist= --_002_05B243F724B2284986522B6ACD0504D7D341083169EXVPMBX1001ex_ Content-Type: application/msword; name="2010 09 04 - Proposed changes to draft-ietf-tsvwg-iana-ports.doc" Content-Description: 2010 09 04 - Proposed changes to draft-ietf-tsvwg-iana-ports.doc Content-Disposition: attachment; filename="2010 09 04 - Proposed changes to draft-ietf-tsvwg-iana-ports.doc"; size=39936; creation-date="Tue, 07 Sep 2010 13:52:29 GMT"; modification-date="Tue, 07 Sep 2010 13:52:29 GMT" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASQAAAAAAAAAA EAAASwAAAAEAAAD+////AAAAAEgAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAX8AJBAAA8BK/AAAAAAAAEAAAAAAACAAAQB0AAA4AYmpiagAVABUAAAAAAAAAAAAAAAAAAAAA AAAJBBYANCgAAGJ/AABifwAAQBUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAABYHAAAAAAAAFgcAAHAU AAAAAAAAcBQAAAAAAABwFAAAAAAAAHAUAAAAAAAAcBQAABQAAAAAAAAAAAAAAP////8AAAAAhBQA AAAAAACEFAAAAAAAAIQUAAAAAAAAhBQAABwAAACgFAAAFAAAAIQUAAAAAAAAqhgAAHABAAC0FAAA KAAAANwUAAAAAAAA3BQAAAAAAADcFAAAAAAAANwUAAAAAAAAtxUAAAAAAAC3FQAAAAAAALcVAAAA AAAAKRgAAAIAAAArGAAAAAAAACsYAAAAAAAAKxgAAAAAAAArGAAAAAAAACsYAAAAAAAAKxgAACQA AAAaGgAAsgIAAMwcAABeAAAATxgAABUAAAAAAAAAAAAAAAAAAAAAAAAAcBQAAAAAAAC3FQAAAAAA AAAAAAAAAAAAAAAAAAAAAAC3FQAAAAAAALcVAAAAAAAAtxUAAAAAAAC3FQAAAAAAAE8YAAAAAAAA AAAAAAAAAABwFAAAAAAAAHAUAAAAAAAA3BQAAAAAAAAAAAAAAAAAANwUAADbAAAAZBgAABYAAACr FwAAAAAAAKsXAAAAAAAAqxcAAAAAAAC3FQAAIgAAAHAUAAAAAAAA3BQAAAAAAABwFAAAAAAAANwU AAAAAAAAKRgAAAAAAAAAAAAAAAAAAKsXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAtxUAAAAAAAApGAAAAAAAAAAAAAAAAAAAqxcAAAAAAAAAAAAA AAAAAKsXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqxcAAAAAAADcFAAAAAAAAP////8AAAAAEGWThc5O ywEAAAAAAAAAAP////8AAAAA2RUAANIBAACrFwAAAAAAAAAAAAAAAAAAFRgAABQAAAB6GAAAMAAA AKoYAAAAAAAAqxcAAAAAAAAqHQAAAAAAAKsXAAAAAAAAKh0AAAAAAACrFwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACr FwAASgAAACodAAAAAAAAAAAAAAAAAABwFAAAAAAAAPUXAAAgAAAAtxUAAAAAAAC3FQAAAAAAAKsX AAAAAAAAtxUAAAAAAAC3FQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtxUA AAAAAAC3FQAAAAAAALcVAAAAAAAATxgAAAAAAABPGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAqxcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALcVAAAA AAAAtxUAAAAAAAC3FQAAAAAAAKoYAAAAAAAAtxUAAAAAAAC3FQAAAAAAALcVAAAAAAAAtxUAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAACodAAAAAAAAtxUAAAAAAAC3 FQAAAAAAALcVAAAAAAAAtxUAAAAAAAC3FQAAAAAAALcVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC3FQAAAAAAALcVAAAAAAAAtxUA AAAAAAAWBwAAIAwAADYTAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFNlY3Rp b24gMToLT2xkIHRleHQ6C0l0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgb3duZXJzaGlwIG9m IHJlZ2lzdGVyZWQgcG9ydCBudW1iZXJzIGFuZCBzZXJ2aWNlIG5hbWVzIHJlbWFpbnMgd2l0aCBJ QU5BLiBGb3IgcHJvdG9jb2xzIGRldmVsb3BlZCBieSBJRVRGIHdvcmtpbmcgZ3JvdXBzLCBJQU5B IG5vdyBhbHNvIG9mZmVycyBhIG1ldGhvZCBmb3IgdGhlICJlYXJseSIgYXNzaWdubWVudCBvZiBw b3J0IG51bWJlcnMgYW5kIHNlcnZpY2UgbmFtZXMgW1JGQzQwMjBdLCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA4LjEuDQtOZXcgcHJvcG9zZWQgdGV4dDoNSUFOQSBpcyB0aGUgYXV0aG9yaXR5IGZv ciByZWdpc3RlcmluZyBwb3J0IG51bWJlcnMgYW5kIHNlcnZpY2UgbmFtZXMuICBUaGUgcmVnaXN0 cmllcyB0aGF0IGFyZSBjcmVhdGVkIHRvIHN0b3JlIHRoZXNlIHJlZ2lzdHJhdGlvbnMgYXJlIG1h aW50YWluZWQgYnkgSUFOQS4gIEZvciBwcm90b2NvbHMgZGV2ZWxvcGVkIGJ5IElFVEYgd29ya2lu ZyBncm91cHMsIElBTkEgbm93IG9mZmVycyBhIG1ldGhvZCBmb3IgdGhlIJNlYXJseZQgYXNzaWdu bWVudCBvZiBwb3J0IG51bWJlcnMgYW5kIHNlcnZpY2UgbmFtZXMgW3NlZSBSRkM0MDIwXSwgYXMg ZGVzY3JpYmVkIGluIHNlY3Rpb24gOC4xLg0NU2VjdGlvbiA1LjE6C09sZCB0ZXh0Og1WYWxpZCBz ZXJ2aWNlIG5hbWVzIE1VU1QgY29udGFpbiBvbmx5IHRoZXNlIFVTLUFTQ0lJIFsTIEhZUEVSTElO SyAiaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1pYW5hLXBvcnRz LTA2IiBcbCAicmVmLUFOU0kuWDMtNC4xOTg2IiBcbyAiXCJDb2RlZCBDaGFyYWN0ZXIgU2V0IC0g Ny1iaXQgQW1lcmljYW4gU3RhbmRhcmQgQ29kZSBmb3IgSW5mb3JtYXRpb24gSW50ZXJjaGFuZ2Vc IiIgFEFOU0kuWDMtNC4xOTg2FV0gY2hhcmFjdGVyczogbGV0dGVycyBmcm9tIEEgdG8gWiBhbmQg YSB0byB6LCBkaWdpdHMgZnJvbSAwIHRvIDksIGFuZCBoeXBoZW5zICgiLSIsIEFTQ0lJIDB4MkQg b3IgZGVjaW1hbCA0NSkuICBUaGV5IE1VU1QgYmUgYXQgbGVhc3Qgb25lIGNoYXJhY3RlciBhbmQg bm8gbW9yZSB0aGFuIGZpZnRlZW4gY2hhcmFjdGVycyBsb25nLCBNVVNUIE5PVCBiZWdpbiBvciBl bmQgd2l0aCBhIGh5cGhlbiwgYW5kIE1VU1QgTk9UIGNvbnNpc3Qgb2Ygb25seSBkaWdpdHMgKGlu IG9yZGVyIHRvIGJlIGRpc3Rpbmd1aXNoYWJsZSBmcm9tIHBvcnQgbnVtYmVycywgd2hpY2ggYXJl IHR5cGljYWxseSB3cml0dGVuIGFzIGFsbCBkaWdpdHMpLg0NTmV3IHByb3Bvc2VkIHRleHQ6DVZh bGlkIHNlcnZpY2UgbmFtZXMgTVVTVCBjb250YWluIG9ubHkgdGhlc2UgVVMtQVNDSUkgWxMgSFlQ RVJMSU5LICJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWlhbmEt cG9ydHMtMDYiIFxsICJyZWYtQU5TSS5YMy00LjE5ODYiIFxvICJcIkNvZGVkIENoYXJhY3RlciBT ZXQgLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNo YW5nZVwiIiAUQU5TSS5YMy00LjE5ODYVXSBjaGFyYWN0ZXJzOiBsZXR0ZXJzIGZyb20gQSB0byBa IGFuZCBhIHRvIHosIGRpZ2l0cyBmcm9tIDAgdG8gOSwgYW5kIGh5cGhlbnMgKCItIiwgQVNDSUkg MHgyRCBvciBkZWNpbWFsIDQ1KS4gIFRoZXkgTVVTVCBiZSBhdCBsZWFzdCBvbmUgY2hhcmFjdGVy IGFuZCBubyBtb3JlIHRoYW4gZmlmdGVlbiBjaGFyYWN0ZXJzIGxvbmcsIE1VU1QgTk9UIGJlZ2lu IG9yIGVuZCB3aXRoIGEgaHlwaGVuLCBNVVNUIE5PVCBoYXZlIGNvbnNlY3V0aXZlIGh5cGhlbnMs IGFuZCBNVVNUIE5PVCBjb25zaXN0IG9mIG9ubHkgZGlnaXRzIChpbiBvcmRlciB0byBiZSBkaXN0 aW5ndWlzaGFibGUgZnJvbSBwb3J0IG51bWJlcnMsIHdoaWNoIGFyZSB0eXBpY2FsbHkgd3JpdHRl biBhcyBhbGwgZGlnaXRzKS4NDU9sZCB0ZXh0Og1UaGUgc2VydmljZSBuYW1lIHN5bnRheCBNQVkg YmUgdXNlZCB0byB2YWxpZGF0ZSBhIHNlcnZpY2UgbmFtZSBzdHJpbmcsIGJ1dCBNVVNUIE5PVCBi ZSB1c2VkIGZvciBhbnkgb3RoZXIgcHVycG9zZSAoZS5nLiwgZGVsaW5lYXRpb24pLiAgQW55IHN5 c3RlbSB0aGF0IGluY2x1ZGVzIGEgc2VydmljZSBuYW1lIGluc2lkZSBhIGxvbmdlciBzdHJpbmcg aXMgaXRzZWxmIHJlc3BvbnNpYmxlIGZvciBkZWxpbmVhdGluZyB0aGUgc2VydmljZSBuYW1lLiBT dWNoIHN5c3RlbXMgTVVTVCBOT1QgcmVseSBvbiB0aGUgc3ludGF4IG9mIGEgc2VydmljZSBuYW1l IGFsb25lIGZvciBzdWNoIGRlbGluZWF0aW9uLg0NTmV3IHByb3Bvc2VkIFRleHQ6DQ1UaGUgc2Vy dmljZSBuYW1lIHN5bnRheCBNQVkgYmUgdXNlZCB0byB2YWxpZGF0ZSBhIHNlcnZpY2UgbmFtZSBz dHJpbmcsIGJ1dCBNVVNUIE5PVCBiZSB1c2VkIGZvciBhbnkgb3RoZXIgcHVycG9zZSAoZS5nLiwg ZGVsaW5lYXRpb24pLiAgQW55IHN5c3RlbSB0aGF0IGluY2x1ZGVzIGEgc2VydmljZSBuYW1lIGlu c2lkZSBhIGxvbmdlciBzdHJpbmcgaXMgaXRzZWxmIHJlc3BvbnNpYmxlIGZvciBkZWxpbmVhdGlu ZyB0aGUgc2VydmljZSBuYW1lLiBTdWNoIHN5c3RlbXMgTVVTVCBOT1QgcmVseSBvbiB0aGUgc3lu dGF4IG9mIGEgc2VydmljZSBuYW1lIGFsb25lIGZvciBzdWNoIGRlbGluZWF0aW9uLg0NTm90ZSB0 aGF0IHRoZSBoaXN0b3JpYyCTcG9ydCBuYW1llCBpcyBub3cgdGhlIJNzZXJ2aWNlIG5hbWWUIGFu ZCBmb2xsb3dzIHRoZSBzZXJ2aWNlIG5hbWUgc3ludGF4IGRlZmluZWQgaW4gdGhpcyBzZWN0aW9u LiALC1NlY3Rpb24gODoLT2xkIHRleHQ6DQ1BIHBvcnQgbnVtYmVyIG9yIHNlcnZpY2UgbmFtZSBy ZWdpc3RyYXRpb24gcmVxdWVzdCBjb250YWlucyBzb21lIG9yIGFsbCBvZiB0aGUgZm9sbG93aW5n IGluZm9ybWF0aW9uLiAgVGhlIGNvbWJpbmF0aW9uIG9mIHNlcnZpY2UgbmFtZSBhbmQgdHJhbnNw b3J0IHByb3RvY29sIGlzIHRoZSB1bmlxdWUgaWRlbnRpZmllciBvZiBhIGdpdmVuIHNlcnZpY2U6 DQ0gICAgICBTZXJ2aWNlIE5hbWUgKFJFUVVJUkVEKQ0gICAgICBUcmFuc3BvcnQgUHJvdG9jb2wo cykgKFJFUVVJUkVEKQ0gICAgICBSZWdpc3RyYXRpb24gQWRtaW5pc3RyYXRpdmUgQ29udGFjdCAo UkVRVUlSRUQpDSAgICAgIFJlZ2lzdHJhdGlvbiBUZWNobmljYWwgQ29udGFjdCAoUkVRVUlSRUQp DSAgICAgIFBvcnQgTnVtYmVyIChPUFRJT05BTCkNICAgICAgU2VydmljZSBDb2RlIChvbmx5IFJF UVVJUkVEIGZvciBEQ0NQKQ0gICAgICBEZXNjcmlwdGlvbiAoUkVRVUlSRUQpDSAgICAgIFJlZmVy ZW5jZSAoUkVRVUlSRUQpDSAgICAgIEtub3duIFVuYXV0aG9yaXplZCBVc2VzIChPUFRJT05BTCkN ICAgICAgQXNzaWdubWVudCBOb3RlcyAoT1BUSU9OQUwpDQ1OZXcgUHJvcG9zZWQgVGV4dDoNDUEg cG9ydCBudW1iZXIgb3Igc2VydmljZSBuYW1lIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IGNvbnRhaW5z IHNvbWUgb3IgYWxsIG9mIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24uICBUaGUgY29tYmluYXRp b24gb2Ygc2VydmljZSBuYW1lIGFuZCB0cmFuc3BvcnQgcHJvdG9jb2wgaXMgdGhlIHVuaXF1ZSBp ZGVudGlmaWVyIG9mIGEgZ2l2ZW4gc2VydmljZToNDSAgICAgIFNlcnZpY2UgTmFtZSAoUkVRVUlS RUQpDSAgICAgIFRyYW5zcG9ydCBQcm90b2NvbChzKSAoUkVRVUlSRUQpDSAgICAgIFJlZ2lzdHJh bnQgKFJFUVVJUkVEKQ0gICAgICBDb250YWN0IChSRVFVSVJFRCkNICAgICAgUG9ydCBOdW1iZXIg KE9QVElPTkFMKQ0gICAgICBTZXJ2aWNlIENvZGUgKG9ubHkgUkVRVUlSRUQgZm9yIERDQ1ApDSAg ICAgIERlc2NyaXB0aW9uIChSRVFVSVJFRCkNICAgICAgUmVmZXJlbmNlIChSRVFVSVJFRCkNICAg ICAgS25vd24gVW5hdXRob3JpemVkIFVzZXMgKE9QVElPTkFMKQ0gICAgICBBc3NpZ25tZW50IE5v dGVzIChPUFRJT05BTCkNDU9sZCBUZXh0Og0NoKCgbyCgUmVnaXN0cmF0aW9uIEFkbWluaXN0cmF0 aXZlIENvbnRhY3Q6IE5hbWUgYW5kIGVtYWlsIGFkZHJlc3Mgb2YgdGhlIGFkbWluaXN0cmF0aXZl IGNvbnRhY3QgZm9yIHRoZSByZWdpc3RyYXRpb24uIFRoaXMgaXMgUkVRVUlSRUQuIFRoZSBuYW1l IG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb250YWN0IGlkZW50aWZpZXMgdGhlIG9yZ2FuaXphdGlv biwgY29tcGFueSwgb3IgaW5kaXZpZHVhbCB3aG8gaXMgcmVzcG9uc2libGUgZm9yIHRoZSByZWdp c3RyYXRpb24uIKBGb3IgcmVnaXN0cmF0aW9ucyBkb25lIHRocm91Z2ggSUVURi1wdWJsaXNoZWQg UkZDcywgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnRhY3Qgd2lsbCBiZSB0aGUgSUVTRy4LC6CgoG8g oFJlZ2lzdHJhdGlvbiBUZWNobmljYWwgQ29udGFjdDogTmFtZSBhbmQgZW1haWwgYWRkcmVzcyBv ZiB0aGUgdGVjaG5pY2FsIGNvbnRhY3QgcGVyc29uIGZvciB0aGUgcmVnaXN0cmF0aW9uLiCgVGhp cyBpcyBSRVFVSVJFRC4gRm9yIGluZGl2aWR1YWxzLCB0aGlzIGlzIHRoZSBzYW1lIGFzIHRoZSBS ZWdpc3RyYXRpb24gQWRtaW5pc3RyYXRpdmUgQ29udGFjdDsgZm9yIG9yZ2FuaXphdGlvbnMsIHRo aXMgaXMgYSBwb2ludCBvZiBjb250YWN0IGF0IHRoYXQgb3JnYW5pemF0aW9uLiCgQWRkaXRpb25h bCBhZGRyZXNzIGluZm9ybWF0aW9uIE1BWSBiZSBwcm92aWRlZC4goEZvciByZWdpc3RyYXRpb25z IGRvbmUgdGhyb3VnaCBJRVRGLXB1Ymxpc2hlZCBSRkNzLCB0aGUgdGVjaG5pY2FsIGNvbnRhY3Qg d2lsbCBiZSB0aGUgSUVTRy4LC05ldyBQcm9wb3NlZCBUZXh0Og0LoKCgbyCgUmVnaXN0cmFudDog TmFtZSBhbmQgZW1haWwgYWRkcmVzcyBvZiB0aGUgUmVnaXN0cmFudC4gVGhpcyBpcyBSRVFVSVJF RC4gVGhlIFJlZ2lzdHJhbnQgaXMgdGhlIE9yZ2FuaXphdGlvbiBvciBDb21wYW55IHJlc3BvbnNp YmxlIGZvciB0aGUgaW5pdGlhbCByZWdpc3RyYXRpb24uICBGb3IgcmVnaXN0cmF0aW9ucyBkb25l IHRocm91Z2ggSUVURi1wdWJsaXNoZWQgUkZDcywgdGhlIFJlZ2lzdHJhbnQgd2lsbCBiZSB0aGUg SUVTRy4LC6CgoG8goENvbnRhY3Q6IE5hbWUgYW5kIGVtYWlsIGFkZHJlc3Mgb2YgdGhlIENvbnRh Y3QgcGVyc29uIGZvciB0aGUgcmVnaXN0cmF0aW9uLiBUaGlzIGlzIFJFUVVJUkVELiBUaGUgQ29u dGFjdCBwZXJzb24gaXMgdGhlIHJlc3BvbnNpYmxlIHBlcnNvbiBmb3IgdGhlIEludGVybmV0IGNv bW11bml0eSB0byBzZW5kIHF1ZXN0aW9ucyB0by4gIFRoaXMgcGVyc29uIHdvdWxkIGFsc28gYmUg YXV0aG9yaXplZCB0byBzdWJtaXQgY2hhbmdlcyBvbiBiZWhhbGYgb2YgdGhlIFJlZ2lzdHJhbnQu IKBBZGRpdGlvbmFsIGFkZHJlc3MgaW5mb3JtYXRpb24gTUFZIGJlIHByb3ZpZGVkLiCgRm9yIHJl Z2lzdHJhdGlvbnMgZG9uZSB0aHJvdWdoIElFVEYtcHVibGlzaGVkIFJGQ3MsIHRoZSBDb250YWN0 IHdpbGwgYmUgdGhlIElFU0cuCw0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACwgAABQIAAAVCAAA LgkAAC8JAABDCQAAkQoAAJIKAACgCgAAqQoAAKoKAADgCgAA4QoAAJgLAACZCwAApwsAAKgLAAAN DQAADg0AAA8NAAAiDQAAWA0AAPPj89Hzwa+ekcGRf2h/aFBof56Rwa8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALwwqBxVoUlHyABZodVGKAD4qAUIqAkNKGABP SgQAUUoEAF5KBABhShgAcGgAAP8ALANqAAAAAAwqBxVoUlHyABZodVGKAENKGABPSgQAUUoEAFUI AV5KBABhShgAACMMKgcVaFJR8gAWaHVRigBDShgAT0oEAFFKBABeSgQAYUoYABgVaOp/3wAWaHVR igBDShgAXkoDAGFKGAAAIBVoUlHyABZodVGKAENKGABPSgQAUUoEAF5KBABhShgAACMMKgMVaFJR 8gAWaHVRigBDShgAT0oEAFFKBABeSgQAYUoYAB4VaOp/3wAWaHVRigA1CIE2CIFDShgAXkoDAGFK GAAAIwwqBxVoUlHyABZoPSmmAENKGABPSgQAUUoEAF5KBABhShgAHhVo6n/fABZoPSmmADUIgTYI gUNKGABeSgMAYUoYAAAYFWjqf98AFmg9KaYAQ0oYAF5KAwBhShgAFgAIAAAvCQAAQwkAAJIKAACT CgAAqgoAAA4NAAAPDQAAIg0AAKkPAACqDwAAtA8AAAoRAAALEQAAHhEAAB8RAAB1EgAAdhIAAAcT AAAIEwAA0xMAANQTAADyEwAAGRQAAE4UAAB+FAAAmxQAAMcUAADkFAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABBAAZ2R1UYoAAAQPAGdkdVGKAAAcWA0AAFkNAAAQDgAAEQ4AAB8O AAAgDgAAqA8AAKkPAACqDwAAtA8AAAkRAAALEQAAHhEAAB8RAADvEgAA8hIAAP0SAAAGEwAACBMA AEkVAADp1+m/6deuo5WJgW2BYaNQbT8zAAAAFwwqBxVoMUXcABZodVGKAENKGABhShgAIBZodVGK ADUIgTYIgUNKGABPSgMAUUoDAF5KAwBhShgAACAVaOp/3wAWaHVRigBDShgAT0oDAFFKAwBeSgMA YUoYAAAXDCoDFWhSUfIAFmh1UYoAQ0oYAGFKGAAmFWjqf98AFmh1UYoANQiBNgiBQ0oYAE9KAwBR SgMAXkoDAGFKGAAADhZodVGKAENKGABhShgAABcMKgcVaFJR8gAWaHVRigBDShgAYUoYABoVaFJR 8gAWaHVRigA1CIE2CIFDShgAYUoYAAAUFWhSUfIAFmh1UYoAQ0oYAGFKGAAAIBVoUlHyABZodVGK AENKGABPSgQAUUoEAF5KBABhShgAAC8MKgMVaFJR8gAWaHVRigA+KgFCKgJDShgAT0oEAFFKBABe SgQAYUoYAHBoAAD/ACMMKgMVaFJR8gAWaHVRigBDShgAT0oEAFFKBABeSgQAYUoYACwDagAAAAAM KgMVaFJR8gAWaHVRigBDShgAT0oEAFFKBABVCAFeSgQAYUoYABPkFAAA/xQAACgVAABKFQAASxUA AF4VAABfFQAAKhYAACsWAABJFgAAcBYAAIwWAAClFgAAwhYAAO4WAAALFwAAJhcAAE8XAABxFwAA chcAAHwXAAB9FwAAphoAAEAdAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEABnZHVRigAAF0kVAABLFQAAXhUAAF8VAABwFwAA cRcAAHIXAAB8FwAAfRcAAIAXAACRGgAAkxoAAKYaAACqGgAA4RoAAOcaAAA+HQAAPx0AAEAdAAD4 5PjY+M3k+MK2wuTC2K3YwqEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAXDCoHFWgxRdwAFmh1UYoAQ0oYAGFKGAARDCoDFmh1UYoAQ0oYAGFK GAAXDCoHFWhSUfIAFmh1UYoAQ0oYAGFKGAAUFWhSUfIAFmh1UYoAQ0oYAGFKGAAAFBVoMUXcABZo dVGKAENKGABhShgAABcMKgMVaDFF3AAWaHVRigBDShgAYUoYACYVaDFF3AAWaHVRigA1CIE2CIFD ShgAT0oDAFFKAwBeSgMAYUoYAAAOFmh1UYoAQ0oYAGFKGAASMgAxkGgBOnB1UYoAH7DQLyCw4D0h sKAFIrCgBSOQoAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqBBMAEgABAAsBDwAHAAMAAwADAAAA BAAIAAAAmAAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAAPgIAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAAKgAAAA2BgAANgYAABYAAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAALgAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAABoAQAASAEAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAsAMAADYGAAAy BgAAGAAAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAE AACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA6AEAACAEAAAwBAAAQAQA AFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAA UAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQ BAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAE AABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQA AGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAA YAQAAHAEAACABAAAkAQAADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAgAAAAT0oDAFBKAwBR SgMAX0gBBG1ICQRuSAkEc0gJBHRICQQAAAAASgAAYPH/AgBKAAwQAAA0HykAAAAGAE4AbwByAG0A YQBsAAAADAAAABJkFAEBABSkyAAYAENKFgBfSAEEYUoWAG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAA AAAAAAAAAEQAQSDy/6EARAAMDAAAAAAAABAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIA YQBwAGgAIABGAG8AbgB0AAAAAABSAGkA8/+zAFIADA0AAAAAAAAwBgwAVABhAGIAbABlACAATgBv AHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAoAGsg9P/BACgA AA0AAAAAAAAwBgcATgBvACAATABpAHMAdAAAAAIADAAAAAAATgCmYPH/8gBOAAwUAAALC14AEAAN AE0AZQBkAGkAdQBtACAARwByAGkAZAAgADIAAAACAA8AGABDShYAX0gBBGFKFgBtSAkEc0gJBHRI CQSeAGVAAQACAZ4ADAgRAAsLXgAwBhEASABUAE0ATAAgAFAAcgBlAGYAbwByAG0AYQB0AHQAZQBk AAAAQQAQAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAA AAAAEmTwAAEAFKQAAAAgAENKFABPSgQAUEoAAFFKBABhShQAbUgAAHNIAAB0SAAAXAD+b/L/EQFc AAwAEAALC14AMAYWAEgAVABNAEwAIABQAHIAZQBmAG8AcgBtAGEAdAB0AGUAZAAgAEMAaABhAHIA AAAYAENKFABPSgQAUEoAAFFKBABeSgQAYUoUADQAVWDy/yEBNAAMCQAACwteADAGCQBIAHkAcABl AHIAbABpAG4AawAAAAkAPioBcGgAAP8AAFBLAwQUAAYACAAAACEA6d4Pv/8AAAAcAgAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyskctOwzAQRfdI/IPlLUqcskAIJemCx47HonzAyJkkFsnYsqdV+/dM 0lRCqCAWbCzZM/eeO+NyvR8HtcOYnKdKr/JCKyTrG0ddpd83T9mtVomBGhg8YaUPmPS6vrwoN4eA SYmaUqV75nBnTLI9jpByH5Ck0vo4Ass1diaA/YAOzXVR3BjriZE448lD1+UDtrAdWD3u5fmYJOKQ tLo/Nk6sSkMIg7PAktTsqPlGyRZCLsq5J/UupCuJoc1ZwlT5GbDoXmU10TWo3iDyC4wSw7AMiV/P ZyAZLea/O56J7NvWWWy83Y6yjnw2XsxOwf8UYPU/6BPTzH9bfwIAAP//AwBQSwMEFAAGAAgAAAAh AKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDh KH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN7 27VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cu j6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYA CAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQ QOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo 2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYK Ajj9AQAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1l MS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXY bYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5 QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxF jBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2Q U9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xut K1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlslii BmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K +BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0L SV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX 1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNx vhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpc VFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq 2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8Tqe KBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5 LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMRFb68 TrgTv4MpG2NiSg0UdadWxzT5u8LNKFRuy+HiCjeUyhdfP66Q+20t2Zuwe1XlzPaJQr0Id7I8d7kI 6NtfnbfwJNkjkBDzW9S74vyuOHv/+eK8KJ8vviTPqjAUaN2L2EbbtN3xwq57TBkbqCkjN6RpvCXs PUEfBvU6c+IkxSksjeBRZzIwcHChwGYNElx9RFU0iHAKTXvd00RCmZEOJUq5hMOiGa6krfHQ+Ct7 1GzqQ4itHBKrXR7Y4RU9nJ81CjJGqtAcaHNGK5rAWZmtXMmIgm6vw6yuhTozt7oRzRRFh1uhsjax OZSDyQvVYLCwJjQ1CFohsPIqnPk1azjsYEYCbXfro9wtxgsX6SIZ4YBkPtJ6z/uobpyUx8qcIloP Gwz64HiK1UrcWprsG3A7i5PK7BoL2OXeexMv5RE88xJQO5mOLCknJ0vQUdtrNZebHvJx2vbGcE6G xzgFr0vdR2IWwmWTr4QN+1OT2WT5zJutXDE3Cepw9WHtPqewUwdSIdUWlpENDTOVhQBLNCcr/3IT zHpRClRUo7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPadvY1K6V8oogYRMERGrGJ2Mfgfh2qoE9AJVx3 mIqgX+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ieyRZuClIhg3kriQe6VcpulDu/KiblL0iVchj/ z1TR+wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsCGgdTOyBa4H4XpiGo4ILa/BfkUP+3OWdpmLSG Q6TapyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFVElemVuwROSRsqGvgqt7bPRRBqJtqkpUBgzsZ f+57lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01Dk9u/ELFoD2a7ql1vlud7b1kRPTFrsxp5VgCz 0lbQytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCncISH9B/Y/Knxmv3boDXXI96G2Ivh4oYlB2EBU X7KNB9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQLvieMrSU7i7/PaeyiOXPZObl4kcbOLOzY2o4t NDV49mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJE0zwnUpg6KEHJg8g+S1Hs3TjLwAAAP//AwBQ SwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFn ZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7 l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQ ilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUo osbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQDp3g+//wAAABwCAAATAAAAAAAA AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEA AAsAAAAAAAAAAAAAAAAAMAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAA ABwAAAAAAAAAAAAAAAAAGQIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYA CAAAACEAMN1DKagGAACkGwAAFgAAAAAAAAAAAAAAAADWAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnht bFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAALIJAAB0aGVtZS90aGVt ZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAArQoAAAAAPD94bWwg dmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xy TWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwv MjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50 MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNjZW50ND0i YWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5r IiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAAAAQBUAAA4AACgAAAAA/////wAIAABYDQAASRUAAEAd AAAPAAAAEQAAABMAAAAACAAA5BQAAEAdAAAQAAAAEgAAAOACAACYAwAApwMAAFgFAAAQBgAAHwYA AEAVAAATWBT/FYwTWBT/FYwPAADwOAAAAAAABvAYAAAAAgQAAAIAAAABAAAAAQAAAAEAAAACAAAA QAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAAS AArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHw BAAAAAEAAAAAAAAA4xIAAOcSAADoEgAA9BIAAEIVAAAHAAMABwADAAcAAAAAAAkAAAAKAAAAngIA AJ8CAADOAwAA0gMAAEYGAABKBgAAtAcAAAkJAAALCQAAHQkAAB8JAAB0CgAAdgoAAPAKAADyCgAA BgsAAAgLAADSCwAA2gsAAPELAAD4CwAAGAwAAB8MAABNDAAAVAwAAH0MAACEDAAAmgwAAKEMAADG DAAAzQwAAOMMAADqDAAA/gwAAAUNAAAnDQAALg0AAEkNAABLDQAAXQ0AAF8NAAApDgAAMQ4AAEgO AABPDgAAbw4AAHYOAACLDgAAkg4AAKQOAACrDgAAwQ4AAMgOAADtDgAA9A4AAAoPAAARDwAAJQ8A ACwPAABODwAAVQ8AAHAPAAByDwAAew8AAIAPAADrEAAA7xAAAJISAACTEgAApRIAAKoSAACjEwAA pxMAAD8VAABCFQAABwAzAAcAMwAHADMABwAzAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAQAGhVx BAAAAAAAAAAAAAECAAIAFxdBRQAAAAAAAAAAAAECAAIARBw3agAAAAAAAAAAAAECAAIA63q0fwAA AAAAAAAAAAECAAIAAgAAAAQAAAAIAAAA5QAAAAAAAAABAAAAdVGKAD0ppgAAAAAAQBUAAEIVAAAA AAAAAQAAAP9AAwABALMTAAA/FQAAAAAAAAEAAQCzEwAAAAAAALMTAAAAAAAAAhAAAAAAAAAAQBUA AHAAABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP// AAACAP//AAAAAP//AAACAP//AAAAAAYAAABHHpABAAACAgYDBQQFAgME/yoA4EF4AMAJAAAAAAAA AP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1HpABAgAFBQECAQcGAgUH AAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzLpABAAACCwYEAgICAgIE/yoA 4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAANy6QAQAAAg8FAgICBAMCBP8CAOH/rABA CQAAAAAAAACfAQAAAAAAAEMAYQBsAGkAYgByAGkAAAA/PZABAAACBwMJAgIFAgQE/yoA4EN4AMAJ AAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAQRKQAQEAAgQFAwUEBgMCBAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAYQBtAGIAcgBpAGEAIABNAGEAdABoAAAAIgAEADEIiAgA 8NACAABoAQAAAAD0O+lG9DvpRgAAAAACAAEAAAArAwAAFRIAAAMACgAAAAQAA5AmAAAAKwMAABUS AAADAAoAAAAmAAAAAAAAADkEAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAFoAW0ALQA gYEyNAAAAAAAAAAAAAAAAAAANhUAADYVAAAAAAAAdZ3QAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACEuDcQDwEAAIAPz9AQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAhIUAAAAAAJ8P8PAAkkUAAA5AQAAP///3////9/////f////3// //9/////f////3/rbDIAAAQAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAhBAAAAAAAAAAAAAAAAAAA AAAAABAcAAAFAAAAAAAAAAAAeAAAAHgAAAAAAAAAAAAAAKAFAAAAAAAACwAAAAAAAADcAAAA//8S AAAAAAAAAAAAAAAAAAAADQBNAGEAcgBrACAATQBjAEYAYQBkAGQAZQBuAA0ATQBhAHIAawAgAE0A YwBGAGEAZABkAGUAbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr kQgAKyez2TAAAAAoNgAADgAAAAEAAAB4AAAABAAAAIAAAAAHAAAAmAAAAAgAAACoAAAACQAAAMAA AAASAAAAzAAAAAoAAADsAAAADAAAAPgAAAANAAAABAEAAA4AAAAQAQAADwAAABgBAAAQAAAAIAEA ABMAAAAoAQAAEQAAADABAAACAAAA5AQAAB4AAAAQAAAATWFyayBNY0ZhZGRlbgAAAB4AAAAIAAAA Tm9ybWFsAAAeAAAAEAAAAE1hcmsgTWNGYWRkZW4AAAAeAAAABAAAADIAAAAeAAAAGAAAAE1pY3Jv c29mdCBPZmZpY2UgV29yZAAAAEAAAAAARsMjAAAAAEAAAAAAGEyEzk7LAUAAAAAAGEyEzk7LAQMA AAADAAAAAwAAACsDAAADAAAAFRIAAAMAAAAAAAAARwAAAPA0AAD/////AwAAAAgAVlQkbUsYAQAJ AAADZxoAAAgAbQAAAAAABAAAAAMBCAAFAAAACwIAAAAABQAAAAwCIQQxAwQAAAAuARgAHAAAAPsC 8P8AAAAAAACQAQAAAAAEQAAiQ2FsaWJyaQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEA AAQAAAAtAQAABAAAAC0BAAAEAAAAAgEBAAUAAAAJAgAAAAIaAAAAMgpvAGAACgAEAAAAAAAwAyAE U2VjdGlvbiAxOgcACAAHAAUABAAIAAgABQAIAAQABQAAAAkCAAAAAg0AAAAyCm8AoAABAAQAAAAA ADADIAQgAAwABQAAAAkCAAAAAhwAAAD7AvD/AAAAAAAAvAIBAAAABEAAIkNhbGlicmkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAQAEAAAALQEBAAQAAAAtAQEABAAAAAIBAQAEAAAALQEB AAQAAAAtAQEABAAAAC0BAQAFAAAACQIAAAACGQAAADIKgwBgAAkABAAAAAAAMAMgBE9sZCB0ZXh0 OgALAAQACAAEAAYACAAHAAYABAAEAAAALQEAAAQAAAAtAQAABAAAAC0BAAAFAAAACQIAAAACDQAA ADIKgwCaAAEABAAAAAAAMAMgBCAADAAFAAAACQIAAAACHAAAAPsC8P8AAAAAAACQAQAAAAAEQAAx Q291cmllciBOZXcAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQECAAQAAAAtAQIABAAAAC0BAgAE AAAAAgEBAAcAAAD8AgAA//8AAgAABAAAAC0BAwAMAAAAQAkhAPAAAAAAAAAAEgAkAocAYAAHAAAA /AIAAP///wAAAAQAAAAtAQQABAAAAPABAwAFAAAACQIAAAACTAAAADIKlQBgACsABAAAAAAAMAMg BEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgb3duZXJzaGlwIG9mIHIACgAKAAkACgAKAAkA CgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAK AAkACgAKAAkACgAJAAoACgAFAAAACQIAAAACIgAAADIKlQD+AQ8ABAAAAAAAMAMgBGVnaXN0ZXJl ZCBwb3J0IAAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACQAFAAAACQIAAAACBAAAAAIBAQAH AAAA/AIAAP//AAIAAAQAAAAtAQMADAAAAEAJIQDwAAAAAAAAABIALgKZAGAABAAAAC0BBAAEAAAA 8AEDAAUAAAAJAgAAAAIdAAAAMgqnAGAADAAEAAAAAAAwAyAEbnVtYmVycyBhbmQgCgAKAAkACgAK AAkACgAJAAoACgAJAAoABQAAAAkCAAAAAg4AAAAyCqcA1AACAAQAAAAAADADIARzZQkACgAFAAAA CQIAAAACOgAAADIKpwDnAB8ABAAAAAAAMAMgBHJ2aWNlIG5hbWVzIHJlbWFpbnMgd2l0aCBJQU5B LiAACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkA CgAKAAkACgAFAAAACQIAAAACEAAAADIKpwARAgMABAAAAAAAMAMgBEZvcgAJAAoACgAFAAAACQIA AAACDQAAADIKpwAuAgEABAAAAAAAMAMgBCAACQAFAAAACQIAAAACGgAAADIKpwA3AgoABAAAAAAA MAMgBHByb3RvY29scyAKAAoACQAKAAkACgAKAAkACgAJAAUAAAAJAgAAAAIEAAAAAgEBAAcAAAD8 AgAA//8AAgAABAAAAC0BAwAMAAAAQAkhAPAAAAAAAAAAEgBeAqsAYAAEAAAALQEEAAQAAADwAQMA BQAAAAkCAAAAAiYAAAAyCrkAYAASAAQAAAAAADADIARkZXZlbG9wZWQgYnkgSUVURiAKAAoACQAK AAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAFAAAACQIAAAACOAAAADIKuQAOAR4ABAAAAAAA MAMgBHdvcmtpbmcgZ3JvdXBzLCBJQU5BIG5vdyBhbHNvIAkACgAJAAoACgAJAAoACQAKAAoACQAK AAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAUAAAAJAgAAAAIjAAAAMgq5AC4C EAAEAAAAAAAwAyAEb2ZmZXJzIGEgbWV0aG9kIAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAK AAkABQAAAAkCAAAAAgQAAAACAQEABwAAAPwCAAD//wACAAAEAAAALQEDAAwAAABACSEA8AAAAAAA AAATAEECvQBgAAQAAAAtAQQABAAAAPABAwAFAAAACQIAAAACIwAAADIKywBgABAABAAAAAAAMAMg BGZvciB0aGUgImVhcmx5IiAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAUAAAAJAgAA AAJEAAAAMgrLAPoAJgAEAAAAAAAwAyAEYXNzaWdubWVudCBvZiBwb3J0IG51bWJlcnMgYW5kIHNl cnZpY2UKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoA CgAJAAoACQAKAAoACQAKAAoACQAKAAkABQAAAAkCAAAAAg0AAAAyCssAZwIBAAQAAAAAADADIAQg AAoABQAAAAkCAAAAAg0AAAAyCssAcQIBAAQAAAAAADADIARuAAoABQAAAAkCAAAAAhMAAAAyCssA ewIFAAQAAAAAADADIARhbWVzIAAJAAoACQAKAAkABQAAAAkCAAAAAgQAAAAtAQAABAAAAC0BAAAE AAAALQEAAAQAAAACAQEABwAAAPwCAAD//wACAAAEAAAALQEDAAwAAABACSEA8AAAAAAAAAASAHcB 0ABgAAQAAAAtAQQABAAAAPABAwAEAAAALQECAAQAAAAtAQIABAAAAC0BAgAFAAAACQIAAAACLwAA ADIK3gBgABgABAAAAAAAMAMgBFtSRkM0MDIwXSwgYXMgZGVzY3JpYmVkIAoACgAJAAoACgAJAAoA CQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoACgAJAAUAAAAJAgAAAAIiAAAAMgreAEcBDwAE AAAAAAAwAyAEaW4gU2VjdGlvbiA4LjEuAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAQA AAAtAQAABAAAAC0BAAAEAAAALQEAAAUAAAAJAgAAAAINAAAAMgreANcBAQAEAAAAAAAwAyAEIAAJ AAUAAAAJAgAAAAIEAAAAAgEBAAQAAAAtAQEABAAAAC0BAQAEAAAALQEBAAUAAAAJAgAAAAINAAAA MgrxAGAAAQAEAAAAAAAwAyAEIAAMAAUAAAAJAgAAAAIEAAAAAgEBAAUAAAAJAgAAAAImAAAAMgoE AWAAEgAEAAAAAAAwAyAETmV3IHByb3Bvc2VkIHRleHQ6CwAIAAwAAwAIAAYACAAIAAgABgAIAAgA BgAGAAgABwAGAAQABQAAAAkCAAAAAg0AAAAyCgQB4wABAAQAAAAAADADIAQgAAoABQAAAAkCAAAA AgQAAAACAQEABwAAAPwCAAAA//8CAAAEAAAALQEDAAwAAABACSEA8AAAAAAAAAASAFQCCQFgAAQA AAAtAQQABAAAAPABAwAEAAAALQECAAQAAAAtAQIABAAAAC0BAgAFAAAACQIAAAACagAAADIKFwFg AD8ABAAAAAAAMAMgBElBTkEgaXMgdGhlIGF1dGhvcml0eSBmb3IgcmVnaXN0ZXJpbmcgcG9ydCBu dW1iZXJzIGFuZCBzZXJ2aWNlIAAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJ AAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoA CgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACQAFAAAACQIAAAACBAAAAAIBAQAHAAAA/AIA AAD//wIAAAQAAAAtAQMADAAAAEAJIQDwAAAAAAAAABIABwIbAWAABAAAAC0BBAAEAAAA8AEDAAUA AAAJAgAAAAJeAAAAMgopAWAANwAEAAAAAAAwAyAEbmFtZXMuICBUaGUgcmVnaXN0cmllcyB0aGF0 IGFyZSBjcmVhdGVkIHRvIHN0b3JlIHRoZXNlIAAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoA CgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAK AAkACgAJAAoACgAJAAoACgAJAAoACQAJAAUAAAAJAgAAAAIEAAAAAgEBAAcAAAD8AgAAAP//AgAA BAAAAC0BAwAMAAAAQAkhAPAAAAAAAAAAEgBUAi0BYAAEAAAALQEEAAQAAADwAQMABQAAAAkCAAAA AmoAAAAyCjsBYAA/AAQAAAAAADADIARyZWdpc3RyYXRpb25zIGFyZSBtYWludGFpbmVkIGJ5IElB TkEuICBGb3IgcHJvdG9jb2xzIGRldmVsb3BlZCAACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAK AAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoA CgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAkABQAAAAkCAAAAAgQAAAAC AQEABwAAAPwCAAAA//8CAAAEAAAALQEDAAwAAABACSEA8AAAAAAAAAASAGcCPwFgAAQAAAAtAQQA BAAAAPABAwAFAAAACQIAAAACFwAAADIKTQFgAAgABAAAAAAAMAMgBGJ5IElFVEYgCgAKAAkACgAK AAkACgAJAAUAAAAJAgAAAAJhAAAAMgpNAa0AOQAEAAAAAAAwAyAEd29ya2luZyBncm91cHMsIElB TkEgbm93IG9mZmVycyBhIG1ldGhvZCBmb3IgdGhlIJNlYXJseZQgAAoACgAJAAoACQAKAAoACQAK AAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoA CQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAJAAUAAAAJAgAAAAIEAAAAAgEB AAcAAAD8AgAAAP//AgAABAAAAC0BAwAMAAAAQAkhAPAAAAAAAAAAEgBUAlEBYAAEAAAALQEEAAQA AADwAQMABQAAAAkCAAAAAmoAAAAyCl8BYAA/AAQAAAAAADADIARhc3NpZ25tZW50IG9mIHBvcnQg bnVtYmVycyBhbmQgc2VydmljZSBuYW1lcyBbc2VlIFJGQzQwMjBdLCBhcyAACgAKAAkACgAKAAkA CgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAK AAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAkA BQAAAAkCAAAAAgQAAAACAQEABwAAAPwCAAAA//8CAAAEAAAALQEDAAwAAABACSEA8AAAAAAAAAAT APAAYwFgAAQAAAAtAQQABAAAAPABAwAFAAAACQIAAAACMQAAADIKcQFgABkABAAAAAAAMAMgBGRl c2NyaWJlZCBpbiBzZWN0aW9uIDguMS4ACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAK AAoACQAKAAkACgAKAAkACQAFAAAACQIAAAACDQAAADIKcQFQAQEABAAAAAAAMAMgBCAACgAFAAAA CQIAAAACBAAAAAIBAQAEAAAALQEAAAQAAAAtAQAABAAAAC0BAAAFAAAACQIAAAACDQAAADIKhQFg AAEABAAAAAAAMAMgBCAACQAFAAAACQIAAAACBAAAAAIBAQAFAAAACQIAAAACHQAAADIKmAFgAAwA BAAAAAAAMAMgBFNlY3Rpb24gNS4xOgcACAAHAAUABAAIAAgABQAIAAQACAAEAAUAAAAJAgAAAAIN AAAAMgqYAawAAQAEAAAAAAAwAyAEIAAMAAUAAAAJAgAAAAIEAAAAAgEBAAQAAAAtAQEABAAAAC0B AQAEAAAALQEBAAUAAAAJAgAAAAIZAAAAMgqsAWAACQAEAAAAAAAwAyAET2xkIHRleHQ6AAsABAAI AAQABgAIAAcABgAEAAQAAAAtAQAABAAAAC0BAAAEAAAALQEAAAUAAAAJAgAAAAINAAAAMgqsAZoA AQAEAAAAAAAwAyAEIAAJAAUAAAAJAgAAAAIEAAAAAgEBAAcAAAD8AgAA//8AAgAABAAAAC0BAwAM AAAAQAkhAPAAAAAAAAAAEgBUArABYAAEAAAALQEEAAQAAADwAQMABAAAAC0BAgAEAAAALQECAAQA AAAtAQIABQAAAAkCAAAAAlAAAAAyCr4BYAAuAAQAAAAAADADIARWYWxpZCBzZXJ2aWNlIG5hbWVz IE1VU1QgY29udGFpbiBvbmx5IHRoZXNlIFVTCgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoA CQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJ AAoACQAFAAAACQIAAAACDQAAADIKvgEaAgEABAAAAAAAMAMgBC0ACgAFAAAACQIAAAACFgAAADIK vgEkAgcABAAAAAAAMAMgBEFTQ0lJIFsACgAJAAoACgAJAAoACQAFAAAACQIAAP8CFgAAADIKvgFn AgcABAAAAAAAMAMgBEFOU0kuWDMACgAKAAkACgAJAAoACgAFAAAACQIAAP8CDQAAADIKvgGrAgEA BAAAAAAAMAMgBC0ACQAcAAAA+wLw/wAAAAAAAJABAAAAAARAADBDb3VyaWVyIE5ldwAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC0BAwAEAAAALQEDAAcAAAD8AgAAAAD/AgAABAAAAC0B BQAMAAAAQAkhAPAAAAAAAAAAAQBNAMEBZwIEAAAALQEEAAQAAADwAQUABQAAAAkCAAAAAgQAAAAC AQEABwAAAPwCAAD//wACAAAEAAAALQEFAAwAAABACSEA8AAAAAAAAAASAF4CwgFgAAQAAAAtAQQA BAAAAPABBQAEAAAALQECAAQAAAAtAQIABAAAAC0BAgAFAAAACQIAAP8CFAAAADIK0AFgAAYABAAA AAAAMAMgBDQuMTk4NgoACgAJAAoACgAJAAUAAAAJAgAAAAJiAAAAMgrQAZoAOgAEAAAAAAAwAyAE XSBjaGFyYWN0ZXJzOiBsZXR0ZXJzIGZyb20gQSB0byBaIGFuZCBhIHRvIHosIGRpZ2l0cyBmcm9t IAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkA CgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAK AAkABwAAAPwCAAAAAP8CAAAEAAAALQEFAAwAAABACSEA8AAAAAAAAAABADoA0wFgAAQAAAAtAQQA BAAAAPABBQAFAAAACQIAAAACBAAAAAIBAQAHAAAA/AIAAP//AAIAAAQAAAAtAQUADAAAAEAJIQDw AAAAAAAAABIAXgLUAWAABAAAAC0BBAAEAAAA8AEFAAQAAAAtAQIABAAAAC0BAgAEAAAALQECAAUA AAAJAgAAAAIsAAAAMgriAWAAFgAEAAAAAAAwAyAEMCB0byA5LCBhbmQgaHlwaGVucyAoIgoACgAJ AAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoABQAAAAkCAAAAAg0AAAAyCuIB NAEBAAQAAAAAADADIAQtAAoABQAAAAkCAAAAAhYAAAAyCuIBPgEHAAQAAAAAADADIAQiLCBBU0NJ AAkACgAJAAoACgAJAAoABQAAAAkCAAAAAj4AAAAyCuIBgQEiAAQAAAAAADADIARJIDB4MkQgb3Ig ZGVjaW1hbCA0NSkuICBUaGV5IE1VU1QgCQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAK AAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAFAAAACQIAAAACBAAAAAIBAQAHAAAA /AIAAP//AAIAAAQAAAAtAQUADAAAAEAJIQDwAAAAAAAAABMASwLmAWAABAAAAC0BBAAEAAAA8AEF AAUAAAAJAgAAAAJoAAAAMgr0AWAAPgAEAAAAAAAwAyAEYmUgYXQgbGVhc3Qgb25lIGNoYXJhY3Rl ciBhbmQgbm8gbW9yZSB0aGFuIGZpZnRlZW4gY2hhcmFjdGVycyAKAAoACQAKAAoACQAKAAkACgAK AAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoA CQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkABQAAAAkCAAAA AgQAAAACAQEABwAAAPwCAAD//wACAAAEAAAALQEFAAwAAABACSEA8AAAAAAAAAASAF4C+QFgAAQA AAAtAQQABAAAAPABBQAFAAAACQIAAAACawAAADIKBwJgAEAABAAAAAAAMAMgBGxvbmcsIE1VU1Qg Tk9UIGJlZ2luIG9yIGVuZCB3aXRoIGEgaHlwaGVuLCBhbmQgTVVTVCBOT1QgY29uc2lzdCAKAAoA CQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJ AAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkA CgAKAAkACgAJAAUAAAAJAgAAAAIEAAAAAgEBAAcAAAD8AgAA//8AAgAABAAAAC0BBQAMAAAAQAkh APAAAAAAAAAAEgAbAgsCYAAEAAAALQEEAAQAAADwAQUABQAAAAkCAAAAAmEAAAAyChkCYAA5AAQA AAAAADADIARvZiBvbmx5IGRpZ2l0cyAoaW4gb3JkZXIgdG8gYmUgZGlzdGluZ3Vpc2hhYmxlIGZy b20gcG9ydCAACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkA CgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAK AAkACgAKAAkABQAAAAkCAAAAAgQAAAACAQEABwAAAPwCAAD//wACAAAEAAAALQEFAAwAAABACSEA 8AAAAAAAAAASAPQBHQJgAAQAAAAtAQQABAAAAPABBQAFAAAACQIAAAACRgAAADIKKwJgACcABAAA AAAAMAMgBG51bWJlcnMsIHdoaWNoIGFyZSB0eXBpY2FsbHkgd3JpdHRlbiBhcwAKAAoACQAKAAoA CQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJ AAoACQAKAAoACQAFAAAACQIAAAACDQAAADIKKwLXAQEABAAAAAAAMAMgBCAACgAFAAAACQIAAAAC HQAAADIKKwLhAQwABAAAAAAAMAMgBGFsbCBkaWdpdHMpLgkACgAKAAkACgAJAAoACgAJAAoACgAJ AAUAAAAJAgAAAAINAAAAMgorAlQCAQAEAAAAAAAwAyAEIAAKAAUAAAAJAgAAAAIEAAAAAgEBAAQA AAAtAQAABAAAAC0BAAAEAAAALQEAAAUAAAAJAgAAAAINAAAAMgo+AmAAAQAEAAAAAAAwAyAEIAAJ AAUAAAAJAgAAAAIEAAAAAgEBAAQAAAAtAQEABAAAAC0BAQAEAAAALQEBAAUAAAAJAgAAAAImAAAA MgpSAmAAEgAEAAAAAAAwAyAETmV3IHByb3Bvc2VkIHRleHQ6CwAIAAwAAwAIAAYACAAIAAgABgAI AAgABgAGAAgABwAGAAQABQAAAAkCAAAAAg0AAAAyClIC4wABAAQAAAAAADADIAQgAAoABQAAAAkC AAAAAgQAAAACAQEABwAAAPwCAAAA//8CAAAEAAAALQEFAAwAAABACSEA8AAAAAAAAAASAFQCVgJg AAQAAAAtAQQABAAAAPABBQAEAAAALQECAAQAAAAtAQIABAAAAC0BAgAFAAAACQIAAAACUAAAADIK ZAJgAC4ABAAAAAAAMAMgBFZhbGlkIHNlcnZpY2UgbmFtZXMgTVVTVCBjb250YWluIG9ubHkgdGhl c2UgVVMKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkA CgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAUAAAAJAgAAAAINAAAAMgpk AhoCAQAEAAAAAAAwAyAELQAKAAUAAAAJAgAAAAIWAAAAMgpkAiQCBwAEAAAAAAAwAyAEQVNDSUkg WwAKAAkACgAKAAkACgAJAAUAAAAJAgAA/wIWAAAAMgpkAmcCBwAEAAAAAAAwAyAEQU5TSS5YMwAK AAoACQAKAAkACgAKAAUAAAAJAgAA/wINAAAAMgpkAqsCAQAEAAAAAAAwAyAELQAJAAcAAAD8AgAA AAD/AgAABAAAAC0BBQAMAAAAQAkhAPAAAAAAAAAAAQBNAGcCZwIEAAAALQEEAAQAAADwAQUABQAA AAkCAAAAAgQAAAACAQEABwAAAPwCAAAA//8CAAAEAAAALQEFAAwAAABACSEA8AAAAAAAAAASAF4C aAJgAAQAAAAtAQQABAAAAPABBQAEAAAALQECAAQAAAAtAQIABAAAAC0BAgAFAAAACQIAAP8CFAAA ADIKdgJgAAYABAAAAAAAMAMgBDQuMTk4NgoACgAJAAoACgAJAAUAAAAJAgAAAAJiAAAAMgp2ApoA OgAEAAAAAAAwAyAEXSBjaGFyYWN0ZXJzOiBsZXR0ZXJzIGZyb20gQSB0byBaIGFuZCBhIHRvIHos IGRpZ2l0cyBmcm9tIAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoA CQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoACgAJ AAoACQAKAAoACQAKAAkABwAAAPwCAAAAAP8CAAAEAAAALQEFAAwAAABACSEA8AAAAAAAAAABADoA eQJgAAQAAAAtAQQABAAAAPABBQAFAAAACQIAAAACBAAAAAIBAQAHAAAA/AIAAAD//wIAAAQAAAAt AQUADAAAAEAJIQDwAAAAAAAAABIAXgJ6AmAABAAAAC0BBAAEAAAA8AEFAAQAAAAtAQIABAAAAC0B AgAEAAAALQECAAUAAAAJAgAAAAIsAAAAMgqIAmAAFgAEAAAAAAAwAyAEMCB0byA5LCBhbmQgaHlw aGVucyAoIgoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoABQAAAAkC AAAAAg0AAAAyCogCNAEBAAQAAAAAADADIAQtAAoABQAAAAkCAAAAAkkAAAAyCogCPgEpAAQAAAAA ADADIAQiLCBBU0NJSSAweDJEIG9yIGRlY2ltYWwgNDUpLiAgVGhleSBNVVNUIAAJAAoACQAKAAoA CQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJAAoACgAJ AAoACQAKAAoACQAKAAkABQAAAAkCAAAAAgQAAAACAQEABwAAAPwCAAAA//8CAAAEAAAALQEFAAwA AABACSEA8AAAAAAAAAATAEsCjAJgAAQAAAAtAQQABAAAAPABBQAFAAAACQIAAAACaAAAADIKmgJg AD4ABAAAAAAAMAMgBGJlIGF0IGxlYXN0IG9uZSBjaGFyYWN0ZXIgYW5kIG5vIG1vcmUgdGhhbiBm aWZ0ZWVuIGNoYXJhY3RlcnMgCgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAK AAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoA CQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAUAAAAJAgAAAAIEAAAAAgEBAAcAAAD8AgAAAP// AgAABAAAAC0BBQAMAAAAQAkhAPAAAAAAAAAAEgAbAp8CYAAEAAAALQEEAAQAAADwAQUABQAAAAkC AAAAAkcAAAAyCq0CYAAoAAQAAAAAADADIARsb25nLCBNVVNUIE5PVCBiZWdpbiBvciBlbmQgd2l0 aCBhIGh5cGhlCgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkA CgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAFAAAACQIAAAACJQAAADIKrQLhAREABAAA AAAAMAMgBG4sIE1VU1QgTk9UIGhhdmUgAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoA CQAFAAAACQIAAAACBAAAAAIBAQAHAAAA/AIAAAD//wIAAAQAAAAtAQUADAAAAEAJIQDwAAAAAAAA ABIAQQKxAmAABAAAAC0BBAAEAAAA8AEFAAUAAAAJAgAAAAJnAAAAMgq/AmAAPQAEAAAAAAAwAyAE Y29uc2VjdXRpdmUgaHlwaGVucywgYW5kIE1VU1QgTk9UIGNvbnNpc3Qgb2Ygb25seSBkaWdpdHMg KGluIAAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkA CgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAK AAoACQAKAAkACgAJAAUAAAAJAgAAAAIEAAAAAgEBAAcAAAD8AgAAAP//AgAABAAAAC0BBQAMAAAA QAkhAPAAAAAAAAAAEgAbAsMCYAAEAAAALQEEAAQAAADwAQUABQAAAAkCAAAAAmEAAAAyCtECYAA5 AAQAAAAAADADIARvcmRlciB0byBiZSBkaXN0aW5ndWlzaGFibGUgZnJvbSBwb3J0IG51bWJlcnMs IHdoaWNoIGFyZSAACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAK AAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoA CQAKAAkACgAKAAkABQAAAAkCAAAAAgQAAAACAQEABwAAAPwCAAAA//8CAAAEAAAALQEFAAwAAABA CSEA8AAAAAAAAAASAD0B1QJgAAQAAAAtAQQABAAAAPABBQAFAAAACQIAAAACPQAAADIK4wJgACEA BAAAAAAAMAMgBHR5cGljYWxseSB3cml0dGVuIGFzIGFsbCBkaWdpdHMpLgAKAAoACQAKAAoACQAK AAkACgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACQAFAAAA CQIAAAACDQAAADIK4wKdAQEABAAAAAAAMAMgBCAACgAFAAAACQIAAAACBAAAAAIBAQAEAAAALQEA AAQAAAAtAQAABAAAAC0BAAAFAAAACQIAAAACDQAAADIK9gJgAAEABAAAAAAAMAMgBCAACQAFAAAA CQIAAAACBAAAAAIBAQAEAAAALQEBAAQAAAAtAQEABAAAAC0BAQAFAAAACQIAAAACGQAAADIKCgNg AAkABAAAAAAAMAMgBE9sZCB0ZXh0OgALAAQACAAEAAYACAAHAAYABAAFAAAACQIAAAACDQAAADIK CgOaAAEABAAAAAAAMAMgBCAACgAFAAAACQIAAAACHAAAAPsC8P8AAAAAAACQAQAAAAAEQAAxQ291 cmllciBOZXcAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEFAAQAAAAtAQUABAAAAC0BBQAEAAAA AgEBAAcAAAD8AgAA//8AAgAABAAAAC0BBgAMAAAAQAkhAPAAAAAAAAAAEgBUAg4DYAAEAAAALQEE AAQAAADwAQYABQAAAAkCAAAAAmoAAAAyChwDYAA/AAQAAAAAADADIARUaGUgc2VydmljZSBuYW1l IHN5bnRheCBNQVkgYmUgdXNlZCB0byB2YWxpZGF0ZSBhIHNlcnZpY2UgbmFtZSAACgAKAAkACgAK AAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoA CQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJ AAkABQAAAAkCAAAAAgMAAAAeAAcAAAAWBCAEMAMAAAAABAAAACcB//8EAAAAAgEBAAcAAAD8AgAA //8AAgAABAAAAC0BBgAMAAAAQAkhAPAAAAAAAAAAEgAkAiADYAAEAAAALQEEAAQAAADwAQYABQAA AAkCAAAAAh8AAAAyCi4DYAANAAQAAAAAADADIARzdHJpbmcsIGJ1dCBNAAoACgAJAAoACgAJAAoA CQAKAAoACQAKAAkABQAAAAkCAAAAAk8AAAAyCi4D3QAtAAQAAAAAADADIARVU1QgTk9UIGJlIHVz ZWQgZm9yIGFueSBvdGhlciBwdXJwb3NlIChlLmcuLCAACgAKAAkACgAKAAkACgAJAAoACgAJAAoA CQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAKAAkACgAJ AAoACgAJAAkABQAAAAkCAAAAAgMAAAAeAAcAAAAWBCAEMAMAAAAABAAAACcB//8EAAAAAgEBAAcA AAD8AgAA//8AAgAABAAAAC0BBgAMAAAAQAkhAPAAAAAAAAAAEgBeAjIDYAAEAAAALQEEAAQAAADw AQYABQAAAAkCAAAAAmsAAAAyCkADYABAAAQAAAAAADADIARkZWxpbmVhdGlvbikuICBBbnkgc3lz dGVtIHRoYXQgaW5jbHVkZXMgYSBzZXJ2aWNlIG5hbWUgaW5zaWRlIGEgCgAKAAkACgAKAAkACgAJ AAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkA CgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAF AAAACQIAAAACAwAAAB4ABwAAABYEIAQwAwAAAAAEAAAAJwH//wQAAAACAQEABwAAAPwCAAD//wAC AAAEAAAALQEGAAwAAABACSEA8AAAAAAAAAATAF4CRANgAAQAAAAtAQQABAAAAPABBgAFAAAACQIA AAACawAAADIKUgNgAEAABAAAAAAAMAMgBGxvbmdlciBzdHJpbmcgaXMgaXRzZWxmIHJlc3BvbnNp YmxlIGZvciBkZWxpbmVhdGluZyB0aGUgc2VydmljZSAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJ AAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkA CgAKAAkACgAJAAoACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAUAAAAJAgAAAAID AAAAHgAHAAAAFgQgBDADAAAAAAQAAAAnAf//BAAAAAIBAQAHAAAA/AIAAP//AAIAAAQAAAAtAQYA DAAAAEAJIQDwAAAAAAAAABIAZwJXA2AABAAAAC0BBAAEAAAA8AEGAAUAAAAJAgAAAAJtAAAAMgpl A2AAQQAEAAAAAAAwAyAEbmFtZS4gU3VjaCBzeXN0ZW1zIE1VU1QgTk9UIHJlbHkgb24gdGhlIHN5 bnRheCBvZiBhIHNlcnZpY2UgbmFtZSAACgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAK AAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoA CQAKAAoACQAKAAoACQAKAAkACgAKAAkACgAJAAoACgAJAAoACQAJAAUAAAAJAgAAAAIDAAAAHgAH AAAAFgQgBDADAAAAAAQAAAAnAf//BAAAAAIBAQAHAAAA/AIAAP//AAIAAAQAAAAtAQYADAAAAEAJ IQDwAAAAAAAAABIAAwFpA2AABAAAAC0BBAAEAAAA8AEGAAUAAAAJAgAAAAImAAAAMgp3A2AAEgAE AAAAAAAwAyAEYWxvbmUgZm9yIHN1Y2ggZGVsCgAKAAkACgAKAAkACgAJAAoACgAJAAoACQAKAAoA CQAKAAoABQAAAAkCAAAAAhkAAAAyCncDDgEJAAQAAAAAADADIARpbmVhdGlvbi4ACQAKAAkACgAK AAkACgAJAAkABQAAAAkCAAAAAg0AAAAyCncDYwEBAAQAAAAAADADIAQgAAoABQAAAAkCAAAAAgMA AAAeAAcAAAAWBCAEMAMAAAAABAAAACcB//8EAAAAAgEBAAUAAAAJAgAAAAINAAAAMgqJA2AAAQAE AAAAAAAwAyAEIAAKAAUAAAAJAgAAAAIDAAAAHgAHAAAAFgQgBDADAAAAAAQAAAAnAf//HAAAAPsC 8P8AAAAAAAC8AgEAAAAEQAAiQ2FsaWJyaQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEG AAQAAAAtAQYABAAAAC0BBgAEAAAAAgEBAAUAAAAJAgAAAAImAAAAMgqcA2AAEgAEAAAAAAAwAyAE TmV3IHByb3Bvc2VkIFRleHQ6CwAIAAwAAwAIAAYACAAIAAgABgAIAAgABgAIAAgABwAGAAQABQAA AAkCAAAAAg0AAAAyCpwD5QABAAQAAAAAADADIAQgAAoABQAAAAkCAAAAAgMAAAAeAAcAAAAWBCAE MAMAAAAABAAAACcB//8EAAAAAgEBAAQAAAAtAQUABAAAAC0BBQAEAAAALQEFAAUAAAAJAgAAAAIN AAAAMgqvA2AAAQAEAAAAAAAwAyAEIAAKAAUAAAAJAgAAAAIDAAAAHgAHAAAAFgQgBDADAAAAAAQA AAAnAf//HAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAHZYiFUAPOdQDu/d6naAAe92TNoP CkjnUA4EAAAALQEHAAQAAAAtAQcABQAAABQCAAAAAAUAAAATAiAEAAAFAAAAEwIgBDADBQAAABMC AAAwAwUAAAATAgAAAAAFAAAAFAIBAAEABQAAABMCHwQBAAUAAAATAh8ELwMFAAAAEwIBAC8DBQAA ABMCAQABAAUAAAAUAgIAAgAFAAAAEwIeBAIABQAAABMCHgQuAwUAAAATAgIALgMFAAAAEwICAAIA AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAGAQIA AAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a40 AQAA8AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIQAAAAGAAAAjAAAABEAAACUAAAAFwAAAJwA AAALAAAApAAAABAAAACsAAAAEwAAALQAAAAWAAAAvAAAAA0AAADEAAAADAAAANEAAAACAAAA5AQA AB4AAAAMAAAATWljcm9zb2Z0AAAAAwAAACYAAAADAAAACgAAAAMAAAA2FQAAAwAAAAAADgALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAAAgAAAB4AAAAGAAAA VGl0bGUAAwAAAAEAAAAA5AEAAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAAAEAAAAABAAAAAgAAAAwA AABfUElEX0hMSU5LUwACAAAA5AQAAEEAAACcAQAADAAAAAMAAABgACcAAwAAAAMAAAADAAAAAAAA AAMAAAAFAAAAHwAAADoAAABoAHQAdABwADoALwAvAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIA ZwAvAGgAdABtAGwALwBkAHIAYQBmAHQALQBpAGUAdABmAC0AdABzAHYAdwBnAC0AaQBhAG4AYQAt AHAAbwByAHQAcwAtADAANgAAAB8AAAATAAAAcgBlAGYALQBBAE4AUwBJAC4AWAAzAC0ANAAuADEA OQA4ADYAAAAAAAMAAABgACcAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAAADoAAABoAHQAdABw ADoALwAvAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwAvAGgAdABtAGwALwBkAHIAYQBmAHQA LQBpAGUAdABmAC0AdABzAHYAdwBnAC0AaQBhAG4AYQAtAHAAbwByAHQAcwAtADAANgAAAB8AAAAT AAAAcgBlAGYALQBBAE4AUwBJAC4AWAAzAC0ANAAuADEAOQA4ADYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAA BQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAAT AAAAFAAAAP7///8WAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEA AAAiAAAAIwAAAP7///8lAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAA ADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA PgAAAD8AAAD+////QQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAP7////9////SgAAAP7////+ /////v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdABy AHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////// //8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAABBAroXOTssBTAAAAIAAAAAAAAAAMQBU AGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA4AAgH/////BQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAV AAAAKh0AAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA0KAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAFg2AAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAABAAAAAAAAABAEMA bwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAA wAAAAAAAAEYgAAAATWljcm9zb2Z0IFdvcmQgOTctMjAwMyBEb2N1bWVudAAKAAAATVNXb3JkRG9j ABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --_002_05B243F724B2284986522B6ACD0504D7D341083169EXVPMBX1001ex_-- From touch@isi.edu Tue Sep 7 14:02:09 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C70B3A6981 for ; Tue, 7 Sep 2010 14:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 SYubPG0UU98n for ; Tue, 7 Sep 2010 14:02:08 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id AE7153A6956 for ; Tue, 7 Sep 2010 14:02:08 -0700 (PDT) Received: from [75.217.225.25] (25.sub-75-217-225.myvzw.com [75.217.225.25]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o87L1VSl024282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 14:01:42 -0700 (PDT) Message-ID: <4C86A82C.3020205@isi.edu> Date: Tue, 07 Sep 2010 14:01:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Mcfadden References: <05B243F724B2284986522B6ACD0504D7D341083169@EXVPMBX100-1.exc.icann.org> In-Reply-To: <05B243F724B2284986522B6ACD0504D7D341083169@EXVPMBX100-1.exc.icann.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o87L1VSl024282 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Making progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 21:02:09 -0000 Only one point... - I don't see why we care about consecutive hyphens; prohibiting that should be dropped Joe On 9/7/2010 1:51 PM, Mark Mcfadden wrote: > The most recent version in the repository has the changes suggested by Michelle and Pearl. The attachment has the before and after language. Of course, a simple diff is also going to provide you with a view of the small changes that were made. They were: > > - clarity in the introduction about the authority for registering port numbers and service names; > - the need to prohibit multiple consecutive hyphens in the service name; and, > - consistency of the contact and registration language in Section 8. > > mark > > Mark McFadden > mark.mcfadden@icann.org > IANA Resource Specialist From mark.mcfadden@icann.org Tue Sep 7 14:09:19 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006E73A6AD6 for ; Tue, 7 Sep 2010 14:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 JRYafHNOHhUN for ; Tue, 7 Sep 2010 14:09:18 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 1FD623A6989 for ; Tue, 7 Sep 2010 14:09:18 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 7 Sep 2010 14:09:46 -0700 From: Mark Mcfadden To: Joe Touch Date: Tue, 7 Sep 2010 14:07:52 -0700 Thread-Topic: Making progress Thread-Index: ActO0AEPFBm56eU0R/i26OUzxcy/BwAALsO+ Message-ID: <05B243F724B2284986522B6ACD0504D7D34108316A@EXVPMBX100-1.exc.icann.org> References: <05B243F724B2284986522B6ACD0504D7D341083169@EXVPMBX100-1.exc.icann.org>, <4C86A82C.3020205@isi.edu> In-Reply-To: <4C86A82C.3020205@isi.edu> 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: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Making progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 21:09:19 -0000 It wasn't my suggestion, but I believe that it is useful to avoid potential= confusion in names. this-svc and this--svc would be easy to confuse. I don't think that it (consecutive hyphens) is a= necessary syntax feature. mark Mark McFadden mark.mcfadden@icann.org IANA Resource Specialist ________________________________________ From: Joe Touch [touch@isi.edu] Sent: Tuesday, September 07, 2010 4:01 PM To: Mark Mcfadden Cc: Stuart Cheshire; port-srv-reg@ietf.org Subject: Re: Making progress Only one point... - I don't see why we care about consecutive hyphens; prohibiting that should be dropped Joe On 9/7/2010 1:51 PM, Mark Mcfadden wrote: > The most recent version in the repository has the changes suggested by Mi= chelle and Pearl. The attachment has the before and after language. Of co= urse, a simple diff is also going to provide you with a view of the small c= hanges that were made. They were: > > - clarity in the introduction about the authority for registering port nu= mbers and service names; > - the need to prohibit multiple consecutive hyphens in the service name; = and, > - consistency of the contact and registration language in Section 8. > > mark > > Mark McFadden > mark.mcfadden@icann.org > IANA Resource Specialist From touch@isi.edu Tue Sep 7 15:10:41 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D7D3A6973 for ; Tue, 7 Sep 2010 15:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.658 X-Spam-Level: X-Spam-Status: No, score=-102.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 l9pglStHdNhz for ; Tue, 7 Sep 2010 15:10:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 389763A6862 for ; Tue, 7 Sep 2010 15:10:32 -0700 (PDT) Received: from [75.217.170.146] (146.sub-75-217-170.myvzw.com [75.217.170.146]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o87M9Wav005309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 15:09:43 -0700 (PDT) Message-ID: <4C86B81E.3080808@isi.edu> Date: Tue, 07 Sep 2010 15:09:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Mcfadden References: <05B243F724B2284986522B6ACD0504D7D341083169@EXVPMBX100-1.exc.icann.org>, <4C86A82C.3020205@isi.edu> <05B243F724B2284986522B6ACD0504D7D34108316A@EXVPMBX100-1.exc.icann.org> In-Reply-To: <05B243F724B2284986522B6ACD0504D7D34108316A@EXVPMBX100-1.exc.icann.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Making progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 22:10:42 -0000 On 9/7/2010 2:07 PM, Mark Mcfadden wrote: > It wasn't my suggestion, but I believe that it is useful to avoid potential confusion in names. > > this-svc and > this--svc > > would be easy to confuse. I don't think that it (consecutive hyphens) is a necessary syntax feature. The issue only arises when there are multiple names with hyphens in the same place, and that can be avoided by IANA during registration. My concern is placing too many syntactical restrictions on the names. The only current restrictions are: - not all numeric (so a name is recognizable as such, rather than possibly being the port number it refers to) - no leading or trailing hyphen (not sure why this is required; it doesn't seem to mess with either the DNS or anything else, AFAICT) I would favor less restrictions, rather than more. Joe > ________________________________________ > From: Joe Touch [touch@isi.edu] > Sent: Tuesday, September 07, 2010 4:01 PM > To: Mark Mcfadden > Cc: Stuart Cheshire; port-srv-reg@ietf.org > Subject: Re: Making progress > > Only one point... > > - I don't see why we care about consecutive hyphens; prohibiting that > should be dropped > > Joe > > > On 9/7/2010 1:51 PM, Mark Mcfadden wrote: >> The most recent version in the repository has the changes suggested by Michelle and Pearl. The attachment has the before and after language. Of course, a simple diff is also going to provide you with a view of the small changes that were made. They were: >> >> - clarity in the introduction about the authority for registering port numbers and service names; >> - the need to prohibit multiple consecutive hyphens in the service name; and, >> - consistency of the contact and registration language in Section 8. >> >> mark >> >> Mark McFadden >> mark.mcfadden@icann.org >> IANA Resource Specialist From cheshire@apple.com Tue Sep 7 16:14:14 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69EA3A6997 for ; Tue, 7 Sep 2010 16:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 EGGQNs2QspTQ for ; Tue, 7 Sep 2010 16:14:12 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id D011E3A6973 for ; Tue, 7 Sep 2010 16:14:11 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 0654AADC1B79; Tue, 7 Sep 2010 16:14:40 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-40-4c86c75f69e3 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay11.apple.com (Apple SCV relay) with SMTP id 57.65.22738.F57C68C4; Tue, 7 Sep 2010 16:14:39 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 16:14:38 -0700 To: Michelle Cotton X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:14:14 -0000 On 3 Sep, 2010, at 12:01, Michelle Cotton wrote: > I agree with all the changes below. > Regarding the last point, can the service name aliases for future > registrations go in the notes column? > > Michelle I don't think there will be any future aliases. I don't see any reason to be allowing further creation of aliases that add nothing except being a new name for something else that already exists. If someone says they want to register a new service name "wibble" which is in fact identical in all respects to "telnet", using the same message formats for the same purpose on the same port, then the answer is they're not allowed to do that because it's a bad idea. It's like someone wanting to register IP protocol number 191 to be a new transport protocol identical in all respects to TCP, so that clients are now free to use *either* IP protocol number 6 *or* IP protocol number 191 to mean "TCP", and all servers have to handle both because a client may use either at the client's whim. And if one alias, why not ten or twenty different aliases for "TCP"? If someone wanted to do that we wouldn't allow them because it's a bad idea that serves no purpose. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Sep 7 16:15:26 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94F83A6AA9 for ; Tue, 7 Sep 2010 16:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 wJk0FBWkwkyY for ; Tue, 7 Sep 2010 16:15:25 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C01603A6A7A for ; Tue, 7 Sep 2010 16:15:24 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 39518ADC1D23; Tue, 7 Sep 2010 16:15:53 -0700 (PDT) X-AuditID: 11807137-b7b43ae00000547d-00-4c86c7a939bf Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay16.apple.com (Apple SCV relay) with SMTP id D3.1A.21629.9A7C68C4; Tue, 7 Sep 2010 16:15:53 -0700 (PDT) In-Reply-To: <05B243F724B2284986522B6ACD0504D7D341083169@EXVPMBX100-1.exc.icann.org> References: <05B243F724B2284986522B6ACD0504D7D341083169@EXVPMBX100-1.exc.icann.org> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <328D8A9E-FE84-4CCB-B102-2849A5DCE9A4@apple.com> Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 16:15:51 -0700 To: Mark Mcfadden X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Making progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:15:26 -0000 On 7 Sep, 2010, at 13:51, Mark Mcfadden wrote: > The most recent version in the repository has the changes suggested > by Michelle and Pearl. The attachment has the before and after > language. Of course, a simple diff is also going to provide you > with a view of the small changes that were made. They were: I see you added. Note that the historic "port name" is now the "service name" and follows the service name syntax defined in this section. To be strictly accurate, this should say: In approximately 98% of cases, the new "service name" is exactly the same as the old historic "short name" from the IANA web forms . In approximately 2% of cases, the new "service name" is derived from the old historic "short name" as described below in . > It wasn't my suggestion, but I believe that it is useful to avoid > potential confusion in names. > > this-svc and > this--svc > > would be easy to confuse. I don't think that it (consecutive > hyphens) is a necessary syntax feature. > > mark We can't stop people creating deliberately confusing names. Limiting length and character set is beneficial for implementation reasons. Prohibiting services called "23" or "6000-6063" is beneficial if it avoids developer confusion with ports or port ranges. Apart from addressing those specific concerns, I don't think we need to be adding additional restrictions. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Sep 7 16:16:04 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533F73A6AA3 for ; Tue, 7 Sep 2010 16:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.996 X-Spam-Level: X-Spam-Status: No, score=-106.996 tagged_above=-999 required=5 tests=[AWL=1.603, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 EGjjIL-MwJ87 for ; Tue, 7 Sep 2010 16:16:03 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 9E0023A6AC0 for ; Tue, 7 Sep 2010 16:16:01 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 249C8ADC1E59; Tue, 7 Sep 2010 16:16:30 -0700 (PDT) X-AuditID: 11807137-b7b43ae00000547d-ef-4c86c7cea9c8 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay16.apple.com (Apple SCV relay) with SMTP id FD.3A.21629.EC7C68C4; Tue, 7 Sep 2010 16:16:30 -0700 (PDT) In-Reply-To: <4C80B256.3090007@isode.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com> <4C80B256.3090007@isode.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <820B0E63-61CA-490F-9D3B-91E0D7830BA2@apple.com> Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 16:16:28 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:16:04 -0000 On 3 Sep, 2010, at 01:31, Alexey Melnikov wrote: >>> 2. Service Name Rules >>> >>> I liked Joe's earlier suggestion to disallow all-numeric service >>> names, to avoid service names that look like a numeric port >>> number. However, even with that rule, we still allow service >>> names like this: "6000-6063" (looks like the X Window System port >>> range). Do we care? We could prevent that by requiring that all >>> service names contain at least one alphabetic character. >>> >> I like that proposal. >> > Fine with me. I've made this change. The text now says: Valid service names: o MUST be at least 1 character and no more than 15 characters long o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45) o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') o MUST NOT begin or end with a hyphen The reason for requiring at least one letter is to avoid service names like "23" (could be confused with a numeric port number) or "6000-6063" (could be confused with a numeric port number range). Although service names may contain both upper-case and lower-case letters, case is ignored for comparison purposes, so both "http" and "HTTP" denote the same service. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Sep 7 16:28:05 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA5C3A69A6 for ; Tue, 7 Sep 2010 16:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pEY+92dG0odb for ; Tue, 7 Sep 2010 16:28:04 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 807AC3A6781 for ; Tue, 7 Sep 2010 16:28:04 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id B3EA2ADC25D0; Tue, 7 Sep 2010 16:28:32 -0700 (PDT) X-AuditID: 11807136-b7b3eae0000066cf-02-4c86caa02a28 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay15.apple.com (Apple SCV relay) with SMTP id B9.82.26319.0AAC68C4; Tue, 7 Sep 2010 16:28:32 -0700 (PDT) In-Reply-To: <4C8689C6.7080000@isi.edu> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> <675AFB53-CFEC-4BC1-9C9E-EF6D12529E37@apple.com> <4C8689C6.7080000@isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 16:28:31 -0700 To: Joe Touch X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:28:05 -0000 On 7 Sep, 2010, at 11:51, Joe Touch wrote: >>>> This implies that a given service name can have *different* port >>>> numbers assigned for different transport protocols. >>> >>> That is correct, and always has been. >> >> Can you give an example? > > DNS and NFS. DNS is 53 on TCP and 53 on UDP. NFS is 2049 on TCP and 2049 on UDP. Can you give an example where a given service name has *different* port numbers assigned for TCP and UDP? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Sep 7 16:29:45 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5193A6AC0 for ; Tue, 7 Sep 2010 16:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 J7eIL029PKju for ; Tue, 7 Sep 2010 16:29:44 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 55C323A6997 for ; Tue, 7 Sep 2010 16:29:44 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id C6BA1A6DF664; Tue, 7 Sep 2010 16:30:12 -0700 (PDT) X-AuditID: 11807136-b7b3eae0000066cf-e7-4c86cb049770 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay15.apple.com (Apple SCV relay) with SMTP id BA.23.26319.40BC68C4; Tue, 7 Sep 2010 16:30:12 -0700 (PDT) In-Reply-To: <4C8689C6.7080000@isi.edu> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> <675AFB53-CFEC-4BC1-9C9E-EF6D12529E37@apple.com> <4C8689C6.7080000@isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3875FA99-0C24-48BC-BF4F-6A153F070995@apple.com> Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 16:30:11 -0700 To: Joe Touch X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:29:45 -0000 > We only know that nobody registered "www" in your database; we > cannot know whether there are no apps that browse for this string. After about eight years of the whole world using "_http._tcp" you're claiming that some hermit somewhere is developing software that uses "_www._tcp" instead? That's about as likely as some hermit somewhere whose TCP stack uses IP protocol number 191 to mean "TCP". Good luck convincing printer companies to update their firmware to advertise a different service type to accommodate a non-existent web browser that's looking for the wrong service type. If such a web browser existed they'd have heard customer complaints for the last eight years (but of course they haven't, because this mythical web browser doesn't exist). > IMO, there is no such thing as primary. It's ALL and ANY - register > ALL, lookup ANY. That's the only way we know things will work. That's a terrible idea for efficiency on the network, and battery life, and I can't see any vendor deciding to do something so pointless. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Sep 7 17:16:19 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944B73A6AE8 for ; Tue, 7 Sep 2010 17:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 m2rdtcbpCZc9 for ; Tue, 7 Sep 2010 17:16:18 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 1330F3A6874 for ; Tue, 7 Sep 2010 17:16:18 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 59EBDA6E1B59; Tue, 7 Sep 2010 17:16:46 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-fb-4c86d5eeb624 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay11.apple.com (Apple SCV relay) with SMTP id 98.B6.22738.EE5D68C4; Tue, 7 Sep 2010 17:16:46 -0700 (PDT) In-Reply-To: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 17:16:44 -0700 To: Lars Eggert X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 00:16:19 -0000 On 3 Sep, 2010, at 01:15, Lars Eggert wrote: >> The service name syntax MAY be used to validate a service >> name >> string, but MUST NOT be used for any other purpose (e.g., >> delineation). Any system that includes a service name inside a >> longer string is itself responsible for delineating the service >> name. Such systems MUST NOT rely on the syntax of a service >> name >> alone for such delineation. >> >> I have no idea what that is talking about. It gives the sense of >> referring to something in particular, but doesn't actually say >> what. Regardless, I did my PhD in message framing and the syntax >> of marking boundaries, and I know of no basis for the claim that >> paragraph is making. > > (No idea either.) Does this convey our intended meaning better? Service names are purely opaque identifiers, and no semantics are implied by any superficial structure that a given service name may appear to have. For example, a company called "Example" may choose to register service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" products, but the "Example" company can't claim to "own" all service names beginning with "Example-", they can't prevent someone else registering "Example-Baz" for a different service, and they can't prevent other developers from using the "Example-Foo" and "Example-Bar" service types in order to interoperate with the "Foo" and "Bar" products. Service names are constructed using human-readable characters for mnemonic convenience for human developers; software should treat them as purely opaque identifiers and not attempt to parse them for any additional embedded meaning. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Sep 7 17:19:41 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149E33A6AFA for ; Tue, 7 Sep 2010 17:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 YQFV-jMjaIzY for ; Tue, 7 Sep 2010 17:19:39 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 7BB913A6AF9 for ; Tue, 7 Sep 2010 17:19:39 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id E60D9A6E1DAC; Tue, 7 Sep 2010 17:20:07 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-88-4c86d6b724c6 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay11.apple.com (Apple SCV relay) with SMTP id 15.77.22738.7B6D68C4; Tue, 7 Sep 2010 17:20:07 -0700 (PDT) In-Reply-To: <4C812B37.1030504@isi.edu> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E8FDD83-FE00-4446-B4E7-01B1809B000B@apple.com> Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 17:20:06 -0700 To: Joe Touch X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 00:19:41 -0000 On 3 Sep, 2010, at 10:07, Joe Touch wrote: >> For each service name, there may exist zero or more >> associated port >> number assignments. A port number assignment associated with >> a service >> name contains the transport protocol, port number and >> possibly additional >> data, such as a DCCP Service Code. >> >> This implies that a given service name can have *different* port >> numbers assigned for different transport protocols. > > That is correct, and always has been. > >> If we really want that then a lot of the rest of the document will >> have to change too. I propose we just delete it. > > Not sure it needs to be called out specifically. OK to delete, but > with > the understanding that we're already allowed to do this and it > shouldn't > affect anything. Okay, deleted. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Sep 7 17:22:01 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619EA3A6859 for ; Tue, 7 Sep 2010 17:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 WK5v7P9a08eD for ; Tue, 7 Sep 2010 17:22:00 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 5C8133A67C3 for ; Tue, 7 Sep 2010 17:22:00 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id D427DA6E1FA7; Tue, 7 Sep 2010 17:22:28 -0700 (PDT) X-AuditID: 11807134-b7cacae0000058e0-69-4c86d7444052 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay14.apple.com (Apple SCV relay) with SMTP id 26.2D.22752.447D68C4; Tue, 7 Sep 2010 17:22:28 -0700 (PDT) In-Reply-To: <4C812B37.1030504@isi.edu> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72977003-7A33-4859-A637-44673AC371B1@apple.com> Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 7 Sep 2010 17:22:26 -0700 To: Joe Touch X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 00:22:01 -0000 On 3 Sep, 2010, at 10:07, Joe Touch wrote: >> The details of how applications make use of DNS SRV >> should be >> specified in the documentation set of the application/ >> service. In >> the absence of such specification, prospective clients of a >> given >> service should not assume the existence of SRV RRs for this >> service or, if they have indications that this will be the case >> (e.g., by configuration), must assume the unextended naming >> scheme >> from for service discovery with DNS >> SRV, >> i.e., the Service Label is constructed from the Service Name >> registered in by prepending a single >> underscore character ("_"). >> >> This is nonsense and must go. What is "the unextended naming >> scheme"? There's no mention in RFC 2782 of "extended" or >> "unextended" naming. > > This refers to the appendix of the gudmundsson-dnsext-srv-clarify, > and I > would agree it should be removed too. > > Joe Okay, this is deleted too. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From touch@isi.edu Wed Sep 8 08:29:31 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52F53A685C for ; Wed, 8 Sep 2010 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 KkFHF9DTGZH6 for ; Wed, 8 Sep 2010 08:29:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id CC9FD3A6904 for ; Wed, 8 Sep 2010 08:29:29 -0700 (PDT) Received: from [75.212.217.53] (53.sub-75-212-217.myvzw.com [75.212.217.53]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o88FSxYP026287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 08:29:10 -0700 (PDT) Message-ID: <4C87ABBC.40506@isi.edu> Date: Wed, 08 Sep 2010 08:29:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> <675AFB53-CFEC-4BC1-9C9E-EF6D12529E37@apple.com> <4C8689C6.7080000@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o88FSxYP026287 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:29:31 -0000 On 9/7/2010 4:28 PM, Stuart Cheshire wrote: > On 7 Sep, 2010, at 11:51, Joe Touch wrote: > >>>>> This implies that a given service name can have *different* port >>>>> numbers assigned for different transport protocols. >>>> >>>> That is correct, and always has been. >>> >>> Can you give an example? >> >> DNS and NFS. > > DNS is 53 on TCP and 53 on UDP. > > NFS is 2049 on TCP and 2049 on UDP. > > Can you give an example where a given service name has *different* port > numbers assigned for TCP and UDP? Not yet. That's always been possible, and we need to reserve the right to do that to conserve the port number space. That's the whole point of not giving out the UDP if only TCP is needed (and the converse) - we can assign them to other protocols later, and if we end up needing a corresponding port on another protocol we can assign a different number. If we ensured that we'd always give matching numbers, there would be no point to giving out only the protocols requested. Joe From touch@isi.edu Wed Sep 8 08:34:09 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B441C3A696D for ; Wed, 8 Sep 2010 08:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 j-FizKsqJXNa for ; Wed, 8 Sep 2010 08:34:04 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 5B9463A695E for ; Wed, 8 Sep 2010 08:33:49 -0700 (PDT) Received: from [75.212.217.53] (53.sub-75-212-217.myvzw.com [75.212.217.53]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o88FXMC9027306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 08:33:32 -0700 (PDT) Message-ID: <4C87ACC3.2060007@isi.edu> Date: Wed, 08 Sep 2010 08:33:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> <675AFB53-CFEC-4BC1-9C9E-EF6D12529E37@apple.com> <4C8689C6.7080000@isi.edu> <3875FA99-0C24-48BC-BF4F-6A153F070995@apple.com> In-Reply-To: <3875FA99-0C24-48BC-BF4F-6A153F070995@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o88FXMC9027306 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:34:09 -0000 On 9/7/2010 4:30 PM, Stuart Cheshire wrote: >> We only know that nobody registered "www" in your database; we cannot >> know whether there are no apps that browse for this string. > > After about eight years of the whole world using "_http._tcp" you're > claiming that some hermit somewhere is developing software that uses > "_www._tcp" instead? > > That's about as likely as some hermit somewhere whose TCP stack uses IP > protocol number 191 to mean "TCP". Although I agree on the likelihood, simply declaring "there are no apps" is not how it's done. We would need to verify. > Good luck convincing printer companies to update their firmware to > advertise a different service type to accommodate a non-existent web > browser that's looking for the wrong service type. If such a web browser > existed they'd have heard customer complaints for the last eight years > (but of course they haven't, because this mythical web browser doesn't > exist). They'd have heard complaints ONLY if they didn't interoperate with other vendors (maybe even just themselves) who do things the same way. And even if they had heard complaints, it's equally unlikely you would have known about that. The overall point is we don't change things because of what we *think* is deployed; we always try to verify as thoroughly as possible. >> IMO, there is no such thing as primary. It's ALL and ANY - register >> ALL, lookup ANY. That's the only way we know things will work. > > That's a terrible idea for efficiency on the network, and battery life, > and I can't see any vendor deciding to do something so pointless. The whole efficiency of registering is based on the assumption that the number of registrations is much smaller than the number of lookups (i.e., writes << reads). Given that, there's hardly significant impact on network or battery life, and the potential benefit in interoperability (since nobody KNOWS for sure what the 'primary' name is) could easily be worth the coding effort. Joe From touch@isi.edu Wed Sep 8 09:01:36 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6B13A68E9 for ; Wed, 8 Sep 2010 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 2lX7gVSIeuaU for ; Wed, 8 Sep 2010 09:01:36 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 12F173A6807 for ; Wed, 8 Sep 2010 09:01:36 -0700 (PDT) Received: from [75.212.217.53] (53.sub-75-212-217.myvzw.com [75.212.217.53]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o88G14B7003445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 09:01:15 -0700 (PDT) Message-ID: <4C87B342.3040508@isi.edu> Date: Wed, 08 Sep 2010 09:01:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o88G14B7003445 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:01:37 -0000 On 9/7/2010 4:14 PM, Stuart Cheshire wrote: > On 3 Sep, 2010, at 12:01, Michelle Cotton wrote: > >> I agree with all the changes below. >> Regarding the last point, can the service name aliases for future >> registrations go in the notes column? >> >> Michelle > > > I don't think there will be any future aliases. > > I don't see any reason to be allowing further creation of aliases that > add nothing except being a new name for something else that already exists. The burden falls on the owner of the port. If they want to ask for aliases, e.g., to shift from an old product name to a new one, I can't see why we would care. There is impact, but only on that port anyway. However, I'd restrict it to the owner of the port only. A good example of this would be the STUN/TURN stuff we discussed recently. Joe From touch@isi.edu Wed Sep 8 09:06:54 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC8C3A67B1 for ; Wed, 8 Sep 2010 09:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.451 X-Spam-Level: X-Spam-Status: No, score=-103.451 tagged_above=-999 required=5 tests=[AWL=1.148, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 phi7SipYCte6 for ; Wed, 8 Sep 2010 09:06:53 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E96383A68E0 for ; Wed, 8 Sep 2010 09:06:52 -0700 (PDT) Received: from [75.212.217.53] (53.sub-75-212-217.myvzw.com [75.212.217.53]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o88G6iEC004408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 09:06:55 -0700 (PDT) Message-ID: <4C87B495.6080804@isi.edu> Date: Wed, 08 Sep 2010 09:06:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com> <4C80B256.3090007@isode.com> <820B0E63-61CA-490F-9D3B-91E0D7830BA2@apple.com> In-Reply-To: <820B0E63-61CA-490F-9D3B-91E0D7830BA2@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o88G6iEC004408 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:06:54 -0000 Hi, all, On 9/7/2010 4:16 PM, Stuart Cheshire wrote: > On 3 Sep, 2010, at 01:31, Alexey Melnikov wrote: > >>>> 2. Service Name Rules >>>> >>>> I liked Joe's earlier suggestion to disallow all-numeric service >>>> names, to avoid service names that look like a numeric port number. >>>> However, even with that rule, we still allow service names like >>>> this: "6000-6063" (looks like the X Window System port range). Do we >>>> care? We could prevent that by requiring that all service names >>>> contain at least one alphabetic character. >>>> >>> I like that proposal. >>> >> Fine with me. > > > I've made this change. The text now says: > > Valid service names: > > o MUST be at least 1 character and no more than 15 characters long > > o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and > 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or > decimal 45) > > o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') > > o MUST NOT begin or end with a hyphen > > The reason for requiring at least one letter is to avoid service > names like "23" (could be confused with a numeric port number) or > "6000-6063" (could be confused with a numeric port number range). But 3-4-5 can't be confused with a range, nor would 6000-45. AFAICT, range-like entries can and should be avoided by the registration procedure, the same way we avoid double hyphens that look too similar to single-hyphen names already registered. FWIW, I still don't like adding the "must have at least one alpha" rule, but IF we keep it, here's the ABNF: NAME = *(1*NUM [HYPHEN]) ALPHA *([HYPHEN] 1*ALPHANUM) > Although service names may contain both upper-case and lower-case > letters, case is ignored for comparison purposes, so both "http" and > "HTTP" denote the same service. Service names are already noted as case-insensitive. We typically record them in the database in lower case only; we do NOT retain any case as provided by the registrant to discourage the notion that case matters. Joe From touch@isi.edu Wed Sep 8 09:12:24 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E317C3A69E3 for ; Wed, 8 Sep 2010 09:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] 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 38DNXRI9ZzP0 for ; Wed, 8 Sep 2010 09:12:15 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BE0EB3A69FC for ; Wed, 8 Sep 2010 09:11:13 -0700 (PDT) Received: from [75.212.217.53] (53.sub-75-212-217.myvzw.com [75.212.217.53]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o88GAqKI005109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 09:11:02 -0700 (PDT) Message-ID: <4C87B58D.7040308@isi.edu> Date: Wed, 08 Sep 2010 09:10:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o88GAqKI005109 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] we need to make progress X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:12:24 -0000 On 9/7/2010 5:16 PM, Stuart Cheshire wrote: > On 3 Sep, 2010, at 01:15, Lars Eggert wrote: > >>> The service name syntax MAY be used to validate a service name >>> string, but MUST NOT be used for any other purpose (e.g., >>> delineation). Any system that includes a service name inside a >>> longer string is itself responsible for delineating the service >>> name. Such systems MUST NOT rely on the syntax of a service name >>> alone for such delineation. >>> >>> I have no idea what that is talking about. It gives the sense of >>> referring to something in particular, but doesn't actually say what. >>> Regardless, I did my PhD in message framing and the syntax of marking >>> boundaries, and I know of no basis for the claim that paragraph is >>> making. >> >> (No idea either.) > > > Does this convey our intended meaning better? > > Service names are purely opaque identifiers, and no semantics are > implied by any superficial structure that a given service name may appear > to have. For example, a company called "Example" may choose to register > service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" > products,but the "Example" company can't claim to "own" all service names > beginning with "Example-", they can't prevent someone else registering > "Example-Baz" for a different service, and they can't prevent other > developers from using the "Example-Foo" and "Example-Bar" service types in > order to interoperate with the "Foo" and "Bar" products. Service names are > constructed using human-readable characters for mnemonic convenience for > human developers; software should treat them as purely opaque identifiers > and not attempt to parse them for any additional embedded meaning. Yes, AFAICT. A better example might be: Example-foo-HTTP and Example-bar-SOAP 1) the prefix "example" isn't owned/reserved 2) the substrings "foo" and "bar" aren't owned/reserved 3) the substrings "HTTP" and "SOAP have *no* meaning at all; they do not indicate the presentation layer protocol over which these services operate. Joe From cheshire@apple.com Wed Sep 8 14:30:04 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72FAA3A69F3 for ; Wed, 8 Sep 2010 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.636 X-Spam-Level: X-Spam-Status: No, score=-106.636 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 os+RXfdEkeFe for ; Wed, 8 Sep 2010 14:30:03 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id A0F683A682E for ; Wed, 8 Sep 2010 14:30:01 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 6F366A71608A for ; Wed, 8 Sep 2010 14:30:29 -0700 (PDT) X-AuditID: 11807134-b7cacae0000058e0-91-4c8800758e2c Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 68.9C.22752.570088C4; Wed, 8 Sep 2010 14:30:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.43] (c-24-6-164-127.hsd1.ca.comcast.net [24.6.164.127]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8G00BED6ES5NB0@et.apple.com> for port-srv-reg@ietf.org; Wed, 08 Sep 2010 14:30:29 -0700 (PDT) From: Stuart Cheshire In-reply-to: <4C80B256.3090007@isode.com> Date: Wed, 08 Sep 2010 14:30:28 -0700 Message-id: References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com> <4C80B256.3090007@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 21:30:04 -0000 On 3 Sep 2010, at 1:31, Alexey Melnikov wrote: >> agree that we should use one name for the registry throughout. Am OK with your proposal; the main reason I put port numbers first in the title was that historically, that was what the registry was known as, and I didn't want to confuse people. >> > BTW, Alfred also raised this point, so changing the registry name would keep him happier. Okay, done. It's now "Service Name and Transport Protocol Port Number Registry" throughout. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Wed Sep 8 18:46:46 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259EC3A6885 for ; Wed, 8 Sep 2010 18:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.631 X-Spam-Level: X-Spam-Status: No, score=-106.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 itAK+Gx0Plgt for ; Wed, 8 Sep 2010 18:46:44 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id DFC9E3A6881 for ; Wed, 8 Sep 2010 18:46:44 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id B3E81ADFE5D9 for ; Wed, 8 Sep 2010 18:47:12 -0700 (PDT) X-AuditID: 11807137-b7b43ae00000547d-b5-4c883ca0a5ab Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id AA.14.21629.0AC388C4; Wed, 8 Sep 2010 18:47:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([24.6.164.127]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8G00BIIIAOKC80@elliott.apple.com> for port-srv-reg@ietf.org; Wed, 08 Sep 2010 18:47:12 -0700 (PDT) In-reply-to: <4C80B256.3090007@isode.com> References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com> <4C80B256.3090007@isode.com> Message-id: From: Stuart Cheshire Date: Wed, 08 Sep 2010 18:47:57 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 01:46:46 -0000 On 3 Sep 2010, at 1:31 AM, Alexey Melnikov wrote: >>> Would it be better to strictly use the terms "System Ports" and >>> "User Ports" to denote the ranges, and keep the term "registered >>> port" to just mean generically, "recorded by IANA in the Registry"? >>> >> We can also use the term "assigned" instead of "registered" in the >> second case. >> > Works for me. This is now also done and checked into svn. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Wed Sep 8 18:53:10 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E7C3A68EF for ; Wed, 8 Sep 2010 18:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.627 X-Spam-Level: X-Spam-Status: No, score=-106.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 SyjLfuwsRXyr for ; Wed, 8 Sep 2010 18:53:09 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 0D4D83A6881 for ; Wed, 8 Sep 2010 18:53:09 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id E7660A726260 for ; Wed, 8 Sep 2010 18:53:36 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-0a-4c883e2063d9 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id A4.5B.22738.02E388C4; Wed, 8 Sep 2010 18:53:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([24.6.164.127]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8G00G2VILBA900@elliott.apple.com> for port-srv-reg@ietf.org; Wed, 08 Sep 2010 18:53:36 -0700 (PDT) Message-id: <11ED4B07-AABE-4F4F-BED0-41BBDBF2ABE8@apple.com> From: Stuart Cheshire Date: Wed, 08 Sep 2010 18:54:23 -0700 To: port-srv-reg@ietf.org X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Subject: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 01:53:10 -0000 I see that Mark Mcfadden's checkin yesterday changed: @@ -874,8 +878,8 @@ Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) - Registration Administrative Contact (REQUIRED) - Registration Technical Contact (REQUIRED) + Registrant (REQUIRED) + Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) However, other places in the document still refer to "Administrative Contact" and "Technical Contact", which no longer make sense. Why was this changed? Do we need to reverse this change, or change the rest of the document to be consistent? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From mark.mcfadden@icann.org Thu Sep 9 07:42:47 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F153A68F2 for ; Thu, 9 Sep 2010 07:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 lmvSiy4gCbDE for ; Thu, 9 Sep 2010 07:42:39 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 0CBE43A6860 for ; Thu, 9 Sep 2010 07:42:39 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 9 Sep 2010 07:43:06 -0700 From: Mark Mcfadden To: Stuart Cheshire , "port-srv-reg@ietf.org" Date: Thu, 9 Sep 2010 07:42:34 -0700 Thread-Topic: Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" Thread-Index: ActPwd4HCenA4CquRX+zXMYkNOg69AAa1+hD Message-ID: <05B243F724B2284986522B6ACD0504D7D34108316E@EXVPMBX100-1.exc.icann.org> References: <11ED4B07-AABE-4F4F-BED0-41BBDBF2ABE8@apple.com> In-Reply-To: <11ED4B07-AABE-4F4F-BED0-41BBDBF2ABE8@apple.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: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:42:48 -0000 I need to go through and change the rest of the document so that it is cons= istent. Let me do that later today. mark Mark McFadden mark.mcfadden@icann.org IANA Resource Specialist ________________________________________ From: Stuart Cheshire [cheshire@apple.com] Sent: Wednesday, September 08, 2010 8:54 PM To: port-srv-reg@ietf.org Cc: Mark Mcfadden Subject: Inconsistent terminology regarding "Administrative Contact" and "T= echnical Contact" I see that Mark Mcfadden's checkin yesterday changed: @@ -874,8 +878,8 @@ Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) - Registration Administrative Contact (REQUIRED) - Registration Technical Contact (REQUIRED) + Registrant (REQUIRED) + Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) However, other places in the document still refer to "Administrative Contact" and "Technical Contact", which no longer make sense. Why was this changed? Do we need to reverse this change, or change the rest of the document to be consistent? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From touch@isi.edu Thu Sep 9 08:33:39 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C013A6891 for ; Thu, 9 Sep 2010 08:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 I+AqA1l8emGD for ; Thu, 9 Sep 2010 08:33:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BE1023A68B3 for ; Thu, 9 Sep 2010 08:33:29 -0700 (PDT) Received: from [75.217.58.205] (205.sub-75-217-58.myvzw.com [75.217.58.205]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o89FWjRJ009144 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2010 08:32:55 -0700 (PDT) Message-ID: <4C88FE1D.1050609@isi.edu> Date: Thu, 09 Sep 2010 08:32:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Mark Mcfadden References: <11ED4B07-AABE-4F4F-BED0-41BBDBF2ABE8@apple.com> <05B243F724B2284986522B6ACD0504D7D34108316E@EXVPMBX100-1.exc.icann.org> In-Reply-To: <05B243F724B2284986522B6ACD0504D7D34108316E@EXVPMBX100-1.exc.icann.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 15:33:39 -0000 FWIW, I'm a bit confused by the current terms. I think we all understand the goal - a tech contact and an owner. However, both require contact info, so both are 'contacts'. Further, the doc needs to be clear about aspects of a registration each contact is permitted to change. AFAICT (subject to IANA approval): tech POC - can change to anything EXCEPT tech POC and owner POC owner POC - can change anything When tech POC and owner POC disagree, owner POC wins. The key question is whether the tech POC can really change things at all without owner POC confirmation. Joe On 9/9/2010 7:42 AM, Mark Mcfadden wrote: > I need to go through and change the rest of the document so that it is consistent. > Let me do that later today. > > mark > > Mark McFadden > mark.mcfadden@icann.org > IANA Resource Specialist > ________________________________________ > From: Stuart Cheshire [cheshire@apple.com] > Sent: Wednesday, September 08, 2010 8:54 PM > To: port-srv-reg@ietf.org > Cc: Mark Mcfadden > Subject: Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" > > I see that Mark Mcfadden's checkin yesterday changed: > > @@ -874,8 +878,8 @@ > > Service Name (REQUIRED) > Transport Protocol(s) (REQUIRED) > - Registration Administrative Contact (REQUIRED) > - Registration Technical Contact (REQUIRED) > + Registrant (REQUIRED) > + Contact (REQUIRED) > Description (REQUIRED) > Reference (REQUIRED) > Port Number (OPTIONAL) > > However, other places in the document still refer to "Administrative > Contact" and "Technical Contact", which no longer make sense. > > Why was this changed? Do we need to reverse this change, or change > the rest of the document to be consistent? > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org > > _______________________________________________ > Port-srv-reg mailing list > Port-srv-reg@ietf.org > https://www.ietf.org/mailman/listinfo/port-srv-reg From cheshire@apple.com Tue Sep 14 14:28:26 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FA03A6AA9 for ; Tue, 14 Sep 2010 14:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.644 X-Spam-Level: X-Spam-Status: No, score=-105.644 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DIMKRvN7GKnV for ; Tue, 14 Sep 2010 14:28:25 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 2E34A3A6B2A for ; Tue, 14 Sep 2010 14:28:25 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id CC08DA89DA7A; Tue, 14 Sep 2010 14:28:50 -0700 (PDT) X-AuditID: 11807136-b7b3eae0000066cf-22-4c8fe912f447 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay15.apple.com (Apple SCV relay) with SMTP id 63.E4.26319.219EF8C4; Tue, 14 Sep 2010 14:28:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <4C88FE1D.1050609@isi.edu> References: <11ED4B07-AABE-4F4F-BED0-41BBDBF2ABE8@apple.com> <05B243F724B2284986522B6ACD0504D7D34108316E@EXVPMBX100-1.exc.icann.org> <4C88FE1D.1050609@isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C6EAD67-2F1C-49F3-A789-07E69DFB466B@apple.com> Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Tue, 14 Sep 2010 14:28:49 -0700 To: port-srv-reg@ietf.org, Joe Touch , Mark Mcfadden X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Subject: Re: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:28:26 -0000 On 9 Sep, 2010, at 08:32, Joe Touch wrote: > FWIW, I'm a bit confused by the current terms. I think we all > understand the goal - a tech contact and an owner. Except it's not an "owner", because we have, in previous versions of the draft, taken pains to stress that no one except IANA "owns" a port or service name: It is important to note that ownership of registered port numbers and service names remains with IANA. Can we get some agreement on the terminology and concepts here? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From michelle.cotton@icann.org Tue Sep 14 14:35:27 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC363A6AA9 for ; Tue, 14 Sep 2010 14:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.159 X-Spam-Level: X-Spam-Status: No, score=-106.159 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zzukmIdWcd8P for ; Tue, 14 Sep 2010 14:35:20 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id E58513A6958 for ; Tue, 14 Sep 2010 14:35:19 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 14 Sep 2010 14:35:45 -0700 From: Michelle Cotton To: Stuart Cheshire , "port-srv-reg@ietf.org" , Joe Touch , Mark Mcfadden Date: Tue, 14 Sep 2010 14:35:44 -0700 Thread-Topic: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" Thread-Index: ActUU+ES2m6UoaA3QZaAs9Qim2CXkgAAOgm0 Message-ID: In-Reply-To: <4C6EAD67-2F1C-49F3-A789-07E69DFB466B@apple.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8B538C028902michellecottonicannorg_" MIME-Version: 1.0 Subject: Re: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:35:27 -0000 --_000_C8B538C028902michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is why we suggested the following terminology: o Registrant: Name and email address of the Registrant. This is REQUIRED. = The Registrant is the Organization or Company responsible for the initial r= egistration. For registrations done through IETF-published RFCs, the Regis= trant will be the IESG. o Contact: Name and email address of the Contact person for the registr= ation. This is REQUIRED. The Contact person is the responsible person for t= he Internet community to send questions to. This person would also be auth= orized to submit changes on behalf of the Registrant. Additional address i= nformation MAY be provided. For registrations done through IETF-published = RFCs, the Contact will be the IESG. This also fits well with other registries where we will be applying the sam= e concept. If there is a better word for "registrant" I'm open for suggestions. Michelle On 9/14/10 2:28 PM, "Stuart Cheshire" wrote: On 9 Sep, 2010, at 08:32, Joe Touch wrote: > FWIW, I'm a bit confused by the current terms. I think we all > understand the goal - a tech contact and an owner. Except it's not an "owner", because we have, in previous versions of the draft, taken pains to stress that no one except IANA "owns" a port or service name: It is important to note that ownership of registered port numbers and service names remains with IANA. Can we get some agreement on the terminology and concepts here? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org _______________________________________________ Port-srv-reg mailing list Port-srv-reg@ietf.org https://www.ietf.org/mailman/listinfo/port-srv-reg --_000_C8B538C028902michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [port-srv-reg] Inconsistent terminology regarding "Administ= rative Contact" and "Technical Contact" This is why we suggested the following terminology:

o  Registrant: Name and email ad= dress of the Registrant. This is REQUIRED. The Registrant is the Organizati= on or Company responsible for the initial registration.  For registrat= ions done through IETF-published RFCs, the Registrant will be the IESG.

   o  Contact: Name and email address of the Contact pe= rson for the registration. This is REQUIRED. The Contact person is the resp= onsible person for the Internet community to send questions to.  This = person would also be authorized to submit changes on behalf of the Registra= nt.  Additional address information MAY be provided.  For registr= ations done through IETF-published RFCs, the Contact will be the IESG.

This also fits well with other registries where we will be applying the sam= e concept.
If there is a better word for “registrant” I’m open for s= uggestions.

Michelle


On 9/14/10 2:28 PM, "Stuart Cheshire" <cheshire@apple.com> wrote:

On 9 Sep, 2010, at 08:32, Joe Touch wrote:<= BR>
> FWIW, I'm a bit confused by the current terms. I think we all
> understand the goal - a tech contact and an owner.

Except it's not an "owner", because we have, in previous versions= of
the draft, taken pains to stress that no one except IANA "owns" a=
port or service name:

    It is important to note that ownership of registere= d port numbers
and
    service names remains with IANA.

Can we get some agreement on the terminology and concepts here?

Stuart Cheshire <cheshire@apple.com&g= t;
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

_______________________________________________
Port-srv-reg mailing list
Port-srv-reg@ietf.org
https://www.= ietf.org/mailman/listinfo/port-srv-reg

--_000_C8B538C028902michellecottonicannorg_-- From touch@isi.edu Tue Sep 14 14:40:25 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8EB3A6B3A for ; Tue, 14 Sep 2010 14:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3Gub2hHtP53g for ; Tue, 14 Sep 2010 14:40:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 871663A6958 for ; Tue, 14 Sep 2010 14:38:28 -0700 (PDT) Received: from [128.9.176.34] (c1-vpn4.isi.edu [128.9.176.34]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8ELb7JZ015875 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Sep 2010 14:37:08 -0700 (PDT) Message-ID: <4C8FEB03.3040008@isi.edu> Date: Tue, 14 Sep 2010 14:37:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Stuart Cheshire References: <11ED4B07-AABE-4F4F-BED0-41BBDBF2ABE8@apple.com> <05B243F724B2284986522B6ACD0504D7D34108316E@EXVPMBX100-1.exc.icann.org> <4C88FE1D.1050609@isi.edu> <4C6EAD67-2F1C-49F3-A789-07E69DFB466B@apple.com> In-Reply-To: <4C6EAD67-2F1C-49F3-A789-07E69DFB466B@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:40:44 -0000 On 9/14/2010 2:28 PM, Stuart Cheshire wrote: > On 9 Sep, 2010, at 08:32, Joe Touch wrote: > >> FWIW, I'm a bit confused by the current terms. I think we all >> understand the goal - a tech contact and an owner. > > Except it's not an "owner", because we have, in previous versions of the > draft, taken pains to stress that no one except IANA "owns" a port or > service name: Right. It's the "owner of the registration", i.e., the owner of the record that IANA lets them use... agreed that 'owner' is equally confusing. Joe > It is important to note that ownership of registered port numbers and > service names remains with IANA. > > Can we get some agreement on the terminology and concepts here? > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org From touch@isi.edu Tue Sep 14 14:50:32 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BECC3A6B3D for ; Tue, 14 Sep 2010 14:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 IyR6HDVm0TQB for ; Tue, 14 Sep 2010 14:50:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C4D503A6B34 for ; Tue, 14 Sep 2010 14:50:22 -0700 (PDT) Received: from [128.9.176.34] (c1-vpn4.isi.edu [128.9.176.34]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8ELnF3A019373 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Sep 2010 14:49:16 -0700 (PDT) Message-ID: <4C8FEDDB.9060205@isi.edu> Date: Tue, 14 Sep 2010 14:49:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Michelle Cotton References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:50:32 -0000 Hi, Michelle, The problem is that they're both contacts, and there's a problem staying that the contact is authorized to make changes for the registrant if you don't also say who wins when there's conflict (i.e., what happens when they disagree). IMO: registrant name of the party controlling the registration tech contact name of the party to whom tech questions are referred, but who can't modify the record In the DNS, FWIW, these are called: registrant party to whom registration is granted billing contact not applicable here administrative contact other managing party technical contact tech questions The precedence, AFAICT, is as follows, for the DNS: registrant > admin > tech/billing In our situation, we have only two, which correspondingly would be: registrant technical contact Where registrant > tech if any conflict arises. AFAICT, the tech contact also ought not be able to change the name of the service, but might be able to ask for the corresponding other transport protocol assignments. Joe On 9/14/2010 2:35 PM, Michelle Cotton wrote: > This is why we suggested the following terminology: > > o Registrant: Name and email address of the Registrant. This is > REQUIRED. The Registrant is the Organization or Company responsible for > the initial registration. For registrations done through IETF-published > RFCs, the Registrant will be the IESG. > > o Contact: Name and email address of the Contact person for the > registration. This is REQUIRED. The Contact person is the responsible > person for the Internet community to send questions to. This person > would also be authorized to submit changes on behalf of the Registrant. > Additional address information MAY be provided. For registrations done > through IETF-published RFCs, the Contact will be the IESG. > > This also fits well with other registries where we will be applying the > same concept. > If there is a better word for “registrant” I’m open for suggestions. > > Michelle > > > On 9/14/10 2:28 PM, "Stuart Cheshire" wrote: > > On 9 Sep, 2010, at 08:32, Joe Touch wrote: > > > FWIW, I'm a bit confused by the current terms. I think we all > > understand the goal - a tech contact and an owner. > > Except it's not an "owner", because we have, in previous versions of > the draft, taken pains to stress that no one except IANA "owns" a > port or service name: > > It is important to note that ownership of registered port numbers > and > service names remains with IANA. > > Can we get some agreement on the terminology and concepts here? > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org > > _______________________________________________ > Port-srv-reg mailing list > Port-srv-reg@ietf.org > https://www.ietf.org/mailman/listinfo/port-srv-reg > From michelle.cotton@icann.org Tue Sep 14 14:56:40 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFBE3A69B0 for ; Tue, 14 Sep 2010 14:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.172 X-Spam-Level: X-Spam-Status: No, score=-106.172 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1McogfB3iIRD for ; Tue, 14 Sep 2010 14:56:34 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 0DF4F3A6807 for ; Tue, 14 Sep 2010 14:56:34 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 14 Sep 2010 14:56:59 -0700 From: Michelle Cotton To: Joe Touch Date: Tue, 14 Sep 2010 14:56:57 -0700 Thread-Topic: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" Thread-Index: ActUVt/Vi3oOzstiTw2lgouxcyHECwAAOAkd Message-ID: In-Reply-To: <4C8FEDDB.9060205@isi.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8B53DB928916michellecottonicannorg_" MIME-Version: 1.0 Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Inconsistent terminology regarding "Administrative Contact" and "Technical Contact" X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:56:40 -0000 --_000_C8B53DB928916michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Part of me feels that the defining language is something that should possib= ly go in RFC5226bis. Let me discuss this issue with IESG folks and I'll get back to the group. Thanks, Michelle On 9/14/10 2:49 PM, "Joe Touch" wrote: Hi, Michelle, The problem is that they're both contacts, and there's a problem staying that the contact is authorized to make changes for the registrant if you don't also say who wins when there's conflict (i.e., what happens when they disagree). IMO: registrant name of the party controlling the registration tech contact name of the party to whom tech questions are referred, but who can't modify the record In the DNS, FWIW, these are called: registrant party to whom registration is granted billing contact not applicable here administrative contact other managing party technical contact tech questions The precedence, AFAICT, is as follows, for the DNS: registrant > admin > tech/billing In our situation, we have only two, which correspondingly would be: registrant technical contact Where registrant > tech if any conflict arises. AFAICT, the tech contact also ought not be able to change the name of the service, but might be able to ask for the corresponding other transport protocol assignments. Joe On 9/14/2010 2:35 PM, Michelle Cotton wrote: > This is why we suggested the following terminology: > > o Registrant: Name and email address of the Registrant. This is > REQUIRED. The Registrant is the Organization or Company responsible for > the initial registration. For registrations done through IETF-published > RFCs, the Registrant will be the IESG. > > o Contact: Name and email address of the Contact person for the > registration. This is REQUIRED. The Contact person is the responsible > person for the Internet community to send questions to. This person > would also be authorized to submit changes on behalf of the Registrant. > Additional address information MAY be provided. For registrations done > through IETF-published RFCs, the Contact will be the IESG. > > This also fits well with other registries where we will be applying the > same concept. > If there is a better word for "registrant" I'm open for suggestions. > > Michelle > > > On 9/14/10 2:28 PM, "Stuart Cheshire" wrote: > > On 9 Sep, 2010, at 08:32, Joe Touch wrote: > > > FWIW, I'm a bit confused by the current terms. I think we all > > understand the goal - a tech contact and an owner. > > Except it's not an "owner", because we have, in previous versions of > the draft, taken pains to stress that no one except IANA "owns" a > port or service name: > > It is important to note that ownership of registered port numbers > and > service names remains with IANA. > > Can we get some agreement on the terminology and concepts here? > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org > > _______________________________________________ > Port-srv-reg mailing list > Port-srv-reg@ietf.org > https://www.ietf.org/mailman/listinfo/port-srv-reg > --_000_C8B53DB928916michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [port-srv-reg] Inconsistent terminology regarding "Administ= rative Contact" and "Technical Contact" Part of me feels that the defining language is something that should = possibly go in RFC5226bis.
Let me discuss this issue with IESG folks and I’ll get back to the gr= oup.

Thanks,

Michelle

On 9/14/10 2:49 PM, "Joe Touch" <tou= ch@isi.edu> wrote:

Hi, Michelle,

The problem is that they're both contacts, and there's a problem staying that the contact is authorized to make changes for the registrant if you don't also say who wins when there's conflict (i.e., what happens when
they disagree).

IMO:

        registrant   &nbs= p;  name of the party controlling the registration

        tech contact   &n= bsp;name of the party to whom tech questions are
            &nb= sp;           referr= ed, but who can't modify the record

In the DNS, FWIW, these are called:

        registrant   &nbs= p;          party to whom= registration is granted

        billing contact   = ;      not applicable here

        administrative contact &nbs= p;other managing party

        technical contact  &nb= sp;    tech questions

The precedence, AFAICT, is as follows, for the DNS:

        registrant > admin > = tech/billing

In our situation, we have only two, which correspondingly would be:

        registrant

        technical contact

Where registrant > tech if any conflict arises. AFAICT, the tech contact=
also ought not be able to change the name of the service, but might be
able to ask for the corresponding other transport protocol assignments.

Joe



On 9/14/2010 2:35 PM, Michelle Cotton wrote:
> This is why we suggested the following terminology:
>
> o Registrant: Name and email address of the Registrant. This is
> REQUIRED. The Registrant is the Organization or Company responsible fo= r
> the initial registration. For registrations done through IETF-publishe= d
> RFCs, the Registrant will be the IESG.
>
> o Contact: Name and email address of the Contact person for the
> registration. This is REQUIRED. The Contact person is the responsible<= BR> > person for the Internet community to send questions to. This person > would also be authorized to submit changes on behalf of the Registrant= .
> Additional address information MAY be provided. For registrations done=
> through IETF-published RFCs, the Contact will be the IESG.
>
> This also fits well with other registries where we will be applying th= e
> same concept.
> If there is a better word for “registrant” I’m open = for suggestions.
>
> Michelle
>
>
> On 9/14/10 2:28 PM, "Stuart Cheshire" <cheshire@apple.com> wrote:
>
>     On 9 Sep, 2010, at 08:32, Joe Touch wrote:
>
>     >  FWIW, I'm a bit confused by the cur= rent terms. I think we all
>     >  understand the goal - a tech contac= t and an owner.
>
>     Except it's not an "owner", because = we have, in previous versions of
>     the draft, taken pains to stress that no one e= xcept IANA "owns" a
>     port or service name:
>
>     It is important to note that ownership of regi= stered port numbers
>     and
>     service names remains with IANA.
>
>     Can we get some agreement on the terminology a= nd concepts here?
>
>     Stuart Cheshire <cheshire@apple.com>
>     * Wizard Without Portfolio, Apple Inc.
>     * www.stuartcheshire.org
>
>     ______________________________________________= _
>     Port-srv-reg mailing list
>     Port-srv-reg= @ietf.org
>     https://www.ietf.org/mailman/listinfo/port-srv-reg
>

--_000_C8B53DB928916michellecottonicannorg_-- From magnus.westerlund@ericsson.com Thu Sep 16 02:11:21 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8093A6AD5 for ; Thu, 16 Sep 2010 02:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 v2lGyh32I4Jd for ; Thu, 16 Sep 2010 02:11:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id EB6393A68DD for ; Thu, 16 Sep 2010 02:11:12 -0700 (PDT) X-AuditID: c1b4fb39-b7b0bae000000f9a-8d-4c91df49e89b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 21.29.03994.94FD19C4; Thu, 16 Sep 2010 11:11:37 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 11:11:37 +0200 Received: from [153.88.17.84] ([153.88.17.84]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 11:11:36 +0200 Message-ID: <4C91DF48.5010009@ericsson.com> Date: Thu, 16 Sep 2010 11:11:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Joe Touch References: <4C87B342.3040508@isi.edu> In-Reply-To: <4C87B342.3040508@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Sep 2010 09:11:36.0102 (UTC) FILETIME=[29D1E460:01CB557F] X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 09:11:21 -0000 Joe Touch skrev 2010-09-08 18:01: > > > On 9/7/2010 4:14 PM, Stuart Cheshire wrote: >> On 3 Sep, 2010, at 12:01, Michelle Cotton wrote: >> >>> I agree with all the changes below. >>> Regarding the last point, can the service name aliases for future >>> registrations go in the notes column? >>> >>> Michelle >> >> >> I don't think there will be any future aliases. >> >> I don't see any reason to be allowing further creation of aliases that >> add nothing except being a new name for something else that already exists. > > The burden falls on the owner of the port. If they want to ask for > aliases, e.g., to shift from an old product name to a new one, I can't > see why we would care. There is impact, but only on that port anyway. > However, I'd restrict it to the owner of the port only. > > A good example of this would be the STUN/TURN stuff we discussed recently. > I think we should strongly recommend against alias for the first case like http and www. However STUN and TURN are not aliases, they are compatible services that can co-exist on the same port. Thus I wouldn't call them aliases at all. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 16 02:17:52 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49763A68E0 for ; Thu, 16 Sep 2010 02:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 eOJIrth6xrq8 for ; Thu, 16 Sep 2010 02:17:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0FD023A6A0C for ; Thu, 16 Sep 2010 02:17:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbeae00000772f-ba-4c91e0cb149d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 12.0B.30511.BC0E19C4; Thu, 16 Sep 2010 11:18:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 11:18:03 +0200 Received: from [153.88.17.84] ([153.88.17.84]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 11:18:03 +0200 Message-ID: <4C91E0CB.6010109@ericsson.com> Date: Thu, 16 Sep 2010 11:18:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Stuart Cheshire References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <1229C0AB-C21C-44C2-BE13-082307B5E3CE@nokia.com> <6774BA34-4CDC-4C83-885E-41986A5A8952@apple.com> In-Reply-To: <6774BA34-4CDC-4C83-885E-41986A5A8952@apple.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Sep 2010 09:18:03.0139 (UTC) FILETIME=[10830D30:01CB5580] X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Aliased service names X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 09:17:52 -0000 Stuart Cheshire skrev 2010-09-04 09:18: > On 3 Sep 2010, at 1:21, Lars Eggert wrote: > >> TURN is a backward-compatible extension of STUN. So if a client looks up "stun", a TURN server can offer service to that client. So a TURN server that wanted to support STUN would need to register both service names. > > Right, and that's okay. > > In this case TURN is not simply an alias for STUN. It's an extension. > > A server that offers TURN on a given port also offers STUN on that port, so it should advertise both. > > My point is that there's nothing to be gained by allowing variant names that are merely aliases for the exact same service. > Fully agreeing, however compatible services must be possible to register and allowed to co-exist on the port. However, that should be allowed currently. I think we are mostly discussing what descriptions are in the document. I think we should clarify that we recommend against any alias like www and http. From my perspective we can even disallow it but no strong preference for me. The second usage should both be endorsed and recommended when possible. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lars.eggert@nokia.com Thu Sep 16 02:24:55 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23903A6940 for ; Thu, 16 Sep 2010 02:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.37 X-Spam-Level: X-Spam-Status: No, score=-103.37 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 O27SMaspfbm9 for ; Thu, 16 Sep 2010 02:24:46 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 621C03A68E0 for ; Thu, 16 Sep 2010 02:24:44 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8G9P6BR009194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Sep 2010 12:25:06 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-11--768267103; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 16 Sep 2010 10:24:54 +0100 Message-Id: To: port-srv-reg@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Subject: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 09:24:55 -0000 --Apple-Mail-11--768267103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I read through the current svn version and am happy with it. We should = submit it once the alias discussion has been resolved. Lars= --Apple-Mail-11--768267103 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkxNjA5 MjQ1NFowIwYJKoZIhvcNAQkEMRYEFH9k4mYLRTkWskKTVUgwY6lFaMMiMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAB6fUhJlNVaKiZp/1Lj2lSYMTkpTpjUsh2vU2QVKYgOaLUKFex+h CpdofkC+zsJ2NmB4iGCxtWRIR/laEUvq5tOXlvrhqChD7ppAx6D3ME1h9w33gxN5xE1d7ep749OO wJf7iGofwxESg3cVGVkMiHLyyVwVIQ5YworZkc9SiJewLLASD0kZXtryiFUrZ1jI8VHq+I/L3ZkR rULrrJ3DuG+YG0u+VX0mq3BN6a+j7g+IVb39alKRpxd+1dBCFlZ62MipjhQbehjeG8A3aEhIwJAm mp1vNh/92oBV4uJpbJVIQi6h2YmOXjs1uci4x/pIZNK22UrHnnNRBbXNkJvoTJAAAAAAAAA= --Apple-Mail-11--768267103-- From magnus.westerlund@ericsson.com Thu Sep 16 03:12:49 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D843A69D3 for ; Thu, 16 Sep 2010 03:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 QWOpZhB0plEj for ; Thu, 16 Sep 2010 03:12:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E6E9A3A6A45 for ; Thu, 16 Sep 2010 03:12:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbeae00000772f-26-4c91edb704fa Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7F.D2.30511.7BDE19C4; Thu, 16 Sep 2010 12:13:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 12:13:11 +0200 Received: from [153.88.16.225] ([153.88.16.225]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 12:13:10 +0200 Message-ID: <4C91EDB6.6070300@ericsson.com> Date: Thu, 16 Sep 2010 12:13:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: port-srv-reg@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Sep 2010 10:13:10.0820 (UTC) FILETIME=[C40B1E40:01CB5587] X-Brightmail-Tracker: AAAAAA== Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 10:12:49 -0000 Lars Eggert skrev 2010-09-16 11:24: > Hi, > > I read through the current svn version and am happy with it. We should submit it once the alias discussion has been resolved. > > Lars I do have a few comments on the document. I hope to get them in later today. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 16 05:56:29 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB29B3A6ABD for ; Thu, 16 Sep 2010 05:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Fui2wDtI8S+2 for ; Thu, 16 Sep 2010 05:56:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E53703A69D3 for ; Thu, 16 Sep 2010 05:56:27 -0700 (PDT) X-AuditID: c1b4fb39-b7b0bae000000f9a-ab-4c9214143e2d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.68.03994.414129C4; Thu, 16 Sep 2010 14:56:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 14:56:52 +0200 Received: from [147.214.183.53] ([147.214.183.53]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Sep 2010 14:56:51 +0200 Message-ID: <4C921413.2010808@ericsson.com> Date: Thu, 16 Sep 2010 14:56:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: "port-srv-reg@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Sep 2010 12:56:51.0905 (UTC) FILETIME=[A1DDC310:01CB559E] X-Brightmail-Tracker: AAAAAA== Subject: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:56:30 -0000 Hi, I am back working and have now completed reviewing the discussion on the team list and the WG list. I also reviewed the published version 6 and all the changes from 6 until 07-to be based on SVN revision 68. I have the following comments. 1. Section 23 uses "RR" without expansion. I have fixed that and committed a new version. 2. I like the current alias text description of section 5. No need for further changes in my eyes except with the possibility that alias isn't the best word for what STUN and TURN does. 3. Section 5.1. As the ABNF etc has been discussed I think the current text mandating the text description over ABNF is good. 4. Section 7.2: IANA decisions are not required to be bound by these principles; other factors may come into play, and exceptions may occur where deemed in the best interest of the Internet. I find this a bit confusing. I assume the intention is to say that these are principles that should be followed. The hard rules are in Section 8. How do you interpret the above? I would also like to point out that the above quote can be interpreted to apply also on section 7.3 where rules are specified that I think are not possible for IANA to waive. 5. Section 7.3: Should really section 7.3 be under Section 7 at all? Doesn't this belong under Section 8.1? The reasons is that is is not principles but actual rules. 6. Section 8.1: o Transport Protocol(s): The transport protocol(s) for which the allocation is requested MUST be provided. This field is currently limited to one or more of TCP, UDP, SCTP, and DCCP. This field is required even for services with no port number. To me it is not clear what I should enter in the case of requesting only a service name and no ports. Should I list the transport protocols that my application is capable of using this service over? In that case I think a clarification is in order. 7. Section 8.1: Reserved numbers and names are assigned only after review by IANA and the IETF, and are accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. How is the review by IETF performed in the above case? I think that needs to be explicitly stated. 8. Section 8.1: The following text did diseaper from this section: If the registration request is for a service name alias (see Section 5), IANA needs to confirm with the administrative contact for the existing service name whether the registration of the alias is appropriate. I think for the STUN/TURN case it was a good rule that the registrant present where an extension has requested to be assigned a service name associated with the same port as a previous service name is contacted. This to ensure that they truly are compatible extensions rather that blatant attempt to do hostile takeover on the port. 9. Section 8.1: o Port Number: If assignment of a port number is desired, either the currently Unassigned or Reserved port number the requester suggests for allocation, or the text "ANY", MUST be provided. If only a service name is to be assigned, this field MUST be empty. If a specific port number is requested, IANA is encouraged to allocate the requested number. If the text "ANY" is specified, IANA will choose a suitable number from the User Ports range. Note that the applicant MUST NOT use the requested port prior to the completion of the registration. Is is worth clarifying that applicants requesting to register a System port must propose such a port. Either that or include an alias SYS to mean any in the System range. 10. Section 8.2 IANA should not re-assign port numbers that have been de-registered until all other available port numbers in the specific range have been assigned. I have changed "all other available" to "all unassigned" 11. Section 8.2: Service name de-registration. I saw it somewhere that it was proposed to allow de-registration of service name in the purpose of getting the HISTORIC stamp on the record. I think we should allow the registrant to request the service name to be marked historic rather the unassign it. 12. Section 8.2: Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that a given service name remain assigned even after all associated port number assignments have become de-registered. Under this policy, it will appear in the registry as if it had been created through a service name registration request that did not include any port numbers. When the above happens I think it should be made clear in the comment field what has happened. 13. Section 8.5: What is unclear is if the Registrant is allowed to perform an update if the legal name of the individual, organization or company is changed. I think we should allow it to ensure that IANA can keep their records up to date. However, the change history should make clear what has happened. In addition I think we are making a mistake by not allowing the registrant to be transfered. If a company sells its product line associated with a protocol to another company. The expertize to judge if an registration request will move. If only the contact information is moved to the "buyer" of the product line, I think IANA gets into the difficult situation to determine if the contact is allowed to answer questions or not on behalf of the registrant. 14. Section 10.2: I think we should update the registrations for UDP and TCP port 1021 and 1022. This to fill in the registrant and contact person correctly. I have done this, but I haven't include RFC 4727 in the "Updates" list nor added comments about what is done in other places than 10.2. 15. Appeal process: Do we need to explicitly define the appeal process? I think a pointer to Section 7 of RFC 5226 is sufficient, but I think it is worth pointing out that this is the appeal order that applies. I think a section 8.7 would be the appropriate place. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From touch@isi.edu Thu Sep 16 09:45:34 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9BD3A69E4 for ; Thu, 16 Sep 2010 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WjhdMoZYom4h for ; Thu, 16 Sep 2010 09:45:32 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 93BD43A6BB5 for ; Thu, 16 Sep 2010 09:44:47 -0700 (PDT) Received: from [128.9.176.211] (c2-vpn02.isi.edu [128.9.176.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o8GGie7m021436 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 16 Sep 2010 09:44:41 -0700 (PDT) Message-ID: <4C924978.4010602@isi.edu> Date: Thu, 16 Sep 2010 09:44:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Magnus Westerlund References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> In-Reply-To: <4C91DF48.5010009@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o8GGie7m021436 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 16:45:34 -0000 On 9/16/2010 2:11 AM, Magnus Westerlund wrote: > Joe Touch skrev 2010-09-08 18:01: >> >> >> On 9/7/2010 4:14 PM, Stuart Cheshire wrote: >>> On 3 Sep, 2010, at 12:01, Michelle Cotton wrote: >>> >>>> I agree with all the changes below. >>>> Regarding the last point, can the service name aliases for future >>>> registrations go in the notes column? >>>> >>>> Michelle >>> >>> >>> I don't think there will be any future aliases. >>> >>> I don't see any reason to be allowing further creation of aliases that >>> add nothing except being a new name for something else that already exists. >> >> The burden falls on the owner of the port. If they want to ask for >> aliases, e.g., to shift from an old product name to a new one, I can't >> see why we would care. There is impact, but only on that port anyway. >> However, I'd restrict it to the owner of the port only. >> >> A good example of this would be the STUN/TURN stuff we discussed recently. >> > > I think we should strongly recommend against alias for the first case > like http and www. However STUN and TURN are not aliases, they are > compatible services that can co-exist on the same port. Thus I wouldn't > call them aliases at all. Any time more than one string maps to the same port number it's a kind of an 'alias'. The only way for the client to know the difference is via in-band information. I.e., we would allow aliases for: - different services - that can be resolved in-band Unless BOTH of those apply, we would not allow aliases except: a) legacy (www, http) b) to support changeover to the new namespace Joe From lars.eggert@nokia.com Fri Sep 17 00:46:01 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190423A6BE5 for ; Fri, 17 Sep 2010 00:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 4lxddflA3UMc for ; Fri, 17 Sep 2010 00:46:00 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 7AECC3A6BCC for ; Fri, 17 Sep 2010 00:45:58 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8H7kMtB020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Sep 2010 10:46:22 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-7--687802562; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 17 Sep 2010 10:45:58 +0300 In-Reply-To: <4C924866.2090707@isi.edu> To: port-srv-reg@ietf.org References: <4C924866.2090707@isi.edu> Message-Id: <0D80A77F-A8CA-4F40-A27C-D011FD9096ED@nokia.com> X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 07:46:01 -0000 --Apple-Mail-7--687802562 Content-Type: multipart/mixed; boundary=Apple-Mail-6--687802607 --Apple-Mail-6--687802607 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2010-9-16, at 19:40, Joe Touch wrote: > can you send the txt? Text for svn rev 69 attached, plus a diff against -06. Lars --Apple-Mail-6--687802607 Content-Disposition: attachment; filename=draft-ietf-tsvwg-iana-ports-from--06.diff.html Content-Type: text/html; x-unix-mode=0644; name="draft-ietf-tsvwg-iana-ports-from--06.diff.html" Content-Transfer-Encoding: 7bit Diff: draft-ietf-tsvwg-iana-ports-06.txt - draft-ietf-tsvwg-iana-ports.txt
 draft-ietf-tsvwg-iana-ports-06.txt   draft-ietf-tsvwg-iana-ports.txt 
Transport Area Working Group M. Cotton Transport Area Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
Updates: 2780, 2782, 3828, 4340, L. Eggert Updates: 2780, 2782, 3828, 4340, L. Eggert
4960 (if approved) Nokia 4960 (if approved) Nokia
Intended status: BCP J. Touch Intended status: BCP J. Touch
Expires: November 27, 2010 USC/ISI Expires: March 21, 2011 USC/ISI
M. Westerlund M. Westerlund
Ericsson Ericsson
S. Cheshire S. Cheshire
Apple Apple
May 26, 2010 September 17, 2010
Internet Assigned Numbers Authority (IANA) Procedures for the Management Internet Assigned Numbers Authority (IANA) Procedures for the Management
of the Transport Protocol Port Number and Service Name Registry of the Service Name and Transport Protocol Port Number Registry
draft-ietf-tsvwg-iana-ports-06 draft-ietf-tsvwg-iana-ports-07
Abstract Abstract
This document defines the procedures that the Internet Assigned This document defines the procedures that the Internet Assigned
Numbers Authority (IANA) uses when handling registration and other Numbers Authority (IANA) uses when handling registration and other
requests related to the transport protocol port number and service requests related to the Service Name and Transport Protocol Port
name registry. It also discusses the rationale and principles behind Number Registry. It also discusses the rationale and principles
these procedures and how they facilitate the long-term sustainability behind these procedures and how they facilitate the long-term
of the registry. sustainability of the registry.
This document updates IANA's procedures by obsoleting Sections 8 and This document updates IANA's procedures by obsoleting Sections 8 and
9.1 of the IANA allocation guidelines [RFC2780], it updates the IANA 9.1 of the IANA allocation guidelines [RFC2780], and it updates the
allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP IANA allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and
[RFC4960], it updates the DNS SRV specification [RFC2782] to clarify SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782]
what a service name is and how it is registered. to clarify what a service name is and how it is registered.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 27, 2010. This Internet-Draft will expire on March 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conventions Used in this Document . . . . . . . . . . . . . . 7 4. Conventions Used in this Document . . . . . . . . . . . . . . 7
5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9
5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 9 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10
6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Port Numbers and Service Names for Experimentation . . . . 11 6.1. Service names and Port Numbers for Experimentation . . . . 11
7. Principles for Port Number and Service Name Registry 7. Principles for Service Name and Transport Protocol Port
Management . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Number Registry Management . . . . . . . . . . . . . . . . . . 12
7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12
7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 12 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13
7.3. Variances for Specific Port Number Ranges . . . . . . . . 15 7.3. Variances for Specific Port Number Ranges . . . . . . . . 15
8. IANA Procedures for Managing the Port Number and Service 8. IANA Procedures for Managing the Service Name and
Name Registry . . . . . . . . . . . . . . . . . . . . . . . . 16 Transport Protocol Port Number Registry . . . . . . . . . . . 16
8.1. Port Number and Service Name Registration . . . . . . . . 16 8.1. Service Name and Port Number Registration . . . . . . . . 16
8.2. Port Number and Service Name De-Registration . . . . . . . 19 8.2. Service Name and Port Number De-Registration . . . . . . . 19
8.3. Port Number and Service Name Re-Use . . . . . . . . . . . 19 8.3. Service Name and Port Number Re-Use . . . . . . . . . . . 20
8.4. Port Number and Service Name Revocation . . . . . . . . . 20 8.4. Service Name and Port Number Revocation . . . . . . . . . 20
8.5. Port Number and Service Name Transfers . . . . . . . . . . 21 8.5. Service Name and Port Number Transfers . . . . . . . . . . 21
8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 21 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 22 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 22
10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24
10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
For many years, the allocation and registration of new port number For many years, the allocation of new service names and port number
values and service names for use with the Transmission Control values for use with the Transmission Control Protocol (TCP) [RFC0793]
Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) and the User Datagram Protocol (UDP) [RFC0768] have had less than
[RFC0768] have had less than clear guidelines. New transport clear guidelines. New transport protocols have been added - the
protocols have been added - the Stream Control Transmission Protocol Stream Control Transmission Protocol (SCTP) [RFC4960] and the
(SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new
[RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have mechanisms like DNS SRV records [RFC2782] have been developed, each
been developed, each with separate registries and separate with separate registries and separate guidelines. The community also
guidelines. The community recognized the need for additional recognized the need for additional procedures beyond just assignment;
procedures beyond just assignment; notably modification, revocation, notably modification, revocation, and release.
and release.
A key factor of this procedural streamlining is to establish A key element of the procedural streamlining specified in this
identical registration procedures for all IETF transport protocols. document is to establish identical assignment procedures for all IETF
This document brings the IANA procedures for TCP and UDP in line with transport protocols. This document brings the IANA procedures for
those for SCTP and DCCP, resulting in a single process that TCP and UDP in line with those for SCTP and DCCP, resulting in a
requesters and IANA follow for all requests for all transport single process that requesters and IANA follow for all requests for
protocols, including those not yet defined. all transport protocols, including future protocols not yet defined.
In addition to detailing the IANA procedures for the initial In addition to detailing the IANA procedures for the initial
assignment of port numbers and service names, this document also assignment of service names and port numbers, this document also
specifies post-assignment procedures that until now have been handled specifies post-assignment procedures that until now have been handled
in an ad hoc manner. These include procedures to de-register a port in an ad hoc manner. These include procedures to de-register a port
number that is no longer in use, to re-use a port number allocated number that is no longer in use, to re-use a port number allocated
for one application that is no longer in use for another application, for one application that is no longer in use for another application,
and the procedure by which IANA can unilaterally revoke a prior port and the procedure by which IANA can unilaterally revoke a prior port
number registration. Section 8 discusses the specifics of these number assignment. Section 8 discusses the specifics of these
procedures and processes that requesters and IANA follow for all procedures and processes that requesters and IANA follow for all
requests for all current and future transport protocols. requests for all current and future transport protocols.
It is important to note that ownership of registered port numbers and IANA is the authority for assigning service names and port numbers.
service names remains with IANA. For protocols developed by IETF The registries that are created to store these registrations are
working groups, IANA now also offers a method for the "early" maintained by IANA. For protocols developed by IETF working groups,
assignment of port numbers and service names [RFC4020], as described IANA now also offers a method for the "early assignment" [RFC4020] of
in Section 8.1. service names and port numbers, as described in Section 8.1.
This document updates IANA's procedures for UDP and TCP port numbers This document updates IANA's procedures for UDP and TCP port numbers
by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines
[RFC2780]. (Note that different sections of the IANA allocation [RFC2780]. (Note that other sections of the IANA allocation
guidelines, relating to the protocol field values in IPv4 header, guidelines, relating to the protocol field values in IPv4 header,
were also updated in February 2008 [RFC5237].) This document also were also updated in February 2008 [RFC5237].) This document also
updates the IANA allocation procedures for DCCP [RFC4340] and SCTP updates the IANA allocation procedures for DCCP [RFC4340] and SCTP
[RFC4960]. [RFC4960].
The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares
the port space with UDP. The UDP-Lite specification says: "UDP-Lite the port space with UDP. The UDP-Lite specification says: "UDP-Lite
uses the same set of port number values assigned by the IANA for use uses the same set of port number values assigned by the IANA for use
by UDP". Thus the update of UDP procedures result in an update also by UDP". Thus the update of UDP procedures result in an update also
of the UDP-Lite procedures. of the UDP-Lite procedures.
This document also clarify what a service name is and how it is This document also clarifies what a service name is and how it is
registered. This will impact the DNS SRV specification, because that registered. This will impact the DNS SRV specification [RFC2782],
specification merely makes a brief mention that the symbolic names of because that specification merely makes a brief mention that the
services are defined in "Assigned Numbers" [RFC1700], without stating symbolic names of services are defined in "Assigned Numbers"
to which section of that 230-page document it refers. The DNS SRV [RFC1700], without stating to which section it refers within that
specification may have been referring to the list of Port Assignments 230-page document. The DNS SRV specification may have been referring
(known as /etc/services on Unix), or to the "Protocol And Service to the list of Port Assignments (known as /etc/services on Unix), or
Names" section, or to both, or to some other section. Furthermore, to the "Protocol And Service Names" section, or to both, or to some
"Assigned Numbers" is now obsolete [RFC3232] and has now been other section. Furthermore, "Assigned Numbers" is now obsolete
replaced by on-line registries [PORTREG][PROTSERVREG]. There are [RFC3232] and has been replaced by on-line registries
additional updates and clarifications on how DNS SRV utilize the [PORTREG][PROTSERVREG].
Service name registry created in this document in "Clarification of
DNS SRV Owner Names" [I-D.gudmundsson-dnsext-srv-clarify].
The development of new transport protocols is a major effort that the The development of new transport protocols is a major effort that the
IETF does not undertake very often. If a new transport protocol is IETF does not undertake very often. If a new transport protocol is
standardized in the future, for the purpose of uniformity it is standardized in the future, for consistency it is expected to follow
expected to follow as much as possible the guidelines and practices as much as possible the guidelines and practices around using service
around using port numbers and service names. names and port numbers.
2. Motivation 2. Motivation
Information about the registration procedures for the port registry Information about the registration procedures for the port registry
has existed in three locations: the forms for requesting port number has existed in three locations: the forms for requesting port number
registrations on the IANA web site [SYSFORM] [USRFORM], an registrations on the IANA web site [SYSFORM] [USRFORM], an
introductory text section in the file listing the port number introductory text section in the file listing the port number
registrations themselves [PORTREG], and two brief sections of the registrations themselves [PORTREG], and two brief sections of the
IANA Allocation Guidelines [RFC2780]. IANA Allocation Guidelines [RFC2780].
Similarly, the procedures surrounding service names have been Similarly, the procedures surrounding service names have been
historically unclear. Service names were originally created as historically unclear. Service names were originally created as
mnemonic identifiers for port numbers without a well-defined syntax, mnemonic identifiers for port numbers without a well-defined syntax,
beyond the 14-character limit mentioned on the IANA website [SYSFORM] beyond the 14-character limit mentioned on the IANA website [SYSFORM]
[USRFORM]. Even that length limit has not been consistently applied, [USRFORM]. Even that length limit has not been consistently applied,
and some assigned service names are 15 characters long. When service and some assigned service names are 15 characters long. When service
identification via DNS SRV RRs was introduced, the requirement by identification via DNS SRV Resource Records (RRs) was introduced, the
IANA to only assign service names and port numbers in combination, requirement by IANA to only assign service names and port numbers in
led to the creation of an ad hoc service name registry outside of the combination, led to the creation of an ad hoc service name registry
control of IANA [SRVREG]. outside of the control of IANA [SRVREG].
This document aggregates all this scattered information into a single This document aggregates all this scattered information into a single
reference that aligns and clearly defines the management procedures reference that aligns and clearly defines the management procedures
for both port numbers and service names. It gives more detailed for both service names and port numbers. It gives more detailed
guidance to prospective requesters of ports and service names than guidance to prospective requesters of service names and ports than
the existing documentation, and it streamlines the IANA procedures the existing documentation, and it streamlines the IANA procedures
for the management of the registry, so that management requests can for the management of the registry, so that management requests can
complete in a timely manner. complete in a timely manner.
This document defines rules for registration of service names without This document defines rules for registration of service names without
associated port numbers, for such usages as DNS SRV records associated port numbers, for such usages as DNS SRV records
[RFC2782], which was not possible under the previous IANA procedures. [RFC2782], which was not possible under the previous IANA procedures.
The document also merges service name registrations from the non-IANA The document also merges service name registrations from the non-IANA
ad hoc registry [SRVREG] and from the IANA "Protocol and Service ad hoc registry [SRVREG] and from the IANA "Protocol and Service
Names" registry [PROTSERVREG] into the IANA "Port and Service Name" Names" registry [PROTSERVREG] into the IANA "Service Name and
registry [PORTREG], which from here on is the single authoritative Transport Protocol Port Number" registry [PORTREG], which from here
registry for service names and port numbers. on is the single authoritative registry for service names and port
numbers.
An additional purpose of this document is to describe the principles An additional purpose of this document is to describe the principles
that guide the IETF and IANA in their role as the long-term joint that guide the IETF and IANA in their role as the long-term joint
stewards of the port number registry. TCP and UDP have been a stewards of the service name and port number registry. TCP and UDP
remarkable success over the last decades. Thousands of applications have had remarkable success over the last decades. Thousands of
and application-level protocols have registered ports and service applications and application-level protocols have service names and
names for their use, and there is every reason to believe that this ports assigned for their use, and there is every reason to believe
trend will continue into the future. It is hence extremely important that this trend will continue into the future. It is hence extremely
that management of the registry follow principles that ensure its important that management of the registry follow principles that
long-term usefulness as a shared resource. Section 7 discusses these ensure its long-term usefulness as a shared resource. Section 7
principles in detail. discusses these principles in detail.
3. Background 3. Background
The Transmission Control Protocol (TCP) [RFC0793] and the User The Transmission Control Protocol (TCP) [RFC0793] and the User
Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success
over the decades as the two most widely used transport protocols on over the decades as the two most widely used transport protocols on
the Internet. They have relied on the concept of "ports" as logical the Internet. They have relied on the concept of "ports" as logical
entities for Internet communication. Ports serve two purposes: entities for Internet communication. Ports serve two purposes:
first, they provide a demultiplexing identifier to differentiate first, they provide a demultiplexing identifier to differentiate
transport sessions between the same pair of endpoints, and second, transport sessions between the same pair of endpoints, and second,
they may also identify the application protocol and associated they may also identify the application protocol and associated
service to which processes bind. Newer transport protocols, such as service to which processes bind. Newer transport protocols, such as
the Stream Control Transmission Protocol (SCTP) [RFC4960] and the the Stream Control Transmission Protocol (SCTP) [RFC4960] and the
Datagram Congestion Control Protocol (DCCP) [RFC4342] have adopted Datagram Congestion Control Protocol (DCCP) [RFC4342] have also
the concept of ports for their communication sessions and use 16-bit adopted the concept of ports for their communication sessions and use
port numbers in the same way as TCP and UDP (and UDP-Lite [RFC3828], sixteen-bit port numbers in the same way as TCP and UDP (and UDP-Lite
a variant of UDP). [RFC3828], a variant of UDP).
Port numbers are the original and most widely used means for Port numbers are the original and most widely used means for
application and service identification on the Internet. Ports are application and service identification on the Internet. Ports are
16-bit numbers, and the combination of source and destination port sixteen-bit numbers, and the combination of source and destination
numbers together with the IP addresses of the communicating end port numbers together with the IP addresses of the communicating end
systems uniquely identifies a session of a given transport protocol. systems uniquely identifies a session of a given transport protocol.
Port numbers are also known by their associated service names such as
Port numbers are also known by their corresponding service names such "telnet" for port number 23 and "http" (and the "www" and "www-http"
as "telnet" for port number 23 and "http" (and the "www" alias) for aliases) for port number 80.
port number 80.
Hosts running services, hosts accessing services on other hosts, and Hosts running services, hosts accessing services on other hosts, and
intermediate devices (such as firewalls and NATs) that restrict intermediate devices (such as firewalls and NATs) that restrict
services need to agree on which service corresponds to a particular services need to agree on which service corresponds to a particular
destination port. Although this is ultimately a local decision with destination port. Although this is ultimately a local decision with
meaning only between the endpoints of a connection, it is common for meaning only between the endpoints of a connection, it is common for
many services to have a default port upon which those servers usually many services to have a default port upon which those servers usually
listen, when possible, and these ports are recorded by the Internet listen, when possible, and these ports are recorded by the Internet
Assigned Numbers Authority (IANA) through the port number registry Assigned Numbers Authority (IANA) through the service name and port
[PORTREG]. number registry [PORTREG].
Over time, the assumption that a particular port number necessarily Over time, the assumption that a particular port number necessarily
implies a particular service may become less true. For example, implies a particular service may become less true. For example,
multiple instances of the same service on the same host cannot multiple instances of the same service on the same host cannot
generally listen on the same port, and multiple hosts behind the same generally listen on the same port, and multiple hosts behind the same
NAT gateway cannot all have a mapping for the same port on the NAT gateway cannot all have a mapping for the same port on the
external side of the NAT gateway, whether using static port mappings external side of the NAT gateway, whether using static port mappings
configured by hand by the user, or dynamic port mappings configured configured by hand by the user, or dynamic port mappings configured
automatically using a port mapping protocol NAT Port Mapping Protocol automatically using a port mapping protocol like NAT Port Mapping
(NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device (IGD) Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device
[IGD]. (IGD) [IGD].
Applications either use numeric port numbers directly, look up port Applications may use numeric port numbers directly, look up port
numbers based on service names via system calls such as numbers based on service names via system calls such as
getservbyname() on UNIX, look up port numbers by performing queries getservbyname() on UNIX, look up port numbers by performing queries
for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd] or for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd], or
determine port numbers in a variety of other ways like the TCP Port determine port numbers in a variety of other ways like the TCP Port
Service Multiplexer (TCPMUX) [RFC1078]. Service Multiplexer (TCPMUX) [RFC1078].
Designers of applications and application-level protocols may apply Designers of applications and application-level protocols may apply
to IANA for an assigned port number and service name for a specific to IANA for an assigned service name and port number for a specific
application, and may - after successful registration - assume that no application, and may - after successful registration - assume that no
other application will use that port number or service name for its other application will use that service name or port number for its
communication sessions. Alternatively, application designers may communication sessions. Alternatively, application designers may
also ask for only an assigned service name, if their application does also ask for only an assigned service name, if their application does
not require a fixed port number. The latter alternative is not require a fixed port number. The latter alternative is
encouraged when possible, in order to conserve the more limited port encouraged when possible, in order to conserve the more limited port
number space. This includes, for example, applications that use DNS number space. This is applicable, for example, to applications that
SRV records to look up port numbers at runtime. use DNS SRV records to look up port numbers at runtime.
4. Conventions Used in this Document 4. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
5. Service Names 5. Service Names
Service names are the unique key in the Port and Service Name Service names are the unique key in the Service Name and Transport
registry. This unique symbolic name for a service may also be used Protocol Port Number Registry. This unique symbolic name for a
for other purposes, such as in DNS SRV records [RFC2782]. Within the service may also be used for other purposes, such as in DNS SRV
registry, this unique key ensures that different services can be records [RFC2782]. Within the registry, this unique key ensures that
unambiguously distinguished, thus preventing name collisions and different services can be unambiguously distinguished, thus
avoiding confusion about who is the administrative contact for a preventing name collisions and avoiding confusion about who is the
particular entry. administrative contact for a particular entry.
For each service name, there may exist zero or more associated port
number assignments. A port number assignment associated with a
service name contains the transport protocol, port number and
possibly additional data, such as a DCCP Service Code.
There may be more than one service name associated with a particular There may be more than one service name associated with a particular
transport protocol and port. There are two valid reasons for transport protocol and port. There are two ways that service name
allowing service name aliases: aliases occur:
o Aliases are permissible when all such service names are for the
same service, such as with "http" and "www", which both name TCP
port 80. In such cases, one of the service names SHOULD be
designated primary, for use with mechanisms such as DNS SRV
Records [RFC2782], and the others SHOULD be designated as aliases
of the primary service name. This is necessary so that clients
and servers using a service discovery mechanism use a consistent
name by which to refer to a given service. Otherwise, if a server
were to advertise that it supports the "www" service, and a client
were to seek instances of the "http" service, that client would
fail to discover that server, defeating the purpose of having a
service discovery mechanism. For aliases that do not indicate a
primary alias, a server is expected to register itself under all
aliased service names.
o Aliases are also permissible when one service is an extension of o Aliases occur when one service is an extension of another service,
another service, and an in-band mechanisms exists for determining and an in-band mechanism exists for determining if the extension
if the extension is present or not. One example is port 3478, is present or not. One example is port 3478, which has the
which has the service name aliases "stun" and "turn". TURN service name aliases "stun" and "turn". TURN [RFC5766] is an
[RFC5766] is an extension to the STUN [RFC5389] service. TURN- extension to the STUN [RFC5389] service. TURN-enabled clients
enabled clients wishing to locate TURN servers could attempt to wishing to locate TURN servers could attempt to discover "stun"
discover "stun" services and then checking in-band if the server services and then check in-band if the server supports TURN, but
supports TURN, but this is inefficient. Enabling them to directly this would be inefficient. Enabling them to directly query for
query for "turn" servers by name is a better approach. (Note that "turn" servers by name is a better approach. (Note that TURN
TURN servers in this case should also be locatable via a "stun" servers in this case should also be locatable via a "stun"
discovery, because every TURN server is also a STUN server.) discovery, because every TURN server is also a STUN server.)
o By historical accident the service name "http" also has aliases
"www" and "www-http". When used in SRV records [RFC2782], and
similar service discovery mechanisms only the service name "http"
should be used, not the aliases. If a server were to advertise
"www" then it would not be discovered by clients browsing for
"http". Advertising or browsing for the aliases as well as the
primary service name would be inefficient, and achieves nothing
that it not already achieved by using the service name "http"
exclusively.
For future assignments, applications will not be permitted that
merely request a new name exactly duplicating an existing service.
Having multiple names for the same service serves no purpose.
Implementers are requested to inform IANA if they discover other
cases where a single service has multiple names, so that one name may
be recorded as the primary name for service discovery purposes.
Service names are assigned on a "first come, first served" basis, as Service names are assigned on a "first come, first served" basis, as
described in Section 8.1. Names should be brief and informative, described in Section 8.1. Names should be brief and informative,
avoiding words or abbreviations that are redundant in the context of avoiding words or abbreviations that are redundant in the context of
the registry (e.g., "port", "service", "protocol", etc.) Names the registry (e.g., "port", "service", "protocol", etc.) Names
referring to discovery services, e.g., using multicast or broadcast referring to discovery services, e.g., using multicast or broadcast
to identify endpoints capable of a given service, SHOULD use an to identify endpoints capable of a given service, SHOULD use an
easily identifiable suffix (e.g., "-disc"). easily identifiable suffix (e.g., "-disc").
5.1. Service Name Syntax 5.1. Service Name Syntax
Valid service names MUST contain only these US-ASCII [ANSI.X3-4.1986] Valid service names:
characters: letters from A to Z and a to z, digits from 0 to 9, and
hyphens ("-", ASCII 0x2D or decimal 45). They MUST be at least one
character and no more than fifteen characters long, MUST NOT begin or
end with a hyphen, and MUST NOT consist of only digits (in order to
be distinguishable from port numbers, which are typically written as
all digits).
The service name syntax MAY be used to validate a service name o MUST be at least 1 character and no more than 15 characters long
string, but MUST NOT be used for any other purpose (e.g.,
delineation). Any system that includes a service name inside a
longer string is itself responsible for delineating the service name.
Such systems MUST NOT rely on the syntax of a service name alone for
such delineation.
The syntax defined in ABNF [RFC5234]: o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and
'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or
decimal 45)
o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')
o MUST NOT begin or end with a hyphen
The reason for requiring at least one letter is to avoid service
names like "23" (could be confused with a numeric port number) or
"6000-6063" (could be confused with a numeric port number range).
Although service names may contain both upper-case and lower-case
letters, case is ignored for comparison purposes, so both "http" and
"HTTP" denote the same service.
Service names are purely opaque identifiers, and no semantics are
implied by any superficial structure that a given service name may
appear to have. For example, a company called "Example" may choose
to register service names "Example-Foo" and "Example-Bar" for its
"Foo" and "Bar" products, but the "Example" company can't claim to
"own" all service names beginning with "Example-", they can't prevent
someone else registering "Example-Baz" for a different service, and
they can't prevent other developers from using the "Example-Foo" and
"Example-Bar" service types in order to interoperate with the "Foo"
and "Bar" products. Technically speaking, in service discovery
protocols, service names are merely a series of byte values on the
wire; for the mnemonic convenience of human developers it can be
convenient to interpret those byte values as human-readable ascii
characters, but software should treat them as purely opaque
identifiers and not attempt to parse them for any additional embedded
meaning.
In approximately 98% of cases, the new "service name" is exactly the
same as the old historic "short name" from the IANA web forms
[SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service
name" is derived from the old historic "short name" as described
below in Section 10.1.
The rules for valid service names are also expressed below using ABNF
[RFC5234]. (In the event that the ABNF rules are found to differ
from the plain-English rules above, the plain-English rules take
priority and are the definitive statement of what constitutes a legal
service name.)
SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) / SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) /
(1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM)) (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM))
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9
HYPHEN = %x2d ; "-" HYPHEN = %x2d ; "-"
ALPHA = <See [RFC5234]> ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = <See [RFC5234]> DIGIT = %x30-39 ; 0-9 [RFC5234]
5.2. Service Name Usage in DNS SRV Records 5.2. Service Name Usage in DNS SRV Records
The DNS SRV specification [RFC2782] requests that the Service Label The DNS SRV specification [RFC2782] states that the Service Label
part of the owner name of DNS SRV records includes a "Service" part of the owner name of a DNS SRV record includes a "Service"
element, defined to be "the symbolic name of the desired service", element, described as "the symbolic name of the desired service", but
but did not state precisely which part of the IANA database (i.e. as discussed above, it is not clear precisely what this means.
STD 2 when [RFC2782] was written) serves as a registry for standard
service names.
This document clarifies that the Service Label MUST be a service name This document clarifies that the Service Label MUST be a service name
as defined herein. The service name SHOULD be registered with IANA as defined herein. The service name SHOULD be registered with IANA
and recorded in the Service Names and Port Numbers registry and recorded in the Service Name and Transport Protocol Port Number
[PORTREG]. This is needed to ensure that only a single registry of Registry [PORTREG].
Service Names exists and name collisions can be avoided in the
future.
The details of the use of Service Names from [PORTREG] in SRV Service
Labels are specified in [RFC2782] and the documents updating or
replacing that specification (see the companion document
[I-D.gudmundsson-dnsext-srv-clarify] for more information).
The details of how applications make use of DNS SRV should be The details of using Service Names in SRV Service Labels are
specified in the documentation set of the application/service. In specified in the DNS SRV specification [RFC2782]. This document does
the absence of such specification, prospective clients of a given not change that specification.
service should not assume the existence of SRV RRs for this service
or, if they have indications that this will be the case (e.g., by
configuration), must assume the unextended naming scheme from
[RFC2782] for service discovery with DNS SRV, i.e., the Service Label
is constructed from the Service Name registered in [PORTREG] by
prepending a single underscore character ("_").
6. Port Number Ranges 6. Port Number Ranges
TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their TCP, UDP, UDP-Lite, SCTP and DCCP use sixteen-bit namespaces for
port number registries. The port registries for all these transport their port number registries. The port registries for all these
protocols are subdivided into three ranges of numbers, and transport protocols are subdivided into three ranges of numbers, and
Section 7.3 describes the IANA procedures for each range in detail: Section 7.3 describes the IANA procedures for each range in detail:
o the Well Known Ports, also known as the System Ports, from 0-1023 o the System Ports, also known as the Well Known Ports, from 0-1023
(assigned by IANA) (assigned by IANA)
o the Registered Ports, also known as the User Ports, from 1024- o the User Ports, also known as the Registered Ports, from 1024-
49151 (assigned by IANA) 49151 (assigned by IANA)
o the Dynamic Ports, also known as the Private Ports, from 49152- o the Dynamic Ports, also known as the Private Ports, from 49152-
65535 (never assigned) 65535 (never assigned)
Of the assignable port ranges (Well Known and Registered, i.e., port Of the assignable port ranges (System Ports and User Ports, i.e.,
numbers 0-49151), individual port numbers are in one of three states port numbers 0-49151), individual port numbers are in one of three
at any given time: states at any given time:
o Assigned: Assigned port numbers are currently allocated to the o Assigned: Assigned port numbers are currently allocated to the
service indicated in the registry. service indicated in the registry.
o Unassigned: Unassigned port numbers are currently available for o Unassigned: Unassigned port numbers are currently available for
assignment upon request, as per the procedures outlined in this assignment upon request, as per the procedures outlined in this
document. document.
o Reserved: Reserved port numbers are not available for regular o Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes. assignment; they are "assigned to IANA" for special purposes.
skipping to change at page 11, line 4 skipping to change at page 11, line 15
o Assigned: Assigned port numbers are currently allocated to the o Assigned: Assigned port numbers are currently allocated to the
service indicated in the registry. service indicated in the registry.
o Unassigned: Unassigned port numbers are currently available for o Unassigned: Unassigned port numbers are currently available for
assignment upon request, as per the procedures outlined in this assignment upon request, as per the procedures outlined in this
document. document.
o Reserved: Reserved port numbers are not available for regular o Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes. assignment; they are "assigned to IANA" for special purposes.
Reserved port numbers include values at the edges of each range, Reserved port numbers include values at the edges of each range,
e.g., 0, 1023, 1024, etc., which may be used to extend these e.g., 0, 1023, 1024, etc., which may be used to extend these
ranges or the overall port number space in the future. ranges or the overall port number space in the future.
In order to keep the size of the registry manageable, IANA typically In order to keep the size of the registry manageable, IANA typically
only records the Assigned and Reserved port numbers and service names only records the Assigned and Reserved service names and port numbers
in the registry. Unassigned values are typically not explicitly in the registry. Unassigned values are typically not explicitly
listed. listed. (There are an near-infinite number of Unassigned service
names and enumerating them all would not be practical.)
As a data point, when this document was written, approximately 76% of As a data point, when this document was written, approximately 76% of
the TCP and UDP Well Known Ports were assigned, and approximately 9% the TCP and UDP System Ports were assigned, and approximately 9% of
of the Registered Ports were assigned. (As noted, Dynamic Ports are the User Ports were assigned. (As noted, Dynamic Ports are never
never assigned.) assigned.)
6.1. Port Numbers and Service Names for Experimentation 6.1. Service names and Port Numbers for Experimentation
Of the Well Known ports, two TCP and UDP port numbers (1021 and Of the System Ports, two TCP and UDP port numbers (1021 and 1022),
1022), together with their respective service names ("exp1" and together with their respective service names ("exp1" and "exp2"),
"exp2"), have been assigned for experimentation with new applications have been assigned for experimentation with new applications and
and application-layer protocols that require a port number in the application-layer protocols that require a port number in the
assigned ports ranges [RFC4727]. assigned ports ranges [RFC4727].
Please refer to Sections 1 and 1.1 of "Assigning Experimental and Please refer to Sections 1 and 1.1 of "Assigning Experimental and
Testing Numbers Considered Useful" [RFC3692] for how these Testing Numbers Considered Useful" [RFC3692] for how these
experimental port numbers are to be used. experimental port numbers are to be used.
This document registers the same two port numbers and service names This document registers the same two service names and port numbers
for experimentation with new application-layer protocols over SCTP for experimentation with new application-layer protocols over SCTP
and DCCP in Section 10.2. and DCCP in Section 10.2.
Unfortunately, it can be difficult to limit access to these ports. Unfortunately, it can be difficult to limit access to these ports.
Users SHOULD take measures to ensure that experimental ports are Users SHOULD take measures to ensure that experimental ports are
connecting to the intended process. For example, users of these connecting to the intended process. For example, users of these
experimental ports might include a 64-bit nonce, once on each segment experimental ports might include a 64-bit nonce, once on each segment
of a message-oriented channel (e.g., UDP), or once at the beginning of a message-oriented channel (e.g., UDP), or once at the beginning
of a byte-stream (e.g., TCP), which is used to confirm that the port of a byte-stream (e.g., TCP), which is used to confirm that the port
is being used as intended. Such confirmation of intended use is is being used as intended. Such confirmation of intended use is
especially important when these ports are associated with privileged especially important when these ports are associated with privileged
(e.g., system or administrator) processes. (e.g., system or administrator) processes.
7. Principles for Port Number and Service Name Registry Management 7. Principles for Service Name and Transport Protocol Port Number
Registry Management
Management procedures for the port number and service name registry Management procedures for the service name and transport protocol
include allocation of port numbers and service names upon request, as port number registry include allocation of service names and port
well as coordination of information about existing allocations. The numbers upon request, as well as management of information about
latter includes maintaining contact and description information about existing allocations. The latter includes maintaining contact and
assignments, revoking abandoned assignments, and redefining description information about assignments, revoking abandoned
assignments when needed. Of these procedures, port number allocation assignments, and redefining assignments when needed. Of these
is most critical, in order to continue to conserve the remaining port procedures, careful port number allocation is most critical, in order
numbers. to continue to conserve the remaining port numbers.
As noted earlier, only ~9% of the Registered Port space is currently As noted earlier, only about 9% of the User Port space is currently
assigned. The current rate of assignment is approximately 400 ports/ assigned. The current rate of assignment is approximately 400 ports
year, and has remained linear for the past 8 years. At that rate, if per year, and has remained steady for the past 8 years. At that
similar conservation continues, this resource will sustain another 85 rate, if similar conservation continues, this resource will sustain
years of assignment - without the need to resort to reassignment of another 85 years of assignment - without the need to resort to
released values or revocation. Note that the namespace available for reassignment of released values or revocation. The namespace
service names is even larger, which allows for a simpler management available for service names is much larger, which allows for simpler
procedures. management procedures.
7.1. Past Principles 7.1. Past Principles
Before the publication of this document, the principles of port Before the publication of this document, the principles of service
number and service name management followed a few mostly-undocumented name and port number management followed a few mostly-undocumented
guidelines. They are recorded here for historical purposes, and this guidelines. They are recorded here for historical purposes, and this
document updates them in Section 7.2. These principles were: document updates them in Section 7.2. These principles were:
o TCP and UDP ports were simultaneously allocated when either was o TCP and UDP ports were simultaneously allocated when either was
requested requested
o Port numbers were the primary allocation; service names were o Port numbers were the primary allocation; service names were
informative only, and did not have a well-defined syntax informative only, and did not have a well-defined syntax
o Port numbers were conserved informally, and sometimes o Port numbers were conserved informally, and sometimes
inconsistently (e.g., some services were allocated ranges of many inconsistently (e.g., some services were allocated ranges of many
port numbers even where not strictly necessary) port numbers even where not strictly necessary)
o SCTP and DCCP port number and service name registries were managed o SCTP and DCCP service name and port number registries were managed
separately from the TCP/UDP registries separately from the TCP/UDP registries
o Service names could not be assigned in the ports registry without o Service names could not be assigned in the old ports registry
assigning a corresponding port number at the same time without assigning an associated port number at the same time
This document clarifies and aligns these guidelines in order to more This document clarifies and aligns these guidelines in order to more
conservatively manage the limited remaining port number space and to conservatively manage the limited remaining port number space and to
enable and promote the use of service names for service enable and promote the use of service names for service
identification without associated port numbers, where possible. identification without associated port numbers, where possible.
7.2. Updated Principles 7.2. Updated Principles
This section summarizes the basic principles by which IANA handles This section summarizes the basic principles by which IANA handles
the Port and Service Name registry, and attempts to conserve the port the Service Name and Transport Protocol Port Number Registry, and
number space. This description is intended to inform applicants attempts to conserve the port number space. This description is
requesting service names and port numbers. IANA decisions are not intended to inform applicants requesting service names and port
required to be bound to these principles, however; other factors may numbers. IANA decisions are not required to be bound by these
come into play, and exceptions may occur where deemed in the best principles; other factors may come into play, and exceptions may
interest of the Internet. occur where deemed in the best interest of the Internet.
IANA will begin assigning service names that do not request a IANA will begin assigning service names that do not request an
corresponding port number allocation under a simple "First Come, associated port number allocation under a simple "First Come, First
First Served" policy [RFC5226]. IANA MAY, at its discretion, refer Served" policy [RFC5226]. IANA MAY, at its discretion, refer service
service name requests to "Expert Review" in cases of mass name requests to "Expert Review" in cases of mass registrations or
registrations or other situations where IANA believes expert review other situations where IANA believes expert review is advisable.
is advisable.
The basic principle of port number registry management is to conserve The basic principle of service name and port number registry
use of the port space where possible. Extensions to support larger management is to conserve use of the port space where possible.
port number spaces would require changing many core protocols of the Extensions to support larger port number spaces would require
current Internet in a way that would not be backward compatible and changing many core protocols of the current Internet in a way that
interfere with both current and legacy applications. To help ensure would not be backward compatible and interfere with both current and
this conservation the policy for any registration request for port legacy applications. To help ensure this conservation the policy for
number allocations uses the "Expert Review" policy [RFC5226]. any registration request for port number allocations uses the "Expert
Review" policy [RFC5226].
Conservation of the port number space is required because this space Conservation of the port number space is required because this space
is a limited resource, applications are expected to participate in is a limited resource, so applications are expected to participate in
the traffic demultiplexing process where feasible. The port numbers the traffic demultiplexing process where feasible. The port numbers
are expected to encode as little information as possible that will are expected to encode as little information as possible that will
still enable an application to perform further demultiplexing by still enable an application to perform further demultiplexing by
itself. In particular: itself. In particular:
o IANA will allocate only one assigned port number per service or o IANA will allocate only one assigned port number per service or
application application
o IANA will allocate only one assigned port number for all versions o IANA will allocate only one assigned port number for all versions
of a service (e.g., running the service with or without a security of a service (e.g., running the service with or without a security
mechanism, or for updated variants of a service) mechanism, or for updated variants of a service)
o IANA will allocate only one assigned port number for all different o IANA will allocate only one assigned port number for all different
types of device using or participating in the same service types of device using or participating in the same service
o IANA will allocate port numbers only for the transport protocol(s) o IANA will allocate port numbers only for the transport protocol(s)
explicitly named in an registration request explicitly named in a registration request
o IANA may recover unused port numbers, via the new procedures of o IANA may recover unused port numbers, via the new procedures of
de-registration, revocation, and transfer de-registration, revocation, and transfer
A given service is expected to further demultiplex messages where Where possible, a given service is expected to demultiplex messages
possible. For example, applications and protocols are expected to if necessary. For example, applications and protocols are expected
include in-band version information, so that future versions of the to include in-band version information, so that future versions of
application or protocol can share the same allocated port. the application or protocol can share the same allocated port.
Applications and protocols are also expected to be able to Applications and protocols are also expected to be able to
efficiently use a single allocated port for multiple sessions, either efficiently use a single allocated port for multiple sessions, either
by demultiplexing multiple streams within one port, or using the by demultiplexing multiple streams within one port, or using the
allocated port to coordinate using dynamic ports for subsequent allocated port to coordinate using dynamic ports for subsequent
exchanges (e.g., in the spirit of FTP [RFC0959]). exchanges (e.g., in the spirit of FTP [RFC0959]).
Ports are used in various ways, notably: Ports are used in various ways, notably:
o as endpoint process identifiers o as endpoint process identifiers
o as application protocol identifiers o as application protocol identifiers
o for firewall filtering purposes o for firewall filtering purposes
The process and protocol identifier use suggests that anything a Both the process identifier and the protocol identifier uses suggest
single process can demultiplex, or that can be encoded into a single that anything a single process can demultiplex, or that can be
protocol, should be. The firewall filtering use suggests that some encoded into a single protocol, should be. The firewall filtering
uses that could be multiplexed or encoded must be separated to allow use suggests that some uses that could be multiplexed or encoded
for firewall management. Note that this latter use is much less could instead be separated to allow for easier firewall management.
sound, because port numbers have meaning only for the two endpoints Note that this latter use is much less sound, because port numbers
involved in a connection, and drawing conclusions about the service have meaning only for the two endpoints involved in a connection, and
that generated a given flow based on observed port numbers is not drawing conclusions about the service that generated a given flow
always reliable. Further, previous separation of protocol variants based on observed port numbers is not always reliable. Further,
based on security capabilities (e.g., HTTP on TCP port 80 vs. HTTPS previous separation of protocol variants based on security
on TCP port 443) is not recommended for new protocols, because all capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
should be security-capable and capable of negotiating the use of not recommended for new protocols, because all new protocols should
security in-band. be security-capable and capable of negotiating the use of security
in-band.
IANA will begin assigning port numbers for only those transport IANA will begin assigning port numbers for only those transport
protocols explicitly included in a registration request. This ends protocols explicitly included in a registration request. This ends
the long-standing practice of automatically assigning a port number the long-standing practice of automatically assigning a port number
to an application for both TCP and a UDP, even if the request is for to an application for both TCP and a UDP, even if the request is for
only one of these transport protocols. The new allocation procedure only one of these transport protocols. The new allocation procedure
conserves resources by allocating a port number to an application for conserves resources by allocating a port number to an application for
only those transport protocols (TCP, UDP, SCTP and/or DCCP) it only those transport protocols (TCP, UDP, SCTP and/or DCCP) it
actually uses. The port number will be marked as Reserved - instead actually uses. The port number will be marked as Reserved - instead
of Assigned - in the port number registries of the other transport of Assigned - in the port number registries of the other transport
protocols. When applications start supporting the use of some of protocols. When applications start supporting the use of some of
those additional transport protocols, the administrative contact for those additional transport protocols, the administrative contact for
the registration MUST request IANA to convert the reservation into a the registration MUST request IANA to convert the reservation into a
proper assignment. An application MUST NOT assume that it can use a proper assignment. An application MUST NOT assume that it can use a
port number assigned to it for use with one transport protocol with port number assigned to it for use with one transport protocol with
another transport protocol without asking IANA to convert the another transport protocol without asking IANA to convert the
reservation into an assignment. reservation into an assignment.
When the available pool of unassigned numbers has run out in a ports When the available pool of unassigned numbers has run out in a ports
range, it will be necessary for IANA to consider the Reserved ports range, it will be necessary for IANA to consider the Reserved ports
for assignment. This is part of the motivation to not automatically for assignment. This is part of the motivation for not automatically
assigning ports for other transport protocols than the requested assigning ports for transport protocols other than the requested
ones. This will allow more ports to be available for assignment at one(s). This will allow more ports to be available for assignment
that point. It also shows the importance to register the transport when that time comes. To help conserve ports, application developers
protocols that are in fact used. should register only the transport protocols that their application
in fact uses.
Conservation of port numbers is improved by procedures that allow Conservation of port numbers is improved by procedures that allow
previously allocated port numbers to become Unassigned, either previously allocated port numbers to become Unassigned, either
through de-registration or through revocation, and by a procedure through de-registration or through revocation, and by a procedure
that lets application designers transfer an allocated but unused port that lets application designers transfer an allocated but unused port
number to a new application. Section 8 describes these procedures, number to a new application. Section 8 describes these procedures,
which so far were undocumented. Port number conservation is also which until now were undocumented. Port number conservation is also
improved by recommending that applications that do not require an improved by recommending that applications that do not require an
allocated port chose this option and register only a service name. allocated port should register only a service name without an
associated port number.
7.3. Variances for Specific Port Number Ranges 7.3. Variances for Specific Port Number Ranges
Section 6 describes the different port number ranges. It is Section 6 describes the different port number ranges. It is
important to note that IANA applies slightly different procedures important to note that IANA applies slightly different procedures
when managing the different ranges of the port number registry: when managing the different port ranges of the service name and port
number registry:
o Ports in the Dynamic Ports range (49152-65535) have been o Ports in the Dynamic Ports range (49152-65535) have been
specifically set aside for local and dynamic use and cannot be specifically set aside for local and dynamic use and cannot be
registered through IANA. Applications may simply use them for assigned through IANA. Application software may simply use them
communication without any sort of registration. On the other for communication without any sort of registration. On the other
hand, applications MUST NOT assume that a specific port number in hand, application software MUST NOT assume that a specific port
the Dynamic Ports range will always be available for communication number in the Dynamic Ports range will always be available for
at all times, and a port number in that range hence MUST NOT be communication at all times, and a port number in that range hence
used as a service identifier. MUST NOT be used as a service identifier.
o Ports in the Registered Ports range (1024-49151) are available for o Ports in the User Ports range (1024-49151) are available for
registration through IANA, and MAY be used as service identifiers registration through IANA, and MAY be used as service identifiers
upon successful registration. Because registering a port number upon successful registration. Because registering a port number
for a specific application consumes a fraction of the shared for a specific application consumes a fraction of the shared
resource that is the port number registry, IANA will require the resource that is the port number registry, IANA will require the
requester to document the intended use of the port number. This requester to document the intended use of the port number. This
documentation will be input to the "Expert Review" allocation documentation will be input to the "Expert Review" allocation
procedure [RFC5226], by which IANA will have a technical expert procedure [RFC5226], by which IANA will have a technical expert
review the request to determine whether to grant the registration. review the request to determine whether to grant the registration.
The submitted documentation MUST explain why using a port number The submitted documentation MUST explain why using a port number
in the Dynamic Ports range is unsuitable for the given in the Dynamic Ports range is unsuitable for the given
application. Ports in the Registered Ports range may also be application. Ports in the User Ports range may also be assigned
assigned under the "IETF Review" or "IESG Approval" allocation under the "IETF Review" or "IESG Approval" allocation procedures
procedures [RFC5226], which is how most assignments for IETF [RFC5226], which is how most assignments for IETF protocols are
protocols are handled. handled.
o Ports in the Well Known Ports range (0-1023) are also available
for registration through IANA. Because the Well Known Ports range
is both the smallest and the most densely allocated, the
requirements for new allocations are more strict than those for
the Registered Ports range, and will only be granted under the
"IETF Review" or "IESG Approval" allocation procedures [RFC5226].
A request for a Well Known port number MUST document why using a o Ports in the System Ports range (0-1023) are also available for
port number from both the Registered Ports and Dynamic Ports registration through IANA. Because the System Ports range is both
ranges is unsuitable for the given application. the smallest and the most densely allocated, the requirements for
new allocations are more strict than those for the User Ports
range, and will only be granted under the "IETF Review" or "IESG
Approval" allocation procedures [RFC5226]. A request for a System
Port number MUST document *both* why using a port number from the
User Ports is unsuitable *and* why using a port number from the
Dynamic Ports ranges is unsuitable for that application.
8. IANA Procedures for Managing the Port Number and Service Name 8. IANA Procedures for Managing the Service Name and Transport Protocol
Registry Port Number Registry
This section describes the process for requests associated with This section describes the process for handling requests associated
IANA's management of the port number and service name registry. Such with IANA's management of the Service Name and Transport Protocol
requests include initial registration, de-registration, re-use, Port Number Registry. Such requests include initial registration,
changes to the service name, as well as updates to the contact de-registration, re-use, changes to the service name, and updates to
information or description associated with an assignment. Revocation the contact information or description associated with an assignment.
is initiated by IANA. Revocation is as additional process, initiated by IANA.
8.1. Port Number and Service Name Registration 8.1. Service Name and Port Number Registration
Registration refers to the allocation of port numbers or service Registration refers to the allocation of service names or port
names to applicants. All such registrations are made from port numbers to applicants. All such registrations are made from service
numbers or service names that are Unassigned or Reserved at the time names or port numbers that are Unassigned or Reserved at the time of
of the allocation. Unassigned numbers and names are allocated as the allocation. Unassigned names and numbers are allocated according
needed, and without further explanation. Reserved numbers and names to the rules described in Section 7.3. Reserved numbers and names
are assigned only after review by IANA and the IETF, and are are assigned only after review by IANA and the IETF, and are
accompanied by a statement explaining the reason a Reserved number or accompanied by a statement explaining the reason a Reserved number or
name is appropriate for this action. name is appropriate for this action.
When a registration for one or more transport protocols is approved, When a registration for one or more transport protocols is approved,
the port number for any non-requested transport protocol(s) will be the port number for any non-requested transport protocol(s) will be
marked as Reserved. IANA SHOULD NOT assign that port number to any marked as Reserved. IANA SHOULD NOT assign that port number to any
other application or service until no other port numbers remain other application or service until no other port numbers remain
Unassigned in the requested range. The current administrative Unassigned in the requested range. The current administrative
contact for a port number MAY register these Reserved port numbers contact for a port number MAY register these Reserved port numbers
for other transport protocols when needed. for other transport protocols when needed.
Service names, on the other hand, are not tied to a specific A service name or port number registration request contains the
transport protocol, and registration requests for only a service name following information. The service name is the unique identifier of
(but not a port number) allocate that service name for use with all a given service:
transport protocols.
A port number or service name registration request contains some or
all of the following information. The combination of service name
and transport protocol is the unique identifier of a given service:
Service Name (REQUIRED) Service Name (REQUIRED)
Transport Protocol(s) (REQUIRED) Transport Protocol(s) (REQUIRED)
Registration Administrative Contact (REQUIRED) Registrant (REQUIRED)
Registration Technical Contact (REQUIRED) Contact (REQUIRED)
Port Number (OPTIONAL)
Service Code (only REQUIRED for DCCP)
Description (REQUIRED) Description (REQUIRED)
Reference (REQUIRED) Reference (REQUIRED)
Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL) Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL) Assignment Notes (OPTIONAL)
o Service Name: A desired unique service name for the service o Service Name: A desired unique service name for the service
associated with the registration request MUST be provided, for use associated with the registration request MUST be provided, for use
in various service selection and discovery mechanisms (including, in various service selection and discovery mechanisms (including,
but not limited to, DNS SRV records [RFC2782]). The name MUST be but not limited to, DNS SRV records [RFC2782]). The name MUST be
compliant with the syntax defined in Section 5.1. In order to be compliant with the syntax defined in Section 5.1. In order to be
unique, they MUST NOT be identical to any currently registered unique, they MUST NOT be identical to any currently assigned
service names in the IANA registry [PORTREG]. Service names are service name in the IANA registry [PORTREG]. Service names are
case-insensitive; they may be provided and entered into the case-insensitive; they may be provided and entered into the
registry with mixed case (e.g., for clarity), but for the purposes registry with mixed case for clarity, but for the comparison
of comparison, the case is ignored. purposes the case is ignored.
o Transport Protocol(s): The transport protocol(s) for which the o Transport Protocol(s): The transport protocol(s) for which the
allocation is requested MUST be provided. This field is currently allocation is requested MUST be provided. This field is currently
limited to one or more of TCP, UDP, SCTP, and DCCP. This field is limited to one or more of TCP, UDP, SCTP, and DCCP. This field is
required even for services with no port number. required even for services with no port number.
o Registration Administrative Contact: Name and email address of the o Registrant: Name and email address of the Registrant. This is
administrative contact for the registration. This is REQUIRED. REQUIRED. The Registrant is the Organization or Company
The name of the administrative contact identifies the responsible for the initial registration. For registrations done
organization, company, or individual who is responsible for the through IETF-published RFCs, the Registrant will be the IESG.
registration. For registrations done through IETF-published RFCs,
the administrative contact will be the IESG.
o Registration Technical Contact: Name and email address of the
technical contact person for the registration. This is REQUIRED.
For individuals, this is the same as the Registration
Administrative Contact; for organizations, this is a point of
contact at that organization. Additional address information MAY
be provided. For registrations done through IETF-published RFCs,
the technical contact will be the IESG.
o Port Number: If assignment of a port number is desired, either the
currently Unassigned port number the requester suggests for
allocation, or the text "ANY", MUST be provided. If only a
service name is to be assigned, this field MUST be empty. If a
specific port number is requested, IANA is encouraged to allocate
the requested number. If the text "ANY" is specified, IANA will
choose a suitable number from the Registered Ports range. Note
that the applicant MUST NOT use the requested port prior to the
completion of the registration.
o Service Code: The request MUST include a desired unique DCCP o Contact: Name and email address of the Contact person for the
service code [RFC5595], if the registration request includes DCCP registration. This is REQUIRED. The Contact person is the
as a transport protocol, and MUST NOT include a requested DCCP responsible person for the Internet community to send questions
service code otherwise. Section 19.8 of [RFC4340] defines to. This person would also be authorized to submit changes on
requirements and rules for allocation, updated by this document. behalf of the Registrant. Additional address information MAY be
provided. For registrations done through IETF-published RFCs, the
Contact will be the IESG.
o Description: A short description of the service associated with o Description: A short description of the service associated with
the registration request is REQUIRED. It should avoid all but the the registration request is REQUIRED. It should avoid all but the
most well known acronyms. most well-known acronyms.
o Reference: A description of (or a reference to a document o Reference: A description of (or a reference to a document
describing) the protocol or application using this port. The describing) the protocol or application using this port. The
description must include whether the protocol uses either description must state whether the protocol uses broadcast,
broadcast, multicast, or anycast communication. multicast, or anycast communication.
For registrations requesting only a Service Name or a Service Name For registrations requesting only a Service Name, or a Service
and Registered Port, a statement that the protocol is proprietary Name and User Port, a statement that the protocol is proprietary
and not publicly documented is also acceptable provided that the and not publicly documented is also acceptable provided that the
above information regarding use of broadcast, multicast, or required information regarding use of broadcast, multicast, or
anycast is given. anycast is given.
For registration requests for a Registered Port, the registration For registration requests for a User Port, the registration
request MUST explain why a port number in the Dynamic Ports range request MUST explain why a port number in the Dynamic Ports range
is unsuitable for the given application. is unsuitable for the given application.
For registration requests for a Well Known Port, the registration For registration requests for a System Port, the registration
request MUST explain why a port number in the Registered Ports or request MUST explain why a port number in the User Ports or
Dynamic Ports ranges is unsuitable, and a reference to a stable Dynamic Ports ranges is unsuitable, and a reference to a stable
protocol specification document MUST be provided. For requests protocol specification document MUST be provided. For requests
from IETF Working Groups, IANA MAY accept "Early" registration from IETF Working Groups, IANA MAY accept "early registration"
requests referencing a sufficiently stable Internet Draft instead [RFC4020] requests referencing a sufficiently stable Internet
of a published Standards-Track RFC [RFC4020]. Draft instead of a published Standards-Track RFC.
o Port Number: If assignment of a port number is desired, either the
currently Unassigned or Reserved port number the requester
suggests for allocation, or the text "ANY", MUST be provided. If
only a service name is to be assigned, this field MUST be empty.
If a specific port number is requested, IANA is encouraged to
allocate the requested number. If the text "ANY" is specified,
IANA will choose a suitable number from the User Ports range.
Note that the applicant MUST NOT use the requested port prior to
the completion of the registration.
o Service Code: If the registration request includes DCCP as a
transport protocol then the request MUST include a desired unique
DCCP service code [RFC5595], and MUST NOT include a requested DCCP
service code otherwise. Section 19.8 of the DCCP specification
[RFC4340] defines requirements and rules for allocation, updated
by this document.
o Known Unauthorized Uses: A list of uses by applications or o Known Unauthorized Uses: A list of uses by applications or
organizations who are not the assignee. This list may be organizations who are not the assignee. This list may be
augmented by IANA after assignment when unauthorized uses are augmented by IANA after assignment when unauthorized uses are
reported. reported.
o Assignment Notes: Indications of owner/name change, or any other o Assignment Notes: Indications of owner/name change, or any other
assignment process issue. This list may be updated by IANA after assignment process issue. This list may be updated by IANA after
assignment to help track changes to an assignment, e.g., de- assignment to help track changes to an assignment, e.g., de-
registration, owner/name changes, etc. registration, owner/name changes, etc.
If the registration request is for the addition of a new transport If the registration request is for the addition of a new transport
protocol to an already assigned service name, IANA needs to confirm protocol to an already assigned service name, IANA needs to confirm
with the administrative contact for the existing assignment whether with the administrative contact for the existing assignment whether
this addition is appropriate. this addition is appropriate.
If the registration request is for a service name alias (see
Section 5), IANA needs to confirm with the administrative contact for
the existing service name whether the registration of the alias is
appropriate.
When IANA receives a registration request - containing the above When IANA receives a registration request - containing the above
information - that is requesting a port number, IANA SHALL initiate information - that is requesting a port number, IANA SHALL initiate
an "Expert Review" [RFC5226] in order to determine whether an an "Expert Review" [RFC5226] in order to determine whether an
assignment should be made. For requests that do not include a port assignment should be made. For requests that do not include a port
number, IANA SHOULD assign the service name under a simple "First number, IANA SHOULD assign the service name under a simple "First
Come First Served" policy [RFC5226]. Come First Served" policy [RFC5226].
8.2. Port Number and Service Name De-Registration 8.2. Service Name and Port Number De-Registration
The administrative contact of a granted port number assignment can The administrative contact of a granted port number assignment can
return the port number to IANA at any time if they no longer have a return the port number to IANA at any time if they no longer have a
need for it. The port number will be de-registered and will be need for it. The port number will be de-registered and will be
marked as Reserved. IANA should not re-assign port numbers that have marked as Reserved. IANA should not re-assign port numbers that have
been de-registered until all other available port numbers in the been de-registered until all unassigned port numbers in the specific
specific range have been assigned. range have been assigned.
Before proceeding with a port number de-registration, IANA needs to Before proceeding with a port number de-registration, IANA needs to
reasonably establish that the value is actually no longer in use. reasonably establish that the value is actually no longer in use.
Because there is much less danger of exhausting the service name Because there is much less danger of exhausting the service name
space compared to the port number space, it is RECOMMENDED that a space compared to the port number space, it is RECOMMENDED that a
given service name remain assigned even after all associated port given service name remain assigned even after all associated port
number assignments have become de-registered. Under this policy, it number assignments have become de-registered. Under this policy, it
will appear in the registry as if it had been created through a will appear in the registry as if it had been created through a
service name registration request that did not include any port service name registration request that did not include any port
numbers. numbers.
On rare occasions, it may still be useful to de-register a service On rare occasions, it may still be useful to de-register a service
name. In such cases, IANA will mark the service name as Reserved. name. In such cases, IANA will mark the service name as Reserved.
IANA will involve their IESG-appointed expert in such cases. IANA will involve their IESG-appointed expert in such cases.
8.3. Port Number and Service Name Re-Use 8.3. Service Name and Port Number Re-Use
If the administrative contact of a granted port number assignment no If the administrative contact of a granted port number assignment no
longer have a need for the registered number, but would like to re- longer have a need for the assigned number, but would like to re-use
use it for a different application, they can submit a request to IANA it for a different application, they can submit a request to IANA to
to do so. do so.
Logically, port number re-use is to be thought of as a de- Logically, port number re-use is to be thought of as a de-
registration (Section 8.2) followed by an immediate re-registration registration (Section 8.2) followed by an immediate re-registration
(Section 8.1) of the same port number for a new application. (Section 8.1) of the same port number for a new application.
Consequently, the information that needs to be provided about the Consequently, the information that needs to be provided about the
proposed new use of the port number is identical to what would need proposed new use of the port number is identical to what would need
to be provided for a new port number allocation for the specific to be provided for a new port number allocation for the specific
ports range. ports range.
Because there is much less danger of exhausting the service name Because there is much less danger of exhausting the service name
skipping to change at page 20, line 32 skipping to change at page 20, line 43
application is NOT RECOMMENDED. application is NOT RECOMMENDED.
IANA needs to carefully review such requests before approving them. IANA needs to carefully review such requests before approving them.
In some instances, the Expert Reviewer will determine that the In some instances, the Expert Reviewer will determine that the
application that the port number was assigned to has found usage application that the port number was assigned to has found usage
beyond the original requester, or that there is a concern that it may beyond the original requester, or that there is a concern that it may
have such users. This determination MUST be made quickly. A have such users. This determination MUST be made quickly. A
community call concerning revocation of a port number (see below) MAY community call concerning revocation of a port number (see below) MAY
be considered, if a broader use of the port number is suspected. be considered, if a broader use of the port number is suspected.
8.4. Port Number and Service Name Revocation 8.4. Service Name and Port Number Revocation
A port number revocation can be thought of as an IANA-initiated de- A port number revocation can be thought of as an IANA-initiated de-
registration (Section 8.2), and has exactly the same effect on the registration (Section 8.2), and has exactly the same effect on the
registry. registry.
Sometimes, it will be clear that a specific port number is no longer Sometimes, it will be clear that a specific port number is no longer
in use and that IANA can revoke it and mark it as Reserved. At other in use and that IANA can revoke it and mark it as Reserved. At other
times, it may be unclear whether a given assigned port number is times, it may be unclear whether a given assigned port number is
still in use somewhere in the Internet. In those cases, IANA must still in use somewhere in the Internet. In those cases, IANA must
carefully consider the consequences of revoking the port number, and carefully consider the consequences of revoking the port number, and
skipping to change at page 21, line 10 skipping to change at page 21, line 21
with the Expert Reviewer's support, SHALL determine promptly after with the Expert Reviewer's support, SHALL determine promptly after
the end of the community call whether revocation should proceed and the end of the community call whether revocation should proceed and
then communicate their decision to the community. This procedure then communicate their decision to the community. This procedure
typically involves similar steps to de-registration except that it is typically involves similar steps to de-registration except that it is
initiated by IANA. initiated by IANA.
Because there is much less danger of exhausting the service name Because there is much less danger of exhausting the service name
space compared to the port number space, revoking service names is space compared to the port number space, revoking service names is
NOT RECOMMENDED. NOT RECOMMENDED.
8.5. Port Number and Service Name Transfers 8.5. Service Name and Port Number Transfers
The value of port numbers and service names is defined by their The value of service names and port numbers is defined by their
careful management as a shared Internet resource, whereas enabling careful management as a shared Internet resource, whereas enabling
transfer allows the potential for associated monetary exchanges. As transfer allows the potential for associated monetary exchanges. As
a result, the IETF does not permit port number or service name a result, the IETF does not permit service name or port number
assignments to be transferred between parties, even when they are assignments to be transferred between parties, even when they are
mutually consenting. mutually consenting.
The appropriate alternate procedure is a coordinated de-registration The appropriate alternate procedure is a coordinated de-registration
and registration: The new party requests the port number or service and registration: The new party requests the service name or port
name via a registration and the previous party releases its number via a registration and the previous party releases its
assignment via the de-registration procedure outlined above. assignment via the de-registration procedure outlined above.
With the help of their IESG-appointed Expert Reviewer, IANA SHALL With the help of their IESG-appointed Expert Reviewer, IANA SHALL
carefully determine if there is a valid technical, operational or carefully determine if there is a valid technical, operational or
managerial reason to grant the requested new assignment. managerial reason to grant the requested new assignment.
8.6. Maintenance Issues 8.6. Maintenance Issues
In addition to the formal procedures described above, updates to the In addition to the formal procedures described above, updates to the
Description and Technical Contact information are coordinated by IANA Description and Technical Contact information are coordinated by IANA
in an informal manner, and may be initiated by either the registrant in an informal manner, and may be initiated by either the registrant
or by IANA, e.g., by the latter requesting an update to current or by IANA, e.g., by the latter requesting an update to current
contact information. (Note that Registration Administrative Contact contact information. (Note that Registration Administrative Contact
cannot be changed; see Section 8.5 above.) cannot be changed; see Section 8.5 above.)
9. Security Considerations 9. Security Considerations
The IANA guidelines described in this document do not change the The IANA guidelines described in this document do not change the
security properties of UDP, TCP, SCTP, or DCCP. security properties of UDP, TCP, SCTP, or DCCP.
Assignment of a port number or service name does not in any way imply Assignment of a service name or port number does not in any way imply
an endorsement of an application or product, and the fact that an endorsement of an application or product, and the fact that
network traffic is flowing to or from a registered port number does network traffic is flowing to or from an assigned port number does
not mean that it is "good" traffic, or even that it is used by the not mean that it is "good" traffic, or even that it is used by the
assigned service. Firewall and system administrators should choose assigned service. Firewall and system administrators should choose
how to configure their systems based on their knowledge of the how to configure their systems based on their knowledge of the
traffic in question, not whether there is a port number or service traffic in question, not based on whether or not there is an assigned
name registered or not. service name or port number.
Services are expected to include support for security, either as Services are expected to include support for security, either as
default or dynamically negotiated in-band. The use of separate port default or dynamically negotiated in-band. The use of separate
number or service name assignments for secure and insecure variants service name or port number assignments for secure and insecure
of the same service is to be avoided in order to discourage the variants of the same service is to be avoided in order to discourage
deployment of insecure services. the deployment of insecure services.
10. IANA Considerations 10. IANA Considerations
This document obsoletes Sections 8 and 9.1 of the March 2000 IANA This document obsoletes Sections 8 and 9.1 of the March 2000 IANA
Allocation Guidelines [RFC2780]. Allocation Guidelines [RFC2780].
Upon approval of this document, IANA is requested to contact the Upon approval of this document, IANA is requested to contact Stuart
maintainer of the [SRVREG] registry, in order to merge the contents Cheshire, maintainer of the independent service name registry
of that private registry into the official IANA registry. It is [SRVREG], in order to merge the contents of that private registry
expected that the contents of [SRVREG] will at that time be replaced into the official IANA registry. It is expected that the independent
with pointers to the IANA registry and to this RFC. registry web page will be updated with pointers to the IANA registry
and to this RFC.
IANA is instructed to create a new service name entry in the port IANA is instructed to create a new service name entry in the service
number registry [PORTREG] for any entry in the "Protocol and Service name and port number registry [PORTREG] for any entry in the
Names" registry [PROTSERVREG] that does not already have one "Protocol and Service Names" registry [PROTSERVREG] that does not
assigned. already have one assigned.
IANA is also instructed to indicate which service name aliases in the IANA is also instructed to indicate in the Assignment Notes for "www"
existing registry are the primary aliases (see Section 5). and "www-http" that they are aliases, and should not be used for
service discovery purposes. For this conceptual service (human-
readable web pages served over HTTP) the correct "primary" service
name to use for service discovery purposes is "http" (see Section 5).
10.1. Service Name Consistency 10.1. Service Name Consistency
Section 8.1 defines which character strings are well-formed service Section 8.1 defines which character strings are well-formed service
names, which until now had not been clearly defined. The definition names, which until now had not been clearly defined. The definition
in Section 8.1 was chosen to allow maximum compatibility of service in Section 8.1 was chosen to allow maximum compatibility of service
names with current and future service discovery mechanisms. names with current and future service discovery mechanisms.
As of August 5, 2009 approximately 98% of the so-called "Short Names" As of August 5, 2009 approximately 98% of the so-called "Short Names"
from existing port number registrations [PORTREG] meet the rules for from existing port number registrations [PORTREG] meet the rules for
legal service names stated in Section 8.1, and hence will be used legal service names stated in Section 8.1, and hence for these
unmodified. services their service name will be exactly the same as their "Short
Name".
The remaining approximately 2% of the exiting "Short Names" are not The remaining approximately 2% of the exiting "Short Names" are not
suitable to be used directly as well-formed service names because suitable to be used directly as well-formed service names because
they contain illegal characters such as asterisks, dots, pluses, they contain illegal characters such as asterisks, dots, pluses,
slashes, or underscores. All existing "Short Names" conform to the slashes, or underscores. All existing "Short Names" conform to the
length requirement of 15 characters or fewer. For these unsuitable length requirement of 15 characters or fewer. For these unsuitable
"Short Names", listed in the table below, the service name will be "Short Names", listed in the table below, the service name will be
the Short Name with any illegal characters replaced by hyphens. IANA the Short Name with any illegal characters replaced by hyphens. IANA
SHALL add an entry to the registry giving the new well-formed primary SHALL add an entry to the registry giving the new well-formed primary
service name for the existing service, that otherwise duplicates the service name for the existing service, that otherwise duplicates the
original assignment information. In the description field of this original assignment information. In the description field of this
new entry giving the primary service name, IANA SHALL record that it new entry giving the primary service name, IANA SHALL record that it
assigns a well-formed service name for the previous service and assigns a well-formed service name for the previous service and
reference the original assignment. In the description field of the reference the original assignment. In the Assignment Notes field of
original assignment, IANA SHALL add a note that this entry is an the original assignment, IANA SHALL add a note that this entry is an
alias to the new well-formed service name, and that the old service alias to the new well-formed service name, and that the old service
name is historic, not usable for use with many common service name is historic, not usable for use with many common service
discovery mechanisms. discovery mechanisms.
Names containing illegal characters to be replaced by hyphens: Names containing illegal characters to be replaced by hyphens:
+----------------+-----------------+-----------------+ +----------------+-----------------+-----------------+
| 914c/g | acmaint_dbd | acmaint_transd | | 914c/g | acmaint_dbd | acmaint_transd |
| atex_elmd | avanti_cdp | badm_priv | | atex_elmd | avanti_cdp | badm_priv |
| badm_pub | bdir_priv | bdir_pub | | badm_pub | bdir_priv | bdir_pub |
skipping to change at page 24, line 48 skipping to change at page 24, line 48
| universe_suite | veritas_pbx | vision_elmd | | universe_suite | veritas_pbx | vision_elmd |
| vision_server | wrs_registry | z39.50 | | vision_server | wrs_registry | z39.50 |
+----------------+-----------------+-----------------+ +----------------+-----------------+-----------------+
Following the example set by the "application/whoispp-query" MIME Following the example set by the "application/whoispp-query" MIME
Content-Type [RFC2957], the service name for "whois++" will be Content-Type [RFC2957], the service name for "whois++" will be
"whoispp". "whoispp".
10.2. Port Numbers for SCTP and DCCP Experimentation 10.2. Port Numbers for SCTP and DCCP Experimentation
Two Well Known UDP and TCP ports, 1021 and 1022, have been reserved Two System UDP and TCP ports, 1021 and 1022, have been reserved for
for experimental use [RFC4727]. This document registers the same experimental use [RFC4727]. This document assigns the same port
port numbers for SCTP and DCCP, and also instructs IANA to numbers for SCTP and DCCP, updates the TCP and UDP registrations, and
automatically register these two port numbers for any new transport also instructs IANA to automatically assign these two port numbers
protocol that will in the future share the port number namespace. for any future transport protocol with a similar sixteen-bit port
number namespace.
Note that these port numbers are meant for temporary experimentation Note that these port numbers are meant for temporary experimentation
and development in controlled environments. Before using these port and development in controlled environments. Before using these port
numbers, carefully consider the advice in Section 6.1 in this numbers, carefully consider the advice in Section 6.1 in this
document, as well as in Sections 1 and 1.1 of "Assigning Experimental document, as well as in Sections 1 and 1.1 of "Assigning Experimental
and Testing Numbers Considered Useful" [RFC3692]. Most importantly, and Testing Numbers Considered Useful" [RFC3692]. Most importantly,
application developers must request a permanent port number application developers must request a permanent port number
assignment from IANA as described in Section 8.1 before any kind of assignment from IANA as described in Section 8.1 before any kind of
non-experimental deployment. non-experimental deployment.
+-------------------------------------+----------------------------+ +-------------------------------------+----------------------------+
| Registration Administrative Contact | IETF <iesg@ietf.org> | | Registration Administrative Contact | IETF <iesg@ietf.org> |
| Registration Technical Contact | IESG <iesg@ietf.org> | | Registration Technical Contact | IESG <iesg@ietf.org> |
| Service Name | exp1 | | Service Name | exp1 |
| Port Number | 1021 | | Port Number | 1021 |
| Transport Protocol | SCTP, DCCP | | Transport Protocol | DCCP, SCTP, TCP, UDP |
| Description | RFC3692-style Experiment 1 | | Description | RFC3692-style Experiment 1 |
| Reference | [RFCyyyy] | | Reference | [RFCyyyy],RFC 4727] |
+-------------------------------------+----------------------------+ +-------------------------------------+----------------------------+
+-------------------------------------+----------------------------+ +-------------------------------------+----------------------------+
| Registration Administrative Contact | IETF <iesg@ietf.org> | | Registration Administrative Contact | IETF <iesg@ietf.org> |
| Registration Technical Contact | IESG <iesg@ietf.org> | | Registration Technical Contact | IESG <iesg@ietf.org> |
| Service Name | exp2 | | Service Name | exp2 |
| Port Number | 1022 | | Port Number | 1022 |
| Transport Protocol | SCTP, DCCP | | Transport Protocol | DCCP, SCTP, TCP, UDP |
| Description | RFC3692-style Experiment 2 | | Description | RFC3692-style Experiment 2 |
| Reference | [RFCyyyy] | | Reference | [RFCyyyy], [RFC4727] |
+-------------------------------------+----------------------------+ +-------------------------------------+----------------------------+
[RFC Editor Note: Please change "yyyy" to the RFC number allocated to [RFC Editor Note: Please change "yyyy" to the RFC number allocated to
this document before publication.] this document before publication.]
10.3. Updates to DCCP Registries 10.3. Updates to DCCP Registries
This document updates the IANA allocation procedures for the DCCP This document updates the IANA allocation procedures for the DCCP
Port Number and DCCP Service Codes Registries [RFC4340]. Port Number and DCCP Service Codes Registries [RFC4340].
skipping to change at page 26, line 14 skipping to change at page 26, line 18
o IANA should feel free to contact the DCCP Expert Reviewer with o IANA should feel free to contact the DCCP Expert Reviewer with
questions on any registry, regardless of the registry policy, for questions on any registry, regardless of the registry policy, for
clarification or if there is a problem with a request [RFC4340]. clarification or if there is a problem with a request [RFC4340].
10.3.2. DCCP Port Numbers Registry 10.3.2. DCCP Port Numbers Registry
The DCCP ports registry is defined by Section 19.9 of the DCCP The DCCP ports registry is defined by Section 19.9 of the DCCP
specification [RFC4340]. Allocations in this registry require prior specification [RFC4340]. Allocations in this registry require prior
allocation of a Service Code. Not all Service Codes require IANA- allocation of a Service Code. Not all Service Codes require IANA-
registered ports. This document updates that section by extending assigned ports. This document updates that section by extending the
the guidelines given there in the following way: guidelines given there in the following way:
o IANA should normally assign a value in the range 1024-49151 to a o IANA should normally assign a value in the range 1024-49151 to a
DCCP server port. IANA allocation requests to allocate port DCCP server port. IANA allocation requests to allocate port
numbers in the Well Known Ports range (0 through 1023), require an numbers in the System Ports range (0 through 1023), require an
"IETF Review" [RFC5226] prior to allocation by IANA [RFC4340]. "IETF Review" [RFC5226] prior to allocation by IANA [RFC4340].
o IANA MUST NOT allocate more than one DCCP server port to a single o IANA MUST NOT allocate more than one DCCP server port to a single
service code value. service code value.
o The allocation of multiple service codes to the same DCCP port is o The allocation of multiple service codes to the same DCCP port is
allowed, but subject to expert review. allowed, but subject to expert review.
o The set of Service Code values associated with a DCCP server port o The set of Service Code values associated with a DCCP server port
should be recorded in the ports registry. should be recorded in the service name and port number registry.
o A request for additional Service Codes to be associated with an o A request for additional Service Codes to be associated with an
already allocated Port Number requires Expert Review. These already allocated Port Number requires Expert Review. These
requests will normally be accepted when they originate from the requests will normally be accepted when they originate from the
contact associated with the port registration. In other cases, contact associated with the port registration. In other cases,
these applications will be expected to use an unallocated port, these applications will be expected to use an unallocated port,
when this is available. when this is available.
The DCCP specification [RFC4340] notes that a short port name MUST be The DCCP specification [RFC4340] notes that a short port name MUST be
associated with each DCCP server port that has been registered. This associated with each DCCP server port that has been assigned. This
document requires that this name MUST be unique. document clarifies that this short port name is the Service Name as
defined here, and this name MUST be unique.
11. Contributors 11. Contributors
Stuart Cheshire (cheshire@apple.com), Alfred Hoenes (ah@tr-sys.de) Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have
and Allison Mankin (mankin@psg.com) have contributed text and ideas contributed text and ideas to this document.
to this document.
12. Acknowledgments 12. Acknowledgments
The text in Section 10.3 is based on a suggestion originally proposed The text in Section 10.3 is based on a suggestion originally proposed
as a part of [RFC5595] by Gorry Fairhurst. as a part of the DCCP Service Codes document[RFC5595] by Gorry
Fairhurst.
Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a
research project supported by the European Commission under its research project supported by the European Commission under its
Seventh Framework Program. Seventh Framework Program.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
skipping to change at page 28, line 17 skipping to change at page 28, line 21
[I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-06 (work in Discovery", draft-cheshire-dnsext-dns-sd-06 (work in
progress), March 2010. progress), March 2010.
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008. draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.gudmundsson-dnsext-srv-clarify]
Gudmundsson, O. and A. Hoenes, "Clarification of DNS SRV
Owner Names", draft-gudmundsson-dnsext-srv-clarify-00
(work in progress), December 2009.
[IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0",
November 2001. November 2001.
[PORTREG] Internet Assigned Numbers Authority (IANA), "Port Numbers [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name
Registry", http://www.iana.org/assignments/port-numbers. and Transport Protocol Port Number Registry",
http://www.iana.org/assignments/port-numbers.
[PROTSERVREG] [PROTSERVREG]
Internet Assigned Numbers Authority (IANA), "Protocol and Internet Assigned Numbers Authority (IANA), "Protocol and
Service Names Registry", Service Names Registry",
http://www.iana.org/assignments/service-names. http://www.iana.org/assignments/service-names.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)",
 End of changes. 127 change blocks. 
434 lines changed or deleted 442 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail-6--687802607 Content-Disposition: attachment; filename=draft-ietf-tsvwg-iana-ports.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-tsvwg-iana-ports.txt" Content-Transfer-Encoding: quoted-printable Transport Area Working Group M. Cotton Internet-Draft ICANN Updates: 2780, 2782, 3828, 4340, L. Eggert 4960 (if approved) Nokia Intended status: BCP J. Touch Expires: March 21, 2011 USC/ISI M. Westerlund Ericsson S. Cheshire Apple September 17, 2010 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry draft-ietf-tsvwg-iana-ports-07 Abstract This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling registration and other requests related to the Service Name and Transport Protocol Port Number Registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782] to clarify what a service name is and how it is registered. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2011. Cotton, et al. Expires March 21, 2011 [Page 1] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Cotton, et al. Expires March 21, 2011 [Page 2] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conventions Used in this Document . . . . . . . . . . . . . . 7 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Service names and Port Numbers for Experimentation . . . . 11 7. Principles for Service Name and Transport Protocol Port Number Registry Management . . . . . . . . . . . . . . . . . . 12 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13 7.3. Variances for Specific Port Number Ranges . . . . . . . . 15 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry . . . . . . . . . . . 16 8.1. Service Name and Port Number Registration . . . . . . . . 16 8.2. Service Name and Port Number De-Registration . . . . . . . 19 8.3. Service Name and Port Number Re-Use . . . . . . . . . . . 20 8.4. Service Name and Port Number Revocation . . . . . . . . . 20 8.5. Service Name and Port Number Transfers . . . . . . . . . . 21 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 22 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Cotton, et al. Expires March 21, 2011 [Page 3] =0C Internet-Draft Service Name and Port Number Procedures September 2010 1. Introduction For many years, the allocation of new service names and port number values for use with the Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have had less than clear guidelines. New transport protocols have been added - the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have been developed, each with separate registries and separate guidelines. The community also recognized the need for additional procedures beyond just assignment; notably modification, revocation, and release. A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. This document brings the IANA procedures for TCP and UDP in line with those for SCTP and DCCP, resulting in a single process that requesters and IANA follow for all requests for all transport protocols, including future protocols not yet defined. In addition to detailing the IANA procedures for the initial assignment of service names and port numbers, this document also specifies post-assignment procedures that until now have been handled in an ad hoc manner. These include procedures to de-register a port number that is no longer in use, to re-use a port number allocated for one application that is no longer in use for another application, and the procedure by which IANA can unilaterally revoke a prior port number assignment. Section 8 discusses the specifics of these procedures and processes that requesters and IANA follow for all requests for all current and future transport protocols. IANA is the authority for assigning service names and port numbers. The registries that are created to store these registrations are maintained by IANA. For protocols developed by IETF working groups, IANA now also offers a method for the "early assignment" [RFC4020] of service names and port numbers, as described in Section 8.1. This document updates IANA's procedures for UDP and TCP port numbers by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780]. (Note that other sections of the IANA allocation guidelines, relating to the protocol field values in IPv4 header, were also updated in February 2008 [RFC5237].) This document also updates the IANA allocation procedures for DCCP [RFC4340] and SCTP [RFC4960]. The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares the port space with UDP. The UDP-Lite specification says: "UDP-Lite uses the same set of port number values assigned by the IANA for use Cotton, et al. Expires March 21, 2011 [Page 4] =0C Internet-Draft Service Name and Port Number Procedures September 2010 by UDP". Thus the update of UDP procedures result in an update also of the UDP-Lite procedures. This document also clarifies what a service name is and how it is registered. This will impact the DNS SRV specification [RFC2782], because that specification merely makes a brief mention that the symbolic names of services are defined in "Assigned Numbers" [RFC1700], without stating to which section it refers within that 230-page document. The DNS SRV specification may have been referring to the list of Port Assignments (known as /etc/services on Unix), or to the "Protocol And Service Names" section, or to both, or to some other section. Furthermore, "Assigned Numbers" is now obsolete [RFC3232] and has been replaced by on-line registries [PORTREG][PROTSERVREG]. The development of new transport protocols is a major effort that the IETF does not undertake very often. If a new transport protocol is standardized in the future, for consistency it is expected to follow as much as possible the guidelines and practices around using service names and port numbers. 2. Motivation Information about the registration procedures for the port registry has existed in three locations: the forms for requesting port number registrations on the IANA web site [SYSFORM] [USRFORM], an introductory text section in the file listing the port number registrations themselves [PORTREG], and two brief sections of the IANA Allocation Guidelines [RFC2780]. Similarly, the procedures surrounding service names have been historically unclear. Service names were originally created as mnemonic identifiers for port numbers without a well-defined syntax, beyond the 14-character limit mentioned on the IANA website [SYSFORM] [USRFORM]. Even that length limit has not been consistently applied, and some assigned service names are 15 characters long. When service identification via DNS SRV Resource Records (RRs) was introduced, the requirement by IANA to only assign service names and port numbers in combination, led to the creation of an ad hoc service name registry outside of the control of IANA [SRVREG]. This document aggregates all this scattered information into a single reference that aligns and clearly defines the management procedures for both service names and port numbers. It gives more detailed guidance to prospective requesters of service names and ports than the existing documentation, and it streamlines the IANA procedures for the management of the registry, so that management requests can Cotton, et al. Expires March 21, 2011 [Page 5] =0C Internet-Draft Service Name and Port Number Procedures September 2010 complete in a timely manner. This document defines rules for registration of service names without associated port numbers, for such usages as DNS SRV records [RFC2782], which was not possible under the previous IANA procedures. The document also merges service name registrations from the non-IANA ad hoc registry [SRVREG] and from the IANA "Protocol and Service Names" registry [PROTSERVREG] into the IANA "Service Name and Transport Protocol Port Number" registry [PORTREG], which from here on is the single authoritative registry for service names and port numbers. An additional purpose of this document is to describe the principles that guide the IETF and IANA in their role as the long-term joint stewards of the service name and port number registry. TCP and UDP have had remarkable success over the last decades. Thousands of applications and application-level protocols have service names and ports assigned for their use, and there is every reason to believe that this trend will continue into the future. It is hence extremely important that management of the registry follow principles that ensure its long-term usefulness as a shared resource. Section 7 discusses these principles in detail. 3. Background The Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success over the decades as the two most widely used transport protocols on the Internet. They have relied on the concept of "ports" as logical entities for Internet communication. Ports serve two purposes: first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes bind. Newer transport protocols, such as the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] have also adopted the concept of ports for their communication sessions and use sixteen-bit port numbers in the same way as TCP and UDP (and UDP-Lite [RFC3828], a variant of UDP). Port numbers are the original and most widely used means for application and service identification on the Internet. Ports are sixteen-bit numbers, and the combination of source and destination port numbers together with the IP addresses of the communicating end systems uniquely identifies a session of a given transport protocol. Port numbers are also known by their associated service names such as "telnet" for port number 23 and "http" (and the "www" and "www-http" Cotton, et al. Expires March 21, 2011 [Page 6] =0C Internet-Draft Service Name and Port Number Procedures September 2010 aliases) for port number 80. Hosts running services, hosts accessing services on other hosts, and intermediate devices (such as firewalls and NATs) that restrict services need to agree on which service corresponds to a particular destination port. Although this is ultimately a local decision with meaning only between the endpoints of a connection, it is common for many services to have a default port upon which those servers usually listen, when possible, and these ports are recorded by the Internet Assigned Numbers Authority (IANA) through the service name and port number registry [PORTREG]. Over time, the assumption that a particular port number necessarily implies a particular service may become less true. For example, multiple instances of the same service on the same host cannot generally listen on the same port, and multiple hosts behind the same NAT gateway cannot all have a mapping for the same port on the external side of the NAT gateway, whether using static port mappings configured by hand by the user, or dynamic port mappings configured automatically using a port mapping protocol like NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device (IGD) [IGD]. Applications may use numeric port numbers directly, look up port numbers based on service names via system calls such as getservbyname() on UNIX, look up port numbers by performing queries for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd], or determine port numbers in a variety of other ways like the TCP Port Service Multiplexer (TCPMUX) [RFC1078]. Designers of applications and application-level protocols may apply to IANA for an assigned service name and port number for a specific application, and may - after successful registration - assume that no other application will use that service name or port number for its communication sessions. Alternatively, application designers may also ask for only an assigned service name, if their application does not require a fixed port number. The latter alternative is encouraged when possible, in order to conserve the more limited port number space. This is applicable, for example, to applications that use DNS SRV records to look up port numbers at runtime. 4. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Cotton, et al. Expires March 21, 2011 [Page 7] =0C Internet-Draft Service Name and Port Number Procedures September 2010 5. Service Names Service names are the unique key in the Service Name and Transport Protocol Port Number Registry. This unique symbolic name for a service may also be used for other purposes, such as in DNS SRV records [RFC2782]. Within the registry, this unique key ensures that different services can be unambiguously distinguished, thus preventing name collisions and avoiding confusion about who is the administrative contact for a particular entry. There may be more than one service name associated with a particular transport protocol and port. There are two ways that service name aliases occur: o Aliases occur when one service is an extension of another service, and an in-band mechanism exists for determining if the extension is present or not. One example is port 3478, which has the service name aliases "stun" and "turn". TURN [RFC5766] is an extension to the STUN [RFC5389] service. TURN-enabled clients wishing to locate TURN servers could attempt to discover "stun" services and then check in-band if the server supports TURN, but this would be inefficient. Enabling them to directly query for "turn" servers by name is a better approach. (Note that TURN servers in this case should also be locatable via a "stun" discovery, because every TURN server is also a STUN server.) o By historical accident the service name "http" also has aliases "www" and "www-http". When used in SRV records [RFC2782], and similar service discovery mechanisms only the service name "http" should be used, not the aliases. If a server were to advertise "www" then it would not be discovered by clients browsing for "http". Advertising or browsing for the aliases as well as the primary service name would be inefficient, and achieves nothing that it not already achieved by using the service name "http" exclusively. For future assignments, applications will not be permitted that merely request a new name exactly duplicating an existing service. Having multiple names for the same service serves no purpose. Implementers are requested to inform IANA if they discover other cases where a single service has multiple names, so that one name may be recorded as the primary name for service discovery purposes. Service names are assigned on a "first come, first served" basis, as described in Section 8.1. Names should be brief and informative, avoiding words or abbreviations that are redundant in the context of the registry (e.g., "port", "service", "protocol", etc.) Names referring to discovery services, e.g., using multicast or broadcast Cotton, et al. Expires March 21, 2011 [Page 8] =0C Internet-Draft Service Name and Port Number Procedures September 2010 to identify endpoints capable of a given service, SHOULD use an easily identifiable suffix (e.g., "-disc"). 5.1. Service Name Syntax Valid service names: o MUST be at least 1 character and no more than 15 characters long o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45) o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') o MUST NOT begin or end with a hyphen The reason for requiring at least one letter is to avoid service names like "23" (could be confused with a numeric port number) or "6000-6063" (could be confused with a numeric port number range). Although service names may contain both upper-case and lower-case letters, case is ignored for comparison purposes, so both "http" and "HTTP" denote the same service. Service names are purely opaque identifiers, and no semantics are implied by any superficial structure that a given service name may appear to have. For example, a company called "Example" may choose to register service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" products, but the "Example" company can't claim to "own" all service names beginning with "Example-", they can't prevent someone else registering "Example-Baz" for a different service, and they can't prevent other developers from using the "Example-Foo" and "Example-Bar" service types in order to interoperate with the "Foo" and "Bar" products. Technically speaking, in service discovery protocols, service names are merely a series of byte values on the wire; for the mnemonic convenience of human developers it can be convenient to interpret those byte values as human-readable ascii characters, but software should treat them as purely opaque identifiers and not attempt to parse them for any additional embedded meaning. In approximately 98% of cases, the new "service name" is exactly the same as the old historic "short name" from the IANA web forms [SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service name" is derived from the old historic "short name" as described below in Section 10.1. The rules for valid service names are also expressed below using ABNF Cotton, et al. Expires March 21, 2011 [Page 9] =0C Internet-Draft Service Name and Port Number Procedures September 2010 [RFC5234]. (In the event that the ABNF rules are found to differ from the plain-English rules above, the plain-English rules take priority and are the definitive statement of what constitutes a legal service name.) SRVNAME =3D (ALPHA / *([HYPHEN] ALNUM)) / (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM)) ALNUM =3D ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN =3D %x2d ; "-" ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] DIGIT =3D %x30-39 ; 0-9 [RFC5234] 5.2. Service Name Usage in DNS SRV Records The DNS SRV specification [RFC2782] states that the Service Label part of the owner name of a DNS SRV record includes a "Service" element, described as "the symbolic name of the desired service", but as discussed above, it is not clear precisely what this means. This document clarifies that the Service Label MUST be a service name as defined herein. The service name SHOULD be registered with IANA and recorded in the Service Name and Transport Protocol Port Number Registry [PORTREG]. The details of using Service Names in SRV Service Labels are specified in the DNS SRV specification [RFC2782]. This document does not change that specification. 6. Port Number Ranges TCP, UDP, UDP-Lite, SCTP and DCCP use sixteen-bit namespaces for their port number registries. The port registries for all these transport protocols are subdivided into three ranges of numbers, and Section 7.3 describes the IANA procedures for each range in detail: o the System Ports, also known as the Well Known Ports, from 0-1023 (assigned by IANA) o the User Ports, also known as the Registered Ports, from 1024- 49151 (assigned by IANA) o the Dynamic Ports, also known as the Private Ports, from 49152- 65535 (never assigned) Of the assignable port ranges (System Ports and User Ports, i.e., port numbers 0-49151), individual port numbers are in one of three Cotton, et al. Expires March 21, 2011 [Page 10] =0C Internet-Draft Service Name and Port Number Procedures September 2010 states at any given time: o Assigned: Assigned port numbers are currently allocated to the service indicated in the registry. o Unassigned: Unassigned port numbers are currently available for assignment upon request, as per the procedures outlined in this document. o Reserved: Reserved port numbers are not available for regular assignment; they are "assigned to IANA" for special purposes. Reserved port numbers include values at the edges of each range, e.g., 0, 1023, 1024, etc., which may be used to extend these ranges or the overall port number space in the future. In order to keep the size of the registry manageable, IANA typically only records the Assigned and Reserved service names and port numbers in the registry. Unassigned values are typically not explicitly listed. (There are an near-infinite number of Unassigned service names and enumerating them all would not be practical.) As a data point, when this document was written, approximately 76% of the TCP and UDP System Ports were assigned, and approximately 9% of the User Ports were assigned. (As noted, Dynamic Ports are never assigned.) 6.1. Service names and Port Numbers for Experimentation Of the System Ports, two TCP and UDP port numbers (1021 and 1022), together with their respective service names ("exp1" and "exp2"), have been assigned for experimentation with new applications and application-layer protocols that require a port number in the assigned ports ranges [RFC4727]. Please refer to Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] for how these experimental port numbers are to be used. This document registers the same two service names and port numbers for experimentation with new application-layer protocols over SCTP and DCCP in Section 10.2. Unfortunately, it can be difficult to limit access to these ports. Users SHOULD take measures to ensure that experimental ports are connecting to the intended process. For example, users of these experimental ports might include a 64-bit nonce, once on each segment of a message-oriented channel (e.g., UDP), or once at the beginning of a byte-stream (e.g., TCP), which is used to confirm that the port Cotton, et al. Expires March 21, 2011 [Page 11] =0C Internet-Draft Service Name and Port Number Procedures September 2010 is being used as intended. Such confirmation of intended use is especially important when these ports are associated with privileged (e.g., system or administrator) processes. 7. Principles for Service Name and Transport Protocol Port Number Registry Management Management procedures for the service name and transport protocol port number registry include allocation of service names and port numbers upon request, as well as management of information about existing allocations. The latter includes maintaining contact and description information about assignments, revoking abandoned assignments, and redefining assignments when needed. Of these procedures, careful port number allocation is most critical, in order to continue to conserve the remaining port numbers. As noted earlier, only about 9% of the User Port space is currently assigned. The current rate of assignment is approximately 400 ports per year, and has remained steady for the past 8 years. At that rate, if similar conservation continues, this resource will sustain another 85 years of assignment - without the need to resort to reassignment of released values or revocation. The namespace available for service names is much larger, which allows for simpler management procedures. 7.1. Past Principles Before the publication of this document, the principles of service name and port number management followed a few mostly-undocumented guidelines. They are recorded here for historical purposes, and this document updates them in Section 7.2. These principles were: o TCP and UDP ports were simultaneously allocated when either was requested o Port numbers were the primary allocation; service names were informative only, and did not have a well-defined syntax o Port numbers were conserved informally, and sometimes inconsistently (e.g., some services were allocated ranges of many port numbers even where not strictly necessary) o SCTP and DCCP service name and port number registries were managed separately from the TCP/UDP registries o Service names could not be assigned in the old ports registry without assigning an associated port number at the same time Cotton, et al. Expires March 21, 2011 [Page 12] =0C Internet-Draft Service Name and Port Number Procedures September 2010 This document clarifies and aligns these guidelines in order to more conservatively manage the limited remaining port number space and to enable and promote the use of service names for service identification without associated port numbers, where possible. 7.2. Updated Principles This section summarizes the basic principles by which IANA handles the Service Name and Transport Protocol Port Number Registry, and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA decisions are not required to be bound by these principles; other factors may come into play, and exceptions may occur where deemed in the best interest of the Internet. IANA will begin assigning service names that do not request an associated port number allocation under a simple "First Come, First Served" policy [RFC5226]. IANA MAY, at its discretion, refer service name requests to "Expert Review" in cases of mass registrations or other situations where IANA believes expert review is advisable. The basic principle of service name and port number registry management is to conserve use of the port space where possible. Extensions to support larger port number spaces would require changing many core protocols of the current Internet in a way that would not be backward compatible and interfere with both current and legacy applications. To help ensure this conservation the policy for any registration request for port number allocations uses the "Expert Review" policy [RFC5226]. Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. In particular: o IANA will allocate only one assigned port number per service or application o IANA will allocate only one assigned port number for all versions of a service (e.g., running the service with or without a security mechanism, or for updated variants of a service) o IANA will allocate only one assigned port number for all different types of device using or participating in the same service Cotton, et al. Expires March 21, 2011 [Page 13] =0C Internet-Draft Service Name and Port Number Procedures September 2010 o IANA will allocate port numbers only for the transport protocol(s) explicitly named in a registration request o IANA may recover unused port numbers, via the new procedures of de-registration, revocation, and transfer Where possible, a given service is expected to demultiplex messages if necessary. For example, applications and protocols are expected to include in-band version information, so that future versions of the application or protocol can share the same allocated port. Applications and protocols are also expected to be able to efficiently use a single allocated port for multiple sessions, either by demultiplexing multiple streams within one port, or using the allocated port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]). Ports are used in various ways, notably: o as endpoint process identifiers o as application protocol identifiers o for firewall filtering purposes Both the process identifier and the protocol identifier uses suggest that anything a single process can demultiplex, or that can be encoded into a single protocol, should be. The firewall filtering use suggests that some uses that could be multiplexed or encoded could instead be separated to allow for easier firewall management. Note that this latter use is much less sound, because port numbers have meaning only for the two endpoints involved in a connection, and drawing conclusions about the service that generated a given flow based on observed port numbers is not always reliable. Further, previous separation of protocol variants based on security capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is not recommended for new protocols, because all new protocols should be security-capable and capable of negotiating the use of security in-band. IANA will begin assigning port numbers for only those transport protocols explicitly included in a registration request. This ends the long-standing practice of automatically assigning a port number to an application for both TCP and a UDP, even if the request is for only one of these transport protocols. The new allocation procedure conserves resources by allocating a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually uses. The port number will be marked as Reserved - instead of Assigned - in the port number registries of the other transport Cotton, et al. Expires March 21, 2011 [Page 14] =0C Internet-Draft Service Name and Port Number Procedures September 2010 protocols. When applications start supporting the use of some of those additional transport protocols, the administrative contact for the registration MUST request IANA to convert the reservation into a proper assignment. An application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport protocol without asking IANA to convert the reservation into an assignment. When the available pool of unassigned numbers has run out in a ports range, it will be necessary for IANA to consider the Reserved ports for assignment. This is part of the motivation for not automatically assigning ports for transport protocols other than the requested one(s). This will allow more ports to be available for assignment when that time comes. To help conserve ports, application developers should register only the transport protocols that their application in fact uses. Conservation of port numbers is improved by procedures that allow previously allocated port numbers to become Unassigned, either through de-registration or through revocation, and by a procedure that lets application designers transfer an allocated but unused port number to a new application. Section 8 describes these procedures, which until now were undocumented. Port number conservation is also improved by recommending that applications that do not require an allocated port should register only a service name without an associated port number. 7.3. Variances for Specific Port Number Ranges Section 6 describes the different port number ranges. It is important to note that IANA applies slightly different procedures when managing the different port ranges of the service name and port number registry: o Ports in the Dynamic Ports range (49152-65535) have been specifically set aside for local and dynamic use and cannot be assigned through IANA. Application software may simply use them for communication without any sort of registration. On the other hand, application software MUST NOT assume that a specific port number in the Dynamic Ports range will always be available for communication at all times, and a port number in that range hence MUST NOT be used as a service identifier. o Ports in the User Ports range (1024-49151) are available for registration through IANA, and MAY be used as service identifiers upon successful registration. Because registering a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the Cotton, et al. Expires March 21, 2011 [Page 15] =0C Internet-Draft Service Name and Port Number Procedures September 2010 requester to document the intended use of the port number. This documentation will be input to the "Expert Review" allocation procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the registration. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226], which is how most assignments for IETF protocols are handled. o Ports in the System Ports range (0-1023) are also available for registration through IANA. Because the System Ports range is both the smallest and the most densely allocated, the requirements for new allocations are more strict than those for the User Ports range, and will only be granted under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226]. A request for a System Port number MUST document *both* why using a port number from the User Ports is unsuitable *and* why using a port number from the Dynamic Ports ranges is unsuitable for that application. 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry This section describes the process for handling requests associated with IANA's management of the Service Name and Transport Protocol Port Number Registry. Such requests include initial registration, de-registration, re-use, changes to the service name, and updates to the contact information or description associated with an assignment. Revocation is as additional process, initiated by IANA. 8.1. Service Name and Port Number Registration Registration refers to the allocation of service names or port numbers to applicants. All such registrations are made from service names or port numbers that are Unassigned or Reserved at the time of the allocation. Unassigned names and numbers are allocated according to the rules described in Section 7.3. Reserved numbers and names are assigned only after review by IANA and the IETF, and are accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. When a registration for one or more transport protocols is approved, the port number for any non-requested transport protocol(s) will be marked as Reserved. IANA SHOULD NOT assign that port number to any other application or service until no other port numbers remain Unassigned in the requested range. The current administrative Cotton, et al. Expires March 21, 2011 [Page 16] =0C Internet-Draft Service Name and Port Number Procedures September 2010 contact for a port number MAY register these Reserved port numbers for other transport protocols when needed. A service name or port number registration request contains the following information. The service name is the unique identifier of a given service: Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) Registrant (REQUIRED) Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL) o Service Name: A desired unique service name for the service associated with the registration request MUST be provided, for use in various service selection and discovery mechanisms (including, but not limited to, DNS SRV records [RFC2782]). The name MUST be compliant with the syntax defined in Section 5.1. In order to be unique, they MUST NOT be identical to any currently assigned service name in the IANA registry [PORTREG]. Service names are case-insensitive; they may be provided and entered into the registry with mixed case for clarity, but for the comparison purposes the case is ignored. o Transport Protocol(s): The transport protocol(s) for which the allocation is requested MUST be provided. This field is currently limited to one or more of TCP, UDP, SCTP, and DCCP. This field is required even for services with no port number. Cotton, et al. Expires March 21, 2011 [Page 17] =0C Internet-Draft Service Name and Port Number Procedures September 2010 o Registrant: Name and email address of the Registrant. This is REQUIRED. The Registrant is the Organization or Company responsible for the initial registration. For registrations done through IETF-published RFCs, the Registrant will be the IESG. o Contact: Name and email address of the Contact person for the registration. This is REQUIRED. The Contact person is the responsible person for the Internet community to send questions to. This person would also be authorized to submit changes on behalf of the Registrant. Additional address information MAY be provided. For registrations done through IETF-published RFCs, the Contact will be the IESG. o Description: A short description of the service associated with the registration request is REQUIRED. It should avoid all but the most well-known acronyms. o Reference: A description of (or a reference to a document describing) the protocol or application using this port. The description must state whether the protocol uses broadcast, multicast, or anycast communication. For registrations requesting only a Service Name, or a Service Name and User Port, a statement that the protocol is proprietary and not publicly documented is also acceptable provided that the required information regarding use of broadcast, multicast, or anycast is given. For registration requests for a User Port, the registration request MUST explain why a port number in the Dynamic Ports range is unsuitable for the given application. For registration requests for a System Port, the registration request MUST explain why a port number in the User Ports or Dynamic Ports ranges is unsuitable, and a reference to a stable protocol specification document MUST be provided. For requests from IETF Working Groups, IANA MAY accept "early registration" [RFC4020] requests referencing a sufficiently stable Internet Draft instead of a published Standards-Track RFC. o Port Number: If assignment of a port number is desired, either the currently Unassigned or Reserved port number the requester suggests for allocation, or the text "ANY", MUST be provided. If only a service name is to be assigned, this field MUST be empty. If a specific port number is requested, IANA is encouraged to allocate the requested number. If the text "ANY" is specified, IANA will choose a suitable number from the User Ports range. Note that the applicant MUST NOT use the requested port prior to Cotton, et al. Expires March 21, 2011 [Page 18] =0C Internet-Draft Service Name and Port Number Procedures September 2010 the completion of the registration. o Service Code: If the registration request includes DCCP as a transport protocol then the request MUST include a desired unique DCCP service code [RFC5595], and MUST NOT include a requested DCCP service code otherwise. Section 19.8 of the DCCP specification [RFC4340] defines requirements and rules for allocation, updated by this document. o Known Unauthorized Uses: A list of uses by applications or organizations who are not the assignee. This list may be augmented by IANA after assignment when unauthorized uses are reported. o Assignment Notes: Indications of owner/name change, or any other assignment process issue. This list may be updated by IANA after assignment to help track changes to an assignment, e.g., de- registration, owner/name changes, etc. If the registration request is for the addition of a new transport protocol to an already assigned service name, IANA needs to confirm with the administrative contact for the existing assignment whether this addition is appropriate. When IANA receives a registration request - containing the above information - that is requesting a port number, IANA SHALL initiate an "Expert Review" [RFC5226] in order to determine whether an assignment should be made. For requests that do not include a port number, IANA SHOULD assign the service name under a simple "First Come First Served" policy [RFC5226]. 8.2. Service Name and Port Number De-Registration The administrative contact of a granted port number assignment can return the port number to IANA at any time if they no longer have a need for it. The port number will be de-registered and will be marked as Reserved. IANA should not re-assign port numbers that have been de-registered until all unassigned port numbers in the specific range have been assigned. Before proceeding with a port number de-registration, IANA needs to reasonably establish that the value is actually no longer in use. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that a given service name remain assigned even after all associated port number assignments have become de-registered. Under this policy, it will appear in the registry as if it had been created through a Cotton, et al. Expires March 21, 2011 [Page 19] =0C Internet-Draft Service Name and Port Number Procedures September 2010 service name registration request that did not include any port numbers. On rare occasions, it may still be useful to de-register a service name. In such cases, IANA will mark the service name as Reserved. IANA will involve their IESG-appointed expert in such cases. 8.3. Service Name and Port Number Re-Use If the administrative contact of a granted port number assignment no longer have a need for the assigned number, but would like to re-use it for a different application, they can submit a request to IANA to do so. Logically, port number re-use is to be thought of as a de- registration (Section 8.2) followed by an immediate re-registration (Section 8.1) of the same port number for a new application. Consequently, the information that needs to be provided about the proposed new use of the port number is identical to what would need to be provided for a new port number allocation for the specific ports range. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that the original service name associated with the prior use of the port number remains assigned, and a new service be created and associated with the port number. This is again consistent with viewing a re-use request as a de-registration followed by an immediate re- registration. Re-using an assigned service name for a different application is NOT RECOMMENDED. IANA needs to carefully review such requests before approving them. In some instances, the Expert Reviewer will determine that the application that the port number was assigned to has found usage beyond the original requester, or that there is a concern that it may have such users. This determination MUST be made quickly. A community call concerning revocation of a port number (see below) MAY be considered, if a broader use of the port number is suspected. 8.4. Service Name and Port Number Revocation A port number revocation can be thought of as an IANA-initiated de- registration (Section 8.2), and has exactly the same effect on the registry. Sometimes, it will be clear that a specific port number is no longer in use and that IANA can revoke it and mark it as Reserved. At other times, it may be unclear whether a given assigned port number is Cotton, et al. Expires March 21, 2011 [Page 20] =0C Internet-Draft Service Name and Port Number Procedures September 2010 still in use somewhere in the Internet. In those cases, IANA must carefully consider the consequences of revoking the port number, and SHOULD only do so if there is an overwhelming need. With the help of their IESG-appointed Expert Reviewer, IANA SHALL formulate a request to the IESG to issue a four-week community call concerning the pending port number revocation. The IESG and IANA, with the Expert Reviewer's support, SHALL determine promptly after the end of the community call whether revocation should proceed and then communicate their decision to the community. This procedure typically involves similar steps to de-registration except that it is initiated by IANA. Because there is much less danger of exhausting the service name space compared to the port number space, revoking service names is NOT RECOMMENDED. 8.5. Service Name and Port Number Transfers The value of service names and port numbers is defined by their careful management as a shared Internet resource, whereas enabling transfer allows the potential for associated monetary exchanges. As a result, the IETF does not permit service name or port number assignments to be transferred between parties, even when they are mutually consenting. The appropriate alternate procedure is a coordinated de-registration and registration: The new party requests the service name or port number via a registration and the previous party releases its assignment via the de-registration procedure outlined above. With the help of their IESG-appointed Expert Reviewer, IANA SHALL carefully determine if there is a valid technical, operational or managerial reason to grant the requested new assignment. 8.6. Maintenance Issues In addition to the formal procedures described above, updates to the Description and Technical Contact information are coordinated by IANA in an informal manner, and may be initiated by either the registrant or by IANA, e.g., by the latter requesting an update to current contact information. (Note that Registration Administrative Contact cannot be changed; see Section 8.5 above.) 9. Security Considerations The IANA guidelines described in this document do not change the Cotton, et al. Expires March 21, 2011 [Page 21] =0C Internet-Draft Service Name and Port Number Procedures September 2010 security properties of UDP, TCP, SCTP, or DCCP. Assignment of a service name or port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from an assigned port number does not mean that it is "good" traffic, or even that it is used by the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, not based on whether or not there is an assigned service name or port number. Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. 10. IANA Considerations This document obsoletes Sections 8 and 9.1 of the March 2000 IANA Allocation Guidelines [RFC2780]. Upon approval of this document, IANA is requested to contact Stuart Cheshire, maintainer of the independent service name registry [SRVREG], in order to merge the contents of that private registry into the official IANA registry. It is expected that the independent registry web page will be updated with pointers to the IANA registry and to this RFC. IANA is instructed to create a new service name entry in the service name and port number registry [PORTREG] for any entry in the "Protocol and Service Names" registry [PROTSERVREG] that does not already have one assigned. IANA is also instructed to indicate in the Assignment Notes for "www" and "www-http" that they are aliases, and should not be used for service discovery purposes. For this conceptual service (human- readable web pages served over HTTP) the correct "primary" service name to use for service discovery purposes is "http" (see Section 5). 10.1. Service Name Consistency Section 8.1 defines which character strings are well-formed service names, which until now had not been clearly defined. The definition in Section 8.1 was chosen to allow maximum compatibility of service names with current and future service discovery mechanisms. Cotton, et al. Expires March 21, 2011 [Page 22] =0C Internet-Draft Service Name and Port Number Procedures September 2010 As of August 5, 2009 approximately 98% of the so-called "Short Names" from existing port number registrations [PORTREG] meet the rules for legal service names stated in Section 8.1, and hence for these services their service name will be exactly the same as their "Short Name". The remaining approximately 2% of the exiting "Short Names" are not suitable to be used directly as well-formed service names because they contain illegal characters such as asterisks, dots, pluses, slashes, or underscores. All existing "Short Names" conform to the length requirement of 15 characters or fewer. For these unsuitable "Short Names", listed in the table below, the service name will be the Short Name with any illegal characters replaced by hyphens. IANA SHALL add an entry to the registry giving the new well-formed primary service name for the existing service, that otherwise duplicates the original assignment information. In the description field of this new entry giving the primary service name, IANA SHALL record that it assigns a well-formed service name for the previous service and reference the original assignment. In the Assignment Notes field of the original assignment, IANA SHALL add a note that this entry is an alias to the new well-formed service name, and that the old service name is historic, not usable for use with many common service discovery mechanisms. Cotton, et al. Expires March 21, 2011 [Page 23] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Names containing illegal characters to be replaced by hyphens: +----------------+-----------------+-----------------+ | 914c/g | acmaint_dbd | acmaint_transd | | atex_elmd | avanti_cdp | badm_priv | | badm_pub | bdir_priv | bdir_pub | | bmc_ctd_ldap | bmc_patroldb | boks_clntd | | boks_servc | boks_servm | broker_service | | bues_service | canit_store | cedros_fds | | cl/1 | contamac_icm | corel_vncadmin | | csc_proxy | cvc_hostd | dbcontrol_agent | | dec_dlm | dl_agent | documentum_s | | dsmeter_iatc | dsx_monitor | elpro_tunnel | | elvin_client | elvin_server | encrypted_admin | | erunbook_agent | erunbook_server | esri_sde | | EtherNet/IP-1 | EtherNet/IP-2 | event_listener | | flr_agent | gds_db | ibm_wrless_lan | | iceedcp_rx | iceedcp_tx | iclcnet_svinfo | | idig_mux | ife_icorp | instl_bootc | | instl_boots | intel_rci | interhdl_elmd | | lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C | | LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet | | mdbs_daemon | menandmice_noh | msl_lmd | | nburn_id | ncr_ccl | nds_sso | | netmap_lm | nms_topo_serv | notify_srvr | | novell-lu6.2 | nuts_bootp | nuts_dem | | ocs_amu | ocs_cmu | pipe_server | | pra_elmd | printer_agent | redstorm_diag | | redstorm_find | redstorm_info | redstorm_join | | resource_mgr | rmonitor_secure | rsvp_tunnel | | sai_sentlm | sge_execd | sge_qmaster | | shiva_confsrvr | sql*net | srvc_registry | | stm_pproc | subntbcst_tftp | udt_os | | universe_suite | veritas_pbx | vision_elmd | | vision_server | wrs_registry | z39.50 | +----------------+-----------------+-----------------+ Following the example set by the "application/whoispp-query" MIME Content-Type [RFC2957], the service name for "whois++" will be "whoispp". 10.2. Port Numbers for SCTP and DCCP Experimentation Two System UDP and TCP ports, 1021 and 1022, have been reserved for experimental use [RFC4727]. This document assigns the same port numbers for SCTP and DCCP, updates the TCP and UDP registrations, and also instructs IANA to automatically assign these two port numbers for any future transport protocol with a similar sixteen-bit port Cotton, et al. Expires March 21, 2011 [Page 24] =0C Internet-Draft Service Name and Port Number Procedures September 2010 number namespace. Note that these port numbers are meant for temporary experimentation and development in controlled environments. Before using these port numbers, carefully consider the advice in Section 6.1 in this document, as well as in Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692]. Most importantly, application developers must request a permanent port number assignment from IANA as described in Section 8.1 before any kind of non-experimental deployment. +-------------------------------------+----------------------------+ | Registration Administrative Contact | IETF | | Registration Technical Contact | IESG | | Service Name | exp1 | | Port Number | 1021 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 1 | | Reference | [RFCyyyy],RFC 4727] | +-------------------------------------+----------------------------+ +-------------------------------------+----------------------------+ | Registration Administrative Contact | IETF | | Registration Technical Contact | IESG | | Service Name | exp2 | | Port Number | 1022 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 2 | | Reference | [RFCyyyy], [RFC4727] | +-------------------------------------+----------------------------+ [RFC Editor Note: Please change "yyyy" to the RFC number allocated to this document before publication.] 10.3. Updates to DCCP Registries This document updates the IANA allocation procedures for the DCCP Port Number and DCCP Service Codes Registries [RFC4340]. 10.3.1. DCCP Service Code Registry Service Codes are allocated first-come-first-served according to Section 19.8 of the DCCP specification [RFC4340]. This document updates that section by extending the guidelines given there in the following ways: Cotton, et al. Expires March 21, 2011 [Page 25] =0C Internet-Draft Service Name and Port Number Procedures September 2010 o IANA MAY assign new Service Codes without seeking Expert Review using their discretion, but SHOULD seek expert review if a request seeks more than five Service Codes. o IANA should feel free to contact the DCCP Expert Reviewer with questions on any registry, regardless of the registry policy, for clarification or if there is a problem with a request [RFC4340]. 10.3.2. DCCP Port Numbers Registry The DCCP ports registry is defined by Section 19.9 of the DCCP specification [RFC4340]. Allocations in this registry require prior allocation of a Service Code. Not all Service Codes require IANA- assigned ports. This document updates that section by extending the guidelines given there in the following way: o IANA should normally assign a value in the range 1024-49151 to a DCCP server port. IANA allocation requests to allocate port numbers in the System Ports range (0 through 1023), require an "IETF Review" [RFC5226] prior to allocation by IANA [RFC4340]. o IANA MUST NOT allocate more than one DCCP server port to a single service code value. o The allocation of multiple service codes to the same DCCP port is allowed, but subject to expert review. o The set of Service Code values associated with a DCCP server port should be recorded in the service name and port number registry. o A request for additional Service Codes to be associated with an already allocated Port Number requires Expert Review. These requests will normally be accepted when they originate from the contact associated with the port registration. In other cases, these applications will be expected to use an unallocated port, when this is available. The DCCP specification [RFC4340] notes that a short port name MUST be associated with each DCCP server port that has been assigned. This document clarifies that this short port name is the Service Name as defined here, and this name MUST be unique. 11. Contributors Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have contributed text and ideas to this document. Cotton, et al. Expires March 21, 2011 [Page 26] =0C Internet-Draft Service Name and Port Number Procedures September 2010 12. Acknowledgments The text in Section 10.3 is based on a suggestion originally proposed as a part of the DCCP Service Codes document[RFC5595] by Gorry Fairhurst. Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program. 13. References 13.1. Normative References [ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an Cotton, et al. Expires March 21, 2011 [Page 27] =0C Internet-Draft Service Name and Port Number Procedures September 2010 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 13.2. Informative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-06 (work in progress), March 2010. [I-D.cheshire-nat-pmp] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-03 (work in progress), April 2008. [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", November 2001. [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name and Transport Protocol Port Number Registry", http://www.iana.org/assignments/port-numbers. [PROTSERVREG] Internet Assigned Numbers Authority (IANA), "Protocol and Service Names Registry", http://www.iana.org/assignments/service-names. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", RFC 1078, November 1988. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2957] Daigle, L. and P. Faltstrom, "The application/ whoispp-query Content-Type", RFC 2957, October 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. Cotton, et al. Expires March 21, 2011 [Page 28] =0C Internet-Draft Service Name and Port Number Procedures September 2010 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, February 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [SRVREG] "DNS SRV Service Types Registry", http://www.dns-sd.org/ServiceTypes.html. [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application for System (Well Known) Port Number", http://www.iana.org/cgi-bin/sys-port-number.pl. [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. [USRFORM] Internet Assigned Numbers Authority (IANA), "Application for User (Registered) Port Number", http://www.iana.org/cgi-bin/usr-port-number.pl. Cotton, et al. Expires March 21, 2011 [Page 29] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Authors' Addresses Michelle Cotton Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1 310 823 9358 Email: michelle.cotton@icann.org URI: http://www.iana.org/ Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +358 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/ Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292 USA Phone: +1 310 448 9151 Email: touch@isi.edu URI: http://www.isi.edu/touch Magnus Westerlund Ericsson Torshamsgatan 23 Stockholm 164 80 Sweden Phone: +46 8 719 0000 Email: magnus.westerlund@ericsson.com Cotton, et al. Expires March 21, 2011 [Page 30] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com Cotton, et al. Expires March 21, 2011 [Page 31] =0C --Apple-Mail-6--687802607-- --Apple-Mail-7--687802562 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkxNzA3 NDU1OVowIwYJKoZIhvcNAQkEMRYEFOaiVqyaj6IbvLcZpOluD9AZVwKAMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAD2AGpY2ZDaJfViccOFk5FEf7NSdXPsBz9nGN4ZdbN9Z03req/aI t+FSJ/X9XI8Nr/jt5/dcMkijcTTfOfjtvE6NUNdZjz2eVWtKNsfbOqs7/G+AgHF0nuERTCwgmvdQ J2BtS+4jPzheK+ZpgS5DeJO4Ms8NyFzoIq7I0f+FUxmbUNvstlKOBv9/7S2dOGsj/UDYR2edEnL/ mcJFvo5wBVWAp/GaJfLRqRTSXR8JyfOY9cYkRQ5Wybk8KBylwmK5rZZ9PiGGIU/AJtyCsMSXUST8 8J91fBoR8kB27J+DySFhMgfsSdSoTOqPtmaL3QAOrzm3KAO0tAHVBfgwTiljXRUAAAAAAAA= --Apple-Mail-7--687802562-- From magnus.westerlund@ericsson.com Fri Sep 17 00:50:33 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A932D3A6AAF for ; Fri, 17 Sep 2010 00:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 d9rmni5eCmfv for ; Fri, 17 Sep 2010 00:50:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5067F3A6A4E for ; Fri, 17 Sep 2010 00:50:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbeae00000772f-41-4c931de0abf3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 62.A7.30511.0ED139C4; Fri, 17 Sep 2010 09:50:56 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Sep 2010 09:50:31 +0200 Received: from [147.214.183.53] ([147.214.183.53]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Sep 2010 09:50:31 +0200 Message-ID: <4C931DC6.1000006@ericsson.com> Date: Fri, 17 Sep 2010 09:50:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Joe Touch References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> <4C924978.4010602@isi.edu> In-Reply-To: <4C924978.4010602@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Sep 2010 07:50:31.0064 (UTC) FILETIME=[0071C180:01CB563D] X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 07:50:33 -0000 Joe Touch skrev 2010-09-16 18:44: > > > On 9/16/2010 2:11 AM, Magnus Westerlund wrote: >> Joe Touch skrev 2010-09-08 18:01: >>> >>> >>> On 9/7/2010 4:14 PM, Stuart Cheshire wrote: >>>> On 3 Sep, 2010, at 12:01, Michelle Cotton wrote: >>>> >>>>> I agree with all the changes below. >>>>> Regarding the last point, can the service name aliases for future >>>>> registrations go in the notes column? >>>>> >>>>> Michelle >>>> >>>> >>>> I don't think there will be any future aliases. >>>> >>>> I don't see any reason to be allowing further creation of aliases that >>>> add nothing except being a new name for something else that already exists. >>> >>> The burden falls on the owner of the port. If they want to ask for >>> aliases, e.g., to shift from an old product name to a new one, I can't >>> see why we would care. There is impact, but only on that port anyway. >>> However, I'd restrict it to the owner of the port only. >>> >>> A good example of this would be the STUN/TURN stuff we discussed recently. >>> >> >> I think we should strongly recommend against alias for the first case >> like http and www. However STUN and TURN are not aliases, they are >> compatible services that can co-exist on the same port. Thus I wouldn't >> call them aliases at all. > > Any time more than one string maps to the same port number it's a kind > of an 'alias'. The only way for the client to know the difference is via > in-band information. > > I.e., we would allow aliases for: > - different services > - that can be resolved in-band > > Unless BOTH of those apply, we would not allow aliases except: > > a) legacy (www, http) > b) to support changeover to the new namespace > I think we are in agreement. Are the text clear enough on this in your view. I think we can have it improved further to make the above clear. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From touch@isi.edu Fri Sep 17 14:12:27 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE923A691A for ; Fri, 17 Sep 2010 14:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.074 X-Spam-Level: X-Spam-Status: No, score=-102.074 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_40=-0.185, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] 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 T0jTpJuBu704 for ; Fri, 17 Sep 2010 14:12:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 01A213A693E for ; Fri, 17 Sep 2010 14:12:18 -0700 (PDT) Received: from [75.217.198.68] (68.sub-75-217-198.myvzw.com [75.217.198.68]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8HLBubr020688 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 17 Sep 2010 14:12:07 -0700 (PDT) Message-ID: <4C93D99C.5030503@isi.edu> Date: Fri, 17 Sep 2010 14:11:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Lars Eggert References: <4C924866.2090707@isi.edu> <0D80A77F-A8CA-4F40-A27C-D011FD9096ED@nokia.com> In-Reply-To: <0D80A77F-A8CA-4F40-A27C-D011FD9096ED@nokia.com> Content-Type: multipart/mixed; boundary="------------040803070802020702060508" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 21:12:27 -0000 This is a multi-part message in MIME format. --------------040803070802020702060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some changes: - to avoid confusion between Registered (user) and system port numbers, I suggest using the term "assignment" for the process IANA performs (this is consistent, FWIW, with the IANA acronym) - I corrected the use of admin contact/tech contact use throughout - I replaced alias with overloading and corrected the text We do have some cases where multiple names map to the same number, so there is aliasing, but we do not have a case where one string ever maps to another string (which is what I would consider an alias). I replaced this with 'overloading', which is the more accurate CS term for what is happening. - corrected the ABNF, and simply indicated that it was provided as a non-normative convenience I'd be glad to put this into the XML if needed (I haven't been able to check it out, though - if someone can mail it to me, I'll do the changes over the weekend). Joe --------------040803070802020702060508 Content-Type: text/plain; name="joe-draft-ietf-tsvwg-iana-ports.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="joe-draft-ietf-tsvwg-iana-ports.txt" Transport Area Working Group M. Cotton Internet-Draft ICANN Updates: 2780, 2782, 3828, 4340, L. Eggert 4960 (if approved) Nokia Intended status: BCP J. Touch Expires: March 21, 2011 USC/ISI M. Westerlund Ericsson S. Cheshire Apple September 17, 2010 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry draft-ietf-tsvwg-iana-ports-07 Abstract This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number Registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782] to clarify what a service name is and how it is assigned. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2011. Cotton, et al. Expires March 21, 2011 [Page 1] Internet-Draft Service Name and Port Number Procedures September 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Cotton, et al. Expires March 21, 2011 [Page 2] Internet-Draft Service Name and Port Number Procedures September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conventions Used in this Document . . . . . . . . . . . . . . 7 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Service names and Port Numbers for Experimentation . . . . 11 7. Principles for Service Name and Transport Protocol Port Number Registry Management . . . . . . . . . . . . . . . . . . 12 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13 7.3. Variances for Specific Port Number Ranges . . . . . . . . 15 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry . . . . . . . . . . . 16 8.1. Service Name and Port Number Assignment . . . . . . . . . 16 8.2. Service Name and Port Number De-Assignment . . . . . . . . 19 8.3. Service Name and Port Number Re-Use . . . . . . . . . . . 20 8.4. Service Name and Port Number Revocation . . . . . . . . . 20 8.5. Service Name and Port Number Transfers . . . . . . . . . . 21 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 22 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Cotton, et al. Expires March 21, 2011 [Page 3] Internet-Draft Service Name and Port Number Procedures September 2010 1. Introduction For many years, the allocation of new service names and port number values for use with the Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have had less than clear guidelines. New transport protocols have been added - the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have been developed, each with separate registries and separate guidelines. The community also recognized the need for additional procedures beyond just assignment; notably modification, revocation, and release. A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. This document brings the IANA procedures for TCP and UDP in line with those for SCTP and DCCP, resulting in a single process that requesters and IANA follow for all requests for all transport protocols, including future protocols not yet defined. In addition to detailing the IANA procedures for the initial assignment of service names and port numbers, this document also specifies post-assignment procedures that until now have been handled in an ad hoc manner. These include procedures to de-assign a port number that is no longer in use, to re-use a port number allocated for one application that is no longer in use for another application, and the procedure by which IANA can unilaterally revoke a prior port number assignment. Section 8 discusses the specifics of these procedures and processes that requesters and IANA follow for all requests for all current and future transport protocols. IANA is the authority for assigning service names and port numbers. The registries that are created to store these assignments are maintained by IANA. For protocols developed by IETF working groups, IANA now also offers a method for the "early assignment" [RFC4020] of service names and port numbers, as described in Section 8.1. This document updates IANA's procedures for UDP and TCP port numbers by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780]. (Note that other sections of the IANA allocation guidelines, relating to the protocol field values in IPv4 header, were also updated in February 2008 [RFC5237].) This document also updates the IANA allocation procedures for DCCP [RFC4340] and SCTP [RFC4960]. The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares the port space with UDP. The UDP-Lite specification says: "UDP-Lite uses the same set of port number values assigned by the IANA for use Cotton, et al. Expires March 21, 2011 [Page 4] Internet-Draft Service Name and Port Number Procedures September 2010 by UDP". Thus the update of UDP procedures result in an update also of the UDP-Lite procedures. This document also clarifies what a service name is and how it is assigned. This will impact the DNS SRV specification [RFC2782], because that specification merely makes a brief mention that the symbolic names of services are defined in "Assigned Numbers" [RFC1700], without stating to which section it refers within that 230-page document. The DNS SRV specification may have been referring to the list of Port Assignments (known as /etc/services on Unix), or to the "Protocol And Service Names" section, or to both, or to some other section. Furthermore, "Assigned Numbers" is now obsolete [RFC3232] and has been replaced by on-line registries [PORTREG][PROTSERVREG]. The development of new transport protocols is a major effort that the IETF does not undertake very often. If a new transport protocol is standardized in the future, for consistency it is expected to follow as much as possible the guidelines and practices around using service names and port numbers. 2. Motivation Information about the assignment procedures for the port registry has existed in three locations: the forms for requesting port number assignments on the IANA web site [SYSFORM] [USRFORM], an introductory text section in the file listing the port number assignments themselves [PORTREG], and two brief sections of the IANA Allocation Guidelines [RFC2780]. Similarly, the procedures surrounding service names have been historically unclear. Service names were originally created as mnemonic identifiers for port numbers without a well-defined syntax, beyond the 14-character limit mentioned on the IANA website [SYSFORM] [USRFORM]. Even that length limit has not been consistently applied, and some assigned service names are 15 characters long. When service identification via DNS SRV Resource Records (RRs) was introduced, the requirement by IANA to only assign service names and port numbers in combination, led to the creation of an ad hoc service name registry outside of the control of IANA [SRVREG]. This document aggregates all this scattered information into a single reference that aligns and clearly defines the management procedures for both service names and port numbers. It gives more detailed guidance to prospective requesters of service names and ports than the existing documentation, and it streamlines the IANA procedures for the management of the registry, so that management requests can Cotton, et al. Expires March 21, 2011 [Page 5] Internet-Draft Service Name and Port Number Procedures September 2010 complete in a timely manner. This document defines rules for assignment of service names without associated port numbers, for such usages as DNS SRV records [RFC2782], which was not possible under the previous IANA procedures. The document also merges service name assignments from the non-IANA ad hoc registry [SRVREG] and from the IANA "Protocol and Service Names" registry [PROTSERVREG] into the IANA "Service Name and Transport Protocol Port Number" registry [PORTREG], which from here on is the single authoritative registry for service names and port numbers. An additional purpose of this document is to describe the principles that guide the IETF and IANA in their role as the long-term joint stewards of the service name and port number registry. TCP and UDP have had remarkable success over the last decades. Thousands of applications and application-level protocols have service names and ports assigned for their use, and there is every reason to believe that this trend will continue into the future. It is hence extremely important that management of the registry follow principles that ensure its long-term usefulness as a shared resource. Section 7 discusses these principles in detail. 3. Background The Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success over the decades as the two most widely used transport protocols on the Internet. They have relied on the concept of "ports" as logical entities for Internet communication. Ports serve two purposes: first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes bind. Newer transport protocols, such as the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] have also adopted the concept of ports for their communication sessions and use sixteen-bit port numbers in the same way as TCP and UDP (and UDP-Lite [RFC3828], a variant of UDP). Port numbers are the original and most widely used means for application and service identification on the Internet. Ports are sixteen-bit numbers, and the combination of source and destination port numbers together with the IP addresses of the communicating end systems uniquely identifies a session of a given transport protocol. Port numbers are also known by their associated service names such as "telnet" for port number 23 and "http" (as well as "www" and "www-http") Cotton, et al. Expires March 21, 2011 [Page 6] Internet-Draft Service Name and Port Number Procedures September 2010 for port number 80. Hosts running services, hosts accessing services on other hosts, and intermediate devices (such as firewalls and NATs) that restrict services need to agree on which service corresponds to a particular destination port. Although this is ultimately a local decision with meaning only between the endpoints of a connection, it is common for many services to have a default port upon which those servers usually listen, when possible, and these ports are recorded by the Internet Assigned Numbers Authority (IANA) through the service name and port number registry [PORTREG]. Over time, the assumption that a particular port number necessarily implies a particular service may become less true. For example, multiple instances of the same service on the same host cannot generally listen on the same port, and multiple hosts behind the same NAT gateway cannot all have a mapping for the same port on the external side of the NAT gateway, whether using static port mappings configured by hand by the user, or dynamic port mappings configured automatically using a port mapping protocol like NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device (IGD) [IGD]. Applications may use numeric port numbers directly, look up port numbers based on service names via system calls such as getservbyname() on UNIX, look up port numbers by performing queries for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd], or determine port numbers in a variety of other ways like the TCP Port Service Multiplexer (TCPMUX) [RFC1078]. Designers of applications and application-level protocols may apply to IANA for an assigned service name and port number for a specific application, and may - after successful assignment - assume that no other application will use that service name or port number for its communication sessions. Alternatively, application designers may also ask for only an assigned service name, if their application does not require a fixed port number. The latter alternative is encouraged when possible, in order to conserve the more limited port number space. This is applicable, for example, to applications that use DNS SRV records to look up port numbers at runtime. 4. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Cotton, et al. Expires March 21, 2011 [Page 7] Internet-Draft Service Name and Port Number Procedures September 2010 5. Service Names Service names are the unique key in the Service Name and Transport Protocol Port Number Registry. This unique symbolic name for a service may also be used for other purposes, such as in DNS SRV records [RFC2782]. Within the registry, this unique key ensures that different services can be unambiguously distinguished, thus preventing name collisions and avoiding confusion about who is the assignee for a particular entry. There may be more than one service name associated with a particular transport protocol and port. There are three ways that such service name overloading occur: o Overloading occurs when one service is an extension of another service, and an in-band mechanism exists for determining if the extension is present or not. One example is port 3478, which has the service name aliases "stun" and "turn". TURN [RFC5766] is an extension to the STUN [RFC5389] service. TURN-enabled clients wishing to locate TURN servers could attempt to discover "stun" services and then check in-band if the server supports TURN, but this would be inefficient. Enabling them to directly query for "turn" servers by name is a better approach. (Note that TURN servers in this case should also be locatable via a "stun" discovery, because every TURN server is also a STUN server.) o By historical accident the service name "http" corresponds to the same port number as "www" and "www-http". When used in SRV records [RFC2782], and similar service discovery mechanisms only the service name "http" should be used, not these additional names. If a server were to advertise "www" then it would not be discovered by clients browsing for "http". Advertising or browsing for the aliases as well as the primary service name would be inefficient, and achieves nothing that it not already achieved by using the service name "http" exclusively. o As indicated in this document, in Section 10.1, to enable legacy names to be replaced with names consistent with the syntax this document proscribes. In this case, only the new name should be used in SRV records, both to avoid the same issues as with historical cases of multiple names, as well as because the legacy names are incompatible with SRV record use. For future assignments, applications will not be permitted that merely request a new name exactly duplicating an existing service. Having multiple names for the same service serves no purpose. Implementers are requested to inform IANA if they discover other cases where a single service has multiple names, so that one name may be recorded as the primary name for service discovery purposes. Service names are assigned on a "first come, first served" basis, as described in Section 8.1. Names should be brief and informative, avoiding words or abbreviations that are redundant in the context of the registry (e.g., "port", "service", "protocol", etc.) Names referring to discovery services, e.g., using multicast or broadcast Cotton, et al. Expires March 21, 2011 [Page 8] Internet-Draft Service Name and Port Number Procedures September 2010 to identify endpoints capable of a given service, SHOULD use an easily identifiable suffix (e.g., "-disc"). 5.1. Service Name Syntax Valid service names are hereby normatively defined as follows: o MUST be at least 1 character and no more than 15 characters long o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45) o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') o MUST NOT begin or end with a hyphen The reason for requiring at least one letter is to avoid service names like "23" (could be confused with a numeric port number) or "6000-6063" (could be confused with a numeric port number range). Although service names may contain both upper-case and lower-case letters, case is ignored for comparison purposes, so both "http" and "HTTP" denote the same service. Service names are purely opaque identifiers, and no semantics are implied by any superficial structure that a given service name may appear to have. For example, a company called "Example" may choose to request assignment of service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" products, but the "Example" company can't claim to "own" all service names beginning with "Example-", they can't prevent someone else requesting assignment of "Example-Baz" for a different service, and they can't prevent other developers from using the "Example-Foo" and "Example-Bar" service types in order to interoperate with the "Foo" and "Bar" products. Technically speaking, in service discovery protocols, service names are merely a series of byte values on the wire; for the mnemonic convenience of human developers it can be convenient to interpret those byte values as human-readable ascii characters, but software should treat them as purely opaque identifiers and not attempt to parse them for any additional embedded meaning. In approximately 98% of cases, the new "service name" is exactly the same as the old historic "short name" from the IANA web forms [SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service name" is derived from the old historic "short name" as described below in Section 10.1. The rules for valid service names, excepting the limit of 15 characters maximum, are also expressed below (as a non-normative convenience) using ABNF Cotton, et al. Expires March 21, 2011 [Page 9] Internet-Draft Service Name and Port Number Procedures September 2010 [RFC5234]: SRVNAME = (ALPHA / (1*DIGIT [HYPHEN] ALPHA)) *([HYPHEN] ALNUM) ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN = %x2d ; "-" ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] DIGIT = %x30-39 ; 0-9 [RFC5234] 5.2. Service Name Usage in DNS SRV Records The DNS SRV specification [RFC2782] states that the Service Label part of the owner name of a DNS SRV record includes a "Service" element, described as "the symbolic name of the desired service", but as discussed above, it is not clear precisely what this means. This document clarifies that the Service Label MUST be a service name as defined herein. The service name SHOULD be assigned through IANA and recorded in the Service Name and Transport Protocol Port Number Registry [PORTREG]. The details of using Service Names in SRV Service Labels are specified in the DNS SRV specification [RFC2782]. This document does not change that specification. 6. Port Number Ranges TCP, UDP, UDP-Lite, SCTP and DCCP use sixteen-bit namespaces for their port number registries. The port registries for all these transport protocols are subdivided into three ranges of numbers, and Section 7.3 describes the IANA procedures for each range in detail: o the System Ports, also known as the Well Known Ports, from 0-1023 (assigned by IANA) o the User Ports, also known as the Registered Ports, from 1024- 49151 (assigned by IANA) o the Dynamic Ports, also known as the Private Ports, from 49152- 65535 (never assigned) Of the assignable port ranges (System Ports and User Ports, i.e., port numbers 0-49151), individual port numbers are in one of three Cotton, et al. Expires March 21, 2011 [Page 10] Internet-Draft Service Name and Port Number Procedures September 2010 states at any given time: o Assigned: Assigned port numbers are currently allocated to the service indicated in the registry. o Unassigned: Unassigned port numbers are currently available for assignment upon request, as per the procedures outlined in this document. o Reserved: Reserved port numbers are not available for regular assignment; they are "assigned to IANA" for special purposes. Reserved port numbers include values at the edges of each range, e.g., 0, 1023, 1024, etc., which may be used to extend these ranges or the overall port number space in the future. In order to keep the size of the registry manageable, IANA typically only records the Assigned and Reserved service names and port numbers in the registry. Unassigned values are typically not explicitly listed. (There are an near-infinite number of Unassigned service names and enumerating them all would not be practical.) As a data point, when this document was written, approximately 76% of the TCP and UDP System Ports were assigned, and approximately 9% of the User Ports were assigned. (As noted, Dynamic Ports are never assigned.) 6.1. Service names and Port Numbers for Experimentation Of the System Ports, two TCP and UDP port numbers (1021 and 1022), together with their respective service names ("exp1" and "exp2"), have been assigned for experimentation with new applications and application-layer protocols that require a port number in the assigned ports ranges [RFC4727]. Please refer to Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] for how these experimental port numbers are to be used. This document assigns the same two service names and port numbers for experimentation with new application-layer protocols over SCTP and DCCP in Section 10.2. Unfortunately, it can be difficult to limit access to these ports. Users SHOULD take measures to ensure that experimental ports are connecting to the intended process. For example, users of these experimental ports might include a 64-bit nonce, once on each segment of a message-oriented channel (e.g., UDP), or once at the beginning of a byte-stream (e.g., TCP), which is used to confirm that the port Cotton, et al. Expires March 21, 2011 [Page 11] Internet-Draft Service Name and Port Number Procedures September 2010 is being used as intended. Such confirmation of intended use is especially important when these ports are associated with privileged (e.g., system or administrator) processes. 7. Principles for Service Name and Transport Protocol Port Number Registry Management Management procedures for the service name and transport protocol port number registry include allocation of service names and port numbers upon request, as well as management of information about existing allocations. The latter includes maintaining contact and description information about assignments, revoking abandoned assignments, and redefining assignments when needed. Of these procedures, careful port number allocation is most critical, in order to continue to conserve the remaining port numbers. As noted earlier, only about 9% of the User Port space is currently assigned. The current rate of assignment is approximately 400 ports per year, and has remained steady for the past 8 years. At that rate, if similar conservation continues, this resource will sustain another 85 years of assignment - without the need to resort to reassignment of released values or revocation. The namespace available for service names is much larger, which allows for simpler management procedures. 7.1. Past Principles Before the publication of this document, the principles of service name and port number management followed a few mostly-undocumented guidelines. They are recorded here for historical purposes, and this document updates them in Section 7.2. These principles were: o TCP and UDP ports were simultaneously allocated when either was requested o Port numbers were the primary allocation; service names were informative only, and did not have a well-defined syntax o Port numbers were conserved informally, and sometimes inconsistently (e.g., some services were allocated ranges of many port numbers even where not strictly necessary) o SCTP and DCCP service name and port number registries were managed separately from the TCP/UDP registries o Service names could not be assigned in the old ports registry without assigning an associated port number at the same time Cotton, et al. Expires March 21, 2011 [Page 12] Internet-Draft Service Name and Port Number Procedures September 2010 This document clarifies and aligns these guidelines in order to more conservatively manage the limited remaining port number space and to enable and promote the use of service names for service identification without associated port numbers, where possible. 7.2. Updated Principles This section summarizes the basic principles by which IANA handles the Service Name and Transport Protocol Port Number Registry, and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA decisions are not required to be bound by these principles; other factors may come into play, and exceptions may occur where deemed in the best interest of the Internet. IANA will begin assigning service names that do not request an associated port number allocation under a simple "First Come, First Served" policy [RFC5226]. IANA MAY, at its discretion, refer service name requests to "Expert Review" in cases of mass assignments or other situations where IANA believes expert review is advisable. The basic principle of service name and port number registry management is to conserve use of the port space where possible. Extensions to support larger port number spaces would require changing many core protocols of the current Internet in a way that would not be backward compatible and interfere with both current and legacy applications. To help ensure this conservation the policy for any assignment request for port number allocations uses the "Expert Review" policy [RFC5226]. Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. In particular: o IANA will allocate only one assigned port number per service or application o IANA will allocate only one assigned port number for all versions of a service (e.g., running the service with or without a security mechanism, or for updated variants of a service) o IANA will allocate only one assigned port number for all different types of device using or participating in the same service Cotton, et al. Expires March 21, 2011 [Page 13] Internet-Draft Service Name and Port Number Procedures September 2010 o IANA will allocate port numbers only for the transport protocol(s) explicitly named in a assignment request o IANA may recover unused port numbers, via the new procedures of de-assignment, revocation, and transfer Where possible, a given service is expected to demultiplex messages if necessary. For example, applications and protocols are expected to include in-band version information, so that future versions of the application or protocol can share the same allocated port. Applications and protocols are also expected to be able to efficiently use a single allocated port for multiple sessions, either by demultiplexing multiple streams within one port, or using the allocated port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]). Ports are used in various ways, notably: o as endpoint process identifiers o as application protocol identifiers o for firewall filtering purposes Both the process identifier and the protocol identifier uses suggest that anything a single process can demultiplex, or that can be encoded into a single protocol, should be. The firewall filtering use suggests that some uses that could be multiplexed or encoded could instead be separated to allow for easier firewall management. Note that this latter use is much less sound, because port numbers have meaning only for the two endpoints involved in a connection, and drawing conclusions about the service that generated a given flow based on observed port numbers is not always reliable. Further, previous separation of protocol variants based on security capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is not recommended for new protocols, because all new protocols should be security-capable and capable of negotiating the use of security in-band. IANA will begin assigning port numbers for only those transport protocols explicitly included in an assignment request. This ends the long-standing practice of automatically assigning a port number to an application for both TCP and a UDP, even if the request is for only one of these transport protocols. The new allocation procedure conserves resources by allocating a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually uses. The port number will be marked as Reserved - instead of Assigned - in the port number registries of the other transport Cotton, et al. Expires March 21, 2011 [Page 14] Internet-Draft Service Name and Port Number Procedures September 2010 protocols. When applications start supporting the use of some of those additional transport protocols, the assignee for the assignment MUST request IANA to convert the reservation into a proper assignment. An application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport protocol without asking IANA to convert the reservation into an assignment. When the available pool of unassigned numbers has run out in a ports range, it will be necessary for IANA to consider the Reserved ports for assignment. This is part of the motivation for not automatically assigning ports for transport protocols other than the requested one(s). This will allow more ports to be available for assignment when that time comes. To help conserve ports, application developers should request assignment of only the transport protocols that their application currently uses. Conservation of port numbers is improved by procedures that allow previously allocated port numbers to become Unassigned, either through de-assignment or through revocation, and by a procedure that lets application designers transfer an allocated but unused port number to a new application. Section 8 describes these procedures, which until now were undocumented. Port number conservation is also improved by recommending that applications that do not require an allocated port should request assignment of only a service name without an associated port number. 7.3. Variances for Specific Port Number Ranges Section 6 describes the different port number ranges. It is important to note that IANA applies slightly different procedures when managing the different port ranges of the service name and port number registry: o Ports in the Dynamic Ports range (49152-65535) have been specifically set aside for local and dynamic use and cannot be assigned through IANA. Application software may simply use them for communication without any sort of assignment. On the other hand, application software MUST NOT assume that a specific port number in the Dynamic Ports range will always be available for communication at all times, and a port number in that range hence MUST NOT be used as a service identifier. o Ports in the User Ports range (1024-49151) are available for assignment through IANA, and MAY be used as service identifiers upon successful assignment. Because assignment a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the Cotton, et al. Expires March 21, 2011 [Page 15] Internet-Draft Service Name and Port Number Procedures September 2010 requester to document the intended use of the port number. This documentation will be input to the "Expert Review" allocation procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the assignment. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226], which is how most assignments for IETF protocols are handled. o Ports in the System Ports range (0-1023) are also available for assignment through IANA. Because the System Ports range is both the smallest and the most densely allocated, the requirements for new allocations are more strict than those for the User Ports range, and will only be granted under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226]. A request for a System Port number MUST document *both* why using a port number from the User Ports is unsuitable *and* why using a port number from the Dynamic Ports ranges is unsuitable for that application. 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry This section describes the process for handling requests associated with IANA's management of the Service Name and Transport Protocol Port Number Registry. Such requests include initial assignment, de-assignment, re-use, changes to the service name, and updates to the contact information or description associated with an assignment. Revocation is as additional process, initiated by IANA. 8.1. Service Name and Port Number Assignment Assignment refers to the allocation of service names or port numbers to applicants. All such assignments are made from service names or port numbers that are Unassigned or Reserved at the time of the allocation. Unassigned names and numbers are allocated according to the rules described in Section 7.3. Reserved numbers and names are assigned only after review by IANA and the IETF, and are accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. When an assignment for one or more transport protocols is approved, the port number for any non-requested transport protocol(s) will be marked as Reserved. IANA SHOULD NOT assign that port number to any other application or service until no other port numbers remain Unassigned in the requested range. The current assignee Cotton, et al. Expires March 21, 2011 [Page 16] Internet-Draft Service Name and Port Number Procedures September 2010 of a port number MAY request assignment of these Reserved port numbers for other transport protocols when needed. A service name or port number assignement request contains the following information. The service name is the unique identifier of a given service: Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) Assignee (REQUIRED) Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL) o Service Name: A desired unique service name for the service associated with the assignment request MUST be provided, for use in various service selection and discovery mechanisms (including, but not limited to, DNS SRV records [RFC2782]). The name MUST be compliant with the syntax defined in Section 5.1. In order to be unique, they MUST NOT be identical to any currently assigned service name in the IANA registry [PORTREG]. Service names are case-insensitive; they may be provided and entered into the registry with mixed case for clarity, but for the comparison purposes the case is ignored. o Transport Protocol(s): The transport protocol(s) for which the allocation is requested MUST be provided. This field is currently limited to one or more of TCP, UDP, SCTP, and DCCP. This field is required even for services with no port number. Cotton, et al. Expires March 21, 2011 [Page 17] Internet-Draft Service Name and Port Number Procedures September 2010 o Assignee: Name and email address of the Assignee. This is REQUIRED. The Assignee is the Organization or Company responsible for the initial assignment. For assignments done through IETF-published RFCs, the Assignee will be the IESG. o Contact: Name and email address of the Contact person for the assignment. This is REQUIRED. The Contact person is the responsible person for the Internet community to send questions to. This person would also be authorized to submit changes on behalf of the Assignee; in cases of conflict between the Assignee and the Contact, the Assignee decision takes precedence. Additional address information MAY be provided. For assignments done through IETF-published RFCs, the Contact will be the IESG. o Description: A short description of the service associated with the assignment request is REQUIRED. It should avoid all but the most well-known acronyms. o Reference: A description of (or a reference to a document describing) the protocol or application using this port. The description must state whether the protocol uses broadcast, multicast, or anycast communication. For assignments requesting only a Service Name, or a Service Name and User Port, a statement that the protocol is proprietary and not publicly documented is also acceptable provided that the required information regarding use of broadcast, multicast, or anycast is given. For assignment requests for a User Port, the assignment request MUST explain why a port number in the Dynamic Ports range is unsuitable for the given application. For assignment requests for a System Port, the assignment request MUST explain why a port number in the User Ports or Dynamic Ports ranges is unsuitable, and a reference to a stable protocol specification document MUST be provided. For requests from IETF Working Groups, IANA MAY accept "early assignment" [RFC4020] requests referencing a sufficiently stable Internet Draft instead of a published Standards-Track RFC. o Port Number: If assignment of a port number is desired, either the currently Unassigned or Reserved port number the requester suggests for allocation, or the text "ANY", MUST be provided. If only a service name is to be assigned, this field MUST be empty. If a specific port number is requested, IANA is encouraged to allocate the requested number. If the text "ANY" is specified, IANA will choose a suitable number from the User Ports range. Note that the applicant MUST NOT use the requested port prior to Cotton, et al. Expires March 21, 2011 [Page 18] Internet-Draft Service Name and Port Number Procedures September 2010 the completion of the assignment. o Service Code: If the assignment request includes DCCP as a transport protocol then the request MUST include a desired unique DCCP service code [RFC5595], and MUST NOT include a requested DCCP service code otherwise. Section 19.8 of the DCCP specification [RFC4340] defines requirements and rules for allocation, updated by this document. o Known Unauthorized Uses: A list of uses by applications or organizations who are not the assignee. This list may be augmented by IANA after assignment when unauthorized uses are reported. o Assignment Notes: Indications of owner/name change, or any other assignment process issue. This list may be updated by IANA after assignment to help track changes to an assignment, e.g., de- assignment, owner/name changes, etc. If the assignment request is for the addition of a new transport protocol to an already assigned service name, IANA needs to confirm with the assignee for the existing assignment whether this addition is appropriate. When IANA receives a assignment request - containing the above information - that is requesting a port number, IANA SHALL initiate an "Expert Review" [RFC5226] in order to determine whether an assignment should be made. For requests that do not include a port number, IANA SHOULD assign the service name under a simple "First Come First Served" policy [RFC5226]. 8.2. Service Name and Port Number De-Assignment The assignee of a granted port number assignment can return the port number to IANA at any time if they no longer have a need for it. The port number will be de-assigned and will be marked as Reserved. IANA should not re-assign port numbers that have been de-assigned until all unassigned port numbers in the specific range have been assigned. Before proceeding with a port number de-assignment, IANA needs to reasonably establish that the value is actually no longer in use. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that a given service name remain assigned even after all associated port number assignments have become de-assigned. Under this policy, it will appear in the registry as if it had been created through a Cotton, et al. Expires March 21, 2011 [Page 19] Internet-Draft Service Name and Port Number Procedures September 2010 service name assignment request that did not include any port numbers. On rare occasions, it may still be useful to de-assign a service name. In such cases, IANA will mark the service name as Reserved. IANA will involve their IESG-appointed expert in such cases. 8.3. Service Name and Port Number Re-Use If the assignee of a granted port number assignment no longer have a need for the assigned number, but would like to re-use it for a different application, they can submit a request to IANA to do so. Logically, port number re-use is to be thought of as a de- assignment (Section 8.2) followed by an immediate re-assignment (Section 8.1) of the same port number for a new application. Consequently, the information that needs to be provided about the proposed new use of the port number is identical to what would need to be provided for a new port number allocation for the specific ports range. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that the original service name associated with the prior use of the port number remains assigned, and a new service be created and associated with the port number. This is again consistent with viewing a re-use request as a de-assignment followed by an immediate re- assignment. Re-using an assigned service name for a different application is NOT RECOMMENDED. IANA needs to carefully review such requests before approving them. In some instances, the Expert Reviewer will determine that the application that the port number was assigned to has found usage beyond the original requester, or that there is a concern that it may have such users. This determination MUST be made quickly. A community call concerning revocation of a port number (see below) MAY be considered, if a broader use of the port number is suspected. 8.4. Service Name and Port Number Revocation A port number revocation can be thought of as an IANA-initiated de- assignement (Section 8.2), and has exactly the same effect on the registry. Sometimes, it will be clear that a specific port number is no longer in use and that IANA can revoke it and mark it as Reserved. At other times, it may be unclear whether a given assigned port number is Cotton, et al. Expires March 21, 2011 [Page 20] Internet-Draft Service Name and Port Number Procedures September 2010 still in use somewhere in the Internet. In those cases, IANA must carefully consider the consequences of revoking the port number, and SHOULD only do so if there is an overwhelming need. With the help of their IESG-appointed Expert Reviewer, IANA SHALL formulate a request to the IESG to issue a four-week community call concerning the pending port number revocation. The IESG and IANA, with the Expert Reviewer's support, SHALL determine promptly after the end of the community call whether revocation should proceed and then communicate their decision to the community. This procedure typically involves similar steps to de-assignment except that it is initiated by IANA. Because there is much less danger of exhausting the service name space compared to the port number space, revoking service names is NOT RECOMMENDED. 8.5. Service Name and Port Number Transfers The value of service names and port numbers is defined by their careful management as a shared Internet resource, whereas enabling transfer allows the potential for associated monetary exchanges. As a result, the IETF does not permit service name or port number assignments to be transferred between parties, even when they are mutually consenting. The appropriate alternate procedure is a coordinated de-assignment and assignment: The new party requests the service name or port number via an assignment and the previous party releases its assignment via the de-assignment procedure outlined above. With the help of their IESG-appointed Expert Reviewer, IANA SHALL carefully determine if there is a valid technical, operational or managerial reason to grant the requested new assignment. 8.6. Maintenance Issues In addition to the formal procedures described above, updates to the Description and Contact information are coordinated by IANA in an informal manner, and may be initiated by either the assignee or by IANA, e.g., by the latter requesting an update to current contact information. (Note that Assignee cannot be changed; see Section 8.5 above.) 9. Security Considerations The IANA guidelines described in this document do not change the Cotton, et al. Expires March 21, 2011 [Page 21] Internet-Draft Service Name and Port Number Procedures September 2010 security properties of UDP, TCP, SCTP, or DCCP. Assignment of a service name or port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from an assigned port number does not mean that it is "good" traffic, or even that it is used by the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, not based on whether or not there is an assigned service name or port number. Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. 10. IANA Considerations This document obsoletes Sections 8 and 9.1 of the March 2000 IANA Allocation Guidelines [RFC2780]. Upon approval of this document, IANA is requested to contact Stuart Cheshire, maintainer of the independent service name registry [SRVREG], in order to merge the contents of that private registry into the official IANA registry. It is expected that the independent registry web page will be updated with pointers to the IANA registry and to this RFC. IANA is instructed to create a new service name entry in the service name and port number registry [PORTREG] for any entry in the "Protocol and Service Names" registry [PROTSERVREG] that does not already have one assigned. IANA is also instructed to indicate in the Assignment Notes for "www" and "www-http" that they are duplicate terms that refer to the "http" service, and should not be used for service discovery purposes. For this conceptual service (human- readable web pages served over HTTP) the correct service name to use for service discovery purposes is "http" (see Section 5). 10.1. Service Name Consistency Section 8.1 defines which character strings are well-formed service names, which until now had not been clearly defined. The definition in Section 8.1 was chosen to allow maximum compatibility of service names with current and future service discovery mechanisms. Cotton, et al. Expires March 21, 2011 [Page 22] Internet-Draft Service Name and Port Number Procedures September 2010 As of August 5, 2009 approximately 98% of the so-called "Short Names" from existing port number assignments [PORTREG] meet the rules for legal service names stated in Section 8.1, and hence for these services their service name will be exactly the same as their "Short Name". The remaining approximately 2% of the exiting "Short Names" are not suitable to be used directly as well-formed service names because they contain illegal characters such as asterisks, dots, pluses, slashes, or underscores. All existing "Short Names" conform to the length requirement of 15 characters or fewer. For these unsuitable "Short Names", listed in the table below, the service name will be the Short Name with any illegal characters replaced by hyphens. IANA SHALL add an entry to the registry giving the new well-formed primary service name for the existing service, that otherwise duplicates the original assignment information. In the description field of this new entry giving the primary service name, IANA SHALL record that it assigns a well-formed service name for the previous service and reference the original assignment. In the Assignment Notes field of the original assignment, IANA SHALL add a note that this entry is an alias to the new well-formed service name, and that the old service name is historic, not usable for use with many common service discovery mechanisms. Cotton, et al. Expires March 21, 2011 [Page 23] Internet-Draft Service Name and Port Number Procedures September 2010 Names containing illegal characters to be replaced by hyphens: +----------------+-----------------+-----------------+ | 914c/g | acmaint_dbd | acmaint_transd | | atex_elmd | avanti_cdp | badm_priv | | badm_pub | bdir_priv | bdir_pub | | bmc_ctd_ldap | bmc_patroldb | boks_clntd | | boks_servc | boks_servm | broker_service | | bues_service | canit_store | cedros_fds | | cl/1 | contamac_icm | corel_vncadmin | | csc_proxy | cvc_hostd | dbcontrol_agent | | dec_dlm | dl_agent | documentum_s | | dsmeter_iatc | dsx_monitor | elpro_tunnel | | elvin_client | elvin_server | encrypted_admin | | erunbook_agent | erunbook_server | esri_sde | | EtherNet/IP-1 | EtherNet/IP-2 | event_listener | | flr_agent | gds_db | ibm_wrless_lan | | iceedcp_rx | iceedcp_tx | iclcnet_svinfo | | idig_mux | ife_icorp | instl_bootc | | instl_boots | intel_rci | interhdl_elmd | | lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C | | LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet | | mdbs_daemon | menandmice_noh | msl_lmd | | nburn_id | ncr_ccl | nds_sso | | netmap_lm | nms_topo_serv | notify_srvr | | novell-lu6.2 | nuts_bootp | nuts_dem | | ocs_amu | ocs_cmu | pipe_server | | pra_elmd | printer_agent | redstorm_diag | | redstorm_find | redstorm_info | redstorm_join | | resource_mgr | rmonitor_secure | rsvp_tunnel | | sai_sentlm | sge_execd | sge_qmaster | | shiva_confsrvr | sql*net | srvc_registry | | stm_pproc | subntbcst_tftp | udt_os | | universe_suite | veritas_pbx | vision_elmd | | vision_server | wrs_registry | z39.50 | +----------------+-----------------+-----------------+ Following the example set by the "application/whoispp-query" MIME Content-Type [RFC2957], the service name for "whois++" will be "whoispp". 10.2. Port Numbers for SCTP and DCCP Experimentation Two System UDP and TCP ports, 1021 and 1022, have been reserved for experimental use [RFC4727]. This document assigns the same port numbers for SCTP and DCCP, updates the TCP and UDP assignments, and also instructs IANA to automatically assign these two port numbers for any future transport protocol with a similar sixteen-bit port Cotton, et al. Expires March 21, 2011 [Page 24] Internet-Draft Service Name and Port Number Procedures September 2010 number namespace. Note that these port numbers are meant for temporary experimentation and development in controlled environments. Before using these port numbers, carefully consider the advice in Section 6.1 in this document, as well as in Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692]. Most importantly, application developers must request a permanent port number assignment from IANA as described in Section 8.1 before any kind of non-experimental deployment. +-------------------------------------+----------------------------+ | Assignee | IETF | | Contact | IESG | | Service Name | exp1 | | Port Number | 1021 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 1 | | Reference | [RFCyyyy],RFC 4727] | +-------------------------------------+----------------------------+ +-------------------------------------+----------------------------+ | Assignee | IETF | | Contact | IESG | | Service Name | exp2 | | Port Number | 1022 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 2 | | Reference | [RFCyyyy], [RFC4727] | +-------------------------------------+----------------------------+ [RFC Editor Note: Please change "yyyy" to the RFC number allocated to this document before publication.] 10.3. Updates to DCCP Registries This document updates the IANA allocation procedures for the DCCP Port Number and DCCP Service Codes Registries [RFC4340]. 10.3.1. DCCP Service Code Registry Service Codes are allocated first-come-first-served according to Section 19.8 of the DCCP specification [RFC4340]. This document updates that section by extending the guidelines given there in the following ways: Cotton, et al. Expires March 21, 2011 [Page 25] Internet-Draft Service Name and Port Number Procedures September 2010 o IANA MAY assign new Service Codes without seeking Expert Review using their discretion, but SHOULD seek expert review if a request seeks more than five Service Codes. o IANA should feel free to contact the DCCP Expert Reviewer with questions on any registry, regardless of the registry policy, for clarification or if there is a problem with a request [RFC4340]. 10.3.2. DCCP Port Numbers Registry The DCCP ports registry is defined by Section 19.9 of the DCCP specification [RFC4340]. Allocations in this registry require prior allocation of a Service Code. Not all Service Codes require IANA- assigned ports. This document updates that section by extending the guidelines given there in the following way: o IANA should normally assign a value in the range 1024-49151 to a DCCP server port. IANA allocation requests to allocate port numbers in the System Ports range (0 through 1023), require an "IETF Review" [RFC5226] prior to allocation by IANA [RFC4340]. o IANA MUST NOT allocate more than one DCCP server port to a single service code value. o The allocation of multiple service codes to the same DCCP port is allowed, but subject to expert review. o The set of Service Code values associated with a DCCP server port should be recorded in the service name and port number registry. o A request for additional Service Codes to be associated with an already allocated Port Number requires Expert Review. These requests will normally be accepted when they originate from the contact associated with the port assignment. In other cases, these applications will be expected to use an unallocated port, when this is available. The DCCP specification [RFC4340] notes that a short port name MUST be associated with each DCCP server port that has been assigned. This document clarifies that this short port name is the Service Name as defined here, and this name MUST be unique. 11. Contributors Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have contributed text and ideas to this document. Cotton, et al. Expires March 21, 2011 [Page 26] Internet-Draft Service Name and Port Number Procedures September 2010 12. Acknowledgments The text in Section 10.3 is based on a suggestion originally proposed as a part of the DCCP Service Codes document[RFC5595] by Gorry Fairhurst. Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program. 13. References 13.1. Normative References [ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an Cotton, et al. Expires March 21, 2011 [Page 27] Internet-Draft Service Name and Port Number Procedures September 2010 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 13.2. Informative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-06 (work in progress), March 2010. [I-D.cheshire-nat-pmp] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-03 (work in progress), April 2008. [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", November 2001. [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name and Transport Protocol Port Number Registry", http://www.iana.org/assignments/port-numbers. [PROTSERVREG] Internet Assigned Numbers Authority (IANA), "Protocol and Service Names Registry", http://www.iana.org/assignments/service-names. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", RFC 1078, November 1988. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2957] Daigle, L. and P. Faltstrom, "The application/ whoispp-query Content-Type", RFC 2957, October 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. Cotton, et al. Expires March 21, 2011 [Page 28] Internet-Draft Service Name and Port Number Procedures September 2010 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, February 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [SRVREG] "DNS SRV Service Types Registry", http://www.dns-sd.org/ServiceTypes.html. [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application for System (Well Known) Port Number", http://www.iana.org/cgi-bin/sys-port-number.pl. [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. [USRFORM] Internet Assigned Numbers Authority (IANA), "Application for User (Registered) Port Number", http://www.iana.org/cgi-bin/usr-port-number.pl. Cotton, et al. Expires March 21, 2011 [Page 29] Internet-Draft Service Name and Port Number Procedures September 2010 Authors' Addresses Michelle Cotton Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1 310 823 9358 Email: michelle.cotton@icann.org URI: http://www.iana.org/ Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +358 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/ Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292 USA Phone: +1 310 448 9151 Email: touch@isi.edu URI: http://www.isi.edu/touch Magnus Westerlund Ericsson Torshamsgatan 23 Stockholm 164 80 Sweden Phone: +46 8 719 0000 Email: magnus.westerlund@ericsson.com Cotton, et al. Expires March 21, 2011 [Page 30] Internet-Draft Service Name and Port Number Procedures September 2010 Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com Cotton, et al. Expires March 21, 2011 [Page 31] --------------040803070802020702060508-- From michelle.cotton@icann.org Fri Sep 17 14:39:15 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17FD3A68C5 for ; Fri, 17 Sep 2010 14:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 IS99fioc1e6V for ; Fri, 17 Sep 2010 14:39:08 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 7B5DC3A68FB for ; Fri, 17 Sep 2010 14:38:42 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Fri, 17 Sep 2010 14:39:07 -0700 From: Michelle Cotton To: Joe Touch , Lars Eggert Date: Fri, 17 Sep 2010 14:39:06 -0700 Thread-Topic: [port-srv-reg] almost good to go Thread-Index: ActWrSZuv+8uPs4SSCi4bC0RHrdxfQAA5psY Message-ID: In-Reply-To: <4C93D99C.5030503@isi.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8B92E0A28C17michellecottonicannorg_" MIME-Version: 1.0 Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 21:39:16 -0000 --_000_C8B92E0A28C17michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have to review the changes you made to the admin contact/tech contact use= as I'm not sure I will agree with them. I had a conversation with Russ Housley today about that language as we are = going to be using it in other registries. I'll get feedback to you all by Monday. Thanks, Michelle On 9/17/10 2:11 PM, "Joe Touch" wrote: Some changes: - to avoid confusion between Registered (user) and system port numbers, I suggest using the term "assignment" for the process IANA performs (this is consistent, FWIW, with the IANA acronym) - I corrected the use of admin contact/tech contact use throughout - I replaced alias with overloading and corrected the text We do have some cases where multiple names map to the same number, so there is aliasing, but we do not have a case where one string ever maps to another string (which is what I would consider an alias). I replaced this with 'overloading', which is the more accurate CS term for what is happening. - corrected the ABNF, and simply indicated that it was provided as a non-normative convenience I'd be glad to put this into the XML if needed (I haven't been able to check it out, though - if someone can mail it to me, I'll do the changes over the weekend). Joe --_000_C8B92E0A28C17michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [port-srv-reg] almost good to go I have to review the changes you made to the admin contact/tech conta= ct use as I’m not sure I will agree with them.
I had a conversation with Russ Housley today about that language as we are = going to be using it in other registries.

I’ll get feedback to you all by Monday.

Thanks,

Michelle


On 9/17/10 2:11 PM, "Joe Touch" <tou= ch@isi.edu> wrote:

Some changes:

- to avoid confusion between Registered (user) and system port numbers,
I suggest using the term "assignment" for the process IANA perfor= ms
(this is consistent, FWIW, with the IANA acronym)

- I corrected the use of admin contact/tech contact use throughout

- I replaced alias with overloading and corrected the text
We do have some cases where multiple names map to the same number, so
there is aliasing, but we do not have a case where one string ever maps
to another string (which is what I would consider an alias). I replaced
this with 'overloading', which is the more accurate CS term for what is
happening.

- corrected the ABNF, and simply indicated that it was provided as a
non-normative convenience

I'd be glad to put this into the XML if needed (I haven't been able to
check it out, though - if someone can mail it to me, I'll do the changes over the weekend).

Joe


--_000_C8B92E0A28C17michellecottonicannorg_-- From touch@isi.edu Fri Sep 17 14:44:52 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329DD3A6875 for ; Fri, 17 Sep 2010 14:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wyNt9PYUEizY for ; Fri, 17 Sep 2010 14:44:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E4B023A68C5 for ; Fri, 17 Sep 2010 14:44:50 -0700 (PDT) Received: from [75.217.198.68] (68.sub-75-217-198.myvzw.com [75.217.198.68]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8HLiHs5027390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 17 Sep 2010 14:44:28 -0700 (PDT) Message-ID: <4C93E131.4040206@isi.edu> Date: Fri, 17 Sep 2010 14:44:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Michelle Cotton References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 21:44:52 -0000 On 9/17/2010 2:39 PM, Michelle Cotton wrote: > nges you made to the admin contact/tech contact use as I’m not sure I > will agree with them. > I had a conversation with Russ Housley today about that language as we > are going to be using it in other registries. > > I’ll get feedback to you all by Monday. AOK - whatever we use, needs to be consistent throughout (the current text had registrant/contact, but then later had admin/tech contact) I am also concerned about a name for the process - whether it's "registration" or "assignment". I prefer the latter. Joe From touch@isi.edu Fri Sep 17 15:14:48 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D043A697D for ; Fri, 17 Sep 2010 15:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4SqruuO0j2cb for ; Fri, 17 Sep 2010 15:14:45 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C748C3A692A for ; Fri, 17 Sep 2010 15:14:45 -0700 (PDT) Received: from [75.217.198.68] (68.sub-75-217-198.myvzw.com [75.217.198.68]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8HMEchJ003340 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 17 Sep 2010 15:14:50 -0700 (PDT) Message-ID: <4C93E84E.8010404@isi.edu> Date: Fri, 17 Sep 2010 15:14:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Lars Eggert References: <4C924866.2090707@isi.edu> <0D80A77F-A8CA-4F40-A27C-D011FD9096ED@nokia.com> <4C93D99C.5030503@isi.edu> In-Reply-To: <4C93D99C.5030503@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: port-srv-reg@ietf.org Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 22:14:48 -0000 PS - replace "proscribe" with "prescribe". My spell checker was over-eager. Joe On 9/17/2010 2:11 PM, Joe Touch wrote: > Some changes: > > - to avoid confusion between Registered (user) and system port numbers, > I suggest using the term "assignment" for the process IANA performs > (this is consistent, FWIW, with the IANA acronym) > > - I corrected the use of admin contact/tech contact use throughout > > - I replaced alias with overloading and corrected the text > We do have some cases where multiple names map to the same number, so > there is aliasing, but we do not have a case where one string ever maps > to another string (which is what I would consider an alias). I replaced > this with 'overloading', which is the more accurate CS term for what is > happening. > > - corrected the ABNF, and simply indicated that it was provided as a > non-normative convenience > > I'd be glad to put this into the XML if needed (I haven't been able to > check it out, though - if someone can mail it to me, I'll do the changes > over the weekend). > > Joe > From touch@isi.edu Fri Sep 17 16:04:50 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359B83A6962 for ; Fri, 17 Sep 2010 16:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9cnuF7H-sKyO for ; Fri, 17 Sep 2010 16:04:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E65403A68F3 for ; Fri, 17 Sep 2010 16:04:48 -0700 (PDT) Received: from [75.217.198.68] (68.sub-75-217-198.myvzw.com [75.217.198.68]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8HN4meo012121 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 17 Sep 2010 16:04:59 -0700 (PDT) Message-ID: <4C93F410.5090007@isi.edu> Date: Fri, 17 Sep 2010 16:04:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Magnus Westerlund References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> <4C924978.4010602@isi.edu> <4C931DC6.1000006@ericsson.com> In-Reply-To: <4C931DC6.1000006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 23:04:50 -0000 On 9/17/2010 12:50 AM, Magnus Westerlund wrote: > Joe Touch skrev 2010-09-16 18:44: >> >> >> On 9/16/2010 2:11 AM, Magnus Westerlund wrote: >>> Joe Touch skrev 2010-09-08 18:01: >>>> >>>> >>>> On 9/7/2010 4:14 PM, Stuart Cheshire wrote: >>>>> On 3 Sep, 2010, at 12:01, Michelle Cotton wrote: >>>>> >>>>>> I agree with all the changes below. >>>>>> Regarding the last point, can the service name aliases for future >>>>>> registrations go in the notes column? >>>>>> >>>>>> Michelle >>>>> >>>>> >>>>> I don't think there will be any future aliases. >>>>> >>>>> I don't see any reason to be allowing further creation of aliases that >>>>> add nothing except being a new name for something else that already exists. >>>> >>>> The burden falls on the owner of the port. If they want to ask for >>>> aliases, e.g., to shift from an old product name to a new one, I can't >>>> see why we would care. There is impact, but only on that port anyway. >>>> However, I'd restrict it to the owner of the port only. >>>> >>>> A good example of this would be the STUN/TURN stuff we discussed recently. >>>> >>> >>> I think we should strongly recommend against alias for the first case >>> like http and www. However STUN and TURN are not aliases, they are >>> compatible services that can co-exist on the same port. Thus I wouldn't >>> call them aliases at all. >> >> Any time more than one string maps to the same port number it's a kind >> of an 'alias'. The only way for the client to know the difference is via >> in-band information. >> >> I.e., we would allow aliases for: >> - different services >> - that can be resolved in-band >> >> Unless BOTH of those apply, we would not allow aliases except: >> >> a) legacy (www, http) >> b) to support changeover to the new namespace >> > > I think we are in agreement. Are the text clear enough on this in your > view. I think we can have it improved further to make the above clear. I tried to do so in the text I just posted. Joe From lars.eggert@nokia.com Sat Sep 18 01:00:14 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8A13A6879 for ; Sat, 18 Sep 2010 01:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.353 X-Spam-Level: X-Spam-Status: No, score=-103.353 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5Zhh-ekZUv-2 for ; Sat, 18 Sep 2010 01:00:14 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 8FCC73A6849 for ; Sat, 18 Sep 2010 01:00:13 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8I80atO026542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Sep 2010 11:00:36 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-3--600537538; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4C93D99C.5030503@isi.edu> Date: Sat, 18 Sep 2010 11:00:23 +0300 Message-Id: References: <4C924866.2090707@isi.edu> <0D80A77F-A8CA-4F40-A27C-D011FD9096ED@nokia.com> <4C93D99C.5030503@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 08:00:15 -0000 --Apple-Mail-3--600537538 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-9-18, at 0:11, Joe Touch wrote: > I'd be glad to put this into the XML if needed (I haven't been able to=20= > check it out, though - if someone can mail it to me, I'll do the = changes > over the weekend). download from = https://svn.tools.ietf.org/svn/area/tsv/draft-cotton-tsvwg-iana-ports (That is also the URL to use for a "svn checkout") Lars --Apple-Mail-3--600537538 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkxODA4 MDAyNFowIwYJKoZIhvcNAQkEMRYEFBTqpVR52WKRX9omtJzoImuaD6v5MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAIkWUFeiOaP8B+N+cX+PD1hyxfUtfkxsDJlwLu0peDa0Vm5M5xeh QgQO+P4ViIwxW2AbCpFgG4UIRcctI3bWTPzBE7X1eadTnR7MJA7OS8d3IibjU14+6dBWuuyAeRcn UERibicFOGjgRII9qhhfM5lzH/t4Hl8f7lYSuBxsViwVMtRtNTruQLUgtAhkB2nCRt49zmQ8EFs0 arM2m0JzggprHS5xpbQC5CtZ3gKmHGwugZGn2SKhQSJcug5jfj1bfeWFekCh7TggkNxMYhHkrdD3 gnXXHc3tiYzcH6S1TxMlAHb7jo7YyiaHD9wQJhVraMr0ve/rskdiZ23/ZAbB9g4AAAAAAAA= --Apple-Mail-3--600537538-- From touch@isi.edu Mon Sep 20 15:21:43 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270263A6851 for ; Mon, 20 Sep 2010 15:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.941 X-Spam-Level: X-Spam-Status: No, score=-101.941 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_50=0.001, GB_I_LETTER=-2, J_CHICKENPOX_84=0.6, USER_IN_WHITELIST=-100] 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 kCNvi2N-P4xq for ; Mon, 20 Sep 2010 15:21:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C7EDC3A67B6 for ; Mon, 20 Sep 2010 15:21:36 -0700 (PDT) Received: from [75.217.186.37] (37.sub-75-217-186.myvzw.com [75.217.186.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o8KMLLZr025142 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 20 Sep 2010 15:21:38 -0700 (PDT) Message-ID: <4C97DE60.6090601@isi.edu> Date: Mon, 20 Sep 2010 15:21:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Lars Eggert References: <4C924866.2090707@isi.edu> <0D80A77F-A8CA-4F40-A27C-D011FD9096ED@nokia.com> <4C93D99C.5030503@isi.edu> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020408010807070403010505" X-MailScanner-ID: o8KMLLZr025142 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 22:21:43 -0000 This is a multi-part message in MIME format. --------------020408010807070403010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks. Attached is an update that - fixes the ABNF - fixes the alias issue - fixes the admin contact/tech contact misuse currently uses Registrant/Contact, as per the bulk of the doc IMO, it's still useful to consider, throughout, the following change (which I left out of this version): Registrant -> Assignee Contact -> registration -> assignment Joe On 9/18/2010 1:00 AM, Lars Eggert wrote: > On 2010-9-18, at 0:11, Joe Touch wrote: >> I'd be glad to put this into the XML if needed (I haven't been able to >> check it out, though - if someone can mail it to me, I'll do the changes >> over the weekend). > > download from https://svn.tools.ietf.org/svn/area/tsv/draft-cotton-tsvwg-iana-ports > > (That is also the URL to use for a "svn checkout") > > Lars > --------------020408010807070403010505 Content-Type: text/xml; name="jt--draft-ietf-tsvwg-iana-ports.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="jt--draft-ietf-tsvwg-iana-ports.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KPD94bWwtc3R5bGVz aGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0icmZjMjYyOS54c2x0IiA/Pgo8IURPQ1RZUEUg cmZjIFNZU1RFTSAicmZjMjYyOS5kdGQiPgo8P3JmYyBjb21tZW50cz0ieWVzIiA/Pgo8P3Jm YyBjb21wYWN0PSJ5ZXMiPz4KPCEtLTw/cmZjIGVkaXRpbmc9InllcyI/Pi0tPgo8P3JmYyBp bmxpbmU9InllcyI/Pgo8P3JmYyBzdHJpY3Q9InllcyI/Pgo8P3JmYyBzb3J0cmVmcz0ieWVz IiA/Pgo8P3JmYyBzdWJjb21wYWN0PSJubyI/Pgo8P3JmYyBzeW1yZWZzPSJ5ZXMiID8+Cjw/ cmZjIHRvYz0ieWVzIj8+Cjw/cmZjIHRvY2RlcHRoPSIyIj8+Cjw/cmZjIHRvY29tcGFjdD0i eWVzIj8+CjxyZmMgY2F0ZWdvcnk9ImJjcCIgZG9jTmFtZT0iZHJhZnQtaWV0Zi10c3Z3Zy1p YW5hLXBvcnRzLTA3IgogICAgIGlwcj0icHJlNTM3OFRydXN0MjAwOTAyIiB1cGRhdGVzPSIy NzgwLCAyNzgyLCAzODI4LCA0MzQwLCA0OTYwIj4KICA8ZnJvbnQ+CiAgICA8dGl0bGUgYWJi cmV2PSJTZXJ2aWNlIE5hbWUgYW5kIFBvcnQgTnVtYmVyIFByb2NlZHVyZXMiPkludGVybmV0 IEFzc2lnbmVkCiAgICBOdW1iZXJzIEF1dGhvcml0eSAoSUFOQSkgUHJvY2VkdXJlcyBmb3Ig dGhlIE1hbmFnZW1lbnQgb2YgdGhlIFNlcnZpY2UgTmFtZQogICAgYW5kIFRyYW5zcG9ydCBQ cm90b2NvbCBQb3J0IE51bWJlciBSZWdpc3RyeTwvdGl0bGU+CgogICAgPGF1dGhvciBmdWxs bmFtZT0iTWljaGVsbGUgQ290dG9uIiBpbml0aWFscz0iTS4iIHN1cm5hbWU9IkNvdHRvbiI+ CiAgICAgIDxvcmdhbml6YXRpb24gYWJicmV2PSJJQ0FOTiI+SW50ZXJuZXQgQ29ycG9yYXRp b24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZAogICAgICBOdW1iZXJzPC9vcmdhbml6YXRpb24+ CgogICAgICA8YWRkcmVzcz4KICAgICAgICA8cG9zdGFsPgogICAgICAgICAgPHN0cmVldD40 Njc2IEFkbWlyYWx0eSBXYXksIFN1aXRlIDMzMDwvc3RyZWV0PgoKICAgICAgICAgIDxjb2Rl PjkwMjkyPC9jb2RlPgoKICAgICAgICAgIDxjaXR5Pk1hcmluYSBkZWwgUmV5PC9jaXR5PgoK ICAgICAgICAgIDxyZWdpb24+Q0E8L3JlZ2lvbj4KCiAgICAgICAgICA8Y291bnRyeT5VU0E8 L2NvdW50cnk+CiAgICAgICAgPC9wb3N0YWw+CgogICAgICAgIDxwaG9uZT4rMSAzMTAgODIz IDkzNTg8L3Bob25lPgoKICAgICAgICA8ZW1haWw+bWljaGVsbGUuY290dG9uQGljYW5uLm9y ZzwvZW1haWw+CgogICAgICAgIDx1cmk+aHR0cDovL3d3dy5pYW5hLm9yZy88L3VyaT4KICAg ICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CgogICAgPGF1dGhvciBmdWxsbmFtZT0iTGFy cyBFZ2dlcnQiIGluaXRpYWxzPSJMLiIgc3VybmFtZT0iRWdnZXJ0Ij4KICAgICAgPG9yZ2Fu aXphdGlvbiBhYmJyZXY9Ik5va2lhIj5Ob2tpYSBSZXNlYXJjaCBDZW50ZXI8L29yZ2FuaXph dGlvbj4KCiAgICAgIDxhZGRyZXNzPgogICAgICAgIDxwb3N0YWw+CiAgICAgICAgICA8c3Ry ZWV0PlAuTy4gQm94IDQwNzwvc3RyZWV0PgoKICAgICAgICAgIDxjb2RlPjAwMDQ1PC9jb2Rl PgoKICAgICAgICAgIDxjaXR5Pk5va2lhIEdyb3VwPC9jaXR5PgoKICAgICAgICAgIDxjb3Vu dHJ5PkZpbmxhbmQ8L2NvdW50cnk+CiAgICAgICAgPC9wb3N0YWw+CgogICAgICAgIDxwaG9u ZT4rMzU4IDUwIDQ4IDI0NDYxPC9waG9uZT4KCiAgICAgICAgPGVtYWlsPmxhcnMuZWdnZXJ0 QG5va2lhLmNvbTwvZW1haWw+CgogICAgICAgIDx1cmk+aHR0cDovL3Jlc2VhcmNoLm5va2lh LmNvbS9wZW9wbGUvbGFyc19lZ2dlcnQvPC91cmk+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwv YXV0aG9yPgoKICAgIDwhLS0KICAgIDxhdXRob3IgZnVsbG5hbWU9IkFsbGlzb24gTWFua2lu IiBpbml0aWFscz0iQS4iIHN1cm5hbWU9Ik1hbmtpbiI+CiAgICAgIDxvcmdhbml6YXRpb24g YWJicmV2PSJKb2hucyBIb3BraW5zIFVuaXYuIj5Kb2hucyBIb3BraW5zCiAgICAgIFVuaXZl cnNpdHk8L29yZ2FuaXphdGlvbj4KICAgICAgPGFkZHJlc3M+CiAgICAgICA8cG9zdGFsPgog ICAgICAgICA8c3RyZWV0PjQxMDIgV2lsc29uIEJvdWxldmFyZDwvc3RyZWV0PgogICAgICAg ICA8Y2l0eT5Bcmxpbmd0b248L2NpdHk+CiAgICAgICAgIDxyZWdpb24+VkE8L3JlZ2lvbj4K ICAgICAgICAgPGNvZGU+MjIyMzA8L2NvZGU+CiAgICAgICAgIDxjb3VudHJ5PlVTQTwvY291 bnRyeT4KICAgICAgIDwvcG9zdGFsPgogICAgICAgIDxwaG9uZT4rMSAzMDEgNzI4IDcxOTk8 L3Bob25lPgogICAgICAgIDxlbWFpbD5tYW5raW5AcHNnLmNvbTwvZW1haWw+CiAgICAgICAg PHVyaT5odHRwOi8vd3d3LnBzZy5jb20vfm1hbmtpbi88L3VyaT4KICAgICAgPC9hZGRyZXNz PgogICAgPC9hdXRob3I+Ci0tPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9IkpvZSBUb3VjaCIg aW5pdGlhbHM9IkouIiBzdXJuYW1lPSJUb3VjaCI+CiAgICAgIDxvcmdhbml6YXRpb24+VVND L0lTSTwvb3JnYW5pemF0aW9uPgoKICAgICAgPGFkZHJlc3M+CiAgICAgICAgPHBvc3RhbD4K ICAgICAgICAgIDxzdHJlZXQ+NDY3NiBBZG1pcmFsdHkgV2F5PC9zdHJlZXQ+CgogICAgICAg ICAgPGNvZGU+OTAyOTI8L2NvZGU+CgogICAgICAgICAgPGNpdHk+TWFyaW5hIGRlbCBSZXk8 L2NpdHk+CgogICAgICAgICAgPHJlZ2lvbj5DQTwvcmVnaW9uPgoKICAgICAgICAgIDxjb3Vu dHJ5PlVTQTwvY291bnRyeT4KICAgICAgICA8L3Bvc3RhbD4KCiAgICAgICAgPHBob25lPisx IDMxMCA0NDggOTE1MTwvcGhvbmU+CgogICAgICAgIDxlbWFpbD50b3VjaEBpc2kuZWR1PC9l bWFpbD4KCiAgICAgICAgPHVyaT5odHRwOi8vd3d3LmlzaS5lZHUvdG91Y2g8L3VyaT4KICAg ICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CgogICAgPGF1dGhvciBmdWxsbmFtZT0iTWFn bnVzIFdlc3Rlcmx1bmQiIGluaXRpYWxzPSJNLiIgc3VybmFtZT0iV2VzdGVybHVuZCI+CiAg ICAgIDxvcmdhbml6YXRpb24+RXJpY3Nzb248L29yZ2FuaXphdGlvbj4KCiAgICAgIDxhZGRy ZXNzPgogICAgICAgIDxwb3N0YWw+CiAgICAgICAgICA8c3RyZWV0PlRvcnNoYW1zZ2F0YW4g MjM8L3N0cmVldD4KCiAgICAgICAgICA8Y2l0eT5TdG9ja2hvbG08L2NpdHk+CgogICAgICAg ICAgPGNvZGU+MTY0IDgwPC9jb2RlPgoKICAgICAgICAgIDxjb3VudHJ5PlN3ZWRlbjwvY291 bnRyeT4KICAgICAgICA8L3Bvc3RhbD4KCiAgICAgICAgPHBob25lPis0NiA4IDcxOSAwMDAw PC9waG9uZT4KCiAgICAgICAgPGVtYWlsPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bTwvZW1haWw+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3Ig ZnVsbG5hbWU9IlN0dWFydCBDaGVzaGlyZSIgaW5pdGlhbHM9IlMuIiBzdXJuYW1lPSJDaGVz aGlyZSI+CiAgICAgIDxvcmdhbml6YXRpb24gYWJicmV2PSJBcHBsZSI+QXBwbGUgSW5jLjwv b3JnYW5pemF0aW9uPgoKICAgICAgPGFkZHJlc3M+CiAgICAgICAgPHBvc3RhbD4KICAgICAg ICAgIDxzdHJlZXQ+MSBJbmZpbml0ZSBMb29wPC9zdHJlZXQ+CgogICAgICAgICAgPGNvZGU+ OTUwMTQ8L2NvZGU+CgogICAgICAgICAgPGNpdHk+Q3VwZXJ0aW5vPC9jaXR5PgoKICAgICAg ICAgIDxyZWdpb24+Q0E8L3JlZ2lvbj4KCiAgICAgICAgICA8Y291bnRyeT5VU0E8L2NvdW50 cnk+CiAgICAgICAgPC9wb3N0YWw+CgogICAgICAgIDxwaG9uZT4rMSA0MDggOTc0IDMyMDc8 L3Bob25lPgoKICAgICAgICA8ZW1haWw+Y2hlc2hpcmVAYXBwbGUuY29tPC9lbWFpbD4KICAg ICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CgogICAgPGRhdGUgeWVhcj0iMjAxMCIgLz4K CiAgICA8YXJlYT5UcmFuc3BvcnQgQXJlYTwvYXJlYT4KCiAgICA8d29ya2dyb3VwPlRyYW5z cG9ydCBBcmVhIFdvcmtpbmcgR3JvdXA8L3dvcmtncm91cD4KCiAgICA8a2V5d29yZD5JQU5B PC9rZXl3b3JkPgoKICAgIDxrZXl3b3JkPnRyYW5zcG9ydDwva2V5d29yZD4KCiAgICA8a2V5 d29yZD5wb3J0czwva2V5d29yZD4KCiAgICA8a2V5d29yZD5wb3J0IG51bWJlcnM8L2tleXdv cmQ+CgogICAgPGtleXdvcmQ+YWxsb2NhdGlvbjwva2V5d29yZD4KCiAgICA8a2V5d29yZD5w cm9jZWR1cmVzPC9rZXl3b3JkPgoKICAgIDxhYnN0cmFjdD4KICAgICAgPHQ+VGhpcyBkb2N1 bWVudCBkZWZpbmVzIHRoZSBwcm9jZWR1cmVzIHRoYXQgdGhlIEludGVybmV0IEFzc2lnbmVk CiAgICAgIE51bWJlcnMgQXV0aG9yaXR5IChJQU5BKSB1c2VzIHdoZW4gaGFuZGxpbmcgcmVn aXN0cmF0aW9uIGFuZCBvdGhlcgogICAgICByZXF1ZXN0cyByZWxhdGVkIHRvIHRoZSBTZXJ2 aWNlIE5hbWUgYW5kIFRyYW5zcG9ydCBQcm90b2NvbCBQb3J0IE51bWJlcgogICAgICBSZWdp c3RyeS4gSXQgYWxzbyBkaXNjdXNzZXMgdGhlIHJhdGlvbmFsZSBhbmQgcHJpbmNpcGxlcyBi ZWhpbmQgdGhlc2UKICAgICAgcHJvY2VkdXJlcyBhbmQgaG93IHRoZXkgZmFjaWxpdGF0ZSB0 aGUgbG9uZy10ZXJtIHN1c3RhaW5hYmlsaXR5IG9mIHRoZQogICAgICByZWdpc3RyeS48L3Q+ CgogICAgICA8dD5UaGlzIGRvY3VtZW50IHVwZGF0ZXMgSUFOQSdzIHByb2NlZHVyZXMgYnkg b2Jzb2xldGluZyBTZWN0aW9ucyA4IGFuZAogICAgICA5LjEgb2YgdGhlIElBTkEgYWxsb2Nh dGlvbiBndWlkZWxpbmVzIFtSRkMyNzgwXSwgYW5kIGl0IHVwZGF0ZXMgdGhlIElBTkEKICAg ICAgYWxsb2NhdGlvbiBwcm9jZWR1cmVzIGZvciBVRFAtTGl0ZSBbUkZDMzgyOF0sIERDQ1Ag W1JGQzQzNDBdIGFuZCBTQ1RQCiAgICAgIFtSRkM0OTYwXS4gSXQgYWxzbyB1cGRhdGVzIHRo ZSBETlMgU1JWIHNwZWNpZmljYXRpb24gW1JGQzI3ODJdIHRvCiAgICAgIGNsYXJpZnkgd2hh dCBhIHNlcnZpY2UgbmFtZSBpcyBhbmQgaG93IGl0IGlzIHJlZ2lzdGVyZWQuPC90PgogICAg PC9hYnN0cmFjdD4KICA8L2Zyb250PgoKICA8bWlkZGxlPgogICAgPHNlY3Rpb24gYW5jaG9y PSJpbnRybyIgdGl0bGU9IkludHJvZHVjdGlvbiI+CiAgICAgIDx0PkZvciBtYW55IHllYXJz LCB0aGUgYWxsb2NhdGlvbiBvZiBuZXcgc2VydmljZSBuYW1lcyBhbmQgcG9ydCBudW1iZXIK ICAgICAgdmFsdWVzIGZvciB1c2Ugd2l0aCB0aGUgVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJv dG9jb2wgKFRDUCkgPHhyZWYKICAgICAgdGFyZ2V0PSJSRkMwNzkzIj48L3hyZWY+IGFuZCB0 aGUgVXNlciBEYXRhZ3JhbSBQcm90b2NvbCAoVURQKSA8eHJlZgogICAgICB0YXJnZXQ9IlJG QzA3NjgiPjwveHJlZj4gaGF2ZSBoYWQgbGVzcyB0aGFuIGNsZWFyIGd1aWRlbGluZXMuIE5l dwogICAgICB0cmFuc3BvcnQgcHJvdG9jb2xzIGhhdmUgYmVlbiBhZGRlZCAtIHRoZSBTdHJl YW0gQ29udHJvbCBUcmFuc21pc3Npb24KICAgICAgUHJvdG9jb2wgKFNDVFApIDx4cmVmIHRh cmdldD0iUkZDNDk2MCI+PC94cmVmPiBhbmQgdGhlIERhdGFncmFtCiAgICAgIENvbmdlc3Rp b24gQ29udHJvbCBQcm90b2NvbCAoRENDUCkgPHhyZWYgdGFyZ2V0PSJSRkM0MzQyIj48L3hy ZWY+IC0gYW5kCiAgICAgIG5ldyBtZWNoYW5pc21zIGxpa2UgRE5TIFNSViByZWNvcmRzIDx4 cmVmIHRhcmdldD0iUkZDMjc4MiI+PC94cmVmPiBoYXZlCiAgICAgIGJlZW4gZGV2ZWxvcGVk LCBlYWNoIHdpdGggc2VwYXJhdGUgcmVnaXN0cmllcyBhbmQgc2VwYXJhdGUgZ3VpZGVsaW5l cy4KICAgICAgVGhlIGNvbW11bml0eSBhbHNvIHJlY29nbml6ZWQgdGhlIG5lZWQgZm9yIGFk ZGl0aW9uYWwgcHJvY2VkdXJlcyBiZXlvbmQKICAgICAganVzdCBhc3NpZ25tZW50OyBub3Rh Ymx5IG1vZGlmaWNhdGlvbiwgcmV2b2NhdGlvbiwgYW5kIHJlbGVhc2UuPC90PgoKICAgICAg PHQ+QSBrZXkgZWxlbWVudCBvZiB0aGUgcHJvY2VkdXJhbCBzdHJlYW1saW5pbmcgc3BlY2lm aWVkIGluIHRoaXMKICAgICAgZG9jdW1lbnQgaXMgdG8gZXN0YWJsaXNoIGlkZW50aWNhbCBh c3NpZ25tZW50IHByb2NlZHVyZXMgZm9yIGFsbCBJRVRGCiAgICAgIHRyYW5zcG9ydCBwcm90 b2NvbHMuIFRoaXMgZG9jdW1lbnQgYnJpbmdzIHRoZSBJQU5BIHByb2NlZHVyZXMgZm9yIFRD UAogICAgICBhbmQgVURQIGluIGxpbmUgd2l0aCB0aG9zZSBmb3IgU0NUUCBhbmQgRENDUCwg cmVzdWx0aW5nIGluIGEgc2luZ2xlCiAgICAgIHByb2Nlc3MgdGhhdCByZXF1ZXN0ZXJzIGFu ZCBJQU5BIGZvbGxvdyBmb3IgYWxsIHJlcXVlc3RzIGZvciBhbGwKICAgICAgdHJhbnNwb3J0 IHByb3RvY29scywgaW5jbHVkaW5nIGZ1dHVyZSBwcm90b2NvbHMgbm90IHlldCBkZWZpbmVk LjwvdD4KCiAgICAgIDx0PkluIGFkZGl0aW9uIHRvIGRldGFpbGluZyB0aGUgSUFOQSBwcm9j ZWR1cmVzIGZvciB0aGUgaW5pdGlhbAogICAgICBhc3NpZ25tZW50IG9mIHNlcnZpY2UgbmFt ZXMgYW5kIHBvcnQgbnVtYmVycywgdGhpcyBkb2N1bWVudCBhbHNvCiAgICAgIHNwZWNpZmll cyBwb3N0LWFzc2lnbm1lbnQgcHJvY2VkdXJlcyB0aGF0IHVudGlsIG5vdyBoYXZlIGJlZW4g aGFuZGxlZCBpbgogICAgICBhbiBhZCBob2MgbWFubmVyLiBUaGVzZSBpbmNsdWRlIHByb2Nl ZHVyZXMgdG8gZGUtcmVnaXN0ZXIgYSBwb3J0IG51bWJlcgogICAgICB0aGF0IGlzIG5vIGxv bmdlciBpbiB1c2UsIHRvIHJlLXVzZSBhIHBvcnQgbnVtYmVyIGFsbG9jYXRlZCBmb3Igb25l CiAgICAgIGFwcGxpY2F0aW9uIHRoYXQgaXMgbm8gbG9uZ2VyIGluIHVzZSBmb3IgYW5vdGhl ciBhcHBsaWNhdGlvbiwgYW5kIHRoZQogICAgICBwcm9jZWR1cmUgYnkgd2hpY2ggSUFOQSBj YW4gdW5pbGF0ZXJhbGx5IHJldm9rZSBhIHByaW9yIHBvcnQgbnVtYmVyCiAgICAgIGFzc2ln bm1lbnQuIDx4cmVmIHRhcmdldD0iaWFuYS1wcm9jZWR1cmVzIj48L3hyZWY+IGRpc2N1c3Nl cyB0aGUKICAgICAgc3BlY2lmaWNzIG9mIHRoZXNlIHByb2NlZHVyZXMgYW5kIHByb2Nlc3Nl cyB0aGF0IHJlcXVlc3RlcnMgYW5kIElBTkEKICAgICAgZm9sbG93IGZvciBhbGwgcmVxdWVz dHMgZm9yIGFsbCBjdXJyZW50IGFuZCBmdXR1cmUgdHJhbnNwb3J0CiAgICAgIHByb3RvY29s cy48L3Q+CgogICAgICA8dD5JQU5BIGlzIHRoZSBhdXRob3JpdHkgZm9yIGFzc2lnbmluZyBz ZXJ2aWNlIG5hbWVzIGFuZCBwb3J0IG51bWJlcnMuCiAgICAgIFRoZSByZWdpc3RyaWVzIHRo YXQgYXJlIGNyZWF0ZWQgdG8gc3RvcmUgdGhlc2UgcmVnaXN0cmF0aW9ucyBhcmUKICAgICAg bWFpbnRhaW5lZCBieSBJQU5BLiBGb3IgcHJvdG9jb2xzIGRldmVsb3BlZCBieSBJRVRGIHdv cmtpbmcgZ3JvdXBzLCBJQU5BCiAgICAgIG5vdyBhbHNvIG9mZmVycyBhIG1ldGhvZCBmb3Ig dGhlICJlYXJseSBhc3NpZ25tZW50IiA8eHJlZgogICAgICB0YXJnZXQ9IlJGQzQwMjAiPjwv eHJlZj4gb2Ygc2VydmljZSBuYW1lcyBhbmQgcG9ydCBudW1iZXJzLCBhcyBkZXNjcmliZWQK ICAgICAgaW4gPHhyZWYgdGFyZ2V0PSJyZWdpc3RyYXRpb24iPjwveHJlZj4uPC90PgoKICAg ICAgPHQ+VGhpcyBkb2N1bWVudCB1cGRhdGVzIElBTkEncyBwcm9jZWR1cmVzIGZvciBVRFAg YW5kIFRDUCBwb3J0IG51bWJlcnMKICAgICAgYnkgb2Jzb2xldGluZyBTZWN0aW9ucyA4IGFu ZCA5LjEgb2YgdGhlIElBTkEgYWxsb2NhdGlvbiBndWlkZWxpbmVzIDx4cmVmCiAgICAgIHRh cmdldD0iUkZDMjc4MCI+PC94cmVmPi4gKE5vdGUgdGhhdCBvdGhlciBzZWN0aW9ucyBvZiB0 aGUgSUFOQQogICAgICBhbGxvY2F0aW9uIGd1aWRlbGluZXMsIHJlbGF0aW5nIHRvIHRoZSBw cm90b2NvbCBmaWVsZCB2YWx1ZXMgaW4gSVB2NAogICAgICBoZWFkZXIsIHdlcmUgYWxzbyB1 cGRhdGVkIGluIEZlYnJ1YXJ5IDIwMDggPHhyZWYKICAgICAgdGFyZ2V0PSJSRkM1MjM3Ij48 L3hyZWY+LikgVGhpcyBkb2N1bWVudCBhbHNvIHVwZGF0ZXMgdGhlIElBTkEKICAgICAgYWxs b2NhdGlvbiBwcm9jZWR1cmVzIGZvciBEQ0NQIDx4cmVmIHRhcmdldD0iUkZDNDM0MCI+PC94 cmVmPiBhbmQgU0NUUAogICAgICA8eHJlZiB0YXJnZXQ9IlJGQzQ5NjAiPjwveHJlZj4uPC90 PgoKICAgICAgPHQ+VGhlIExpZ2h0d2VpZ2h0IFVzZXIgRGF0YWdyYW0gUHJvdG9jb2wgKFVE UC1MaXRlKSA8eHJlZgogICAgICB0YXJnZXQ9IlJGQzUyMzciPjwveHJlZj4gc2hhcmVzIHRo ZSBwb3J0IHNwYWNlIHdpdGggVURQLiBUaGUgVURQLUxpdGUKICAgICAgc3BlY2lmaWNhdGlv biBzYXlzOiAiVURQLUxpdGUgdXNlcyB0aGUgc2FtZSBzZXQgb2YgcG9ydCBudW1iZXIgdmFs dWVzCiAgICAgIGFzc2lnbmVkIGJ5IHRoZSBJQU5BIGZvciB1c2UgYnkgVURQIi4gVGh1cyB0 aGUgdXBkYXRlIG9mIFVEUCBwcm9jZWR1cmVzCiAgICAgIHJlc3VsdCBpbiBhbiB1cGRhdGUg YWxzbyBvZiB0aGUgVURQLUxpdGUgcHJvY2VkdXJlcy48L3Q+CgogICAgICA8dD5UaGlzIGRv Y3VtZW50IGFsc28gY2xhcmlmaWVzIHdoYXQgYSBzZXJ2aWNlIG5hbWUgaXMgYW5kIGhvdyBp dCBpcwogICAgICByZWdpc3RlcmVkLiBUaGlzIHdpbGwgaW1wYWN0IHRoZSBETlMgU1JWIHNw ZWNpZmljYXRpb24gPHhyZWYKICAgICAgdGFyZ2V0PSJSRkMyNzgyIj48L3hyZWY+LCBiZWNh dXNlIHRoYXQgc3BlY2lmaWNhdGlvbiBtZXJlbHkgbWFrZXMgYQogICAgICBicmllZiBtZW50 aW9uIHRoYXQgdGhlIHN5bWJvbGljIG5hbWVzIG9mIHNlcnZpY2VzIGFyZSBkZWZpbmVkIGlu CiAgICAgICJBc3NpZ25lZCBOdW1iZXJzIiA8eHJlZiB0YXJnZXQ9IlJGQzE3MDAiPjwveHJl Zj4sIHdpdGhvdXQgc3RhdGluZyB0bwogICAgICB3aGljaCBzZWN0aW9uIGl0IHJlZmVycyB3 aXRoaW4gdGhhdCAyMzAtcGFnZSBkb2N1bWVudC4gVGhlIEROUyBTUlYKICAgICAgc3BlY2lm aWNhdGlvbiBtYXkgaGF2ZSBiZWVuIHJlZmVycmluZyB0byB0aGUgbGlzdCBvZiBQb3J0IEFz c2lnbm1lbnRzCiAgICAgIChrbm93biBhcyAvZXRjL3NlcnZpY2VzIG9uIFVuaXgpLCBvciB0 byB0aGUgIlByb3RvY29sIEFuZCBTZXJ2aWNlIE5hbWVzIgogICAgICBzZWN0aW9uLCBvciB0 byBib3RoLCBvciB0byBzb21lIG90aGVyIHNlY3Rpb24uIEZ1cnRoZXJtb3JlLCAiQXNzaWdu ZWQKICAgICAgTnVtYmVycyIgaXMgbm93IG9ic29sZXRlIDx4cmVmIHRhcmdldD0iUkZDMzIz MiI+PC94cmVmPiBhbmQgaGFzIGJlZW4KICAgICAgcmVwbGFjZWQgYnkgb24tbGluZSByZWdp c3RyaWVzIDx4cmVmIHRhcmdldD0iUE9SVFJFRyI+PC94cmVmPjx4cmVmCiAgICAgIHRhcmdl dD0iUFJPVFNFUlZSRUciPjwveHJlZj4uPCEtLVRoZXJlIGFyZSAKICAgICAgYWRkaXRpb25h bCB1cGRhdGVzIGFuZCBjbGFyaWZpY2F0aW9ucyBvbiBob3cgRE5TIFNSViB1dGlsaXplIHRo ZSAKICAgICAgU2VydmljZSBuYW1lIHJlZ2lzdHJ5IGNyZWF0ZWQgaW4gdGhpcyBkb2N1bWVu dCBpbiAKICAgICAgIkNsYXJpZmljYXRpb24gb2YgRE5TIFNSViBPd25lciBOYW1lcyIgCiAg ICAgIDx4cmVmIHRhcmdldD0iSS1ELmd1ZG11bmRzc29uLWRuc2V4dC1zcnYtY2xhcmlmeSIv Pi4tLT48L3Q+CgogICAgICA8dD5UaGUgZGV2ZWxvcG1lbnQgb2YgbmV3IHRyYW5zcG9ydCBw cm90b2NvbHMgaXMgYSBtYWpvciBlZmZvcnQgdGhhdCB0aGUKICAgICAgSUVURiBkb2VzIG5v dCB1bmRlcnRha2UgdmVyeSBvZnRlbi4gSWYgYSBuZXcgdHJhbnNwb3J0IHByb3RvY29sIGlz CiAgICAgIHN0YW5kYXJkaXplZCBpbiB0aGUgZnV0dXJlLCBmb3IgY29uc2lzdGVuY3kgaXQg aXMgZXhwZWN0ZWQgdG8gZm9sbG93IGFzCiAgICAgIG11Y2ggYXMgcG9zc2libGUgdGhlIGd1 aWRlbGluZXMgYW5kIHByYWN0aWNlcyBhcm91bmQgdXNpbmcgc2VydmljZSBuYW1lcwogICAg ICBhbmQgcG9ydCBudW1iZXJzLjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBh bmNob3I9Im1vdGl2YXRpb24iIHRpdGxlPSJNb3RpdmF0aW9uIj4KICAgICAgPHQ+SW5mb3Jt YXRpb24gYWJvdXQgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmVzIGZvciB0aGUgcG9ydCBy ZWdpc3RyeQogICAgICBoYXMgZXhpc3RlZCBpbiB0aHJlZSBsb2NhdGlvbnM6IHRoZSBmb3Jt cyBmb3IgcmVxdWVzdGluZyBwb3J0IG51bWJlcgogICAgICByZWdpc3RyYXRpb25zIG9uIHRo ZSBJQU5BIHdlYiBzaXRlIDx4cmVmIHRhcmdldD0iU1lTRk9STSI+PC94cmVmPiA8eHJlZgog ICAgICB0YXJnZXQ9IlVTUkZPUk0iPjwveHJlZj4sIGFuIGludHJvZHVjdG9yeSB0ZXh0IHNl Y3Rpb24gaW4gdGhlIGZpbGUKICAgICAgbGlzdGluZyB0aGUgcG9ydCBudW1iZXIgcmVnaXN0 cmF0aW9ucyB0aGVtc2VsdmVzIDx4cmVmCiAgICAgIHRhcmdldD0iUE9SVFJFRyI+PC94cmVm PiwgYW5kIHR3byBicmllZiBzZWN0aW9ucyBvZiB0aGUgSUFOQSBBbGxvY2F0aW9uCiAgICAg IEd1aWRlbGluZXMgPHhyZWYgdGFyZ2V0PSJSRkMyNzgwIj48L3hyZWY+LjwvdD4KCiAgICAg IDx0PlNpbWlsYXJseSwgdGhlIHByb2NlZHVyZXMgc3Vycm91bmRpbmcgc2VydmljZSBuYW1l cyBoYXZlIGJlZW4KICAgICAgaGlzdG9yaWNhbGx5IHVuY2xlYXIuIFNlcnZpY2UgbmFtZXMg d2VyZSBvcmlnaW5hbGx5IGNyZWF0ZWQgYXMgbW5lbW9uaWMKICAgICAgaWRlbnRpZmllcnMg Zm9yIHBvcnQgbnVtYmVycyB3aXRob3V0IGEgd2VsbC1kZWZpbmVkIHN5bnRheCwgYmV5b25k IHRoZQogICAgICAxNC1jaGFyYWN0ZXIgbGltaXQgbWVudGlvbmVkIG9uIHRoZSBJQU5BIHdl YnNpdGUgPHhyZWYKICAgICAgdGFyZ2V0PSJTWVNGT1JNIj48L3hyZWY+IDx4cmVmIHRhcmdl dD0iVVNSRk9STSI+PC94cmVmPi4gRXZlbiB0aGF0CiAgICAgIGxlbmd0aCBsaW1pdCBoYXMg bm90IGJlZW4gY29uc2lzdGVudGx5IGFwcGxpZWQsIGFuZCBzb21lIGFzc2lnbmVkCiAgICAg IHNlcnZpY2UgbmFtZXMgYXJlIDE1IGNoYXJhY3RlcnMgbG9uZy4gV2hlbiBzZXJ2aWNlIGlk ZW50aWZpY2F0aW9uIHZpYQogICAgICBETlMgU1JWIFJlc291cmNlIFJlY29yZHMgKFJScykg d2FzIGludHJvZHVjZWQsIHRoZSByZXF1aXJlbWVudCBieSBJQU5BCiAgICAgIHRvIG9ubHkg YXNzaWduIHNlcnZpY2UgbmFtZXMgYW5kIHBvcnQgbnVtYmVycyBpbiBjb21iaW5hdGlvbiwg bGVkIHRvIHRoZQogICAgICBjcmVhdGlvbiBvZiBhbiBhZCBob2Mgc2VydmljZSBuYW1lIHJl Z2lzdHJ5IG91dHNpZGUgb2YgdGhlIGNvbnRyb2wgb2YKICAgICAgSUFOQSA8eHJlZiB0YXJn ZXQ9IlNSVlJFRyI+PC94cmVmPi48L3Q+CgogICAgICA8IS0tCiAgICAgIFRoaXMgdGV4dCBk dXBsaWNhdGVzIHdoYXQncyBzYWlkIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQuCiAgICAg IEkgYWxzbyBkb24ndCB0aGluayB0aGF0IFJGQyAwOTUyIChET0QgSU5URVJORVQgSE9TVCBU QUJMRSBTUEVDSUZJQ0FUSU9OKQogICAgICBzaGVkcyBhbnkgbGlnaHQgb24gdGhpcyBpc3N1 ZS4gLSBTQwogICAgICA8dD5JdCBoYXMgYWxzbyBiZWVuIGhpc3RvcmljYWxseSB1bmNsZWFy IGlmIHRoZSAibmFtZSIgZW50cmllcyByZWdpc3RlcmVkCiAgICAgIGluIHRoZSAiUHJvdG9j b2wgYW5kIFNlcnZpY2UgTmFtZXMgUmVnaXN0cnkiIDx4cmVmIHRhcmdldD0iUFJPVFNFUlZS RUciLz4KICAgICAgY2FuIGJlIHVzZWQgYXMgc2VydmljZSBuYW1lcy4gPHhyZWYgdGFyZ2V0 PSJSRkMwOTUyIi8+IGRlZmluZXMgdGhlIG5hbWVzCiAgICAgIGluIHRoYXQgcmVnaXN0cnkg YXMgZWl0aGVyIHNlcnZpY2UgbmFtZXMgb3IgcHJvdG9jb2wgbmFtZXMuIEl0IGlzIHBvc3Np YmxlIHRoYXQKICAgICAgc29tZSBvZiB0aGVzZSBuYW1lcyBtYXkgaGF2ZSBiZWVuIGludGVy cHJldGVkIGFzIGJlaW5nIHZhbGlkIHNlcnZpY2UgbmFtZXMgYW5kCiAgICAgIGNvbnNlcXVl bnRseSBoYXZlIGJlZW4gdXNlZCwgZS5nLiwgaW4gU1JWIHJlY29yZHMuIFRoaXMgbW90aXZh dGVzIHdoeQogICAgICB0aGlzIGRvY3VtZW50IG1lcmdlcyB0aGUgMTY2IHByb3RvY29sIGFu ZCBzZXJ2aWNlIG5hbWVzIGRlZmluZWQgaW4gdGhhdAogICAgICByZWdpc3RyeSBpbnRvIHRo ZSBzZXJ2aWNlIG5hbWUgYW5kIHRyYW5zcG9ydCBwcm90b2NvbCBwb3J0IG51bWJlciByZWdp c3RyeQogICAgICA8eHJlZiB0YXJnZXQ9IlBPUlRSRUciLz4uPC90PgogICAgICAtLT4KCiAg ICAgIDx0PlRoaXMgZG9jdW1lbnQgYWdncmVnYXRlcyBhbGwgdGhpcyBzY2F0dGVyZWQgaW5m b3JtYXRpb24gaW50byBhIHNpbmdsZQogICAgICByZWZlcmVuY2UgdGhhdCBhbGlnbnMgYW5k IGNsZWFybHkgZGVmaW5lcyB0aGUgbWFuYWdlbWVudCBwcm9jZWR1cmVzIGZvcgogICAgICBi b3RoIHNlcnZpY2UgbmFtZXMgYW5kIHBvcnQgbnVtYmVycy4gSXQgZ2l2ZXMgbW9yZSBkZXRh aWxlZCBndWlkYW5jZSB0bwogICAgICBwcm9zcGVjdGl2ZSByZXF1ZXN0ZXJzIG9mIHNlcnZp Y2UgbmFtZXMgYW5kIHBvcnRzIHRoYW4gdGhlIGV4aXN0aW5nCiAgICAgIGRvY3VtZW50YXRp b24sIGFuZCBpdCBzdHJlYW1saW5lcyB0aGUgSUFOQSBwcm9jZWR1cmVzIGZvciB0aGUgbWFu YWdlbWVudAogICAgICBvZiB0aGUgcmVnaXN0cnksIHNvIHRoYXQgbWFuYWdlbWVudCByZXF1 ZXN0cyBjYW4gY29tcGxldGUgaW4gYSB0aW1lbHkKICAgICAgbWFubmVyLjwvdD4KCiAgICAg IDx0PlRoaXMgZG9jdW1lbnQgZGVmaW5lcyBydWxlcyBmb3IgcmVnaXN0cmF0aW9uIG9mIHNl cnZpY2UgbmFtZXMgd2l0aG91dAogICAgICBhc3NvY2lhdGVkIHBvcnQgbnVtYmVycywgZm9y IHN1Y2ggdXNhZ2VzIGFzIEROUyBTUlYgcmVjb3JkcyA8eHJlZgogICAgICB0YXJnZXQ9IlJG QzI3ODIiPjwveHJlZj4sIHdoaWNoIHdhcyBub3QgcG9zc2libGUgdW5kZXIgdGhlIHByZXZp b3VzIElBTkEKICAgICAgcHJvY2VkdXJlcy4gVGhlIGRvY3VtZW50IGFsc28gbWVyZ2VzIHNl cnZpY2UgbmFtZSByZWdpc3RyYXRpb25zIGZyb20gdGhlCiAgICAgIG5vbi1JQU5BIGFkIGhv YyByZWdpc3RyeSA8eHJlZiB0YXJnZXQ9IlNSVlJFRyI+PC94cmVmPiBhbmQgZnJvbSB0aGUg SUFOQQogICAgICAiUHJvdG9jb2wgYW5kIFNlcnZpY2UgTmFtZXMiIHJlZ2lzdHJ5IDx4cmVm IHRhcmdldD0iUFJPVFNFUlZSRUciPjwveHJlZj4KICAgICAgaW50byB0aGUgSUFOQSAiU2Vy dmljZSBOYW1lIGFuZCBUcmFuc3BvcnQgUHJvdG9jb2wgUG9ydCBOdW1iZXIiIHJlZ2lzdHJ5 CiAgICAgIDx4cmVmIHRhcmdldD0iUE9SVFJFRyI+PC94cmVmPiwgd2hpY2ggZnJvbSBoZXJl IG9uIGlzIHRoZSBzaW5nbGUKICAgICAgYXV0aG9yaXRhdGl2ZSByZWdpc3RyeSBmb3Igc2Vy dmljZSBuYW1lcyBhbmQgcG9ydCBudW1iZXJzLjwvdD4KCiAgICAgIDx0PkFuIGFkZGl0aW9u YWwgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGRlc2NyaWJlIHRoZSBwcmluY2lw bGVzCiAgICAgIHRoYXQgZ3VpZGUgdGhlIElFVEYgYW5kIElBTkEgaW4gdGhlaXIgcm9sZSBh cyB0aGUgbG9uZy10ZXJtIGpvaW50CiAgICAgIHN0ZXdhcmRzIG9mIHRoZSBzZXJ2aWNlIG5h bWUgYW5kIHBvcnQgbnVtYmVyIHJlZ2lzdHJ5LiBUQ1AgYW5kIFVEUCBoYXZlCiAgICAgIGhh ZCByZW1hcmthYmxlIHN1Y2Nlc3Mgb3ZlciB0aGUgbGFzdCBkZWNhZGVzLiBUaG91c2FuZHMg b2YgYXBwbGljYXRpb25zCiAgICAgIGFuZCBhcHBsaWNhdGlvbi1sZXZlbCBwcm90b2NvbHMg aGF2ZSBzZXJ2aWNlIG5hbWVzIGFuZCBwb3J0cyBhc3NpZ25lZAogICAgICBmb3IgdGhlaXIg dXNlLCBhbmQgdGhlcmUgaXMgZXZlcnkgcmVhc29uIHRvIGJlbGlldmUgdGhhdCB0aGlzIHRy ZW5kIHdpbGwKICAgICAgY29udGludWUgaW50byB0aGUgZnV0dXJlLiBJdCBpcyBoZW5jZSBl eHRyZW1lbHkgaW1wb3J0YW50IHRoYXQKICAgICAgbWFuYWdlbWVudCBvZiB0aGUgcmVnaXN0 cnkgZm9sbG93IHByaW5jaXBsZXMgdGhhdCBlbnN1cmUgaXRzIGxvbmctdGVybQogICAgICB1 c2VmdWxuZXNzIGFzIGEgc2hhcmVkIHJlc291cmNlLiA8eHJlZiB0YXJnZXQ9InByaW5jaXBs ZXMiPjwveHJlZj4KICAgICAgZGlzY3Vzc2VzIHRoZXNlIHByaW5jaXBsZXMgaW4gZGV0YWls LjwhLS0gQ29tbWVudGVkIHRoaXMgb3V0IHVudGlsIHdlIGtub3cgd2hhdCBKb2UncyBkb2Mg d2lsbCBhY3R1YWxseSBzYXkuCiAgICAgIEd1aWRlbGluZXMgZm9yIHVzZXJzIHNlZWtpbmcg cG9ydCBudW1iZXJzIGFuZC9vciBzZXJ2aWNlIG5hbWVzLCBhcyB3ZWxsCiAgICAgIGFzIGEg ZGV0YWlsZWQgaGlzdG9yeSBvZiB0aGUgcG9ydCBudW1iZXIgcmVnaXN0cnkgYW5kIGFsdGVy bmF0ZSBtZWFucyBmb3IKICAgICAgY29vcmRpbmF0aW5nIGhvc3QgYWdyZWVtZW50IG9uIHNl cnZpY2UtdG8tcG9ydC1udW1iZXIgbWFwcGluZ3MsIGlzCiAgICAgIHByb3ZpZGVkIGluIGEg PHhyZWYgdGFyZ2V0PSJJLUQudG91Y2gtdHN2d2ctcG9ydC1ndWlkZWxpbmVzIj5jb21wYW5p b24KICAgICAgZG9jdW1lbnQ8L3hyZWY+Li0tPjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8 c2VjdGlvbiBhbmNob3I9ImJhY2tncm91bmQiIHRpdGxlPSJCYWNrZ3JvdW5kIj4KICAgICAg PHQ+VGhlIFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sIChUQ1ApIDx4cmVmCiAgICAg IHRhcmdldD0iUkZDMDc5MyI+PC94cmVmPiBhbmQgdGhlIFVzZXIgRGF0YWdyYW0gUHJvdG9j b2wgKFVEUCkgPHhyZWYKICAgICAgdGFyZ2V0PSJSRkMwNzY4Ij48L3hyZWY+IGhhdmUgZW5q b3llZCBhIHJlbWFya2FibGUgc3VjY2VzcyBvdmVyIHRoZQogICAgICBkZWNhZGVzIGFzIHRo ZSB0d28gbW9zdCB3aWRlbHkgdXNlZCB0cmFuc3BvcnQgcHJvdG9jb2xzIG9uIHRoZSBJbnRl cm5ldC4KICAgICAgVGhleSBoYXZlIHJlbGllZCBvbiB0aGUgY29uY2VwdCBvZiAicG9ydHMi IGFzIGxvZ2ljYWwgZW50aXRpZXMgZm9yCiAgICAgIEludGVybmV0IGNvbW11bmljYXRpb24u IFBvcnRzIHNlcnZlIHR3byBwdXJwb3NlczogZmlyc3QsIHRoZXkgcHJvdmlkZSBhCiAgICAg IGRlbXVsdGlwbGV4aW5nIGlkZW50aWZpZXIgdG8gZGlmZmVyZW50aWF0ZSB0cmFuc3BvcnQg c2Vzc2lvbnMgYmV0d2VlbgogICAgICB0aGUgc2FtZSBwYWlyIG9mIGVuZHBvaW50cywgYW5k IHNlY29uZCwgdGhleSBtYXkgYWxzbyBpZGVudGlmeSB0aGUKICAgICAgYXBwbGljYXRpb24g cHJvdG9jb2wgYW5kIGFzc29jaWF0ZWQgc2VydmljZSB0byB3aGljaCBwcm9jZXNzZXMgYmlu ZC4KICAgICAgTmV3ZXIgdHJhbnNwb3J0IHByb3RvY29scywgc3VjaCBhcyB0aGUgU3RyZWFt IENvbnRyb2wgVHJhbnNtaXNzaW9uCiAgICAgIFByb3RvY29sIChTQ1RQKSA8eHJlZiB0YXJn ZXQ9IlJGQzQ5NjAiPjwveHJlZj4gYW5kIHRoZSBEYXRhZ3JhbQogICAgICBDb25nZXN0aW9u IENvbnRyb2wgUHJvdG9jb2wgKERDQ1ApIDx4cmVmIHRhcmdldD0iUkZDNDM0MiI+PC94cmVm PiBoYXZlCiAgICAgIGFsc28gYWRvcHRlZCB0aGUgY29uY2VwdCBvZiBwb3J0cyBmb3IgdGhl aXIgY29tbXVuaWNhdGlvbiBzZXNzaW9ucyBhbmQKICAgICAgdXNlIHNpeHRlZW4tYml0IHBv cnQgbnVtYmVycyBpbiB0aGUgc2FtZSB3YXkgYXMgVENQIGFuZCBVRFAgKGFuZAogICAgICBV RFAtTGl0ZSA8eHJlZiB0YXJnZXQ9IlJGQzM4MjgiPjwveHJlZj4sIGEgdmFyaWFudCBvZiBV RFApLjwvdD4KCiAgICAgIDx0PlBvcnQgbnVtYmVycyBhcmUgdGhlIG9yaWdpbmFsIGFuZCBt b3N0IHdpZGVseSB1c2VkIG1lYW5zIGZvcgogICAgICBhcHBsaWNhdGlvbiBhbmQgc2Vydmlj ZSBpZGVudGlmaWNhdGlvbiBvbiB0aGUgSW50ZXJuZXQuIFBvcnRzIGFyZQogICAgICBzaXh0 ZWVuLWJpdCBudW1iZXJzLCBhbmQgdGhlIGNvbWJpbmF0aW9uIG9mIHNvdXJjZSBhbmQgZGVz dGluYXRpb24gcG9ydAogICAgICBudW1iZXJzIHRvZ2V0aGVyIHdpdGggdGhlIElQIGFkZHJl c3NlcyBvZiB0aGUgY29tbXVuaWNhdGluZyBlbmQgc3lzdGVtcwogICAgICB1bmlxdWVseSBp ZGVudGlmaWVzIGEgc2Vzc2lvbiBvZiBhIGdpdmVuIHRyYW5zcG9ydCBwcm90b2NvbC4gUG9y dAogICAgICBudW1iZXJzIGFyZSBhbHNvIGtub3duIGJ5IHRoZWlyIGFzc29jaWF0ZWQgc2Vy dmljZSBuYW1lcyBzdWNoIGFzCiAgICAgICJ0ZWxuZXQiIGZvciBwb3J0IG51bWJlciAyMyBh bmQgImh0dHAiIChhcyB3ZWxsIGFzICJ3d3ciIGFuZCAid3d3LWh0dHAiKQogICAgICBmb3Ig cG9ydCBudW1iZXIgODAuPC90PgoKICAgICAgPHQ+SG9zdHMgcnVubmluZyBzZXJ2aWNlcywg aG9zdHMgYWNjZXNzaW5nIHNlcnZpY2VzIG9uIG90aGVyIGhvc3RzLCBhbmQKICAgICAgaW50 ZXJtZWRpYXRlIGRldmljZXMgKHN1Y2ggYXMgZmlyZXdhbGxzIGFuZCBOQVRzKSB0aGF0IHJl c3RyaWN0IHNlcnZpY2VzCiAgICAgIG5lZWQgdG8gYWdyZWUgb24gd2hpY2ggc2VydmljZSBj b3JyZXNwb25kcyB0byBhIHBhcnRpY3VsYXIgZGVzdGluYXRpb24KICAgICAgcG9ydC4gQWx0 aG91Z2ggdGhpcyBpcyB1bHRpbWF0ZWx5IGEgbG9jYWwgZGVjaXNpb24gd2l0aCBtZWFuaW5n IG9ubHkKICAgICAgYmV0d2VlbiB0aGUgZW5kcG9pbnRzIG9mIGEgY29ubmVjdGlvbiwgaXQg aXMgY29tbW9uIGZvciBtYW55IHNlcnZpY2VzIHRvCiAgICAgIGhhdmUgYSBkZWZhdWx0IHBv cnQgdXBvbiB3aGljaCB0aG9zZSBzZXJ2ZXJzIHVzdWFsbHkgbGlzdGVuLCB3aGVuCiAgICAg IHBvc3NpYmxlLCBhbmQgdGhlc2UgcG9ydHMgYXJlIHJlY29yZGVkIGJ5IHRoZSBJbnRlcm5l dCBBc3NpZ25lZCBOdW1iZXJzCiAgICAgIEF1dGhvcml0eSAoSUFOQSkgdGhyb3VnaCB0aGUg c2VydmljZSBuYW1lIGFuZCBwb3J0IG51bWJlciByZWdpc3RyeSA8eHJlZgogICAgICB0YXJn ZXQ9IlBPUlRSRUciPjwveHJlZj4uPC90PgoKICAgICAgPHQ+T3ZlciB0aW1lLCB0aGUgYXNz dW1wdGlvbiB0aGF0IGEgcGFydGljdWxhciBwb3J0IG51bWJlciBuZWNlc3NhcmlseQogICAg ICBpbXBsaWVzIGEgcGFydGljdWxhciBzZXJ2aWNlIG1heSBiZWNvbWUgbGVzcyB0cnVlLiBG b3IgZXhhbXBsZSwgbXVsdGlwbGUKICAgICAgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIHNlcnZp Y2Ugb24gdGhlIHNhbWUgaG9zdCBjYW5ub3QgZ2VuZXJhbGx5IGxpc3RlbgogICAgICBvbiB0 aGUgc2FtZSBwb3J0LCBhbmQgbXVsdGlwbGUgaG9zdHMgYmVoaW5kIHRoZSBzYW1lIE5BVCBn YXRld2F5IGNhbm5vdAogICAgICBhbGwgaGF2ZSBhIG1hcHBpbmcgZm9yIHRoZSBzYW1lIHBv cnQgb24gdGhlIGV4dGVybmFsIHNpZGUgb2YgdGhlIE5BVAogICAgICBnYXRld2F5LCB3aGV0 aGVyIHVzaW5nIHN0YXRpYyBwb3J0IG1hcHBpbmdzIGNvbmZpZ3VyZWQgYnkgaGFuZCBieSB0 aGUKICAgICAgdXNlciwgb3IgZHluYW1pYyBwb3J0IG1hcHBpbmdzIGNvbmZpZ3VyZWQgYXV0 b21hdGljYWxseSB1c2luZyBhIHBvcnQKICAgICAgbWFwcGluZyBwcm90b2NvbCBsaWtlIDx4 cmVmIHRhcmdldD0iSS1ELmNoZXNoaXJlLW5hdC1wbXAiPk5BVCBQb3J0CiAgICAgIE1hcHBp bmcgUHJvdG9jb2wgKE5BVC1QTVApIDwveHJlZj4gb3IgPHhyZWYgdGFyZ2V0PSJJR0QiPklu dGVybmV0CiAgICAgIEdhdGV3YXkgRGV2aWNlIChJR0QpPC94cmVmPi48L3Q+CgogICAgICA8 IS0tCiAgICAgIDx0PjxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgIDx0PldoZW4g ZGlmZmVyZW50IGJhY2tncm91bmQgYXBwbGljYXRpb25zIG9uIGEgc2luZ2xlIGNvbXB1dGVy IGVhY2gKICAgICAgICAgIGV4cG9ydCBhIHdlYi1iYXNlZCB1c2VyIGludGVyZmFjZSwgKGUu Zy4gYXMgZG9uZSBieSB0aGUgQ29tbW9uIFVuaXgKICAgICAgICAgIFByaW50aW5nIFN5c3Rl bSA8eHJlZiB0YXJnZXQ9IkNVUFMiLz4pIHRoZXkgY2Fubm90IGFsbCBnZXQgVENQCiAgICAg ICAgICBwb3J0IDgwLCBlc3BlY2lhbGx5IGlmIHRoYXQgY29tcHV0ZXIgaXMgYWxzbyBob3N0 aW5nIGEgY29udmVudGlvbmFsCiAgICAgICAgICB3ZWIgc2l0ZSBvbiBUQ1AgcG9ydCA4MC4g Q29uc2VxdWVudGx5LCBhIHNpbmdsZSBob3N0IG1heSBoYXZlCiAgICAgICAgICBzZXZlcmFs IGRpZmZlcmVudCBwcm9jZXNzZXMgYWxsIGFuc3dlcmluZyBIVFRQIHJlcXVlc3RzIG9mIHZh cmlvdXMKICAgICAgICAgIGtpbmRzLCBvbiBwb3J0cyBvdGhlciB0aGFuIHBvcnQgODAuPC90 PgoKICAgICAgICAgIDx0PldoZW4gZGlmZmVyZW50IHVzZXJzIGFyZSBydW5uaW5nIG11bHRp cGxlIGNvcGllcyBvZiB0aGUgc2FtZQogICAgICAgICAgYXBwbGljYXRpb24gb24gYSBzaW5n bGUgY29tcHV0ZXIsIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUKICAgICAgICAgIGFwcGxp Y2F0aW9uIGNhbm5vdCBsaXN0ZW4gb24gdGhlIHNhbWUgcG9ydCBhdCB0aGUgc2FtZSB0aW1l LgogICAgICAgICAgQ29uc2VxdWVudGx5LCBhcHBsaWNhdGlvbnMgb2YgdGhpcyBraW5kIG5l ZWQgdG8gYmUgcHJvZ3JhbW1lZCB0bwogICAgICAgICAgZXhwZWN0IHRoYXQgdGhleSBtYXkg bm90IGFsd2F5cyBiZSBhYmxlIHRvIGdldCB0aGUgcG9ydCB0aGV5IHdhbnQsCiAgICAgICAg ICBhbmQgbWF5IGhhdmUgdG8gbGlzdGVuIG9uIGFuIGFsdGVybmF0aXZlIHBvcnQgaW5zdGVh ZC48L3Q+CgogICAgICAgICAgPHQ+V2hlbiBkaWZmZXJlbnQgY29tcHV0ZXJzIGluIGEgaG9t ZSBhcmUgdXNpbmcgYSBOQVQgZ2F0ZXdheSB0bwogICAgICAgICAgc2hhcmUgYSBzaW5nbGUg SVAgYWRkcmVzcywgdGhlIGNvbXB1dGVycyBjYW4gcmVxdWVzdCB0aGF0IHRoZSBOQVQKICAg ICAgICAgIGdhdGV3YXkgY3JlYXRlIHBvcnQgbWFwcGluZ3MgdG8gZW5hYmxlIHRoZW0gdG8g cmVjZWl2ZSBpbmJvdW5kCiAgICAgICAgICBjb25uZWN0aW9ucyA8eHJlZiB0YXJnZXQ9Ikkt RC5jaGVzaGlyZS1uYXQtcG1wIi8+PHhyZWYKICAgICAgICAgIHRhcmdldD0iSUdEIi8+LCBi dXQgdGhleSBjYW4ndCBhbGwgZ2V0IHRoZSBzYW1lIGV4dGVybmFsIHBvcnQKICAgICAgICAg IGF0IHRoZSBzYW1lIHRpbWUuIENvbnNlcXVlbnRseSwgc29tZSBhcHBsaWNhdGlvbnMgb24g c29tZSBvZiB0aG9zZQogICAgICAgICAgY29tcHV0ZXJzIG1heSBiZSByZWNlaXZpbmcgaW5i b3VuZCBjb25uZWN0aW9ucyBvbiBwb3J0IG90aGVyIHRoYW4KICAgICAgICAgIHRoZSBwb3J0 IHVzdWFsbHkgdXNlZCBmb3IgdGhlIHNlcnZpY2UgaW4gcXVlc3Rpb24uIEFzIElTUHMgYmVn aW4gdG8KICAgICAgICAgIGRlcGxveSBsYXJnZS1zY2FsZSBOQVQsIHNoYXJpbmcgYSBzaW5n bGUgSVAgYWRkcmVzcyBiZXR3ZWVuIG11bHRpcGxlCiAgICAgICAgICBob21lcywgaXQgaXMg bGlrZWx5IHRvIGJlY29tZSBldmVuIG1vcmUgY29tbW9uIHRvIGhhdmUgYXBwbGljYXRpb25z CiAgICAgICAgICByZWNlaXZpbmcgY29ubmVjdGlvbnMgb24gZHluYW1pY2FsbHkgYWxsb2Nh dGVkIHBvcnRzLjwvdD4KICAgICAgICA8L2xpc3Q+PC90PgotLT4KCiAgICAgIDx0PkFwcGxp Y2F0aW9ucyBtYXkgdXNlIG51bWVyaWMgcG9ydCBudW1iZXJzIGRpcmVjdGx5LCBsb29rIHVw IHBvcnQKICAgICAgbnVtYmVycyBiYXNlZCBvbiBzZXJ2aWNlIG5hbWVzIHZpYSBzeXN0ZW0g Y2FsbHMgc3VjaCBhcyBnZXRzZXJ2YnluYW1lKCkKICAgICAgb24gVU5JWCwgbG9vayB1cCBw b3J0IG51bWJlcnMgYnkgcGVyZm9ybWluZyBxdWVyaWVzIGZvciBETlMgU1JWIHJlY29yZHMK ICAgICAgPHhyZWYgdGFyZ2V0PSJSRkMyNzgyIj48L3hyZWY+PHhyZWYKICAgICAgdGFyZ2V0 PSJJLUQuY2hlc2hpcmUtZG5zZXh0LWRucy1zZCI+PC94cmVmPiwgb3IgZGV0ZXJtaW5lIHBv cnQgbnVtYmVycwogICAgICBpbiBhIHZhcmlldHkgb2Ygb3RoZXIgd2F5cyBsaWtlIHRoZSBU Q1AgUG9ydCBTZXJ2aWNlIE11bHRpcGxleGVyCiAgICAgIChUQ1BNVVgpIDx4cmVmIHRhcmdl dD0iUkZDMTA3OCI+PC94cmVmPi48L3Q+CgogICAgICA8dD5EZXNpZ25lcnMgb2YgYXBwbGlj YXRpb25zIGFuZCBhcHBsaWNhdGlvbi1sZXZlbCBwcm90b2NvbHMgbWF5IGFwcGx5CiAgICAg IHRvIElBTkEgZm9yIGFuIGFzc2lnbmVkIHNlcnZpY2UgbmFtZSBhbmQgcG9ydCBudW1iZXIg Zm9yIGEgc3BlY2lmaWMKICAgICAgYXBwbGljYXRpb24sIGFuZCBtYXkgLSBhZnRlciBzdWNj ZXNzZnVsIHJlZ2lzdHJhdGlvbiAtIGFzc3VtZSB0aGF0IG5vCiAgICAgIG90aGVyIGFwcGxp Y2F0aW9uIHdpbGwgdXNlIHRoYXQgc2VydmljZSBuYW1lIG9yIHBvcnQgbnVtYmVyIGZvciBp dHMKICAgICAgY29tbXVuaWNhdGlvbiBzZXNzaW9ucy4gQWx0ZXJuYXRpdmVseSwgYXBwbGlj YXRpb24gZGVzaWduZXJzIG1heSBhbHNvCiAgICAgIGFzayBmb3Igb25seSBhbiBhc3NpZ25l ZCBzZXJ2aWNlIG5hbWUsIGlmIHRoZWlyIGFwcGxpY2F0aW9uIGRvZXMgbm90CiAgICAgIHJl cXVpcmUgYSBmaXhlZCBwb3J0IG51bWJlci4gVGhlIGxhdHRlciBhbHRlcm5hdGl2ZSBpcyBl bmNvdXJhZ2VkIHdoZW4KICAgICAgcG9zc2libGUsIGluIG9yZGVyIHRvIGNvbnNlcnZlIHRo ZSBtb3JlIGxpbWl0ZWQgcG9ydCBudW1iZXIgc3BhY2UuIFRoaXMKICAgICAgaXMgYXBwbGlj YWJsZSwgZm9yIGV4YW1wbGUsIHRvIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBETlMgU1JWIHJl Y29yZHMgdG8KICAgICAgbG9vayB1cCBwb3J0IG51bWJlcnMgYXQgcnVudGltZS48L3Q+Cgog ICAgICA8IS0tCiAgICAgIFRoZXJlIGhhdmUgYmVlbiBtYW55IHByb3Bvc2FscyBvdmVyIHRo ZSB5ZWFycyBmb3IgcHV0dGluZyBuYW1lcwogICAgICBpbnN0ZWFkIG9mIG51bWJlcnMgaW50 byB0aGUgVENQIGhlYWRlci4gSSB0aGluayBpdCdzCiAgICAgIGluYXBwcm9wcmlhdGUgdG8g bGlzdCBvbmUgc3VjaCBwcm9wb3NhbCBoZXJlIGlmIHdlJ3JlIG5vdCBnb2luZwogICAgICB0 byBsaXN0IGFsbCB0aGUgb3RoZXJzIHRvby4KICAgICAgCiAgICAgICwgb3IgdHJhbnNwb3J0 cyB0aGF0IHVzZSBzZXJ2aWNlIG5hbWVzIG5vdCBjb3VwbGVkCiAgICAgIHRvIHBvcnQgbnVt YmVycywgZS5nLiwgVENQIHBvcnRuYW1lcwogICAgICA8eHJlZiB0YXJnZXQ9IkktRC50b3Vj aC10Y3AtcG9ydG5hbWVzIi8+CiAgICAgIC0tPgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0 aW9uIGFuY2hvcj0idGVybSIgdGl0bGU9IkNvbnZlbnRpb25zIFVzZWQgaW4gdGhpcyBEb2N1 bWVudCI+CiAgICAgIDx0PlRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVR VUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgICAgIlNIT1VMRCIsICJTSE9VTEQg Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAg ICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiAiS2V5 IHdvcmRzIGZvciB1c2UgaW4KICAgICAgUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBM ZXZlbHMiIDx4cmVmIHRhcmdldD0iUkZDMjExOSI+PC94cmVmPi48L3Q+CiAgICA8L3NlY3Rp b24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzcnZuYW1lIiB0aXRsZT0iU2VydmljZSBOYW1l cyI+CiAgICAgIDx0PlNlcnZpY2UgbmFtZXMgYXJlIHRoZSB1bmlxdWUga2V5IGluIHRoZSBT ZXJ2aWNlIE5hbWUgYW5kIFRyYW5zcG9ydAogICAgICBQcm90b2NvbCBQb3J0IE51bWJlciBS ZWdpc3RyeS4gVGhpcyB1bmlxdWUgc3ltYm9saWMgbmFtZSBmb3IgYSBzZXJ2aWNlCiAgICAg IG1heSBhbHNvIGJlIHVzZWQgZm9yIG90aGVyIHB1cnBvc2VzLCBzdWNoIGFzIGluIDx4cmVm CiAgICAgIHRhcmdldD0iUkZDMjc4MiI+RE5TIFNSViByZWNvcmRzPC94cmVmPi4gV2l0aGlu IHRoZSByZWdpc3RyeSwgdGhpcwogICAgICB1bmlxdWUga2V5IGVuc3VyZXMgdGhhdCBkaWZm ZXJlbnQgc2VydmljZXMgY2FuIGJlIHVuYW1iaWd1b3VzbHkKICAgICAgZGlzdGluZ3Vpc2hl ZCwgdGh1cyBwcmV2ZW50aW5nIG5hbWUgY29sbGlzaW9ucyBhbmQgYXZvaWRpbmcgY29uZnVz aW9uCiAgICAgIGFib3V0IHdobyBpcyB0aGUgUmVnaXN0cmFudCBmb3IgYSBwYXJ0aWN1bGFy IGVudHJ5LjwvdD4KCiAgICAgIDx0PlRoZXJlIG1heSBiZSBtb3JlIHRoYW4gb25lIHNlcnZp Y2UgbmFtZSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyCiAgICAgIHRyYW5zcG9ydCBw cm90b2NvbCBhbmQgcG9ydC4gVGhlcmUgYXJlIHRocmVlIHdheXMgdGhhdCBzdWNoIHNlcnZp Y2UgbmFtZQogICAgICBvdmVybG9hZGluZyBjYW4gb2NjdXI6IDxsaXN0IHN0eWxlPSJzeW1i b2xzIj4KICAgICAgICAgIDx0Pk92ZXJsb2FkaW5nIG9jY3VycyB3aGVuIG9uZSBzZXJ2aWNl IGlzIGFuIGV4dGVuc2lvbiBvZiBhbm90aGVyCiAgICAgICAgICBzZXJ2aWNlLCBhbmQgYW4g aW4tYmFuZCBtZWNoYW5pc20gZXhpc3RzIGZvciBkZXRlcm1pbmluZyBpZiB0aGUKICAgICAg ICAgIGV4dGVuc2lvbiBpcyBwcmVzZW50IG9yIG5vdC4gT25lIGV4YW1wbGUgaXMgcG9ydCAz NDc4LCB3aGljaCBoYXMgdGhlCiAgICAgICAgICBzZXJ2aWNlIG5hbWUgYWxpYXNlcyAic3R1 biIgYW5kICJ0dXJuIi4gVFVSTiA8eHJlZgogICAgICAgICAgdGFyZ2V0PSJSRkM1NzY2Ij48 L3hyZWY+IGlzIGFuIGV4dGVuc2lvbiB0byB0aGUgU1RVTiA8eHJlZgogICAgICAgICAgdGFy Z2V0PSJSRkM1Mzg5Ij48L3hyZWY+IHNlcnZpY2UuIFRVUk4tZW5hYmxlZCBjbGllbnRzIHdp c2hpbmcgdG8KICAgICAgICAgIGxvY2F0ZSBUVVJOIHNlcnZlcnMgY291bGQgYXR0ZW1wdCB0 byBkaXNjb3ZlciAic3R1biIgc2VydmljZXMgYW5kCiAgICAgICAgICB0aGVuIGNoZWNrIGlu LWJhbmQgaWYgdGhlIHNlcnZlciBzdXBwb3J0cyBUVVJOLCBidXQgdGhpcyB3b3VsZCBiZQog ICAgICAgICAgaW5lZmZpY2llbnQuIEVuYWJsaW5nIHRoZW0gdG8gZGlyZWN0bHkgcXVlcnkg Zm9yICJ0dXJuIiBzZXJ2ZXJzIGJ5CiAgICAgICAgICBuYW1lIGlzIGEgYmV0dGVyIGFwcHJv YWNoLiAoTm90ZSB0aGF0IFRVUk4gc2VydmVycyBpbiB0aGlzIGNhc2UKICAgICAgICAgIHNo b3VsZCBhbHNvIGJlIGxvY2F0YWJsZSB2aWEgYSAic3R1biIgZGlzY292ZXJ5LCBiZWNhdXNl IGV2ZXJ5IFRVUk4KICAgICAgICAgIHNlcnZlciBpcyBhbHNvIGEgU1RVTiBzZXJ2ZXIuKTwv dD4KCiAgICAgICAgICA8dD5CeSBoaXN0b3JpY2FsIGFjY2lkZW50IHRoZSBzZXJ2aWNlIG5h bWUgImh0dHAiIGNvcnJlc3BvbmRzIHRvCiAgICAgICAgICB0aGUgc2FtZSBwb3J0IG51bWJl ciBhcyAKICAgICAgICAgICJ3d3ciIGFuZCAid3d3LWh0dHAiLiBXaGVuIHVzZWQgaW4gU1JW IHJlY29yZHMgPHhyZWYKICAgICAgICAgIHRhcmdldD0iUkZDMjc4MiI+PC94cmVmPiwgYW5k IHNpbWlsYXIgc2VydmljZSBkaXNjb3ZlcnkgbWVjaGFuaXNtcwogICAgICAgICAgb25seSB0 aGUgc2VydmljZSBuYW1lICJodHRwIiBzaG91bGQgYmUgdXNlZCwgbm90IHRoZXNlIGFkZGl0 aW9uYWwKICAgICAgICAgIG5hbWVzLiBJZiBhCiAgICAgICAgICBzZXJ2ZXIgd2VyZSB0byBh ZHZlcnRpc2UgInd3dyIgdGhlbiBpdCB3b3VsZCBub3QgYmUgZGlzY292ZXJlZCBieQogICAg ICAgICAgY2xpZW50cyBicm93c2luZyBmb3IgImh0dHAiLiBBZHZlcnRpc2luZyBvciBicm93 c2luZyBmb3IgdGhlIGFsaWFzZXMKICAgICAgICAgIGFzIHdlbGwgYXMgdGhlIHByaW1hcnkg c2VydmljZSBuYW1lIHdvdWxkIGJlIGluZWZmaWNpZW50LCBhbmQKICAgICAgICAgIGFjaGll dmVzIG5vdGhpbmcgdGhhdCBpdCBub3QgYWxyZWFkeSBhY2hpZXZlZCBieSB1c2luZyB0aGUg c2VydmljZQogICAgICAgICAgbmFtZSAiaHR0cCIgZXhjbHVzaXZlbHkuPC90PgoKICAgICAg ICAgIDx0PkFzIGluZGljYXRlZCBpbiB0aGlzIGRvY3VtZW50LCBpbiAKICAgICAgICAgIDx4 cmVmIHRhcmdldD0iY29uc2lzdGVuY3kiPjwveHJlZj4sIHRvIGVuYWJsZQkKICAgICAgICAg IGxlZ2FjeSBuYW1lcyB0byBiZSByZXBsYWNlZCB3aXRoIG5hbWVzIGNvbnNpc3RlbnQgd2l0 aCB0aGUJCiAgICAgICAgICBzeW50YXggdGhpcyBkb2N1bWVudCBwcmVzY3JpYmVzLiBJbiB0 aGlzIGNhc2UsIG9ubHkgdGhlCQogICAgICAgICAgbmV3IG5hbWUgc2hvdWxkIGJlIHVzZWQg aW4gU1JWIHJlY29yZHMsIGJvdGggdG8gYXZvaWQJCiAgICAgICAgICB0aGUgc2FtZSBpc3N1 ZXMgYXMgd2l0aCBoaXN0b3JpY2FsIGNhc2VzIG9mIG11bHRpcGxlIG5hbWVzLAkKICAgICAg ICAgIGFzIHdlbGwgYXMgYmVjYXVzZSB0aGUgbGVnYWN5IG5hbWVzIGFyZSBpbmNvbXBhdGli bGUgd2l0aAkKICAgICAgICAgIFNSViByZWNvcmQgdXNlLjwvdD4KCiAgICAgICAgPC9saXN0 PiBGb3IgZnV0dXJlIGFzc2lnbm1lbnRzLCBhcHBsaWNhdGlvbnMgd2lsbCBub3QgYmUgcGVy bWl0dGVkCiAgICAgIHRoYXQgbWVyZWx5IHJlcXVlc3QgYSBuZXcgbmFtZSBleGFjdGx5IGR1 cGxpY2F0aW5nIGFuIGV4aXN0aW5nIHNlcnZpY2UuCiAgICAgIEhhdmluZyBtdWx0aXBsZSBu YW1lcyBmb3IgdGhlIHNhbWUgc2VydmljZSBzZXJ2ZXMgbm8gcHVycG9zZS4KICAgICAgSW1w bGVtZW50ZXJzIGFyZSByZXF1ZXN0ZWQgdG8gaW5mb3JtIElBTkEgaWYgdGhleSBkaXNjb3Zl ciBvdGhlciBjYXNlcwogICAgICB3aGVyZSBhIHNpbmdsZSBzZXJ2aWNlIGhhcyBtdWx0aXBs ZSBuYW1lcywgc28gdGhhdCBvbmUgbmFtZSBtYXkgYmUKICAgICAgcmVjb3JkZWQgYXMgdGhl IHByaW1hcnkgbmFtZSBmb3Igc2VydmljZSBkaXNjb3ZlcnkgcHVycG9zZXMuPC90PgoKICAg ICAgPHQ+U2VydmljZSBuYW1lcyBhcmUgYXNzaWduZWQgb24gYSAiZmlyc3QgY29tZSwgZmly c3Qgc2VydmVkIiBiYXNpcywgYXMKICAgICAgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0i cmVnaXN0cmF0aW9uIj48L3hyZWY+LiBOYW1lcyBzaG91bGQgYmUgYnJpZWYKICAgICAgYW5k IGluZm9ybWF0aXZlLCBhdm9pZGluZyB3b3JkcyBvciBhYmJyZXZpYXRpb25zIHRoYXQgYXJl IHJlZHVuZGFudCBpbgogICAgICB0aGUgY29udGV4dCBvZiB0aGUgcmVnaXN0cnkgKGUuZy4s ICJwb3J0IiwgInNlcnZpY2UiLCAicHJvdG9jb2wiLCBldGMuKQogICAgICBOYW1lcyByZWZl cnJpbmcgdG8gZGlzY292ZXJ5IHNlcnZpY2VzLCBlLmcuLCB1c2luZyBtdWx0aWNhc3Qgb3IK ICAgICAgYnJvYWRjYXN0IHRvIGlkZW50aWZ5IGVuZHBvaW50cyBjYXBhYmxlIG9mIGEgZ2l2 ZW4gc2VydmljZSwgU0hPVUxEIHVzZQogICAgICBhbiBlYXNpbHkgaWRlbnRpZmlhYmxlIHN1 ZmZpeCAoZS5nLiwgIi1kaXNjIikuPC90PgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMt c3ludGF4IiB0aXRsZT0iU2VydmljZSBOYW1lIFN5bnRheCI+CiAgICAgICAgPHQ+VmFsaWQg c2VydmljZSBuYW1lcyBhcmUgaGVyZWJ5IG5vcm1hdGl2ZWx5IGRlZmluZWQgYXMgZm9sbG93 czogCiAgICAgICAgPGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAgICAgICAgICA8dD5NVVNU IGJlIGF0IGxlYXN0IDEgY2hhcmFjdGVyIGFuZCBubyBtb3JlIHRoYW4gMTUgY2hhcmFjdGVy cwogICAgICAgICAgICBsb25nPC90PgoKICAgICAgICAgICAgPHQ+TVVTVCBjb250YWluIG9u bHkgVVMtQVNDSUkgPHhyZWYKICAgICAgICAgICAgdGFyZ2V0PSJBTlNJLlgzLTQuMTk4NiI+ PC94cmVmPiBsZXR0ZXJzICdBJyAtICdaJyBhbmQgJ2EnIC0gJ3onLAogICAgICAgICAgICBk aWdpdHMgJzAnIC0gJzknLCBhbmQgaHlwaGVucyAoJy0nLCBBU0NJSSAweDJEIG9yIGRlY2lt YWwgNDUpPC90PgoKICAgICAgICAgICAgPHQ+TVVTVCBjb250YWluIGF0IGxlYXN0IG9uZSBs ZXR0ZXIgKCdBJyAtICdaJyBvciAnYScgLSAneicpPC90PgoKICAgICAgICAgICAgPHQ+TVVT VCBOT1QgYmVnaW4gb3IgZW5kIHdpdGggYSBoeXBoZW48L3Q+CiAgICAgICAgICA8L2xpc3Q+ PC90PgoKICAgICAgICA8dD5UaGUgcmVhc29uIGZvciByZXF1aXJpbmcgYXQgbGVhc3Qgb25l IGxldHRlciBpcyB0byBhdm9pZCBzZXJ2aWNlCiAgICAgICAgbmFtZXMgbGlrZSAiMjMiIChj b3VsZCBiZSBjb25mdXNlZCB3aXRoIGEgbnVtZXJpYyBwb3J0IG51bWJlcikgb3IKICAgICAg ICAiNjAwMC02MDYzIiAoY291bGQgYmUgY29uZnVzZWQgd2l0aCBhIG51bWVyaWMgcG9ydCBu dW1iZXIgcmFuZ2UpLgogICAgICAgIEFsdGhvdWdoIHNlcnZpY2UgbmFtZXMgbWF5IGNvbnRh aW4gYm90aCB1cHBlci1jYXNlIGFuZCBsb3dlci1jYXNlCiAgICAgICAgbGV0dGVycywgY2Fz ZSBpcyBpZ25vcmVkIGZvciBjb21wYXJpc29uIHB1cnBvc2VzLCBzbyBib3RoICJodHRwIiBh bmQKICAgICAgICAiSFRUUCIgZGVub3RlIHRoZSBzYW1lIHNlcnZpY2UuPC90PgoKICAgICAg ICA8dD5TZXJ2aWNlIG5hbWVzIGFyZSBwdXJlbHkgb3BhcXVlIGlkZW50aWZpZXJzLCBhbmQg bm8gc2VtYW50aWNzIGFyZQogICAgICAgIGltcGxpZWQgYnkgYW55IHN1cGVyZmljaWFsIHN0 cnVjdHVyZSB0aGF0IGEgZ2l2ZW4gc2VydmljZSBuYW1lIG1heQogICAgICAgIGFwcGVhciB0 byBoYXZlLiBGb3IgZXhhbXBsZSwgYSBjb21wYW55IGNhbGxlZCAiRXhhbXBsZSIgbWF5IGNo b29zZSB0bwogICAgICAgIHJlZ2lzdGVyIHNlcnZpY2UgbmFtZXMgIkV4YW1wbGUtRm9vIiBh bmQgIkV4YW1wbGUtQmFyIiBmb3IgaXRzICJGb28iCiAgICAgICAgYW5kICJCYXIiIHByb2R1 Y3RzLCBidXQgdGhlICJFeGFtcGxlIiBjb21wYW55IGNhbid0IGNsYWltIHRvICJvd24iIGFs bAogICAgICAgIHNlcnZpY2UgbmFtZXMgYmVnaW5uaW5nIHdpdGggIkV4YW1wbGUtIiwgdGhl eSBjYW4ndCBwcmV2ZW50IHNvbWVvbmUKICAgICAgICBlbHNlIHJlZ2lzdGVyaW5nICJFeGFt cGxlLUJheiIgZm9yIGEgZGlmZmVyZW50IHNlcnZpY2UsIGFuZCB0aGV5IGNhbid0CiAgICAg ICAgcHJldmVudCBvdGhlciBkZXZlbG9wZXJzIGZyb20gdXNpbmcgdGhlICJFeGFtcGxlLUZv byIgYW5kCiAgICAgICAgIkV4YW1wbGUtQmFyIiBzZXJ2aWNlIHR5cGVzIGluIG9yZGVyIHRv IGludGVyb3BlcmF0ZSB3aXRoIHRoZSAiRm9vIgogICAgICAgIGFuZCAiQmFyIiBwcm9kdWN0 cy4gVGVjaG5pY2FsbHkgc3BlYWtpbmcsIGluIHNlcnZpY2UgZGlzY292ZXJ5CiAgICAgICAg cHJvdG9jb2xzLCBzZXJ2aWNlIG5hbWVzIGFyZSBtZXJlbHkgYSBzZXJpZXMgb2YgYnl0ZSB2 YWx1ZXMgb24gdGhlCiAgICAgICAgd2lyZTsgZm9yIHRoZSBtbmVtb25pYyBjb252ZW5pZW5j ZSBvZiBodW1hbiBkZXZlbG9wZXJzIGl0IGNhbiBiZQogICAgICAgIGNvbnZlbmllbnQgdG8g aW50ZXJwcmV0IHRob3NlIGJ5dGUgdmFsdWVzIGFzIGh1bWFuLXJlYWRhYmxlIGFzY2lpCiAg ICAgICAgY2hhcmFjdGVycywgYnV0IHNvZnR3YXJlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHB1 cmVseSBvcGFxdWUKICAgICAgICBpZGVudGlmaWVycyBhbmQgbm90IGF0dGVtcHQgdG8gcGFy c2UgdGhlbSBmb3IgYW55IGFkZGl0aW9uYWwgZW1iZWRkZWQKICAgICAgICBtZWFuaW5nLjwv dD4KCiAgICAgICAgPHQ+SW4gYXBwcm94aW1hdGVseSA5OCUgb2YgY2FzZXMsIHRoZSBuZXcg InNlcnZpY2UgbmFtZSIgaXMgZXhhY3RseQogICAgICAgIHRoZSBzYW1lIGFzIHRoZSBvbGQg aGlzdG9yaWMgInNob3J0IG5hbWUiIGZyb20gdGhlIElBTkEgd2ViIGZvcm1zCiAgICAgICAg PHhyZWYgdGFyZ2V0PSJTWVNGT1JNIj48L3hyZWY+IDx4cmVmIHRhcmdldD0iVVNSRk9STSI+ PC94cmVmPi4gSW4KICAgICAgICBhcHByb3hpbWF0ZWx5IDIlIG9mIGNhc2VzLCB0aGUgbmV3 ICJzZXJ2aWNlIG5hbWUiIGlzIGRlcml2ZWQgZnJvbSB0aGUKICAgICAgICBvbGQgaGlzdG9y aWMgInNob3J0IG5hbWUiIGFzIGRlc2NyaWJlZCBiZWxvdyBpbiA8eHJlZgogICAgICAgIHRh cmdldD0iY29uc2lzdGVuY3kiPjwveHJlZj4uPC90PgoKICAgICAgICA8dD5UaGUgcnVsZXMg Zm9yIHZhbGlkIHNlcnZpY2UgbmFtZXMsIGV4Y2VwdGluZyB0aGUgbGltaXQgb2YgMTUgY2hh cmFjdGVycwogICAgICAgIG1heGltdSwgYXJlIGFsc28gZXhwcmVzc2VkIGJlbG93IChhcyBh IG5vbi1ub3JtYXRpdmUgY29udmVuaWVuY2UpIHVzaW5nCiAgICAgICAgPHhyZWYgdGFyZ2V0 PSJSRkM1MjM0Ij5BQk5GPC94cmVmPi48L3Q+CgogICAgICAgIDxmaWd1cmU+CiAgICAgICAg ICA8YXJ0d29yaz48IVtDREFUQVsKICAgU1JWTkFNRSA9IChBTFBIQSAvICgxKkRJR0lUIFtI WVBIRU5dIEFMUEhBKSkgKihbSFlQSEVOXSBBTE5VTSkKICAgQUxOVU0gICA9IEFMUEhBIC8g RElHSVQgICAgIDsgQS1aLCBhLXosIDAtOQogICBIWVBIRU4gID0gJXgyZCAgICAgICAgICAg ICAgOyAiLSIgCiAgIEFMUEhBICAgPSAleDQxLTVBIC8gJXg2MS03QSA7IEEtWiAvIGEteiBb UkZDNTIzNF0KICAgRElHSVQgICA9ICV4MzAtMzkgICAgICAgICAgIDsgMC05ICAgICAgIFtS RkM1MjM0XQogICAgICAKICAgICAgXV0+PC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iU2VydmljZSBOYW1lIFVz YWdlIGluIEROUyBTUlYgUmVjb3JkcyI+CiAgICAgICAgPHQ+VGhlIEROUyBTUlYgc3BlY2lm aWNhdGlvbiA8eHJlZiB0YXJnZXQ9IlJGQzI3ODIiPjwveHJlZj4gc3RhdGVzCiAgICAgICAg dGhhdCB0aGUgU2VydmljZSBMYWJlbCBwYXJ0IG9mIHRoZSBvd25lciBuYW1lIG9mIGEgRE5T IFNSViByZWNvcmQKICAgICAgICBpbmNsdWRlcyBhICJTZXJ2aWNlIiBlbGVtZW50LCBkZXNj cmliZWQgYXMgInRoZSBzeW1ib2xpYyBuYW1lIG9mIHRoZQogICAgICAgIGRlc2lyZWQgc2Vy dmljZSIsIGJ1dCBhcyBkaXNjdXNzZWQgYWJvdmUsIGl0IGlzIG5vdCBjbGVhciBwcmVjaXNl bHkKICAgICAgICB3aGF0IHRoaXMgbWVhbnMuPC90PgoKICAgICAgICA8dD5UaGlzIGRvY3Vt ZW50IGNsYXJpZmllcyB0aGF0IHRoZSBTZXJ2aWNlIExhYmVsIE1VU1QgYmUgYSBzZXJ2aWNl CiAgICAgICAgbmFtZSBhcyBkZWZpbmVkIGhlcmVpbi4gVGhlIHNlcnZpY2UgbmFtZSBTSE9V TEQgYmUgcmVnaXN0ZXJlZCB3aXRoCiAgICAgICAgSUFOQSBhbmQgcmVjb3JkZWQgaW4gdGhl IFNlcnZpY2UgTmFtZSBhbmQgVHJhbnNwb3J0IFByb3RvY29sIFBvcnQKICAgICAgICBOdW1i ZXIgUmVnaXN0cnkgPHhyZWYgdGFyZ2V0PSJQT1JUUkVHIj48L3hyZWY+LjwvdD4KCiAgICAg ICAgPHQ+VGhlIGRldGFpbHMgb2YgdXNpbmcgU2VydmljZSBOYW1lcyBpbiBTUlYgU2Vydmlj ZSBMYWJlbHMgYXJlCiAgICAgICAgc3BlY2lmaWVkIGluIHRoZSBETlMgU1JWIHNwZWNpZmlj YXRpb24gPHhyZWYgdGFyZ2V0PSJSRkMyNzgyIj48L3hyZWY+LgogICAgICAgIFRoaXMgZG9j dW1lbnQgZG9lcyBub3QgY2hhbmdlIHRoYXQgc3BlY2lmaWNhdGlvbi48L3Q+CiAgICAgIDwv c2VjdGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9InR5cGVzIiB0 aXRsZT0iUG9ydCBOdW1iZXIgUmFuZ2VzIj4KICAgICAgPHQ+VENQLCBVRFAsIFVEUC1MaXRl LCBTQ1RQIGFuZCBEQ0NQIHVzZSBzaXh0ZWVuLWJpdCBuYW1lc3BhY2VzIGZvcgogICAgICB0 aGVpciBwb3J0IG51bWJlciByZWdpc3RyaWVzLiBUaGUgcG9ydCByZWdpc3RyaWVzIGZvciBh bGwgdGhlc2UKICAgICAgdHJhbnNwb3J0IHByb3RvY29scyBhcmUgc3ViZGl2aWRlZCBpbnRv IHRocmVlIHJhbmdlcyBvZiBudW1iZXJzLCBhbmQKICAgICAgPHhyZWYgdGFyZ2V0PSJ2YXJp YW5jZXMiPjwveHJlZj4gZGVzY3JpYmVzIHRoZSBJQU5BIHByb2NlZHVyZXMgZm9yIGVhY2gK ICAgICAgcmFuZ2UgaW4gZGV0YWlsOiA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAg ICA8dD50aGUgU3lzdGVtIFBvcnRzLCBhbHNvIGtub3duIGFzIHRoZSBXZWxsIEtub3duIFBv cnRzLCBmcm9tIDAtMTAyMwogICAgICAgICAgKGFzc2lnbmVkIGJ5IElBTkEpPC90PgoKICAg ICAgICAgIDx0PnRoZSBVc2VyIFBvcnRzLCBhbHNvIGtub3duIGFzIHRoZSBSZWdpc3RlcmVk IFBvcnRzLCBmcm9tCiAgICAgICAgICAxMDI0LTQ5MTUxIChhc3NpZ25lZCBieSBJQU5BKTwv dD4KCiAgICAgICAgICA8dD50aGUgRHluYW1pYyBQb3J0cywgYWxzbyBrbm93biBhcyB0aGUg UHJpdmF0ZSBQb3J0cywgZnJvbQogICAgICAgICAgNDkxNTItNjU1MzUgKG5ldmVyIGFzc2ln bmVkKTwvdD4KICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAgPHQ+T2YgdGhlIGFzc2lnbmFi bGUgcG9ydCByYW5nZXMgKFN5c3RlbSBQb3J0cyBhbmQgVXNlciBQb3J0cywgaS5lLiwKICAg ICAgcG9ydCBudW1iZXJzIDAtNDkxNTEpLCBpbmRpdmlkdWFsIHBvcnQgbnVtYmVycyBhcmUg aW4gb25lIG9mIHRocmVlCiAgICAgIHN0YXRlcyBhdCBhbnkgZ2l2ZW4gdGltZTo8L3Q+Cgog ICAgICA8dD48bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICA8dD5Bc3NpZ25lZDog QXNzaWduZWQgcG9ydCBudW1iZXJzIGFyZSBjdXJyZW50bHkgYWxsb2NhdGVkIHRvIHRoZQog ICAgICAgICAgc2VydmljZSBpbmRpY2F0ZWQgaW4gdGhlIHJlZ2lzdHJ5LjwvdD4KCiAgICAg ICAgICA8dD5VbmFzc2lnbmVkOiBVbmFzc2lnbmVkIHBvcnQgbnVtYmVycyBhcmUgY3VycmVu dGx5IGF2YWlsYWJsZSBmb3IKICAgICAgICAgIGFzc2lnbm1lbnQgdXBvbiByZXF1ZXN0LCBh cyBwZXIgdGhlIHByb2NlZHVyZXMgb3V0bGluZWQgaW4gdGhpcwogICAgICAgICAgZG9jdW1l bnQuPC90PgoKICAgICAgICAgIDx0PlJlc2VydmVkOiBSZXNlcnZlZCBwb3J0IG51bWJlcnMg YXJlIG5vdCBhdmFpbGFibGUgZm9yIHJlZ3VsYXIKICAgICAgICAgIGFzc2lnbm1lbnQ7IHRo ZXkgYXJlICJhc3NpZ25lZCB0byBJQU5BIiBmb3Igc3BlY2lhbCBwdXJwb3Nlcy4KICAgICAg ICAgIFJlc2VydmVkIHBvcnQgbnVtYmVycyBpbmNsdWRlIHZhbHVlcyBhdCB0aGUgZWRnZXMg b2YgZWFjaCByYW5nZSwKICAgICAgICAgIGUuZy4sIDAsIDEwMjMsIDEwMjQsIGV0Yy4sIHdo aWNoIG1heSBiZSB1c2VkIHRvIGV4dGVuZCB0aGVzZSByYW5nZXMKICAgICAgICAgIG9yIHRo ZSBvdmVyYWxsIHBvcnQgbnVtYmVyIHNwYWNlIGluIHRoZSBmdXR1cmUuPC90PgogICAgICAg IDwvbGlzdD48L3Q+CgogICAgICA8dD5JbiBvcmRlciB0byBrZWVwIHRoZSBzaXplIG9mIHRo ZSByZWdpc3RyeSBtYW5hZ2VhYmxlLCBJQU5BIHR5cGljYWxseQogICAgICBvbmx5IHJlY29y ZHMgdGhlIEFzc2lnbmVkIGFuZCBSZXNlcnZlZCBzZXJ2aWNlIG5hbWVzIGFuZCBwb3J0IG51 bWJlcnMgaW4KICAgICAgdGhlIHJlZ2lzdHJ5LiBVbmFzc2lnbmVkIHZhbHVlcyBhcmUgdHlw aWNhbGx5IG5vdCBleHBsaWNpdGx5IGxpc3RlZC4KICAgICAgKFRoZXJlIGFyZSBhbiBuZWFy LWluZmluaXRlIG51bWJlciBvZiBVbmFzc2lnbmVkIHNlcnZpY2UgbmFtZXMgYW5kCiAgICAg IGVudW1lcmF0aW5nIHRoZW0gYWxsIHdvdWxkIG5vdCBiZSBwcmFjdGljYWwuKTwvdD4KCiAg ICAgIDx0PkFzIGEgZGF0YSBwb2ludCwgd2hlbiB0aGlzIGRvY3VtZW50IHdhcyB3cml0dGVu LCBhcHByb3hpbWF0ZWx5IDc2JSBvZgogICAgICB0aGUgVENQIGFuZCBVRFAgU3lzdGVtIFBv cnRzIHdlcmUgYXNzaWduZWQsIGFuZCBhcHByb3hpbWF0ZWx5IDklIG9mIHRoZQogICAgICBV c2VyIFBvcnRzIHdlcmUgYXNzaWduZWQuIChBcyBub3RlZCwgRHluYW1pYyBQb3J0cyBhcmUg bmV2ZXIKICAgICAgYXNzaWduZWQuKTwvdD4KCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0idWRw dGNwZXhwIgogICAgICAgICAgICAgICB0aXRsZT0iU2VydmljZSBuYW1lcyBhbmQgUG9ydCBO dW1iZXJzIGZvciBFeHBlcmltZW50YXRpb24iPgogICAgICAgIDx0Pk9mIHRoZSBTeXN0ZW0g UG9ydHMsIHR3byBUQ1AgYW5kIFVEUCBwb3J0IG51bWJlcnMgKDEwMjEgYW5kIDEwMjIpLAog ICAgICAgIHRvZ2V0aGVyIHdpdGggdGhlaXIgcmVzcGVjdGl2ZSBzZXJ2aWNlIG5hbWVzICgi ZXhwMSIgYW5kICJleHAyIiksIGhhdmUKICAgICAgICBiZWVuIGFzc2lnbmVkIGZvciBleHBl cmltZW50YXRpb24gd2l0aCBuZXcgYXBwbGljYXRpb25zIGFuZAogICAgICAgIGFwcGxpY2F0 aW9uLWxheWVyIHByb3RvY29scyB0aGF0IHJlcXVpcmUgYSBwb3J0IG51bWJlciBpbiB0aGUg YXNzaWduZWQKICAgICAgICBwb3J0cyByYW5nZXMgPHhyZWYgdGFyZ2V0PSJSRkM0NzI3Ij48 L3hyZWY+LjwvdD4KCiAgICAgICAgPHQ+UGxlYXNlIHJlZmVyIHRvIFNlY3Rpb25zIDEgYW5k IDEuMSBvZiAiQXNzaWduaW5nIEV4cGVyaW1lbnRhbCBhbmQKICAgICAgICBUZXN0aW5nIE51 bWJlcnMgQ29uc2lkZXJlZCBVc2VmdWwiIDx4cmVmIHRhcmdldD0iUkZDMzY5MiI+PC94cmVm PiBmb3IKICAgICAgICBob3cgdGhlc2UgZXhwZXJpbWVudGFsIHBvcnQgbnVtYmVycyBhcmUg dG8gYmUgdXNlZC48IS0tIEkgc3RpbGwgdGhpbmsgdGhpcyBjb3VsZCBiZSB1c2VmdWwgdG8g ZXhwbGljaXRseSByZXBlYXQgLSBMYXJzCiAgICAgICAgU3BlY2lmaWNhbGx5LCB0aGV5CiAg ICAgICAgU0hPVUxEIG9ubHkgYmUgdXNlZCBmb3IgbG9jYWwgZXhwZXJpbWVudHMgaW4gY29u dHJvbGxlZCBlbnZpcm9ubWVudHMsCiAgICAgICAgYW5kIHRoZXkgU0hPVUxEIE5PVCBiZSB1 c2VkIG9uIHRoZSBnbG9iYWwgSW50ZXJuZXQuIE1hbnkgbmV3CiAgICAgICAgYXBwbGljYXRp b25zIGFuZCBhcHBsaWNhdGlvbi1sYXllciBwcm90b2NvbHMgY2FuIGJlIGV4cGVyaW1lbnRl ZCB3aXRoCiAgICAgICAgd2l0aG91dCByZXF1aXJpbmcgYSBwb3J0IGluIHRoZSBTeXN0ZW0g b3IgVXNlciBwb3J0cyByYW5nZSwKICAgICAgICBieSB1c2luZyBwb3J0IG51bWJlcnMgaW4g dGhlIER5bmFtaWMgUG9ydHMgcmFuZ2UuIC0tPjwvdD4KCiAgICAgICAgPHQ+VGhpcyBkb2N1 bWVudCByZWdpc3RlcnMgdGhlIHNhbWUgdHdvIHNlcnZpY2UgbmFtZXMgYW5kIHBvcnQgbnVt YmVycwogICAgICAgIGZvciBleHBlcmltZW50YXRpb24gd2l0aCBuZXcgYXBwbGljYXRpb24t bGF5ZXIgcHJvdG9jb2xzIG92ZXIgU0NUUCBhbmQKICAgICAgICBEQ0NQIGluIDx4cmVmIHRh cmdldD0ic2N0cGRjY3BleHAiPjwveHJlZj4uPC90PgoKICAgICAgICA8dD5VbmZvcnR1bmF0 ZWx5LCBpdCBjYW4gYmUgZGlmZmljdWx0IHRvIGxpbWl0IGFjY2VzcyB0byB0aGVzZSBwb3J0 cy4KICAgICAgICBVc2VycyBTSE9VTEQgdGFrZSBtZWFzdXJlcyB0byBlbnN1cmUgdGhhdCBl eHBlcmltZW50YWwgcG9ydHMgYXJlCiAgICAgICAgY29ubmVjdGluZyB0byB0aGUgaW50ZW5k ZWQgcHJvY2Vzcy4gRm9yIGV4YW1wbGUsIHVzZXJzIG9mIHRoZXNlCiAgICAgICAgZXhwZXJp bWVudGFsIHBvcnRzIG1pZ2h0IGluY2x1ZGUgYSA2NC1iaXQgbm9uY2UsIG9uY2Ugb24gZWFj aCBzZWdtZW50CiAgICAgICAgb2YgYSBtZXNzYWdlLW9yaWVudGVkIGNoYW5uZWwgKGUuZy4s IFVEUCksIG9yIG9uY2UgYXQgdGhlIGJlZ2lubmluZyBvZgogICAgICAgIGEgYnl0ZS1zdHJl YW0gKGUuZy4sIFRDUCksIHdoaWNoIGlzIHVzZWQgdG8gY29uZmlybSB0aGF0IHRoZSBwb3J0 IGlzCiAgICAgICAgYmVpbmcgdXNlZCBhcyBpbnRlbmRlZC4gU3VjaCBjb25maXJtYXRpb24g b2YgaW50ZW5kZWQgdXNlIGlzCiAgICAgICAgZXNwZWNpYWxseSBpbXBvcnRhbnQgd2hlbiB0 aGVzZSBwb3J0cyBhcmUgYXNzb2NpYXRlZCB3aXRoIHByaXZpbGVnZWQKICAgICAgICAoZS5n Liwgc3lzdGVtIG9yIGFkbWluaXN0cmF0b3IpIHByb2Nlc3Nlcy48L3Q+CiAgICAgIDwvc2Vj dGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9InByaW5jaXBsZXMi CiAgICAgICAgICAgICB0aXRsZT0iUHJpbmNpcGxlcyBmb3IgU2VydmljZSBOYW1lIGFuZCBU cmFuc3BvcnQgUHJvdG9jb2wgUG9ydCBOdW1iZXIgUmVnaXN0cnkgTWFuYWdlbWVudCI+CiAg ICAgIDx0Pk1hbmFnZW1lbnQgcHJvY2VkdXJlcyBmb3IgdGhlIHNlcnZpY2UgbmFtZSBhbmQg dHJhbnNwb3J0IHByb3RvY29sCiAgICAgIHBvcnQgbnVtYmVyIHJlZ2lzdHJ5IGluY2x1ZGUg YWxsb2NhdGlvbiBvZiBzZXJ2aWNlIG5hbWVzIGFuZCBwb3J0CiAgICAgIG51bWJlcnMgdXBv biByZXF1ZXN0LCBhcyB3ZWxsIGFzIG1hbmFnZW1lbnQgb2YgaW5mb3JtYXRpb24gYWJvdXQK ICAgICAgZXhpc3RpbmcgYWxsb2NhdGlvbnMuIFRoZSBsYXR0ZXIgaW5jbHVkZXMgbWFpbnRh aW5pbmcgY29udGFjdCBhbmQKICAgICAgZGVzY3JpcHRpb24gaW5mb3JtYXRpb24gYWJvdXQg YXNzaWdubWVudHMsIHJldm9raW5nIGFiYW5kb25lZAogICAgICBhc3NpZ25tZW50cywgYW5k IHJlZGVmaW5pbmcgYXNzaWdubWVudHMgd2hlbiBuZWVkZWQuIE9mIHRoZXNlCiAgICAgIHBy b2NlZHVyZXMsIGNhcmVmdWwgcG9ydCBudW1iZXIgYWxsb2NhdGlvbiBpcyBtb3N0IGNyaXRp Y2FsLCBpbiBvcmRlciB0bwogICAgICBjb250aW51ZSB0byBjb25zZXJ2ZSB0aGUgcmVtYWlu aW5nIHBvcnQgbnVtYmVycy48L3Q+CgogICAgICA8dD5BcyBub3RlZCBlYXJsaWVyLCBvbmx5 IGFib3V0IDklIG9mIHRoZSBVc2VyIFBvcnQgc3BhY2UgaXMgY3VycmVudGx5CiAgICAgIGFz c2lnbmVkLiBUaGUgY3VycmVudCByYXRlIG9mIGFzc2lnbm1lbnQgaXMgYXBwcm94aW1hdGVs eSA0MDAgcG9ydHMgcGVyCiAgICAgIHllYXIsIGFuZCBoYXMgcmVtYWluZWQgc3RlYWR5IGZv ciB0aGUgcGFzdCA4IHllYXJzLiBBdCB0aGF0IHJhdGUsIGlmCiAgICAgIHNpbWlsYXIgY29u c2VydmF0aW9uIGNvbnRpbnVlcywgdGhpcyByZXNvdXJjZSB3aWxsIHN1c3RhaW4gYW5vdGhl ciA4NQogICAgICB5ZWFycyBvZiBhc3NpZ25tZW50IC0gd2l0aG91dCB0aGUgbmVlZCB0byBy ZXNvcnQgdG8gcmVhc3NpZ25tZW50IG9mCiAgICAgIHJlbGVhc2VkIHZhbHVlcyBvciByZXZv Y2F0aW9uLiBUaGUgbmFtZXNwYWNlIGF2YWlsYWJsZSBmb3Igc2VydmljZSBuYW1lcwogICAg ICBpcyBtdWNoIGxhcmdlciwgd2hpY2ggYWxsb3dzIGZvciBzaW1wbGVyIG1hbmFnZW1lbnQg cHJvY2VkdXJlcy48L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iUGFzdCBQcmluY2lwbGVz Ij4KICAgICAgICA8dD5CZWZvcmUgdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQs IHRoZSBwcmluY2lwbGVzIG9mIHNlcnZpY2UKICAgICAgICBuYW1lIGFuZCBwb3J0IG51bWJl ciBtYW5hZ2VtZW50IGZvbGxvd2VkIGEgZmV3IG1vc3RseS11bmRvY3VtZW50ZWQKICAgICAg ICBndWlkZWxpbmVzLiBUaGV5IGFyZSByZWNvcmRlZCBoZXJlIGZvciBoaXN0b3JpY2FsIHB1 cnBvc2VzLCBhbmQgdGhpcwogICAgICAgIGRvY3VtZW50IHVwZGF0ZXMgdGhlbSBpbiA8eHJl ZiB0YXJnZXQ9InVwcHJpbmMiPjwveHJlZj4uIFRoZXNlCiAgICAgICAgcHJpbmNpcGxlcyB3 ZXJlOjwvdD4KCiAgICAgICAgPHQ+PGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAgICAgICAg ICA8dD5UQ1AgYW5kIFVEUCBwb3J0cyB3ZXJlIHNpbXVsdGFuZW91c2x5IGFsbG9jYXRlZCB3 aGVuIGVpdGhlciB3YXMKICAgICAgICAgICAgcmVxdWVzdGVkPC90PgoKICAgICAgICAgICAg PHQ+UG9ydCBudW1iZXJzIHdlcmUgdGhlIHByaW1hcnkgYWxsb2NhdGlvbjsgc2VydmljZSBu YW1lcyB3ZXJlCiAgICAgICAgICAgIGluZm9ybWF0aXZlIG9ubHksIGFuZCBkaWQgbm90IGhh dmUgYSB3ZWxsLWRlZmluZWQgc3ludGF4PC90PgoKICAgICAgICAgICAgPHQ+UG9ydCBudW1i ZXJzIHdlcmUgY29uc2VydmVkIGluZm9ybWFsbHksIGFuZCBzb21ldGltZXMKICAgICAgICAg ICAgaW5jb25zaXN0ZW50bHkgKGUuZy4sIHNvbWUgc2VydmljZXMgd2VyZSBhbGxvY2F0ZWQg cmFuZ2VzIG9mIG1hbnkKICAgICAgICAgICAgcG9ydCBudW1iZXJzIGV2ZW4gd2hlcmUgbm90 IHN0cmljdGx5IG5lY2Vzc2FyeSk8L3Q+CgogICAgICAgICAgICA8dD5TQ1RQIGFuZCBEQ0NQ IHNlcnZpY2UgbmFtZSBhbmQgcG9ydCBudW1iZXIgcmVnaXN0cmllcyB3ZXJlCiAgICAgICAg ICAgIG1hbmFnZWQgc2VwYXJhdGVseSBmcm9tIHRoZSBUQ1AvVURQIHJlZ2lzdHJpZXM8L3Q+ CgogICAgICAgICAgICA8dD5TZXJ2aWNlIG5hbWVzIGNvdWxkIG5vdCBiZSBhc3NpZ25lZCBp biB0aGUgb2xkIHBvcnRzIHJlZ2lzdHJ5CiAgICAgICAgICAgIHdpdGhvdXQgYXNzaWduaW5n IGFuIGFzc29jaWF0ZWQgcG9ydCBudW1iZXIgYXQgdGhlIHNhbWUgdGltZTwvdD4KICAgICAg ICAgIDwvbGlzdD4gVGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgYW5kIGFsaWducyB0aGVzZSBn dWlkZWxpbmVzIGluIG9yZGVyCiAgICAgICAgdG8gbW9yZSBjb25zZXJ2YXRpdmVseSBtYW5h Z2UgdGhlIGxpbWl0ZWQgcmVtYWluaW5nIHBvcnQgbnVtYmVyIHNwYWNlCiAgICAgICAgYW5k IHRvIGVuYWJsZSBhbmQgcHJvbW90ZSB0aGUgdXNlIG9mIHNlcnZpY2UgbmFtZXMgZm9yIHNl cnZpY2UKICAgICAgICBpZGVudGlmaWNhdGlvbiB3aXRob3V0IGFzc29jaWF0ZWQgcG9ydCBu dW1iZXJzLCB3aGVyZSBwb3NzaWJsZS48L3Q+CgogICAgICAgIDwhLS0KICAgICAgPHQ+UG9y dCBudW1iZXJzIGFyZSBpbnRlbmRlZCB0byBpZGVudGlmeSBhIHNlcnZpY2UgYW5kCiAgICAg IGVuYWJsZSBwcm9jZXNzIGRlbXVsdGlwbGV4aW5nIGF0IGFuIGVuZHBvaW50OyB1c2VzIGJl eW9uZAogICAgICB0aG9zZSBiYXNpYyByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGF2b2lkZWQK ICAgICAgPHhyZWYgdGFyZ2V0PSJJLUQudG91Y2gtdHN2d2ctcG9ydC1ndWlkZWxpbmVzIi8+ LiBUaGlzCiAgICAgIGRvY3VtZW50IGFsc28gZm9jdXNlcyBvbiBzZXJ2aWNlIG5hbWVzIGFz IGEgdW5pcXVlIGlkZW50aWZpZXIsCiAgICAgIHRvIGluY3JlYXNlIHRoZSBzcGFjZSBhdmFp bGFibGUgKGZyb20gNCBieXRlcyB0byAxNCksIGFuZCB0bwogICAgICBlbmFibGUgdGhlaXIg dXNlIGluIHRoZSBhYnNlbmNlIG9mIGFzc29jaWF0ZWQgcG9ydCBudW1iZXIKICAgICAgYXNz aWdubWVudHMuCiAgICAgIDxjcmVmIHNvdXJjZT0iTGFycyIgYW5jaG9yPSJpbmNyLXNwYWNl Ij5JIGRvbid0IHVuZGVyc3RhbmQKICAgICAgd2hlcmUgdGhlICJleHRlbmQgZnJvbSA0IGJ5 dGVzIHRvIDE0IiBiaXQgY29tZXMKICAgICAgZnJvbS48L2NyZWY+PC90PgogICAgICAtLT4K ICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJ1cHByaW5jIiB0aXRs ZT0iVXBkYXRlZCBQcmluY2lwbGVzIj4KICAgICAgICA8dD5UaGlzIHNlY3Rpb24gc3VtbWFy aXplcyB0aGUgYmFzaWMgcHJpbmNpcGxlcyBieSB3aGljaCBJQU5BIGhhbmRsZXMKICAgICAg ICB0aGUgU2VydmljZSBOYW1lIGFuZCBUcmFuc3BvcnQgUHJvdG9jb2wgUG9ydCBOdW1iZXIg UmVnaXN0cnksIGFuZAogICAgICAgIGF0dGVtcHRzIHRvIGNvbnNlcnZlIHRoZSBwb3J0IG51 bWJlciBzcGFjZS4gVGhpcyBkZXNjcmlwdGlvbiBpcwogICAgICAgIGludGVuZGVkIHRvIGlu Zm9ybSBhcHBsaWNhbnRzIHJlcXVlc3Rpbmcgc2VydmljZSBuYW1lcyBhbmQgcG9ydAogICAg ICAgIG51bWJlcnMuIElBTkEgZGVjaXNpb25zIGFyZSBub3QgcmVxdWlyZWQgdG8gYmUgYm91 bmQgYnkgdGhlc2UKICAgICAgICBwcmluY2lwbGVzOyBvdGhlciBmYWN0b3JzIG1heSBjb21l IGludG8gcGxheSwgYW5kIGV4Y2VwdGlvbnMgbWF5IG9jY3VyCiAgICAgICAgd2hlcmUgZGVl bWVkIGluIHRoZSBiZXN0IGludGVyZXN0IG9mIHRoZSBJbnRlcm5ldC48L3Q+CgogICAgICAg IDx0PklBTkEgd2lsbCBiZWdpbiBhc3NpZ25pbmcgc2VydmljZSBuYW1lcyB0aGF0IGRvIG5v dCByZXF1ZXN0IGFuCiAgICAgICAgYXNzb2NpYXRlZCBwb3J0IG51bWJlciBhbGxvY2F0aW9u IHVuZGVyIGEgc2ltcGxlICJGaXJzdCBDb21lLCBGaXJzdAogICAgICAgIFNlcnZlZCIgcG9s aWN5IDx4cmVmIHRhcmdldD0iUkZDNTIyNiI+PC94cmVmPi4gSUFOQSBNQVksIGF0IGl0cwog ICAgICAgIGRpc2NyZXRpb24sIHJlZmVyIHNlcnZpY2UgbmFtZSByZXF1ZXN0cyB0byAiRXhw ZXJ0IFJldmlldyIgaW4gY2FzZXMgb2YKICAgICAgICBtYXNzIHJlZ2lzdHJhdGlvbnMgb3Ig b3RoZXIgc2l0dWF0aW9ucyB3aGVyZSBJQU5BIGJlbGlldmVzIGV4cGVydAogICAgICAgIHJl dmlldyBpcyBhZHZpc2FibGUuPC90PgoKICAgICAgICA8dD5UaGUgYmFzaWMgcHJpbmNpcGxl IG9mIHNlcnZpY2UgbmFtZSBhbmQgcG9ydCBudW1iZXIgcmVnaXN0cnkKICAgICAgICBtYW5h Z2VtZW50IGlzIHRvIGNvbnNlcnZlIHVzZSBvZiB0aGUgcG9ydCBzcGFjZSB3aGVyZSBwb3Nz aWJsZS4KICAgICAgICBFeHRlbnNpb25zIHRvIHN1cHBvcnQgbGFyZ2VyIHBvcnQgbnVtYmVy IHNwYWNlcyB3b3VsZCByZXF1aXJlIGNoYW5naW5nCiAgICAgICAgbWFueSBjb3JlIHByb3Rv Y29scyBvZiB0aGUgY3VycmVudCBJbnRlcm5ldCBpbiBhIHdheSB0aGF0IHdvdWxkIG5vdCBi ZQogICAgICAgIGJhY2t3YXJkIGNvbXBhdGlibGUgYW5kIGludGVyZmVyZSB3aXRoIGJvdGgg Y3VycmVudCBhbmQgbGVnYWN5CiAgICAgICAgYXBwbGljYXRpb25zLiBUbyBoZWxwIGVuc3Vy ZSB0aGlzIGNvbnNlcnZhdGlvbiB0aGUgcG9saWN5IGZvciBhbnkKICAgICAgICByZWdpc3Ry YXRpb24gcmVxdWVzdCBmb3IgcG9ydCBudW1iZXIgYWxsb2NhdGlvbnMgdXNlcyB0aGUgIkV4 cGVydAogICAgICAgIFJldmlldyIgcG9saWN5IDx4cmVmIHRhcmdldD0iUkZDNTIyNiI+PC94 cmVmPi48L3Q+CgogICAgICAgIDx0PkNvbnNlcnZhdGlvbiBvZiB0aGUgcG9ydCBudW1iZXIg c3BhY2UgaXMgcmVxdWlyZWQgYmVjYXVzZSB0aGlzCiAgICAgICAgc3BhY2UgaXMgYSBsaW1p dGVkIHJlc291cmNlLCBzbyBhcHBsaWNhdGlvbnMgYXJlIGV4cGVjdGVkIHRvCiAgICAgICAg cGFydGljaXBhdGUgaW4gdGhlIHRyYWZmaWMgZGVtdWx0aXBsZXhpbmcgcHJvY2VzcyB3aGVy ZSBmZWFzaWJsZS4gVGhlCiAgICAgICAgcG9ydCBudW1iZXJzIGFyZSBleHBlY3RlZCB0byBl bmNvZGUgYXMgbGl0dGxlIGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlCiAgICAgICAgdGhhdCB3 aWxsIHN0aWxsIGVuYWJsZSBhbiBhcHBsaWNhdGlvbiB0byBwZXJmb3JtIGZ1cnRoZXIKICAg ICAgICBkZW11bHRpcGxleGluZyBieSBpdHNlbGYuIEluIHBhcnRpY3VsYXI6PC90PgoKICAg ICAgICA8dD48bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICAgIDx0PklBTkEgd2ls bCBhbGxvY2F0ZSBvbmx5IG9uZSBhc3NpZ25lZCBwb3J0IG51bWJlciBwZXIgc2VydmljZSBv cgogICAgICAgICAgICBhcHBsaWNhdGlvbjwvdD4KCiAgICAgICAgICAgIDx0PklBTkEgd2ls bCBhbGxvY2F0ZSBvbmx5IG9uZSBhc3NpZ25lZCBwb3J0IG51bWJlciBmb3IgYWxsCiAgICAg ICAgICAgIHZlcnNpb25zIG9mIGEgc2VydmljZSAoZS5nLiwgcnVubmluZyB0aGUgc2Vydmlj ZSB3aXRoIG9yIHdpdGhvdXQgYQogICAgICAgICAgICBzZWN1cml0eSBtZWNoYW5pc20sIG9y IGZvciB1cGRhdGVkIHZhcmlhbnRzIG9mIGEgc2VydmljZSk8L3Q+CgogICAgICAgICAgICA8 dD5JQU5BIHdpbGwgYWxsb2NhdGUgb25seSBvbmUgYXNzaWduZWQgcG9ydCBudW1iZXIgZm9y IGFsbAogICAgICAgICAgICBkaWZmZXJlbnQgdHlwZXMgb2YgZGV2aWNlIHVzaW5nIG9yIHBh cnRpY2lwYXRpbmcgaW4gdGhlIHNhbWUKICAgICAgICAgICAgc2VydmljZTwvdD4KCiAgICAg ICAgICAgIDx0PklBTkEgd2lsbCBhbGxvY2F0ZSBwb3J0IG51bWJlcnMgb25seSBmb3IgdGhl IHRyYW5zcG9ydAogICAgICAgICAgICBwcm90b2NvbChzKSBleHBsaWNpdGx5IG5hbWVkIGlu IGEgcmVnaXN0cmF0aW9uIHJlcXVlc3Q8L3Q+CgogICAgICAgICAgICA8dD5JQU5BIG1heSBy ZWNvdmVyIHVudXNlZCBwb3J0IG51bWJlcnMsIHZpYSB0aGUgbmV3IHByb2NlZHVyZXMgb2YK ICAgICAgICAgICAgZGUtcmVnaXN0cmF0aW9uLCByZXZvY2F0aW9uLCBhbmQgdHJhbnNmZXI8 L3Q+CiAgICAgICAgICA8L2xpc3Q+IFdoZXJlIHBvc3NpYmxlLCBhIGdpdmVuIHNlcnZpY2Ug aXMgZXhwZWN0ZWQgdG8gZGVtdWx0aXBsZXgKICAgICAgICBtZXNzYWdlcyBpZiBuZWNlc3Nh cnkuIEZvciBleGFtcGxlLCBhcHBsaWNhdGlvbnMgYW5kIHByb3RvY29scyBhcmUKICAgICAg ICBleHBlY3RlZCB0byBpbmNsdWRlIGluLWJhbmQgdmVyc2lvbiBpbmZvcm1hdGlvbiwgc28g dGhhdCBmdXR1cmUKICAgICAgICB2ZXJzaW9ucyBvZiB0aGUgYXBwbGljYXRpb24gb3IgcHJv dG9jb2wgY2FuIHNoYXJlIHRoZSBzYW1lIGFsbG9jYXRlZAogICAgICAgIHBvcnQuIEFwcGxp Y2F0aW9ucyBhbmQgcHJvdG9jb2xzIGFyZSBhbHNvIGV4cGVjdGVkIHRvIGJlIGFibGUgdG8K ICAgICAgICBlZmZpY2llbnRseSB1c2UgYSBzaW5nbGUgYWxsb2NhdGVkIHBvcnQgZm9yIG11 bHRpcGxlIHNlc3Npb25zLCBlaXRoZXIKICAgICAgICBieSBkZW11bHRpcGxleGluZyBtdWx0 aXBsZSBzdHJlYW1zIHdpdGhpbiBvbmUgcG9ydCwgb3IgdXNpbmcgdGhlCiAgICAgICAgYWxs b2NhdGVkIHBvcnQgdG8gY29vcmRpbmF0ZSB1c2luZyBkeW5hbWljIHBvcnRzIGZvciBzdWJz ZXF1ZW50CiAgICAgICAgZXhjaGFuZ2VzIChlLmcuLCBpbiB0aGUgc3Bpcml0IG9mIEZUUCA8 eHJlZgogICAgICAgIHRhcmdldD0iUkZDMDk1OSI+PC94cmVmPikuPC90PgoKICAgICAgICA8 IS0tIFJlbW92ZWQgdW50aWwgZG9jIGlzIGF2YWlsYWJsZToKICAgICAgICBUaGVzZSBwcmlu Y2lwbGVzIG9mIHBvcnQgY29uc2VydmF0aW9uIGFyZSBleHBsYWluZWQgaW4KICAgICAgICA8 eHJlZiB0YXJnZXQ9IkktRC50b3VjaC10c3Z3Zy1wb3J0LWd1aWRlbGluZXMiLz4uCiAgICAg ICAgVGhhdCBkb2N1bWVudCBleHBsYWlucyBpbiBmdXJ0aGVyIGRldGFpbCBob3cgLS0+Cgog ICAgICAgIDx0PlBvcnRzIGFyZSB1c2VkIGluIHZhcmlvdXMgd2F5cywgbm90YWJseTo8L3Q+ CgogICAgICAgIDx0PjxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgICAgPHQ+YXMg ZW5kcG9pbnQgcHJvY2VzcyBpZGVudGlmaWVyczwvdD4KCiAgICAgICAgICAgIDx0PmFzIGFw cGxpY2F0aW9uIHByb3RvY29sIGlkZW50aWZpZXJzPC90PgoKICAgICAgICAgICAgPHQ+Zm9y IGZpcmV3YWxsIGZpbHRlcmluZyBwdXJwb3NlczwvdD4KICAgICAgICAgIDwvbGlzdD4gQm90 aCB0aGUgcHJvY2VzcyBpZGVudGlmaWVyIGFuZCB0aGUgcHJvdG9jb2wgaWRlbnRpZmllciB1 c2VzCiAgICAgICAgc3VnZ2VzdCB0aGF0IGFueXRoaW5nIGEgc2luZ2xlIHByb2Nlc3MgY2Fu IGRlbXVsdGlwbGV4LCBvciB0aGF0IGNhbiBiZQogICAgICAgIGVuY29kZWQgaW50byBhIHNp bmdsZSBwcm90b2NvbCwgc2hvdWxkIGJlLiBUaGUgZmlyZXdhbGwgZmlsdGVyaW5nIHVzZQog ICAgICAgIHN1Z2dlc3RzIHRoYXQgc29tZSB1c2VzIHRoYXQgY291bGQgYmUgbXVsdGlwbGV4 ZWQgb3IgZW5jb2RlZCBjb3VsZAogICAgICAgIGluc3RlYWQgYmUgc2VwYXJhdGVkIHRvIGFs bG93IGZvciBlYXNpZXIgZmlyZXdhbGwgbWFuYWdlbWVudC4gTm90ZQogICAgICAgIHRoYXQg dGhpcyBsYXR0ZXIgdXNlIGlzIG11Y2ggbGVzcyBzb3VuZCwgYmVjYXVzZSBwb3J0IG51bWJl cnMgaGF2ZQogICAgICAgIG1lYW5pbmcgb25seSBmb3IgdGhlIHR3byBlbmRwb2ludHMgaW52 b2x2ZWQgaW4gYSBjb25uZWN0aW9uLCBhbmQKICAgICAgICBkcmF3aW5nIGNvbmNsdXNpb25z IGFib3V0IHRoZSBzZXJ2aWNlIHRoYXQgZ2VuZXJhdGVkIGEgZ2l2ZW4gZmxvdwogICAgICAg IGJhc2VkIG9uIG9ic2VydmVkIHBvcnQgbnVtYmVycyBpcyBub3QgYWx3YXlzIHJlbGlhYmxl LiA8IS0tIChhZ2FpbiwgYXMgZGlzY3Vzc2VkIGluIGRldGFpbCBpbgogICAgICAgIDx4cmVm IHRhcmdldD0iSS1ELnRvdWNoLXRzdndnLXBvcnQtZ3VpZGVsaW5lcyIvPikuLS0+IEZ1cnRo ZXIsCiAgICAgICAgcHJldmlvdXMgc2VwYXJhdGlvbiBvZiBwcm90b2NvbCB2YXJpYW50cyBi YXNlZCBvbiBzZWN1cml0eQogICAgICAgIGNhcGFiaWxpdGllcyAoZS5nLiwgSFRUUCBvbiBU Q1AgcG9ydCA4MCB2cy4gSFRUUFMgb24gVENQIHBvcnQgNDQzKSBpcwogICAgICAgIG5vdCBy ZWNvbW1lbmRlZCBmb3IgbmV3IHByb3RvY29scywgYmVjYXVzZSBhbGwgbmV3IHByb3RvY29s cyBzaG91bGQgYmUKICAgICAgICBzZWN1cml0eS1jYXBhYmxlIGFuZCBjYXBhYmxlIG9mIG5l Z290aWF0aW5nIHRoZSB1c2Ugb2Ygc2VjdXJpdHkKICAgICAgICBpbi1iYW5kLjwvdD4KCiAg ICAgICAgPHQ+SUFOQSB3aWxsIGJlZ2luIGFzc2lnbmluZyBwb3J0IG51bWJlcnMgZm9yIG9u bHkgdGhvc2UgdHJhbnNwb3J0CiAgICAgICAgcHJvdG9jb2xzIGV4cGxpY2l0bHkgaW5jbHVk ZWQgaW4gYSByZWdpc3RyYXRpb24gcmVxdWVzdC4gVGhpcyBlbmRzIHRoZQogICAgICAgIGxv bmctc3RhbmRpbmcgcHJhY3RpY2Ugb2YgYXV0b21hdGljYWxseSBhc3NpZ25pbmcgYSBwb3J0 IG51bWJlciB0byBhbgogICAgICAgIGFwcGxpY2F0aW9uIGZvciBib3RoIFRDUCBhbmQgYSBV RFAsIGV2ZW4gaWYgdGhlIHJlcXVlc3QgaXMgZm9yIG9ubHkKICAgICAgICBvbmUgb2YgdGhl c2UgdHJhbnNwb3J0IHByb3RvY29scy4gVGhlIG5ldyBhbGxvY2F0aW9uIHByb2NlZHVyZQog ICAgICAgIGNvbnNlcnZlcyByZXNvdXJjZXMgYnkgYWxsb2NhdGluZyBhIHBvcnQgbnVtYmVy IHRvIGFuIGFwcGxpY2F0aW9uIGZvcgogICAgICAgIG9ubHkgdGhvc2UgdHJhbnNwb3J0IHBy b3RvY29scyAoVENQLCBVRFAsIFNDVFAgYW5kL29yIERDQ1ApIGl0CiAgICAgICAgYWN0dWFs bHkgdXNlcy4gVGhlIHBvcnQgbnVtYmVyIHdpbGwgYmUgbWFya2VkIGFzIFJlc2VydmVkIC0g aW5zdGVhZCBvZgogICAgICAgIEFzc2lnbmVkIC0gaW4gdGhlIHBvcnQgbnVtYmVyIHJlZ2lz dHJpZXMgb2YgdGhlIG90aGVyIHRyYW5zcG9ydAogICAgICAgIHByb3RvY29scy4gV2hlbiBh cHBsaWNhdGlvbnMgc3RhcnQgc3VwcG9ydGluZyB0aGUgdXNlIG9mIHNvbWUgb2YgdGhvc2UK ICAgICAgICBhZGRpdGlvbmFsIHRyYW5zcG9ydCBwcm90b2NvbHMsIHRoZSBSZWdpc3RyYW50 IGZvciB0aGUKICAgICAgICByZWdpc3RyYXRpb24gTVVTVCByZXF1ZXN0IElBTkEgdG8gY29u dmVydCB0aGUgcmVzZXJ2YXRpb24gaW50byBhCiAgICAgICAgcHJvcGVyIGFzc2lnbm1lbnQu IEFuIGFwcGxpY2F0aW9uIE1VU1QgTk9UIGFzc3VtZSB0aGF0IGl0IGNhbiB1c2UgYQogICAg ICAgIHBvcnQgbnVtYmVyIGFzc2lnbmVkIHRvIGl0IGZvciB1c2Ugd2l0aCBvbmUgdHJhbnNw b3J0IHByb3RvY29sIHdpdGgKICAgICAgICBhbm90aGVyIHRyYW5zcG9ydCBwcm90b2NvbCB3 aXRob3V0IGFza2luZyBJQU5BIHRvIGNvbnZlcnQgdGhlCiAgICAgICAgcmVzZXJ2YXRpb24g aW50byBhbiBhc3NpZ25tZW50LjwvdD4KCiAgICAgICAgPHQ+V2hlbiB0aGUgYXZhaWxhYmxl IHBvb2wgb2YgdW5hc3NpZ25lZCBudW1iZXJzIGhhcyBydW4gb3V0IGluIGEKICAgICAgICBw b3J0cyByYW5nZSwgaXQgd2lsbCBiZSBuZWNlc3NhcnkgZm9yIElBTkEgdG8gY29uc2lkZXIg dGhlIFJlc2VydmVkCiAgICAgICAgcG9ydHMgZm9yIGFzc2lnbm1lbnQuIFRoaXMgaXMgcGFy dCBvZiB0aGUgbW90aXZhdGlvbiBmb3Igbm90CiAgICAgICAgYXV0b21hdGljYWxseSBhc3Np Z25pbmcgcG9ydHMgZm9yIHRyYW5zcG9ydCBwcm90b2NvbHMgb3RoZXIgdGhhbiB0aGUKICAg ICAgICByZXF1ZXN0ZWQgb25lKHMpLiBUaGlzIHdpbGwgYWxsb3cgbW9yZSBwb3J0cyB0byBi ZSBhdmFpbGFibGUgZm9yCiAgICAgICAgYXNzaWdubWVudCB3aGVuIHRoYXQgdGltZSBjb21l cy4gVG8gaGVscCBjb25zZXJ2ZSBwb3J0cywgYXBwbGljYXRpb24KICAgICAgICBkZXZlbG9w ZXJzIHNob3VsZCByZWdpc3RlciBvbmx5IHRoZSB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQg dGhlaXIKICAgICAgICBhcHBsaWNhdGlvbiBjdXJyZW50bHkgdXNlcy48L3Q+CgogICAgICAg IDx0PkNvbnNlcnZhdGlvbiBvZiBwb3J0IG51bWJlcnMgaXMgaW1wcm92ZWQgYnkgcHJvY2Vk dXJlcyB0aGF0IGFsbG93CiAgICAgICAgcHJldmlvdXNseSBhbGxvY2F0ZWQgcG9ydCBudW1i ZXJzIHRvIGJlY29tZSBVbmFzc2lnbmVkLCBlaXRoZXIgdGhyb3VnaAogICAgICAgIGRlLXJl Z2lzdHJhdGlvbiBvciB0aHJvdWdoIHJldm9jYXRpb24sIGFuZCBieSBhIHByb2NlZHVyZSB0 aGF0IGxldHMKICAgICAgICBhcHBsaWNhdGlvbiBkZXNpZ25lcnMgdHJhbnNmZXIgYW4gYWxs b2NhdGVkIGJ1dCB1bnVzZWQgcG9ydCBudW1iZXIgdG8KICAgICAgICBhIG5ldyBhcHBsaWNh dGlvbi4gPHhyZWYgdGFyZ2V0PSJpYW5hLXByb2NlZHVyZXMiPjwveHJlZj4gZGVzY3JpYmVz CiAgICAgICAgdGhlc2UgcHJvY2VkdXJlcywgd2hpY2ggdW50aWwgbm93IHdlcmUgdW5kb2N1 bWVudGVkLiBQb3J0IG51bWJlcgogICAgICAgIGNvbnNlcnZhdGlvbiBpcyBhbHNvIGltcHJv dmVkIGJ5IHJlY29tbWVuZGluZyB0aGF0IGFwcGxpY2F0aW9ucyB0aGF0CiAgICAgICAgZG8g bm90IHJlcXVpcmUgYW4gYWxsb2NhdGVkIHBvcnQgc2hvdWxkIHJlZ2lzdGVyIG9ubHkgYSBz ZXJ2aWNlIG5hbWUKICAgICAgICB3aXRob3V0IGFuIGFzc29jaWF0ZWQgcG9ydCBudW1iZXIu PC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiBhbmNob3I9InZhcmlhbmNl cyIKICAgICAgICAgICAgICAgdGl0bGU9IlZhcmlhbmNlcyBmb3IgU3BlY2lmaWMgUG9ydCBO dW1iZXIgUmFuZ2VzIj4KICAgICAgICA8dD48eHJlZiB0YXJnZXQ9InR5cGVzIj48L3hyZWY+ IGRlc2NyaWJlcyB0aGUgZGlmZmVyZW50IHBvcnQgbnVtYmVyCiAgICAgICAgcmFuZ2VzLiBJ dCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IElBTkEgYXBwbGllcyBzbGlnaHRseSBkaWZm ZXJlbnQKICAgICAgICBwcm9jZWR1cmVzIHdoZW4gbWFuYWdpbmcgdGhlIGRpZmZlcmVudCBw b3J0IHJhbmdlcyBvZiB0aGUgc2VydmljZSBuYW1lCiAgICAgICAgYW5kIHBvcnQgbnVtYmVy IHJlZ2lzdHJ5OiA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICAgIDx0PlBvcnRz IGluIHRoZSBEeW5hbWljIFBvcnRzIHJhbmdlICg0OTE1Mi02NTUzNSkgaGF2ZSBiZWVuCiAg ICAgICAgICAgIHNwZWNpZmljYWxseSBzZXQgYXNpZGUgZm9yIGxvY2FsIGFuZCBkeW5hbWlj IHVzZSBhbmQgY2Fubm90IGJlCiAgICAgICAgICAgIGFzc2lnbmVkIHRocm91Z2ggSUFOQS4g QXBwbGljYXRpb24gc29mdHdhcmUgbWF5IHNpbXBseSB1c2UgdGhlbQogICAgICAgICAgICBm b3IgY29tbXVuaWNhdGlvbiB3aXRob3V0IGFueSBzb3J0IG9mIHJlZ2lzdHJhdGlvbi4gT24g dGhlIG90aGVyCiAgICAgICAgICAgIGhhbmQsIGFwcGxpY2F0aW9uIHNvZnR3YXJlIE1VU1Qg Tk9UIGFzc3VtZSB0aGF0IGEgc3BlY2lmaWMgcG9ydAogICAgICAgICAgICBudW1iZXIgaW4g dGhlIER5bmFtaWMgUG9ydHMgcmFuZ2Ugd2lsbCBhbHdheXMgYmUgYXZhaWxhYmxlIGZvcgog ICAgICAgICAgICBjb21tdW5pY2F0aW9uIGF0IGFsbCB0aW1lcywgYW5kIGEgcG9ydCBudW1i ZXIgaW4gdGhhdCByYW5nZSBoZW5jZQogICAgICAgICAgICBNVVNUIE5PVCBiZSB1c2VkIGFz IGEgc2VydmljZSBpZGVudGlmaWVyLjwvdD4KCiAgICAgICAgICAgIDx0PlBvcnRzIGluIHRo ZSBVc2VyIFBvcnRzIHJhbmdlICgxMDI0LTQ5MTUxKSBhcmUgYXZhaWxhYmxlIGZvcgogICAg ICAgICAgICByZWdpc3RyYXRpb24gdGhyb3VnaCBJQU5BLCBhbmQgTUFZIGJlIHVzZWQgYXMg c2VydmljZSBpZGVudGlmaWVycwogICAgICAgICAgICB1cG9uIHN1Y2Nlc3NmdWwgcmVnaXN0 cmF0aW9uLiBCZWNhdXNlIHJlZ2lzdGVyaW5nIGEgcG9ydCBudW1iZXIKICAgICAgICAgICAg Zm9yIGEgc3BlY2lmaWMgYXBwbGljYXRpb24gY29uc3VtZXMgYSBmcmFjdGlvbiBvZiB0aGUg c2hhcmVkCiAgICAgICAgICAgIHJlc291cmNlIHRoYXQgaXMgdGhlIHBvcnQgbnVtYmVyIHJl Z2lzdHJ5LCBJQU5BIHdpbGwgcmVxdWlyZSB0aGUKICAgICAgICAgICAgcmVxdWVzdGVyIHRv IGRvY3VtZW50IHRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhlIHBvcnQgbnVtYmVyLiBUaGlzCiAg ICAgICAgICAgIGRvY3VtZW50YXRpb24gd2lsbCBiZSBpbnB1dCB0byB0aGUgIkV4cGVydCBS ZXZpZXciIGFsbG9jYXRpb24KICAgICAgICAgICAgcHJvY2VkdXJlIDx4cmVmIHRhcmdldD0i UkZDNTIyNiI+PC94cmVmPiwgYnkgd2hpY2ggSUFOQSB3aWxsIGhhdmUKICAgICAgICAgICAg YSB0ZWNobmljYWwgZXhwZXJ0IHJldmlldyB0aGUgcmVxdWVzdCB0byBkZXRlcm1pbmUgd2hl dGhlciB0bwogICAgICAgICAgICBncmFudCB0aGUgcmVnaXN0cmF0aW9uLiBUaGUgc3VibWl0 dGVkIGRvY3VtZW50YXRpb24gTVVTVCBleHBsYWluCiAgICAgICAgICAgIHdoeSB1c2luZyBh IHBvcnQgbnVtYmVyIGluIHRoZSBEeW5hbWljIFBvcnRzIHJhbmdlIGlzIHVuc3VpdGFibGUK ICAgICAgICAgICAgZm9yIHRoZSBnaXZlbiBhcHBsaWNhdGlvbi4gUG9ydHMgaW4gdGhlIFVz ZXIgUG9ydHMgcmFuZ2UgbWF5IGFsc28KICAgICAgICAgICAgYmUgYXNzaWduZWQgdW5kZXIg dGhlICJJRVRGIFJldmlldyIgb3IgIklFU0cgQXBwcm92YWwiIGFsbG9jYXRpb24KICAgICAg ICAgICAgcHJvY2VkdXJlcyA8eHJlZiB0YXJnZXQ9IlJGQzUyMjYiPjwveHJlZj4sIHdoaWNo IGlzIGhvdyBtb3N0CiAgICAgICAgICAgIGFzc2lnbm1lbnRzIGZvciBJRVRGIHByb3RvY29s cyBhcmUgaGFuZGxlZC48L3Q+CgogICAgICAgICAgICA8dD5Qb3J0cyBpbiB0aGUgU3lzdGVt IFBvcnRzIHJhbmdlICgwLTEwMjMpIGFyZSBhbHNvIGF2YWlsYWJsZSBmb3IKICAgICAgICAg ICAgcmVnaXN0cmF0aW9uIHRocm91Z2ggSUFOQS4gQmVjYXVzZSB0aGUgU3lzdGVtIFBvcnRz IHJhbmdlIGlzIGJvdGgKICAgICAgICAgICAgdGhlIHNtYWxsZXN0IGFuZCB0aGUgbW9zdCBk ZW5zZWx5IGFsbG9jYXRlZCwgdGhlIHJlcXVpcmVtZW50cyBmb3IKICAgICAgICAgICAgbmV3 IGFsbG9jYXRpb25zIGFyZSBtb3JlIHN0cmljdCB0aGFuIHRob3NlIGZvciB0aGUgVXNlciBQ b3J0cwogICAgICAgICAgICByYW5nZSwgYW5kIHdpbGwgb25seSBiZSBncmFudGVkIHVuZGVy IHRoZSAiSUVURiBSZXZpZXciIG9yICJJRVNHCiAgICAgICAgICAgIEFwcHJvdmFsIiBhbGxv Y2F0aW9uIHByb2NlZHVyZXMgPHhyZWYgdGFyZ2V0PSJSRkM1MjI2Ij48L3hyZWY+LiBBCiAg ICAgICAgICAgIHJlcXVlc3QgZm9yIGEgU3lzdGVtIFBvcnQgbnVtYmVyIE1VU1QgZG9jdW1l bnQgKmJvdGgqIHdoeSB1c2luZyBhCiAgICAgICAgICAgIHBvcnQgbnVtYmVyIGZyb20gdGhl IFVzZXIgUG9ydHMgaXMgdW5zdWl0YWJsZSAqYW5kKiB3aHkgdXNpbmcgYQogICAgICAgICAg ICBwb3J0IG51bWJlciBmcm9tIHRoZSBEeW5hbWljIFBvcnRzIHJhbmdlcyBpcyB1bnN1aXRh YmxlIGZvciB0aGF0CiAgICAgICAgICAgIGFwcGxpY2F0aW9uLjwvdD4KICAgICAgICAgIDwv bGlzdD48L3Q+CiAgICAgIDwvc2VjdGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlv biBhbmNob3I9ImlhbmEtcHJvY2VkdXJlcyIKICAgICAgICAgICAgIHRpdGxlPSJJQU5BIFBy b2NlZHVyZXMgZm9yIE1hbmFnaW5nIHRoZSBTZXJ2aWNlIE5hbWUgYW5kIFRyYW5zcG9ydCBQ cm90b2NvbCBQb3J0IE51bWJlciBSZWdpc3RyeSI+CiAgICAgIDx0PlRoaXMgc2VjdGlvbiBk ZXNjcmliZXMgdGhlIHByb2Nlc3MgZm9yIGhhbmRsaW5nIHJlcXVlc3RzIGFzc29jaWF0ZWQK ICAgICAgd2l0aCBJQU5BJ3MgbWFuYWdlbWVudCBvZiB0aGUgU2VydmljZSBOYW1lIGFuZCBU cmFuc3BvcnQgUHJvdG9jb2wgUG9ydAogICAgICBOdW1iZXIgUmVnaXN0cnkuIFN1Y2ggcmVx dWVzdHMgaW5jbHVkZSBpbml0aWFsIHJlZ2lzdHJhdGlvbiwKICAgICAgZGUtcmVnaXN0cmF0 aW9uLCByZS11c2UsIGNoYW5nZXMgdG8gdGhlIHNlcnZpY2UgbmFtZSwgYW5kIHVwZGF0ZXMg dG8gdGhlCiAgICAgIGNvbnRhY3QgaW5mb3JtYXRpb24gb3IgZGVzY3JpcHRpb24gYXNzb2Np YXRlZCB3aXRoIGFuIGFzc2lnbm1lbnQuCiAgICAgIFJldm9jYXRpb24gaXMgYXMgYWRkaXRp b25hbCBwcm9jZXNzLCBpbml0aWF0ZWQgYnkgSUFOQS48L3Q+CgogICAgICA8c2VjdGlvbiBh bmNob3I9InJlZ2lzdHJhdGlvbiIKICAgICAgICAgICAgICAgdGl0bGU9IlNlcnZpY2UgTmFt ZSBhbmQgUG9ydCBOdW1iZXIgUmVnaXN0cmF0aW9uIj4KICAgICAgICA8dD5SZWdpc3RyYXRp b24gcmVmZXJzIHRvIHRoZSBhbGxvY2F0aW9uIG9mIHNlcnZpY2UgbmFtZXMgb3IgcG9ydAog ICAgICAgIG51bWJlcnMgdG8gYXBwbGljYW50cy4gQWxsIHN1Y2ggcmVnaXN0cmF0aW9ucyBh cmUgbWFkZSBmcm9tIHNlcnZpY2UKICAgICAgICBuYW1lcyBvciBwb3J0IG51bWJlcnMgdGhh dCBhcmUgVW5hc3NpZ25lZCBvciBSZXNlcnZlZCBhdCB0aGUgdGltZSBvZgogICAgICAgIHRo ZSBhbGxvY2F0aW9uLiBVbmFzc2lnbmVkIG5hbWVzIGFuZCBudW1iZXJzIGFyZSBhbGxvY2F0 ZWQgYWNjb3JkaW5nCiAgICAgICAgdG8gdGhlIHJ1bGVzIGRlc2NyaWJlZCBpbiA8eHJlZiB0 YXJnZXQ9InZhcmlhbmNlcyI+PC94cmVmPi4gUmVzZXJ2ZWQKICAgICAgICBudW1iZXJzIGFu ZCBuYW1lcyBhcmUgYXNzaWduZWQgb25seSBhZnRlciByZXZpZXcgYnkgSUFOQSBhbmQgdGhl IElFVEYsCiAgICAgICAgYW5kIGFyZSBhY2NvbXBhbmllZCBieSBhIHN0YXRlbWVudCBleHBs YWluaW5nIHRoZSByZWFzb24gYSBSZXNlcnZlZAogICAgICAgIG51bWJlciBvciBuYW1lIGlz IGFwcHJvcHJpYXRlIGZvciB0aGlzIGFjdGlvbi48L3Q+CgogICAgICAgIDx0PldoZW4gYSBy ZWdpc3RyYXRpb24gZm9yIG9uZSBvciBtb3JlIHRyYW5zcG9ydCBwcm90b2NvbHMgaXMKICAg ICAgICBhcHByb3ZlZCwgdGhlIHBvcnQgbnVtYmVyIGZvciBhbnkgbm9uLXJlcXVlc3RlZCB0 cmFuc3BvcnQgcHJvdG9jb2wocykKICAgICAgICB3aWxsIGJlIG1hcmtlZCBhcyBSZXNlcnZl ZC4gSUFOQSBTSE9VTEQgTk9UIGFzc2lnbiB0aGF0IHBvcnQgbnVtYmVyIHRvCiAgICAgICAg YW55IG90aGVyIGFwcGxpY2F0aW9uIG9yIHNlcnZpY2UgdW50aWwgbm8gb3RoZXIgcG9ydCBu dW1iZXJzIHJlbWFpbgogICAgICAgIFVuYXNzaWduZWQgaW4gdGhlIHJlcXVlc3RlZCByYW5n ZS4gVGhlIGN1cnJlbnQgUmVnaXN0cmFudAogICAgICAgIGZvciBhIHBvcnQgbnVtYmVyIE1B WSByZWdpc3RlciB0aGVzZSBSZXNlcnZlZCBwb3J0IG51bWJlcnMgZm9yIG90aGVyCiAgICAg ICAgdHJhbnNwb3J0IHByb3RvY29scyB3aGVuIG5lZWRlZC48L3Q+CgogICAgICAgIDx0Pjx2 c3BhY2UgYmxhbmtMaW5lcz0iMTQiIC8+QSBzZXJ2aWNlIG5hbWUgb3IgcG9ydCBudW1iZXIK ICAgICAgICByZWdpc3RyYXRpb24gcmVxdWVzdCBjb250YWlucyB0aGUgZm9sbG93aW5nIGlu Zm9ybWF0aW9uLiBUaGUgc2VydmljZQogICAgICAgIG5hbWUgaXMgdGhlIHVuaXF1ZSBpZGVu dGlmaWVyIG9mIGEgZ2l2ZW4gc2VydmljZTo8L3Q+CgogICAgICAgIDx0PjxsaXN0IHN0eWxl PSJlbXB0eSI+CiAgICAgICAgICAgIDx0PlNlcnZpY2UgTmFtZSAoUkVRVUlSRUQpPHZzcGFj ZSAvPiBUcmFuc3BvcnQgUHJvdG9jb2wocykKICAgICAgICAgICAgKFJFUVVJUkVEKTx2c3Bh Y2UgLz4gUmVnaXN0cmFudCAoUkVRVUlSRUQpPHZzcGFjZSAvPiBDb250YWN0CiAgICAgICAg ICAgIChSRVFVSVJFRCk8dnNwYWNlIC8+IERlc2NyaXB0aW9uIChSRVFVSVJFRCk8dnNwYWNl IC8+IFJlZmVyZW5jZQogICAgICAgICAgICAoUkVRVUlSRUQpPHZzcGFjZSAvPiBQb3J0IE51 bWJlciAoT1BUSU9OQUwpPHZzcGFjZSAvPiBTZXJ2aWNlIENvZGUKICAgICAgICAgICAgKFJF UVVJUkVEIGZvciBEQ0NQIG9ubHkpPHZzcGFjZSAvPiBLbm93biBVbmF1dGhvcml6ZWQgVXNl cwogICAgICAgICAgICAoT1BUSU9OQUwpPHZzcGFjZSAvPiBBc3NpZ25tZW50IE5vdGVzIChP UFRJT05BTCk8L3Q+CiAgICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAgICA8dD48bGlzdCBz dHlsZT0ic3ltYm9scyI+CiAgICAgICAgICAgIDx0PlNlcnZpY2UgTmFtZTogQSBkZXNpcmVk IHVuaXF1ZSBzZXJ2aWNlIG5hbWUgZm9yIHRoZSBzZXJ2aWNlCiAgICAgICAgICAgIGFzc29j aWF0ZWQgd2l0aCB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgTVVTVCBiZSBwcm92aWRlZCwg Zm9yIHVzZQogICAgICAgICAgICBpbiB2YXJpb3VzIHNlcnZpY2Ugc2VsZWN0aW9uIGFuZCBk aXNjb3ZlcnkgbWVjaGFuaXNtcyAoaW5jbHVkaW5nLAogICAgICAgICAgICBidXQgbm90IGxp bWl0ZWQgdG8sIEROUyBTUlYgcmVjb3JkcyA8eHJlZgogICAgICAgICAgICB0YXJnZXQ9IlJG QzI3ODIiPjwveHJlZj4pLiBUaGUgbmFtZSBNVVNUIGJlIGNvbXBsaWFudCB3aXRoIHRoZQog ICAgICAgICAgICBzeW50YXggZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9InNlYy1zeW50YXgi PjwveHJlZj4uIEluIG9yZGVyIHRvCiAgICAgICAgICAgIGJlIHVuaXF1ZSwgdGhleSBNVVNU IE5PVCBiZSBpZGVudGljYWwgdG8gYW55IGN1cnJlbnRseSBhc3NpZ25lZAogICAgICAgICAg ICBzZXJ2aWNlIG5hbWUgaW4gdGhlIElBTkEgcmVnaXN0cnkgPHhyZWYgdGFyZ2V0PSJQT1JU UkVHIj48L3hyZWY+LgogICAgICAgICAgICBTZXJ2aWNlIG5hbWVzIGFyZSBjYXNlLWluc2Vu c2l0aXZlOyB0aGV5IG1heSBiZSBwcm92aWRlZCBhbmQKICAgICAgICAgICAgZW50ZXJlZCBp bnRvIHRoZSByZWdpc3RyeSB3aXRoIG1peGVkIGNhc2UgZm9yIGNsYXJpdHksIGJ1dCBmb3Ig dGhlCiAgICAgICAgICAgIGNvbXBhcmlzb24gcHVycG9zZXMgdGhlIGNhc2UgaXMgaWdub3Jl ZC48L3Q+CgogICAgICAgICAgICA8dD5UcmFuc3BvcnQgUHJvdG9jb2wocyk6IFRoZSB0cmFu c3BvcnQgcHJvdG9jb2wocykgZm9yIHdoaWNoIHRoZQogICAgICAgICAgICBhbGxvY2F0aW9u IGlzIHJlcXVlc3RlZCBNVVNUIGJlIHByb3ZpZGVkLiBUaGlzIGZpZWxkIGlzIGN1cnJlbnRs eQogICAgICAgICAgICBsaW1pdGVkIHRvIG9uZSBvciBtb3JlIG9mIFRDUCwgVURQLCBTQ1RQ LCBhbmQgRENDUC4gVGhpcyBmaWVsZCBpcwogICAgICAgICAgICByZXF1aXJlZCBldmVuIGZv ciBzZXJ2aWNlcyB3aXRoIG5vIHBvcnQgbnVtYmVyLjwvdD4KCiAgICAgICAgICAgIDx0PlJl Z2lzdHJhbnQ6IE5hbWUgYW5kIGVtYWlsIGFkZHJlc3Mgb2YgdGhlIFJlZ2lzdHJhbnQuIFRo aXMgaXMKICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBSZWdpc3RyYW50IGlzIHRoZSBPcmdh bml6YXRpb24gb3IgQ29tcGFueQogICAgICAgICAgICByZXNwb25zaWJsZSBmb3IgdGhlIGlu aXRpYWwgcmVnaXN0cmF0aW9uLiBGb3IgcmVnaXN0cmF0aW9ucyBkb25lCiAgICAgICAgICAg IHRocm91Z2ggSUVURi1wdWJsaXNoZWQgUkZDcywgdGhlIFJlZ2lzdHJhbnQgd2lsbCBiZSB0 aGUgSUVTRy48L3Q+CgogICAgICAgICAgICA8dD5Db250YWN0OiBOYW1lIGFuZCBlbWFpbCBh ZGRyZXNzIG9mIHRoZSBDb250YWN0IHBlcnNvbiBmb3IgdGhlCiAgICAgICAgICAgIHJlZ2lz dHJhdGlvbi4gVGhpcyBpcyBSRVFVSVJFRC4gVGhlIENvbnRhY3QgcGVyc29uIGlzIHRoZQog ICAgICAgICAgICByZXNwb25zaWJsZSBwZXJzb24gZm9yIHRoZSBJbnRlcm5ldCBjb21tdW5p dHkgdG8gc2VuZCBxdWVzdGlvbnMKICAgICAgICAgICAgdG8uIFRoaXMgcGVyc29uIHdvdWxk IGFsc28gYmUgYXV0aG9yaXplZCB0byBzdWJtaXQgY2hhbmdlcyBvbgogICAgICAgICAgICBi ZWhhbGYgb2YgdGhlIFJlZ2lzdHJhbnQ7IGluIGNhc2VzIG9mIGNvbmZsaWN0IGJldHdlZW4g dGhlCiAgICAgICAgICAgIFJlZ2lzdHJhbnQgYW5kIHRoZSBDb250YWN0LCB0aGUgUmVnaXN0 cmFudCBkZWNpc2lvbnMgdGFrZSBwcmVjZWRlbmNlLiAKICAgICAgICAgICAgQWRkaXRpb25h bCBhZGRyZXNzIGluZm9ybWF0aW9uIE1BWSBiZQogICAgICAgICAgICBwcm92aWRlZC4gRm9y IHJlZ2lzdHJhdGlvbnMgZG9uZSB0aHJvdWdoIElFVEYtcHVibGlzaGVkIFJGQ3MsIHRoZQog ICAgICAgICAgICBDb250YWN0IHdpbGwgYmUgdGhlIElFU0cuPC90PgoKICAgICAgICAgICAg PHQ+RGVzY3JpcHRpb246IEEgc2hvcnQgZGVzY3JpcHRpb24gb2YgdGhlIHNlcnZpY2UgYXNz b2NpYXRlZCB3aXRoCiAgICAgICAgICAgIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCBpcyBS RVFVSVJFRC4gSXQgc2hvdWxkIGF2b2lkIGFsbCBidXQgdGhlCiAgICAgICAgICAgIG1vc3Qg d2VsbC1rbm93biBhY3Jvbnltcy48L3Q+CgogICAgICAgICAgICA8dD5SZWZlcmVuY2U6IEEg ZGVzY3JpcHRpb24gb2YgKG9yIGEgcmVmZXJlbmNlIHRvIGEgZG9jdW1lbnQKICAgICAgICAg ICAgZGVzY3JpYmluZykgdGhlIHByb3RvY29sIG9yIGFwcGxpY2F0aW9uIHVzaW5nIHRoaXMg cG9ydC4gVGhlCiAgICAgICAgICAgIGRlc2NyaXB0aW9uIG11c3Qgc3RhdGUgd2hldGhlciB0 aGUgcHJvdG9jb2wgdXNlcyBicm9hZGNhc3QsCiAgICAgICAgICAgIG11bHRpY2FzdCwgb3Ig YW55Y2FzdCBjb21tdW5pY2F0aW9uLiA8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+IEZvcgog ICAgICAgICAgICByZWdpc3RyYXRpb25zIHJlcXVlc3Rpbmcgb25seSBhIFNlcnZpY2UgTmFt ZSwgb3IgYSBTZXJ2aWNlIE5hbWUKICAgICAgICAgICAgYW5kIFVzZXIgUG9ydCwgYSBzdGF0 ZW1lbnQgdGhhdCB0aGUgcHJvdG9jb2wgaXMgcHJvcHJpZXRhcnkgYW5kCiAgICAgICAgICAg IG5vdCBwdWJsaWNseSBkb2N1bWVudGVkIGlzIGFsc28gYWNjZXB0YWJsZSBwcm92aWRlZCB0 aGF0IHRoZQogICAgICAgICAgICByZXF1aXJlZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdXNl IG9mIGJyb2FkY2FzdCwgbXVsdGljYXN0LCBvcgogICAgICAgICAgICBhbnljYXN0IGlzIGdp dmVuLiA8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+IEZvciByZWdpc3RyYXRpb24KICAgICAg ICAgICAgcmVxdWVzdHMgZm9yIGEgVXNlciBQb3J0LCB0aGUgcmVnaXN0cmF0aW9uIHJlcXVl c3QgTVVTVCBleHBsYWluCiAgICAgICAgICAgIHdoeSBhIHBvcnQgbnVtYmVyIGluIHRoZSBE eW5hbWljIFBvcnRzIHJhbmdlIGlzIHVuc3VpdGFibGUgZm9yIHRoZQogICAgICAgICAgICBn aXZlbiBhcHBsaWNhdGlvbi4gPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPiBGb3IgcmVnaXN0 cmF0aW9uCiAgICAgICAgICAgIHJlcXVlc3RzIGZvciBhIFN5c3RlbSBQb3J0LCB0aGUgcmVn aXN0cmF0aW9uIHJlcXVlc3QgTVVTVCBleHBsYWluCiAgICAgICAgICAgIHdoeSBhIHBvcnQg bnVtYmVyIGluIHRoZSBVc2VyIFBvcnRzIG9yIER5bmFtaWMgUG9ydHMgcmFuZ2VzIGlzCiAg ICAgICAgICAgIHVuc3VpdGFibGUsIGFuZCBhIHJlZmVyZW5jZSB0byBhIHN0YWJsZSBwcm90 b2NvbCBzcGVjaWZpY2F0aW9uCiAgICAgICAgICAgIGRvY3VtZW50IE1VU1QgYmUgcHJvdmlk ZWQuIEZvciByZXF1ZXN0cyBmcm9tIElFVEYgV29ya2luZyBHcm91cHMsCiAgICAgICAgICAg IElBTkEgTUFZIGFjY2VwdCAiZWFybHkgcmVnaXN0cmF0aW9uIiA8eHJlZgogICAgICAgICAg ICB0YXJnZXQ9IlJGQzQwMjAiPjwveHJlZj4gcmVxdWVzdHMgcmVmZXJlbmNpbmcgYSBzdWZm aWNpZW50bHkKICAgICAgICAgICAgc3RhYmxlIEludGVybmV0IERyYWZ0IGluc3RlYWQgb2Yg YSBwdWJsaXNoZWQgU3RhbmRhcmRzLVRyYWNrCiAgICAgICAgICAgIFJGQy48L3Q+CgogICAg ICAgICAgICA8dD5Qb3J0IE51bWJlcjogSWYgYXNzaWdubWVudCBvZiBhIHBvcnQgbnVtYmVy IGlzIGRlc2lyZWQsIGVpdGhlcgogICAgICAgICAgICB0aGUgY3VycmVudGx5IFVuYXNzaWdu ZWQgb3IgUmVzZXJ2ZWQgcG9ydCBudW1iZXIgdGhlIHJlcXVlc3RlcgogICAgICAgICAgICBz dWdnZXN0cyBmb3IgYWxsb2NhdGlvbiwgb3IgdGhlIHRleHQgIkFOWSIsIE1VU1QgYmUgcHJv dmlkZWQuIElmCiAgICAgICAgICAgIG9ubHkgYSBzZXJ2aWNlIG5hbWUgaXMgdG8gYmUgYXNz aWduZWQsIHRoaXMgZmllbGQgTVVTVCBiZSBlbXB0eS4KICAgICAgICAgICAgSWYgYSBzcGVj aWZpYyBwb3J0IG51bWJlciBpcyByZXF1ZXN0ZWQsIElBTkEgaXMgZW5jb3VyYWdlZCB0bwog ICAgICAgICAgICBhbGxvY2F0ZSB0aGUgcmVxdWVzdGVkIG51bWJlci4gSWYgdGhlIHRleHQg IkFOWSIgaXMgc3BlY2lmaWVkLAogICAgICAgICAgICBJQU5BIHdpbGwgY2hvb3NlIGEgc3Vp dGFibGUgbnVtYmVyIGZyb20gdGhlIFVzZXIgUG9ydHMgcmFuZ2UuIE5vdGUKICAgICAgICAg ICAgdGhhdCB0aGUgYXBwbGljYW50IE1VU1QgTk9UIHVzZSB0aGUgcmVxdWVzdGVkIHBvcnQg cHJpb3IgdG8gdGhlCiAgICAgICAgICAgIGNvbXBsZXRpb24gb2YgdGhlIHJlZ2lzdHJhdGlv bjwhLS0gb3IgdGhlIElFVEYgd2lsbCBiZSB2ZXJ5IHZlcnkgY3Jvc3MKICAgICAgICAgICAg YW5kIHdpbGwgZ2xhcmUgYXQgeW91IGluIGEgbW9zdCBkaXNhcHByb3ZpbmcgbWFubmVyLS0+ LjwvdD4KCiAgICAgICAgICAgIDx0PlNlcnZpY2UgQ29kZTogSWYgdGhlIHJlZ2lzdHJhdGlv biByZXF1ZXN0IGluY2x1ZGVzIERDQ1AgYXMgYQogICAgICAgICAgICB0cmFuc3BvcnQgcHJv dG9jb2wgdGhlbiB0aGUgcmVxdWVzdCBNVVNUIGluY2x1ZGUgYSBkZXNpcmVkIHVuaXF1ZQog ICAgICAgICAgICBEQ0NQIHNlcnZpY2UgY29kZSA8eHJlZiB0YXJnZXQ9IlJGQzU1OTUiPjwv eHJlZj4sIGFuZCBNVVNUIE5PVAogICAgICAgICAgICBpbmNsdWRlIGEgcmVxdWVzdGVkIERD Q1Agc2VydmljZSBjb2RlIG90aGVyd2lzZS4gU2VjdGlvbiAxOS44IG9mCiAgICAgICAgICAg IHRoZSBEQ0NQIHNwZWNpZmljYXRpb24gPHhyZWYgdGFyZ2V0PSJSRkM0MzQwIj48L3hyZWY+ IGRlZmluZXMKICAgICAgICAgICAgcmVxdWlyZW1lbnRzIGFuZCBydWxlcyBmb3IgYWxsb2Nh dGlvbiwgdXBkYXRlZCBieSB0aGlzCiAgICAgICAgICAgIGRvY3VtZW50LjwvdD4KCiAgICAg ICAgICAgIDx0Pktub3duIFVuYXV0aG9yaXplZCBVc2VzOiBBIGxpc3Qgb2YgdXNlcyBieSBh cHBsaWNhdGlvbnMgb3IKICAgICAgICAgICAgb3JnYW5pemF0aW9ucyB3aG8gYXJlIG5vdCB0 aGUgYXNzaWduZWUuIFRoaXMgbGlzdCBtYXkgYmUgYXVnbWVudGVkCiAgICAgICAgICAgIGJ5 IElBTkEgYWZ0ZXIgYXNzaWdubWVudCB3aGVuIHVuYXV0aG9yaXplZCB1c2VzIGFyZSByZXBv cnRlZC48L3Q+CgogICAgICAgICAgICA8dD5Bc3NpZ25tZW50IE5vdGVzOiBJbmRpY2F0aW9u cyBvZiBvd25lci9uYW1lIGNoYW5nZSwgb3IgYW55CiAgICAgICAgICAgIG90aGVyIGFzc2ln bm1lbnQgcHJvY2VzcyBpc3N1ZS4gVGhpcyBsaXN0IG1heSBiZSB1cGRhdGVkIGJ5IElBTkEK ICAgICAgICAgICAgYWZ0ZXIgYXNzaWdubWVudCB0byBoZWxwIHRyYWNrIGNoYW5nZXMgdG8g YW4gYXNzaWdubWVudCwgZS5nLiwKICAgICAgICAgICAgZGUtcmVnaXN0cmF0aW9uLCBvd25l ci9uYW1lIGNoYW5nZXMsIGV0Yy48L3Q+CiAgICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAg ICA8dD5JZiB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgaXMgZm9yIHRoZSBhZGRpdGlvbiBv ZiBhIG5ldyB0cmFuc3BvcnQKICAgICAgICBwcm90b2NvbCB0byBhbiBhbHJlYWR5IGFzc2ln bmVkIHNlcnZpY2UgbmFtZSwgSUFOQSBuZWVkcyB0byBjb25maXJtCiAgICAgICAgd2l0aCB0 aGUgUmVnaXN0cmFudCBmb3IgdGhlIGV4aXN0aW5nIGFzc2lnbm1lbnQgd2hldGhlcgogICAg ICAgIHRoaXMgYWRkaXRpb24gaXMgYXBwcm9wcmlhdGUuPC90PgoKICAgICAgICA8dD5XaGVu IElBTkEgcmVjZWl2ZXMgYSByZWdpc3RyYXRpb24gcmVxdWVzdCAtIGNvbnRhaW5pbmcgdGhl IGFib3ZlCiAgICAgICAgaW5mb3JtYXRpb24gLSB0aGF0IGlzIHJlcXVlc3RpbmcgYSBwb3J0 IG51bWJlciwgSUFOQSBTSEFMTCBpbml0aWF0ZSBhbgogICAgICAgICJFeHBlcnQgUmV2aWV3 IiA8eHJlZiB0YXJnZXQ9IlJGQzUyMjYiPjwveHJlZj4gaW4gb3JkZXIgdG8gZGV0ZXJtaW5l CiAgICAgICAgd2hldGhlciBhbiBhc3NpZ25tZW50IHNob3VsZCBiZSBtYWRlLiBGb3IgcmVx dWVzdHMgdGhhdCBkbyBub3QgaW5jbHVkZQogICAgICAgIGEgcG9ydCBudW1iZXIsIElBTkEg U0hPVUxEIGFzc2lnbiB0aGUgc2VydmljZSBuYW1lIHVuZGVyIGEgc2ltcGxlCiAgICAgICAg IkZpcnN0IENvbWUgRmlyc3QgU2VydmVkIiBwb2xpY3kgPHhyZWYgdGFyZ2V0PSJSRkM1MjI2 Ij48L3hyZWY+LjwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gYW5jaG9y PSJkZXJlZ2lzdHJhdGlvbiIKICAgICAgICAgICAgICAgdGl0bGU9IlNlcnZpY2UgTmFtZSBh bmQgUG9ydCBOdW1iZXIgRGUtUmVnaXN0cmF0aW9uIj4KICAgICAgICA8dD5UaGUgUmVnaXN0 cmFudCBvZiBhIGdyYW50ZWQgcG9ydCBudW1iZXIgYXNzaWdubWVudCBjYW4KICAgICAgICBy ZXR1cm4gdGhlIHBvcnQgbnVtYmVyIHRvIElBTkEgYXQgYW55IHRpbWUgaWYgdGhleSBubyBs b25nZXIgaGF2ZSBhCiAgICAgICAgbmVlZCBmb3IgaXQuIFRoZSBwb3J0IG51bWJlciB3aWxs IGJlIGRlLXJlZ2lzdGVyZWQgYW5kIHdpbGwgYmUgbWFya2VkCiAgICAgICAgYXMgUmVzZXJ2 ZWQuIElBTkEgc2hvdWxkIG5vdCByZS1hc3NpZ24gcG9ydCBudW1iZXJzIHRoYXQgaGF2ZSBi ZWVuCiAgICAgICAgZGUtcmVnaXN0ZXJlZCB1bnRpbCBhbGwgdW5hc3NpZ25lZCBwb3J0IG51 bWJlcnMgaW4gdGhlIHNwZWNpZmljIHJhbmdlCiAgICAgICAgaGF2ZSBiZWVuIGFzc2lnbmVk LjwvdD4KCiAgICAgICAgPHQ+QmVmb3JlIHByb2NlZWRpbmcgd2l0aCBhIHBvcnQgbnVtYmVy IGRlLXJlZ2lzdHJhdGlvbiwgSUFOQSBuZWVkcyB0bwogICAgICAgIHJlYXNvbmFibHkgZXN0 YWJsaXNoIHRoYXQgdGhlIHZhbHVlIGlzIGFjdHVhbGx5IG5vIGxvbmdlciBpbiB1c2UuPC90 PgoKICAgICAgICA8dD5CZWNhdXNlIHRoZXJlIGlzIG11Y2ggbGVzcyBkYW5nZXIgb2YgZXho YXVzdGluZyB0aGUgc2VydmljZSBuYW1lCiAgICAgICAgc3BhY2UgY29tcGFyZWQgdG8gdGhl IHBvcnQgbnVtYmVyIHNwYWNlLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGEKICAgICAgICBn aXZlbiBzZXJ2aWNlIG5hbWUgcmVtYWluIGFzc2lnbmVkIGV2ZW4gYWZ0ZXIgYWxsIGFzc29j aWF0ZWQgcG9ydAogICAgICAgIG51bWJlciBhc3NpZ25tZW50cyBoYXZlIGJlY29tZSBkZS1y ZWdpc3RlcmVkLiBVbmRlciB0aGlzIHBvbGljeSwgaXQKICAgICAgICB3aWxsIGFwcGVhciBp biB0aGUgcmVnaXN0cnkgYXMgaWYgaXQgaGFkIGJlZW4gY3JlYXRlZCB0aHJvdWdoIGEKICAg ICAgICBzZXJ2aWNlIG5hbWUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgdGhhdCBkaWQgbm90IGlu Y2x1ZGUgYW55IHBvcnQKICAgICAgICBudW1iZXJzLjwvdD4KCiAgICAgICAgPHQ+T24gcmFy ZSBvY2Nhc2lvbnMsIGl0IG1heSBzdGlsbCBiZSB1c2VmdWwgdG8gZGUtcmVnaXN0ZXIgYSBz ZXJ2aWNlCiAgICAgICAgbmFtZS4gSW4gc3VjaCBjYXNlcywgSUFOQSB3aWxsIG1hcmsgdGhl IHNlcnZpY2UgbmFtZSBhcyBSZXNlcnZlZC4gSUFOQQogICAgICAgIHdpbGwgaW52b2x2ZSB0 aGVpciBJRVNHLWFwcG9pbnRlZCBleHBlcnQgaW4gc3VjaCBjYXNlcy48L3Q+CiAgICAgIDwv c2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0icmV1c2UiIHRpdGxlPSJTZXJ2aWNl IE5hbWUgYW5kIFBvcnQgTnVtYmVyIFJlLVVzZSI+CiAgICAgICAgPHQ+SWYgdGhlIFJlZ2lz dHJhbnQgb2YgYSBncmFudGVkIHBvcnQgbnVtYmVyIGFzc2lnbm1lbnQKICAgICAgICBubyBs b25nZXIgaGF2ZSBhIG5lZWQgZm9yIHRoZSBhc3NpZ25lZCBudW1iZXIsIGJ1dCB3b3VsZCBs aWtlIHRvCiAgICAgICAgcmUtdXNlIGl0IGZvciBhIGRpZmZlcmVudCBhcHBsaWNhdGlvbiwg dGhleSBjYW4gc3VibWl0IGEgcmVxdWVzdCB0bwogICAgICAgIElBTkEgdG8gZG8gc28uPC90 PgoKICAgICAgICA8dD5Mb2dpY2FsbHksIHBvcnQgbnVtYmVyIHJlLXVzZSBpcyB0byBiZSB0 aG91Z2h0IG9mIGFzIGEKICAgICAgICBkZS1yZWdpc3RyYXRpb24gKDx4cmVmIHRhcmdldD0i ZGVyZWdpc3RyYXRpb24iPjwveHJlZj4pIGZvbGxvd2VkIGJ5IGFuCiAgICAgICAgaW1tZWRp YXRlIHJlLXJlZ2lzdHJhdGlvbiAoPHhyZWYgdGFyZ2V0PSJyZWdpc3RyYXRpb24iPjwveHJl Zj4pIG9mIHRoZQogICAgICAgIHNhbWUgcG9ydCBudW1iZXIgZm9yIGEgbmV3IGFwcGxpY2F0 aW9uLiBDb25zZXF1ZW50bHksIHRoZSBpbmZvcm1hdGlvbgogICAgICAgIHRoYXQgbmVlZHMg dG8gYmUgcHJvdmlkZWQgYWJvdXQgdGhlIHByb3Bvc2VkIG5ldyB1c2Ugb2YgdGhlIHBvcnQK ICAgICAgICBudW1iZXIgaXMgaWRlbnRpY2FsIHRvIHdoYXQgd291bGQgbmVlZCB0byBiZSBw cm92aWRlZCBmb3IgYSBuZXcgcG9ydAogICAgICAgIG51bWJlciBhbGxvY2F0aW9uIGZvciB0 aGUgc3BlY2lmaWMgcG9ydHMgcmFuZ2UuPC90PgoKICAgICAgICA8dD5CZWNhdXNlIHRoZXJl IGlzIG11Y2ggbGVzcyBkYW5nZXIgb2YgZXhoYXVzdGluZyB0aGUgc2VydmljZSBuYW1lCiAg ICAgICAgc3BhY2UgY29tcGFyZWQgdG8gdGhlIHBvcnQgbnVtYmVyIHNwYWNlLCBpdCBpcyBS RUNPTU1FTkRFRCB0aGF0IHRoZQogICAgICAgIG9yaWdpbmFsIHNlcnZpY2UgbmFtZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIHByaW9yIHVzZSBvZiB0aGUgcG9ydCBudW1iZXIKICAgICAgICBy ZW1haW5zIGFzc2lnbmVkLCBhbmQgYSBuZXcgc2VydmljZSBiZSBjcmVhdGVkIGFuZCBhc3Nv Y2lhdGVkIHdpdGggdGhlCiAgICAgICAgcG9ydCBudW1iZXIuIFRoaXMgaXMgYWdhaW4gY29u c2lzdGVudCB3aXRoIHZpZXdpbmcgYSByZS11c2UgcmVxdWVzdCBhcwogICAgICAgIGEgZGUt cmVnaXN0cmF0aW9uIGZvbGxvd2VkIGJ5IGFuIGltbWVkaWF0ZSByZS1yZWdpc3RyYXRpb24u IFJlLXVzaW5nCiAgICAgICAgYW4gYXNzaWduZWQgc2VydmljZSBuYW1lIGZvciBhIGRpZmZl cmVudCBhcHBsaWNhdGlvbiBpcyBOT1QKICAgICAgICBSRUNPTU1FTkRFRC48L3Q+CgogICAg ICAgIDx0PklBTkEgbmVlZHMgdG8gY2FyZWZ1bGx5IHJldmlldyBzdWNoIHJlcXVlc3RzIGJl Zm9yZSBhcHByb3ZpbmcgdGhlbS4KICAgICAgICBJbiBzb21lIGluc3RhbmNlcywgdGhlIEV4 cGVydCBSZXZpZXdlciB3aWxsIGRldGVybWluZSB0aGF0IHRoZQogICAgICAgIGFwcGxpY2F0 aW9uIHRoYXQgdGhlIHBvcnQgbnVtYmVyIHdhcyBhc3NpZ25lZCB0byBoYXMgZm91bmQgdXNh Z2UKICAgICAgICBiZXlvbmQgdGhlIG9yaWdpbmFsIHJlcXVlc3Rlciwgb3IgdGhhdCB0aGVy ZSBpcyBhIGNvbmNlcm4gdGhhdCBpdCBtYXkKICAgICAgICBoYXZlIHN1Y2ggdXNlcnMuIFRo aXMgZGV0ZXJtaW5hdGlvbiBNVVNUIGJlIG1hZGUgcXVpY2tseS4gQSBjb21tdW5pdHkKICAg ICAgICBjYWxsIGNvbmNlcm5pbmcgcmV2b2NhdGlvbiBvZiBhIHBvcnQgbnVtYmVyIChzZWUg YmVsb3cpIE1BWSBiZQogICAgICAgIGNvbnNpZGVyZWQsIGlmIGEgYnJvYWRlciB1c2Ugb2Yg dGhlIHBvcnQgbnVtYmVyIGlzIHN1c3BlY3RlZC48L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAg ICAgIDxzZWN0aW9uIGFuY2hvcj0icmV2b2NhdGlvbiIKICAgICAgICAgICAgICAgdGl0bGU9 IlNlcnZpY2UgTmFtZSBhbmQgUG9ydCBOdW1iZXIgUmV2b2NhdGlvbiI+CiAgICAgICAgPHQ+ QSBwb3J0IG51bWJlciByZXZvY2F0aW9uIGNhbiBiZSB0aG91Z2h0IG9mIGFzIGFuIElBTkEt aW5pdGlhdGVkCiAgICAgICAgZGUtcmVnaXN0cmF0aW9uICg8eHJlZiB0YXJnZXQ9ImRlcmVn aXN0cmF0aW9uIj48L3hyZWY+KSwgYW5kIGhhcwogICAgICAgIGV4YWN0bHkgdGhlIHNhbWUg ZWZmZWN0IG9uIHRoZSByZWdpc3RyeS48L3Q+CgogICAgICAgIDx0PlNvbWV0aW1lcywgaXQg d2lsbCBiZSBjbGVhciB0aGF0IGEgc3BlY2lmaWMgcG9ydCBudW1iZXIgaXMgbm8KICAgICAg ICBsb25nZXIgaW4gdXNlIGFuZCB0aGF0IElBTkEgY2FuIHJldm9rZSBpdCBhbmQgbWFyayBp dCBhcyBSZXNlcnZlZC4gQXQKICAgICAgICBvdGhlciB0aW1lcywgaXQgbWF5IGJlIHVuY2xl YXIgd2hldGhlciBhIGdpdmVuIGFzc2lnbmVkIHBvcnQgbnVtYmVyIGlzCiAgICAgICAgc3Rp bGwgaW4gdXNlIHNvbWV3aGVyZSBpbiB0aGUgSW50ZXJuZXQuIEluIHRob3NlIGNhc2VzLCBJ QU5BIG11c3QKICAgICAgICBjYXJlZnVsbHkgY29uc2lkZXIgdGhlIGNvbnNlcXVlbmNlcyBv ZiByZXZva2luZyB0aGUgcG9ydCBudW1iZXIsIGFuZAogICAgICAgIFNIT1VMRCBvbmx5IGRv IHNvIGlmIHRoZXJlIGlzIGFuIG92ZXJ3aGVsbWluZyBuZWVkLjwvdD4KCiAgICAgICAgPHQ+ V2l0aCB0aGUgaGVscCBvZiB0aGVpciBJRVNHLWFwcG9pbnRlZCBFeHBlcnQgUmV2aWV3ZXIs IElBTkEgU0hBTEwKICAgICAgICBmb3JtdWxhdGUgYSByZXF1ZXN0IHRvIHRoZSBJRVNHIHRv IGlzc3VlIGEgZm91ci13ZWVrIGNvbW11bml0eSBjYWxsCiAgICAgICAgY29uY2VybmluZyB0 aGUgcGVuZGluZyBwb3J0IG51bWJlciByZXZvY2F0aW9uLiBUaGUgSUVTRyBhbmQgSUFOQSwg d2l0aAogICAgICAgIHRoZSBFeHBlcnQgUmV2aWV3ZXIncyBzdXBwb3J0LCBTSEFMTCBkZXRl cm1pbmUgcHJvbXB0bHkgYWZ0ZXIgdGhlIGVuZAogICAgICAgIG9mIHRoZSBjb21tdW5pdHkg Y2FsbCB3aGV0aGVyIHJldm9jYXRpb24gc2hvdWxkIHByb2NlZWQgYW5kIHRoZW4KICAgICAg ICBjb21tdW5pY2F0ZSB0aGVpciBkZWNpc2lvbiB0byB0aGUgY29tbXVuaXR5LiBUaGlzIHBy b2NlZHVyZSB0eXBpY2FsbHkKICAgICAgICBpbnZvbHZlcyBzaW1pbGFyIHN0ZXBzIHRvIGRl LXJlZ2lzdHJhdGlvbiBleGNlcHQgdGhhdCBpdCBpcyBpbml0aWF0ZWQKICAgICAgICBieSBJ QU5BLjwvdD4KCiAgICAgICAgPHQ+QmVjYXVzZSB0aGVyZSBpcyBtdWNoIGxlc3MgZGFuZ2Vy IG9mIGV4aGF1c3RpbmcgdGhlIHNlcnZpY2UgbmFtZQogICAgICAgIHNwYWNlIGNvbXBhcmVk IHRvIHRoZSBwb3J0IG51bWJlciBzcGFjZSwgcmV2b2tpbmcgc2VydmljZSBuYW1lcyBpcyBO T1QKICAgICAgICBSRUNPTU1FTkRFRC48L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxz ZWN0aW9uIGFuY2hvcj0idHJhbnNmZXIiCiAgICAgICAgICAgICAgIHRpdGxlPSJTZXJ2aWNl IE5hbWUgYW5kIFBvcnQgTnVtYmVyIFRyYW5zZmVycyI+CiAgICAgICAgPHQ+VGhlIHZhbHVl IG9mIHNlcnZpY2UgbmFtZXMgYW5kIHBvcnQgbnVtYmVycyBpcyBkZWZpbmVkIGJ5IHRoZWly CiAgICAgICAgY2FyZWZ1bCBtYW5hZ2VtZW50IGFzIGEgc2hhcmVkIEludGVybmV0IHJlc291 cmNlLCB3aGVyZWFzIGVuYWJsaW5nCiAgICAgICAgdHJhbnNmZXIgYWxsb3dzIHRoZSBwb3Rl bnRpYWwgZm9yIGFzc29jaWF0ZWQgbW9uZXRhcnkgZXhjaGFuZ2VzLiBBcyBhCiAgICAgICAg cmVzdWx0LCB0aGUgSUVURiBkb2VzIG5vdCBwZXJtaXQgc2VydmljZSBuYW1lIG9yIHBvcnQg bnVtYmVyCiAgICAgICAgYXNzaWdubWVudHMgdG8gYmUgdHJhbnNmZXJyZWQgYmV0d2VlbiBw YXJ0aWVzLCBldmVuIHdoZW4gdGhleSBhcmUKICAgICAgICBtdXR1YWxseSBjb25zZW50aW5n LjwvdD4KCiAgICAgICAgPHQ+VGhlIGFwcHJvcHJpYXRlIGFsdGVybmF0ZSBwcm9jZWR1cmUg aXMgYSBjb29yZGluYXRlZAogICAgICAgIGRlLXJlZ2lzdHJhdGlvbiBhbmQgcmVnaXN0cmF0 aW9uOiBUaGUgbmV3IHBhcnR5IHJlcXVlc3RzIHRoZSBzZXJ2aWNlCiAgICAgICAgbmFtZSBv ciBwb3J0IG51bWJlciB2aWEgYSByZWdpc3RyYXRpb24gYW5kIHRoZSBwcmV2aW91cyBwYXJ0 eSByZWxlYXNlcwogICAgICAgIGl0cyBhc3NpZ25tZW50IHZpYSB0aGUgZGUtcmVnaXN0cmF0 aW9uIHByb2NlZHVyZSBvdXRsaW5lZCBhYm92ZS48L3Q+CgogICAgICAgIDx0PldpdGggdGhl IGhlbHAgb2YgdGhlaXIgSUVTRy1hcHBvaW50ZWQgRXhwZXJ0IFJldmlld2VyLCBJQU5BIFNI QUxMCiAgICAgICAgY2FyZWZ1bGx5IGRldGVybWluZSBpZiB0aGVyZSBpcyBhIHZhbGlkIHRl Y2huaWNhbCwgb3BlcmF0aW9uYWwgb3IKICAgICAgICBtYW5hZ2VyaWFsIHJlYXNvbiB0byBn cmFudCB0aGUgcmVxdWVzdGVkIG5ldyBhc3NpZ25tZW50LjwvdD4KICAgICAgPC9zZWN0aW9u PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9Ik1haW50ZW5hbmNlIElzc3VlcyI+CiAgICAgICAg PHQ+SW4gYWRkaXRpb24gdG8gdGhlIGZvcm1hbCBwcm9jZWR1cmVzIGRlc2NyaWJlZCBhYm92 ZSwgdXBkYXRlcyB0bwogICAgICAgIHRoZSBEZXNjcmlwdGlvbiBhbmQgQ29udGFjdCBpbmZv cm1hdGlvbiBhcmUgY29vcmRpbmF0ZWQgYnkKICAgICAgICBJQU5BIGluIGFuIGluZm9ybWFs IG1hbm5lciwgYW5kIG1heSBiZSBpbml0aWF0ZWQgYnkgZWl0aGVyIHRoZQogICAgICAgIHJl Z2lzdHJhbnQgb3IgYnkgSUFOQSwgZS5nLiwgYnkgdGhlIGxhdHRlciByZXF1ZXN0aW5nIGFu IHVwZGF0ZSB0bwogICAgICAgIGN1cnJlbnQgY29udGFjdCBpbmZvcm1hdGlvbi4gKE5vdGUg dGhhdCBSZWdpc3RyYXRpb24gQWRtaW5pc3RyYXRpdmUKICAgICAgICBDb250YWN0IGNhbm5v dCBiZSBjaGFuZ2VkOyBzZWUgPHhyZWYgdGFyZ2V0PSJ0cmFuc2ZlciI+PC94cmVmPgogICAg ICAgIGFib3ZlLik8L3Q+CiAgICAgIDwvc2VjdGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8 c2VjdGlvbiBhbmNob3I9InNlY2NvbnMiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0aW9u cyI+CiAgICAgIDx0PlRoZSBJQU5BIGd1aWRlbGluZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQgZG8gbm90IGNoYW5nZSB0aGUKICAgICAgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBV RFAsIFRDUCwgU0NUUCwgb3IgRENDUC48L3Q+CgogICAgICA8dD48IS0tIGFkYXB0ZWQgZnJv bSBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3BvcnQtbnVtYmVycyAtLT5Bc3Np Z25tZW50CiAgICAgIG9mIGEgc2VydmljZSBuYW1lIG9yIHBvcnQgbnVtYmVyIGRvZXMgbm90 IGluIGFueSB3YXkgaW1wbHkgYW4KICAgICAgZW5kb3JzZW1lbnQgb2YgYW4gYXBwbGljYXRp b24gb3IgcHJvZHVjdCwgYW5kIHRoZSBmYWN0IHRoYXQgbmV0d29yawogICAgICB0cmFmZmlj IGlzIGZsb3dpbmcgdG8gb3IgZnJvbSBhbiBhc3NpZ25lZCBwb3J0IG51bWJlciBkb2VzIG5v dCBtZWFuIHRoYXQKICAgICAgaXQgaXMgImdvb2QiIHRyYWZmaWMsIG9yIGV2ZW4gdGhhdCBp dCBpcyB1c2VkIGJ5IHRoZSBhc3NpZ25lZCBzZXJ2aWNlLgogICAgICBGaXJld2FsbCBhbmQg c3lzdGVtIGFkbWluaXN0cmF0b3JzIHNob3VsZCBjaG9vc2UgaG93IHRvIGNvbmZpZ3VyZSB0 aGVpcgogICAgICBzeXN0ZW1zIGJhc2VkIG9uIHRoZWlyIGtub3dsZWRnZSBvZiB0aGUgdHJh ZmZpYyBpbiBxdWVzdGlvbiwgbm90IGJhc2VkCiAgICAgIG9uIHdoZXRoZXIgb3Igbm90IHRo ZXJlIGlzIGFuIGFzc2lnbmVkIHNlcnZpY2UgbmFtZSBvciBwb3J0IG51bWJlci48L3Q+Cgog ICAgICA8dD5TZXJ2aWNlcyBhcmUgZXhwZWN0ZWQgdG8gaW5jbHVkZSBzdXBwb3J0IGZvciBz ZWN1cml0eSwgZWl0aGVyIGFzCiAgICAgIGRlZmF1bHQgb3IgZHluYW1pY2FsbHkgbmVnb3Rp YXRlZCBpbi1iYW5kLiBUaGUgdXNlIG9mIHNlcGFyYXRlIHNlcnZpY2UKICAgICAgbmFtZSBv ciBwb3J0IG51bWJlciBhc3NpZ25tZW50cyBmb3Igc2VjdXJlIGFuZCBpbnNlY3VyZSB2YXJp YW50cyBvZiB0aGUKICAgICAgc2FtZSBzZXJ2aWNlIGlzIHRvIGJlIGF2b2lkZWQgaW4gb3Jk ZXIgdG8gZGlzY291cmFnZSB0aGUgZGVwbG95bWVudCBvZgogICAgICBpbnNlY3VyZSBzZXJ2 aWNlcy48L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJpYW5hY29u cyIgdGl0bGU9IklBTkEgQ29uc2lkZXJhdGlvbnMiPgogICAgICA8IS0tIHB1dCBhbGwgY2hh bmdlcyBmcm9tIDI3ODAgaW50byB0aGlzIHNlY3Rpb24gLS0+CgogICAgICA8dD5UaGlzIGRv Y3VtZW50IG9ic29sZXRlcyBTZWN0aW9ucyA4IGFuZCA5LjEgb2YgdGhlIE1hcmNoIDIwMDAg SUFOQQogICAgICBBbGxvY2F0aW9uIEd1aWRlbGluZXMgPHhyZWYgdGFyZ2V0PSJSRkMyNzgw Ij48L3hyZWY+LjwvdD4KCiAgICAgIDwhLS0gVGhpcyBpcyB0cml2aWEgdGhhdCBiZWxvbmdz IGluIGFuIGVtYWlsIG1lc3NhZ2UsIG5vdCBpbiBhCiAgICAgIHB1YmxpYyBkb2N1bWVudCB0 aGF0IGV4aXN0cyBpbiBwZXJwZXR1aXR5LiBBIHllYXIgZnJvbSBub3cgd2hhdAogICAgICBw ZW9wbGUgd2lsbCBjYXJlIGFib3V0IGlzIGhvdyB0byByZWdpc3RlciB0aGVpciBzZXJ2aWNl LCBub3QgYQogICAgICB0ZWRpb3VzIGV4aGF1c3RpdmUgaGlzdG9yeSBvZiBob3cgaXQgY2Ft ZSB0byBiZSB0aGF0IHdheS4KICAgICAgCiAgICAgIExhcnMgc2F5czogTm8sIGl0IG5lZWRz IHRvIGJlIGhlcmUsIGJlY2F1c2UgYWxsIElBTkEgYWN0aW9ucyBuZWVkCiAgICAgIHRvIGJl IGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuCiAgICAgIC0tPgoKICAgICAgPHQ+VXBvbiBh cHByb3ZhbCBvZiB0aGlzIGRvY3VtZW50LCBJQU5BIGlzIHJlcXVlc3RlZCB0byBjb250YWN0 IFN0dWFydAogICAgICBDaGVzaGlyZSwgbWFpbnRhaW5lciBvZiB0aGUgaW5kZXBlbmRlbnQg c2VydmljZSBuYW1lIHJlZ2lzdHJ5IDx4cmVmCiAgICAgIHRhcmdldD0iU1JWUkVHIj48L3hy ZWY+LCBpbiBvcmRlciB0byBtZXJnZSB0aGUgY29udGVudHMgb2YgdGhhdCBwcml2YXRlCiAg ICAgIHJlZ2lzdHJ5IGludG8gdGhlIG9mZmljaWFsIElBTkEgcmVnaXN0cnkuIEl0IGlzIGV4 cGVjdGVkIHRoYXQgdGhlCiAgICAgIGluZGVwZW5kZW50IHJlZ2lzdHJ5IHdlYiBwYWdlIHdp bGwgYmUgdXBkYXRlZCB3aXRoIHBvaW50ZXJzIHRvIHRoZSBJQU5BCiAgICAgIHJlZ2lzdHJ5 IGFuZCB0byB0aGlzIFJGQy48L3Q+CgogICAgICA8dD5JQU5BIGlzIGluc3RydWN0ZWQgdG8g Y3JlYXRlIGEgbmV3IHNlcnZpY2UgbmFtZSBlbnRyeSBpbiB0aGUgc2VydmljZQogICAgICBu YW1lIGFuZCBwb3J0IG51bWJlciByZWdpc3RyeSA8eHJlZiB0YXJnZXQ9IlBPUlRSRUciPjwv eHJlZj4gZm9yIGFueQogICAgICBlbnRyeSBpbiB0aGUgIlByb3RvY29sIGFuZCBTZXJ2aWNl IE5hbWVzIiByZWdpc3RyeSA8eHJlZgogICAgICB0YXJnZXQ9IlBST1RTRVJWUkVHIj48L3hy ZWY+IHRoYXQgZG9lcyBub3QgYWxyZWFkeSBoYXZlIG9uZQogICAgICBhc3NpZ25lZC48L3Q+ CgogICAgICA8dD5JQU5BIGlzIGFsc28gaW5zdHJ1Y3RlZCB0byBpbmRpY2F0ZSBpbiB0aGUg QXNzaWdubWVudCBOb3RlcyBmb3IgInd3dyIKICAgICAgYW5kICJ3d3ctaHR0cCIgdGhhdCB0 aGV5IGFyZSBkdXBsaWNhbnRlIHRlcm1zIHRoYXQgcmVmZXIgdG8gdGhlICJodHRwIiBzZXJ2 aWNlLAogICAgICBhbmQgc2hvdWxkIG5vdCBiZSB1c2VkIGZvcgogICAgICBkaXNjb3Zlcnkg cHVycG9zZXMuIEZvciB0aGlzIGNvbmNlcHR1YWwgc2VydmljZSAoaHVtYW4tcmVhZGFibGUg d2ViCiAgICAgIHBhZ2VzIHNlcnZlZCBvdmVyIEhUVFApIHRoZSBjb3JyZWN0IHNlcnZpY2Ug bmFtZSB0byB1c2UgZm9yCiAgICAgIHNlcnZpY2UgZGlzY292ZXJ5IHB1cnBvc2VzIGlzICJo dHRwIiAoc2VlIDx4cmVmCiAgICAgIHRhcmdldD0ic3J2bmFtZSI+PC94cmVmPikuPC90PgoK ICAgICAgPHNlY3Rpb24gYW5jaG9yPSJjb25zaXN0ZW5jeSIgdGl0bGU9IlNlcnZpY2UgTmFt ZSBDb25zaXN0ZW5jeSI+CiAgICAgICAgPHQ+PHhyZWYgdGFyZ2V0PSJyZWdpc3RyYXRpb24i PjwveHJlZj4gZGVmaW5lcyB3aGljaCBjaGFyYWN0ZXIgc3RyaW5ncwogICAgICAgIGFyZSB3 ZWxsLWZvcm1lZCBzZXJ2aWNlIG5hbWVzLCB3aGljaCB1bnRpbCBub3cgaGFkIG5vdCBiZWVu IGNsZWFybHkKICAgICAgICBkZWZpbmVkLiBUaGUgZGVmaW5pdGlvbiBpbiA8eHJlZiB0YXJn ZXQ9InJlZ2lzdHJhdGlvbiI+PC94cmVmPiB3YXMKICAgICAgICBjaG9zZW4gdG8gYWxsb3cg bWF4aW11bSBjb21wYXRpYmlsaXR5IG9mIHNlcnZpY2UgbmFtZXMgd2l0aCBjdXJyZW50CiAg ICAgICAgYW5kIGZ1dHVyZSBzZXJ2aWNlIGRpc2NvdmVyeSBtZWNoYW5pc21zLjwvdD4KCiAg ICAgICAgPHQ+QXMgb2YgQXVndXN0IDUsIDIwMDkgYXBwcm94aW1hdGVseSA5OCUgb2YgdGhl IHNvLWNhbGxlZCAiU2hvcnQKICAgICAgICBOYW1lcyIgZnJvbSBleGlzdGluZyBwb3J0IG51 bWJlciByZWdpc3RyYXRpb25zIDx4cmVmCiAgICAgICAgdGFyZ2V0PSJQT1JUUkVHIj48L3hy ZWY+IG1lZXQgdGhlIHJ1bGVzIGZvciBsZWdhbCBzZXJ2aWNlIG5hbWVzIHN0YXRlZAogICAg ICAgIGluIDx4cmVmIHRhcmdldD0icmVnaXN0cmF0aW9uIj48L3hyZWY+LCBhbmQgaGVuY2Ug Zm9yIHRoZXNlIHNlcnZpY2VzCiAgICAgICAgdGhlaXIgc2VydmljZSBuYW1lIHdpbGwgYmUg ZXhhY3RseSB0aGUgc2FtZSBhcyB0aGVpciAiU2hvcnQgTmFtZSIuPC90PgoKICAgICAgICA8 dD5UaGUgcmVtYWluaW5nIGFwcHJveGltYXRlbHkgMiUgb2YgdGhlIGV4aXRpbmcgIlNob3J0 IE5hbWVzIiBhcmUgbm90CiAgICAgICAgc3VpdGFibGUgdG8gYmUgdXNlZCBkaXJlY3RseSBh cyB3ZWxsLWZvcm1lZCBzZXJ2aWNlIG5hbWVzIGJlY2F1c2UgdGhleQogICAgICAgIGNvbnRh aW4gaWxsZWdhbCBjaGFyYWN0ZXJzIHN1Y2ggYXMgYXN0ZXJpc2tzLCBkb3RzLCBwbHVzZXMs IHNsYXNoZXMsCiAgICAgICAgb3IgdW5kZXJzY29yZXMuIEFsbCBleGlzdGluZyAiU2hvcnQg TmFtZXMiIGNvbmZvcm0gdG8gdGhlIGxlbmd0aAogICAgICAgIHJlcXVpcmVtZW50IG9mIDE1 IGNoYXJhY3RlcnMgb3IgZmV3ZXIuIEZvciB0aGVzZSB1bnN1aXRhYmxlICJTaG9ydAogICAg ICAgIE5hbWVzIiwgbGlzdGVkIGluIHRoZSB0YWJsZSBiZWxvdywgdGhlIHNlcnZpY2UgbmFt ZSB3aWxsIGJlIHRoZSBTaG9ydAogICAgICAgIE5hbWUgd2l0aCBhbnkgaWxsZWdhbCBjaGFy YWN0ZXJzIHJlcGxhY2VkIGJ5IGh5cGhlbnMuIElBTkEgU0hBTEwgYWRkCiAgICAgICAgYW4g ZW50cnkgdG8gdGhlIHJlZ2lzdHJ5IGdpdmluZyB0aGUgbmV3IHdlbGwtZm9ybWVkIHByaW1h cnkgc2VydmljZQogICAgICAgIG5hbWUgZm9yIHRoZSBleGlzdGluZyBzZXJ2aWNlLCB0aGF0 IG90aGVyd2lzZSBkdXBsaWNhdGVzIHRoZSBvcmlnaW5hbAogICAgICAgIGFzc2lnbm1lbnQg aW5mb3JtYXRpb24uIEluIHRoZSBkZXNjcmlwdGlvbiBmaWVsZCBvZiB0aGlzIG5ldyBlbnRy eQogICAgICAgIGdpdmluZyB0aGUgcHJpbWFyeSBzZXJ2aWNlIG5hbWUsIElBTkEgU0hBTEwg cmVjb3JkIHRoYXQgaXQgYXNzaWducyBhCiAgICAgICAgd2VsbC1mb3JtZWQgc2VydmljZSBu YW1lIGZvciB0aGUgcHJldmlvdXMgc2VydmljZSBhbmQgcmVmZXJlbmNlIHRoZQogICAgICAg IG9yaWdpbmFsIGFzc2lnbm1lbnQuIEluIHRoZSBBc3NpZ25tZW50IE5vdGVzIGZpZWxkIG9m IHRoZSBvcmlnaW5hbAogICAgICAgIGFzc2lnbm1lbnQsIElBTkEgU0hBTEwgYWRkIGEgbm90 ZSB0aGF0IHRoaXMgZW50cnkgaXMgYW4gYWxpYXMgdG8gdGhlCiAgICAgICAgbmV3IHdlbGwt Zm9ybWVkIHNlcnZpY2UgbmFtZSwgYW5kIHRoYXQgdGhlIG9sZCBzZXJ2aWNlIG5hbWUgaXMK ICAgICAgICBoaXN0b3JpYywgbm90IHVzYWJsZSBmb3IgdXNlIHdpdGggbWFueSBjb21tb24g c2VydmljZSBkaXNjb3ZlcnkKICAgICAgICBtZWNoYW5pc21zLjwvdD4KCiAgICAgICAgPHQ+ PHZzcGFjZSBibGFua0xpbmVzPSI0MiIgLz5OYW1lcyBjb250YWluaW5nIGlsbGVnYWwgY2hh cmFjdGVycyB0byBiZQogICAgICAgIHJlcGxhY2VkIGJ5IGh5cGhlbnM6PC90PgoKICAgICAg ICA8dGV4dHRhYmxlPgogICAgICAgICAgPHR0Y29sPjwvdHRjb2w+CgogICAgICAgICAgPHR0 Y29sPjwvdHRjb2w+CgogICAgICAgICAgPHR0Y29sPjwvdHRjb2w+CgogICAgICAgICAgPGM+ OTE0Yy9nPC9jPgoKICAgICAgICAgIDxjPmFjbWFpbnRfZGJkPC9jPgoKICAgICAgICAgIDxj PmFjbWFpbnRfdHJhbnNkPC9jPgoKICAgICAgICAgIDxjPmF0ZXhfZWxtZDwvYz4KCiAgICAg ICAgICA8Yz5hdmFudGlfY2RwPC9jPgoKICAgICAgICAgIDxjPmJhZG1fcHJpdjwvYz4KCiAg ICAgICAgICA8Yz5iYWRtX3B1YjwvYz4KCiAgICAgICAgICA8Yz5iZGlyX3ByaXY8L2M+Cgog ICAgICAgICAgPGM+YmRpcl9wdWI8L2M+CgogICAgICAgICAgPGM+Ym1jX2N0ZF9sZGFwPC9j PgoKICAgICAgICAgIDxjPmJtY19wYXRyb2xkYjwvYz4KCiAgICAgICAgICA8Yz5ib2tzX2Ns bnRkPC9jPgoKICAgICAgICAgIDxjPmJva3Nfc2VydmM8L2M+CgogICAgICAgICAgPGM+Ym9r c19zZXJ2bTwvYz4KCiAgICAgICAgICA8Yz5icm9rZXJfc2VydmljZTwvYz4KCiAgICAgICAg ICA8Yz5idWVzX3NlcnZpY2U8L2M+CgogICAgICAgICAgPGM+Y2FuaXRfc3RvcmU8L2M+Cgog ICAgICAgICAgPGM+Y2Vkcm9zX2ZkczwvYz4KCiAgICAgICAgICA8Yz5jbC8xPC9jPgoKICAg ICAgICAgIDxjPmNvbnRhbWFjX2ljbTwvYz4KCiAgICAgICAgICA8Yz5jb3JlbF92bmNhZG1p bjwvYz4KCiAgICAgICAgICA8Yz5jc2NfcHJveHk8L2M+CgogICAgICAgICAgPGM+Y3ZjX2hv c3RkPC9jPgoKICAgICAgICAgIDxjPmRiY29udHJvbF9hZ2VudDwvYz4KCiAgICAgICAgICA8 Yz5kZWNfZGxtPC9jPgoKICAgICAgICAgIDxjPmRsX2FnZW50PC9jPgoKICAgICAgICAgIDxj PmRvY3VtZW50dW1fczwvYz4KCiAgICAgICAgICA8Yz5kc21ldGVyX2lhdGM8L2M+CgogICAg ICAgICAgPGM+ZHN4X21vbml0b3I8L2M+CgogICAgICAgICAgPGM+ZWxwcm9fdHVubmVsPC9j PgoKICAgICAgICAgIDxjPmVsdmluX2NsaWVudDwvYz4KCiAgICAgICAgICA8Yz5lbHZpbl9z ZXJ2ZXI8L2M+CgogICAgICAgICAgPGM+ZW5jcnlwdGVkX2FkbWluPC9jPgoKICAgICAgICAg IDxjPmVydW5ib29rX2FnZW50PC9jPgoKICAgICAgICAgIDxjPmVydW5ib29rX3NlcnZlcjwv Yz4KCiAgICAgICAgICA8Yz5lc3JpX3NkZTwvYz4KCiAgICAgICAgICA8Yz5FdGhlck5ldC9J UC0xPC9jPgoKICAgICAgICAgIDxjPkV0aGVyTmV0L0lQLTI8L2M+CgogICAgICAgICAgPGM+ ZXZlbnRfbGlzdGVuZXI8L2M+CgogICAgICAgICAgPGM+ZmxyX2FnZW50PC9jPgoKICAgICAg ICAgIDxjPmdkc19kYjwvYz4KCiAgICAgICAgICA8Yz5pYm1fd3JsZXNzX2xhbjwvYz4KCiAg ICAgICAgICA8Yz5pY2VlZGNwX3J4PC9jPgoKICAgICAgICAgIDxjPmljZWVkY3BfdHg8L2M+ CgogICAgICAgICAgPGM+aWNsY25ldF9zdmluZm88L2M+CgogICAgICAgICAgPGM+aWRpZ19t dXg8L2M+CgogICAgICAgICAgPGM+aWZlX2ljb3JwPC9jPgoKICAgICAgICAgIDxjPmluc3Rs X2Jvb3RjPC9jPgoKICAgICAgICAgIDxjPmluc3RsX2Jvb3RzPC9jPgoKICAgICAgICAgIDxj PmludGVsX3JjaTwvYz4KCiAgICAgICAgICA8Yz5pbnRlcmhkbF9lbG1kPC9jPgoKICAgICAg ICAgIDxjPmxhbjkwMF9yZW1vdGU8L2M+CgogICAgICAgICAgPGM+TGllYkRldk1nbXRfQTwv Yz4KCiAgICAgICAgICA8Yz5MaWViRGV2TWdtdF9DPC9jPgoKICAgICAgICAgIDxjPkxpZWJE ZXZNZ210X0RNPC9jPgoKICAgICAgICAgIDxjPm1hcHBlci13c19ldGhkPC9jPgoKICAgICAg ICAgIDxjPm1hdHJpeF92bmV0PC9jPgoKICAgICAgICAgIDxjPm1kYnNfZGFlbW9uPC9jPgoK ICAgICAgICAgIDxjPm1lbmFuZG1pY2Vfbm9oPC9jPgoKICAgICAgICAgIDxjPm1zbF9sbWQ8 L2M+CgogICAgICAgICAgPGM+bmJ1cm5faWQ8L2M+CgogICAgICAgICAgPGM+bmNyX2NjbDwv Yz4KCiAgICAgICAgICA8Yz5uZHNfc3NvPC9jPgoKICAgICAgICAgIDxjPm5ldG1hcF9sbTwv Yz4KCiAgICAgICAgICA8Yz5ubXNfdG9wb19zZXJ2PC9jPgoKICAgICAgICAgIDxjPm5vdGlm eV9zcnZyPC9jPgoKICAgICAgICAgIDxjPm5vdmVsbC1sdTYuMjwvYz4KCiAgICAgICAgICA8 Yz5udXRzX2Jvb3RwPC9jPgoKICAgICAgICAgIDxjPm51dHNfZGVtPC9jPgoKICAgICAgICAg IDxjPm9jc19hbXU8L2M+CgogICAgICAgICAgPGM+b2NzX2NtdTwvYz4KCiAgICAgICAgICA8 Yz5waXBlX3NlcnZlcjwvYz4KCiAgICAgICAgICA8Yz5wcmFfZWxtZDwvYz4KCiAgICAgICAg ICA8Yz5wcmludGVyX2FnZW50PC9jPgoKICAgICAgICAgIDxjPnJlZHN0b3JtX2RpYWc8L2M+ CgogICAgICAgICAgPGM+cmVkc3Rvcm1fZmluZDwvYz4KCiAgICAgICAgICA8Yz5yZWRzdG9y bV9pbmZvPC9jPgoKICAgICAgICAgIDxjPnJlZHN0b3JtX2pvaW48L2M+CgogICAgICAgICAg PGM+cmVzb3VyY2VfbWdyPC9jPgoKICAgICAgICAgIDxjPnJtb25pdG9yX3NlY3VyZTwvYz4K CiAgICAgICAgICA8Yz5yc3ZwX3R1bm5lbDwvYz4KCiAgICAgICAgICA8Yz5zYWlfc2VudGxt PC9jPgoKICAgICAgICAgIDxjPnNnZV9leGVjZDwvYz4KCiAgICAgICAgICA8Yz5zZ2VfcW1h c3RlcjwvYz4KCiAgICAgICAgICA8Yz5zaGl2YV9jb25mc3J2cjwvYz4KCiAgICAgICAgICA8 Yz5zcWwqbmV0PC9jPgoKICAgICAgICAgIDxjPnNydmNfcmVnaXN0cnk8L2M+CgogICAgICAg ICAgPGM+c3RtX3Bwcm9jPC9jPgoKICAgICAgICAgIDxjPnN1Ym50YmNzdF90ZnRwPC9jPgoK ICAgICAgICAgIDxjPnVkdF9vczwvYz4KCiAgICAgICAgICA8Yz51bml2ZXJzZV9zdWl0ZTwv Yz4KCiAgICAgICAgICA8Yz52ZXJpdGFzX3BieDwvYz4KCiAgICAgICAgICA8Yz52aXNpb25f ZWxtZDwvYz4KCiAgICAgICAgICA8Yz52aXNpb25fc2VydmVyPC9jPgoKICAgICAgICAgIDxj Pndyc19yZWdpc3RyeTwvYz4KCiAgICAgICAgICA8Yz56MzkuNTA8L2M+CiAgICAgICAgPC90 ZXh0dGFibGU+CgogICAgICAgIDx0PkZvbGxvd2luZyB0aGUgZXhhbXBsZSBzZXQgYnkgdGhl ICJhcHBsaWNhdGlvbi93aG9pc3BwLXF1ZXJ5IiBNSU1FCiAgICAgICAgQ29udGVudC1UeXBl IDx4cmVmIHRhcmdldD0iUkZDMjk1NyI+PC94cmVmPiwgdGhlIHNlcnZpY2UgbmFtZSBmb3IK ICAgICAgICAid2hvaXMrKyIgd2lsbCBiZSAid2hvaXNwcCIuPC90PgogICAgICA8L3NlY3Rp b24+CgogICAgICA8c2VjdGlvbiBhbmNob3I9InNjdHBkY2NwZXhwIgogICAgICAgICAgICAg ICB0aXRsZT0iUG9ydCBOdW1iZXJzIGZvciBTQ1RQIGFuZCBEQ0NQIEV4cGVyaW1lbnRhdGlv biI+CiAgICAgICAgPHQ+VHdvIFN5c3RlbSBVRFAgYW5kIFRDUCBwb3J0cywgMTAyMSBhbmQg MTAyMiwgaGF2ZSBiZWVuIHJlc2VydmVkIGZvcgogICAgICAgIGV4cGVyaW1lbnRhbCB1c2Ug PHhyZWYgdGFyZ2V0PSJSRkM0NzI3Ij48L3hyZWY+LiBUaGlzIGRvY3VtZW50IGFzc2lnbnMK ICAgICAgICB0aGUgc2FtZSBwb3J0IG51bWJlcnMgZm9yIFNDVFAgYW5kIERDQ1AsIHVwZGF0 ZXMgdGhlIFRDUCBhbmQgVURQCiAgICAgICAgcmVnaXN0cmF0aW9ucywgYW5kIGFsc28gaW5z dHJ1Y3RzIElBTkEgdG8gYXV0b21hdGljYWxseSBhc3NpZ24gdGhlc2UKICAgICAgICB0d28g cG9ydCBudW1iZXJzIGZvciBhbnkgZnV0dXJlIHRyYW5zcG9ydCBwcm90b2NvbCB3aXRoIGEg c2ltaWxhcgogICAgICAgIHNpeHRlZW4tYml0IHBvcnQgbnVtYmVyIG5hbWVzcGFjZS48L3Q+ CgogICAgICAgIDx0Pk5vdGUgdGhhdCB0aGVzZSBwb3J0IG51bWJlcnMgYXJlIG1lYW50IGZv ciB0ZW1wb3JhcnkKICAgICAgICBleHBlcmltZW50YXRpb24gYW5kIGRldmVsb3BtZW50IGlu IGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzLiBCZWZvcmUKICAgICAgICB1c2luZyB0aGVzZSBw b3J0IG51bWJlcnMsIGNhcmVmdWxseSBjb25zaWRlciB0aGUgYWR2aWNlIGluIDx4cmVmCiAg ICAgICAgdGFyZ2V0PSJ1ZHB0Y3BleHAiPjwveHJlZj4gaW4gdGhpcyBkb2N1bWVudCwgYXMg d2VsbCBhcyBpbiBTZWN0aW9ucyAxCiAgICAgICAgYW5kIDEuMSBvZiAiQXNzaWduaW5nIEV4 cGVyaW1lbnRhbCBhbmQgVGVzdGluZyBOdW1iZXJzIENvbnNpZGVyZWQKICAgICAgICBVc2Vm dWwiIDx4cmVmIHRhcmdldD0iUkZDMzY5MiI+PC94cmVmPi4gTW9zdCBpbXBvcnRhbnRseSwg YXBwbGljYXRpb24KICAgICAgICBkZXZlbG9wZXJzIG11c3QgcmVxdWVzdCBhIHBlcm1hbmVu dCBwb3J0IG51bWJlciBhc3NpZ25tZW50IGZyb20gSUFOQQogICAgICAgIGFzIGRlc2NyaWJl ZCBpbiA8eHJlZiB0YXJnZXQ9InJlZ2lzdHJhdGlvbiI+PC94cmVmPiBiZWZvcmUgYW55IGtp bmQgb2YKICAgICAgICBub24tZXhwZXJpbWVudGFsIGRlcGxveW1lbnQuPC90PgoKICAgICAg ICA8dGV4dHRhYmxlPgogICAgICAgICAgPHR0Y29sPjwvdHRjb2w+CgogICAgICAgICAgPHR0 Y29sPjwvdHRjb2w+CgogICAgICAgICAgPGM+UmVnaXN0cmFudDwvYz4KCiAgICAgICAgICA8 Yz5JRVRGICZsdDtpZXNnQGlldGYub3JnJmd0OzwvYz4KCiAgICAgICAgICA8Yz5Db250YWN0 PC9jPgoKICAgICAgICAgIDxjPklFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7PC9jPgoKICAg ICAgICAgIDxjPlNlcnZpY2UgTmFtZTwvYz4KCiAgICAgICAgICA8Yz5leHAxPC9jPgoKICAg ICAgICAgIDxjPlBvcnQgTnVtYmVyPC9jPgoKICAgICAgICAgIDxjPjEwMjE8L2M+CgogICAg ICAgICAgPGM+VHJhbnNwb3J0IFByb3RvY29sPC9jPgoKICAgICAgICAgIDxjPkRDQ1AsIFND VFAsIFRDUCwgVURQPC9jPgoKICAgICAgICAgIDxjPkRlc2NyaXB0aW9uPC9jPgoKICAgICAg ICAgIDxjPlJGQzM2OTItc3R5bGUgRXhwZXJpbWVudCAxPC9jPgoKICAgICAgICAgIDxjPlJl ZmVyZW5jZTwvYz4KCiAgICAgICAgICA8Yz5bUkZDeXl5eV0sUkZDIDQ3MjddPC9jPgogICAg ICAgIDwvdGV4dHRhYmxlPgoKICAgICAgICA8dGV4dHRhYmxlPgogICAgICAgICAgPHR0Y29s PjwvdHRjb2w+CgogICAgICAgICAgPHR0Y29sPjwvdHRjb2w+CgogICAgICAgICAgPGM+UmVn aXN0cmFudDwvYz4KCiAgICAgICAgICA8Yz5JRVRGICZsdDtpZXNnQGlldGYub3JnJmd0Ozwv Yz4KCiAgICAgICAgICA8Yz5Db250YWN0PC9jPgoKICAgICAgICAgIDxjPklFU0cgJmx0O2ll c2dAaWV0Zi5vcmcmZ3Q7PC9jPgoKICAgICAgICAgIDxjPlNlcnZpY2UgTmFtZTwvYz4KCiAg ICAgICAgICA8Yz5leHAyPC9jPgoKICAgICAgICAgIDxjPlBvcnQgTnVtYmVyPC9jPgoKICAg ICAgICAgIDxjPjEwMjI8L2M+CgogICAgICAgICAgPGM+VHJhbnNwb3J0IFByb3RvY29sPC9j PgoKICAgICAgICAgIDxjPkRDQ1AsIFNDVFAsIFRDUCwgVURQPC9jPgoKICAgICAgICAgIDxj PkRlc2NyaXB0aW9uPC9jPgoKICAgICAgICAgIDxjPlJGQzM2OTItc3R5bGUgRXhwZXJpbWVu dCAyPC9jPgoKICAgICAgICAgIDxjPlJlZmVyZW5jZTwvYz4KCiAgICAgICAgICA8Yz5bUkZD eXl5eV0sIFtSRkM0NzI3XTwvYz4KICAgICAgICA8L3RleHR0YWJsZT4KCiAgICAgICAgPHQ+ W1JGQyBFZGl0b3IgTm90ZTogUGxlYXNlIGNoYW5nZSAieXl5eSIgdG8gdGhlIFJGQyBudW1i ZXIgYWxsb2NhdGVkCiAgICAgICAgdG8gdGhpcyBkb2N1bWVudCBiZWZvcmUgcHVibGljYXRp b24uXTwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJkY2Nw IiB0aXRsZT0iVXBkYXRlcyB0byBEQ0NQIFJlZ2lzdHJpZXMiPgogICAgICAgIDx0PlRoaXMg ZG9jdW1lbnQgdXBkYXRlcyB0aGUgSUFOQSBhbGxvY2F0aW9uIHByb2NlZHVyZXMgZm9yIHRo ZSBEQ0NQCiAgICAgICAgUG9ydCBOdW1iZXIgYW5kIERDQ1AgU2VydmljZSBDb2RlcyBSZWdp c3RyaWVzIDx4cmVmCiAgICAgICAgdGFyZ2V0PSJSRkM0MzQwIj48L3hyZWY+LjwvdD4KCiAg ICAgICAgPHNlY3Rpb24gdGl0bGU9IkRDQ1AgU2VydmljZSBDb2RlIFJlZ2lzdHJ5Ij4KICAg ICAgICAgIDx0PlNlcnZpY2UgQ29kZXMgYXJlIGFsbG9jYXRlZCBmaXJzdC1jb21lLWZpcnN0 LXNlcnZlZCBhY2NvcmRpbmcgdG8KICAgICAgICAgIFNlY3Rpb24gMTkuOCBvZiB0aGUgREND UCBzcGVjaWZpY2F0aW9uIDx4cmVmCiAgICAgICAgICB0YXJnZXQ9IlJGQzQzNDAiPjwveHJl Zj4uIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGF0IHNlY3Rpb24gYnkKICAgICAgICAgIGV4 dGVuZGluZyB0aGUgZ3VpZGVsaW5lcyBnaXZlbiB0aGVyZSBpbiB0aGUgZm9sbG93aW5nIHdh eXM6PC90PgoKICAgICAgICAgIDx0PjxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAg ICAgICA8dD5JQU5BIE1BWSBhc3NpZ24gbmV3IFNlcnZpY2UgQ29kZXMgd2l0aG91dCBzZWVr aW5nIEV4cGVydAogICAgICAgICAgICAgIFJldmlldyB1c2luZyB0aGVpciBkaXNjcmV0aW9u LCBidXQgU0hPVUxEIHNlZWsgZXhwZXJ0IHJldmlldyBpZgogICAgICAgICAgICAgIGEgcmVx dWVzdCBzZWVrcyBtb3JlIHRoYW4gZml2ZSBTZXJ2aWNlIENvZGVzLjwvdD4KCiAgICAgICAg ICAgICAgPHQ+SUFOQSBzaG91bGQgZmVlbCBmcmVlIHRvIGNvbnRhY3QgdGhlIERDQ1AgRXhw ZXJ0IFJldmlld2VyCiAgICAgICAgICAgICAgd2l0aCBxdWVzdGlvbnMgb24gYW55IHJlZ2lz dHJ5LCByZWdhcmRsZXNzIG9mIHRoZSByZWdpc3RyeQogICAgICAgICAgICAgIHBvbGljeSwg Zm9yIGNsYXJpZmljYXRpb24gb3IgaWYgdGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggYQogICAg ICAgICAgICAgIHJlcXVlc3QgPHhyZWYgdGFyZ2V0PSJSRkM0MzQwIj48L3hyZWY+LjwvdD4K ICAgICAgICAgICAgPC9saXN0PjwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxz ZWN0aW9uIHRpdGxlPSJEQ0NQIFBvcnQgTnVtYmVycyBSZWdpc3RyeSI+CiAgICAgICAgICA8 dD5UaGUgRENDUCBwb3J0cyByZWdpc3RyeSBpcyBkZWZpbmVkIGJ5IFNlY3Rpb24gMTkuOSBv ZiB0aGUgRENDUAogICAgICAgICAgc3BlY2lmaWNhdGlvbiA8eHJlZiB0YXJnZXQ9IlJGQzQz NDAiPjwveHJlZj4uIEFsbG9jYXRpb25zIGluIHRoaXMKICAgICAgICAgIHJlZ2lzdHJ5IHJl cXVpcmUgcHJpb3IgYWxsb2NhdGlvbiBvZiBhIFNlcnZpY2UgQ29kZS4gTm90IGFsbCBTZXJ2 aWNlCiAgICAgICAgICBDb2RlcyByZXF1aXJlIElBTkEtYXNzaWduZWQgcG9ydHMuIFRoaXMg ZG9jdW1lbnQgdXBkYXRlcyB0aGF0CiAgICAgICAgICBzZWN0aW9uIGJ5IGV4dGVuZGluZyB0 aGUgZ3VpZGVsaW5lcyBnaXZlbiB0aGVyZSBpbiB0aGUgZm9sbG93aW5nCiAgICAgICAgICB3 YXk6PC90PgoKICAgICAgICAgIDx0PjxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAg ICAgICA8dD5JQU5BIHNob3VsZCBub3JtYWxseSBhc3NpZ24gYSB2YWx1ZSBpbiB0aGUgcmFu Z2UgMTAyNC00OTE1MQogICAgICAgICAgICAgIHRvIGEgRENDUCBzZXJ2ZXIgcG9ydC4gSUFO QSBhbGxvY2F0aW9uIHJlcXVlc3RzIHRvIGFsbG9jYXRlIHBvcnQKICAgICAgICAgICAgICBu dW1iZXJzIGluIHRoZSBTeXN0ZW0gUG9ydHMgcmFuZ2UgKDAgdGhyb3VnaCAxMDIzKSwgcmVx dWlyZSBhbgogICAgICAgICAgICAgICJJRVRGIFJldmlldyIgPHhyZWYgdGFyZ2V0PSJSRkM1 MjI2Ij48L3hyZWY+IHByaW9yIHRvIGFsbG9jYXRpb24KICAgICAgICAgICAgICBieSBJQU5B IDx4cmVmIHRhcmdldD0iUkZDNDM0MCI+PC94cmVmPi48L3Q+CgogICAgICAgICAgICAgIDx0 PklBTkEgTVVTVCBOT1QgYWxsb2NhdGUgbW9yZSB0aGFuIG9uZSBEQ0NQIHNlcnZlciBwb3J0 IHRvIGEKICAgICAgICAgICAgICBzaW5nbGUgc2VydmljZSBjb2RlIHZhbHVlLjwvdD4KCiAg ICAgICAgICAgICAgPHQ+VGhlIGFsbG9jYXRpb24gb2YgbXVsdGlwbGUgc2VydmljZSBjb2Rl cyB0byB0aGUgc2FtZSBEQ0NQCiAgICAgICAgICAgICAgcG9ydCBpcyBhbGxvd2VkLCBidXQg c3ViamVjdCB0byBleHBlcnQgcmV2aWV3LjwvdD4KCiAgICAgICAgICAgICAgPHQ+VGhlIHNl dCBvZiBTZXJ2aWNlIENvZGUgdmFsdWVzIGFzc29jaWF0ZWQgd2l0aCBhIERDQ1Agc2VydmVy CiAgICAgICAgICAgICAgcG9ydCBzaG91bGQgYmUgcmVjb3JkZWQgaW4gdGhlIHNlcnZpY2Ug bmFtZSBhbmQgcG9ydCBudW1iZXIKICAgICAgICAgICAgICByZWdpc3RyeS48L3Q+CgogICAg ICAgICAgICAgIDx0PkEgcmVxdWVzdCBmb3IgYWRkaXRpb25hbCBTZXJ2aWNlIENvZGVzIHRv IGJlIGFzc29jaWF0ZWQgd2l0aAogICAgICAgICAgICAgIGFuIGFscmVhZHkgYWxsb2NhdGVk IFBvcnQgTnVtYmVyIHJlcXVpcmVzIEV4cGVydCBSZXZpZXcuIFRoZXNlCiAgICAgICAgICAg ICAgcmVxdWVzdHMgd2lsbCBub3JtYWxseSBiZSBhY2NlcHRlZCB3aGVuIHRoZXkgb3JpZ2lu YXRlIGZyb20gdGhlCiAgICAgICAgICAgICAgY29udGFjdCBhc3NvY2lhdGVkIHdpdGggdGhl IHBvcnQgcmVnaXN0cmF0aW9uLiBJbiBvdGhlciBjYXNlcywKICAgICAgICAgICAgICB0aGVz ZSBhcHBsaWNhdGlvbnMgd2lsbCBiZSBleHBlY3RlZCB0byB1c2UgYW4gdW5hbGxvY2F0ZWQg cG9ydCwKICAgICAgICAgICAgICB3aGVuIHRoaXMgaXMgYXZhaWxhYmxlLjwvdD4KICAgICAg ICAgICAgPC9saXN0PjwvdD4KCiAgICAgICAgICA8dD5UaGUgRENDUCBzcGVjaWZpY2F0aW9u IDx4cmVmIHRhcmdldD0iUkZDNDM0MCI+PC94cmVmPiBub3RlcyB0aGF0CiAgICAgICAgICBh IHNob3J0IHBvcnQgbmFtZSBNVVNUIGJlIGFzc29jaWF0ZWQgd2l0aCBlYWNoIERDQ1Agc2Vy dmVyIHBvcnQgdGhhdAogICAgICAgICAgaGFzIGJlZW4gYXNzaWduZWQuIFRoaXMgZG9jdW1l bnQgY2xhcmlmaWVzIHRoYXQgdGhpcyBzaG9ydCBwb3J0IG5hbWUKICAgICAgICAgIGlzIHRo ZSBTZXJ2aWNlIE5hbWUgYXMgZGVmaW5lZCBoZXJlLCBhbmQgdGhpcyBuYW1lIE1VU1QgYmUK ICAgICAgICAgIHVuaXF1ZS48L3Q+CiAgICAgICAgPC9zZWN0aW9uPgogICAgICA8L3NlY3Rp b24+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMtY29udHJpYnV0 b3JzIiB0aXRsZT0iQ29udHJpYnV0b3JzIj4KICAgICAgPHQ+QWxmcmVkIEhvZW5lcyAoYWhA dHItc3lzLmRlKSBhbmQgQWxsaXNvbiBNYW5raW4gKG1hbmtpbkBwc2cuY29tKSBoYXZlCiAg ICAgIGNvbnRyaWJ1dGVkIHRleHQgYW5kIGlkZWFzIHRvIHRoaXMgZG9jdW1lbnQuPC90Pgog ICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0iYWNrIiB0aXRsZT0iQWNrbm93 bGVkZ21lbnRzIj4KICAgICAgPHQ+VGhlIHRleHQgaW4gPHhyZWYgdGFyZ2V0PSJkY2NwIj48 L3hyZWY+IGlzIGJhc2VkIG9uIGEgc3VnZ2VzdGlvbgogICAgICBvcmlnaW5hbGx5IHByb3Bv c2VkIGFzIGEgcGFydCBvZiB0aGUgRENDUCBTZXJ2aWNlIENvZGVzIGRvY3VtZW50PHhyZWYK ICAgICAgdGFyZ2V0PSJSRkM1NTk1Ij48L3hyZWY+IGJ5IEdvcnJ5IEZhaXJodXJzdC48L3Q+ CgogICAgICA8dD5MYXJzIEVnZ2VydCBpcyBwYXJ0bHkgZnVuZGVkIGJ5IHRoZSBUcmlsb2d5 IFByb2plY3QgPHhyZWYKICAgICAgdGFyZ2V0PSJUUklMT0dZIj48L3hyZWY+LCBhIHJlc2Vh cmNoIHByb2plY3Qgc3VwcG9ydGVkIGJ5IHRoZSBFdXJvcGVhbgogICAgICBDb21taXNzaW9u IHVuZGVyIGl0cyBTZXZlbnRoIEZyYW1ld29yayBQcm9ncmFtLjwvdD4KICAgIDwvc2VjdGlv bj4KICA8L21pZGRsZT4KCiAgPCEtLSBSRUZFUkVOQ0UgVEVNUExBVEUKICAgICA8cmVmZXJl bmNlIGFuY2hvcj0icmVmZXJlbmNlLlhYWCI+CiAgICAgICAgICAgICA8ZnJvbnQ+CgogICAg ICAgICAgICAgICAgICAgICA8dGl0bGU+WFhYPC90aXRsZT4KICAgICAgICAgICAgICAgICAg ICAgPGF1dGhvciBpbml0aWFscz0iWC4iIHN1cm5hbWU9IlhYWCIgZnVsbG5hbWU9IlhYWCI+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG9yZ2FuaXphdGlvbiBhYmJyZXY9IlhY WCI+WFhYPC9vcmdhbml6YXRpb24+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGFk ZHJlc3M+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cG9zdGFsPgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3RyZWV0PlhY WDwvc3RyZWV0PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8Y2l0eT5YWFg8L2NpdHk+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxyZWdpb24+WFhYPC9yZWdpb24+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxjb2RlPlhYWDwvY29kZT4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGNvdW50cnk+WFhYPC9jb3VudHJ5Pgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9wb3N0YWw+CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cGhvbmU+WFhYPC9waG9uZT4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxmYWNzaW1pbGU+WFhYPC9mYWNzaW1p bGU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZW1haWw+WFhYPC9l bWFpbD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx1cmk+WFhYPC91 cmk+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9hZGRyZXNzPgoKICAgICAgICAg ICAgICAgICAgICAgPC9hdXRob3I+CiAgICAgICAgICAgICAgICAgICAgIDxkYXRlIG1vbnRo PSJYWFgiIHllYXI9IlhYWCIvPgogICAgICAgICAgICAgPC9mcm9udD4KICAgICAgICAgICAg IDxzZXJpZXNJbmZvIG5hbWU9IlhYWCIgdmFsdWU9IlhYWCIvPgogICAgICAgICAgICAgPGZv cm1hdCB0eXBlPSJYWFgiIHRhcmdldD0iWFhYIi8+CiAgICAgPC9yZWZlcmVuY2U+CiAgICAg LS0+CgogIDxiYWNrPgogICAgPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBSZWZlcmVu Y2VzIj4KICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4wNzY4IiA/PgoKICAg ICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4wNzkzIiA/PgoKICAgICAgPD9yZmMg aW5jbHVkZT0icmVmZXJlbmNlLlJGQy4yMTE5IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0i cmVmZXJlbmNlLlJGQy4yNzgwIiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNl LlJGQy4zODI4IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy40MDIw IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy40MzQwIiA/PgoKICAg ICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy40NzI3IiA/PgoKICAgICAgPD9yZmMg aW5jbHVkZT0icmVmZXJlbmNlLlJGQy41MjI2IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0i cmVmZXJlbmNlLlJGQy41MjM0IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNl LkFOU0kuWDMtNC4xOTg2IiA/PgogICAgPC9yZWZlcmVuY2VzPgoKICAgIDxyZWZlcmVuY2Vz IHRpdGxlPSJJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIj4KICAgICAgPD9yZmMgaW5jbHVkZT0i cmVmZXJlbmNlLlJGQy4wOTU5IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNl LlJGQy4xMDc4IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4xNzAw IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4yNzgyIiA/PgoKICAg ICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4yOTU3IiA/PgoKICAgICAgPD9yZmMg aW5jbHVkZT0icmVmZXJlbmNlLlJGQy4zMjMyIiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0i cmVmZXJlbmNlLlJGQy4zNjkyIiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNl LlJGQy40MzQyIiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy40OTYw IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy41MjM3IiA/PgoKICAg ICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy41NTk1IiA/PgoKICAgICAgPD9yZmMg aW5jbHVkZT0icmVmZXJlbmNlLlJGQy41NzY2IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0i cmVmZXJlbmNlLlJGQy41Mzg5IiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNl LkktRC5jaGVzaGlyZS1kbnNleHQtZG5zLXNkIiA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0i cmVmZXJlbmNlLkktRC5jaGVzaGlyZS1uYXQtcG1wIiA/PgoKICAgICAgPCEtLSAgICAgIDw/ cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5JLUQuZ3VkbXVuZHNzb24tZG5zZXh0LXNydi1jbGFy aWZ5IiA/PiAtLT4KCiAgICAgIDwhLS0KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkktRC50 b3VjaC10c3Z3Zy1wb3J0LWd1aWRlbGluZXMiPgogICAgICAgPGZyb250PgoKICAgICAgICAg PHRpdGxlPkd1aWRlbGluZXMgZm9yIFRyYW5zcG9ydCBQb3J0IFVzZTwvdGl0bGU+CiAgICAg ICAgIDxhdXRob3IgZnVsbG5hbWU9IkpvZSBUb3VjaCIgaW5pdGlhbHM9IkoiIHN1cm5hbWU9 IlRvdWNoIj4KICAgICAgICAgICA8b3JnYW5pemF0aW9uPjwvb3JnYW5pemF0aW9uPgogICAg ICAgICA8L2F1dGhvcj4KICAgICAgIDwvZnJvbnQ+CiAgICAgICA8c2VyaWVzSW5mbyBuYW1l PSIiIHZhbHVlPSJDdXJyZW50bHkgVW5wdWJsaXNoZWQiLz4KICAgICAgPC9yZWZlcmVuY2U+ CiAgICAgIC0tPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlNZU0ZPUk0iPgogICAgICAg IDxmcm9udD4KICAgICAgICAgIDx0aXRsZT5BcHBsaWNhdGlvbiBmb3IgU3lzdGVtIChXZWxs IEtub3duKSBQb3J0IE51bWJlcjwvdGl0bGU+CgogICAgICAgICAgPGF1dGhvciBzdXJuYW1l PSJJbnRlcm5ldCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSAoSUFOQSkiPgogICAgICAg ICAgICA8b3JnYW5pemF0aW9uIC8+CiAgICAgICAgICA8L2F1dGhvcj4KICAgICAgICA8L2Zy b250PgoKICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSIiCiAgICAgICAgICAgICAgICAgICAg dmFsdWU9Imh0dHA6Ly93d3cuaWFuYS5vcmcvY2dpLWJpbi9zeXMtcG9ydC1udW1iZXIucGwi IC8+CiAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlVTUkZP Uk0iPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0aXRsZT5BcHBsaWNhdGlvbiBmb3Ig VXNlciAoUmVnaXN0ZXJlZCkgUG9ydCBOdW1iZXI8L3RpdGxlPgoKICAgICAgICAgIDxhdXRo b3Igc3VybmFtZT0iSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKElBTkEp Ij4KICAgICAgICAgICAgPG9yZ2FuaXphdGlvbiAvPgogICAgICAgICAgPC9hdXRob3I+CiAg ICAgICAgPC9mcm9udD4KCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iIgogICAgICAgICAg ICAgICAgICAgIHZhbHVlPSJodHRwOi8vd3d3LmlhbmEub3JnL2NnaS1iaW4vdXNyLXBvcnQt bnVtYmVyLnBsIiAvPgogICAgICA8L3JlZmVyZW5jZT4KCiAgICAgIDxyZWZlcmVuY2UgYW5j aG9yPSJQT1JUUkVHIj4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+U2Vydmlj ZSBOYW1lIGFuZCBUcmFuc3BvcnQgUHJvdG9jb2wgUG9ydCBOdW1iZXIKICAgICAgICAgIFJl Z2lzdHJ5PC90aXRsZT4KCiAgICAgICAgICA8YXV0aG9yIHN1cm5hbWU9IkludGVybmV0IEFz c2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IChJQU5BKSI+CiAgICAgICAgICAgIDxvcmdhbml6 YXRpb24gLz4KICAgICAgICAgIDwvYXV0aG9yPgogICAgICAgIDwvZnJvbnQ+CgogICAgICAg IDxzZXJpZXNJbmZvIG5hbWU9IiIKICAgICAgICAgICAgICAgICAgICB2YWx1ZT0iaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9wb3J0LW51bWJlcnMiIC8+CiAgICAgIDwvcmVm ZXJlbmNlPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlBST1RTRVJWUkVHIj4KICAgICAg ICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+UHJvdG9jb2wgYW5kIFNlcnZpY2UgTmFtZXMg UmVnaXN0cnk8L3RpdGxlPgoKICAgICAgICAgIDxhdXRob3Igc3VybmFtZT0iSW50ZXJuZXQg QXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIj4KICAgICAgICAgICAgPG9yZ2Fu aXphdGlvbiAvPgogICAgICAgICAgPC9hdXRob3I+CiAgICAgICAgPC9mcm9udD4KCiAgICAg ICAgPHNlcmllc0luZm8gbmFtZT0iIgogICAgICAgICAgICAgICAgICAgIHZhbHVlPSJodHRw Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NlcnZpY2UtbmFtZXMiIC8+CiAgICAgIDwv cmVmZXJlbmNlPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlNSVlJFRyI+CiAgICAgICAg PGZyb250PgogICAgICAgICAgPHRpdGxlPkROUyBTUlYgU2VydmljZSBUeXBlcyBSZWdpc3Ry eTwvdGl0bGU+CgogICAgICAgICAgPGF1dGhvciBzdXJuYW1lPSIiPgogICAgICAgICAgICA8 b3JnYW5pemF0aW9uIC8+CiAgICAgICAgICA8L2F1dGhvcj4KICAgICAgICA8L2Zyb250PgoK ICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSIiIHZhbHVlPSJodHRwOi8vd3d3LmRucy1zZC5v cmcvU2VydmljZVR5cGVzLmh0bWwiIC8+CiAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAgPHJl ZmVyZW5jZSBhbmNob3I9IlRSSUxPR1kiPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0 aXRsZT5Ucmlsb2d5IFByb2plY3Q8L3RpdGxlPgoKICAgICAgICAgIDxhdXRob3I+CiAgICAg ICAgICAgIDxvcmdhbml6YXRpb24gLz4KICAgICAgICAgIDwvYXV0aG9yPgogICAgICAgIDwv ZnJvbnQ+CgogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IiIgdmFsdWU9Imh0dHA6Ly93d3cu dHJpbG9neS1wcm9qZWN0Lm9yZy8iIC8+CiAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAgPCEt LQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iQ1VQUyIgdGFyZ2V0PSJodHRwOi8vd3d3LmN1 cHMub3JnLyI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPkNvbW1vbiBVbml4 IFByaW50aW5nIFN5c3RlbTwvdGl0bGU+CiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSIi IGluaXRpYWxzPSIiIHN1cm5hbWU9IiI+CiAgICAgICAgICAgIDxvcmdhbml6YXRpb24vPgog ICAgICAgICAgPC9hdXRob3I+CiAgICAgICAgPC9mcm9udD4KICAgICAgPC9yZWZlcmVuY2U+ Ci0tPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IklHRCI+CiAgICAgICAgPGZyb250Pgog ICAgICAgICAgPHRpdGxlPkludGVybmV0IEdhdGV3YXkgRGV2aWNlIChJR0QpIFYgMS4wPC90 aXRsZT4KCiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJVUG5QIEZvcnVtIj4KICAgICAg ICAgICAgPG9yZ2FuaXphdGlvbj5VUG5QIEZvcnVtPC9vcmdhbml6YXRpb24+CiAgICAgICAg ICA8L2F1dGhvcj4KCiAgICAgICAgICA8ZGF0ZSBkYXk9IjEyIiBtb250aD0iTm92ZW1iZXIi IHllYXI9IjIwMDEiIC8+CiAgICAgICAgPC9mcm9udD4KICAgICAgPC9yZWZlcmVuY2U+CiAg ICA8L3JlZmVyZW5jZXM+CiAgPC9iYWNrPgo8L3JmYz4= --------------020408010807070403010505-- From cheshire@apple.com Mon Sep 20 21:08:36 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A063A691C for ; Mon, 20 Sep 2010 21:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 S0M8CMOPts9E for ; Mon, 20 Sep 2010 21:08:35 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4444D3A6922 for ; Mon, 20 Sep 2010 21:08:32 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 0F3D5AA11670; Mon, 20 Sep 2010 21:08:56 -0700 (PDT) X-AuditID: 11807130-b7cf8ae0000058d2-98-4c982fd7a1e4 Received: from [17.202.46.71] (chesh1.apple.com [17.202.46.71]) by relay11.apple.com (Apple SCV relay) with SMTP id 09.C7.22738.8DF289C4; Mon, 20 Sep 2010 21:08:56 -0700 (PDT) In-Reply-To: <4C924978.4010602@isi.edu> References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> <4C924978.4010602@isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DF309EA-4D18-4D5D-BBF0-9665719BE901@apple.com> Content-Transfer-Encoding: 7bit From: Stuart Cheshire Date: Mon, 20 Sep 2010 21:08:28 -0700 To: Joe Touch X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 04:08:36 -0000 On 16 Sep, 2010, at 09:44, Joe Touch wrote: > Any time more than one string maps to the same port number it's a > kind of an 'alias'. The only way for the client to know the > difference is via in-band information. > > I.e., we would allow aliases for: > - different services > - that can be resolved in-band > > Unless BOTH of those apply, we would not allow aliases except: > > a) legacy (www, http) > b) to support changeover to the new namespace > > Joe I think we agree on the concept, but the terminology previously confused me. When you said, "alias," I read that as meaning, "different names for the same service." Now I see that when you say, "alias," you mean, "different services on the same port." (I'd call that a "collision", except in the special case of a new service which is a compatible extension to an old one on the same port.) Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From lars.eggert@nokia.com Mon Sep 20 23:11:10 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45B03A691D for ; Mon, 20 Sep 2010 23:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.334 X-Spam-Level: X-Spam-Status: No, score=-103.334 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8rRMHWkxOUXE for ; Mon, 20 Sep 2010 23:11:04 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 2F19B3A6929 for ; Mon, 20 Sep 2010 23:11:03 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8L6BQlD004035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Sep 2010 09:11:26 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-4--347880719; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4C97DE60.6090601@isi.edu> Date: Tue, 21 Sep 2010 09:11:20 +0300 Message-Id: <05A766B1-A4C8-4926-97C2-0DC3DFAF251C@nokia.com> References: <4C924866.2090707@isi.edu> <0D80A77F-A8CA-4F40-A27C-D011FD9096ED@nokia.com> <4C93D99C.5030503@isi.edu> <4C97DE60.6090601@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 21 Sep 2010 09:11:20 +0300 (EEST) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] almost good to go X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 06:11:10 -0000 --Apple-Mail-4--347880719 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2010-9-21, at 1:21, Joe Touch wrote: > Attached is an update that Committed to svn as rev 70. Lars --Apple-Mail-4--347880719 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyMTA2 MTEyMVowIwYJKoZIhvcNAQkEMRYEFKjlvY7Om3AFUrm3uYYeeKlGjnYEMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAAdgNECYRiSPwWEeW67KBNl9hRs7EB+kevdIIFAu28AHL0FC59je RKz9cUkl+53/XkZOO7MHNt2kcDF41ZISpeUQ8qnWWF9wDphxjHahcI/0e3siBHdG3Wk9GXZBiFzh yA24sVGWEHlC9rp/WmXnubIMkGYXbgDhVZvYTt/TiO/SXzaB8NkkqWVWDGTx4muGmNjcB+eFQFVj fAup+pf/NKwD2XG6ZN0DbUKQxEzP+ZGuR129niwvCmdN0umVK7aXU9cC5KZy/23AgQjkT6SLFL/p 3VgvZil3EPQ4vpaGgAl0B90jdVjAE5BNHz4bSx9yaIpQSZUWYCMyG+iAP5JkZtoAAAAAAAA= --Apple-Mail-4--347880719-- From touch@isi.edu Tue Sep 21 07:04:52 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09533A69F6 for ; Tue, 21 Sep 2010 07:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 kfShjR49xe8o for ; Tue, 21 Sep 2010 07:04:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9507B3A681D for ; Tue, 21 Sep 2010 07:04:50 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8LE48jn028717 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 21 Sep 2010 07:04:18 -0700 (PDT) Message-ID: <4C98BB57.7070202@isi.edu> Date: Tue, 21 Sep 2010 07:04:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Stuart Cheshire References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> <4C924978.4010602@isi.edu> <3DF309EA-4D18-4D5D-BBF0-9665719BE901@apple.com> In-Reply-To: <3DF309EA-4D18-4D5D-BBF0-9665719BE901@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 14:04:52 -0000 Hi, Stuart, On 9/20/2010 9:08 PM, Stuart Cheshire wrote: > On 16 Sep, 2010, at 09:44, Joe Touch wrote: > >> Any time more than one string maps to the same port number it's a kind >> of an 'alias'. The only way for the client to know the difference is >> via in-band information. >> >> I.e., we would allow aliases for: >> - different services >> - that can be resolved in-band >> >> Unless BOTH of those apply, we would not allow aliases except: >> >> a) legacy (www, http) >> b) to support changeover to the new namespace >> >> Joe > > > I think we agree on the concept, but the terminology previously confused > me. > > When you said, "alias," I read that as meaning, "different names for the > same service." > > Now I see that when you say, "alias," you mean, "different services on > the same port." (I'd call that a "collision", except in the special case > of a new service which is a compatible extension to an old one on the > same port.) Please see the text Lars just checked-in. - overloading is when different service names correspond to the same port number, of which there are three cases: 1- extended services with in-band resolution mechanisms 2- legacy names for the same service 3- names this doc phases out for syntax reasons (i.e., instances of #2 this doc deliberately creates) The current text does not use a single word to describe 1 vs 2 or 3; it distinguishes them in prose instead. (The only further mod might be to remove the "Overloading occurs" in the first bullet, which might suggest (inadvertently) that overloading doesn't occur in the other two bullets; it's really in all three, as per the lead-in intro to the bullets). Joe From lars.eggert@nokia.com Thu Sep 23 05:38:52 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8794F3A69C8 for ; Thu, 23 Sep 2010 05:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.309 X-Spam-Level: X-Spam-Status: No, score=-103.309 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6JdXZaFWndiW for ; Thu, 23 Sep 2010 05:38:51 -0700 (PDT) Received: from mgw-sa01.nokia.com (mgw-sa01.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 42F7D3A6921 for ; Thu, 23 Sep 2010 05:38:51 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8NCdEVV021043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Sep 2010 15:39:14 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-64--151813408; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4C98BB57.7070202@isi.edu> Date: Thu, 23 Sep 2010 15:39:08 +0300 Message-Id: <78FBB119-F8F5-4B53-B987-2D5499E2E341@nokia.com> References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> <4C924978.4010602@isi.edu> <3DF309EA-4D18-4D5D-BBF0-9665719BE901@apple.com> <4C98BB57.7070202@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 23 Sep 2010 15:39:08 +0300 (EEST) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 12:38:52 -0000 --Apple-Mail-64--151813408 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii OK, so are we good to submit the revision? Lars --Apple-Mail-64--151813408 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyMzEy MzkwOFowIwYJKoZIhvcNAQkEMRYEFPiCG4Pf2nu5U4O+uKjds2s/pgpGMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAHa17XjxQCWDn/aLOU0VP9QMqwzuqrqTJyRakjDxfqtfFhVo6YTo OCn4oLdQ8Fw1/PVZT6NTsRChS0ncIwjvll/ve/7B/XDP+YTpV6XQgf47/gd5UnL93us+H+gtcBES XhmN/R1vENX2LWsJ37m3IUqHWsxL/rYld1v2hiHDE8TWx959QPt/hKTuuqNNixD6UrO6d7CrQ3h7 BAiLZTFGp2kmBWaffIR0wFOVSEc8BkiiLB+SDiE+TskU64SiTMsspx8SPW+UXrTFK4A+rvW54NCk u6g6npMKGIhk4X89jl+WfSwNtUPBSnH1PncO5HuT66bUkh3i8jEZJ52x8KCM/54AAAAAAAA= --Apple-Mail-64--151813408-- From magnus.westerlund@ericsson.com Thu Sep 23 05:52:02 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC253A6AFA for ; Thu, 23 Sep 2010 05:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.447 X-Spam-Level: X-Spam-Status: No, score=-106.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 iQFAxZkMAMPF for ; Thu, 23 Sep 2010 05:52:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AABFF3A6AF6 for ; Thu, 23 Sep 2010 05:52:00 -0700 (PDT) X-AuditID: c1b4fb39-b7b0bae000000f9a-50-4c9b4d8d74ad Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.DA.03994.D8D4B9C4; Thu, 23 Sep 2010 14:52:29 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Sep 2010 14:52:29 +0200 Received: from [147.214.183.53] ([147.214.183.53]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Sep 2010 14:52:29 +0200 Message-ID: <4C9B4D8C.5020505@ericsson.com> Date: Thu, 23 Sep 2010 14:52:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Lars Eggert References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> <4C924978.4010602@isi.edu> <3DF309EA-4D18-4D5D-BBF0-9665719BE901@apple.com> <4C98BB57.7070202@isi.edu> <78FBB119-F8F5-4B53-B987-2D5499E2E341@nokia.com> In-Reply-To: <78FBB119-F8F5-4B53-B987-2D5499E2E341@nokia.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Sep 2010 12:52:29.0066 (UTC) FILETIME=[2E17F6A0:01CB5B1E] X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" , Joe Touch Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 12:52:02 -0000 Lars Eggert skrev 2010-09-23 14:39: > OK, so are we good to submit the revision? I want to check my 15 points against the latest SVN revision. I also are missing comments on some of my questions in that email: "Comments on SVN revision 68". Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From michelle.cotton@icann.org Thu Sep 23 06:24:52 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A023A6AAE for ; Thu, 23 Sep 2010 06:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Q2iVDVpy5Dq7 for ; Thu, 23 Sep 2010 06:24:50 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 5DA2C3A6AAD for ; Thu, 23 Sep 2010 06:24:50 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 23 Sep 2010 06:25:19 -0700 From: Michelle Cotton To: Magnus Westerlund Date: Thu, 23 Sep 2010 06:25:06 -0700 Thread-Topic: [port-srv-reg] Four final points for discussion Thread-Index: ActbIsRmonhcrVeITrqF87USc6g9sg== Message-ID: <8DBA5653-09FB-485D-B938-5DE57CC815AA@icann.org> References: <4C87B342.3040508@isi.edu> <4C91DF48.5010009@ericsson.com> <4C924978.4010602@isi.edu> <3DF309EA-4D18-4D5D-BBF0-9665719BE901@apple.com> <4C98BB57.7070202@isi.edu> <78FBB119-F8F5-4B53-B987-2D5499E2E341@nokia.com> <4C9B4D8C.5020505@ericsson.com> In-Reply-To: <4C9B4D8C.5020505@ericsson.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "port-srv-reg@ietf.org" , Joe Touch Subject: Re: [port-srv-reg] Four final points for discussion X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 13:24:53 -0000 SSBhbHNvIG93ZSBsYW5ndWFnZSBjaGFuZ2VzIGZvciB0aGUgY29udGFjdHMuIFNob3VsZCBiZSBh YmxlIHRvIGRvICANCnRoaXMgYnkgdG9tb3Jyb3cuDQotLU1pY2hlbGxlDQoNClNlbnQgZnJvbSBt eSBpUGhvbmUNCg0KT24gU2VwIDIzLCAyMDEwLCBhdCA1OjUyIEFNLCAiTWFnbnVzIFdlc3Rlcmx1 bmQiIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20gDQogPiB3cm90ZToNCg0KPiBMYXJz IEVnZ2VydCBza3JldiAyMDEwLTA5LTIzIDE0OjM5Og0KPj4gT0ssIHNvIGFyZSB3ZSBnb29kIHRv IHN1Ym1pdCB0aGUgcmV2aXNpb24/DQo+DQo+IEkgd2FudCB0byBjaGVjayBteSAxNSBwb2ludHMg YWdhaW5zdCB0aGUgbGF0ZXN0IFNWTiByZXZpc2lvbi4gSSBhbHNvICANCj4gYXJlDQo+IG1pc3Np bmcgY29tbWVudHMgb24gc29tZSBvZiBteSBxdWVzdGlvbnMgaW4gdGhhdCBlbWFpbDogIkNvbW1l bnRzIG9uICANCj4gU1ZODQo+IHJldmlzaW9uIDY4Ii4NCj4NCj4gQ2hlZXJzDQo+DQo+IE1hZ251 cyBXZXN0ZXJsdW5kDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gTXVsdGltZWRpYSBUZWNobm9sb2dp ZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3Nv biBBQiAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBGw6Ryw7ZnYXRh biA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBT dG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20N Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBQb3J0LXNydi1yZWcgbWFpbGluZyBsaXN0DQo+IFBvcnQtc3J2LXJlZ0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BvcnQtc3J2 LXJlZw0K From magnus.westerlund@ericsson.com Thu Sep 23 07:55:43 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2991C3A6B18 for ; Thu, 23 Sep 2010 07:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ygoGf9YC4ga9 for ; Thu, 23 Sep 2010 07:55:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 869D23A6B15 for ; Thu, 23 Sep 2010 07:55:41 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbeae00000772f-7c-4c9b6a895e7c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EB.37.30511.98A6B9C4; Thu, 23 Sep 2010 16:56:09 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Sep 2010 16:56:09 +0200 Received: from [147.214.183.53] ([147.214.183.53]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Sep 2010 16:56:08 +0200 Message-ID: <4C9B6A89.3090401@ericsson.com> Date: Thu, 23 Sep 2010 16:56:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: port-srv-reg@ietf.org References: <4C921413.2010808@ericsson.com> In-Reply-To: <4C921413.2010808@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Sep 2010 14:56:08.0943 (UTC) FILETIME=[74AF57F0:01CB5B2F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 14:55:43 -0000 Hi, I have removed all issues that has been resolved in r70. However, most of my questions still remains. Please comment. Magnus Westerlund skrev 2010-09-16 14:56: > 4. Section 7.2: > IANA decisions are not required to be bound by these > principles; other factors may come into play, and exceptions may > occur where deemed in the best interest of the Internet. > > I find this a bit confusing. I assume the intention is to say that these > are principles that should be followed. The hard rules are in Section 8. > How do you interpret the above? > > I would also like to point out that the above quote can be interpreted > to apply also on section 7.3 where rules are specified that I think are > not possible for IANA to waive. > > 5. Section 7.3: > > Should really section 7.3 be under Section 7 at all? Doesn't this belong > under Section 8.1? The reasons is that is is not principles but actual > rules. > > 6. Section 8.1: > o Transport Protocol(s): The transport protocol(s) for which the > allocation is requested MUST be provided. This field is currently > limited to one or more of TCP, UDP, SCTP, and DCCP. This field is > required even for services with no port number. > > To me it is not clear what I should enter in the case of requesting only > a service name and no ports. Should I list the transport protocols that > my application is capable of using this service over? In that case I > think a clarification is in order. > > 7. Section 8.1: > > Reserved numbers and names > are assigned only after review by IANA and the IETF, and are > accompanied by a statement explaining the reason a Reserved number or > name is appropriate for this action. > > How is the review by IETF performed in the above case? I think that > needs to be explicitly stated. > > 8. Section 8.1: > The following text did diseaper from this section: > > If the registration request is for a service name alias (see > Section 5), IANA needs to confirm with the administrative contact for > the existing service name whether the registration of the alias is > appropriate. > > I think for the STUN/TURN case it was a good rule that the registrant > present where an extension has requested to be assigned a service name > associated with the same port as a previous service name is contacted. > This to ensure that they truly are compatible extensions rather that > blatant attempt to do hostile takeover on the port. > > 9. Section 8.1: > o Port Number: If assignment of a port number is desired, either the > currently Unassigned or Reserved port number the requester > suggests for allocation, or the text "ANY", MUST be provided. If > only a service name is to be assigned, this field MUST be empty. > If a specific port number is requested, IANA is encouraged to > allocate the requested number. If the text "ANY" is specified, > IANA will choose a suitable number from the User Ports range. > Note that the applicant MUST NOT use the requested port prior to > the completion of the registration. > > Is is worth clarifying that applicants requesting to register a System > port must propose such a port. Either that or include an alias SYS to > mean any in the System range. > > > 11. Section 8.2: Service name de-registration. I saw it somewhere that > it was proposed to allow de-registration of service name in the purpose > of getting the HISTORIC stamp on the record. I think we should allow the > registrant to request the service name to be marked historic rather the > unassign it. > > 12. Section 8.2: > Because there is much less danger of exhausting the service name > space compared to the port number space, it is RECOMMENDED that a > given service name remain assigned even after all associated port > number assignments have become de-registered. Under this policy, it > will appear in the registry as if it had been created through a > service name registration request that did not include any port > numbers. > > When the above happens I think it should be made clear in the comment > field what has happened. > > 13. Section 8.5: What is unclear is if the Registrant is allowed to > perform an update if the legal name of the individual, organization or > company is changed. I think we should allow it to ensure that IANA can > keep their records up to date. However, the change history should make > clear what has happened. > > In addition I think we are making a mistake by not allowing the > registrant to be transfered. If a company sells its product line > associated with a protocol to another company. The expertize to judge if > an registration request will move. If only the contact information is > moved to the "buyer" of the product line, I think IANA gets into the > difficult situation to determine if the contact is allowed to answer > questions or not on behalf of the registrant. > > > 15. Appeal process: Do we need to explicitly define the appeal process? > I think a pointer to Section 7 of RFC 5226 is sufficient, but I think it > is worth pointing out that this is the appeal order that applies. I > think a section 8.7 would be the appropriate place. > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lars.eggert@nokia.com Thu Sep 23 22:58:58 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8FA3A6AA3 for ; Thu, 23 Sep 2010 22:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.292 X-Spam-Level: X-Spam-Status: No, score=-103.292 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 t8LmClEZFc6X for ; Thu, 23 Sep 2010 22:58:45 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id D5D0A3A68DF for ; Thu, 23 Sep 2010 22:58:43 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8O5xCX2021645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Sep 2010 08:59:12 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-21--89424556; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4C9B6A89.3090401@ericsson.com> Date: Fri, 24 Sep 2010 08:58:56 +0300 Message-Id: References: <4C921413.2010808@ericsson.com> <4C9B6A89.3090401@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 24 Sep 2010 08:59:02 +0300 (EEST) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 05:58:59 -0000 --Apple-Mail-21--89424556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2010-9-23, at 17:56, Magnus Westerlund wrote: > Magnus Westerlund skrev 2010-09-16 14:56: >> 4. Section 7.2: >> IANA decisions are not required to be bound by these >> principles; other factors may come into play, and exceptions may >> occur where deemed in the best interest of the Internet. >>=20 >> I find this a bit confusing. I assume the intention is to say that = these >> are principles that should be followed. The hard rules are in Section = 8. >> How do you interpret the above? I think we should instead say something like "these are the rules that = IANA SHOULD follow, but in exceptional cases special considerations MAY = apply." >> 5. Section 7.3: >>=20 >> Should really section 7.3 be under Section 7 at all? Doesn't this = belong >> under Section 8.1? The reasons is that is is not principles but = actual >> rules. Yes, I think this could be moved (it is likely here for historic = reasons). >> 6. Section 8.1: >> o Transport Protocol(s): The transport protocol(s) for which the >> allocation is requested MUST be provided. This field is = currently >> limited to one or more of TCP, UDP, SCTP, and DCCP. This field = is >> required even for services with no port number. >>=20 >> To me it is not clear what I should enter in the case of requesting = only >> a service name and no ports. Should I list the transport protocols = that >> my application is capable of using this service over? In that case I >> think a clarification is in order. I think we touched on this in another thread. I believe the result was = that we go with Stuart's suggestion: if you only want a service name, = and your service runs on TCP, this will be TCP, in all other cases this = will be UDP. Or do I mis-remember? >> 7. Section 8.1: >>=20 >> Reserved numbers and names >> are assigned only after review by IANA and the IETF, and are >> accompanied by a statement explaining the reason a Reserved number = or >> name is appropriate for this action. >>=20 >> How is the review by IETF performed in the above case? I think that >> needs to be explicitly stated. I think we should actually say that these are only assigned after a = Standards Action or IESG Approval, and that any such request must be = submitted to IANA with a statement explaining why. >> 8. Section 8.1: >> The following text did diseaper from this section: >>=20 >> If the registration request is for a service name alias (see >> Section 5), IANA needs to confirm with the administrative contact = for >> the existing service name whether the registration of the alias is >> appropriate. >>=20 >> I think for the STUN/TURN case it was a good rule that the registrant >> present where an extension has requested to be assigned a service = name >> associated with the same port as a previous service name is = contacted. >> This to ensure that they truly are compatible extensions rather that >> blatant attempt to do hostile takeover on the port. Agree. >> 9. Section 8.1: >> o Port Number: If assignment of a port number is desired, either = the >> currently Unassigned or Reserved port number the requester >> suggests for allocation, or the text "ANY", MUST be provided. = If >> only a service name is to be assigned, this field MUST be empty. >> If a specific port number is requested, IANA is encouraged to >> allocate the requested number. If the text "ANY" is specified, >> IANA will choose a suitable number from the User Ports range. >> Note that the applicant MUST NOT use the requested port prior to >> the completion of the registration. >>=20 >> Is is worth clarifying that applicants requesting to register a = System >> port must propose such a port. Either that or include an alias SYS to >> mean any in the System range. You only get System ports after "IETF Review" or "IESG Approval" anyway, = so the general public won't be affected by this much. But yes, we should = clarify. >> 11. Section 8.2: Service name de-registration. I saw it somewhere = that >> it was proposed to allow de-registration of service name in the = purpose >> of getting the HISTORIC stamp on the record. I think we should allow = the >> registrant to request the service name to be marked historic rather = the >> unassign it. This probably came from Alfred, whose philosophy is that an IANA = registry should somehow reflect actual deployment or use. I think this = will cause too much management overhead and the informaiton will be = inaccurate and stale anyway, so what's the point. >> 12. Section 8.2: >> Because there is much less danger of exhausting the service name >> space compared to the port number space, it is RECOMMENDED that a >> given service name remain assigned even after all associated port >> number assignments have become de-registered. Under this policy, = it >> will appear in the registry as if it had been created through a >> service name registration request that did not include any port >> numbers. >>=20 >> When the above happens I think it should be made clear in the comment >> field what has happened. Agreed. >> 13. Section 8.5: What is unclear is if the Registrant is allowed to >> perform an update if the legal name of the individual, organization = or >> company is changed. I think we should allow it to ensure that IANA = can >> keep their records up to date. However, the change history should = make >> clear what has happened. If the legal name changes, it is still the same registrant though. (The = name is an identifier, not an identity.) >> In addition I think we are making a mistake by not allowing the >> registrant to be transfered. If a company sells its product line >> associated with a protocol to another company. The expertize to judge = if >> an registration request will move. If only the contact information is >> moved to the "buyer" of the product line, I think IANA gets into the >> difficult situation to determine if the contact is allowed to answer >> questions or not on behalf of the registrant. That case is IMO handled by the "coordinated de-registration and = re-registration." Company A (who is being bought) returns the codepoints = to IANA, and at the same time company B (the buyer) requests assignment. = This allows IANA the option to say no, in cases where codepoints are = being transferred without companies being bought.=20 >> 15. Appeal process: Do we need to explicitly define the appeal = process? >> I think a pointer to Section 7 of RFC 5226 is sufficient, but I think = it >> is worth pointing out that this is the appeal order that applies. I >> think a section 8.7 would be the appropriate place. Agreed that a pointed to RFC5226 is all we need. Lars >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Port-srv-reg mailing list > Port-srv-reg@ietf.org > https://www.ietf.org/mailman/listinfo/port-srv-reg --Apple-Mail-21--89424556 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyNDA1 NTg1N1owIwYJKoZIhvcNAQkEMRYEFIUMI24Ub4PkucxLte1vzsvL4SdhMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBACpcd1m1U8u3cQe29zPgGgikFu8l6j1uDdSrR+mhpIU36kO23sqh 4S6jnNxEjdOK+V13sjqHBM8SP0znvp5zZO9YvkxzT3SJb75/NkcbZApc6UAfIeVryTjOpN68lpF1 SS2lHp6gVwP38e/7sWd8U/15Ht6wsF//5rLFQg0l7spXSyArwiUQB1/3Dt11gU7i1sB+03q706PZ Cmy4WvmoWpOQKqC4avTa9bf61maUkg7PevZuoq7629YUl7GcOSTVumhhymQxH9j/+Pi3PhVaE27D kSdC72DG/f1/u/Dkry2V9QiaPTN83d4+Ipwi82UUeQpvJFzlp93Xk5kJKteQKB0AAAAAAAA= --Apple-Mail-21--89424556-- From magnus.westerlund@ericsson.com Fri Sep 24 05:25:42 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A723A6B43 for ; Fri, 24 Sep 2010 05:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.872 X-Spam-Level: X-Spam-Status: No, score=-105.872 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 tklvnmhgjgsh for ; Fri, 24 Sep 2010 05:25:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6812C3A6B40 for ; Fri, 24 Sep 2010 05:25:31 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-00-4c9c98da8001 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.26.27351.AD89C9C4; Fri, 24 Sep 2010 14:26:02 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Sep 2010 14:25:06 +0200 Received: from [147.214.183.53] ([147.214.183.53]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Sep 2010 14:25:06 +0200 Message-ID: <4C9C98A2.5060405@ericsson.com> Date: Fri, 24 Sep 2010 14:25:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Lars Eggert References: <4C921413.2010808@ericsson.com> <4C9B6A89.3090401@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------060506030105030301060704" X-OriginalArrivalTime: 24 Sep 2010 12:25:06.0619 (UTC) FILETIME=[858830B0:01CB5BE3] X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 12:25:42 -0000 This is a multi-part message in MIME format. --------------060506030105030301060704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, I have made a number of changes and committed them as r71. There is likely need to word smith, but I wanted to put in embryo of text for people to react to. See discussion inline. Lars Eggert skrev 2010-09-24 07:58: > Hi, > > On 2010-9-23, at 17:56, Magnus Westerlund wrote: >> Magnus Westerlund skrev 2010-09-16 14:56: >>> 4. Section 7.2: >>> IANA decisions are not required to be bound by these >>> principles; other factors may come into play, and exceptions may >>> occur where deemed in the best interest of the Internet. >>> >>> I find this a bit confusing. I assume the intention is to say that these >>> are principles that should be followed. The hard rules are in Section 8. >>> How do you interpret the above? > > I think we should instead say something like "these are the rules that IANA SHOULD follow, but in exceptional cases special considerations MAY apply." I am a bit worried by that. I think the general rules should not be possible to void at least not by IANA. I think we can require IESG approval to break a rule. I have tweaked this sentence a bit to indicate that it IANA's handling of the request that the principle applies to. > >>> 5. Section 7.3: >>> >>> Should really section 7.3 be under Section 7 at all? Doesn't this belong >>> under Section 8.1? The reasons is that is is not principles but actual >>> rules. > > Yes, I think this could be moved (it is likely here for historic reasons). I will move it and people can yell if it was better or not. > >>> 6. Section 8.1: >>> o Transport Protocol(s): The transport protocol(s) for which the >>> allocation is requested MUST be provided. This field is currently >>> limited to one or more of TCP, UDP, SCTP, and DCCP. This field is >>> required even for services with no port number. >>> >>> To me it is not clear what I should enter in the case of requesting only >>> a service name and no ports. Should I list the transport protocols that >>> my application is capable of using this service over? In that case I >>> think a clarification is in order. > > I think we touched on this in another thread. I believe the result was that we go with Stuart's suggestion: if you only want a service name, and your service runs on TCP, this will be TCP, in all other cases this will be UDP. Or do I mis-remember? Okay, but then we need text that makes it clear that service name registrations shall indicate the protocols that is being used. Transport Protocol(s): The transport protocol(s) for which a allocation is requested MUST be provided. This field is currently limited to one or more of TCP, UDP, SCTP, and DCCP. Requests without any port allocation and only a service name are still required to indicate which protocol the service uses. > > >>> 7. Section 8.1: >>> >>> Reserved numbers and names >>> are assigned only after review by IANA and the IETF, and are >>> accompanied by a statement explaining the reason a Reserved number or >>> name is appropriate for this action. >>> >>> How is the review by IETF performed in the above case? I think that >>> needs to be explicitly stated. > > I think we should actually say that these are only assigned after a Standards Action or IESG Approval, and that any such request must be submitted to IANA with a statement explaining why. Implemented: Reserved numbers and names are assigned only by Standards Action or IESG Approval, and MUST accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. > >>> 8. Section 8.1: >>> The following text did diseaper from this section: >>> >>> If the registration request is for a service name alias (see >>> Section 5), IANA needs to confirm with the administrative contact for >>> the existing service name whether the registration of the alias is >>> appropriate. >>> >>> I think for the STUN/TURN case it was a good rule that the registrant >>> present where an extension has requested to be assigned a service name >>> associated with the same port as a previous service name is contacted. >>> This to ensure that they truly are compatible extensions rather that >>> blatant attempt to do hostile takeover on the port. > > Agree. > Implemented >>> 9. Section 8.1: >>> o Port Number: If assignment of a port number is desired, either the >>> currently Unassigned or Reserved port number the requester >>> suggests for allocation, or the text "ANY", MUST be provided. If >>> only a service name is to be assigned, this field MUST be empty. >>> If a specific port number is requested, IANA is encouraged to >>> allocate the requested number. If the text "ANY" is specified, >>> IANA will choose a suitable number from the User Ports range. >>> Note that the applicant MUST NOT use the requested port prior to >>> the completion of the registration. >>> >>> Is is worth clarifying that applicants requesting to register a System >>> port must propose such a port. Either that or include an alias SYS to >>> mean any in the System range. > > You only get System ports after "IETF Review" or "IESG Approval" anyway, so the general public won't be affected by this much. But yes, we should clarify. Ok, attempted to clarify this. > >>> 11. Section 8.2: Service name de-registration. I saw it somewhere that >>> it was proposed to allow de-registration of service name in the purpose >>> of getting the HISTORIC stamp on the record. I think we should allow the >>> registrant to request the service name to be marked historic rather the >>> unassign it. > > This probably came from Alfred, whose philosophy is that an IANA registry should somehow reflect actual deployment or use. I think this will cause too much management overhead and the informaiton will be inaccurate and stale anyway, so what's the point. Yes, I agree that it will never be up to date. However, an entry marked as historic will clearly be historic. While you never know if an umarked one is used or not. I am fine with the current text indicating that service name should normally not be de-registered. > >>> 12. Section 8.2: >>> Because there is much less danger of exhausting the service name >>> space compared to the port number space, it is RECOMMENDED that a >>> given service name remain assigned even after all associated port >>> number assignments have become de-registered. Under this policy, it >>> will appear in the registry as if it had been created through a >>> service name registration request that did not include any port >>> numbers. >>> >>> When the above happens I think it should be made clear in the comment >>> field what has happened. > > Agreed. Text added at the end of the section. > >>> 13. Section 8.5: What is unclear is if the Registrant is allowed to >>> perform an update if the legal name of the individual, organization or >>> company is changed. I think we should allow it to ensure that IANA can >>> keep their records up to date. However, the change history should make >>> clear what has happened. > > If the legal name changes, it is still the same registrant though. (The name is an identifier, not an identity.) well, but 8.6 says: "(Note that Registration Administrative Contact cannot be changed; see Section 8.5 above.)" Which from my perspective prohibits IANA to change the value of the field, even if simply to update what is clearly the same Registrant. > >>> In addition I think we are making a mistake by not allowing the >>> registrant to be transfered. If a company sells its product line >>> associated with a protocol to another company. The expertize to judge if >>> an registration request will move. If only the contact information is >>> moved to the "buyer" of the product line, I think IANA gets into the >>> difficult situation to determine if the contact is allowed to answer >>> questions or not on behalf of the registrant. > > That case is IMO handled by the "coordinated de-registration and re-registration." Company A (who is being bought) returns the codepoints to IANA, and at the same time company B (the buyer) requests assignment. This allows IANA the option to say no, in cases where codepoints are being transferred without companies being bought. Ok, I don't have a strong view on this. But I think we are overly sensitive on this. > >>> 15. Appeal process: Do we need to explicitly define the appeal process? >>> I think a pointer to Section 7 of RFC 5226 is sufficient, but I think it >>> is worth pointing out that this is the appeal order that applies. I >>> think a section 8.7 would be the appropriate place. > > Agreed that a pointed to RFC5226 is all we need. Okay, added text in new section 8.7. I have attached text of r71 and a diff between 70 and 71. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------060506030105030301060704 Content-Type: text/plain; name="draft-ietf-tsvwg-iana-ports-r71.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-tsvwg-iana-ports-r71.txt" Transport Area Working Group M. Cotton Internet-Draft ICANN Updates: 2780, 2782, 3828, 4340, L. Eggert 4960 (if approved) Nokia Intended status: BCP J. Touch Expires: March 28, 2011 USC/ISI M. Westerlund Ericsson S. Cheshire Apple September 24, 2010 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry draft-ietf-tsvwg-iana-ports-07 Abstract This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling registration and other requests related to the Service Name and Transport Protocol Port Number Registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782] to clarify what a service name is and how it is registered. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 28, 2011. Cotton, et al. Expires March 28, 2011 [Page 1] Internet-Draft Service Name and Port Number Procedures September 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Cotton, et al. Expires March 28, 2011 [Page 2] Internet-Draft Service Name and Port Number Procedures September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conventions Used in this Document . . . . . . . . . . . . . . 7 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Service names and Port Numbers for Experimentation . . . . 11 7. Principles for Service Name and Transport Protocol Port Number Registry Management . . . . . . . . . . . . . . . . . . 12 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry . . . . . . . . . . . 15 8.1. Service Name and Port Number Registration . . . . . . . . 15 8.2. Service Name and Port Number De-Registration . . . . . . . 20 8.3. Service Name and Port Number Re-Use . . . . . . . . . . . 20 8.4. Service Name and Port Number Revocation . . . . . . . . . 21 8.5. Service Name and Port Number Transfers . . . . . . . . . . 21 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 22 8.7. Disagrements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 23 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 25 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Cotton, et al. Expires March 28, 2011 [Page 3] Internet-Draft Service Name and Port Number Procedures September 2010 1. Introduction For many years, the allocation of new service names and port number values for use with the Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have had less than clear guidelines. New transport protocols have been added - the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have been developed, each with separate registries and separate guidelines. The community also recognized the need for additional procedures beyond just assignment; notably modification, revocation, and release. A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. This document brings the IANA procedures for TCP and UDP in line with those for SCTP and DCCP, resulting in a single process that requesters and IANA follow for all requests for all transport protocols, including future protocols not yet defined. In addition to detailing the IANA procedures for the initial assignment of service names and port numbers, this document also specifies post-assignment procedures that until now have been handled in an ad hoc manner. These include procedures to de-register a port number that is no longer in use, to re-use a port number allocated for one application that is no longer in use for another application, and the procedure by which IANA can unilaterally revoke a prior port number assignment. Section 8 discusses the specifics of these procedures and processes that requesters and IANA follow for all requests for all current and future transport protocols. IANA is the authority for assigning service names and port numbers. The registries that are created to store these registrations are maintained by IANA. For protocols developed by IETF working groups, IANA now also offers a method for the "early assignment" [RFC4020] of service names and port numbers, as described in Section 8.1. This document updates IANA's procedures for UDP and TCP port numbers by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780]. (Note that other sections of the IANA allocation guidelines, relating to the protocol field values in IPv4 header, were also updated in February 2008 [RFC5237].) This document also updates the IANA allocation procedures for DCCP [RFC4340] and SCTP [RFC4960]. The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares the port space with UDP. The UDP-Lite specification says: "UDP-Lite uses the same set of port number values assigned by the IANA for use Cotton, et al. Expires March 28, 2011 [Page 4] Internet-Draft Service Name and Port Number Procedures September 2010 by UDP". Thus the update of UDP procedures result in an update also of the UDP-Lite procedures. This document also clarifies what a service name is and how it is registered. This will impact the DNS SRV specification [RFC2782], because that specification merely makes a brief mention that the symbolic names of services are defined in "Assigned Numbers" [RFC1700], without stating to which section it refers within that 230-page document. The DNS SRV specification may have been referring to the list of Port Assignments (known as /etc/services on Unix), or to the "Protocol And Service Names" section, or to both, or to some other section. Furthermore, "Assigned Numbers" is now obsolete [RFC3232] and has been replaced by on-line registries [PORTREG][PROTSERVREG]. The development of new transport protocols is a major effort that the IETF does not undertake very often. If a new transport protocol is standardized in the future, for consistency it is expected to follow as much as possible the guidelines and practices around using service names and port numbers. 2. Motivation Information about the registration procedures for the port registry has existed in three locations: the forms for requesting port number registrations on the IANA web site [SYSFORM] [USRFORM], an introductory text section in the file listing the port number registrations themselves [PORTREG], and two brief sections of the IANA Allocation Guidelines [RFC2780]. Similarly, the procedures surrounding service names have been historically unclear. Service names were originally created as mnemonic identifiers for port numbers without a well-defined syntax, beyond the 14-character limit mentioned on the IANA website [SYSFORM] [USRFORM]. Even that length limit has not been consistently applied, and some assigned service names are 15 characters long. When service identification via DNS SRV Resource Records (RRs) was introduced, the requirement by IANA to only assign service names and port numbers in combination, led to the creation of an ad hoc service name registry outside of the control of IANA [SRVREG]. This document aggregates all this scattered information into a single reference that aligns and clearly defines the management procedures for both service names and port numbers. It gives more detailed guidance to prospective requesters of service names and ports than the existing documentation, and it streamlines the IANA procedures for the management of the registry, so that management requests can Cotton, et al. Expires March 28, 2011 [Page 5] Internet-Draft Service Name and Port Number Procedures September 2010 complete in a timely manner. This document defines rules for registration of service names without associated port numbers, for such usages as DNS SRV records [RFC2782], which was not possible under the previous IANA procedures. The document also merges service name registrations from the non-IANA ad hoc registry [SRVREG] and from the IANA "Protocol and Service Names" registry [PROTSERVREG] into the IANA "Service Name and Transport Protocol Port Number" registry [PORTREG], which from here on is the single authoritative registry for service names and port numbers. An additional purpose of this document is to describe the principles that guide the IETF and IANA in their role as the long-term joint stewards of the service name and port number registry. TCP and UDP have had remarkable success over the last decades. Thousands of applications and application-level protocols have service names and ports assigned for their use, and there is every reason to believe that this trend will continue into the future. It is hence extremely important that management of the registry follow principles that ensure its long-term usefulness as a shared resource. Section 7 discusses these principles in detail. 3. Background The Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success over the decades as the two most widely used transport protocols on the Internet. They have relied on the concept of "ports" as logical entities for Internet communication. Ports serve two purposes: first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes bind. Newer transport protocols, such as the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] have also adopted the concept of ports for their communication sessions and use sixteen-bit port numbers in the same way as TCP and UDP (and UDP-Lite [RFC3828], a variant of UDP). Port numbers are the original and most widely used means for application and service identification on the Internet. Ports are sixteen-bit numbers, and the combination of source and destination port numbers together with the IP addresses of the communicating end systems uniquely identifies a session of a given transport protocol. Port numbers are also known by their associated service names such as "telnet" for port number 23 and "http" (as well as "www" and "www- Cotton, et al. Expires March 28, 2011 [Page 6] Internet-Draft Service Name and Port Number Procedures September 2010 http") for port number 80. Hosts running services, hosts accessing services on other hosts, and intermediate devices (such as firewalls and NATs) that restrict services need to agree on which service corresponds to a particular destination port. Although this is ultimately a local decision with meaning only between the endpoints of a connection, it is common for many services to have a default port upon which those servers usually listen, when possible, and these ports are recorded by the Internet Assigned Numbers Authority (IANA) through the service name and port number registry [PORTREG]. Over time, the assumption that a particular port number necessarily implies a particular service may become less true. For example, multiple instances of the same service on the same host cannot generally listen on the same port, and multiple hosts behind the same NAT gateway cannot all have a mapping for the same port on the external side of the NAT gateway, whether using static port mappings configured by hand by the user, or dynamic port mappings configured automatically using a port mapping protocol like NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device (IGD) [IGD]. Applications may use numeric port numbers directly, look up port numbers based on service names via system calls such as getservbyname() on UNIX, look up port numbers by performing queries for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd], or determine port numbers in a variety of other ways like the TCP Port Service Multiplexer (TCPMUX) [RFC1078]. Designers of applications and application-level protocols may apply to IANA for an assigned service name and port number for a specific application, and may - after successful registration - assume that no other application will use that service name or port number for its communication sessions. Alternatively, application designers may also ask for only an assigned service name, if their application does not require a fixed port number. The latter alternative is encouraged when possible, in order to conserve the more limited port number space. This is applicable, for example, to applications that use DNS SRV records to look up port numbers at runtime. 4. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Cotton, et al. Expires March 28, 2011 [Page 7] Internet-Draft Service Name and Port Number Procedures September 2010 5. Service Names Service names are the unique key in the Service Name and Transport Protocol Port Number Registry. This unique symbolic name for a service may also be used for other purposes, such as in DNS SRV records [RFC2782]. Within the registry, this unique key ensures that different services can be unambiguously distinguished, thus preventing name collisions and avoiding confusion about who is the Registrant for a particular entry. There may be more than one service name associated with a particular transport protocol and port. There are three ways that such service name overloading can occur: o Overloading occurs when one service is an extension of another service, and an in-band mechanism exists for determining if the extension is present or not. One example is port 3478, which has the service name aliases "stun" and "turn". TURN [RFC5766] is an extension to the STUN [RFC5389] service. TURN-enabled clients wishing to locate TURN servers could attempt to discover "stun" services and then check in-band if the server supports TURN, but this would be inefficient. Enabling them to directly query for "turn" servers by name is a better approach. (Note that TURN servers in this case should also be locatable via a "stun" discovery, because every TURN server is also a STUN server.) o By historical accident the service name "http" corresponds to the same port number as "www" and "www-http". When used in SRV records [RFC2782], and similar service discovery mechanisms only the service name "http" should be used, not these additional names. If a server were to advertise "www" then it would not be discovered by clients browsing for "http". Advertising or browsing for the aliases as well as the primary service name would be inefficient, and achieves nothing that it not already achieved by using the service name "http" exclusively. o As indicated in this document, in Section 10.1, to enable legacy names to be replaced with names consistent with the syntax this document prescribes. In this case, only the new name should be used in SRV records, both to avoid the same issues as with historical cases of multiple names, as well as because the legacy names are incompatible with SRV record use. For future assignments, applications will not be permitted that merely request a new name exactly duplicating an existing service. Having multiple names for the same service serves no purpose. Implementers are requested to inform IANA if they discover other cases where a single service has multiple names, so that one name may Cotton, et al. Expires March 28, 2011 [Page 8] Internet-Draft Service Name and Port Number Procedures September 2010 be recorded as the primary name for service discovery purposes. Service names are assigned on a "first come, first served" basis, as described in Section 8.1. Names should be brief and informative, avoiding words or abbreviations that are redundant in the context of the registry (e.g., "port", "service", "protocol", etc.) Names referring to discovery services, e.g., using multicast or broadcast to identify endpoints capable of a given service, SHOULD use an easily identifiable suffix (e.g., "-disc"). 5.1. Service Name Syntax Valid service names are hereby normatively defined as follows: o MUST be at least 1 character and no more than 15 characters long o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45) o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') o MUST NOT begin or end with a hyphen The reason for requiring at least one letter is to avoid service names like "23" (could be confused with a numeric port number) or "6000-6063" (could be confused with a numeric port number range). Although service names may contain both upper-case and lower-case letters, case is ignored for comparison purposes, so both "http" and "HTTP" denote the same service. Service names are purely opaque identifiers, and no semantics are implied by any superficial structure that a given service name may appear to have. For example, a company called "Example" may choose to register service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" products, but the "Example" company can't claim to "own" all service names beginning with "Example-", they can't prevent someone else registering "Example-Baz" for a different service, and they can't prevent other developers from using the "Example-Foo" and "Example-Bar" service types in order to interoperate with the "Foo" and "Bar" products. Technically speaking, in service discovery protocols, service names are merely a series of byte values on the wire; for the mnemonic convenience of human developers it can be convenient to interpret those byte values as human-readable ascii characters, but software should treat them as purely opaque identifiers and not attempt to parse them for any additional embedded meaning. Cotton, et al. Expires March 28, 2011 [Page 9] Internet-Draft Service Name and Port Number Procedures September 2010 In approximately 98% of cases, the new "service name" is exactly the same as the old historic "short name" from the IANA web forms [SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service name" is derived from the old historic "short name" as described below in Section 10.1. The rules for valid service names, excepting the limit of 15 characters maximu, are also expressed below (as a non-normative convenience) using ABNF [RFC5234]. SRVNAME = (ALPHA / (1*DIGIT [HYPHEN] ALPHA)) *([HYPHEN] ALNUM) ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN = %x2d ; "-" ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] DIGIT = %x30-39 ; 0-9 [RFC5234] 5.2. Service Name Usage in DNS SRV Records The DNS SRV specification [RFC2782] states that the Service Label part of the owner name of a DNS SRV record includes a "Service" element, described as "the symbolic name of the desired service", but as discussed above, it is not clear precisely what this means. This document clarifies that the Service Label MUST be a service name as defined herein. The service name SHOULD be registered with IANA and recorded in the Service Name and Transport Protocol Port Number Registry [PORTREG]. The details of using Service Names in SRV Service Labels are specified in the DNS SRV specification [RFC2782]. This document does not change that specification. 6. Port Number Ranges TCP, UDP, UDP-Lite, SCTP and DCCP use sixteen-bit namespaces for their port number registries. The port registries for all these transport protocols are subdivided into three ranges of numbers, and Section 8.1.1 describes the IANA procedures for each range in detail: o the System Ports, also known as the Well Known Ports, from 0-1023 (assigned by IANA) o the User Ports, also known as the Registered Ports, from 1024- 49151 (assigned by IANA) Cotton, et al. Expires March 28, 2011 [Page 10] Internet-Draft Service Name and Port Number Procedures September 2010 o the Dynamic Ports, also known as the Private Ports, from 49152- 65535 (never assigned) Of the assignable port ranges (System Ports and User Ports, i.e., port numbers 0-49151), individual port numbers are in one of three states at any given time: o Assigned: Assigned port numbers are currently allocated to the service indicated in the registry. o Unassigned: Unassigned port numbers are currently available for assignment upon request, as per the procedures outlined in this document. o Reserved: Reserved port numbers are not available for regular assignment; they are "assigned to IANA" for special purposes. Reserved port numbers include values at the edges of each range, e.g., 0, 1023, 1024, etc., which may be used to extend these ranges or the overall port number space in the future. In order to keep the size of the registry manageable, IANA typically only records the Assigned and Reserved service names and port numbers in the registry. Unassigned values are typically not explicitly listed. (There are an near-infinite number of Unassigned service names and enumerating them all would not be practical.) As a data point, when this document was written, approximately 76% of the TCP and UDP System Ports were assigned, and approximately 9% of the User Ports were assigned. (As noted, Dynamic Ports are never assigned.) 6.1. Service names and Port Numbers for Experimentation Of the System Ports, two TCP and UDP port numbers (1021 and 1022), together with their respective service names ("exp1" and "exp2"), have been assigned for experimentation with new applications and application-layer protocols that require a port number in the assigned ports ranges [RFC4727]. Please refer to Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] for how these experimental port numbers are to be used. This document registers the same two service names and port numbers for experimentation with new application-layer protocols over SCTP and DCCP in Section 10.2. Unfortunately, it can be difficult to limit access to these ports. Cotton, et al. Expires March 28, 2011 [Page 11] Internet-Draft Service Name and Port Number Procedures September 2010 Users SHOULD take measures to ensure that experimental ports are connecting to the intended process. For example, users of these experimental ports might include a 64-bit nonce, once on each segment of a message-oriented channel (e.g., UDP), or once at the beginning of a byte-stream (e.g., TCP), which is used to confirm that the port is being used as intended. Such confirmation of intended use is especially important when these ports are associated with privileged (e.g., system or administrator) processes. 7. Principles for Service Name and Transport Protocol Port Number Registry Management Management procedures for the service name and transport protocol port number registry include allocation of service names and port numbers upon request, as well as management of information about existing allocations. The latter includes maintaining contact and description information about assignments, revoking abandoned assignments, and redefining assignments when needed. Of these procedures, careful port number allocation is most critical, in order to continue to conserve the remaining port numbers. As noted earlier, only about 9% of the User Port space is currently assigned. The current rate of assignment is approximately 400 ports per year, and has remained steady for the past 8 years. At that rate, if similar conservation continues, this resource will sustain another 85 years of assignment - without the need to resort to reassignment of released values or revocation. The namespace available for service names is much larger, which allows for simpler management procedures. 7.1. Past Principles Before the publication of this document, the principles of service name and port number management followed a few mostly-undocumented guidelines. They are recorded here for historical purposes, and this document updates them in Section 7.2. These principles were: o TCP and UDP ports were simultaneously allocated when either was requested o Port numbers were the primary allocation; service names were informative only, and did not have a well-defined syntax o Port numbers were conserved informally, and sometimes inconsistently (e.g., some services were allocated ranges of many port numbers even where not strictly necessary) Cotton, et al. Expires March 28, 2011 [Page 12] Internet-Draft Service Name and Port Number Procedures September 2010 o SCTP and DCCP service name and port number registries were managed separately from the TCP/UDP registries o Service names could not be assigned in the old ports registry without assigning an associated port number at the same time This document clarifies and aligns these guidelines in order to more conservatively manage the limited remaining port number space and to enable and promote the use of service names for service identification without associated port numbers, where possible. 7.2. Updated Principles This section summarizes the basic principles by which IANA handles the Service Name and Transport Protocol Port Number Registry, and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA are not required to be bound by these principles when handling requests; other factors may come into play, and exceptions may occur where deemed in the best interest of the Internet. IANA will begin assigning service names that do not request an associated port number allocation under a simple "First Come, First Served" policy [RFC5226]. IANA MAY, at its discretion, refer service name requests to "Expert Review" in cases of mass registrations or other situations where IANA believes expert review is advisable. The basic principle of service name and port number registry management is to conserve use of the port space where possible. Extensions to support larger port number spaces would require changing many core protocols of the current Internet in a way that would not be backward compatible and interfere with both current and legacy applications. To help ensure this conservation the policy for any registration request for port number allocations uses the "Expert Review" policy [RFC5226]. Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. In particular: o IANA will allocate only one assigned port number per service or application o IANA will allocate only one assigned port number for all versions of a service (e.g., running the service with or without a security Cotton, et al. Expires March 28, 2011 [Page 13] Internet-Draft Service Name and Port Number Procedures September 2010 mechanism, or for updated variants of a service) o IANA will allocate only one assigned port number for all different types of device using or participating in the same service o IANA will allocate port numbers only for the transport protocol(s) explicitly named in a registration request o IANA may recover unused port numbers, via the new procedures of de-registration, revocation, and transfer Where possible, a given service is expected to demultiplex messages if necessary. For example, applications and protocols are expected to include in-band version information, so that future versions of the application or protocol can share the same allocated port. Applications and protocols are also expected to be able to efficiently use a single allocated port for multiple sessions, either by demultiplexing multiple streams within one port, or using the allocated port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]). Ports are used in various ways, notably: o as endpoint process identifiers o as application protocol identifiers o for firewall filtering purposes Both the process identifier and the protocol identifier uses suggest that anything a single process can demultiplex, or that can be encoded into a single protocol, should be. The firewall filtering use suggests that some uses that could be multiplexed or encoded could instead be separated to allow for easier firewall management. Note that this latter use is much less sound, because port numbers have meaning only for the two endpoints involved in a connection, and drawing conclusions about the service that generated a given flow based on observed port numbers is not always reliable. Further, previous separation of protocol variants based on security capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is not recommended for new protocols, because all new protocols should be security-capable and capable of negotiating the use of security in-band. IANA will begin assigning port numbers for only those transport protocols explicitly included in a registration request. This ends the long-standing practice of automatically assigning a port number to an application for both TCP and a UDP, even if the request is for Cotton, et al. Expires March 28, 2011 [Page 14] Internet-Draft Service Name and Port Number Procedures September 2010 only one of these transport protocols. The new allocation procedure conserves resources by allocating a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually uses. The port number will be marked as Reserved - instead of Assigned - in the port number registries of the other transport protocols. When applications start supporting the use of some of those additional transport protocols, the Registrant for the registration MUST request IANA to convert the reservation into a proper assignment. An application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport protocol without asking IANA to convert the reservation into an assignment. When the available pool of unassigned numbers has run out in a ports range, it will be necessary for IANA to consider the Reserved ports for assignment. This is part of the motivation for not automatically assigning ports for transport protocols other than the requested one(s). This will allow more ports to be available for assignment when that time comes. To help conserve ports, application developers should register only the transport protocols that their application currently uses. Conservation of port numbers is improved by procedures that allow previously allocated port numbers to become Unassigned, either through de-registration or through revocation, and by a procedure that lets application designers transfer an allocated but unused port number to a new application. Section 8 describes these procedures, which until now were undocumented. Port number conservation is also improved by recommending that applications that do not require an allocated port should register only a service name without an associated port number. 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry This section describes the process for handling requests associated with IANA's management of the Service Name and Transport Protocol Port Number Registry. Such requests include initial registration, de-registration, re-use, changes to the service name, and updates to the contact information or description associated with an assignment. Revocation is as additional process, initiated by IANA. 8.1. Service Name and Port Number Registration Registration refers to the allocation of service names or port numbers to applicants. All such registrations are made from service names or port numbers that are Unassigned or Reserved at the time of Cotton, et al. Expires March 28, 2011 [Page 15] Internet-Draft Service Name and Port Number Procedures September 2010 the allocation. Unassigned names and numbers are allocated according to the rules described in Section 8.1.1 below. Reserved numbers and names are assigned only by Standards Action or IESG Approval, and MUST accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. When a registration for one or more transport protocols is approved, the port number for any non-requested transport protocol(s) will be marked as Reserved. IANA SHOULD NOT assign that port number to any other application or service until no other port numbers remain Unassigned in the requested range. The current Registrant for a port number MAY register these Reserved port numbers for other transport protocols when needed. A service name or port number registration request contains the following information. The service name is the unique identifier of a given service: Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) Registrant (REQUIRED) Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL) o Service Name: A desired unique service name for the service associated with the registration request MUST be provided, for use in various service selection and discovery mechanisms (including, but not limited to, DNS SRV records [RFC2782]). The name MUST be compliant with the syntax defined in Section 5.1. In order to be Cotton, et al. Expires March 28, 2011 [Page 16] Internet-Draft Service Name and Port Number Procedures September 2010 unique, they MUST NOT be identical to any currently assigned service name in the IANA registry [PORTREG]. Service names are case-insensitive; they may be provided and entered into the registry with mixed case for clarity, but for the comparison purposes the case is ignored. o Transport Protocol(s): The transport protocol(s) for which a allocation is requested MUST be provided. This field is currently limited to one or more of TCP, UDP, SCTP, and DCCP. Requests without any port allocation and only a service name are still required to indicate which protocol the service uses. o Registrant: Name and email address of the Registrant. This is REQUIRED. The Registrant is the Organization or Company responsible for the initial registration. For registrations done through IETF-published RFCs, the Registrant will be the IESG. o Contact: Name and email address of the Contact person for the registration. This is REQUIRED. The Contact person is the responsible person for the Internet community to send questions to. This person would also be authorized to submit changes on behalf of the Registrant; in cases of conflict between the Registrant and the Contact, the Registrant decisions take precedence. Additional address information MAY be provided. For registrations done through IETF-published RFCs, the Contact will be the IESG. o Description: A short description of the service associated with the registration request is REQUIRED. It should avoid all but the most well-known acronyms. o Reference: A description of (or a reference to a document describing) the protocol or application using this port. The description must state whether the protocol uses broadcast, multicast, or anycast communication. For registrations requesting only a Service Name, or a Service Name and User Port, a statement that the protocol is proprietary and not publicly documented is also acceptable provided that the required information regarding use of broadcast, multicast, or anycast is given. For registration requests for a User Port, the registration request MUST explain why a port number in the Dynamic Ports range is unsuitable for the given application. For registration requests for a System Port, the registration request MUST explain why a port number in the User Ports or Cotton, et al. Expires March 28, 2011 [Page 17] Internet-Draft Service Name and Port Number Procedures September 2010 Dynamic Ports ranges is unsuitable, and a reference to a stable protocol specification document MUST be provided. For requests from IETF Working Groups, IANA MAY accept "early registration" [RFC4020] requests referencing a sufficiently stable Internet Draft instead of a published Standards-Track RFC. o Port Number: If assignment of a port number is desired, either the currently Unassigned or Reserved port number the requester suggests for allocation, or the text "USER" for a port in the User Port range, or the text "SYS" for a port in the System Port range, MUST be provided. If only a service name is to be assigned, this field MUST be empty. If a specific port number is requested, IANA is encouraged to allocate the requested number. If the text "USER" or "SYS" is specified, IANA will choose a suitable number from the User or System Ports ranges. Note that the applicant MUST NOT use the requested port prior to the completion of the registration. o Service Code: If the registration request includes DCCP as a transport protocol then the request MUST include a desired unique DCCP service code [RFC5595], and MUST NOT include a requested DCCP service code otherwise. Section 19.8 of the DCCP specification [RFC4340] defines requirements and rules for allocation, updated by this document. o Known Unauthorized Uses: A list of uses by applications or organizations who are not the assignee. This list may be augmented by IANA after assignment when unauthorized uses are reported. o Assignment Notes: Indications of owner/name change, or any other assignment process issue. This list may be updated by IANA after assignment to help track changes to an assignment, e.g., de- registration, owner/name changes, etc. If the registration request is for the addition of a new transport protocol to an already assigned service name, IANA needs to confirm with the Registrant for the existing assignment whether this addition is appropriate. If the registration request is for a service name overloading a port number (see Section 5), IANA needs to confirm with the Registrant for the existing service name whether the registration of the overloading is appropriate. When IANA receives a registration request - containing the above information - that is requesting a port number, IANA SHALL initiate an "Expert Review" [RFC5226] in order to determine whether an Cotton, et al. Expires March 28, 2011 [Page 18] Internet-Draft Service Name and Port Number Procedures September 2010 assignment should be made. For requests that do not include a port number, IANA SHOULD assign the service name under a simple "First Come First Served" policy [RFC5226]. 8.1.1. Variances for Specific Port Number Ranges Section 6 describes the different port number ranges. It is important to note that IANA applies slightly different procedures when managing the different port ranges of the service name and port number registry: o Ports in the Dynamic Ports range (49152-65535) have been specifically set aside for local and dynamic use and cannot be assigned through IANA. Application software may simply use them for communication without any sort of registration. On the other hand, application software MUST NOT assume that a specific port number in the Dynamic Ports range will always be available for communication at all times, and a port number in that range hence MUST NOT be used as a service identifier. o Ports in the User Ports range (1024-49151) are available for registration through IANA, and MAY be used as service identifiers upon successful registration. Because registering a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. This documentation will be input to the "Expert Review" allocation procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the registration. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226], which is how most assignments for IETF protocols are handled. o Ports in the System Ports range (0-1023) are also available for registration through IANA. Because the System Ports range is both the smallest and the most densely allocated, the requirements for new allocations are more strict than those for the User Ports range, and will only be granted under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226]. A request for a System Port number MUST document *both* why using a port number from the User Ports is unsuitable *and* why using a port number from the Dynamic Ports ranges is unsuitable for that application. Cotton, et al. Expires March 28, 2011 [Page 19] Internet-Draft Service Name and Port Number Procedures September 2010 8.2. Service Name and Port Number De-Registration The Registrant of a granted port number assignment can return the port number to IANA at any time if they no longer have a need for it. The port number will be de-registered and will be marked as Reserved. IANA should not re-assign port numbers that have been de-registered until all unassigned port numbers in the specific range have been assigned. Before proceeding with a port number de-registration, IANA needs to reasonably establish that the value is actually no longer in use. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that a given service name remain assigned even after all associated port number assignments have become de-registered. Under this policy, it will appear in the registry as if it had been created through a service name registration request that did not include any port numbers. On rare occasions, it may still be useful to de-register a service name. In such cases, IANA will mark the service name as Reserved. IANA will involve their IESG-appointed expert in such cases. IANA will include a comment in the registry when de-registration happens to indicate its historic usage. 8.3. Service Name and Port Number Re-Use If the Registrant of a granted port number assignment no longer have a need for the assigned number, but would like to re-use it for a different application, they can submit a request to IANA to do so. Logically, port number re-use is to be thought of as a de- registration (Section 8.2) followed by an immediate re-registration (Section 8.1) of the same port number for a new application. Consequently, the information that needs to be provided about the proposed new use of the port number is identical to what would need to be provided for a new port number allocation for the specific ports range. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that the original service name associated with the prior use of the port number remains assigned, and a new service be created and associated with the port number. This is again consistent with viewing a re-use request as a de-registration followed by an immediate re- registration. Re-using an assigned service name for a different Cotton, et al. Expires March 28, 2011 [Page 20] Internet-Draft Service Name and Port Number Procedures September 2010 application is NOT RECOMMENDED. IANA needs to carefully review such requests before approving them. In some instances, the Expert Reviewer will determine that the application that the port number was assigned to has found usage beyond the original requester, or that there is a concern that it may have such users. This determination MUST be made quickly. A community call concerning revocation of a port number (see below) MAY be considered, if a broader use of the port number is suspected. 8.4. Service Name and Port Number Revocation A port number revocation can be thought of as an IANA-initiated de- registration (Section 8.2), and has exactly the same effect on the registry. Sometimes, it will be clear that a specific port number is no longer in use and that IANA can revoke it and mark it as Reserved. At other times, it may be unclear whether a given assigned port number is still in use somewhere in the Internet. In those cases, IANA must carefully consider the consequences of revoking the port number, and SHOULD only do so if there is an overwhelming need. With the help of their IESG-appointed Expert Reviewer, IANA SHALL formulate a request to the IESG to issue a four-week community call concerning the pending port number revocation. The IESG and IANA, with the Expert Reviewer's support, SHALL determine promptly after the end of the community call whether revocation should proceed and then communicate their decision to the community. This procedure typically involves similar steps to de-registration except that it is initiated by IANA. Because there is much less danger of exhausting the service name space compared to the port number space, revoking service names is NOT RECOMMENDED. 8.5. Service Name and Port Number Transfers The value of service names and port numbers is defined by their careful management as a shared Internet resource, whereas enabling transfer allows the potential for associated monetary exchanges. As a result, the IETF does not permit service name or port number assignments to be transferred between parties, even when they are mutually consenting. The appropriate alternate procedure is a coordinated de-registration and registration: The new party requests the service name or port number via a registration and the previous party releases its Cotton, et al. Expires March 28, 2011 [Page 21] Internet-Draft Service Name and Port Number Procedures September 2010 assignment via the de-registration procedure outlined above. With the help of their IESG-appointed Expert Reviewer, IANA SHALL carefully determine if there is a valid technical, operational or managerial reason to grant the requested new assignment. 8.6. Maintenance Issues In addition to the formal procedures described above, updates to the Description and Contact information are coordinated by IANA in an informal manner, and may be initiated by either the registrant or by IANA, e.g., by the latter requesting an update to current contact information. (Note that Registration Administrative Contact cannot be changed; see Section 8.5 above.) 8.7. Disagrements In the case of disagreements around any request there is the possibility of appeal following the normal appelas process for IANA registrations as defined by Section 7 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. 9. Security Considerations The IANA guidelines described in this document do not change the security properties of UDP, TCP, SCTP, or DCCP. Assignment of a service name or port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from an assigned port number does not mean that it is "good" traffic, or even that it is used by the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, not based on whether or not there is an assigned service name or port number. Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. 10. IANA Considerations This document obsoletes Sections 8 and 9.1 of the March 2000 IANA Allocation Guidelines [RFC2780]. Cotton, et al. Expires March 28, 2011 [Page 22] Internet-Draft Service Name and Port Number Procedures September 2010 Upon approval of this document, IANA is requested to contact Stuart Cheshire, maintainer of the independent service name registry [SRVREG], in order to merge the contents of that private registry into the official IANA registry. It is expected that the independent registry web page will be updated with pointers to the IANA registry and to this RFC. IANA is instructed to create a new service name entry in the service name and port number registry [PORTREG] for any entry in the "Protocol and Service Names" registry [PROTSERVREG] that does not already have one assigned. IANA is also instructed to indicate in the Assignment Notes for "www" and "www-http" that they are duplicante terms that refer to the "http" service, and should not be used for discovery purposes. For this conceptual service (human-readable web pages served over HTTP) the correct service name to use for service discovery purposes is "http" (see Section 5). 10.1. Service Name Consistency Section 8.1 defines which character strings are well-formed service names, which until now had not been clearly defined. The definition in Section 8.1 was chosen to allow maximum compatibility of service names with current and future service discovery mechanisms. As of August 5, 2009 approximately 98% of the so-called "Short Names" from existing port number registrations [PORTREG] meet the rules for legal service names stated in Section 8.1, and hence for these services their service name will be exactly the same as their "Short Name". The remaining approximately 2% of the exiting "Short Names" are not suitable to be used directly as well-formed service names because they contain illegal characters such as asterisks, dots, pluses, slashes, or underscores. All existing "Short Names" conform to the length requirement of 15 characters or fewer. For these unsuitable "Short Names", listed in the table below, the service name will be the Short Name with any illegal characters replaced by hyphens. IANA SHALL add an entry to the registry giving the new well-formed primary service name for the existing service, that otherwise duplicates the original assignment information. In the description field of this new entry giving the primary service name, IANA SHALL record that it assigns a well-formed service name for the previous service and reference the original assignment. In the Assignment Notes field of the original assignment, IANA SHALL add a note that this entry is an alias to the new well-formed service name, and that the old service name is historic, not usable for use with many common service Cotton, et al. Expires March 28, 2011 [Page 23] Internet-Draft Service Name and Port Number Procedures September 2010 discovery mechanisms. Names containing illegal characters to be replaced by hyphens: Cotton, et al. Expires March 28, 2011 [Page 24] Internet-Draft Service Name and Port Number Procedures September 2010 +----------------+-----------------+-----------------+ | 914c/g | acmaint_dbd | acmaint_transd | | atex_elmd | avanti_cdp | badm_priv | | badm_pub | bdir_priv | bdir_pub | | bmc_ctd_ldap | bmc_patroldb | boks_clntd | | boks_servc | boks_servm | broker_service | | bues_service | canit_store | cedros_fds | | cl/1 | contamac_icm | corel_vncadmin | | csc_proxy | cvc_hostd | dbcontrol_agent | | dec_dlm | dl_agent | documentum_s | | dsmeter_iatc | dsx_monitor | elpro_tunnel | | elvin_client | elvin_server | encrypted_admin | | erunbook_agent | erunbook_server | esri_sde | | EtherNet/IP-1 | EtherNet/IP-2 | event_listener | | flr_agent | gds_db | ibm_wrless_lan | | iceedcp_rx | iceedcp_tx | iclcnet_svinfo | | idig_mux | ife_icorp | instl_bootc | | instl_boots | intel_rci | interhdl_elmd | | lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C | | LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet | | mdbs_daemon | menandmice_noh | msl_lmd | | nburn_id | ncr_ccl | nds_sso | | netmap_lm | nms_topo_serv | notify_srvr | | novell-lu6.2 | nuts_bootp | nuts_dem | | ocs_amu | ocs_cmu | pipe_server | | pra_elmd | printer_agent | redstorm_diag | | redstorm_find | redstorm_info | redstorm_join | | resource_mgr | rmonitor_secure | rsvp_tunnel | | sai_sentlm | sge_execd | sge_qmaster | | shiva_confsrvr | sql*net | srvc_registry | | stm_pproc | subntbcst_tftp | udt_os | | universe_suite | veritas_pbx | vision_elmd | | vision_server | wrs_registry | z39.50 | +----------------+-----------------+-----------------+ Following the example set by the "application/whoispp-query" MIME Content-Type [RFC2957], the service name for "whois++" will be "whoispp". 10.2. Port Numbers for SCTP and DCCP Experimentation Two System UDP and TCP ports, 1021 and 1022, have been reserved for experimental use [RFC4727]. This document assigns the same port numbers for SCTP and DCCP, updates the TCP and UDP registrations, and also instructs IANA to automatically assign these two port numbers for any future transport protocol with a similar sixteen-bit port number namespace. Cotton, et al. Expires March 28, 2011 [Page 25] Internet-Draft Service Name and Port Number Procedures September 2010 Note that these port numbers are meant for temporary experimentation and development in controlled environments. Before using these port numbers, carefully consider the advice in Section 6.1 in this document, as well as in Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692]. Most importantly, application developers must request a permanent port number assignment from IANA as described in Section 8.1 before any kind of non-experimental deployment. +--------------------+----------------------------+ | Registrant | IETF | | Contact | IESG | | Service Name | exp1 | | Port Number | 1021 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 1 | | Reference | [RFCyyyy],RFC 4727] | +--------------------+----------------------------+ +--------------------+----------------------------+ | Registrant | IETF | | Contact | IESG | | Service Name | exp2 | | Port Number | 1022 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 2 | | Reference | [RFCyyyy], [RFC4727] | +--------------------+----------------------------+ [RFC Editor Note: Please change "yyyy" to the RFC number allocated to this document before publication.] 10.3. Updates to DCCP Registries This document updates the IANA allocation procedures for the DCCP Port Number and DCCP Service Codes Registries [RFC4340]. 10.3.1. DCCP Service Code Registry Service Codes are allocated first-come-first-served according to Section 19.8 of the DCCP specification [RFC4340]. This document updates that section by extending the guidelines given there in the following ways: o IANA MAY assign new Service Codes without seeking Expert Review using their discretion, but SHOULD seek expert review if a request seeks more than five Service Codes. Cotton, et al. Expires March 28, 2011 [Page 26] Internet-Draft Service Name and Port Number Procedures September 2010 o IANA should feel free to contact the DCCP Expert Reviewer with questions on any registry, regardless of the registry policy, for clarification or if there is a problem with a request [RFC4340]. 10.3.2. DCCP Port Numbers Registry The DCCP ports registry is defined by Section 19.9 of the DCCP specification [RFC4340]. Allocations in this registry require prior allocation of a Service Code. Not all Service Codes require IANA- assigned ports. This document updates that section by extending the guidelines given there in the following way: o IANA should normally assign a value in the range 1024-49151 to a DCCP server port. IANA allocation requests to allocate port numbers in the System Ports range (0 through 1023), require an "IETF Review" [RFC5226] prior to allocation by IANA [RFC4340]. o IANA MUST NOT allocate more than one DCCP server port to a single service code value. o The allocation of multiple service codes to the same DCCP port is allowed, but subject to expert review. o The set of Service Code values associated with a DCCP server port should be recorded in the service name and port number registry. o A request for additional Service Codes to be associated with an already allocated Port Number requires Expert Review. These requests will normally be accepted when they originate from the contact associated with the port registration. In other cases, these applications will be expected to use an unallocated port, when this is available. The DCCP specification [RFC4340] notes that a short port name MUST be associated with each DCCP server port that has been assigned. This document clarifies that this short port name is the Service Name as defined here, and this name MUST be unique. 11. Contributors Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have contributed text and ideas to this document. 12. Acknowledgments The text in Section 10.3 is based on a suggestion originally proposed Cotton, et al. Expires March 28, 2011 [Page 27] Internet-Draft Service Name and Port Number Procedures September 2010 as a part of the DCCP Service Codes document[RFC5595] by Gorry Fairhurst. Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program. 13. References 13.1. Normative References [ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Cotton, et al. Expires March 28, 2011 [Page 28] Internet-Draft Service Name and Port Number Procedures September 2010 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 13.2. Informative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-06 (work in progress), March 2010. [I-D.cheshire-nat-pmp] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-03 (work in progress), April 2008. [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", November 2001. [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name and Transport Protocol Port Number Registry", http://www.iana.org/assignments/port-numbers. [PROTSERVREG] Internet Assigned Numbers Authority (IANA), "Protocol and Service Names Registry", http://www.iana.org/assignments/service-names. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", RFC 1078, November 1988. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2957] Daigle, L. and P. Faltstrom, "The application/ whoispp-query Content-Type", RFC 2957, October 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. Cotton, et al. Expires March 28, 2011 [Page 29] Internet-Draft Service Name and Port Number Procedures September 2010 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, February 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [SRVREG] "DNS SRV Service Types Registry", http://www.dns-sd.org/ServiceTypes.html. [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application for System (Well Known) Port Number", http://www.iana.org/cgi-bin/sys-port-number.pl. [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. [USRFORM] Internet Assigned Numbers Authority (IANA), "Application for User (Registered) Port Number", http://www.iana.org/cgi-bin/usr-port-number.pl. Authors' Addresses Michelle Cotton Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1 310 823 9358 Email: michelle.cotton@icann.org URI: http://www.iana.org/ Cotton, et al. Expires March 28, 2011 [Page 30] Internet-Draft Service Name and Port Number Procedures September 2010 Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +358 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/ Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292 USA Phone: +1 310 448 9151 Email: touch@isi.edu URI: http://www.isi.edu/touch Magnus Westerlund Ericsson Farogatan 6 Stockholm 164 80 Sweden Phone: +46 8 719 0000 Email: magnus.westerlund@ericsson.com Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com Cotton, et al. Expires March 28, 2011 [Page 31] --------------060506030105030301060704 Content-Type: text/html; charset=ISO-8859-1; name="rfcdiff-iana-ports-r70-r71.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rfcdiff-iana-ports-r70-r71.htm" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5z aXRpb25hbC5kdGQiPg0KPGh0bWw+PGhlYWQ+DQogDQo8IS0tIEdlbmVyYXRlZCBieSByZmNk aWZmIDEuMzk6IHJmY2RpZmYgIC0tPiANCjwhLS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICIt Ly9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFsIiA+IC0tPg0KPCEtLSBTeXN0ZW06 IExpbnV4IG1lcmxvdCAyLjYuMjYtMi02ODYgIzEgU01QIFRodSBNYXIgMjYgMDE6MDg6MTEg VVRDIDIwMDkgaTY4NiBHTlUvTGludXggLS0+IA0KPCEtLSBVc2luZyBhd2s6IC91c3IvYmlu L2dhd2s6IEdOVSBBd2sgMy4xLjcgLS0+IA0KPCEtLSBVc2luZyBkaWZmOiAvdXNyL2Jpbi9k aWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjAgLS0+IA0KPCEtLSBVc2luZyB3ZGlmZjog L3Vzci9iaW4vd2RpZmY6IHdkaWZmIChHTlUgd2RpZmYpIDAuNi4zIC0tPiANCiANCiANCiAg PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo YXJzZXQ9SVNPLTg4NTktMSI+IA0KICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxl LVR5cGUiIGNvbnRlbnQ9InRleHQvY3NzIj4gDQogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRm LXRzdndnLWlhbmEtcG9ydHMtcjcwLnR4dCAtIGRyYWZ0LWlldGYtdHN2d2ctaWFuYS1wb3J0 cy1yNzEudHh0PC90aXRsZT4gDQogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+IA0KICAgIGJv ZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1dG87IH0gDQogICAgdHIg ICAgICB7IH0gDQogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30g DQogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IA0KICAgIC5zbWFsbCAgeyBm b250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJk YW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gDQogICAgLmxlZnQgICB7IGJhY2tncm91 bmQtY29sb3I6ICNFRUU7IH0gDQogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNG RkY7IH0gDQogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gDQogICAg LmxibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gDQogICAgLnJibG9jayB7IGJh Y2tncm91bmQtY29sb3I6ICNGRjg7IH0gDQogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29s b3I6ICM4RkY7IH0gDQogICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7IH0g DQogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkI7IH0gDQogICAgLmNvbnQg ICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gDQogICAgLmxpbmViciB7IGJhY2tncm91 bmQtY29sb3I6ICNBQUE7IH0gDQogICAgLmxpbmVubyB7IGNvbG9yOiByZWQ7IGJhY2tncm91 bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246IHJpZ2h0OyBw YWRkaW5nOiAwIDJweDsgfSANCiAgICAuZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FB QTsgfSANCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gDQog ICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSANCiAgICAubGJs b2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSANCiAgICAucmJsb2NrIC5j b250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsgfSANCiAgICAuaW5zZXJ0IC5jb250IHsg YmFja2dyb3VuZC1jb2xvcjogIzBERDsgfSANCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogIzhBRDsgfSANCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRo IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7IH0gDQogIDwvc3R5 bGU+IA0KPC9oZWFkPjxib2R5PiANCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIwIj4gDQogIDx0Ym9keT48dHIgYmdjb2xvcj0ib3JhbmdlIj48 dGg+PC90aD48dGg+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXRzdndnLWlhbmEtcG9ydHMtcjcwLnR4dCIgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMTM2KTsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+Jmx0OzwvYT4mbmJzcDs8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWlh bmEtcG9ydHMtcjcwLnR4dCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMTM2KTsiPmRyYWZ0 LWlldGYtdHN2d2ctaWFuYS1wb3J0cy1yNzAudHh0PC9hPiZuYnNwOzwvdGg+PHRoPiA8L3Ro Pjx0aD4mbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXRzdndnLWlhbmEtcG9ydHMtcjcxLnR4dCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MTM2KTsiPmRyYWZ0LWlldGYtdHN2d2ctaWFuYS1wb3J0cy1yNzEudHh0PC9hPiZuYnNwOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi10 c3Z3Zy1pYW5hLXBvcnRzLXI3MS50eHQiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDEzNik7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3RyPiAN CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlRyYW5z cG9ydCBBcmVhIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE0uIENvdHRvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlRyYW5zcG9y dCBBcmVhIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE0uIENvdHRvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElDQU5OPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIElDQU5OPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5VcGRhdGVzOiAyNzgwLCAyNzgy LCAzODI4LCA0MzQwLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBFZ2dlcnQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5VcGRhdGVzOiAyNzgwLCAyNzgyLCAz ODI4LCA0MzQwLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBFZ2dlcnQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjQ5NjAgKGlmIGFwcHJvdmVkKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBOb2tpYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQ5 NjAgKGlmIGFwcHJvdmVkKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBOb2tpYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZW5kZWQgc3RhdHVzOiBCQ1AgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIFRvdWNoPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+SW50ZW5kZWQgc3RhdHVzOiBCQ1AgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIFRvdWNoPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMDEiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiBNYXJjaCAy PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Nzwvc3Bhbj4sIDIwMTEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBVU0MvSVNJPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPkV4cGlyZXM6IE1hcmNoIDI8c3BhbiBjbGFzcz0iaW5zZXJ0Ij44PC9zcGFu PiwgMjAxMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVTQy9J U0k8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTS4gV2VzdGVybHVuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTS4gV2VzdGVybHVuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Uy4gQ2hlc2hpcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4g Q2hlc2hpcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBcHBsZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBcHBsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAy Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDI8c3BhbiBjbGFzcz0i ZGVsZXRlIj4zPC9zcGFuPiwgMjAxMDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTZXB0ZW1iZXIgMjxzcGFuIGNsYXNzPSJpbnNlcnQiPjQ8L3NwYW4+LCAyMDEwPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0IEFzc2lnbmVk IE51bWJlcnMgQXV0aG9yaXR5IChJQU5BKSBQcm9jZWR1cmVzIGZvciB0aGUgTWFuYWdlbWVu dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0IEFzc2lnbmVkIE51 bWJlcnMgQXV0aG9yaXR5IChJQU5BKSBQcm9jZWR1cmVzIGZvciB0aGUgTWFuYWdlbWVudDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgIG9mIHRoZSBTZXJ2aWNlIE5hbWUgYW5kIFRyYW5zcG9ydCBQcm90b2NvbCBQb3J0 IE51bWJlciBSZWdpc3RyeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICBv ZiB0aGUgU2VydmljZSBOYW1lIGFuZCBUcmFuc3BvcnQgUHJvdG9jb2wgUG9ydCBOdW1iZXIg UmVnaXN0cnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtdHN2d2ctaWFu YS1wb3J0cy0wNzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgIGRyYWZ0LWlldGYtdHN2d2ctaWFuYS1wb3J0cy0wNzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgcHJvY2VkdXJlcyB0 aGF0IHRoZSBJbnRlcm5ldCBBc3NpZ25lZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgcHJvY2VkdXJlcyB0aGF0IHRoZSBJ bnRlcm5ldCBBc3NpZ25lZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIHVzZXMg d2hlbiBoYW5kbGluZyByZWdpc3RyYXRpb24gYW5kIG90aGVyPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIHVzZXMgd2hlbiBo YW5kbGluZyByZWdpc3RyYXRpb24gYW5kIG90aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXF1ZXN0cyByZWxhdGVk IHRvIHRoZSBTZXJ2aWNlIE5hbWUgYW5kIFRyYW5zcG9ydCBQcm90b2NvbCBQb3J0PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVxdWVzdHMgcmVsYXRlZCB0byB0aGUg U2VydmljZSBOYW1lIGFuZCBUcmFuc3BvcnQgUHJvdG9jb2wgUG9ydDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+DQogICAgICA8 dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDIiPjxzbWFs bD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5lIDQ5PC9l bT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjIiPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5lIDQ5PC9lbT48L2E+ PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUg d29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhc2sgRm9y Y2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGFzayBGb3JjZSAoSUVURiku ICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJ bnRlcm5ldC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJl bnQvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp eCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29s ZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8g dXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMyI+PC9hPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g TWFyY2ggMjxzcGFuIGNsYXNzPSJkZWxldGUiPjc8L3NwYW4+LCAyMDExLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhw aXJlIG9uIE1hcmNoIDI8c3BhbiBjbGFzcz0iaW5zZXJ0Ij44PC9zcGFuPiwgMjAxMS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGlj ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChj KSAyMDEwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29weXJpZ2h0IChjKSAyMDEwIElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1 bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZl ZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBy b3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZl Y3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAo aHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhl IGRhdGUgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2Ug cmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNl IGRvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRo PjxhIG5hbWU9InBhcnQtbDMiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxs PjxlbT4gcGFnZSAzLCBsaW5lIDIwPC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5h bWU9InBhcnQtcjMiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4g cGFnZSAzLCBsaW5lIDIwPC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIDQuICBDb252ZW50aW9ucyBVc2VkIGluIHRoaXMgRG9jdW1lbnQgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IDQuICBDb252ZW50aW9ucyBVc2VkIGluIHRoaXMgRG9jdW1lbnQgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNS4gIFNlcnZpY2UgTmFtZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgNS4gIFNlcnZpY2UgTmFtZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDUuMS4gIFNl cnZpY2UgTmFtZSBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDUuMS4gIFNlcnZp Y2UgTmFtZSBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgNS4yLiAgU2VydmljZSBOYW1lIFVzYWdlIGluIEROUyBTUlYgUmVjb3Jk cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAxMDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgNS4yLiAgU2VydmljZSBOYW1lIFVzYWdlIGluIEROUyBTUlYgUmVjb3JkcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAxMDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNi4gIFBvcnQgTnVtYmVyIFJhbmdlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNi4gIFBvcnQgTnVtYmVyIFJhbmdlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDYu MS4gIFNlcnZpY2UgbmFtZXMgYW5kIFBvcnQgTnVtYmVycyBmb3IgRXhwZXJpbWVudGF0aW9u IC4gLiAuIC4gMTE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDYuMS4g IFNlcnZpY2UgbmFtZXMgYW5kIFBvcnQgTnVtYmVycyBmb3IgRXhwZXJpbWVudGF0aW9uIC4g LiAuIC4gMTE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIDcuICBQcmluY2lwbGVzIGZvciBTZXJ2aWNlIE5hbWUgYW5kIFRy YW5zcG9ydCBQcm90b2NvbCBQb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgNy4gIFByaW5jaXBsZXMgZm9yIFNlcnZpY2UgTmFtZSBhbmQgVHJhbnNwb3J0IFByb3Rv Y29sIFBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICBOdW1iZXIgUmVnaXN0cnkgTWFuYWdlbWVudCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICBOdW1iZXIgUmVnaXN0cnkgTWFuYWdlbWVudCAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjEuICBQYXN0IFByaW5j aXBsZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjEuICBQYXN0IFByaW5jaXBs ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgIDcuMi4gIFVwZGF0ZWQgUHJpbmNpcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg IDcuMi4gIFVwZGF0ZWQgUHJpbmNpcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNCI+PC9hPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgNy4zLiAgVmFyaWFu Y2VzIGZvciBTcGVjaWZpYyBQb3J0IE51bWJlciBSYW5nZXMgIC4gLiAuIC4gLiAuIC4gLiAx NTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA4LiAg SUFOQSBQcm9jZWR1cmVzIGZvciBNYW5hZ2luZyB0aGUgU2VydmljZSBOYW1lIGFuZDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDguICBJQU5BIFByb2NlZHVyZXMgZm9y IE1hbmFnaW5nIHRoZSBTZXJ2aWNlIE5hbWUgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MDUiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgVHJhbnNwb3J0IFByb3Rv Y29sIFBvcnQgTnVtYmVyIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+MTY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgICBUcmFuc3BvcnQgUHJvdG9jb2wgUG9ydCBOdW1iZXIgUmVnaXN0cnkgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNTwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICA4LjEuICBTZXJ2aWNlIE5hbWUgYW5kIFBvcnQgTnVtYmVyIFJlZ2lzdHJhdGlv biAgLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjE2PC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDguMS4gIFNlcnZpY2UgTmFtZSBh bmQgUG9ydCBOdW1iZXIgUmVnaXN0cmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xh c3M9Imluc2VydCI+MTU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgOC4yLiAgU2VydmljZSBOYW1lIGFu ZCBQb3J0IE51bWJlciBEZS1SZWdpc3RyYXRpb24gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFz cz0iZGVsZXRlIj4xOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICA4LjIuICBTZXJ2aWNlIE5hbWUgYW5kIFBvcnQgTnVtYmVyIERlLVJlZ2lzdHJhdGlv biAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjIwPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICA4LjMuICBTZXJ2aWNlIE5hbWUgYW5kIFBvcnQgTnVtYmVyIFJlLVVzZSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDIwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA4 LjMuICBTZXJ2aWNlIE5hbWUgYW5kIFBvcnQgTnVtYmVyIFJlLVVzZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDIwPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDguNC4gIFNlcnZpY2UgTmFtZSBhbmQgUG9ydCBOdW1i ZXIgUmV2b2NhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gMjE8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgIDguNC4gIFNlcnZpY2UgTmFtZSBhbmQgUG9ydCBOdW1iZXIg UmV2b2NhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gMjE8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgOC41LiAgU2Vydmlj ZSBOYW1lIGFuZCBQb3J0IE51bWJlciBUcmFuc2ZlcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAy MTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgOC41LiAgU2VydmljZSBO YW1lIGFuZCBQb3J0IE51bWJlciBUcmFuc2ZlcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAyMTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA2Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICA4LjYuICBNYWludGVuYW5jZSBJc3N1ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjIxPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDguNi4gIE1haW50ZW5hbmNlIElzc3Vl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9 Imluc2VydCI+MjI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgIDguNy4gIERpc2FncmVtZW50cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjI8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAxMC4xLiBT ZXJ2aWNlIE5hbWUgQ29uc2lzdGVuY3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAxMC4xLiBTZXJ2 aWNlIE5hbWUgQ29uc2lzdGVuY3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDIzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDciPjwvYT48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICAgIDEwLjIuIFBvcnQgTnVtYmVycyBmb3IgU0NUUCBhbmQgRENDUCBFeHBlcmlt ZW50YXRpb24gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MjQ8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMTAuMi4gUG9ydCBOdW1iZXJz IGZvciBTQ1RQIGFuZCBEQ0NQIEV4cGVyaW1lbnRhdGlvbiAuIC4gLiAuIC4gLiA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij4yNTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAxMC4zLiBVcGRhdGVzIHRvIERD Q1AgUmVnaXN0cmllcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNs YXNzPSJkZWxldGUiPjI1PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgIDEwLjMuIFVwZGF0ZXMgdG8gRENDUCBSZWdpc3RyaWVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+MjY8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIDExLiBDb250cmlidXRvcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4yNjwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgMTEuIENvbnRyaWJ1dG9ycyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNz PSJpbnNlcnQiPjI3PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTIuIEFja25vd2xlZGdtZW50cyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMTIuIEFja25vd2xlZGdtZW50cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFt ZT0iZGlmZjAwMDgiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAxMy4gUmVmZXJl bmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIDEzLiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yODwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICAxMy4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjI3PC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDEzLjEuIE5vcm1h dGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g PHNwYW4gY2xhc3M9Imluc2VydCI+Mjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgMTMuMi4gSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8 c3BhbiBjbGFzcz0iZGVsZXRlIj4yODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAxMy4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjI5PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mjk8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEF1dGhvcnMnIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij4zMDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgRm9yIG1hbnkgeWVhcnMsIHRoZSBhbGxvY2F0aW9uIG9mIG5l dyBzZXJ2aWNlIG5hbWVzIGFuZCBwb3J0IG51bWJlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIEZvciBtYW55IHllYXJzLCB0aGUgYWxsb2NhdGlvbiBvZiBuZXcgc2Vy dmljZSBuYW1lcyBhbmQgcG9ydCBudW1iZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHZhbHVlcyBmb3IgdXNlIHdpdGgg dGhlIFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sIChUQ1ApIFtSRkMwNzkzXTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHZhbHVlcyBmb3IgdXNlIHdpdGggdGhl IFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sIChUQ1ApIFtSRkMwNzkzXTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg YW5kIHRoZSBVc2VyIERhdGFncmFtIFByb3RvY29sIChVRFApIFtSRkMwNzY4XSBoYXZlIGhh ZCBsZXNzIHRoYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgdGhl IFVzZXIgRGF0YWdyYW0gUHJvdG9jb2wgKFVEUCkgW1JGQzA3NjhdIGhhdmUgaGFkIGxlc3Mg dGhhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgY2xlYXIgZ3VpZGVsaW5lcy4gIE5ldyB0cmFuc3BvcnQgcHJvdG9jb2xz IGhhdmUgYmVlbiBhZGRlZCAtIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGNsZWFyIGd1aWRlbGluZXMuICBOZXcgdHJhbnNwb3J0IHByb3RvY29scyBoYXZlIGJl ZW4gYWRkZWQgLSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN0cmVhbSBDb250cm9sIFRyYW5zbWlzc2lvbiBQcm90 b2NvbCAoU0NUUCkgW1JGQzQ5NjBdIGFuZCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFNDVFAp IFtSRkM0OTYwXSBhbmQgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEYXRhZ3JhbSBDb25nZXN0aW9uIENvbnRyb2wg UHJvdG9jb2wgKERDQ1ApIFtSRkM0MzQyXSAtIGFuZCBuZXc8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBEYXRhZ3JhbSBDb25nZXN0aW9uIENvbnRyb2wgUHJvdG9jb2wg KERDQ1ApIFtSRkM0MzQyXSAtIGFuZCBuZXc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1lY2hhbmlzbXMgbGlrZSBETlMg U1JWIHJlY29yZHMgW1JGQzI3ODJdIGhhdmUgYmVlbiBkZXZlbG9wZWQsIGVhY2g8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtZWNoYW5pc21zIGxpa2UgRE5TIFNSViBy ZWNvcmRzIFtSRkMyNzgyXSBoYXZlIGJlZW4gZGV2ZWxvcGVkLCBlYWNoPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAg IDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNCI+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDEwLCBsaW5lIDQy PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjQiPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxMCwgbGluZSA0MjwvZW0+ PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBkZXRhaWxzIG9mIHVzaW5nIFNlcnZpY2UgTmFt ZXMgaW4gU1JWIFNlcnZpY2UgTGFiZWxzIGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoZSBkZXRhaWxzIG9mIHVzaW5nIFNlcnZpY2UgTmFtZXMgaW4gU1JWIFNl cnZpY2UgTGFiZWxzIGFyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3BlY2lmaWVkIGluIHRoZSBETlMgU1JWIHNwZWNp ZmljYXRpb24gW1JGQzI3ODJdLiAgVGhpcyBkb2N1bWVudCBkb2VzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWVkIGluIHRoZSBETlMgU1JWIHNwZWNpZmlj YXRpb24gW1JGQzI3ODJdLiAgVGhpcyBkb2N1bWVudCBkb2VzPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBub3QgY2hhbmdl IHRoYXQgc3BlY2lmaWNhdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBub3QgY2hhbmdlIHRoYXQgc3BlY2lmaWNhdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4gIFBvcnQgTnVtYmVyIFJhbmdlczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjYuICBQb3J0IE51bWJlciBSYW5nZXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVENQLCBVRFAsIFVEUC1MaXRl LCBTQ1RQIGFuZCBEQ0NQIHVzZSBzaXh0ZWVuLWJpdCBuYW1lc3BhY2VzIGZvcjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRDUCwgVURQLCBVRFAtTGl0ZSwgU0NUUCBh bmQgRENDUCB1c2Ugc2l4dGVlbi1iaXQgbmFtZXNwYWNlcyBmb3I8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZWlyIHBv cnQgbnVtYmVyIHJlZ2lzdHJpZXMuICBUaGUgcG9ydCByZWdpc3RyaWVzIGZvciBhbGwgdGhl c2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGVpciBwb3J0IG51bWJl ciByZWdpc3RyaWVzLiAgVGhlIHBvcnQgcmVnaXN0cmllcyBmb3IgYWxsIHRoZXNlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICB0cmFuc3BvcnQgcHJvdG9jb2xzIGFyZSBzdWJkaXZpZGVkIGludG8gdGhyZWUgcmFuZ2Vz IG9mIG51bWJlcnMsIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRy YW5zcG9ydCBwcm90b2NvbHMgYXJlIHN1YmRpdmlkZWQgaW50byB0aHJlZSByYW5nZXMgb2Yg bnVtYmVycywgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDkiPjwvYT48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBTZWN0aW9uIDxzcGFuIGNsYXNzPSJkZWxldGUiPjcuMzwvc3Bh bj4gZGVzY3JpYmVzIHRoZSBJQU5BIHByb2NlZHVyZXMgZm9yIGVhY2ggcmFuZ2UgaW4gZGV0 YWlsOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBTZWN0aW9uIDxzcGFu IGNsYXNzPSJpbnNlcnQiPjguMS4xPC9zcGFuPiBkZXNjcmliZXMgdGhlIElBTkEgcHJvY2Vk dXJlcyBmb3IgZWFjaCByYW5nZSBpbiBkZXRhaWw6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIHRoZSBTeXN0ZW0gUG9ydHMsIGFsc28ga25vd24g YXMgdGhlIFdlbGwgS25vd24gUG9ydHMsIGZyb20gMC0xMDIzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgbyAgdGhlIFN5c3RlbSBQb3J0cywgYWxzbyBrbm93biBhcyB0 aGUgV2VsbCBLbm93biBQb3J0cywgZnJvbSAwLTEwMjM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIChhc3NpZ25lZCBi eSBJQU5BKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIChhc3NpZ25l ZCBieSBJQU5BKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvICB0aGUgVXNlciBQb3J0cywgYWxzbyBrbm93biBhcyB0aGUgUmVnaXN0ZXJlZCBQb3J0 cywgZnJvbSAxMDI0LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIHRo ZSBVc2VyIFBvcnRzLCBhbHNvIGtub3duIGFzIHRoZSBSZWdpc3RlcmVkIFBvcnRzLCBmcm9t IDEwMjQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICA0OTE1MSAoYXNzaWduZWQgYnkgSUFOQSk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICA0OTE1MSAoYXNzaWduZWQgYnkgSUFOQSk8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgdGhlIER5bmFt aWMgUG9ydHMsIGFsc28ga25vd24gYXMgdGhlIFByaXZhdGUgUG9ydHMsIGZyb20gNDkxNTIt PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgdGhlIER5bmFtaWMgUG9y dHMsIGFsc28ga25vd24gYXMgdGhlIFByaXZhdGUgUG9ydHMsIGZyb20gNDkxNTItPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICA2NTUzNSAobmV2ZXIgYXNzaWduZWQpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgNjU1MzUgKG5ldmVyIGFzc2lnbmVkKTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+ PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNSI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDEzLCBsaW5lIDIyPC9lbT48L2E+PC90aD48dGg+IDwvdGg+ PHRoPjxhIG5hbWU9InBhcnQtcjUiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxlbT4gcGFnZSAxMywgbGluZSAyMjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBjb25zZXJ2YXRpdmVseSBtYW5hZ2UgdGhlIGxpbWl0ZWQgcmVtYWlu aW5nIHBvcnQgbnVtYmVyIHNwYWNlIGFuZCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGNvbnNlcnZhdGl2ZWx5IG1hbmFnZSB0aGUgbGltaXRlZCByZW1haW5pbmcg cG9ydCBudW1iZXIgc3BhY2UgYW5kIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBlbmFibGUgYW5kIHByb21vdGUgdGhl IHVzZSBvZiBzZXJ2aWNlIG5hbWVzIGZvciBzZXJ2aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgZW5hYmxlIGFuZCBwcm9tb3RlIHRoZSB1c2Ugb2Ygc2VydmljZSBu YW1lcyBmb3Igc2VydmljZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaWRlbnRpZmljYXRpb24gd2l0aG91dCBhc3NvY2lh dGVkIHBvcnQgbnVtYmVycywgd2hlcmUgcG9zc2libGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgaWRlbnRpZmljYXRpb24gd2l0aG91dCBhc3NvY2lhdGVkIHBvcnQg bnVtYmVycywgd2hlcmUgcG9zc2libGUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjcuMi4gIFVwZGF0ZWQgUHJpbmNpcGxlczwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjcuMi4gIFVwZGF0ZWQgUHJpbmNpcGxlczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHNlY3Rpb24gc3VtbWFyaXpl cyB0aGUgYmFzaWMgcHJpbmNpcGxlcyBieSB3aGljaCBJQU5BIGhhbmRsZXM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIHNlY3Rpb24gc3VtbWFyaXplcyB0aGUg YmFzaWMgcHJpbmNpcGxlcyBieSB3aGljaCBJQU5BIGhhbmRsZXM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBTZXJ2 aWNlIE5hbWUgYW5kIFRyYW5zcG9ydCBQcm90b2NvbCBQb3J0IE51bWJlciBSZWdpc3RyeSwg YW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIFNlcnZpY2UgTmFt ZSBhbmQgVHJhbnNwb3J0IFByb3RvY29sIFBvcnQgTnVtYmVyIFJlZ2lzdHJ5LCBhbmQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGF0dGVtcHRzIHRvIGNvbnNlcnZlIHRoZSBwb3J0IG51bWJlciBzcGFjZS4gIFRoaXMg ZGVzY3JpcHRpb24gaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdHRl bXB0cyB0byBjb25zZXJ2ZSB0aGUgcG9ydCBudW1iZXIgc3BhY2UuICBUaGlzIGRlc2NyaXB0 aW9uIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBpbnRlbmRlZCB0byBpbmZvcm0gYXBwbGljYW50cyByZXF1ZXN0aW5n IHNlcnZpY2UgbmFtZXMgYW5kIHBvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBpbnRlbmRlZCB0byBpbmZvcm0gYXBwbGljYW50cyByZXF1ZXN0aW5nIHNlcnZpY2Ug bmFtZXMgYW5kIHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxMCI+PC9hPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIG51bWJlcnMuICBJQU5BIDxzcGFuIGNsYXNzPSJkZWxldGUi PmRlY2lzaW9uczwvc3Bhbj4gYXJlIG5vdCByZXF1aXJlZCB0byBiZSBib3VuZCBieSB0aGVz ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBudW1iZXJzLiAgSUFOQSBh cmUgbm90IHJlcXVpcmVkIHRvIGJlIGJvdW5kIGJ5IHRoZXNlIDxzcGFuIGNsYXNzPSJpbnNl cnQiPnByaW5jaXBsZXMgd2hlbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+cHJpbmNpcGxlczs8L3NwYW4+IG90aGVyIGZhY3RvcnMgbWF5IGNvbWUgaW50byBwbGF5 LCBhbmQgZXhjZXB0aW9ucyBtYXk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgaGFuZGxpbmcgcmVxdWVzdHM7PC9zcGFuPiBvdGhl ciBmYWN0b3JzIG1heSBjb21lIGludG8gcGxheSwgYW5kIGV4Y2VwdGlvbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg b2NjdXIgd2hlcmUgZGVlbWVkIGluIHRoZSBiZXN0IGludGVyZXN0IG9mIHRoZSBJbnRlcm5l dC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbWF5IG9jY3VyIHdoZXJl IGRlZW1lZCBpbiB0aGUgYmVzdCBpbnRlcmVzdCBvZiB0aGUgSW50ZXJuZXQuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElBTkEgd2lsbCBiZWdpbiBh c3NpZ25pbmcgc2VydmljZSBuYW1lcyB0aGF0IGRvIG5vdCByZXF1ZXN0IGFuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSUFOQSB3aWxsIGJlZ2luIGFzc2lnbmluZyBz ZXJ2aWNlIG5hbWVzIHRoYXQgZG8gbm90IHJlcXVlc3QgYW48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFzc29jaWF0ZWQg cG9ydCBudW1iZXIgYWxsb2NhdGlvbiB1bmRlciBhIHNpbXBsZSAiRmlyc3QgQ29tZSwgRmly c3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhc3NvY2lhdGVkIHBvcnQg bnVtYmVyIGFsbG9jYXRpb24gdW5kZXIgYSBzaW1wbGUgIkZpcnN0IENvbWUsIEZpcnN0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBTZXJ2ZWQiIHBvbGljeSBbUkZDNTIyNl0uICBJQU5BIE1BWSwgYXQgaXRzIGRpc2Ny ZXRpb24sIHJlZmVyIHNlcnZpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBTZXJ2ZWQiIHBvbGljeSBbUkZDNTIyNl0uICBJQU5BIE1BWSwgYXQgaXRzIGRpc2NyZXRp b24sIHJlZmVyIHNlcnZpY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5hbWUgcmVxdWVzdHMgdG8gIkV4cGVydCBSZXZp ZXciIGluIGNhc2VzIG9mIG1hc3MgcmVnaXN0cmF0aW9ucyBvcjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIG5hbWUgcmVxdWVzdHMgdG8gIkV4cGVydCBSZXZpZXciIGlu IGNhc2VzIG9mIG1hc3MgcmVnaXN0cmF0aW9ucyBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3RoZXIgc2l0dWF0aW9u cyB3aGVyZSBJQU5BIGJlbGlldmVzIGV4cGVydCByZXZpZXcgaXMgYWR2aXNhYmxlLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG90aGVyIHNpdHVhdGlvbnMgd2hlcmUg SUFOQSBiZWxpZXZlcyBleHBlcnQgcmV2aWV3IGlzIGFkdmlzYWJsZS48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGJhc2ljIHByaW5jaXBsZSBv ZiBzZXJ2aWNlIG5hbWUgYW5kIHBvcnQgbnVtYmVyIHJlZ2lzdHJ5PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGJhc2ljIHByaW5jaXBsZSBvZiBzZXJ2aWNlIG5h bWUgYW5kIHBvcnQgbnVtYmVyIHJlZ2lzdHJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYW5hZ2VtZW50IGlzIHRvIGNv bnNlcnZlIHVzZSBvZiB0aGUgcG9ydCBzcGFjZSB3aGVyZSBwb3NzaWJsZS48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYW5hZ2VtZW50IGlzIHRvIGNvbnNlcnZlIHVz ZSBvZiB0aGUgcG9ydCBzcGFjZSB3aGVyZSBwb3NzaWJsZS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEV4dGVuc2lvbnMg dG8gc3VwcG9ydCBsYXJnZXIgcG9ydCBudW1iZXIgc3BhY2VzIHdvdWxkIHJlcXVpcmU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFeHRlbnNpb25zIHRvIHN1cHBvcnQg bGFyZ2VyIHBvcnQgbnVtYmVyIHNwYWNlcyB3b3VsZCByZXF1aXJlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0 ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNiI+PHNtYWxs PnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDE1LCBsaW5lIDM2PC9l bT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjYiPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxNSwgbGluZSAzNjwvZW0+PC9h PjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb25zZXJ2YXRpb24gb2YgcG9y dCBudW1iZXJzIGlzIGltcHJvdmVkIGJ5IHByb2NlZHVyZXMgdGhhdCBhbGxvdzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbnNlcnZhdGlvbiBvZiBwb3J0IG51bWJl cnMgaXMgaW1wcm92ZWQgYnkgcHJvY2VkdXJlcyB0aGF0IGFsbG93PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcmV2aW91 c2x5IGFsbG9jYXRlZCBwb3J0IG51bWJlcnMgdG8gYmVjb21lIFVuYXNzaWduZWQsIGVpdGhl cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByZXZpb3VzbHkgYWxsb2Nh dGVkIHBvcnQgbnVtYmVycyB0byBiZWNvbWUgVW5hc3NpZ25lZCwgZWl0aGVyPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 aHJvdWdoIGRlLXJlZ2lzdHJhdGlvbiBvciB0aHJvdWdoIHJldm9jYXRpb24sIGFuZCBieSBh IHByb2NlZHVyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRocm91Z2gg ZGUtcmVnaXN0cmF0aW9uIG9yIHRocm91Z2ggcmV2b2NhdGlvbiwgYW5kIGJ5IGEgcHJvY2Vk dXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB0aGF0IGxldHMgYXBwbGljYXRpb24gZGVzaWduZXJzIHRyYW5zZmVyIGFu IGFsbG9jYXRlZCBidXQgdW51c2VkIHBvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB0aGF0IGxldHMgYXBwbGljYXRpb24gZGVzaWduZXJzIHRyYW5zZmVyIGFuIGFs bG9jYXRlZCBidXQgdW51c2VkIHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG51bWJlciB0byBhIG5ldyBhcHBsaWNh dGlvbi4gIFNlY3Rpb24gOCBkZXNjcmliZXMgdGhlc2UgcHJvY2VkdXJlcyw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBudW1iZXIgdG8gYSBuZXcgYXBwbGljYXRpb24u ICBTZWN0aW9uIDggZGVzY3JpYmVzIHRoZXNlIHByb2NlZHVyZXMsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aGljaCB1 bnRpbCBub3cgd2VyZSB1bmRvY3VtZW50ZWQuICBQb3J0IG51bWJlciBjb25zZXJ2YXRpb24g aXMgYWxzbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdoaWNoIHVudGls IG5vdyB3ZXJlIHVuZG9jdW1lbnRlZC4gIFBvcnQgbnVtYmVyIGNvbnNlcnZhdGlvbiBpcyBh bHNvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBpbXByb3ZlZCBieSByZWNvbW1lbmRpbmcgdGhhdCBhcHBsaWNhdGlvbnMg dGhhdCBkbyBub3QgcmVxdWlyZSBhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGltcHJvdmVkIGJ5IHJlY29tbWVuZGluZyB0aGF0IGFwcGxpY2F0aW9ucyB0aGF0IGRv IG5vdCByZXF1aXJlIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbGxvY2F0ZWQgcG9ydCBzaG91bGQgcmVnaXN0ZXIg b25seSBhIHNlcnZpY2UgbmFtZSB3aXRob3V0IGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYWxsb2NhdGVkIHBvcnQgc2hvdWxkIHJlZ2lzdGVyIG9ubHkgYSBzZXJ2 aWNlIG5hbWUgd2l0aG91dCBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXNzb2NpYXRlZCBwb3J0IG51bWJlci48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhc3NvY2lhdGVkIHBvcnQgbnVtYmVy LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFt ZT0iZGlmZjAwMTEiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj43LjMuICBWYXJpYW5jZXMgZm9yIFNwZWNpZmljIFBvcnQgTnVtYmVyIFJhbmdl czwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIFNlY3Rpb24gNiBkZXNjcmliZXMg dGhlIGRpZmZlcmVudCBwb3J0IG51bWJlciByYW5nZXMuICBJdCBpczwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PiAgIGltcG9ydGFudCB0byBub3RlIHRoYXQgSUFOQSBhcHBsaWVzIHNsaWdodGx5IGRpZmZl cmVudCBwcm9jZWR1cmVzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgd2hlbiBtYW5hZ2luZyB0aGUgZGlm ZmVyZW50IHBvcnQgcmFuZ2VzIG9mIHRoZSBzZXJ2aWNlIG5hbWUgYW5kIHBvcnQ8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICBudW1iZXIgcmVnaXN0cnk6PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ICAgbyAgUG9ydHMgaW4gdGhlIER5bmFtaWMgUG9ydHMgcmFuZ2UgKDQ5MTUyLTY1NTM1 KSBoYXZlIGJlZW48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICBzcGVjaWZpY2FsbHkgc2V0IGFzaWRl IGZvciBsb2NhbCBhbmQgZHluYW1pYyB1c2UgYW5kIGNhbm5vdCBiZTwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi PiAgICAgIGFzc2lnbmVkIHRocm91Z2ggSUFOQS4gIEFwcGxpY2F0aW9uIHNvZnR3YXJlIG1h eSBzaW1wbHkgdXNlIHRoZW08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICBmb3IgY29tbXVuaWNhdGlv biB3aXRob3V0IGFueSBzb3J0IG9mIHJlZ2lzdHJhdGlvbi4gIE9uIHRoZSBvdGhlcjwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgICAgIGhhbmQsIGFwcGxpY2F0aW9uIHNvZnR3YXJlIE1VU1QgTk9UIGFz c3VtZSB0aGF0IGEgc3BlY2lmaWMgcG9ydDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgIG51bWJlciBp biB0aGUgRHluYW1pYyBQb3J0cyByYW5nZSB3aWxsIGFsd2F5cyBiZSBhdmFpbGFibGUgZm9y PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ICAgICAgY29tbXVuaWNhdGlvbiBhdCBhbGwgdGltZXMsIGFuZCBh IHBvcnQgbnVtYmVyIGluIHRoYXQgcmFuZ2UgaGVuY2U8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICBN VVNUIE5PVCBiZSB1c2VkIGFzIGEgc2VydmljZSBpZGVudGlmaWVyLjwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi Pjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPiAgIG8gIFBvcnRzIGluIHRoZSBVc2VyIFBvcnRzIHJhbmdlICgx MDI0LTQ5MTUxKSBhcmUgYXZhaWxhYmxlIGZvcjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgIHJlZ2lz dHJhdGlvbiB0aHJvdWdoIElBTkEsIGFuZCBNQVkgYmUgdXNlZCBhcyBzZXJ2aWNlIGlkZW50 aWZpZXJzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgdXBvbiBzdWNjZXNzZnVsIHJlZ2lzdHJhdGlv bi4gIEJlY2F1c2UgcmVnaXN0ZXJpbmcgYSBwb3J0IG51bWJlcjwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAg ICAgIGZvciBhIHNwZWNpZmljIGFwcGxpY2F0aW9uIGNvbnN1bWVzIGEgZnJhY3Rpb24gb2Yg dGhlIHNoYXJlZDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgIHJlc291cmNlIHRoYXQgaXMgdGhlIHBv cnQgbnVtYmVyIHJlZ2lzdHJ5LCBJQU5BIHdpbGwgcmVxdWlyZSB0aGU8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICAgICByZXF1ZXN0ZXIgdG8gZG9jdW1lbnQgdGhlIGludGVuZGVkIHVzZSBvZiB0aGUg cG9ydCBudW1iZXIuICBUaGlzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgZG9jdW1lbnRhdGlvbiB3 aWxsIGJlIGlucHV0IHRvIHRoZSAiRXhwZXJ0IFJldmlldyIgYWxsb2NhdGlvbjwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgICAgIHByb2NlZHVyZSBbUkZDNTIyNl0sIGJ5IHdoaWNoIElBTkEgd2lsbCBo YXZlIGEgdGVjaG5pY2FsIGV4cGVydDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgIHJldmlldyB0aGUg cmVxdWVzdCB0byBkZXRlcm1pbmUgd2hldGhlciB0byBncmFudCB0aGUgcmVnaXN0cmF0aW9u Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPiAgICAgIFRoZSBzdWJtaXR0ZWQgZG9jdW1lbnRhdGlvbiBNVVNU IGV4cGxhaW4gd2h5IHVzaW5nIGEgcG9ydCBudW1iZXI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICBp biB0aGUgRHluYW1pYyBQb3J0cyByYW5nZSBpcyB1bnN1aXRhYmxlIGZvciB0aGUgZ2l2ZW48 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBj bGFzcz0iZGVsZXRlIj4gICAgICBhcHBsaWNhdGlvbi4gIFBvcnRzIGluIHRoZSBVc2VyIFBv cnRzIHJhbmdlIG1heSBhbHNvIGJlIGFzc2lnbmVkPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgdW5k ZXIgdGhlICJJRVRGIFJldmlldyIgb3IgIklFU0cgQXBwcm92YWwiIGFsbG9jYXRpb24gcHJv Y2VkdXJlczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgIFtSRkM1MjI2XSwgd2hpY2ggaXMgaG93IG1v c3QgYXNzaWdubWVudHMgZm9yIElFVEYgcHJvdG9jb2xzIGFyZTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAg ICAgIGhhbmRsZWQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgbyAgUG9ydHMg aW4gdGhlIFN5c3RlbSBQb3J0cyByYW5nZSAoMC0xMDIzKSBhcmUgYWxzbyBhdmFpbGFibGUg Zm9yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgcmVnaXN0cmF0aW9uIHRocm91Z2ggSUFOQS4gIEJl Y2F1c2UgdGhlIFN5c3RlbSBQb3J0cyByYW5nZSBpcyBib3RoPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg ICAgdGhlIHNtYWxsZXN0IGFuZCB0aGUgbW9zdCBkZW5zZWx5IGFsbG9jYXRlZCwgdGhlIHJl cXVpcmVtZW50cyBmb3I8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICBuZXcgYWxsb2NhdGlvbnMgYXJl IG1vcmUgc3RyaWN0IHRoYW4gdGhvc2UgZm9yIHRoZSBVc2VyIFBvcnRzPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ICAgICAgcmFuZ2UsIGFuZCB3aWxsIG9ubHkgYmUgZ3JhbnRlZCB1bmRlciB0aGUgIklF VEYgUmV2aWV3IiBvciAiSUVTRzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgIEFwcHJvdmFsIiBhbGxv Y2F0aW9uIHByb2NlZHVyZXMgW1JGQzUyMjZdLiAgQSByZXF1ZXN0IGZvciBhIFN5c3RlbTwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgICAgIFBvcnQgbnVtYmVyIE1VU1QgZG9jdW1lbnQgKmJvdGgqIHdo eSB1c2luZyBhIHBvcnQgbnVtYmVyIGZyb20gdGhlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgVXNl ciBQb3J0cyBpcyB1bnN1aXRhYmxlICphbmQqIHdoeSB1c2luZyBhIHBvcnQgbnVtYmVyIGZy b20gdGhlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgRHluYW1pYyBQb3J0cyByYW5nZXMgaXMgdW5z dWl0YWJsZSBmb3IgdGhhdCBhcHBsaWNhdGlvbi48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+OC4gIElBTkEgUHJvY2VkdXJlcyBmb3IgTWFu YWdpbmcgdGhlIFNlcnZpY2UgTmFtZSBhbmQgVHJhbnNwb3J0IFByb3RvY29sPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OC4gIElBTkEgUHJvY2VkdXJlcyBmb3IgTWFuYWdp bmcgdGhlIFNlcnZpY2UgTmFtZSBhbmQgVHJhbnNwb3J0IFByb3RvY29sPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgUG9y dCBOdW1iZXIgUmVnaXN0cnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg UG9ydCBOdW1iZXIgUmVnaXN0cnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcHJvY2VzcyBmb3IgaGFu ZGxpbmcgcmVxdWVzdHMgYXNzb2NpYXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHByb2Nlc3MgZm9yIGhhbmRsaW5n IHJlcXVlc3RzIGFzc29jaWF0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdpdGggSUFOQSdzIG1hbmFnZW1lbnQgb2Yg dGhlIFNlcnZpY2UgTmFtZSBhbmQgVHJhbnNwb3J0IFByb3RvY29sPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgd2l0aCBJQU5BJ3MgbWFuYWdlbWVudCBvZiB0aGUgU2Vy dmljZSBOYW1lIGFuZCBUcmFuc3BvcnQgUHJvdG9jb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBvcnQgTnVtYmVyIFJl Z2lzdHJ5LiAgU3VjaCByZXF1ZXN0cyBpbmNsdWRlIGluaXRpYWwgcmVnaXN0cmF0aW9uLDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBvcnQgTnVtYmVyIFJlZ2lzdHJ5 LiAgU3VjaCByZXF1ZXN0cyBpbmNsdWRlIGluaXRpYWwgcmVnaXN0cmF0aW9uLDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZGUtcmVnaXN0cmF0aW9uLCByZS11c2UsIGNoYW5nZXMgdG8gdGhlIHNlcnZpY2UgbmFtZSwg YW5kIHVwZGF0ZXMgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZS1y ZWdpc3RyYXRpb24sIHJlLXVzZSwgY2hhbmdlcyB0byB0aGUgc2VydmljZSBuYW1lLCBhbmQg dXBkYXRlcyB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gb3IgZGVzY3JpcHRp b24gYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbm1lbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gb3IgZGVzY3JpcHRpb24g YXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbm1lbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBSZXZvY2F0aW9uIGlzIGFz IGFkZGl0aW9uYWwgcHJvY2VzcywgaW5pdGlhdGVkIGJ5IElBTkEuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgUmV2b2NhdGlvbiBpcyBhcyBhZGRpdGlvbmFsIHByb2Nl c3MsIGluaXRpYXRlZCBieSBJQU5BLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij44LjEuICBTZXJ2aWNlIE5hbWUgYW5kIFBvcnQgTnVtYmVyIFJlZ2lzdHJh dGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjguMS4gIFNlcnZpY2UgTmFt ZSBhbmQgUG9ydCBOdW1iZXIgUmVnaXN0cmF0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJlZ2lzdHJhdGlvbiByZWZlcnMgdG8gdGhlIGFsbG9j YXRpb24gb2Ygc2VydmljZSBuYW1lcyBvciBwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgUmVnaXN0cmF0aW9uIHJlZmVycyB0byB0aGUgYWxsb2NhdGlvbiBvZiBz ZXJ2aWNlIG5hbWVzIG9yIHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG51bWJlcnMgdG8gYXBwbGljYW50cy4gIEFs bCBzdWNoIHJlZ2lzdHJhdGlvbnMgYXJlIG1hZGUgZnJvbSBzZXJ2aWNlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbnVtYmVycyB0byBhcHBsaWNhbnRzLiAgQWxsIHN1 Y2ggcmVnaXN0cmF0aW9ucyBhcmUgbWFkZSBmcm9tIHNlcnZpY2U8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5hbWVzIG9y IHBvcnQgbnVtYmVycyB0aGF0IGFyZSBVbmFzc2lnbmVkIG9yIFJlc2VydmVkIGF0IHRoZSB0 aW1lIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbmFtZXMgb3IgcG9y dCBudW1iZXJzIHRoYXQgYXJlIFVuYXNzaWduZWQgb3IgUmVzZXJ2ZWQgYXQgdGhlIHRpbWUg b2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRoZSBhbGxvY2F0aW9uLiAgVW5hc3NpZ25lZCBuYW1lcyBhbmQgbnVtYmVy cyBhcmUgYWxsb2NhdGVkIGFjY29yZGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHRoZSBhbGxvY2F0aW9uLiAgVW5hc3NpZ25lZCBuYW1lcyBhbmQgbnVtYmVycyBh cmUgYWxsb2NhdGVkIGFjY29yZGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEyIj48L2E+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdG8gdGhlIHJ1bGVzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDxzcGFuIGNsYXNzPSJkZWxldGUiPjcuMy48L3NwYW4+ICBSZXNlcnZlZCBudW1i ZXJzIGFuZCBuYW1lczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0byB0 aGUgcnVsZXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gPHNwYW4gY2xhc3M9Imluc2VydCI+OC4x LjEgYmVsb3cuPC9zcGFuPiAgUmVzZXJ2ZWQgbnVtYmVycyBhbmQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYXJlIGFz c2lnbmVkIG9ubHkgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YWZ0ZXIgcmV2aWV3PC9zcGFuPiBi eSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5JQU5BPC9zcGFuPiBhbmQgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+dGhlIElFVEYsIGFuZCBhcmU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIG5hbWVzIGFyZSBhc3NpZ25lZCBvbmx5IGJ5IDxzcGFuIGNsYXNzPSJp bnNlcnQiPlN0YW5kYXJkcyBBY3Rpb24gb3IgSUVTRyBBcHByb3ZhbCw8L3NwYW4+IGFuZDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBhY2NvbXBhbmllZCBieSBhIHN0YXRlbWVudCBleHBsYWluaW5nIHRoZSByZWFz b24gYSBSZXNlcnZlZCBudW1iZXIgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+TVVTVDwvc3Bhbj4gYWNjb21wYW5pZWQgYnkg YSBzdGF0ZW1lbnQgZXhwbGFpbmluZyB0aGUgcmVhc29uIGEgUmVzZXJ2ZWQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg bmFtZSBpcyBhcHByb3ByaWF0ZSBmb3IgdGhpcyBhY3Rpb24uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIG51bWJlciBvciBuYW1lIGlzIGFwcHJvcHJpYXRlIGZvciB0 aGlzIGFjdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgV2hlbiBhIHJlZ2lzdHJhdGlvbiBmb3Igb25lIG9yIG1vcmUgdHJhbnNwb3J0IHByb3Rv Y29scyBpcyBhcHByb3ZlZCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBX aGVuIGEgcmVnaXN0cmF0aW9uIGZvciBvbmUgb3IgbW9yZSB0cmFuc3BvcnQgcHJvdG9jb2xz IGlzIGFwcHJvdmVkLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHBvcnQgbnVtYmVyIGZvciBhbnkgbm9uLXJlcXVl c3RlZCB0cmFuc3BvcnQgcHJvdG9jb2wocykgd2lsbCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHRoZSBwb3J0IG51bWJlciBmb3IgYW55IG5vbi1yZXF1ZXN0ZWQg dHJhbnNwb3J0IHByb3RvY29sKHMpIHdpbGwgYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hcmtlZCBhcyBSZXNlcnZl ZC4gIElBTkEgU0hPVUxEIE5PVCBhc3NpZ24gdGhhdCBwb3J0IG51bWJlciB0byBhbnk8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXJrZWQgYXMgUmVzZXJ2ZWQuICBJ QU5BIFNIT1VMRCBOT1QgYXNzaWduIHRoYXQgcG9ydCBudW1iZXIgdG8gYW55PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBv dGhlciBhcHBsaWNhdGlvbiBvciBzZXJ2aWNlIHVudGlsIG5vIG90aGVyIHBvcnQgbnVtYmVy cyByZW1haW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvdGhlciBhcHBs aWNhdGlvbiBvciBzZXJ2aWNlIHVudGlsIG5vIG90aGVyIHBvcnQgbnVtYmVycyByZW1haW48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFVuYXNzaWduZWQgaW4gdGhlIHJlcXVlc3RlZCByYW5nZS4gIFRoZSBjdXJyZW50 IFJlZ2lzdHJhbnQgZm9yIGEgcG9ydDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFVuYXNzaWduZWQgaW4gdGhlIHJlcXVlc3RlZCByYW5nZS4gIFRoZSBjdXJyZW50IFJl Z2lzdHJhbnQgZm9yIGEgcG9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbnVtYmVyIE1BWSByZWdpc3RlciB0aGVzZSBS ZXNlcnZlZCBwb3J0IG51bWJlcnMgZm9yIG90aGVyIHRyYW5zcG9ydDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG51bWJlciBNQVkgcmVnaXN0ZXIgdGhlc2UgUmVzZXJ2 ZWQgcG9ydCBudW1iZXJzIGZvciBvdGhlciB0cmFuc3BvcnQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3RvY29scyB3 aGVuIG5lZWRlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm90b2Nv bHMgd2hlbiBuZWVkZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEEgc2VydmljZSBuYW1lIG9yIHBvcnQgbnVtYmVyIHJlZ2lzdHJhdGlvbiByZXF1 ZXN0IGNvbnRhaW5zIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEEg c2VydmljZSBuYW1lIG9yIHBvcnQgbnVtYmVyIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IGNvbnRh aW5zIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxh IG5hbWU9InBhcnQtbDciPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxl bT4gcGFnZSAxOCwgbGluZSA1PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9 InBhcnQtcjciPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFn ZSAxNywgbGluZSAxMDwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IE1VU1QgYmUg cHJvdmlkZWQsIGZvciB1c2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBhc3NvY2lhdGVkIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IE1VU1QgYmUgcHJv dmlkZWQsIGZvciB1c2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGluIHZhcmlvdXMgc2VydmljZSBzZWxlY3Rpb24g YW5kIGRpc2NvdmVyeSBtZWNoYW5pc21zIChpbmNsdWRpbmcsPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgaW4gdmFyaW91cyBzZXJ2aWNlIHNlbGVjdGlvbiBhbmQg ZGlzY292ZXJ5IG1lY2hhbmlzbXMgKGluY2x1ZGluZyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGJ1dCBub3QgbGlt aXRlZCB0bywgRE5TIFNSViByZWNvcmRzIFtSRkMyNzgyXSkuICBUaGUgbmFtZSBNVVNUIGJl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYnV0IG5vdCBsaW1pdGVk IHRvLCBETlMgU1JWIHJlY29yZHMgW1JGQzI3ODJdKS4gIFRoZSBuYW1lIE1VU1QgYmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIGNvbXBsaWFudCB3aXRoIHRoZSBzeW50YXggZGVmaW5lZCBpbiBTZWN0aW9uIDUu MS4gIEluIG9yZGVyIHRvIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgY29tcGxpYW50IHdpdGggdGhlIHN5bnRheCBkZWZpbmVkIGluIFNlY3Rpb24gNS4xLiAg SW4gb3JkZXIgdG8gYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHVuaXF1ZSwgdGhleSBNVVNUIE5PVCBiZSBpZGVu dGljYWwgdG8gYW55IGN1cnJlbnRseSBhc3NpZ25lZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIHVuaXF1ZSwgdGhleSBNVVNUIE5PVCBiZSBpZGVudGljYWwgdG8g YW55IGN1cnJlbnRseSBhc3NpZ25lZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgc2VydmljZSBuYW1lIGluIHRoZSBJ QU5BIHJlZ2lzdHJ5IFtQT1JUUkVHXS4gIFNlcnZpY2UgbmFtZXMgYXJlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgc2VydmljZSBuYW1lIGluIHRoZSBJQU5BIHJl Z2lzdHJ5IFtQT1JUUkVHXS4gIFNlcnZpY2UgbmFtZXMgYXJlPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBjYXNlLWlu c2Vuc2l0aXZlOyB0aGV5IG1heSBiZSBwcm92aWRlZCBhbmQgZW50ZXJlZCBpbnRvIHRoZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGNhc2UtaW5zZW5zaXRpdmU7 IHRoZXkgbWF5IGJlIHByb3ZpZGVkIGFuZCBlbnRlcmVkIGludG8gdGhlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBy ZWdpc3RyeSB3aXRoIG1peGVkIGNhc2UgZm9yIGNsYXJpdHksIGJ1dCBmb3IgdGhlIGNvbXBh cmlzb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICByZWdpc3RyeSB3 aXRoIG1peGVkIGNhc2UgZm9yIGNsYXJpdHksIGJ1dCBmb3IgdGhlIGNvbXBhcmlzb248L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIHB1cnBvc2VzIHRoZSBjYXNlIGlzIGlnbm9yZWQuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgcHVycG9zZXMgdGhlIGNhc2UgaXMgaWdub3JlZC48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRp ZmYwMDEzIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgVHJhbnNwb3J0IFBy b3RvY29sKHMpOiBUaGUgdHJhbnNwb3J0IHByb3RvY29sKHMpIGZvciB3aGljaCA8c3BhbiBj bGFzcz0iZGVsZXRlIj50aGU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIG8gIFRyYW5zcG9ydCBQcm90b2NvbChzKTogVGhlIHRyYW5zcG9ydCBwcm90b2Nv bChzKSBmb3Igd2hpY2ggPHNwYW4gY2xhc3M9Imluc2VydCI+YTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IGFsbG9jYXRpb24gaXMgcmVxdWVzdGVkIE1VU1QgYmUgcHJvdmlkZWQuICBUaGlzIGZpZWxk IGlzIGN1cnJlbnRseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGFs bG9jYXRpb24gaXMgcmVxdWVzdGVkIE1VU1QgYmUgcHJvdmlkZWQuICBUaGlzIGZpZWxkIGlz IGN1cnJlbnRseTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE0Ij48L2E+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICAgbGltaXRlZCB0byBvbmUgb3IgbW9yZSBvZiBUQ1AsIFVEUCwg U0NUUCwgYW5kIERDQ1AuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGlzIGZpZWxkIGlzPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBsaW1pdGVkIHRv IG9uZSBvciBtb3JlIG9mIFRDUCwgVURQLCBTQ1RQLCBhbmQgRENDUC4gIDxzcGFuIGNsYXNz PSJpbnNlcnQiPlJlcXVlc3RzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4g ICAgICByZXF1aXJlZCBldmVuIGZvciBzZXJ2aWNlcyB3aXRoIG5vPC9zcGFuPiBwb3J0IDxz cGFuIGNsYXNzPSJkZWxldGUiPm51bWJlci48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIHdpdGhvdXQgYW55PC9z cGFuPiBwb3J0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmFsbG9jYXRpb24gYW5kIG9ubHkgYSBz ZXJ2aWNlIG5hbWUgYXJlIHN0aWxsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgcmVxdWlyZWQgdG8g aW5kaWNhdGUgd2hpY2ggcHJvdG9jb2wgdGhlIHNlcnZpY2UgdXNlcy48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFJlZ2lzdHJhbnQ6 IE5hbWUgYW5kIGVtYWlsIGFkZHJlc3Mgb2YgdGhlIFJlZ2lzdHJhbnQuICBUaGlzIGlzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgUmVnaXN0cmFudDogTmFtZSBh bmQgZW1haWwgYWRkcmVzcyBvZiB0aGUgUmVnaXN0cmFudC4gIFRoaXMgaXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IFJFUVVJUkVELiAgVGhlIFJlZ2lzdHJhbnQgaXMgdGhlIE9yZ2FuaXphdGlvbiBvciBDb21w YW55PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgUkVRVUlSRUQuICBU aGUgUmVnaXN0cmFudCBpcyB0aGUgT3JnYW5pemF0aW9uIG9yIENvbXBhbnk8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IHJlc3BvbnNpYmxlIGZvciB0aGUgaW5pdGlhbCByZWdpc3RyYXRpb24uICBGb3IgcmVnaXN0 cmF0aW9ucyBkb25lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgcmVz cG9uc2libGUgZm9yIHRoZSBpbml0aWFsIHJlZ2lzdHJhdGlvbi4gIEZvciByZWdpc3RyYXRp b25zIGRvbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIHRocm91Z2ggSUVURi1wdWJsaXNoZWQgUkZDcywgdGhlIFJl Z2lzdHJhbnQgd2lsbCBiZSB0aGUgSUVTRy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICB0aHJvdWdoIElFVEYtcHVibGlzaGVkIFJGQ3MsIHRoZSBSZWdpc3RyYW50 IHdpbGwgYmUgdGhlIElFU0cuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG8gIENvbnRhY3Q6IE5hbWUgYW5kIGVtYWlsIGFkZHJlc3Mgb2YgdGhlIENv bnRhY3QgcGVyc29uIGZvciB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBvICBDb250YWN0OiBOYW1lIGFuZCBlbWFpbCBhZGRyZXNzIG9mIHRoZSBDb250YWN0IHBl cnNvbiBmb3IgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICByZWdpc3RyYXRpb24uICBUaGlzIGlzIFJFUVVJUkVE LiAgVGhlIENvbnRhY3QgcGVyc29uIGlzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgIHJlZ2lzdHJhdGlvbi4gIFRoaXMgaXMgUkVRVUlSRUQuICBUaGUgQ29u dGFjdCBwZXJzb24gaXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICByZXNwb25zaWJsZSBwZXJzb24gZm9yIHRo ZSBJbnRlcm5ldCBjb21tdW5pdHkgdG8gc2VuZCBxdWVzdGlvbnM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICByZXNwb25zaWJsZSBwZXJzb24gZm9yIHRoZSBJbnRl cm5ldCBjb21tdW5pdHkgdG8gc2VuZCBxdWVzdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRvLiAgVGhpcyBw ZXJzb24gd291bGQgYWxzbyBiZSBhdXRob3JpemVkIHRvIHN1Ym1pdCBjaGFuZ2VzIG9uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdG8uICBUaGlzIHBlcnNvbiB3 b3VsZCBhbHNvIGJlIGF1dGhvcml6ZWQgdG8gc3VibWl0IGNoYW5nZXMgb248L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAg ICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWw4Ij48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTksIGxpbmUg NzwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI4Ij48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTgsIGxpbmUgMTI8L2Vt PjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgRm9yIHJlZ2lzdHJh dGlvbiByZXF1ZXN0cyBmb3IgYSBTeXN0ZW0gUG9ydCwgdGhlIHJlZ2lzdHJhdGlvbjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIEZvciByZWdpc3RyYXRpb24gcmVx dWVzdHMgZm9yIGEgU3lzdGVtIFBvcnQsIHRoZSByZWdpc3RyYXRpb248L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHJl cXVlc3QgTVVTVCBleHBsYWluIHdoeSBhIHBvcnQgbnVtYmVyIGluIHRoZSBVc2VyIFBvcnRz IG9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgcmVxdWVzdCBNVVNU IGV4cGxhaW4gd2h5IGEgcG9ydCBudW1iZXIgaW4gdGhlIFVzZXIgUG9ydHMgb3I8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIER5bmFtaWMgUG9ydHMgcmFuZ2VzIGlzIHVuc3VpdGFibGUsIGFuZCBhIHJlZmVyZW5j ZSB0byBhIHN0YWJsZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIER5 bmFtaWMgUG9ydHMgcmFuZ2VzIGlzIHVuc3VpdGFibGUsIGFuZCBhIHJlZmVyZW5jZSB0byBh IHN0YWJsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBkb2N1bWVudCBNVVNU IGJlIHByb3ZpZGVkLiAgRm9yIHJlcXVlc3RzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBkb2N1bWVudCBNVVNUIGJlIHBy b3ZpZGVkLiAgRm9yIHJlcXVlc3RzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBmcm9tIElFVEYgV29ya2luZyBHcm91 cHMsIElBTkEgTUFZIGFjY2VwdCAiZWFybHkgcmVnaXN0cmF0aW9uIjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGZyb20gSUVURiBXb3JraW5nIEdyb3VwcywgSUFO QSBNQVkgYWNjZXB0ICJlYXJseSByZWdpc3RyYXRpb24iPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBbUkZDNDAyMF0g cmVxdWVzdHMgcmVmZXJlbmNpbmcgYSBzdWZmaWNpZW50bHkgc3RhYmxlIEludGVybmV0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgW1JGQzQwMjBdIHJlcXVlc3Rz IHJlZmVyZW5jaW5nIGEgc3VmZmljaWVudGx5IHN0YWJsZSBJbnRlcm5ldDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg RHJhZnQgaW5zdGVhZCBvZiBhIHB1Ymxpc2hlZCBTdGFuZGFyZHMtVHJhY2sgUkZDLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERyYWZ0IGluc3RlYWQgb2YgYSBw dWJsaXNoZWQgU3RhbmRhcmRzLVRyYWNrIFJGQy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgUG9ydCBOdW1iZXI6IElmIGFzc2lnbm1lbnQgb2Yg YSBwb3J0IG51bWJlciBpcyBkZXNpcmVkLCBlaXRoZXIgdGhlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgbyAgUG9ydCBOdW1iZXI6IElmIGFzc2lnbm1lbnQgb2YgYSBw b3J0IG51bWJlciBpcyBkZXNpcmVkLCBlaXRoZXIgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBjdXJyZW50bHkg VW5hc3NpZ25lZCBvciBSZXNlcnZlZCBwb3J0IG51bWJlciB0aGUgcmVxdWVzdGVyPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgY3VycmVudGx5IFVuYXNzaWduZWQg b3IgUmVzZXJ2ZWQgcG9ydCBudW1iZXIgdGhlIHJlcXVlc3RlcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDE1Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgc3VnZ2VzdHMg Zm9yIGFsbG9jYXRpb24sIG9yIHRoZSB0ZXh0IDxzcGFuIGNsYXNzPSJkZWxldGUiPiJBTlki LDwvc3Bhbj4gTVVTVCBiZSBwcm92aWRlZC4gIElmPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgIHN1Z2dlc3RzIGZvciBhbGxvY2F0aW9uLCBvciB0aGUgdGV4dCA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4iVVNFUiIgZm9yIGEgcG9ydCBpbiB0aGUgVXNlcjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgb25seSBhIHNlcnZpY2UgbmFtZSBpcyB0byBiZSBhc3NpZ25lZCwg dGhpcyBmaWVsZCBNVVNUIGJlIGVtcHR5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBQb3J0IHJhbmdlLCBvciB0aGUgdGV4 dCAiU1lTIiBmb3IgYSBwb3J0IGluIHRoZSBTeXN0ZW0gUG9ydCByYW5nZSw8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgIElmIGEgc3BlY2lmaWMgcG9ydCBudW1iZXIgaXMgcmVxdWVzdGVkLCBJQU5B IGlzIGVuY291cmFnZWQgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgTVVTVCBiZSBwcm92aWRlZC4gIElmIG9ubHkgYSBzZXJ2aWNlIG5hbWUgaXMgdG8gYmUg YXNzaWduZWQsIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgYWxsb2NhdGUgdGhlIHJlcXVlc3RlZCBudW1i ZXIuICBJZiB0aGUgdGV4dCA8c3BhbiBjbGFzcz0iZGVsZXRlIj4iQU5ZIjwvc3Bhbj4gaXMg c3BlY2lmaWVkLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBmaWVs ZCBNVVNUIGJlIGVtcHR5LiAgSWYgYSBzcGVjaWZpYyBwb3J0IG51bWJlciBpcyByZXF1ZXN0 ZWQsIElBTkE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgSUFOQSB3aWxsIGNob29zZSBhIHN1aXRhYmxlIG51bWJl ciBmcm9tIHRoZSBVc2VyIFBvcnRzIDxzcGFuIGNsYXNzPSJkZWxldGUiPnJhbmdlLjwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgaXMgZW5jb3VyYWdl ZCB0byBhbGxvY2F0ZSB0aGUgcmVxdWVzdGVkIG51bWJlci4gIElmIHRoZSB0ZXh0PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgIE5vdGUgdGhhdCB0aGUgYXBwbGljYW50IE1VU1QgTk9UIHVzZSB0aGUgcmVxdWVz dGVkIHBvcnQgcHJpb3IgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+IlVTRVIiIG9yICJTWVMiPC9zcGFuPiBpcyBzcGVj aWZpZWQsIElBTkEgd2lsbCBjaG9vc2UgYSBzdWl0YWJsZSBudW1iZXI8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg dGhlIGNvbXBsZXRpb24gb2YgdGhlIHJlZ2lzdHJhdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICAgZnJvbSB0aGUgVXNlciA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5vciBTeXN0ZW08L3NwYW4+IFBvcnRzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnJhbmdlcy48 L3NwYW4+ICBOb3RlIHRoYXQgdGhlIGFwcGxpY2FudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgTVVTVCBOT1QgdXNlIHRoZSByZXF1ZXN0ZWQgcG9y dCBwcmlvciB0byB0aGUgY29tcGxldGlvbiBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIHJlZ2lzdHJhdGlvbi48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgU2VydmljZSBDb2RlOiBJZiB0aGUg cmVnaXN0cmF0aW9uIHJlcXVlc3QgaW5jbHVkZXMgRENDUCBhcyBhPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgU2VydmljZSBDb2RlOiBJZiB0aGUgcmVnaXN0cmF0 aW9uIHJlcXVlc3QgaW5jbHVkZXMgRENDUCBhcyBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0cmFuc3BvcnQgcHJv dG9jb2wgdGhlbiB0aGUgcmVxdWVzdCBNVVNUIGluY2x1ZGUgYSBkZXNpcmVkIHVuaXF1ZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHRyYW5zcG9ydCBwcm90b2Nv bCB0aGVuIHRoZSByZXF1ZXN0IE1VU1QgaW5jbHVkZSBhIGRlc2lyZWQgdW5pcXVlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICBEQ0NQIHNlcnZpY2UgY29kZSBbUkZDNTU5NV0sIGFuZCBNVVNUIE5PVCBpbmNsdWRl IGEgcmVxdWVzdGVkIERDQ1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBEQ0NQIHNlcnZpY2UgY29kZSBbUkZDNTU5NV0sIGFuZCBNVVNUIE5PVCBpbmNsdWRlIGEg cmVxdWVzdGVkIERDQ1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHNlcnZpY2UgY29kZSBvdGhlcndpc2UuICBTZWN0 aW9uIDE5Ljggb2YgdGhlIERDQ1Agc3BlY2lmaWNhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIHNlcnZpY2UgY29kZSBvdGhlcndpc2UuICBTZWN0aW9uIDE5 Ljggb2YgdGhlIERDQ1Agc3BlY2lmaWNhdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgW1JGQzQzNDBdIGRlZmlu ZXMgcmVxdWlyZW1lbnRzIGFuZCBydWxlcyBmb3IgYWxsb2NhdGlvbiwgdXBkYXRlZDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFtSRkM0MzQwXSBkZWZpbmVzIHJl cXVpcmVtZW50cyBhbmQgcnVsZXMgZm9yIGFsbG9jYXRpb24sIHVwZGF0ZWQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IGJ5IHRoaXMgZG9jdW1lbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgYnkgdGhpcyBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgbyAgS25vd24gVW5hdXRob3JpemVkIFVzZXM6IEEgbGlzdCBvZiB1c2Vz IGJ5IGFwcGxpY2F0aW9ucyBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG8gIEtub3duIFVuYXV0aG9yaXplZCBVc2VzOiBBIGxpc3Qgb2YgdXNlcyBieSBhcHBsaWNh dGlvbnMgb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIG9yZ2FuaXphdGlvbnMgd2hvIGFyZSBub3QgdGhlIGFzc2ln bmVlLiAgVGhpcyBsaXN0IG1heSBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgIG9yZ2FuaXphdGlvbnMgd2hvIGFyZSBub3QgdGhlIGFzc2lnbmVlLiAgVGhpcyBs aXN0IG1heSBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+DQogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRo PjxhIG5hbWU9InBhcnQtbDkiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxs PjxlbT4gcGFnZSAxOSwgbGluZSAzNzwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBu YW1lPSJwYXJ0LXI5Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgMTgsIGxpbmUgNDQ8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgbyAgQXNzaWdubWVudCBOb3RlczogSW5kaWNhdGlvbnMgb2Ygb3duZXIvbmFtZSBj aGFuZ2UsIG9yIGFueSBvdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG8gIEFzc2lnbm1lbnQgTm90ZXM6IEluZGljYXRpb25zIG9mIG93bmVyL25hbWUgY2hhbmdl LCBvciBhbnkgb3RoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGFzc2lnbm1lbnQgcHJvY2VzcyBpc3N1ZS4gIFRo aXMgbGlzdCBtYXkgYmUgdXBkYXRlZCBieSBJQU5BIGFmdGVyPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgYXNzaWdubWVudCBwcm9jZXNzIGlzc3VlLiAgVGhpcyBs aXN0IG1heSBiZSB1cGRhdGVkIGJ5IElBTkEgYWZ0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGFzc2lnbm1lbnQg dG8gaGVscCB0cmFjayBjaGFuZ2VzIHRvIGFuIGFzc2lnbm1lbnQsIGUuZy4sIGRlLTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGFzc2lnbm1lbnQgdG8gaGVscCB0 cmFjayBjaGFuZ2VzIHRvIGFuIGFzc2lnbm1lbnQsIGUuZy4sIGRlLTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcmVn aXN0cmF0aW9uLCBvd25lci9uYW1lIGNoYW5nZXMsIGV0Yy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICByZWdpc3RyYXRpb24sIG93bmVyL25hbWUgY2hhbmdlcywg ZXRjLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiB0 aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgaXMgZm9yIHRoZSBhZGRpdGlvbiBvZiBhIG5ldyB0 cmFuc3BvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiB0aGUgcmVn aXN0cmF0aW9uIHJlcXVlc3QgaXMgZm9yIHRoZSBhZGRpdGlvbiBvZiBhIG5ldyB0cmFuc3Bv cnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHByb3RvY29sIHRvIGFuIGFscmVhZHkgYXNzaWduZWQgc2VydmljZSBuYW1l LCBJQU5BIG5lZWRzIHRvIGNvbmZpcm08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBwcm90b2NvbCB0byBhbiBhbHJlYWR5IGFzc2lnbmVkIHNlcnZpY2UgbmFtZSwgSUFO QSBuZWVkcyB0byBjb25maXJtPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aXRoIHRoZSBSZWdpc3RyYW50IGZvciB0aGUg ZXhpc3RpbmcgYXNzaWdubWVudCB3aGV0aGVyIHRoaXMgYWRkaXRpb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aXRoIHRoZSBSZWdpc3RyYW50IGZvciB0aGUgZXhp c3RpbmcgYXNzaWdubWVudCB3aGV0aGVyIHRoaXMgYWRkaXRpb248L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlzIGFwcHJv cHJpYXRlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlzIGFwcHJvcHJp YXRlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAwMTYiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+SWYgdGhl IHJlZ2lzdHJhdGlvbiByZXF1ZXN0IGlzIGZvciBhIHNlcnZpY2UgbmFtZSBvdmVybG9hZGlu ZyBhIHBvcnQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBudW1iZXIgKHNlZSBTZWN0aW9uIDUpLCBJQU5B IG5lZWRzIHRvIGNvbmZpcm0gd2l0aCB0aGUgUmVnaXN0cmFudCBmb3I8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICB0aGUgZXhpc3Rpbmcgc2VydmljZSBuYW1lIHdoZXRoZXIgdGhlIHJlZ2lzdHJhdGlv biBvZiB0aGUgb3ZlcmxvYWRpbmc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBpcyBhcHByb3ByaWF0ZS48 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBXaGVuIElBTkEgcmVjZWl2ZXMgYSByZWdpc3RyYXRpb24g cmVxdWVzdCAtIGNvbnRhaW5pbmcgdGhlIGFib3ZlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgV2hlbiBJQU5BIHJlY2VpdmVzIGEgcmVnaXN0cmF0aW9uIHJlcXVlc3Qg LSBjb250YWluaW5nIHRoZSBhYm92ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5mb3JtYXRpb24gLSB0aGF0IGlzIHJl cXVlc3RpbmcgYSBwb3J0IG51bWJlciwgSUFOQSBTSEFMTCBpbml0aWF0ZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluZm9ybWF0aW9uIC0gdGhhdCBpcyByZXF1ZXN0 aW5nIGEgcG9ydCBudW1iZXIsIElBTkEgU0hBTEwgaW5pdGlhdGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuICJFeHBl cnQgUmV2aWV3IiBbUkZDNTIyNl0gaW4gb3JkZXIgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYW48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbiAiRXhwZXJ0IFJldmlldyIg W1JGQzUyMjZdIGluIG9yZGVyIHRvIGRldGVybWluZSB3aGV0aGVyIGFuPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhc3Np Z25tZW50IHNob3VsZCBiZSBtYWRlLiAgRm9yIHJlcXVlc3RzIHRoYXQgZG8gbm90IGluY2x1 ZGUgYSBwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXNzaWdubWVu dCBzaG91bGQgYmUgbWFkZS4gIEZvciByZXF1ZXN0cyB0aGF0IGRvIG5vdCBpbmNsdWRlIGEg cG9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgbnVtYmVyLCBJQU5BIFNIT1VMRCBhc3NpZ24gdGhlIHNlcnZpY2UgbmFt ZSB1bmRlciBhIHNpbXBsZSAiRmlyc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBudW1iZXIsIElBTkEgU0hPVUxEIGFzc2lnbiB0aGUgc2VydmljZSBuYW1lIHVuZGVy IGEgc2ltcGxlICJGaXJzdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29tZSBGaXJzdCBTZXJ2ZWQiIHBvbGljeSBbUkZD NTIyNl0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29tZSBGaXJzdCBT ZXJ2ZWQiIHBvbGljeSBbUkZDNTIyNl0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNyI+PC9hPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij44LjEuMS4gIFZhcmlhbmNlcyBmb3IgU3BlY2lmaWMgUG9ydCBOdW1iZXIg UmFuZ2VzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgU2VjdGlvbiA2IGRlc2Ny aWJlcyB0aGUgZGlmZmVyZW50IHBvcnQgbnVtYmVyIHJhbmdlcy4gIEl0IGlzPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCBJQU5BIGFwcGxpZXMgc2xpZ2h0bHkg ZGlmZmVyZW50IHByb2NlZHVyZXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB3aGVuIG1hbmFnaW5nIHRo ZSBkaWZmZXJlbnQgcG9ydCByYW5nZXMgb2YgdGhlIHNlcnZpY2UgbmFtZSBhbmQgcG9ydDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIG51bWJlciByZWdpc3RyeTo8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBvICBQb3J0cyBpbiB0aGUgRHluYW1pYyBQb3J0cyByYW5nZSAoNDkxNTIt NjU1MzUpIGhhdmUgYmVlbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIHNwZWNpZmljYWxseSBzZXQg YXNpZGUgZm9yIGxvY2FsIGFuZCBkeW5hbWljIHVzZSBhbmQgY2Fubm90IGJlPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgICAgYXNzaWduZWQgdGhyb3VnaCBJQU5BLiAgQXBwbGljYXRpb24gc29mdHdh cmUgbWF5IHNpbXBseSB1c2UgdGhlbTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIGZvciBjb21tdW5p Y2F0aW9uIHdpdGhvdXQgYW55IHNvcnQgb2YgcmVnaXN0cmF0aW9uLiAgT24gdGhlIG90aGVy PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgICAgaGFuZCwgYXBwbGljYXRpb24gc29mdHdhcmUgTVVTVCBO T1QgYXNzdW1lIHRoYXQgYSBzcGVjaWZpYyBwb3J0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgbnVt YmVyIGluIHRoZSBEeW5hbWljIFBvcnRzIHJhbmdlIHdpbGwgYWx3YXlzIGJlIGF2YWlsYWJs ZSBmb3I8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBjb21tdW5pY2F0aW9uIGF0IGFsbCB0aW1lcywg YW5kIGEgcG9ydCBudW1iZXIgaW4gdGhhdCByYW5nZSBoZW5jZTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg ICAgIE1VU1QgTk9UIGJlIHVzZWQgYXMgYSBzZXJ2aWNlIGlkZW50aWZpZXIuPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbyAgUG9ydHMgaW4gdGhlIFVzZXIgUG9ydHMgcmFu Z2UgKDEwMjQtNDkxNTEpIGFyZSBhdmFpbGFibGUgZm9yPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg cmVnaXN0cmF0aW9uIHRocm91Z2ggSUFOQSwgYW5kIE1BWSBiZSB1c2VkIGFzIHNlcnZpY2Ug aWRlbnRpZmllcnM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICB1cG9uIHN1Y2Nlc3NmdWwgcmVnaXN0 cmF0aW9uLiAgQmVjYXVzZSByZWdpc3RlcmluZyBhIHBvcnQgbnVtYmVyPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgZm9yIGEgc3BlY2lmaWMgYXBwbGljYXRpb24gY29uc3VtZXMgYSBmcmFjdGlv biBvZiB0aGUgc2hhcmVkPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgcmVzb3VyY2UgdGhhdCBpcyB0 aGUgcG9ydCBudW1iZXIgcmVnaXN0cnksIElBTkEgd2lsbCByZXF1aXJlIHRoZTwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgICAgIHJlcXVlc3RlciB0byBkb2N1bWVudCB0aGUgaW50ZW5kZWQgdXNlIG9m IHRoZSBwb3J0IG51bWJlci4gIFRoaXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBkb2N1bWVudGF0 aW9uIHdpbGwgYmUgaW5wdXQgdG8gdGhlICJFeHBlcnQgUmV2aWV3IiBhbGxvY2F0aW9uPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgICAgcHJvY2VkdXJlIFtSRkM1MjI2XSwgYnkgd2hpY2ggSUFOQSB3 aWxsIGhhdmUgYSB0ZWNobmljYWwgZXhwZXJ0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgcmV2aWV3 IHRoZSByZXF1ZXN0IHRvIGRldGVybWluZSB3aGV0aGVyIHRvIGdyYW50IHRoZSByZWdpc3Ry YXRpb24uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgVGhlIHN1Ym1pdHRlZCBkb2N1bWVudGF0aW9u IE1VU1QgZXhwbGFpbiB3aHkgdXNpbmcgYSBwb3J0IG51bWJlcjwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg ICAgIGluIHRoZSBEeW5hbWljIFBvcnRzIHJhbmdlIGlzIHVuc3VpdGFibGUgZm9yIHRoZSBn aXZlbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIGFwcGxpY2F0aW9uLiAgUG9ydHMgaW4gdGhlIFVz ZXIgUG9ydHMgcmFuZ2UgbWF5IGFsc28gYmUgYXNzaWduZWQ8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAg ICB1bmRlciB0aGUgIklFVEYgUmV2aWV3IiBvciAiSUVTRyBBcHByb3ZhbCIgYWxsb2NhdGlv biBwcm9jZWR1cmVzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgW1JGQzUyMjZdLCB3aGljaCBpcyBo b3cgbW9zdCBhc3NpZ25tZW50cyBmb3IgSUVURiBwcm90b2NvbHMgYXJlPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgaGFuZGxlZC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBvICBQ b3J0cyBpbiB0aGUgU3lzdGVtIFBvcnRzIHJhbmdlICgwLTEwMjMpIGFyZSBhbHNvIGF2YWls YWJsZSBmb3I8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICByZWdpc3RyYXRpb24gdGhyb3VnaCBJQU5B LiAgQmVjYXVzZSB0aGUgU3lzdGVtIFBvcnRzIHJhbmdlIGlzIGJvdGg8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAgICB0aGUgc21hbGxlc3QgYW5kIHRoZSBtb3N0IGRlbnNlbHkgYWxsb2NhdGVkLCB0 aGUgcmVxdWlyZW1lbnRzIGZvcjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIG5ldyBhbGxvY2F0aW9u cyBhcmUgbW9yZSBzdHJpY3QgdGhhbiB0aG9zZSBmb3IgdGhlIFVzZXIgUG9ydHM8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgICByYW5nZSwgYW5kIHdpbGwgb25seSBiZSBncmFudGVkIHVuZGVyIHRo ZSAiSUVURiBSZXZpZXciIG9yICJJRVNHPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgQXBwcm92YWwi IGFsbG9jYXRpb24gcHJvY2VkdXJlcyBbUkZDNTIyNl0uICBBIHJlcXVlc3QgZm9yIGEgU3lz dGVtPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgICAgUG9ydCBudW1iZXIgTVVTVCBkb2N1bWVudCAqYm90 aCogd2h5IHVzaW5nIGEgcG9ydCBudW1iZXIgZnJvbSB0aGU8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAg ICBVc2VyIFBvcnRzIGlzIHVuc3VpdGFibGUgKmFuZCogd2h5IHVzaW5nIGEgcG9ydCBudW1i ZXIgZnJvbSB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBEeW5hbWljIFBvcnRzIHJhbmdlcyBp cyB1bnN1aXRhYmxlIGZvciB0aGF0IGFwcGxpY2F0aW9uLjwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjgu Mi4gIFNlcnZpY2UgTmFtZSBhbmQgUG9ydCBOdW1iZXIgRGUtUmVnaXN0cmF0aW9uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OC4yLiAgU2VydmljZSBOYW1lIGFuZCBQb3J0 IE51bWJlciBEZS1SZWdpc3RyYXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgVGhlIFJlZ2lzdHJhbnQgb2YgYSBncmFudGVkIHBvcnQgbnVtYmVy IGFzc2lnbm1lbnQgY2FuIHJldHVybiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGUgUmVnaXN0cmFudCBvZiBhIGdyYW50ZWQgcG9ydCBudW1iZXIgYXNzaWdu bWVudCBjYW4gcmV0dXJuIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcG9ydCBudW1iZXIgdG8gSUFOQSBhdCBhbnkg dGltZSBpZiB0aGV5IG5vIGxvbmdlciBoYXZlIGEgbmVlZCBmb3IgaXQuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcG9ydCBudW1iZXIgdG8gSUFOQSBhdCBhbnkgdGlt ZSBpZiB0aGV5IG5vIGxvbmdlciBoYXZlIGEgbmVlZCBmb3IgaXQuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgcG9y dCBudW1iZXIgd2lsbCBiZSBkZS1yZWdpc3RlcmVkIGFuZCB3aWxsIGJlIG1hcmtlZCBhcyBS ZXNlcnZlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgcG9ydCBu dW1iZXIgd2lsbCBiZSBkZS1yZWdpc3RlcmVkIGFuZCB3aWxsIGJlIG1hcmtlZCBhcyBSZXNl cnZlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIElBTkEgc2hvdWxkIG5vdCByZS1hc3NpZ24gcG9ydCBudW1iZXJzIHRo YXQgaGF2ZSBiZWVuIGRlLXJlZ2lzdGVyZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBJQU5BIHNob3VsZCBub3QgcmUtYXNzaWduIHBvcnQgbnVtYmVycyB0aGF0IGhh dmUgYmVlbiBkZS1yZWdpc3RlcmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1bnRpbCBhbGwgdW5hc3NpZ25lZCBwb3J0 IG51bWJlcnMgaW4gdGhlIHNwZWNpZmljIHJhbmdlIGhhdmUgYmVlbjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVudGlsIGFsbCB1bmFzc2lnbmVkIHBvcnQgbnVtYmVy cyBpbiB0aGUgc3BlY2lmaWMgcmFuZ2UgaGF2ZSBiZWVuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhc3NpZ25lZC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhc3NpZ25lZC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQmVmb3JlIHByb2NlZWRpbmcgd2l0 aCBhIHBvcnQgbnVtYmVyIGRlLXJlZ2lzdHJhdGlvbiwgSUFOQSBuZWVkcyB0bzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJlZm9yZSBwcm9jZWVkaW5nIHdpdGggYSBw b3J0IG51bWJlciBkZS1yZWdpc3RyYXRpb24sIElBTkEgbmVlZHMgdG88L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPg0KICAgICAg PHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwxMCI+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDIwLCBsaW5lIDIw PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjEwIj48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMjAsIGxpbmUgMjk8L2Vt PjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZ2l2ZW4gc2VydmljZSBu YW1lIHJlbWFpbiBhc3NpZ25lZCBldmVuIGFmdGVyIGFsbCBhc3NvY2lhdGVkIHBvcnQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBnaXZlbiBzZXJ2aWNlIG5hbWUgcmVt YWluIGFzc2lnbmVkIGV2ZW4gYWZ0ZXIgYWxsIGFzc29jaWF0ZWQgcG9ydDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbnVt YmVyIGFzc2lnbm1lbnRzIGhhdmUgYmVjb21lIGRlLXJlZ2lzdGVyZWQuICBVbmRlciB0aGlz IHBvbGljeSwgaXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBudW1iZXIg YXNzaWdubWVudHMgaGF2ZSBiZWNvbWUgZGUtcmVnaXN0ZXJlZC4gIFVuZGVyIHRoaXMgcG9s aWN5LCBpdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgd2lsbCBhcHBlYXIgaW4gdGhlIHJlZ2lzdHJ5IGFzIGlmIGl0IGhh ZCBiZWVuIGNyZWF0ZWQgdGhyb3VnaCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgd2lsbCBhcHBlYXIgaW4gdGhlIHJlZ2lzdHJ5IGFzIGlmIGl0IGhhZCBiZWVuIGNy ZWF0ZWQgdGhyb3VnaCBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZXJ2aWNlIG5hbWUgcmVnaXN0cmF0aW9uIHJlcXVl c3QgdGhhdCBkaWQgbm90IGluY2x1ZGUgYW55IHBvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBzZXJ2aWNlIG5hbWUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgdGhhdCBk aWQgbm90IGluY2x1ZGUgYW55IHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG51bWJlcnMuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbnVtYmVycy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgT24gcmFyZSBvY2Nhc2lvbnMsIGl0IG1heSBzdGlsbCBi ZSB1c2VmdWwgdG8gZGUtcmVnaXN0ZXIgYSBzZXJ2aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgT24gcmFyZSBvY2Nhc2lvbnMsIGl0IG1heSBzdGlsbCBiZSB1c2Vm dWwgdG8gZGUtcmVnaXN0ZXIgYSBzZXJ2aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBuYW1lLiAgSW4gc3VjaCBjYXNl cywgSUFOQSB3aWxsIG1hcmsgdGhlIHNlcnZpY2UgbmFtZSBhcyBSZXNlcnZlZC48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBuYW1lLiAgSW4gc3VjaCBjYXNlcywgSUFO QSB3aWxsIG1hcmsgdGhlIHNlcnZpY2UgbmFtZSBhcyBSZXNlcnZlZC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElBTkEg d2lsbCBpbnZvbHZlIHRoZWlyIElFU0ctYXBwb2ludGVkIGV4cGVydCBpbiBzdWNoIGNhc2Vz LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElBTkEgd2lsbCBpbnZvbHZl IHRoZWlyIElFU0ctYXBwb2ludGVkIGV4cGVydCBpbiBzdWNoIGNhc2VzLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTgi PjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+SUFOQSB3aWxsIGluY2x1ZGUgYSBj b21tZW50IGluIHRoZSByZWdpc3RyeSB3aGVuIGRlLXJlZ2lzdHJhdGlvbjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIGhhcHBlbnMgdG8gaW5kaWNhdGUgaXRzIGhpc3RvcmljIHVzYWdlLjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjguMy4gIFNlcnZpY2UgTmFtZSBhbmQgUG9ydCBOdW1iZXIgUmUtVXNlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OC4zLiAgU2VydmljZSBOYW1lIGFuZCBQ b3J0IE51bWJlciBSZS1Vc2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgSWYgdGhlIFJlZ2lzdHJhbnQgb2YgYSBncmFudGVkIHBvcnQgbnVtYmVyIGFz c2lnbm1lbnQgbm8gbG9uZ2VyIGhhdmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJZiB0aGUgUmVnaXN0cmFudCBvZiBhIGdyYW50ZWQgcG9ydCBudW1iZXIgYXNzaWdu bWVudCBubyBsb25nZXIgaGF2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYSBuZWVkIGZvciB0aGUgYXNzaWduZWQgbnVt YmVyLCBidXQgd291bGQgbGlrZSB0byByZS11c2UgaXQgZm9yIGE8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBhIG5lZWQgZm9yIHRoZSBhc3NpZ25lZCBudW1iZXIsIGJ1 dCB3b3VsZCBsaWtlIHRvIHJlLXVzZSBpdCBmb3IgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGlmZmVyZW50IGFwcGxp Y2F0aW9uLCB0aGV5IGNhbiBzdWJtaXQgYSByZXF1ZXN0IHRvIElBTkEgdG8gZG8gc28uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGlmZmVyZW50IGFwcGxpY2F0aW9u LCB0aGV5IGNhbiBzdWJtaXQgYSByZXF1ZXN0IHRvIElBTkEgdG8gZG8gc28uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIExvZ2ljYWxseSwgcG9ydCBu dW1iZXIgcmUtdXNlIGlzIHRvIGJlIHRob3VnaHQgb2YgYXMgYSBkZS08L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBMb2dpY2FsbHksIHBvcnQgbnVtYmVyIHJlLXVzZSBp cyB0byBiZSB0aG91Z2h0IG9mIGFzIGEgZGUtPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWdpc3RyYXRpb24gKFNlY3Rp b24gOC4yKSBmb2xsb3dlZCBieSBhbiBpbW1lZGlhdGUgcmUtcmVnaXN0cmF0aW9uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVnaXN0cmF0aW9uIChTZWN0aW9uIDgu MikgZm9sbG93ZWQgYnkgYW4gaW1tZWRpYXRlIHJlLXJlZ2lzdHJhdGlvbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKFNl Y3Rpb24gOC4xKSBvZiB0aGUgc2FtZSBwb3J0IG51bWJlciBmb3IgYSBuZXcgYXBwbGljYXRp b24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKFNlY3Rpb24gOC4xKSBv ZiB0aGUgc2FtZSBwb3J0IG51bWJlciBmb3IgYSBuZXcgYXBwbGljYXRpb24uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBD b25zZXF1ZW50bHksIHRoZSBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGJlIHByb3ZpZGVk IGFib3V0IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbnNlcXVl bnRseSwgdGhlIGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgYWJvdXQg dGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFt ZT0icGFydC1sMTEiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4g cGFnZSAyMiwgbGluZSA5PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBh cnQtcjExIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2Ug MjIsIGxpbmUgMTk8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij44LjYuICBNYWludGVuYW5jZSBJ c3N1ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij44LjYuICBNYWludGVuYW5j ZSBJc3N1ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg SW4gYWRkaXRpb24gdG8gdGhlIGZvcm1hbCBwcm9jZWR1cmVzIGRlc2NyaWJlZCBhYm92ZSwg dXBkYXRlcyB0byB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbiBh ZGRpdGlvbiB0byB0aGUgZm9ybWFsIHByb2NlZHVyZXMgZGVzY3JpYmVkIGFib3ZlLCB1cGRh dGVzIHRvIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgRGVzY3JpcHRpb24gYW5kIENvbnRhY3QgaW5mb3JtYXRpb24g YXJlIGNvb3JkaW5hdGVkIGJ5IElBTkEgaW4gYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBEZXNjcmlwdGlvbiBhbmQgQ29udGFjdCBpbmZvcm1hdGlvbiBhcmUgY29v cmRpbmF0ZWQgYnkgSUFOQSBpbiBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5mb3JtYWwgbWFubmVyLCBhbmQgbWF5 IGJlIGluaXRpYXRlZCBieSBlaXRoZXIgdGhlIHJlZ2lzdHJhbnQgb3IgYnk8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmZvcm1hbCBtYW5uZXIsIGFuZCBtYXkgYmUg aW5pdGlhdGVkIGJ5IGVpdGhlciB0aGUgcmVnaXN0cmFudCBvciBieTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSUFOQSwg ZS5nLiwgYnkgdGhlIGxhdHRlciByZXF1ZXN0aW5nIGFuIHVwZGF0ZSB0byBjdXJyZW50IGNv bnRhY3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJQU5BLCBlLmcuLCBi eSB0aGUgbGF0dGVyIHJlcXVlc3RpbmcgYW4gdXBkYXRlIHRvIGN1cnJlbnQgY29udGFjdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgaW5mb3JtYXRpb24uICAoTm90ZSB0aGF0IFJlZ2lzdHJhdGlvbiBBZG1pbmlzdHJh dGl2ZSBDb250YWN0IGNhbm5vdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGluZm9ybWF0aW9uLiAgKE5vdGUgdGhhdCBSZWdpc3RyYXRpb24gQWRtaW5pc3RyYXRpdmUg Q29udGFjdCBjYW5ub3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJlIGNoYW5nZWQ7IHNlZSBTZWN0aW9uIDguNSBhYm92 ZS4pPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmUgY2hhbmdlZDsgc2Vl IFNlY3Rpb24gOC41IGFib3ZlLik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE5Ij48L2E+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPjguNy4gIERpc2FncmVtZW50czwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIEluIHRoZSBjYXNlIG9mIGRpc2FncmVlbWVudHMgYXJvdW5kIGFueSByZXF1ZXN0IHRo ZXJlIGlzIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHBvc3NpYmlsaXR5IG9mIGFwcGVhbCBmb2xs b3dpbmcgdGhlIG5vcm1hbCBhcHBlbGFzIHByb2Nlc3MgZm9yIElBTkE8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICByZWdpc3RyYXRpb25zIGFzIGRlZmluZWQgYnkgU2VjdGlvbiA3IG9mICJHdWlkZWxp bmVzIGZvciBXcml0aW5nIGFuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgSUFOQSBDb25zaWRlcmF0aW9u cyBTZWN0aW9uIGluIFJGQ3MiIFtSRkM1MjI2XS48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij45LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij45 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIElBTkEgZ3VpZGVsaW5lcyBkZXNjcmliZWQgaW4gdGhp cyBkb2N1bWVudCBkbyBub3QgY2hhbmdlIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoZSBJQU5BIGd1aWRlbGluZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQgZG8gbm90IGNoYW5nZSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgVURQ LCBUQ1AsIFNDVFAsIG9yIERDQ1AuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBVRFAsIFRDUCwgU0NUUCwgb3IgRENDUC48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQXNzaWdubWVudCBv ZiBhIHNlcnZpY2UgbmFtZSBvciBwb3J0IG51bWJlciBkb2VzIG5vdCBpbiBhbnkgd2F5IGlt cGx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXNzaWdubWVudCBvZiBh IHNlcnZpY2UgbmFtZSBvciBwb3J0IG51bWJlciBkb2VzIG5vdCBpbiBhbnkgd2F5IGltcGx5 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbiBlbmRvcnNlbWVudCBvZiBhbiBhcHBsaWNhdGlvbiBvciBwcm9kdWN0LCBh bmQgdGhlIGZhY3QgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFu IGVuZG9yc2VtZW50IG9mIGFuIGFwcGxpY2F0aW9uIG9yIHByb2R1Y3QsIGFuZCB0aGUgZmFj dCB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBuZXR3b3JrIHRyYWZmaWMgaXMgZmxvd2luZyB0byBvciBmcm9tIGFu IGFzc2lnbmVkIHBvcnQgbnVtYmVyIGRvZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBuZXR3b3JrIHRyYWZmaWMgaXMgZmxvd2luZyB0byBvciBmcm9tIGFuIGFzc2ln bmVkIHBvcnQgbnVtYmVyIGRvZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5vdCBtZWFuIHRoYXQgaXQgaXMgImdvb2Qi IHRyYWZmaWMsIG9yIGV2ZW4gdGhhdCBpdCBpcyB1c2VkIGJ5IHRoZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5vdCBtZWFuIHRoYXQgaXQgaXMgImdvb2QiIHRyYWZm aWMsIG9yIGV2ZW4gdGhhdCBpdCBpcyB1c2VkIGJ5IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXNzaWduZWQgc2Vy dmljZS4gIEZpcmV3YWxsIGFuZCBzeXN0ZW0gYWRtaW5pc3RyYXRvcnMgc2hvdWxkIGNob29z ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFzc2lnbmVkIHNlcnZpY2Uu ICBGaXJld2FsbCBhbmQgc3lzdGVtIGFkbWluaXN0cmF0b3JzIHNob3VsZCBjaG9vc2U8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry Pg0KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0 LWwxMiI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDMw LCBsaW5lIDM5PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjEy Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMzEsIGxp bmUgMjY8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNDY3NiBB ZG1pcmFsdHkgV2F5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNDY3NiBB ZG1pcmFsdHkgV2F5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBNYXJpbmEgZGVsIFJleSwgQ0EgIDkwMjkyPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWFyaW5hIGRlbCBSZXksIENBICA5MDI5Mjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgVVNBPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVVNBPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBob25lOiArMSAzMTAg NDQ4IDkxNTE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQaG9uZTogKzEg MzEwIDQ0OCA5MTUxPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBFbWFpbDogdG91Y2hAaXNpLmVkdTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVtYWlsOiB0b3VjaEBpc2kuZWR1PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBVUkk6 ICAgaHR0cDovL3d3dy5pc2kuZWR1L3RvdWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVVJJOiAgIGh0dHA6Ly93d3cuaXNpLmVkdS90b3VjaDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNYWdudXMgV2VzdGVybHVuZDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1hZ251cyBXZXN0ZXJsdW5kPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBFcmljc3NvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVyaWNzc29u PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjAiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Ub3JzaGFtc2dhdGFuIDIzPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5G YXJvZ2F0YW4gNjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN0b2NraG9sbSAgMTY0IDgwPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU3RvY2tob2xtICAxNjQgODA8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN3ZWRl bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFN3ZWRlbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQaG9uZTogKzQ2IDggNzE5IDAw MDA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQaG9uZTogKzQ2IDggNzE5 IDAwMDA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIEVtYWlsOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFbWFpbDogbWFnbnVzLndlc3Rlcmx1 bmRAZXJpY3Nzb24uY29tPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjEiPjwvYT48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN0 dWFydCBDaGVzaGlyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFN0dWFy dCBDaGVzaGlyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgQXBwbGUgSW5jLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEFwcGxlIEluYy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEgSW5maW5pdGUgTG9vcDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEgSW5maW5pdGUgTG9vcDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ3VwZXJ0 aW5vLCBDQSAgOTUwMTQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDdXBl cnRpbm8sIENBICA5NTAxNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVVNBPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVVNBPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFBob25lOiArMSA0MDggOTc0IDMyMDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBQaG9uZTogKzEgNDA4IDk3NCAzMjA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFbWFpbDogY2hlc2hpcmVA YXBwbGUuY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRW1haWw6IGNo ZXNoaXJlQGFwcGxlLmNvbTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQoNCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPg0KICAgICA8 dHIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5h bWU9ImVuZCI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDIxIGNoYW5nZSBibG9ja3MuJm5ic3A7 PC9hPjwvdGg+PC90cj4NCiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRoPjxp Pjc2IGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwvdGg+ PHRoPjxpPjk1IGxpbmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+PC90aD48dGQ+PC90ZD48L3Ry Pg0KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGNsYXNzPSJzbWFsbCIgYWxpZ249ImNlbnRl ciI+PGJyPlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuMzkuIFRo ZSBsYXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3 LnRvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv dG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4NCiAgIDwvdGJvZHk+PC90YWJsZT4NCiAg IDwvYm9keT48L2h0bWw+ --------------060506030105030301060704-- From touch@isi.edu Fri Sep 24 06:50:17 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914D13A6A08 for ; Fri, 24 Sep 2010 06:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9pK+5s5g5v5D for ; Fri, 24 Sep 2010 06:50:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 286C83A6AAE for ; Fri, 24 Sep 2010 06:50:14 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o8ODl52r004775 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 24 Sep 2010 06:47:15 -0700 (PDT) Message-ID: <4C9CABD8.5070501@isi.edu> Date: Fri, 24 Sep 2010 06:47:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Magnus Westerlund References: <4C921413.2010808@ericsson.com> <4C9B6A89.3090401@ericsson.com> <4C9C98A2.5060405@ericsson.com> In-Reply-To: <4C9C98A2.5060405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 13:50:17 -0000 One minor comment: pg 18: References to specific form text, such as "USR" or "SYS", should be removed, and the text should just say that the application must indicate whether the desired port number is in the User or System range. Joe From magnus.westerlund@ericsson.com Mon Sep 27 04:16:49 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04FD3A6CF5 for ; Mon, 27 Sep 2010 04:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 SaevXMXAZAoi for ; Mon, 27 Sep 2010 04:16:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8673E3A6CF0 for ; Mon, 27 Sep 2010 04:16:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-ac-4ca07d46eb07 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F3.B0.09806.64D70AC4; Mon, 27 Sep 2010 13:17:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Sep 2010 13:17:25 +0200 Received: from [147.214.183.53] ([147.214.183.53]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Sep 2010 13:17:25 +0200 Message-ID: <4CA07D45.2080509@ericsson.com> Date: Mon, 27 Sep 2010 13:17:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Joe Touch References: <4C921413.2010808@ericsson.com> <4C9B6A89.3090401@ericsson.com> <4C9C98A2.5060405@ericsson.com> <4C9CABD8.5070501@isi.edu> In-Reply-To: <4C9CABD8.5070501@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Sep 2010 11:17:25.0559 (UTC) FILETIME=[9030DC70:01CB5E35] X-Brightmail-Tracker: AAAAAA== Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 11:16:49 -0000 Joe Touch skrev 2010-09-24 15:47: > One minor comment: > > pg 18: > References to specific form text, such as "USR" or "SYS", should be > removed, and the text should just say that the application must indicate > whether the desired port number is in the User or System range. > > Joe > > I have removed the form specific text from the ports bullet and committed the revision. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lars.eggert@nokia.com Wed Sep 29 11:16:12 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05B03A6D14 for ; Wed, 29 Sep 2010 11:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 Z3LyOfY4Ixr2 for ; Wed, 29 Sep 2010 11:16:11 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 728423A6D0C for ; Wed, 29 Sep 2010 11:16:04 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8TIGiUn026486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2010 21:16:45 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-95-386818137; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4CA07D45.2080509@ericsson.com> Date: Wed, 29 Sep 2010 21:16:19 +0300 Message-Id: <3292C01F-0C7C-45B0-A460-5B91FA635890@nokia.com> References: <4C921413.2010808@ericsson.com> <4C9B6A89.3090401@ericsson.com> <4C9C98A2.5060405@ericsson.com> <4C9CABD8.5070501@isi.edu> <4CA07D45.2080509@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 29 Sep 2010 21:16:26 +0300 (EEST) X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:16:12 -0000 --Apple-Mail-95-386818137 Content-Type: multipart/mixed; boundary=Apple-Mail-94-386818094 --Apple-Mail-94-386818094 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii OK, I suggest everyone give the current version a read, and then we ship it. Lars --Apple-Mail-94-386818094 Content-Disposition: attachment; filename=draft-ietf-tsvwg-iana-ports-from--06.diff.html Content-Type: text/html; x-unix-mode=0644; name="draft-ietf-tsvwg-iana-ports-from--06.diff.html" Content-Transfer-Encoding: 7bit Diff: draft-ietf-tsvwg-iana-ports-06.txt - draft-ietf-tsvwg-iana-ports.txt
 draft-ietf-tsvwg-iana-ports-06.txt   draft-ietf-tsvwg-iana-ports.txt 
Transport Area Working Group M. Cotton Transport Area Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
Updates: 2780, 2782, 3828, 4340, L. Eggert Updates: 2780, 2782, 3828, 4340, L. Eggert
4960 (if approved) Nokia 4960 (if approved) Nokia
Intended status: BCP J. Touch Intended status: BCP J. Touch
Expires: November 27, 2010 USC/ISI Expires: April 2, 2011 USC/ISI
M. Westerlund M. Westerlund
Ericsson Ericsson
S. Cheshire S. Cheshire
Apple Apple
May 26, 2010 September 29, 2010
Internet Assigned Numbers Authority (IANA) Procedures for the Management Internet Assigned Numbers Authority (IANA) Procedures for the Management
of the Transport Protocol Port Number and Service Name Registry of the Service Name and Transport Protocol Port Number Registry
draft-ietf-tsvwg-iana-ports-06 draft-ietf-tsvwg-iana-ports-07
Abstract Abstract
This document defines the procedures that the Internet Assigned This document defines the procedures that the Internet Assigned
Numbers Authority (IANA) uses when handling registration and other Numbers Authority (IANA) uses when handling registration and other
requests related to the transport protocol port number and service requests related to the Service Name and Transport Protocol Port
name registry. It also discusses the rationale and principles behind Number Registry. It also discusses the rationale and principles
these procedures and how they facilitate the long-term sustainability behind these procedures and how they facilitate the long-term
of the registry. sustainability of the registry.
This document updates IANA's procedures by obsoleting Sections 8 and This document updates IANA's procedures by obsoleting Sections 8 and
9.1 of the IANA allocation guidelines [RFC2780], it updates the IANA 9.1 of the IANA allocation guidelines [RFC2780], and it updates the
allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP IANA allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and
[RFC4960], it updates the DNS SRV specification [RFC2782] to clarify SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782]
what a service name is and how it is registered. to clarify what a service name is and how it is registered.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 27, 2010. This Internet-Draft will expire on April 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conventions Used in this Document . . . . . . . . . . . . . . 7 4. Conventions Used in this Document . . . . . . . . . . . . . . 7
5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9
5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 9 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10
6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Port Numbers and Service Names for Experimentation . . . . 11 6.1. Service names and Port Numbers for Experimentation . . . . 11
7. Principles for Port Number and Service Name Registry 7. Principles for Service Name and Transport Protocol Port
Management . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Number Registry Management . . . . . . . . . . . . . . . . . . 12
7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12
7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 12 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13
7.3. Variances for Specific Port Number Ranges . . . . . . . . 15 8. IANA Procedures for Managing the Service Name and
8. IANA Procedures for Managing the Port Number and Service Transport Protocol Port Number Registry . . . . . . . . . . . 15
Name Registry . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Service Name and Port Number Registration . . . . . . . . 15
8.1. Port Number and Service Name Registration . . . . . . . . 16 8.2. Service Name and Port Number De-Registration . . . . . . . 20
8.2. Port Number and Service Name De-Registration . . . . . . . 19 8.3. Service Name and Port Number Re-Use . . . . . . . . . . . 20
8.3. Port Number and Service Name Re-Use . . . . . . . . . . . 19 8.4. Service Name and Port Number Revocation . . . . . . . . . 21
8.4. Port Number and Service Name Revocation . . . . . . . . . 20 8.5. Service Name and Port Number Transfers . . . . . . . . . . 21
8.5. Port Number and Service Name Transfers . . . . . . . . . . 21 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 22
8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 21 8.7. Disagrements . . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 22 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 23
10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 25
10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 26
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
For many years, the allocation and registration of new port number For many years, the allocation of new service names and port number
values and service names for use with the Transmission Control values for use with the Transmission Control Protocol (TCP) [RFC0793]
Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) and the User Datagram Protocol (UDP) [RFC0768] have had less than
[RFC0768] have had less than clear guidelines. New transport clear guidelines. New transport protocols have been added - the
protocols have been added - the Stream Control Transmission Protocol Stream Control Transmission Protocol (SCTP) [RFC4960] and the
(SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new
[RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have mechanisms like DNS SRV records [RFC2782] have been developed, each
been developed, each with separate registries and separate with separate registries and separate guidelines. The community also
guidelines. The community recognized the need for additional recognized the need for additional procedures beyond just assignment;
procedures beyond just assignment; notably modification, revocation, notably modification, revocation, and release.
and release.
A key factor of this procedural streamlining is to establish A key element of the procedural streamlining specified in this
identical registration procedures for all IETF transport protocols. document is to establish identical assignment procedures for all IETF
This document brings the IANA procedures for TCP and UDP in line with transport protocols. This document brings the IANA procedures for
those for SCTP and DCCP, resulting in a single process that TCP and UDP in line with those for SCTP and DCCP, resulting in a
requesters and IANA follow for all requests for all transport single process that requesters and IANA follow for all requests for
protocols, including those not yet defined. all transport protocols, including future protocols not yet defined.
In addition to detailing the IANA procedures for the initial In addition to detailing the IANA procedures for the initial
assignment of port numbers and service names, this document also assignment of service names and port numbers, this document also
specifies post-assignment procedures that until now have been handled specifies post-assignment procedures that until now have been handled
in an ad hoc manner. These include procedures to de-register a port in an ad hoc manner. These include procedures to de-register a port
number that is no longer in use, to re-use a port number allocated number that is no longer in use, to re-use a port number allocated
for one application that is no longer in use for another application, for one application that is no longer in use for another application,
and the procedure by which IANA can unilaterally revoke a prior port and the procedure by which IANA can unilaterally revoke a prior port
number registration. Section 8 discusses the specifics of these number assignment. Section 8 discusses the specifics of these
procedures and processes that requesters and IANA follow for all procedures and processes that requesters and IANA follow for all
requests for all current and future transport protocols. requests for all current and future transport protocols.
It is important to note that ownership of registered port numbers and IANA is the authority for assigning service names and port numbers.
service names remains with IANA. For protocols developed by IETF The registries that are created to store these registrations are
working groups, IANA now also offers a method for the "early" maintained by IANA. For protocols developed by IETF working groups,
assignment of port numbers and service names [RFC4020], as described IANA now also offers a method for the "early assignment" [RFC4020] of
in Section 8.1. service names and port numbers, as described in Section 8.1.
This document updates IANA's procedures for UDP and TCP port numbers This document updates IANA's procedures for UDP and TCP port numbers
by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines
[RFC2780]. (Note that different sections of the IANA allocation [RFC2780]. (Note that other sections of the IANA allocation
guidelines, relating to the protocol field values in IPv4 header, guidelines, relating to the protocol field values in IPv4 header,
were also updated in February 2008 [RFC5237].) This document also were also updated in February 2008 [RFC5237].) This document also
updates the IANA allocation procedures for DCCP [RFC4340] and SCTP updates the IANA allocation procedures for DCCP [RFC4340] and SCTP
[RFC4960]. [RFC4960].
The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares
the port space with UDP. The UDP-Lite specification says: "UDP-Lite the port space with UDP. The UDP-Lite specification says: "UDP-Lite
uses the same set of port number values assigned by the IANA for use uses the same set of port number values assigned by the IANA for use
by UDP". Thus the update of UDP procedures result in an update also by UDP". Thus the update of UDP procedures result in an update also
of the UDP-Lite procedures. of the UDP-Lite procedures.
This document also clarify what a service name is and how it is This document also clarifies what a service name is and how it is
registered. This will impact the DNS SRV specification, because that registered. This will impact the DNS SRV specification [RFC2782],
specification merely makes a brief mention that the symbolic names of because that specification merely makes a brief mention that the
services are defined in "Assigned Numbers" [RFC1700], without stating symbolic names of services are defined in "Assigned Numbers"
to which section of that 230-page document it refers. The DNS SRV [RFC1700], without stating to which section it refers within that
specification may have been referring to the list of Port Assignments 230-page document. The DNS SRV specification may have been referring
(known as /etc/services on Unix), or to the "Protocol And Service to the list of Port Assignments (known as /etc/services on Unix), or
Names" section, or to both, or to some other section. Furthermore, to the "Protocol And Service Names" section, or to both, or to some
"Assigned Numbers" is now obsolete [RFC3232] and has now been other section. Furthermore, "Assigned Numbers" is now obsolete
replaced by on-line registries [PORTREG][PROTSERVREG]. There are [RFC3232] and has been replaced by on-line registries
additional updates and clarifications on how DNS SRV utilize the [PORTREG][PROTSERVREG].
Service name registry created in this document in "Clarification of
DNS SRV Owner Names" [I-D.gudmundsson-dnsext-srv-clarify].
The development of new transport protocols is a major effort that the The development of new transport protocols is a major effort that the
IETF does not undertake very often. If a new transport protocol is IETF does not undertake very often. If a new transport protocol is
standardized in the future, for the purpose of uniformity it is standardized in the future, for consistency it is expected to follow
expected to follow as much as possible the guidelines and practices as much as possible the guidelines and practices around using service
around using port numbers and service names. names and port numbers.
2. Motivation 2. Motivation
Information about the registration procedures for the port registry Information about the registration procedures for the port registry
has existed in three locations: the forms for requesting port number has existed in three locations: the forms for requesting port number
registrations on the IANA web site [SYSFORM] [USRFORM], an registrations on the IANA web site [SYSFORM] [USRFORM], an
introductory text section in the file listing the port number introductory text section in the file listing the port number
registrations themselves [PORTREG], and two brief sections of the registrations themselves [PORTREG], and two brief sections of the
IANA Allocation Guidelines [RFC2780]. IANA Allocation Guidelines [RFC2780].
Similarly, the procedures surrounding service names have been Similarly, the procedures surrounding service names have been
historically unclear. Service names were originally created as historically unclear. Service names were originally created as
mnemonic identifiers for port numbers without a well-defined syntax, mnemonic identifiers for port numbers without a well-defined syntax,
beyond the 14-character limit mentioned on the IANA website [SYSFORM] beyond the 14-character limit mentioned on the IANA website [SYSFORM]
[USRFORM]. Even that length limit has not been consistently applied, [USRFORM]. Even that length limit has not been consistently applied,
and some assigned service names are 15 characters long. When service and some assigned service names are 15 characters long. When service
identification via DNS SRV RRs was introduced, the requirement by identification via DNS SRV Resource Records (RRs) was introduced, the
IANA to only assign service names and port numbers in combination, requirement by IANA to only assign service names and port numbers in
led to the creation of an ad hoc service name registry outside of the combination, led to the creation of an ad hoc service name registry
control of IANA [SRVREG]. outside of the control of IANA [SRVREG].
This document aggregates all this scattered information into a single This document aggregates all this scattered information into a single
reference that aligns and clearly defines the management procedures reference that aligns and clearly defines the management procedures
for both port numbers and service names. It gives more detailed for both service names and port numbers. It gives more detailed
guidance to prospective requesters of ports and service names than guidance to prospective requesters of service names and ports than
the existing documentation, and it streamlines the IANA procedures the existing documentation, and it streamlines the IANA procedures
for the management of the registry, so that management requests can for the management of the registry, so that management requests can
complete in a timely manner. complete in a timely manner.
This document defines rules for registration of service names without This document defines rules for registration of service names without
associated port numbers, for such usages as DNS SRV records associated port numbers, for such usages as DNS SRV records
[RFC2782], which was not possible under the previous IANA procedures. [RFC2782], which was not possible under the previous IANA procedures.
The document also merges service name registrations from the non-IANA The document also merges service name registrations from the non-IANA
ad hoc registry [SRVREG] and from the IANA "Protocol and Service ad hoc registry [SRVREG] and from the IANA "Protocol and Service
Names" registry [PROTSERVREG] into the IANA "Port and Service Name" Names" registry [PROTSERVREG] into the IANA "Service Name and
registry [PORTREG], which from here on is the single authoritative Transport Protocol Port Number" registry [PORTREG], which from here
registry for service names and port numbers. on is the single authoritative registry for service names and port
numbers.
An additional purpose of this document is to describe the principles An additional purpose of this document is to describe the principles
that guide the IETF and IANA in their role as the long-term joint that guide the IETF and IANA in their role as the long-term joint
stewards of the port number registry. TCP and UDP have been a stewards of the service name and port number registry. TCP and UDP
remarkable success over the last decades. Thousands of applications have had remarkable success over the last decades. Thousands of
and application-level protocols have registered ports and service applications and application-level protocols have service names and
names for their use, and there is every reason to believe that this ports assigned for their use, and there is every reason to believe
trend will continue into the future. It is hence extremely important that this trend will continue into the future. It is hence extremely
that management of the registry follow principles that ensure its important that management of the registry follow principles that
long-term usefulness as a shared resource. Section 7 discusses these ensure its long-term usefulness as a shared resource. Section 7
principles in detail. discusses these principles in detail.
3. Background 3. Background
The Transmission Control Protocol (TCP) [RFC0793] and the User The Transmission Control Protocol (TCP) [RFC0793] and the User
Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success
over the decades as the two most widely used transport protocols on over the decades as the two most widely used transport protocols on
the Internet. They have relied on the concept of "ports" as logical the Internet. They have relied on the concept of "ports" as logical
entities for Internet communication. Ports serve two purposes: entities for Internet communication. Ports serve two purposes:
first, they provide a demultiplexing identifier to differentiate first, they provide a demultiplexing identifier to differentiate
transport sessions between the same pair of endpoints, and second, transport sessions between the same pair of endpoints, and second,
they may also identify the application protocol and associated they may also identify the application protocol and associated
service to which processes bind. Newer transport protocols, such as service to which processes bind. Newer transport protocols, such as
the Stream Control Transmission Protocol (SCTP) [RFC4960] and the the Stream Control Transmission Protocol (SCTP) [RFC4960] and the
Datagram Congestion Control Protocol (DCCP) [RFC4342] have adopted Datagram Congestion Control Protocol (DCCP) [RFC4342] have also
the concept of ports for their communication sessions and use 16-bit adopted the concept of ports for their communication sessions and use
port numbers in the same way as TCP and UDP (and UDP-Lite [RFC3828], sixteen-bit port numbers in the same way as TCP and UDP (and UDP-Lite
a variant of UDP). [RFC3828], a variant of UDP).
Port numbers are the original and most widely used means for Port numbers are the original and most widely used means for
application and service identification on the Internet. Ports are application and service identification on the Internet. Ports are
16-bit numbers, and the combination of source and destination port sixteen-bit numbers, and the combination of source and destination
numbers together with the IP addresses of the communicating end port numbers together with the IP addresses of the communicating end
systems uniquely identifies a session of a given transport protocol. systems uniquely identifies a session of a given transport protocol.
Port numbers are also known by their associated service names such as
Port numbers are also known by their corresponding service names such "telnet" for port number 23 and "http" (as well as "www" and "www-
as "telnet" for port number 23 and "http" (and the "www" alias) for http") for port number 80.
port number 80.
Hosts running services, hosts accessing services on other hosts, and Hosts running services, hosts accessing services on other hosts, and
intermediate devices (such as firewalls and NATs) that restrict intermediate devices (such as firewalls and NATs) that restrict
services need to agree on which service corresponds to a particular services need to agree on which service corresponds to a particular
destination port. Although this is ultimately a local decision with destination port. Although this is ultimately a local decision with
meaning only between the endpoints of a connection, it is common for meaning only between the endpoints of a connection, it is common for
many services to have a default port upon which those servers usually many services to have a default port upon which those servers usually
listen, when possible, and these ports are recorded by the Internet listen, when possible, and these ports are recorded by the Internet
Assigned Numbers Authority (IANA) through the port number registry Assigned Numbers Authority (IANA) through the service name and port
[PORTREG]. number registry [PORTREG].
Over time, the assumption that a particular port number necessarily Over time, the assumption that a particular port number necessarily
implies a particular service may become less true. For example, implies a particular service may become less true. For example,
multiple instances of the same service on the same host cannot multiple instances of the same service on the same host cannot
generally listen on the same port, and multiple hosts behind the same generally listen on the same port, and multiple hosts behind the same
NAT gateway cannot all have a mapping for the same port on the NAT gateway cannot all have a mapping for the same port on the
external side of the NAT gateway, whether using static port mappings external side of the NAT gateway, whether using static port mappings
configured by hand by the user, or dynamic port mappings configured configured by hand by the user, or dynamic port mappings configured
automatically using a port mapping protocol NAT Port Mapping Protocol automatically using a port mapping protocol like NAT Port Mapping
(NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device (IGD) Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device
[IGD]. (IGD) [IGD].
Applications either use numeric port numbers directly, look up port Applications may use numeric port numbers directly, look up port
numbers based on service names via system calls such as numbers based on service names via system calls such as
getservbyname() on UNIX, look up port numbers by performing queries getservbyname() on UNIX, look up port numbers by performing queries
for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd] or for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd], or
determine port numbers in a variety of other ways like the TCP Port determine port numbers in a variety of other ways like the TCP Port
Service Multiplexer (TCPMUX) [RFC1078]. Service Multiplexer (TCPMUX) [RFC1078].
Designers of applications and application-level protocols may apply Designers of applications and application-level protocols may apply
to IANA for an assigned port number and service name for a specific to IANA for an assigned service name and port number for a specific
application, and may - after successful registration - assume that no application, and may - after successful registration - assume that no
other application will use that port number or service name for its other application will use that service name or port number for its
communication sessions. Alternatively, application designers may communication sessions. Alternatively, application designers may
also ask for only an assigned service name, if their application does also ask for only an assigned service name, if their application does
not require a fixed port number. The latter alternative is not require a fixed port number. The latter alternative is
encouraged when possible, in order to conserve the more limited port encouraged when possible, in order to conserve the more limited port
number space. This includes, for example, applications that use DNS number space. This is applicable, for example, to applications that
SRV records to look up port numbers at runtime. use DNS SRV records to look up port numbers at runtime.
4. Conventions Used in this Document 4. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
5. Service Names 5. Service Names
Service names are the unique key in the Port and Service Name Service names are the unique key in the Service Name and Transport
registry. This unique symbolic name for a service may also be used Protocol Port Number Registry. This unique symbolic name for a
for other purposes, such as in DNS SRV records [RFC2782]. Within the service may also be used for other purposes, such as in DNS SRV
registry, this unique key ensures that different services can be records [RFC2782]. Within the registry, this unique key ensures that
unambiguously distinguished, thus preventing name collisions and different services can be unambiguously distinguished, thus
avoiding confusion about who is the administrative contact for a preventing name collisions and avoiding confusion about who is the
particular entry. Registrant for a particular entry.
For each service name, there may exist zero or more associated port
number assignments. A port number assignment associated with a
service name contains the transport protocol, port number and
possibly additional data, such as a DCCP Service Code.
There may be more than one service name associated with a particular There may be more than one service name associated with a particular
transport protocol and port. There are two valid reasons for transport protocol and port. There are three ways that such service
allowing service name aliases: name overloading can occur:
o Aliases are permissible when all such service names are for the
same service, such as with "http" and "www", which both name TCP
port 80. In such cases, one of the service names SHOULD be
designated primary, for use with mechanisms such as DNS SRV
Records [RFC2782], and the others SHOULD be designated as aliases
of the primary service name. This is necessary so that clients
and servers using a service discovery mechanism use a consistent
name by which to refer to a given service. Otherwise, if a server
were to advertise that it supports the "www" service, and a client
were to seek instances of the "http" service, that client would
fail to discover that server, defeating the purpose of having a
service discovery mechanism. For aliases that do not indicate a
primary alias, a server is expected to register itself under all
aliased service names.
o Aliases are also permissible when one service is an extension of o Overloading occurs when one service is an extension of another
another service, and an in-band mechanisms exists for determining service, and an in-band mechanism exists for determining if the
if the extension is present or not. One example is port 3478, extension is present or not. One example is port 3478, which has
which has the service name aliases "stun" and "turn". TURN the service name aliases "stun" and "turn". TURN [RFC5766] is an
[RFC5766] is an extension to the STUN [RFC5389] service. TURN- extension to the STUN [RFC5389] service. TURN-enabled clients
enabled clients wishing to locate TURN servers could attempt to wishing to locate TURN servers could attempt to discover "stun"
discover "stun" services and then checking in-band if the server services and then check in-band if the server supports TURN, but
supports TURN, but this is inefficient. Enabling them to directly this would be inefficient. Enabling them to directly query for
query for "turn" servers by name is a better approach. (Note that "turn" servers by name is a better approach. (Note that TURN
TURN servers in this case should also be locatable via a "stun" servers in this case should also be locatable via a "stun"
discovery, because every TURN server is also a STUN server.) discovery, because every TURN server is also a STUN server.)
o By historical accident the service name "http" corresponds to the
same port number as "www" and "www-http". When used in SRV
records [RFC2782], and similar service discovery mechanisms only
the service name "http" should be used, not these additional
names. If a server were to advertise "www" then it would not be
discovered by clients browsing for "http". Advertising or
browsing for the aliases as well as the primary service name would
be inefficient, and achieves nothing that it not already achieved
by using the service name "http" exclusively.
o As indicated in this document, in Section 10.1, to enable legacy
names to be replaced with names consistent with the syntax this
document prescribes. In this case, only the new name should be
used in SRV records, both to avoid the same issues as with
historical cases of multiple names, as well as because the legacy
names are incompatible with SRV record use.
For future assignments, applications will not be permitted that
merely request a new name exactly duplicating an existing service.
Having multiple names for the same service serves no purpose.
Implementers are requested to inform IANA if they discover other
cases where a single service has multiple names, so that one name may
be recorded as the primary name for service discovery purposes.
Service names are assigned on a "first come, first served" basis, as Service names are assigned on a "first come, first served" basis, as
described in Section 8.1. Names should be brief and informative, described in Section 8.1. Names should be brief and informative,
avoiding words or abbreviations that are redundant in the context of avoiding words or abbreviations that are redundant in the context of
the registry (e.g., "port", "service", "protocol", etc.) Names the registry (e.g., "port", "service", "protocol", etc.) Names
referring to discovery services, e.g., using multicast or broadcast referring to discovery services, e.g., using multicast or broadcast
to identify endpoints capable of a given service, SHOULD use an to identify endpoints capable of a given service, SHOULD use an
easily identifiable suffix (e.g., "-disc"). easily identifiable suffix (e.g., "-disc").
5.1. Service Name Syntax 5.1. Service Name Syntax
Valid service names MUST contain only these US-ASCII [ANSI.X3-4.1986] Valid service names are hereby normatively defined as follows:
characters: letters from A to Z and a to z, digits from 0 to 9, and
hyphens ("-", ASCII 0x2D or decimal 45). They MUST be at least one
character and no more than fifteen characters long, MUST NOT begin or
end with a hyphen, and MUST NOT consist of only digits (in order to
be distinguishable from port numbers, which are typically written as
all digits).
The service name syntax MAY be used to validate a service name o MUST be at least 1 character and no more than 15 characters long
string, but MUST NOT be used for any other purpose (e.g.,
delineation). Any system that includes a service name inside a
longer string is itself responsible for delineating the service name.
Such systems MUST NOT rely on the syntax of a service name alone for
such delineation.
The syntax defined in ABNF [RFC5234]: o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and
'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or
decimal 45)
SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) / o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')
(1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM))
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 o MUST NOT begin or end with a hyphen
HYPHEN = %x2d ; "-"
ALPHA = <See [RFC5234]> The reason for requiring at least one letter is to avoid service
DIGIT = <See [RFC5234]> names like "23" (could be confused with a numeric port number) or
"6000-6063" (could be confused with a numeric port number range).
Although service names may contain both upper-case and lower-case
letters, case is ignored for comparison purposes, so both "http" and
"HTTP" denote the same service.
Service names are purely opaque identifiers, and no semantics are
implied by any superficial structure that a given service name may
appear to have. For example, a company called "Example" may choose
to register service names "Example-Foo" and "Example-Bar" for its
"Foo" and "Bar" products, but the "Example" company can't claim to
"own" all service names beginning with "Example-", they can't prevent
someone else registering "Example-Baz" for a different service, and
they can't prevent other developers from using the "Example-Foo" and
"Example-Bar" service types in order to interoperate with the "Foo"
and "Bar" products. Technically speaking, in service discovery
protocols, service names are merely a series of byte values on the
wire; for the mnemonic convenience of human developers it can be
convenient to interpret those byte values as human-readable ascii
characters, but software should treat them as purely opaque
identifiers and not attempt to parse them for any additional embedded
meaning.
In approximately 98% of cases, the new "service name" is exactly the
same as the old historic "short name" from the IANA web forms
[SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service
name" is derived from the old historic "short name" as described
below in Section 10.1.
The rules for valid service names, excepting the limit of 15
characters maximu, are also expressed below (as a non-normative
convenience) using ABNF [RFC5234].
SRVNAME = (ALPHA / (1*DIGIT [HYPHEN] ALPHA)) *([HYPHEN] ALNUM)
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9
HYPHEN = %x2d ; "-"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = %x30-39 ; 0-9 [RFC5234]
5.2. Service Name Usage in DNS SRV Records 5.2. Service Name Usage in DNS SRV Records
The DNS SRV specification [RFC2782] requests that the Service Label The DNS SRV specification [RFC2782] states that the Service Label
part of the owner name of DNS SRV records includes a "Service" part of the owner name of a DNS SRV record includes a "Service"
element, defined to be "the symbolic name of the desired service", element, described as "the symbolic name of the desired service", but
but did not state precisely which part of the IANA database (i.e. as discussed above, it is not clear precisely what this means.
STD 2 when [RFC2782] was written) serves as a registry for standard
service names.
This document clarifies that the Service Label MUST be a service name This document clarifies that the Service Label MUST be a service name
as defined herein. The service name SHOULD be registered with IANA as defined herein. The service name SHOULD be registered with IANA
and recorded in the Service Names and Port Numbers registry and recorded in the Service Name and Transport Protocol Port Number
[PORTREG]. This is needed to ensure that only a single registry of Registry [PORTREG].
Service Names exists and name collisions can be avoided in the
future.
The details of the use of Service Names from [PORTREG] in SRV Service
Labels are specified in [RFC2782] and the documents updating or
replacing that specification (see the companion document
[I-D.gudmundsson-dnsext-srv-clarify] for more information).
The details of how applications make use of DNS SRV should be The details of using Service Names in SRV Service Labels are
specified in the documentation set of the application/service. In specified in the DNS SRV specification [RFC2782]. This document does
the absence of such specification, prospective clients of a given not change that specification.
service should not assume the existence of SRV RRs for this service
or, if they have indications that this will be the case (e.g., by
configuration), must assume the unextended naming scheme from
[RFC2782] for service discovery with DNS SRV, i.e., the Service Label
is constructed from the Service Name registered in [PORTREG] by
prepending a single underscore character ("_").
6. Port Number Ranges 6. Port Number Ranges
TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their TCP, UDP, UDP-Lite, SCTP and DCCP use sixteen-bit namespaces for
port number registries. The port registries for all these transport their port number registries. The port registries for all these
protocols are subdivided into three ranges of numbers, and transport protocols are subdivided into three ranges of numbers, and
Section 7.3 describes the IANA procedures for each range in detail: Section 8.1.1 describes the IANA procedures for each range in detail:
o the Well Known Ports, also known as the System Ports, from 0-1023 o the System Ports, also known as the Well Known Ports, from 0-1023
(assigned by IANA) (assigned by IANA)
o the Registered Ports, also known as the User Ports, from 1024- o the User Ports, also known as the Registered Ports, from 1024-
49151 (assigned by IANA) 49151 (assigned by IANA)
o the Dynamic Ports, also known as the Private Ports, from 49152- o the Dynamic Ports, also known as the Private Ports, from 49152-
65535 (never assigned) 65535 (never assigned)
Of the assignable port ranges (Well Known and Registered, i.e., port Of the assignable port ranges (System Ports and User Ports, i.e.,
numbers 0-49151), individual port numbers are in one of three states port numbers 0-49151), individual port numbers are in one of three
at any given time: states at any given time:
o Assigned: Assigned port numbers are currently allocated to the o Assigned: Assigned port numbers are currently allocated to the
service indicated in the registry. service indicated in the registry.
o Unassigned: Unassigned port numbers are currently available for o Unassigned: Unassigned port numbers are currently available for
assignment upon request, as per the procedures outlined in this assignment upon request, as per the procedures outlined in this
document. document.
o Reserved: Reserved port numbers are not available for regular o Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes. assignment; they are "assigned to IANA" for special purposes.
skipping to change at page 11, line 4 skipping to change at page 11, line 21
o Assigned: Assigned port numbers are currently allocated to the o Assigned: Assigned port numbers are currently allocated to the
service indicated in the registry. service indicated in the registry.
o Unassigned: Unassigned port numbers are currently available for o Unassigned: Unassigned port numbers are currently available for
assignment upon request, as per the procedures outlined in this assignment upon request, as per the procedures outlined in this
document. document.
o Reserved: Reserved port numbers are not available for regular o Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes. assignment; they are "assigned to IANA" for special purposes.
Reserved port numbers include values at the edges of each range, Reserved port numbers include values at the edges of each range,
e.g., 0, 1023, 1024, etc., which may be used to extend these e.g., 0, 1023, 1024, etc., which may be used to extend these
ranges or the overall port number space in the future. ranges or the overall port number space in the future.
In order to keep the size of the registry manageable, IANA typically In order to keep the size of the registry manageable, IANA typically
only records the Assigned and Reserved port numbers and service names only records the Assigned and Reserved service names and port numbers
in the registry. Unassigned values are typically not explicitly in the registry. Unassigned values are typically not explicitly
listed. listed. (There are an near-infinite number of Unassigned service
names and enumerating them all would not be practical.)
As a data point, when this document was written, approximately 76% of As a data point, when this document was written, approximately 76% of
the TCP and UDP Well Known Ports were assigned, and approximately 9% the TCP and UDP System Ports were assigned, and approximately 9% of
of the Registered Ports were assigned. (As noted, Dynamic Ports are the User Ports were assigned. (As noted, Dynamic Ports are never
never assigned.) assigned.)
6.1. Port Numbers and Service Names for Experimentation 6.1. Service names and Port Numbers for Experimentation
Of the Well Known ports, two TCP and UDP port numbers (1021 and Of the System Ports, two TCP and UDP port numbers (1021 and 1022),
1022), together with their respective service names ("exp1" and together with their respective service names ("exp1" and "exp2"),
"exp2"), have been assigned for experimentation with new applications have been assigned for experimentation with new applications and
and application-layer protocols that require a port number in the application-layer protocols that require a port number in the
assigned ports ranges [RFC4727]. assigned ports ranges [RFC4727].
Please refer to Sections 1 and 1.1 of "Assigning Experimental and Please refer to Sections 1 and 1.1 of "Assigning Experimental and
Testing Numbers Considered Useful" [RFC3692] for how these Testing Numbers Considered Useful" [RFC3692] for how these
experimental port numbers are to be used. experimental port numbers are to be used.
This document registers the same two port numbers and service names This document registers the same two service names and port numbers
for experimentation with new application-layer protocols over SCTP for experimentation with new application-layer protocols over SCTP
and DCCP in Section 10.2. and DCCP in Section 10.2.
Unfortunately, it can be difficult to limit access to these ports. Unfortunately, it can be difficult to limit access to these ports.
Users SHOULD take measures to ensure that experimental ports are Users SHOULD take measures to ensure that experimental ports are
connecting to the intended process. For example, users of these connecting to the intended process. For example, users of these
experimental ports might include a 64-bit nonce, once on each segment experimental ports might include a 64-bit nonce, once on each segment
of a message-oriented channel (e.g., UDP), or once at the beginning of a message-oriented channel (e.g., UDP), or once at the beginning
of a byte-stream (e.g., TCP), which is used to confirm that the port of a byte-stream (e.g., TCP), which is used to confirm that the port
is being used as intended. Such confirmation of intended use is is being used as intended. Such confirmation of intended use is
especially important when these ports are associated with privileged especially important when these ports are associated with privileged
(e.g., system or administrator) processes. (e.g., system or administrator) processes.
7. Principles for Port Number and Service Name Registry Management 7. Principles for Service Name and Transport Protocol Port Number
Registry Management
Management procedures for the port number and service name registry Management procedures for the service name and transport protocol
include allocation of port numbers and service names upon request, as port number registry include allocation of service names and port
well as coordination of information about existing allocations. The numbers upon request, as well as management of information about
latter includes maintaining contact and description information about existing allocations. The latter includes maintaining contact and
assignments, revoking abandoned assignments, and redefining description information about assignments, revoking abandoned
assignments when needed. Of these procedures, port number allocation assignments, and redefining assignments when needed. Of these
is most critical, in order to continue to conserve the remaining port procedures, careful port number allocation is most critical, in order
numbers. to continue to conserve the remaining port numbers.
As noted earlier, only ~9% of the Registered Port space is currently As noted earlier, only about 9% of the User Port space is currently
assigned. The current rate of assignment is approximately 400 ports/ assigned. The current rate of assignment is approximately 400 ports
year, and has remained linear for the past 8 years. At that rate, if per year, and has remained steady for the past 8 years. At that
similar conservation continues, this resource will sustain another 85 rate, if similar conservation continues, this resource will sustain
years of assignment - without the need to resort to reassignment of another 85 years of assignment - without the need to resort to
released values or revocation. Note that the namespace available for reassignment of released values or revocation. The namespace
service names is even larger, which allows for a simpler management available for service names is much larger, which allows for simpler
procedures. management procedures.
7.1. Past Principles 7.1. Past Principles
Before the publication of this document, the principles of port Before the publication of this document, the principles of service
number and service name management followed a few mostly-undocumented name and port number management followed a few mostly-undocumented
guidelines. They are recorded here for historical purposes, and this guidelines. They are recorded here for historical purposes, and this
document updates them in Section 7.2. These principles were: document updates them in Section 7.2. These principles were:
o TCP and UDP ports were simultaneously allocated when either was o TCP and UDP ports were simultaneously allocated when either was
requested requested
o Port numbers were the primary allocation; service names were o Port numbers were the primary allocation; service names were
informative only, and did not have a well-defined syntax informative only, and did not have a well-defined syntax
o Port numbers were conserved informally, and sometimes o Port numbers were conserved informally, and sometimes
inconsistently (e.g., some services were allocated ranges of many inconsistently (e.g., some services were allocated ranges of many
port numbers even where not strictly necessary) port numbers even where not strictly necessary)
o SCTP and DCCP port number and service name registries were managed o SCTP and DCCP service name and port number registries were managed
separately from the TCP/UDP registries separately from the TCP/UDP registries
o Service names could not be assigned in the ports registry without o Service names could not be assigned in the old ports registry
assigning a corresponding port number at the same time without assigning an associated port number at the same time
This document clarifies and aligns these guidelines in order to more This document clarifies and aligns these guidelines in order to more
conservatively manage the limited remaining port number space and to conservatively manage the limited remaining port number space and to
enable and promote the use of service names for service enable and promote the use of service names for service
identification without associated port numbers, where possible. identification without associated port numbers, where possible.
7.2. Updated Principles 7.2. Updated Principles
This section summarizes the basic principles by which IANA handles This section summarizes the basic principles by which IANA handles
the Port and Service Name registry, and attempts to conserve the port the Service Name and Transport Protocol Port Number Registry, and
number space. This description is intended to inform applicants attempts to conserve the port number space. This description is
requesting service names and port numbers. IANA decisions are not intended to inform applicants requesting service names and port
required to be bound to these principles, however; other factors may numbers. IANA are not required to be bound by these principles when
come into play, and exceptions may occur where deemed in the best handling requests; other factors may come into play, and exceptions
interest of the Internet. may occur where deemed in the best interest of the Internet.
IANA will begin assigning service names that do not request a IANA will begin assigning service names that do not request an
corresponding port number allocation under a simple "First Come, associated port number allocation under a simple "First Come, First
First Served" policy [RFC5226]. IANA MAY, at its discretion, refer Served" policy [RFC5226]. IANA MAY, at its discretion, refer service
service name requests to "Expert Review" in cases of mass name requests to "Expert Review" in cases of mass registrations or
registrations or other situations where IANA believes expert review other situations where IANA believes expert review is advisable.
is advisable.
The basic principle of port number registry management is to conserve The basic principle of service name and port number registry
use of the port space where possible. Extensions to support larger management is to conserve use of the port space where possible.
port number spaces would require changing many core protocols of the Extensions to support larger port number spaces would require
current Internet in a way that would not be backward compatible and changing many core protocols of the current Internet in a way that
interfere with both current and legacy applications. To help ensure would not be backward compatible and interfere with both current and
this conservation the policy for any registration request for port legacy applications. To help ensure this conservation the policy for
number allocations uses the "Expert Review" policy [RFC5226]. any registration request for port number allocations uses the "Expert
Review" policy [RFC5226].
Conservation of the port number space is required because this space Conservation of the port number space is required because this space
is a limited resource, applications are expected to participate in is a limited resource, so applications are expected to participate in
the traffic demultiplexing process where feasible. The port numbers the traffic demultiplexing process where feasible. The port numbers
are expected to encode as little information as possible that will are expected to encode as little information as possible that will
still enable an application to perform further demultiplexing by still enable an application to perform further demultiplexing by
itself. In particular: itself. In particular:
o IANA will allocate only one assigned port number per service or o IANA will allocate only one assigned port number per service or
application application
o IANA will allocate only one assigned port number for all versions o IANA will allocate only one assigned port number for all versions
of a service (e.g., running the service with or without a security of a service (e.g., running the service with or without a security
mechanism, or for updated variants of a service) mechanism, or for updated variants of a service)
o IANA will allocate only one assigned port number for all different o IANA will allocate only one assigned port number for all different
types of device using or participating in the same service types of device using or participating in the same service
o IANA will allocate port numbers only for the transport protocol(s) o IANA will allocate port numbers only for the transport protocol(s)
explicitly named in an registration request explicitly named in a registration request
o IANA may recover unused port numbers, via the new procedures of o IANA may recover unused port numbers, via the new procedures of
de-registration, revocation, and transfer de-registration, revocation, and transfer
A given service is expected to further demultiplex messages where Where possible, a given service is expected to demultiplex messages
possible. For example, applications and protocols are expected to if necessary. For example, applications and protocols are expected
include in-band version information, so that future versions of the to include in-band version information, so that future versions of
application or protocol can share the same allocated port. the application or protocol can share the same allocated port.
Applications and protocols are also expected to be able to Applications and protocols are also expected to be able to
efficiently use a single allocated port for multiple sessions, either efficiently use a single allocated port for multiple sessions, either
by demultiplexing multiple streams within one port, or using the by demultiplexing multiple streams within one port, or using the
allocated port to coordinate using dynamic ports for subsequent allocated port to coordinate using dynamic ports for subsequent
exchanges (e.g., in the spirit of FTP [RFC0959]). exchanges (e.g., in the spirit of FTP [RFC0959]).
Ports are used in various ways, notably: Ports are used in various ways, notably:
o as endpoint process identifiers o as endpoint process identifiers
o as application protocol identifiers o as application protocol identifiers
o for firewall filtering purposes o for firewall filtering purposes
The process and protocol identifier use suggests that anything a Both the process identifier and the protocol identifier uses suggest
single process can demultiplex, or that can be encoded into a single that anything a single process can demultiplex, or that can be
protocol, should be. The firewall filtering use suggests that some encoded into a single protocol, should be. The firewall filtering
uses that could be multiplexed or encoded must be separated to allow use suggests that some uses that could be multiplexed or encoded
for firewall management. Note that this latter use is much less could instead be separated to allow for easier firewall management.
sound, because port numbers have meaning only for the two endpoints Note that this latter use is much less sound, because port numbers
involved in a connection, and drawing conclusions about the service have meaning only for the two endpoints involved in a connection, and
that generated a given flow based on observed port numbers is not drawing conclusions about the service that generated a given flow
always reliable. Further, previous separation of protocol variants based on observed port numbers is not always reliable. Further,
based on security capabilities (e.g., HTTP on TCP port 80 vs. HTTPS previous separation of protocol variants based on security
on TCP port 443) is not recommended for new protocols, because all capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
should be security-capable and capable of negotiating the use of not recommended for new protocols, because all new protocols should
security in-band. be security-capable and capable of negotiating the use of security
in-band.
IANA will begin assigning port numbers for only those transport IANA will begin assigning port numbers for only those transport
protocols explicitly included in a registration request. This ends protocols explicitly included in a registration request. This ends
the long-standing practice of automatically assigning a port number the long-standing practice of automatically assigning a port number
to an application for both TCP and a UDP, even if the request is for to an application for both TCP and a UDP, even if the request is for
only one of these transport protocols. The new allocation procedure only one of these transport protocols. The new allocation procedure
conserves resources by allocating a port number to an application for conserves resources by allocating a port number to an application for
only those transport protocols (TCP, UDP, SCTP and/or DCCP) it only those transport protocols (TCP, UDP, SCTP and/or DCCP) it
actually uses. The port number will be marked as Reserved - instead actually uses. The port number will be marked as Reserved - instead
of Assigned - in the port number registries of the other transport of Assigned - in the port number registries of the other transport
protocols. When applications start supporting the use of some of protocols. When applications start supporting the use of some of
those additional transport protocols, the administrative contact for those additional transport protocols, the Registrant for the
the registration MUST request IANA to convert the reservation into a registration MUST request IANA to convert the reservation into a
proper assignment. An application MUST NOT assume that it can use a proper assignment. An application MUST NOT assume that it can use a
port number assigned to it for use with one transport protocol with port number assigned to it for use with one transport protocol with
another transport protocol without asking IANA to convert the another transport protocol without asking IANA to convert the
reservation into an assignment. reservation into an assignment.
When the available pool of unassigned numbers has run out in a ports When the available pool of unassigned numbers has run out in a ports
range, it will be necessary for IANA to consider the Reserved ports range, it will be necessary for IANA to consider the Reserved ports
for assignment. This is part of the motivation to not automatically for assignment. This is part of the motivation for not automatically
assigning ports for other transport protocols than the requested assigning ports for transport protocols other than the requested
ones. This will allow more ports to be available for assignment at one(s). This will allow more ports to be available for assignment
that point. It also shows the importance to register the transport when that time comes. To help conserve ports, application developers
protocols that are in fact used. should register only the transport protocols that their application
currently uses.
Conservation of port numbers is improved by procedures that allow Conservation of port numbers is improved by procedures that allow
previously allocated port numbers to become Unassigned, either previously allocated port numbers to become Unassigned, either
through de-registration or through revocation, and by a procedure through de-registration or through revocation, and by a procedure
that lets application designers transfer an allocated but unused port that lets application designers transfer an allocated but unused port
number to a new application. Section 8 describes these procedures, number to a new application. Section 8 describes these procedures,
which so far were undocumented. Port number conservation is also which until now were undocumented. Port number conservation is also
improved by recommending that applications that do not require an improved by recommending that applications that do not require an
allocated port chose this option and register only a service name. allocated port should register only a service name without an
associated port number.
7.3. Variances for Specific Port Number Ranges
Section 6 describes the different port number ranges. It is
important to note that IANA applies slightly different procedures
when managing the different ranges of the port number registry:
o Ports in the Dynamic Ports range (49152-65535) have been
specifically set aside for local and dynamic use and cannot be
registered through IANA. Applications may simply use them for
communication without any sort of registration. On the other
hand, applications MUST NOT assume that a specific port number in
the Dynamic Ports range will always be available for communication
at all times, and a port number in that range hence MUST NOT be
used as a service identifier.
o Ports in the Registered Ports range (1024-49151) are available for
registration through IANA, and MAY be used as service identifiers
upon successful registration. Because registering a port number
for a specific application consumes a fraction of the shared
resource that is the port number registry, IANA will require the
requester to document the intended use of the port number. This
documentation will be input to the "Expert Review" allocation
procedure [RFC5226], by which IANA will have a technical expert
review the request to determine whether to grant the registration.
The submitted documentation MUST explain why using a port number
in the Dynamic Ports range is unsuitable for the given
application. Ports in the Registered Ports range may also be
assigned under the "IETF Review" or "IESG Approval" allocation
procedures [RFC5226], which is how most assignments for IETF
protocols are handled.
o Ports in the Well Known Ports range (0-1023) are also available
for registration through IANA. Because the Well Known Ports range
is both the smallest and the most densely allocated, the
requirements for new allocations are more strict than those for
the Registered Ports range, and will only be granted under the
"IETF Review" or "IESG Approval" allocation procedures [RFC5226].
A request for a Well Known port number MUST document why using a
port number from both the Registered Ports and Dynamic Ports
ranges is unsuitable for the given application.
8. IANA Procedures for Managing the Port Number and Service Name 8. IANA Procedures for Managing the Service Name and Transport Protocol
Registry Port Number Registry
This section describes the process for requests associated with This section describes the process for handling requests associated
IANA's management of the port number and service name registry. Such with IANA's management of the Service Name and Transport Protocol
requests include initial registration, de-registration, re-use, Port Number Registry. Such requests include initial registration,
changes to the service name, as well as updates to the contact de-registration, re-use, changes to the service name, and updates to
information or description associated with an assignment. Revocation the contact information or description associated with an assignment.
is initiated by IANA. Revocation is as additional process, initiated by IANA.
8.1. Port Number and Service Name Registration 8.1. Service Name and Port Number Registration
Registration refers to the allocation of port numbers or service Registration refers to the allocation of service names or port
names to applicants. All such registrations are made from port numbers to applicants. All such registrations are made from service
numbers or service names that are Unassigned or Reserved at the time names or port numbers that are Unassigned or Reserved at the time of
of the allocation. Unassigned numbers and names are allocated as the allocation. Unassigned names and numbers are allocated according
needed, and without further explanation. Reserved numbers and names to the rules described in Section 8.1.1 below. Reserved numbers and
are assigned only after review by IANA and the IETF, and are names are assigned only by Standards Action or IESG Approval, and
accompanied by a statement explaining the reason a Reserved number or MUST accompanied by a statement explaining the reason a Reserved
name is appropriate for this action. number or name is appropriate for this action.
When a registration for one or more transport protocols is approved, When a registration for one or more transport protocols is approved,
the port number for any non-requested transport protocol(s) will be the port number for any non-requested transport protocol(s) will be
marked as Reserved. IANA SHOULD NOT assign that port number to any marked as Reserved. IANA SHOULD NOT assign that port number to any
other application or service until no other port numbers remain other application or service until no other port numbers remain
Unassigned in the requested range. The current administrative Unassigned in the requested range. The current Registrant for a port
contact for a port number MAY register these Reserved port numbers number MAY register these Reserved port numbers for other transport
for other transport protocols when needed. protocols when needed.
Service names, on the other hand, are not tied to a specific
transport protocol, and registration requests for only a service name
(but not a port number) allocate that service name for use with all
transport protocols.
A port number or service name registration request contains some or A service name or port number registration request contains the
all of the following information. The combination of service name following information. The service name is the unique identifier of
and transport protocol is the unique identifier of a given service: a given service:
Service Name (REQUIRED) Service Name (REQUIRED)
Transport Protocol(s) (REQUIRED) Transport Protocol(s) (REQUIRED)
Registration Administrative Contact (REQUIRED) Registrant (REQUIRED)
Registration Technical Contact (REQUIRED) Contact (REQUIRED)
Port Number (OPTIONAL)
Service Code (only REQUIRED for DCCP)
Description (REQUIRED) Description (REQUIRED)
Reference (REQUIRED) Reference (REQUIRED)
Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL) Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL) Assignment Notes (OPTIONAL)
o Service Name: A desired unique service name for the service o Service Name: A desired unique service name for the service
associated with the registration request MUST be provided, for use associated with the registration request MUST be provided, for use
in various service selection and discovery mechanisms (including, in various service selection and discovery mechanisms (including,
but not limited to, DNS SRV records [RFC2782]). The name MUST be but not limited to, DNS SRV records [RFC2782]). The name MUST be
compliant with the syntax defined in Section 5.1. In order to be compliant with the syntax defined in Section 5.1. In order to be
unique, they MUST NOT be identical to any currently registered unique, they MUST NOT be identical to any currently assigned
service names in the IANA registry [PORTREG]. Service names are service name in the IANA registry [PORTREG]. Service names are
case-insensitive; they may be provided and entered into the case-insensitive; they may be provided and entered into the
registry with mixed case (e.g., for clarity), but for the purposes registry with mixed case for clarity, but for the comparison
of comparison, the case is ignored. purposes the case is ignored.
o Transport Protocol(s): The transport protocol(s) for which the o Transport Protocol(s): The transport protocol(s) for which a
allocation is requested MUST be provided. This field is currently allocation is requested MUST be provided. This field is currently
limited to one or more of TCP, UDP, SCTP, and DCCP. This field is limited to one or more of TCP, UDP, SCTP, and DCCP. Requests
required even for services with no port number. without any port allocation and only a service name are still
required to indicate which protocol the service uses.
o Registration Administrative Contact: Name and email address of the
administrative contact for the registration. This is REQUIRED.
The name of the administrative contact identifies the
organization, company, or individual who is responsible for the
registration. For registrations done through IETF-published RFCs,
the administrative contact will be the IESG.
o Registration Technical Contact: Name and email address of the
technical contact person for the registration. This is REQUIRED.
For individuals, this is the same as the Registration
Administrative Contact; for organizations, this is a point of
contact at that organization. Additional address information MAY
be provided. For registrations done through IETF-published RFCs,
the technical contact will be the IESG.
o Port Number: If assignment of a port number is desired, either the o Registrant: Name and email address of the Registrant. This is
currently Unassigned port number the requester suggests for REQUIRED. The Registrant is the Organization or Company
allocation, or the text "ANY", MUST be provided. If only a responsible for the initial registration. For registrations done
service name is to be assigned, this field MUST be empty. If a through IETF-published RFCs, the Registrant will be the IESG.
specific port number is requested, IANA is encouraged to allocate
the requested number. If the text "ANY" is specified, IANA will
choose a suitable number from the Registered Ports range. Note
that the applicant MUST NOT use the requested port prior to the
completion of the registration.
o Service Code: The request MUST include a desired unique DCCP o Contact: Name and email address of the Contact person for the
service code [RFC5595], if the registration request includes DCCP registration. This is REQUIRED. The Contact person is the
as a transport protocol, and MUST NOT include a requested DCCP responsible person for the Internet community to send questions
service code otherwise. Section 19.8 of [RFC4340] defines to. This person would also be authorized to submit changes on
requirements and rules for allocation, updated by this document. behalf of the Registrant; in cases of conflict between the
Registrant and the Contact, the Registrant decisions take
precedence. Additional address information MAY be provided. For
registrations done through IETF-published RFCs, the Contact will
be the IESG.
o Description: A short description of the service associated with o Description: A short description of the service associated with
the registration request is REQUIRED. It should avoid all but the the registration request is REQUIRED. It should avoid all but the
most well known acronyms. most well-known acronyms.
o Reference: A description of (or a reference to a document o Reference: A description of (or a reference to a document
describing) the protocol or application using this port. The describing) the protocol or application using this port. The
description must include whether the protocol uses either description must state whether the protocol uses broadcast,
broadcast, multicast, or anycast communication. multicast, or anycast communication.
For registrations requesting only a Service Name or a Service Name For registrations requesting only a Service Name, or a Service
and Registered Port, a statement that the protocol is proprietary Name and User Port, a statement that the protocol is proprietary
and not publicly documented is also acceptable provided that the and not publicly documented is also acceptable provided that the
above information regarding use of broadcast, multicast, or required information regarding use of broadcast, multicast, or
anycast is given. anycast is given.
For registration requests for a Registered Port, the registration For registration requests for a User Port, the registration
request MUST explain why a port number in the Dynamic Ports range request MUST explain why a port number in the Dynamic Ports range
is unsuitable for the given application. is unsuitable for the given application.
For registration requests for a Well Known Port, the registration For registration requests for a System Port, the registration
request MUST explain why a port number in the Registered Ports or request MUST explain why a port number in the User Ports or
Dynamic Ports ranges is unsuitable, and a reference to a stable Dynamic Ports ranges is unsuitable, and a reference to a stable
protocol specification document MUST be provided. For requests protocol specification document MUST be provided. For requests
from IETF Working Groups, IANA MAY accept "Early" registration from IETF Working Groups, IANA MAY accept "early registration"
requests referencing a sufficiently stable Internet Draft instead [RFC4020] requests referencing a sufficiently stable Internet
of a published Standards-Track RFC [RFC4020]. Draft instead of a published Standards-Track RFC.
o Port Number: If assignment of a port number is desired, either the
currently Unassigned or Reserved port number the requester
suggests for allocation, or indication of which port range, user
or system, that the requester requires, MUST be provided. If only
a service name is to be assigned, this field is left empty. If a
specific port number is requested, IANA is encouraged to allocate
the requested number. If a range is specified, IANA will choose a
suitable number from the User or System Ports ranges. Note that
the applicant MUST NOT use the requested port prior to the
completion of the registration.
o Service Code: If the registration request includes DCCP as a
transport protocol then the request MUST include a desired unique
DCCP service code [RFC5595], and MUST NOT include a requested DCCP
service code otherwise. Section 19.8 of the DCCP specification
[RFC4340] defines requirements and rules for allocation, updated
by this document.
o Known Unauthorized Uses: A list of uses by applications or o Known Unauthorized Uses: A list of uses by applications or
organizations who are not the assignee. This list may be organizations who are not the assignee. This list may be
augmented by IANA after assignment when unauthorized uses are augmented by IANA after assignment when unauthorized uses are
reported. reported.
o Assignment Notes: Indications of owner/name change, or any other o Assignment Notes: Indications of owner/name change, or any other
assignment process issue. This list may be updated by IANA after assignment process issue. This list may be updated by IANA after
assignment to help track changes to an assignment, e.g., de- assignment to help track changes to an assignment, e.g., de-
registration, owner/name changes, etc. registration, owner/name changes, etc.
If the registration request is for the addition of a new transport If the registration request is for the addition of a new transport
protocol to an already assigned service name, IANA needs to confirm protocol to an already assigned service name, IANA needs to confirm
with the administrative contact for the existing assignment whether with the Registrant for the existing assignment whether this addition
this addition is appropriate. is appropriate.
If the registration request is for a service name alias (see If the registration request is for a service name overloading a port
Section 5), IANA needs to confirm with the administrative contact for number (see Section 5), IANA needs to confirm with the Registrant for
the existing service name whether the registration of the alias is the existing service name whether the registration of the overloading
appropriate. is appropriate.
When IANA receives a registration request - containing the above When IANA receives a registration request - containing the above
information - that is requesting a port number, IANA SHALL initiate information - that is requesting a port number, IANA SHALL initiate
an "Expert Review" [RFC5226] in order to determine whether an an "Expert Review" [RFC5226] in order to determine whether an
assignment should be made. For requests that do not include a port assignment should be made. For requests that do not include a port
number, IANA SHOULD assign the service name under a simple "First number, IANA SHOULD assign the service name under a simple "First
Come First Served" policy [RFC5226]. Come First Served" policy [RFC5226].
8.2. Port Number and Service Name De-Registration 8.1.1. Variances for Specific Port Number Ranges
The administrative contact of a granted port number assignment can Section 6 describes the different port number ranges. It is
return the port number to IANA at any time if they no longer have a important to note that IANA applies slightly different procedures
need for it. The port number will be de-registered and will be when managing the different port ranges of the service name and port
marked as Reserved. IANA should not re-assign port numbers that have number registry:
been de-registered until all other available port numbers in the
specific range have been assigned. o Ports in the Dynamic Ports range (49152-65535) have been
specifically set aside for local and dynamic use and cannot be
assigned through IANA. Application software may simply use them
for communication without any sort of registration. On the other
hand, application software MUST NOT assume that a specific port
number in the Dynamic Ports range will always be available for
communication at all times, and a port number in that range hence
MUST NOT be used as a service identifier.
o Ports in the User Ports range (1024-49151) are available for
registration through IANA, and MAY be used as service identifiers
upon successful registration. Because registering a port number
for a specific application consumes a fraction of the shared
resource that is the port number registry, IANA will require the
requester to document the intended use of the port number. This
documentation will be input to the "Expert Review" allocation
procedure [RFC5226], by which IANA will have a technical expert
review the request to determine whether to grant the registration.
The submitted documentation MUST explain why using a port number
in the Dynamic Ports range is unsuitable for the given
application. Ports in the User Ports range may also be assigned
under the "IETF Review" or "IESG Approval" allocation procedures
[RFC5226], which is how most assignments for IETF protocols are
handled.
o Ports in the System Ports range (0-1023) are also available for
registration through IANA. Because the System Ports range is both
the smallest and the most densely allocated, the requirements for
new allocations are more strict than those for the User Ports
range, and will only be granted under the "IETF Review" or "IESG
Approval" allocation procedures [RFC5226]. A request for a System
Port number MUST document *both* why using a port number from the
User Ports is unsuitable *and* why using a port number from the
Dynamic Ports ranges is unsuitable for that application.
8.2. Service Name and Port Number De-Registration
The Registrant of a granted port number assignment can return the
port number to IANA at any time if they no longer have a need for it.
The port number will be de-registered and will be marked as Reserved.
IANA should not re-assign port numbers that have been de-registered
until all unassigned port numbers in the specific range have been
assigned.
Before proceeding with a port number de-registration, IANA needs to Before proceeding with a port number de-registration, IANA needs to
reasonably establish that the value is actually no longer in use. reasonably establish that the value is actually no longer in use.
Because there is much less danger of exhausting the service name Because there is much less danger of exhausting the service name
space compared to the port number space, it is RECOMMENDED that a space compared to the port number space, it is RECOMMENDED that a
given service name remain assigned even after all associated port given service name remain assigned even after all associated port
number assignments have become de-registered. Under this policy, it number assignments have become de-registered. Under this policy, it
will appear in the registry as if it had been created through a will appear in the registry as if it had been created through a
service name registration request that did not include any port service name registration request that did not include any port
numbers. numbers.
On rare occasions, it may still be useful to de-register a service On rare occasions, it may still be useful to de-register a service
name. In such cases, IANA will mark the service name as Reserved. name. In such cases, IANA will mark the service name as Reserved.
IANA will involve their IESG-appointed expert in such cases. IANA will involve their IESG-appointed expert in such cases.
8.3. Port Number and Service Name Re-Use IANA will include a comment in the registry when de-registration
happens to indicate its historic usage.
If the administrative contact of a granted port number assignment no 8.3. Service Name and Port Number Re-Use
longer have a need for the registered number, but would like to re-
use it for a different application, they can submit a request to IANA If the Registrant of a granted port number assignment no longer have
to do so. a need for the assigned number, but would like to re-use it for a
different application, they can submit a request to IANA to do so.
Logically, port number re-use is to be thought of as a de- Logically, port number re-use is to be thought of as a de-
registration (Section 8.2) followed by an immediate re-registration registration (Section 8.2) followed by an immediate re-registration
(Section 8.1) of the same port number for a new application. (Section 8.1) of the same port number for a new application.
Consequently, the information that needs to be provided about the Consequently, the information that needs to be provided about the
proposed new use of the port number is identical to what would need proposed new use of the port number is identical to what would need
to be provided for a new port number allocation for the specific to be provided for a new port number allocation for the specific
ports range. ports range.
Because there is much less danger of exhausting the service name Because there is much less danger of exhausting the service name
skipping to change at page 20, line 32 skipping to change at page 21, line 14
application is NOT RECOMMENDED. application is NOT RECOMMENDED.
IANA needs to carefully review such requests before approving them. IANA needs to carefully review such requests before approving them.
In some instances, the Expert Reviewer will determine that the In some instances, the Expert Reviewer will determine that the
application that the port number was assigned to has found usage application that the port number was assigned to has found usage
beyond the original requester, or that there is a concern that it may beyond the original requester, or that there is a concern that it may
have such users. This determination MUST be made quickly. A have such users. This determination MUST be made quickly. A
community call concerning revocation of a port number (see below) MAY community call concerning revocation of a port number (see below) MAY
be considered, if a broader use of the port number is suspected. be considered, if a broader use of the port number is suspected.
8.4. Port Number and Service Name Revocation 8.4. Service Name and Port Number Revocation
A port number revocation can be thought of as an IANA-initiated de- A port number revocation can be thought of as an IANA-initiated de-
registration (Section 8.2), and has exactly the same effect on the registration (Section 8.2), and has exactly the same effect on the
registry. registry.
Sometimes, it will be clear that a specific port number is no longer Sometimes, it will be clear that a specific port number is no longer
in use and that IANA can revoke it and mark it as Reserved. At other in use and that IANA can revoke it and mark it as Reserved. At other
times, it may be unclear whether a given assigned port number is times, it may be unclear whether a given assigned port number is
still in use somewhere in the Internet. In those cases, IANA must still in use somewhere in the Internet. In those cases, IANA must
carefully consider the consequences of revoking the port number, and carefully consider the consequences of revoking the port number, and
skipping to change at page 21, line 10 skipping to change at page 21, line 40
with the Expert Reviewer's support, SHALL determine promptly after with the Expert Reviewer's support, SHALL determine promptly after
the end of the community call whether revocation should proceed and the end of the community call whether revocation should proceed and
then communicate their decision to the community. This procedure then communicate their decision to the community. This procedure
typically involves similar steps to de-registration except that it is typically involves similar steps to de-registration except that it is
initiated by IANA. initiated by IANA.
Because there is much less danger of exhausting the service name Because there is much less danger of exhausting the service name
space compared to the port number space, revoking service names is space compared to the port number space, revoking service names is
NOT RECOMMENDED. NOT RECOMMENDED.
8.5. Port Number and Service Name Transfers 8.5. Service Name and Port Number Transfers
The value of port numbers and service names is defined by their The value of service names and port numbers is defined by their
careful management as a shared Internet resource, whereas enabling careful management as a shared Internet resource, whereas enabling
transfer allows the potential for associated monetary exchanges. As transfer allows the potential for associated monetary exchanges. As
a result, the IETF does not permit port number or service name a result, the IETF does not permit service name or port number
assignments to be transferred between parties, even when they are assignments to be transferred between parties, even when they are
mutually consenting. mutually consenting.
The appropriate alternate procedure is a coordinated de-registration The appropriate alternate procedure is a coordinated de-registration
and registration: The new party requests the port number or service and registration: The new party requests the service name or port
name via a registration and the previous party releases its number via a registration and the previous party releases its
assignment via the de-registration procedure outlined above. assignment via the de-registration procedure outlined above.
With the help of their IESG-appointed Expert Reviewer, IANA SHALL With the help of their IESG-appointed Expert Reviewer, IANA SHALL
carefully determine if there is a valid technical, operational or carefully determine if there is a valid technical, operational or
managerial reason to grant the requested new assignment. managerial reason to grant the requested new assignment.
8.6. Maintenance Issues 8.6. Maintenance Issues
In addition to the formal procedures described above, updates to the In addition to the formal procedures described above, updates to the
Description and Technical Contact information are coordinated by IANA Description and Contact information are coordinated by IANA in an
in an informal manner, and may be initiated by either the registrant informal manner, and may be initiated by either the registrant or by
or by IANA, e.g., by the latter requesting an update to current IANA, e.g., by the latter requesting an update to current contact
contact information. (Note that Registration Administrative Contact information. (Note that Registration Administrative Contact cannot
cannot be changed; see Section 8.5 above.) be changed; see Section 8.5 above.)
8.7. Disagrements
In the case of disagreements around any request there is the
possibility of appeal following the normal appelas process for IANA
registrations as defined by Section 7 of "Guidelines for Writing an
IANA Considerations Section in RFCs" [RFC5226].
9. Security Considerations 9. Security Considerations
The IANA guidelines described in this document do not change the The IANA guidelines described in this document do not change the
security properties of UDP, TCP, SCTP, or DCCP. security properties of UDP, TCP, SCTP, or DCCP.
Assignment of a port number or service name does not in any way imply Assignment of a service name or port number does not in any way imply
an endorsement of an application or product, and the fact that an endorsement of an application or product, and the fact that
network traffic is flowing to or from a registered port number does network traffic is flowing to or from an assigned port number does
not mean that it is "good" traffic, or even that it is used by the not mean that it is "good" traffic, or even that it is used by the
assigned service. Firewall and system administrators should choose assigned service. Firewall and system administrators should choose
how to configure their systems based on their knowledge of the how to configure their systems based on their knowledge of the
traffic in question, not whether there is a port number or service traffic in question, not based on whether or not there is an assigned
name registered or not. service name or port number.
Services are expected to include support for security, either as Services are expected to include support for security, either as
default or dynamically negotiated in-band. The use of separate port default or dynamically negotiated in-band. The use of separate
number or service name assignments for secure and insecure variants service name or port number assignments for secure and insecure
of the same service is to be avoided in order to discourage the variants of the same service is to be avoided in order to discourage
deployment of insecure services. the deployment of insecure services.
10. IANA Considerations 10. IANA Considerations
This document obsoletes Sections 8 and 9.1 of the March 2000 IANA This document obsoletes Sections 8 and 9.1 of the March 2000 IANA
Allocation Guidelines [RFC2780]. Allocation Guidelines [RFC2780].
Upon approval of this document, IANA is requested to contact the Upon approval of this document, IANA is requested to contact Stuart
maintainer of the [SRVREG] registry, in order to merge the contents Cheshire, maintainer of the independent service name registry
of that private registry into the official IANA registry. It is [SRVREG], in order to merge the contents of that private registry
expected that the contents of [SRVREG] will at that time be replaced into the official IANA registry. It is expected that the independent
with pointers to the IANA registry and to this RFC. registry web page will be updated with pointers to the IANA registry
and to this RFC.
IANA is instructed to create a new service name entry in the port IANA is instructed to create a new service name entry in the service
number registry [PORTREG] for any entry in the "Protocol and Service name and port number registry [PORTREG] for any entry in the
Names" registry [PROTSERVREG] that does not already have one "Protocol and Service Names" registry [PROTSERVREG] that does not
assigned. already have one assigned.
IANA is also instructed to indicate which service name aliases in the IANA is also instructed to indicate in the Assignment Notes for "www"
existing registry are the primary aliases (see Section 5). and "www-http" that they are duplicante terms that refer to the
"http" service, and should not be used for discovery purposes. For
this conceptual service (human-readable web pages served over HTTP)
the correct service name to use for service discovery purposes is
"http" (see Section 5).
10.1. Service Name Consistency 10.1. Service Name Consistency
Section 8.1 defines which character strings are well-formed service Section 8.1 defines which character strings are well-formed service
names, which until now had not been clearly defined. The definition names, which until now had not been clearly defined. The definition
in Section 8.1 was chosen to allow maximum compatibility of service in Section 8.1 was chosen to allow maximum compatibility of service
names with current and future service discovery mechanisms. names with current and future service discovery mechanisms.
As of August 5, 2009 approximately 98% of the so-called "Short Names" As of August 5, 2009 approximately 98% of the so-called "Short Names"
from existing port number registrations [PORTREG] meet the rules for from existing port number registrations [PORTREG] meet the rules for
legal service names stated in Section 8.1, and hence will be used legal service names stated in Section 8.1, and hence for these
unmodified. services their service name will be exactly the same as their "Short
Name".
The remaining approximately 2% of the exiting "Short Names" are not The remaining approximately 2% of the exiting "Short Names" are not
suitable to be used directly as well-formed service names because suitable to be used directly as well-formed service names because
they contain illegal characters such as asterisks, dots, pluses, they contain illegal characters such as asterisks, dots, pluses,
slashes, or underscores. All existing "Short Names" conform to the slashes, or underscores. All existing "Short Names" conform to the
length requirement of 15 characters or fewer. For these unsuitable length requirement of 15 characters or fewer. For these unsuitable
"Short Names", listed in the table below, the service name will be "Short Names", listed in the table below, the service name will be
the Short Name with any illegal characters replaced by hyphens. IANA the Short Name with any illegal characters replaced by hyphens. IANA
SHALL add an entry to the registry giving the new well-formed primary SHALL add an entry to the registry giving the new well-formed primary
service name for the existing service, that otherwise duplicates the service name for the existing service, that otherwise duplicates the
original assignment information. In the description field of this original assignment information. In the description field of this
new entry giving the primary service name, IANA SHALL record that it new entry giving the primary service name, IANA SHALL record that it
assigns a well-formed service name for the previous service and assigns a well-formed service name for the previous service and
reference the original assignment. In the description field of the reference the original assignment. In the Assignment Notes field of
original assignment, IANA SHALL add a note that this entry is an the original assignment, IANA SHALL add a note that this entry is an
alias to the new well-formed service name, and that the old service alias to the new well-formed service name, and that the old service
name is historic, not usable for use with many common service name is historic, not usable for use with many common service
discovery mechanisms. discovery mechanisms.
Names containing illegal characters to be replaced by hyphens: Names containing illegal characters to be replaced by hyphens:
+----------------+-----------------+-----------------+ +----------------+-----------------+-----------------+
| 914c/g | acmaint_dbd | acmaint_transd | | 914c/g | acmaint_dbd | acmaint_transd |
| atex_elmd | avanti_cdp | badm_priv | | atex_elmd | avanti_cdp | badm_priv |
| badm_pub | bdir_priv | bdir_pub | | badm_pub | bdir_priv | bdir_pub |
skipping to change at page 24, line 48 skipping to change at page 25, line 46
| universe_suite | veritas_pbx | vision_elmd | | universe_suite | veritas_pbx | vision_elmd |
| vision_server | wrs_registry | z39.50 | | vision_server | wrs_registry | z39.50 |
+----------------+-----------------+-----------------+ +----------------+-----------------+-----------------+
Following the example set by the "application/whoispp-query" MIME Following the example set by the "application/whoispp-query" MIME
Content-Type [RFC2957], the service name for "whois++" will be Content-Type [RFC2957], the service name for "whois++" will be
"whoispp". "whoispp".
10.2. Port Numbers for SCTP and DCCP Experimentation 10.2. Port Numbers for SCTP and DCCP Experimentation
Two Well Known UDP and TCP ports, 1021 and 1022, have been reserved Two System UDP and TCP ports, 1021 and 1022, have been reserved for
for experimental use [RFC4727]. This document registers the same experimental use [RFC4727]. This document assigns the same port
port numbers for SCTP and DCCP, and also instructs IANA to numbers for SCTP and DCCP, updates the TCP and UDP registrations, and
automatically register these two port numbers for any new transport also instructs IANA to automatically assign these two port numbers
protocol that will in the future share the port number namespace. for any future transport protocol with a similar sixteen-bit port
number namespace.
Note that these port numbers are meant for temporary experimentation Note that these port numbers are meant for temporary experimentation
and development in controlled environments. Before using these port and development in controlled environments. Before using these port
numbers, carefully consider the advice in Section 6.1 in this numbers, carefully consider the advice in Section 6.1 in this
document, as well as in Sections 1 and 1.1 of "Assigning Experimental document, as well as in Sections 1 and 1.1 of "Assigning Experimental
and Testing Numbers Considered Useful" [RFC3692]. Most importantly, and Testing Numbers Considered Useful" [RFC3692]. Most importantly,
application developers must request a permanent port number application developers must request a permanent port number
assignment from IANA as described in Section 8.1 before any kind of assignment from IANA as described in Section 8.1 before any kind of
non-experimental deployment. non-experimental deployment.
+-------------------------------------+----------------------------+ +--------------------+----------------------------+
| Registration Administrative Contact | IETF <iesg@ietf.org> | | Registrant | IETF <iesg@ietf.org> |
| Registration Technical Contact | IESG <iesg@ietf.org> | | Contact | IESG <iesg@ietf.org> |
| Service Name | exp1 | | Service Name | exp1 |
| Port Number | 1021 | | Port Number | 1021 |
| Transport Protocol | SCTP, DCCP | | Transport Protocol | DCCP, SCTP, TCP, UDP |
| Description | RFC3692-style Experiment 1 | | Description | RFC3692-style Experiment 1 |
| Reference | [RFCyyyy] | | Reference | [RFCyyyy],RFC 4727] |
+-------------------------------------+----------------------------+ +--------------------+----------------------------+
+-------------------------------------+----------------------------+ +--------------------+----------------------------+
| Registration Administrative Contact | IETF <iesg@ietf.org> | | Registrant | IETF <iesg@ietf.org> |
| Registration Technical Contact | IESG <iesg@ietf.org> | | Contact | IESG <iesg@ietf.org> |
| Service Name | exp2 | | Service Name | exp2 |
| Port Number | 1022 | | Port Number | 1022 |
| Transport Protocol | SCTP, DCCP | | Transport Protocol | DCCP, SCTP, TCP, UDP |
| Description | RFC3692-style Experiment 2 | | Description | RFC3692-style Experiment 2 |
| Reference | [RFCyyyy] | | Reference | [RFCyyyy], [RFC4727] |
+-------------------------------------+----------------------------+ +--------------------+----------------------------+
[RFC Editor Note: Please change "yyyy" to the RFC number allocated to [RFC Editor Note: Please change "yyyy" to the RFC number allocated to
this document before publication.] this document before publication.]
10.3. Updates to DCCP Registries 10.3. Updates to DCCP Registries
This document updates the IANA allocation procedures for the DCCP This document updates the IANA allocation procedures for the DCCP
Port Number and DCCP Service Codes Registries [RFC4340]. Port Number and DCCP Service Codes Registries [RFC4340].
10.3.1. DCCP Service Code Registry 10.3.1. DCCP Service Code Registry
skipping to change at page 26, line 14 skipping to change at page 27, line 14
o IANA should feel free to contact the DCCP Expert Reviewer with o IANA should feel free to contact the DCCP Expert Reviewer with
questions on any registry, regardless of the registry policy, for questions on any registry, regardless of the registry policy, for
clarification or if there is a problem with a request [RFC4340]. clarification or if there is a problem with a request [RFC4340].
10.3.2. DCCP Port Numbers Registry 10.3.2. DCCP Port Numbers Registry
The DCCP ports registry is defined by Section 19.9 of the DCCP The DCCP ports registry is defined by Section 19.9 of the DCCP
specification [RFC4340]. Allocations in this registry require prior specification [RFC4340]. Allocations in this registry require prior
allocation of a Service Code. Not all Service Codes require IANA- allocation of a Service Code. Not all Service Codes require IANA-
registered ports. This document updates that section by extending assigned ports. This document updates that section by extending the
the guidelines given there in the following way: guidelines given there in the following way:
o IANA should normally assign a value in the range 1024-49151 to a o IANA should normally assign a value in the range 1024-49151 to a
DCCP server port. IANA allocation requests to allocate port DCCP server port. IANA allocation requests to allocate port
numbers in the Well Known Ports range (0 through 1023), require an numbers in the System Ports range (0 through 1023), require an
"IETF Review" [RFC5226] prior to allocation by IANA [RFC4340]. "IETF Review" [RFC5226] prior to allocation by IANA [RFC4340].
o IANA MUST NOT allocate more than one DCCP server port to a single o IANA MUST NOT allocate more than one DCCP server port to a single
service code value. service code value.
o The allocation of multiple service codes to the same DCCP port is o The allocation of multiple service codes to the same DCCP port is
allowed, but subject to expert review. allowed, but subject to expert review.
o The set of Service Code values associated with a DCCP server port o The set of Service Code values associated with a DCCP server port
should be recorded in the ports registry. should be recorded in the service name and port number registry.
o A request for additional Service Codes to be associated with an o A request for additional Service Codes to be associated with an
already allocated Port Number requires Expert Review. These already allocated Port Number requires Expert Review. These
requests will normally be accepted when they originate from the requests will normally be accepted when they originate from the
contact associated with the port registration. In other cases, contact associated with the port registration. In other cases,
these applications will be expected to use an unallocated port, these applications will be expected to use an unallocated port,
when this is available. when this is available.
The DCCP specification [RFC4340] notes that a short port name MUST be The DCCP specification [RFC4340] notes that a short port name MUST be
associated with each DCCP server port that has been registered. This associated with each DCCP server port that has been assigned. This
document requires that this name MUST be unique. document clarifies that this short port name is the Service Name as
defined here, and this name MUST be unique.
11. Contributors 11. Contributors
Stuart Cheshire (cheshire@apple.com), Alfred Hoenes (ah@tr-sys.de) Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have
and Allison Mankin (mankin@psg.com) have contributed text and ideas contributed text and ideas to this document.
to this document.
12. Acknowledgments 12. Acknowledgments
The text in Section 10.3 is based on a suggestion originally proposed The text in Section 10.3 is based on a suggestion originally proposed
as a part of [RFC5595] by Gorry Fairhurst. as a part of the DCCP Service Codes document[RFC5595] by Gorry
Fairhurst.
Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a
research project supported by the European Commission under its research project supported by the European Commission under its
Seventh Framework Program. Seventh Framework Program.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
skipping to change at page 28, line 17 skipping to change at page 29, line 19
[I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-06 (work in Discovery", draft-cheshire-dnsext-dns-sd-06 (work in
progress), March 2010. progress), March 2010.
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008. draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.gudmundsson-dnsext-srv-clarify]
Gudmundsson, O. and A. Hoenes, "Clarification of DNS SRV
Owner Names", draft-gudmundsson-dnsext-srv-clarify-00
(work in progress), December 2009.
[IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0",
November 2001. November 2001.
[PORTREG] Internet Assigned Numbers Authority (IANA), "Port Numbers [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name
Registry", http://www.iana.org/assignments/port-numbers. and Transport Protocol Port Number Registry",
http://www.iana.org/assignments/port-numbers.
[PROTSERVREG] [PROTSERVREG]
Internet Assigned Numbers Authority (IANA), "Protocol and Internet Assigned Numbers Authority (IANA), "Protocol and
Service Names Registry", Service Names Registry",
http://www.iana.org/assignments/service-names. http://www.iana.org/assignments/service-names.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)",
skipping to change at page 30, line 39 skipping to change at page 31, line 26
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
USA USA
Phone: +1 310 448 9151 Phone: +1 310 448 9151
Email: touch@isi.edu Email: touch@isi.edu
URI: http://www.isi.edu/touch URI: http://www.isi.edu/touch
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Torshamsgatan 23 Farogatan 6
Stockholm 164 80 Stockholm 164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Phone: +1 408 974 3207 Phone: +1 408 974 3207
Email: cheshire@apple.com Email: cheshire@apple.com
 End of changes. 128 change blocks. 
505 lines changed or deleted 537 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail-94-386818094 Content-Disposition: attachment; filename=draft-ietf-tsvwg-iana-ports.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-tsvwg-iana-ports.txt" Content-Transfer-Encoding: quoted-printable Transport Area Working Group M. Cotton Internet-Draft ICANN Updates: 2780, 2782, 3828, 4340, L. Eggert 4960 (if approved) Nokia Intended status: BCP J. Touch Expires: April 2, 2011 USC/ISI M. Westerlund Ericsson S. Cheshire Apple September 29, 2010 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry draft-ietf-tsvwg-iana-ports-07 Abstract This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling registration and other requests related to the Service Name and Transport Protocol Port Number Registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782] to clarify what a service name is and how it is registered. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 2, 2011. Cotton, et al. Expires April 2, 2011 [Page 1] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Cotton, et al. Expires April 2, 2011 [Page 2] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conventions Used in this Document . . . . . . . . . . . . . . 7 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Service names and Port Numbers for Experimentation . . . . 11 7. Principles for Service Name and Transport Protocol Port Number Registry Management . . . . . . . . . . . . . . . . . . 12 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry . . . . . . . . . . . 15 8.1. Service Name and Port Number Registration . . . . . . . . 15 8.2. Service Name and Port Number De-Registration . . . . . . . 20 8.3. Service Name and Port Number Re-Use . . . . . . . . . . . 20 8.4. Service Name and Port Number Revocation . . . . . . . . . 21 8.5. Service Name and Port Number Transfers . . . . . . . . . . 21 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 22 8.7. Disagrements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 23 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 25 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Cotton, et al. Expires April 2, 2011 [Page 3] =0C Internet-Draft Service Name and Port Number Procedures September 2010 1. Introduction For many years, the allocation of new service names and port number values for use with the Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have had less than clear guidelines. New transport protocols have been added - the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have been developed, each with separate registries and separate guidelines. The community also recognized the need for additional procedures beyond just assignment; notably modification, revocation, and release. A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. This document brings the IANA procedures for TCP and UDP in line with those for SCTP and DCCP, resulting in a single process that requesters and IANA follow for all requests for all transport protocols, including future protocols not yet defined. In addition to detailing the IANA procedures for the initial assignment of service names and port numbers, this document also specifies post-assignment procedures that until now have been handled in an ad hoc manner. These include procedures to de-register a port number that is no longer in use, to re-use a port number allocated for one application that is no longer in use for another application, and the procedure by which IANA can unilaterally revoke a prior port number assignment. Section 8 discusses the specifics of these procedures and processes that requesters and IANA follow for all requests for all current and future transport protocols. IANA is the authority for assigning service names and port numbers. The registries that are created to store these registrations are maintained by IANA. For protocols developed by IETF working groups, IANA now also offers a method for the "early assignment" [RFC4020] of service names and port numbers, as described in Section 8.1. This document updates IANA's procedures for UDP and TCP port numbers by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780]. (Note that other sections of the IANA allocation guidelines, relating to the protocol field values in IPv4 header, were also updated in February 2008 [RFC5237].) This document also updates the IANA allocation procedures for DCCP [RFC4340] and SCTP [RFC4960]. The Lightweight User Datagram Protocol (UDP-Lite) [RFC5237] shares the port space with UDP. The UDP-Lite specification says: "UDP-Lite uses the same set of port number values assigned by the IANA for use Cotton, et al. Expires April 2, 2011 [Page 4] =0C Internet-Draft Service Name and Port Number Procedures September 2010 by UDP". Thus the update of UDP procedures result in an update also of the UDP-Lite procedures. This document also clarifies what a service name is and how it is registered. This will impact the DNS SRV specification [RFC2782], because that specification merely makes a brief mention that the symbolic names of services are defined in "Assigned Numbers" [RFC1700], without stating to which section it refers within that 230-page document. The DNS SRV specification may have been referring to the list of Port Assignments (known as /etc/services on Unix), or to the "Protocol And Service Names" section, or to both, or to some other section. Furthermore, "Assigned Numbers" is now obsolete [RFC3232] and has been replaced by on-line registries [PORTREG][PROTSERVREG]. The development of new transport protocols is a major effort that the IETF does not undertake very often. If a new transport protocol is standardized in the future, for consistency it is expected to follow as much as possible the guidelines and practices around using service names and port numbers. 2. Motivation Information about the registration procedures for the port registry has existed in three locations: the forms for requesting port number registrations on the IANA web site [SYSFORM] [USRFORM], an introductory text section in the file listing the port number registrations themselves [PORTREG], and two brief sections of the IANA Allocation Guidelines [RFC2780]. Similarly, the procedures surrounding service names have been historically unclear. Service names were originally created as mnemonic identifiers for port numbers without a well-defined syntax, beyond the 14-character limit mentioned on the IANA website [SYSFORM] [USRFORM]. Even that length limit has not been consistently applied, and some assigned service names are 15 characters long. When service identification via DNS SRV Resource Records (RRs) was introduced, the requirement by IANA to only assign service names and port numbers in combination, led to the creation of an ad hoc service name registry outside of the control of IANA [SRVREG]. This document aggregates all this scattered information into a single reference that aligns and clearly defines the management procedures for both service names and port numbers. It gives more detailed guidance to prospective requesters of service names and ports than the existing documentation, and it streamlines the IANA procedures for the management of the registry, so that management requests can Cotton, et al. Expires April 2, 2011 [Page 5] =0C Internet-Draft Service Name and Port Number Procedures September 2010 complete in a timely manner. This document defines rules for registration of service names without associated port numbers, for such usages as DNS SRV records [RFC2782], which was not possible under the previous IANA procedures. The document also merges service name registrations from the non-IANA ad hoc registry [SRVREG] and from the IANA "Protocol and Service Names" registry [PROTSERVREG] into the IANA "Service Name and Transport Protocol Port Number" registry [PORTREG], which from here on is the single authoritative registry for service names and port numbers. An additional purpose of this document is to describe the principles that guide the IETF and IANA in their role as the long-term joint stewards of the service name and port number registry. TCP and UDP have had remarkable success over the last decades. Thousands of applications and application-level protocols have service names and ports assigned for their use, and there is every reason to believe that this trend will continue into the future. It is hence extremely important that management of the registry follow principles that ensure its long-term usefulness as a shared resource. Section 7 discusses these principles in detail. 3. Background The Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success over the decades as the two most widely used transport protocols on the Internet. They have relied on the concept of "ports" as logical entities for Internet communication. Ports serve two purposes: first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes bind. Newer transport protocols, such as the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] have also adopted the concept of ports for their communication sessions and use sixteen-bit port numbers in the same way as TCP and UDP (and UDP-Lite [RFC3828], a variant of UDP). Port numbers are the original and most widely used means for application and service identification on the Internet. Ports are sixteen-bit numbers, and the combination of source and destination port numbers together with the IP addresses of the communicating end systems uniquely identifies a session of a given transport protocol. Port numbers are also known by their associated service names such as "telnet" for port number 23 and "http" (as well as "www" and "www- Cotton, et al. Expires April 2, 2011 [Page 6] =0C Internet-Draft Service Name and Port Number Procedures September 2010 http") for port number 80. Hosts running services, hosts accessing services on other hosts, and intermediate devices (such as firewalls and NATs) that restrict services need to agree on which service corresponds to a particular destination port. Although this is ultimately a local decision with meaning only between the endpoints of a connection, it is common for many services to have a default port upon which those servers usually listen, when possible, and these ports are recorded by the Internet Assigned Numbers Authority (IANA) through the service name and port number registry [PORTREG]. Over time, the assumption that a particular port number necessarily implies a particular service may become less true. For example, multiple instances of the same service on the same host cannot generally listen on the same port, and multiple hosts behind the same NAT gateway cannot all have a mapping for the same port on the external side of the NAT gateway, whether using static port mappings configured by hand by the user, or dynamic port mappings configured automatically using a port mapping protocol like NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device (IGD) [IGD]. Applications may use numeric port numbers directly, look up port numbers based on service names via system calls such as getservbyname() on UNIX, look up port numbers by performing queries for DNS SRV records [RFC2782][I-D.cheshire-dnsext-dns-sd], or determine port numbers in a variety of other ways like the TCP Port Service Multiplexer (TCPMUX) [RFC1078]. Designers of applications and application-level protocols may apply to IANA for an assigned service name and port number for a specific application, and may - after successful registration - assume that no other application will use that service name or port number for its communication sessions. Alternatively, application designers may also ask for only an assigned service name, if their application does not require a fixed port number. The latter alternative is encouraged when possible, in order to conserve the more limited port number space. This is applicable, for example, to applications that use DNS SRV records to look up port numbers at runtime. 4. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Cotton, et al. Expires April 2, 2011 [Page 7] =0C Internet-Draft Service Name and Port Number Procedures September 2010 5. Service Names Service names are the unique key in the Service Name and Transport Protocol Port Number Registry. This unique symbolic name for a service may also be used for other purposes, such as in DNS SRV records [RFC2782]. Within the registry, this unique key ensures that different services can be unambiguously distinguished, thus preventing name collisions and avoiding confusion about who is the Registrant for a particular entry. There may be more than one service name associated with a particular transport protocol and port. There are three ways that such service name overloading can occur: o Overloading occurs when one service is an extension of another service, and an in-band mechanism exists for determining if the extension is present or not. One example is port 3478, which has the service name aliases "stun" and "turn". TURN [RFC5766] is an extension to the STUN [RFC5389] service. TURN-enabled clients wishing to locate TURN servers could attempt to discover "stun" services and then check in-band if the server supports TURN, but this would be inefficient. Enabling them to directly query for "turn" servers by name is a better approach. (Note that TURN servers in this case should also be locatable via a "stun" discovery, because every TURN server is also a STUN server.) o By historical accident the service name "http" corresponds to the same port number as "www" and "www-http". When used in SRV records [RFC2782], and similar service discovery mechanisms only the service name "http" should be used, not these additional names. If a server were to advertise "www" then it would not be discovered by clients browsing for "http". Advertising or browsing for the aliases as well as the primary service name would be inefficient, and achieves nothing that it not already achieved by using the service name "http" exclusively. o As indicated in this document, in Section 10.1, to enable legacy names to be replaced with names consistent with the syntax this document prescribes. In this case, only the new name should be used in SRV records, both to avoid the same issues as with historical cases of multiple names, as well as because the legacy names are incompatible with SRV record use. For future assignments, applications will not be permitted that merely request a new name exactly duplicating an existing service. Having multiple names for the same service serves no purpose. Implementers are requested to inform IANA if they discover other cases where a single service has multiple names, so that one name may Cotton, et al. Expires April 2, 2011 [Page 8] =0C Internet-Draft Service Name and Port Number Procedures September 2010 be recorded as the primary name for service discovery purposes. Service names are assigned on a "first come, first served" basis, as described in Section 8.1. Names should be brief and informative, avoiding words or abbreviations that are redundant in the context of the registry (e.g., "port", "service", "protocol", etc.) Names referring to discovery services, e.g., using multicast or broadcast to identify endpoints capable of a given service, SHOULD use an easily identifiable suffix (e.g., "-disc"). 5.1. Service Name Syntax Valid service names are hereby normatively defined as follows: o MUST be at least 1 character and no more than 15 characters long o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45) o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') o MUST NOT begin or end with a hyphen The reason for requiring at least one letter is to avoid service names like "23" (could be confused with a numeric port number) or "6000-6063" (could be confused with a numeric port number range). Although service names may contain both upper-case and lower-case letters, case is ignored for comparison purposes, so both "http" and "HTTP" denote the same service. Service names are purely opaque identifiers, and no semantics are implied by any superficial structure that a given service name may appear to have. For example, a company called "Example" may choose to register service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" products, but the "Example" company can't claim to "own" all service names beginning with "Example-", they can't prevent someone else registering "Example-Baz" for a different service, and they can't prevent other developers from using the "Example-Foo" and "Example-Bar" service types in order to interoperate with the "Foo" and "Bar" products. Technically speaking, in service discovery protocols, service names are merely a series of byte values on the wire; for the mnemonic convenience of human developers it can be convenient to interpret those byte values as human-readable ascii characters, but software should treat them as purely opaque identifiers and not attempt to parse them for any additional embedded meaning. Cotton, et al. Expires April 2, 2011 [Page 9] =0C Internet-Draft Service Name and Port Number Procedures September 2010 In approximately 98% of cases, the new "service name" is exactly the same as the old historic "short name" from the IANA web forms [SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service name" is derived from the old historic "short name" as described below in Section 10.1. The rules for valid service names, excepting the limit of 15 characters maximu, are also expressed below (as a non-normative convenience) using ABNF [RFC5234]. SRVNAME =3D (ALPHA / (1*DIGIT [HYPHEN] ALPHA)) *([HYPHEN] ALNUM) ALNUM =3D ALPHA / DIGIT ; A-Z, a-z, 0-9 HYPHEN =3D %x2d ; "-" ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] DIGIT =3D %x30-39 ; 0-9 [RFC5234] 5.2. Service Name Usage in DNS SRV Records The DNS SRV specification [RFC2782] states that the Service Label part of the owner name of a DNS SRV record includes a "Service" element, described as "the symbolic name of the desired service", but as discussed above, it is not clear precisely what this means. This document clarifies that the Service Label MUST be a service name as defined herein. The service name SHOULD be registered with IANA and recorded in the Service Name and Transport Protocol Port Number Registry [PORTREG]. The details of using Service Names in SRV Service Labels are specified in the DNS SRV specification [RFC2782]. This document does not change that specification. 6. Port Number Ranges TCP, UDP, UDP-Lite, SCTP and DCCP use sixteen-bit namespaces for their port number registries. The port registries for all these transport protocols are subdivided into three ranges of numbers, and Section 8.1.1 describes the IANA procedures for each range in detail: o the System Ports, also known as the Well Known Ports, from 0-1023 (assigned by IANA) o the User Ports, also known as the Registered Ports, from 1024- 49151 (assigned by IANA) Cotton, et al. Expires April 2, 2011 [Page 10] =0C Internet-Draft Service Name and Port Number Procedures September 2010 o the Dynamic Ports, also known as the Private Ports, from 49152- 65535 (never assigned) Of the assignable port ranges (System Ports and User Ports, i.e., port numbers 0-49151), individual port numbers are in one of three states at any given time: o Assigned: Assigned port numbers are currently allocated to the service indicated in the registry. o Unassigned: Unassigned port numbers are currently available for assignment upon request, as per the procedures outlined in this document. o Reserved: Reserved port numbers are not available for regular assignment; they are "assigned to IANA" for special purposes. Reserved port numbers include values at the edges of each range, e.g., 0, 1023, 1024, etc., which may be used to extend these ranges or the overall port number space in the future. In order to keep the size of the registry manageable, IANA typically only records the Assigned and Reserved service names and port numbers in the registry. Unassigned values are typically not explicitly listed. (There are an near-infinite number of Unassigned service names and enumerating them all would not be practical.) As a data point, when this document was written, approximately 76% of the TCP and UDP System Ports were assigned, and approximately 9% of the User Ports were assigned. (As noted, Dynamic Ports are never assigned.) 6.1. Service names and Port Numbers for Experimentation Of the System Ports, two TCP and UDP port numbers (1021 and 1022), together with their respective service names ("exp1" and "exp2"), have been assigned for experimentation with new applications and application-layer protocols that require a port number in the assigned ports ranges [RFC4727]. Please refer to Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] for how these experimental port numbers are to be used. This document registers the same two service names and port numbers for experimentation with new application-layer protocols over SCTP and DCCP in Section 10.2. Unfortunately, it can be difficult to limit access to these ports. Cotton, et al. Expires April 2, 2011 [Page 11] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Users SHOULD take measures to ensure that experimental ports are connecting to the intended process. For example, users of these experimental ports might include a 64-bit nonce, once on each segment of a message-oriented channel (e.g., UDP), or once at the beginning of a byte-stream (e.g., TCP), which is used to confirm that the port is being used as intended. Such confirmation of intended use is especially important when these ports are associated with privileged (e.g., system or administrator) processes. 7. Principles for Service Name and Transport Protocol Port Number Registry Management Management procedures for the service name and transport protocol port number registry include allocation of service names and port numbers upon request, as well as management of information about existing allocations. The latter includes maintaining contact and description information about assignments, revoking abandoned assignments, and redefining assignments when needed. Of these procedures, careful port number allocation is most critical, in order to continue to conserve the remaining port numbers. As noted earlier, only about 9% of the User Port space is currently assigned. The current rate of assignment is approximately 400 ports per year, and has remained steady for the past 8 years. At that rate, if similar conservation continues, this resource will sustain another 85 years of assignment - without the need to resort to reassignment of released values or revocation. The namespace available for service names is much larger, which allows for simpler management procedures. 7.1. Past Principles Before the publication of this document, the principles of service name and port number management followed a few mostly-undocumented guidelines. They are recorded here for historical purposes, and this document updates them in Section 7.2. These principles were: o TCP and UDP ports were simultaneously allocated when either was requested o Port numbers were the primary allocation; service names were informative only, and did not have a well-defined syntax o Port numbers were conserved informally, and sometimes inconsistently (e.g., some services were allocated ranges of many port numbers even where not strictly necessary) Cotton, et al. Expires April 2, 2011 [Page 12] =0C Internet-Draft Service Name and Port Number Procedures September 2010 o SCTP and DCCP service name and port number registries were managed separately from the TCP/UDP registries o Service names could not be assigned in the old ports registry without assigning an associated port number at the same time This document clarifies and aligns these guidelines in order to more conservatively manage the limited remaining port number space and to enable and promote the use of service names for service identification without associated port numbers, where possible. 7.2. Updated Principles This section summarizes the basic principles by which IANA handles the Service Name and Transport Protocol Port Number Registry, and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA are not required to be bound by these principles when handling requests; other factors may come into play, and exceptions may occur where deemed in the best interest of the Internet. IANA will begin assigning service names that do not request an associated port number allocation under a simple "First Come, First Served" policy [RFC5226]. IANA MAY, at its discretion, refer service name requests to "Expert Review" in cases of mass registrations or other situations where IANA believes expert review is advisable. The basic principle of service name and port number registry management is to conserve use of the port space where possible. Extensions to support larger port number spaces would require changing many core protocols of the current Internet in a way that would not be backward compatible and interfere with both current and legacy applications. To help ensure this conservation the policy for any registration request for port number allocations uses the "Expert Review" policy [RFC5226]. Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. In particular: o IANA will allocate only one assigned port number per service or application o IANA will allocate only one assigned port number for all versions of a service (e.g., running the service with or without a security Cotton, et al. Expires April 2, 2011 [Page 13] =0C Internet-Draft Service Name and Port Number Procedures September 2010 mechanism, or for updated variants of a service) o IANA will allocate only one assigned port number for all different types of device using or participating in the same service o IANA will allocate port numbers only for the transport protocol(s) explicitly named in a registration request o IANA may recover unused port numbers, via the new procedures of de-registration, revocation, and transfer Where possible, a given service is expected to demultiplex messages if necessary. For example, applications and protocols are expected to include in-band version information, so that future versions of the application or protocol can share the same allocated port. Applications and protocols are also expected to be able to efficiently use a single allocated port for multiple sessions, either by demultiplexing multiple streams within one port, or using the allocated port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]). Ports are used in various ways, notably: o as endpoint process identifiers o as application protocol identifiers o for firewall filtering purposes Both the process identifier and the protocol identifier uses suggest that anything a single process can demultiplex, or that can be encoded into a single protocol, should be. The firewall filtering use suggests that some uses that could be multiplexed or encoded could instead be separated to allow for easier firewall management. Note that this latter use is much less sound, because port numbers have meaning only for the two endpoints involved in a connection, and drawing conclusions about the service that generated a given flow based on observed port numbers is not always reliable. Further, previous separation of protocol variants based on security capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is not recommended for new protocols, because all new protocols should be security-capable and capable of negotiating the use of security in-band. IANA will begin assigning port numbers for only those transport protocols explicitly included in a registration request. This ends the long-standing practice of automatically assigning a port number to an application for both TCP and a UDP, even if the request is for Cotton, et al. Expires April 2, 2011 [Page 14] =0C Internet-Draft Service Name and Port Number Procedures September 2010 only one of these transport protocols. The new allocation procedure conserves resources by allocating a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually uses. The port number will be marked as Reserved - instead of Assigned - in the port number registries of the other transport protocols. When applications start supporting the use of some of those additional transport protocols, the Registrant for the registration MUST request IANA to convert the reservation into a proper assignment. An application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport protocol without asking IANA to convert the reservation into an assignment. When the available pool of unassigned numbers has run out in a ports range, it will be necessary for IANA to consider the Reserved ports for assignment. This is part of the motivation for not automatically assigning ports for transport protocols other than the requested one(s). This will allow more ports to be available for assignment when that time comes. To help conserve ports, application developers should register only the transport protocols that their application currently uses. Conservation of port numbers is improved by procedures that allow previously allocated port numbers to become Unassigned, either through de-registration or through revocation, and by a procedure that lets application designers transfer an allocated but unused port number to a new application. Section 8 describes these procedures, which until now were undocumented. Port number conservation is also improved by recommending that applications that do not require an allocated port should register only a service name without an associated port number. 8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry This section describes the process for handling requests associated with IANA's management of the Service Name and Transport Protocol Port Number Registry. Such requests include initial registration, de-registration, re-use, changes to the service name, and updates to the contact information or description associated with an assignment. Revocation is as additional process, initiated by IANA. 8.1. Service Name and Port Number Registration Registration refers to the allocation of service names or port numbers to applicants. All such registrations are made from service names or port numbers that are Unassigned or Reserved at the time of Cotton, et al. Expires April 2, 2011 [Page 15] =0C Internet-Draft Service Name and Port Number Procedures September 2010 the allocation. Unassigned names and numbers are allocated according to the rules described in Section 8.1.1 below. Reserved numbers and names are assigned only by Standards Action or IESG Approval, and MUST accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. When a registration for one or more transport protocols is approved, the port number for any non-requested transport protocol(s) will be marked as Reserved. IANA SHOULD NOT assign that port number to any other application or service until no other port numbers remain Unassigned in the requested range. The current Registrant for a port number MAY register these Reserved port numbers for other transport protocols when needed. A service name or port number registration request contains the following information. The service name is the unique identifier of a given service: Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) Registrant (REQUIRED) Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL) o Service Name: A desired unique service name for the service associated with the registration request MUST be provided, for use in various service selection and discovery mechanisms (including, but not limited to, DNS SRV records [RFC2782]). The name MUST be compliant with the syntax defined in Section 5.1. In order to be Cotton, et al. Expires April 2, 2011 [Page 16] =0C Internet-Draft Service Name and Port Number Procedures September 2010 unique, they MUST NOT be identical to any currently assigned service name in the IANA registry [PORTREG]. Service names are case-insensitive; they may be provided and entered into the registry with mixed case for clarity, but for the comparison purposes the case is ignored. o Transport Protocol(s): The transport protocol(s) for which a allocation is requested MUST be provided. This field is currently limited to one or more of TCP, UDP, SCTP, and DCCP. Requests without any port allocation and only a service name are still required to indicate which protocol the service uses. o Registrant: Name and email address of the Registrant. This is REQUIRED. The Registrant is the Organization or Company responsible for the initial registration. For registrations done through IETF-published RFCs, the Registrant will be the IESG. o Contact: Name and email address of the Contact person for the registration. This is REQUIRED. The Contact person is the responsible person for the Internet community to send questions to. This person would also be authorized to submit changes on behalf of the Registrant; in cases of conflict between the Registrant and the Contact, the Registrant decisions take precedence. Additional address information MAY be provided. For registrations done through IETF-published RFCs, the Contact will be the IESG. o Description: A short description of the service associated with the registration request is REQUIRED. It should avoid all but the most well-known acronyms. o Reference: A description of (or a reference to a document describing) the protocol or application using this port. The description must state whether the protocol uses broadcast, multicast, or anycast communication. For registrations requesting only a Service Name, or a Service Name and User Port, a statement that the protocol is proprietary and not publicly documented is also acceptable provided that the required information regarding use of broadcast, multicast, or anycast is given. For registration requests for a User Port, the registration request MUST explain why a port number in the Dynamic Ports range is unsuitable for the given application. For registration requests for a System Port, the registration request MUST explain why a port number in the User Ports or Cotton, et al. Expires April 2, 2011 [Page 17] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Dynamic Ports ranges is unsuitable, and a reference to a stable protocol specification document MUST be provided. For requests from IETF Working Groups, IANA MAY accept "early registration" [RFC4020] requests referencing a sufficiently stable Internet Draft instead of a published Standards-Track RFC. o Port Number: If assignment of a port number is desired, either the currently Unassigned or Reserved port number the requester suggests for allocation, or indication of which port range, user or system, that the requester requires, MUST be provided. If only a service name is to be assigned, this field is left empty. If a specific port number is requested, IANA is encouraged to allocate the requested number. If a range is specified, IANA will choose a suitable number from the User or System Ports ranges. Note that the applicant MUST NOT use the requested port prior to the completion of the registration. o Service Code: If the registration request includes DCCP as a transport protocol then the request MUST include a desired unique DCCP service code [RFC5595], and MUST NOT include a requested DCCP service code otherwise. Section 19.8 of the DCCP specification [RFC4340] defines requirements and rules for allocation, updated by this document. o Known Unauthorized Uses: A list of uses by applications or organizations who are not the assignee. This list may be augmented by IANA after assignment when unauthorized uses are reported. o Assignment Notes: Indications of owner/name change, or any other assignment process issue. This list may be updated by IANA after assignment to help track changes to an assignment, e.g., de- registration, owner/name changes, etc. If the registration request is for the addition of a new transport protocol to an already assigned service name, IANA needs to confirm with the Registrant for the existing assignment whether this addition is appropriate. If the registration request is for a service name overloading a port number (see Section 5), IANA needs to confirm with the Registrant for the existing service name whether the registration of the overloading is appropriate. When IANA receives a registration request - containing the above information - that is requesting a port number, IANA SHALL initiate an "Expert Review" [RFC5226] in order to determine whether an assignment should be made. For requests that do not include a port Cotton, et al. Expires April 2, 2011 [Page 18] =0C Internet-Draft Service Name and Port Number Procedures September 2010 number, IANA SHOULD assign the service name under a simple "First Come First Served" policy [RFC5226]. 8.1.1. Variances for Specific Port Number Ranges Section 6 describes the different port number ranges. It is important to note that IANA applies slightly different procedures when managing the different port ranges of the service name and port number registry: o Ports in the Dynamic Ports range (49152-65535) have been specifically set aside for local and dynamic use and cannot be assigned through IANA. Application software may simply use them for communication without any sort of registration. On the other hand, application software MUST NOT assume that a specific port number in the Dynamic Ports range will always be available for communication at all times, and a port number in that range hence MUST NOT be used as a service identifier. o Ports in the User Ports range (1024-49151) are available for registration through IANA, and MAY be used as service identifiers upon successful registration. Because registering a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. This documentation will be input to the "Expert Review" allocation procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the registration. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226], which is how most assignments for IETF protocols are handled. o Ports in the System Ports range (0-1023) are also available for registration through IANA. Because the System Ports range is both the smallest and the most densely allocated, the requirements for new allocations are more strict than those for the User Ports range, and will only be granted under the "IETF Review" or "IESG Approval" allocation procedures [RFC5226]. A request for a System Port number MUST document *both* why using a port number from the User Ports is unsuitable *and* why using a port number from the Dynamic Ports ranges is unsuitable for that application. Cotton, et al. Expires April 2, 2011 [Page 19] =0C Internet-Draft Service Name and Port Number Procedures September 2010 8.2. Service Name and Port Number De-Registration The Registrant of a granted port number assignment can return the port number to IANA at any time if they no longer have a need for it. The port number will be de-registered and will be marked as Reserved. IANA should not re-assign port numbers that have been de-registered until all unassigned port numbers in the specific range have been assigned. Before proceeding with a port number de-registration, IANA needs to reasonably establish that the value is actually no longer in use. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that a given service name remain assigned even after all associated port number assignments have become de-registered. Under this policy, it will appear in the registry as if it had been created through a service name registration request that did not include any port numbers. On rare occasions, it may still be useful to de-register a service name. In such cases, IANA will mark the service name as Reserved. IANA will involve their IESG-appointed expert in such cases. IANA will include a comment in the registry when de-registration happens to indicate its historic usage. 8.3. Service Name and Port Number Re-Use If the Registrant of a granted port number assignment no longer have a need for the assigned number, but would like to re-use it for a different application, they can submit a request to IANA to do so. Logically, port number re-use is to be thought of as a de- registration (Section 8.2) followed by an immediate re-registration (Section 8.1) of the same port number for a new application. Consequently, the information that needs to be provided about the proposed new use of the port number is identical to what would need to be provided for a new port number allocation for the specific ports range. Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that the original service name associated with the prior use of the port number remains assigned, and a new service be created and associated with the port number. This is again consistent with viewing a re-use request as a de-registration followed by an immediate re- registration. Re-using an assigned service name for a different Cotton, et al. Expires April 2, 2011 [Page 20] =0C Internet-Draft Service Name and Port Number Procedures September 2010 application is NOT RECOMMENDED. IANA needs to carefully review such requests before approving them. In some instances, the Expert Reviewer will determine that the application that the port number was assigned to has found usage beyond the original requester, or that there is a concern that it may have such users. This determination MUST be made quickly. A community call concerning revocation of a port number (see below) MAY be considered, if a broader use of the port number is suspected. 8.4. Service Name and Port Number Revocation A port number revocation can be thought of as an IANA-initiated de- registration (Section 8.2), and has exactly the same effect on the registry. Sometimes, it will be clear that a specific port number is no longer in use and that IANA can revoke it and mark it as Reserved. At other times, it may be unclear whether a given assigned port number is still in use somewhere in the Internet. In those cases, IANA must carefully consider the consequences of revoking the port number, and SHOULD only do so if there is an overwhelming need. With the help of their IESG-appointed Expert Reviewer, IANA SHALL formulate a request to the IESG to issue a four-week community call concerning the pending port number revocation. The IESG and IANA, with the Expert Reviewer's support, SHALL determine promptly after the end of the community call whether revocation should proceed and then communicate their decision to the community. This procedure typically involves similar steps to de-registration except that it is initiated by IANA. Because there is much less danger of exhausting the service name space compared to the port number space, revoking service names is NOT RECOMMENDED. 8.5. Service Name and Port Number Transfers The value of service names and port numbers is defined by their careful management as a shared Internet resource, whereas enabling transfer allows the potential for associated monetary exchanges. As a result, the IETF does not permit service name or port number assignments to be transferred between parties, even when they are mutually consenting. The appropriate alternate procedure is a coordinated de-registration and registration: The new party requests the service name or port number via a registration and the previous party releases its Cotton, et al. Expires April 2, 2011 [Page 21] =0C Internet-Draft Service Name and Port Number Procedures September 2010 assignment via the de-registration procedure outlined above. With the help of their IESG-appointed Expert Reviewer, IANA SHALL carefully determine if there is a valid technical, operational or managerial reason to grant the requested new assignment. 8.6. Maintenance Issues In addition to the formal procedures described above, updates to the Description and Contact information are coordinated by IANA in an informal manner, and may be initiated by either the registrant or by IANA, e.g., by the latter requesting an update to current contact information. (Note that Registration Administrative Contact cannot be changed; see Section 8.5 above.) 8.7. Disagrements In the case of disagreements around any request there is the possibility of appeal following the normal appelas process for IANA registrations as defined by Section 7 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. 9. Security Considerations The IANA guidelines described in this document do not change the security properties of UDP, TCP, SCTP, or DCCP. Assignment of a service name or port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from an assigned port number does not mean that it is "good" traffic, or even that it is used by the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, not based on whether or not there is an assigned service name or port number. Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. 10. IANA Considerations This document obsoletes Sections 8 and 9.1 of the March 2000 IANA Allocation Guidelines [RFC2780]. Cotton, et al. Expires April 2, 2011 [Page 22] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Upon approval of this document, IANA is requested to contact Stuart Cheshire, maintainer of the independent service name registry [SRVREG], in order to merge the contents of that private registry into the official IANA registry. It is expected that the independent registry web page will be updated with pointers to the IANA registry and to this RFC. IANA is instructed to create a new service name entry in the service name and port number registry [PORTREG] for any entry in the "Protocol and Service Names" registry [PROTSERVREG] that does not already have one assigned. IANA is also instructed to indicate in the Assignment Notes for "www" and "www-http" that they are duplicante terms that refer to the "http" service, and should not be used for discovery purposes. For this conceptual service (human-readable web pages served over HTTP) the correct service name to use for service discovery purposes is "http" (see Section 5). 10.1. Service Name Consistency Section 8.1 defines which character strings are well-formed service names, which until now had not been clearly defined. The definition in Section 8.1 was chosen to allow maximum compatibility of service names with current and future service discovery mechanisms. As of August 5, 2009 approximately 98% of the so-called "Short Names" from existing port number registrations [PORTREG] meet the rules for legal service names stated in Section 8.1, and hence for these services their service name will be exactly the same as their "Short Name". The remaining approximately 2% of the exiting "Short Names" are not suitable to be used directly as well-formed service names because they contain illegal characters such as asterisks, dots, pluses, slashes, or underscores. All existing "Short Names" conform to the length requirement of 15 characters or fewer. For these unsuitable "Short Names", listed in the table below, the service name will be the Short Name with any illegal characters replaced by hyphens. IANA SHALL add an entry to the registry giving the new well-formed primary service name for the existing service, that otherwise duplicates the original assignment information. In the description field of this new entry giving the primary service name, IANA SHALL record that it assigns a well-formed service name for the previous service and reference the original assignment. In the Assignment Notes field of the original assignment, IANA SHALL add a note that this entry is an alias to the new well-formed service name, and that the old service name is historic, not usable for use with many common service Cotton, et al. Expires April 2, 2011 [Page 23] =0C Internet-Draft Service Name and Port Number Procedures September 2010 discovery mechanisms. Names containing illegal characters to be replaced by hyphens: Cotton, et al. Expires April 2, 2011 [Page 24] =0C Internet-Draft Service Name and Port Number Procedures September 2010 +----------------+-----------------+-----------------+ | 914c/g | acmaint_dbd | acmaint_transd | | atex_elmd | avanti_cdp | badm_priv | | badm_pub | bdir_priv | bdir_pub | | bmc_ctd_ldap | bmc_patroldb | boks_clntd | | boks_servc | boks_servm | broker_service | | bues_service | canit_store | cedros_fds | | cl/1 | contamac_icm | corel_vncadmin | | csc_proxy | cvc_hostd | dbcontrol_agent | | dec_dlm | dl_agent | documentum_s | | dsmeter_iatc | dsx_monitor | elpro_tunnel | | elvin_client | elvin_server | encrypted_admin | | erunbook_agent | erunbook_server | esri_sde | | EtherNet/IP-1 | EtherNet/IP-2 | event_listener | | flr_agent | gds_db | ibm_wrless_lan | | iceedcp_rx | iceedcp_tx | iclcnet_svinfo | | idig_mux | ife_icorp | instl_bootc | | instl_boots | intel_rci | interhdl_elmd | | lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C | | LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet | | mdbs_daemon | menandmice_noh | msl_lmd | | nburn_id | ncr_ccl | nds_sso | | netmap_lm | nms_topo_serv | notify_srvr | | novell-lu6.2 | nuts_bootp | nuts_dem | | ocs_amu | ocs_cmu | pipe_server | | pra_elmd | printer_agent | redstorm_diag | | redstorm_find | redstorm_info | redstorm_join | | resource_mgr | rmonitor_secure | rsvp_tunnel | | sai_sentlm | sge_execd | sge_qmaster | | shiva_confsrvr | sql*net | srvc_registry | | stm_pproc | subntbcst_tftp | udt_os | | universe_suite | veritas_pbx | vision_elmd | | vision_server | wrs_registry | z39.50 | +----------------+-----------------+-----------------+ Following the example set by the "application/whoispp-query" MIME Content-Type [RFC2957], the service name for "whois++" will be "whoispp". 10.2. Port Numbers for SCTP and DCCP Experimentation Two System UDP and TCP ports, 1021 and 1022, have been reserved for experimental use [RFC4727]. This document assigns the same port numbers for SCTP and DCCP, updates the TCP and UDP registrations, and also instructs IANA to automatically assign these two port numbers for any future transport protocol with a similar sixteen-bit port number namespace. Cotton, et al. Expires April 2, 2011 [Page 25] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Note that these port numbers are meant for temporary experimentation and development in controlled environments. Before using these port numbers, carefully consider the advice in Section 6.1 in this document, as well as in Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692]. Most importantly, application developers must request a permanent port number assignment from IANA as described in Section 8.1 before any kind of non-experimental deployment. +--------------------+----------------------------+ | Registrant | IETF | | Contact | IESG | | Service Name | exp1 | | Port Number | 1021 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 1 | | Reference | [RFCyyyy],RFC 4727] | +--------------------+----------------------------+ +--------------------+----------------------------+ | Registrant | IETF | | Contact | IESG | | Service Name | exp2 | | Port Number | 1022 | | Transport Protocol | DCCP, SCTP, TCP, UDP | | Description | RFC3692-style Experiment 2 | | Reference | [RFCyyyy], [RFC4727] | +--------------------+----------------------------+ [RFC Editor Note: Please change "yyyy" to the RFC number allocated to this document before publication.] 10.3. Updates to DCCP Registries This document updates the IANA allocation procedures for the DCCP Port Number and DCCP Service Codes Registries [RFC4340]. 10.3.1. DCCP Service Code Registry Service Codes are allocated first-come-first-served according to Section 19.8 of the DCCP specification [RFC4340]. This document updates that section by extending the guidelines given there in the following ways: o IANA MAY assign new Service Codes without seeking Expert Review using their discretion, but SHOULD seek expert review if a request seeks more than five Service Codes. Cotton, et al. Expires April 2, 2011 [Page 26] =0C Internet-Draft Service Name and Port Number Procedures September 2010 o IANA should feel free to contact the DCCP Expert Reviewer with questions on any registry, regardless of the registry policy, for clarification or if there is a problem with a request [RFC4340]. 10.3.2. DCCP Port Numbers Registry The DCCP ports registry is defined by Section 19.9 of the DCCP specification [RFC4340]. Allocations in this registry require prior allocation of a Service Code. Not all Service Codes require IANA- assigned ports. This document updates that section by extending the guidelines given there in the following way: o IANA should normally assign a value in the range 1024-49151 to a DCCP server port. IANA allocation requests to allocate port numbers in the System Ports range (0 through 1023), require an "IETF Review" [RFC5226] prior to allocation by IANA [RFC4340]. o IANA MUST NOT allocate more than one DCCP server port to a single service code value. o The allocation of multiple service codes to the same DCCP port is allowed, but subject to expert review. o The set of Service Code values associated with a DCCP server port should be recorded in the service name and port number registry. o A request for additional Service Codes to be associated with an already allocated Port Number requires Expert Review. These requests will normally be accepted when they originate from the contact associated with the port registration. In other cases, these applications will be expected to use an unallocated port, when this is available. The DCCP specification [RFC4340] notes that a short port name MUST be associated with each DCCP server port that has been assigned. This document clarifies that this short port name is the Service Name as defined here, and this name MUST be unique. 11. Contributors Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have contributed text and ideas to this document. 12. Acknowledgments The text in Section 10.3 is based on a suggestion originally proposed Cotton, et al. Expires April 2, 2011 [Page 27] =0C Internet-Draft Service Name and Port Number Procedures September 2010 as a part of the DCCP Service Codes document[RFC5595] by Gorry Fairhurst. Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program. 13. References 13.1. Normative References [ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Cotton, et al. Expires April 2, 2011 [Page 28] =0C Internet-Draft Service Name and Port Number Procedures September 2010 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 13.2. Informative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-06 (work in progress), March 2010. [I-D.cheshire-nat-pmp] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-03 (work in progress), April 2008. [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", November 2001. [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name and Transport Protocol Port Number Registry", http://www.iana.org/assignments/port-numbers. [PROTSERVREG] Internet Assigned Numbers Authority (IANA), "Protocol and Service Names Registry", http://www.iana.org/assignments/service-names. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", RFC 1078, November 1988. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2957] Daigle, L. and P. Faltstrom, "The application/ whoispp-query Content-Type", RFC 2957, October 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. Cotton, et al. Expires April 2, 2011 [Page 29] =0C Internet-Draft Service Name and Port Number Procedures September 2010 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, February 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [SRVREG] "DNS SRV Service Types Registry", http://www.dns-sd.org/ServiceTypes.html. [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application for System (Well Known) Port Number", http://www.iana.org/cgi-bin/sys-port-number.pl. [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. [USRFORM] Internet Assigned Numbers Authority (IANA), "Application for User (Registered) Port Number", http://www.iana.org/cgi-bin/usr-port-number.pl. Authors' Addresses Michelle Cotton Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1 310 823 9358 Email: michelle.cotton@icann.org URI: http://www.iana.org/ Cotton, et al. Expires April 2, 2011 [Page 30] =0C Internet-Draft Service Name and Port Number Procedures September 2010 Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +358 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/ Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292 USA Phone: +1 310 448 9151 Email: touch@isi.edu URI: http://www.isi.edu/touch Magnus Westerlund Ericsson Farogatan 6 Stockholm 164 80 Sweden Phone: +46 8 719 0000 Email: magnus.westerlund@ericsson.com Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com Cotton, et al. Expires April 2, 2011 [Page 31] =0C --Apple-Mail-94-386818094-- --Apple-Mail-95-386818137 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyOTE4 MTYyMFowIwYJKoZIhvcNAQkEMRYEFNGsdVgvCpuR3CrpyRHRYuI5ryE/MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAA6kSnAlv+yhSRMfeitkLxi5eqF+fjdHW10WfbUHs/BqC1HXKHcv mEFNidfrDjVBbAEHCHAbVn1xhouTiebd3AOY6N/uD3XxueTx+djJV6V9LIe8yJZhGfh9HoB63Xe2 kuibkqqDgEnz93ru9iElL3zMdeB+xL8xHTU3ZovoBXkB3PINgLrUQ/U/k95bIKNF2voXrYV1dlXn tFdjU8+bdVWEgrr0IcRk+F1lNIMoSfDs+UW//jrlRZTBUTK1NhwGeObaKkXUaOxgYreBP0FUwU7I 882kMLAJzJhgaxJRvPYWrjG2pPljEebLQvJ7lRD7cKERu5TQ/HIZFQCe3tO+7j8AAAAAAAA= --Apple-Mail-95-386818137-- From michelle.cotton@icann.org Thu Sep 30 16:24:24 2010 Return-Path: X-Original-To: port-srv-reg@core3.amsl.com Delivered-To: port-srv-reg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BB63A6BC9 for ; Thu, 30 Sep 2010 16:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.203 X-Spam-Level: X-Spam-Status: No, score=-106.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 RgHvCYjlMuPw for ; Thu, 30 Sep 2010 16:24:23 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id EC2013A6B01 for ; Thu, 30 Sep 2010 16:24:22 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 30 Sep 2010 16:25:09 -0700 From: Michelle Cotton To: Lars Eggert , Magnus Westerlund Date: Thu, 30 Sep 2010 16:25:07 -0700 Thread-Topic: [port-srv-reg] Comments on SVN revision 68 Thread-Index: ActgApPYwls7kY00TzyGWK/bkMqT7wA9CPUF Message-ID: In-Reply-To: <3292C01F-0C7C-45B0-A460-5B91FA635890@nokia.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "port-srv-reg@ietf.org" Subject: Re: [port-srv-reg] Comments on SVN revision 68 X-BeenThere: port-srv-reg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of updates to service name and transport protocol port registry List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 23:24:24 -0000 All, Here are our comments/questions for the proposed version 07. Let us know if anything below needs clarification. Thanks, Michelle and Pearl *******=20 1. In Section 2, we believe the following should be changed from: ...so that management requests can complete in a timely manner. To: ...so that requests can be completed in a timely manner. 2. Related to section 5.1, what about the rule that there are no consecutiv= e hypens? Could someone register a---------5 as a service name/port number? Are there any issues with that? 3. In section 8.1, we saw this part taken out: Service names, on the other hand, are not tied to a specific transport protocol, and registration requests for only a service name (but not a port number) allocate that service name for use with all transport protocols. I also read the section below that paragraph in the document. Just to confirm, there are no situations where a service name would be registered without identifying a transport protocol? 4. In section 8.1, there is the list of what is required to apply for a port number assignment. Are those pieces of information going to fully replace the current application form or will we retain some of the other questions currently asked? 5. Also in section 8.1, the document says: If the registration request is for the addition of a new transport protocol to an already assigned service name, IANA needs to confirm with th= e Registrant for the existing assignment whether this addition is appropriate= . If the registration request is for a service name overloading a port number (see Section 5), IANA needs to confirm with the Registrant for the existing service name whether the registration of the overloading is appropriate. Is checking with the listed contact person be sufficient in these cases? If they are not available we check with the organization/company. 6. In section 8.1, we think this should be slightly changed When IANA receives a registration request - containing the above information - that is requesting a port number, IANA SHALL initiate an "Expert Review" [RFC5226] in order to determine whether an assignment should be made. For requests that do not include a port number, IANA SHOULD assign the service name under a simple "First Come First Served" policy [RFC5226]. It should say something like "For requests that are not requesting a port number," 7. In section 8.5, what about mergers or acquisitions? How are those to be handled in the case of port number/service name contact information? 8. In section 8.6 it uses the term "administrative contact". This should be changed to the Registrant. 9. In section 10, just double checking...should "duplicante" be "duplicate"???? 10. In section 5.1, there is a typo 'maximu'. Should be maximum? 11. In section 6.1, it mentions '64-bit'. We noticed that the new version changed all 16-bit to 'sixteen-bit'. So would it be consistent to use 'sixty-four-bit' to replace '64-bit'? They should probably at least be in the same format. 12. The following paragraph describes that we only assign the requested protocol and mark others 'Reserved': "The new allocation procedure conserves resources by allocating a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually uses. The port number will be marked as Reserved = - instead of Assigned - in the port number registries of the other transport protocols." QUESTION: When reserving the non-used protocols, are we putting additional lines for each entry? This will make it very clear however the registry will get much larger. (and it is already quite large) 13. In section 8.1 about the Registrant and Contact, we have a clarifying question. Will a role account acceptable? I imagine that is partly up to how we handl= e the contacts internally. If a registrant wants the contact to be tech-dept@company.com then this should be OK. Would we require an acutal person's name to go with it? Or would "Technical Department" be sufficient= ? Also, should we add the word "valid" to the email address so they know it should be a valid/working email address? 14. This document still uses one instance of "assignee" in section 8.1. Should that be changed to "original requester" or Registrant? On 9/29/10 11:16 AM, "Lars Eggert" wrote: > OK, I suggest everyone give the current version a read, and then we ship = it. >=20 > Lars >=20 >=20