From owner-namedroppers@ops.ietf.org Thu Nov 1 01:14:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14337 for ; Thu, 1 Nov 2001 01:14:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15zAls-0006jX-00 for namedroppers-data@psg.com; Wed, 31 Oct 2001 21:52:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15zAlr-0006jR-00 for namedroppers@ops.ietf.org; Wed, 31 Oct 2001 21:52:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15zAlr-000KkL-00 for namedroppers@ops.ietf.org; Wed, 31 Oct 2001 21:52:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <5.1.0.14.2.20011016143043.00afad90@localhost> References: <5.1.0.14.2.20011016143043.00afad90@localhost> Message-ID: <1916.1004593762@brandenburg.cs.mu.OZ.AU> From: Robert Elz To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: namedroppers@ops.ietf.org Subject: Re: Admitting more documents: application keys in DNS Date: Thu, 01 Nov 2001 12:49:22 +0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In general I have no great problems with adding new RR types in the DNS - if they turn out to be rubbish (perhaps 50% of the assigned RR types are) they don't cost all that much (really just some implementor effort in the servers to support them, and for most RR's that's pretty trivial). On the other hand, I very much don't like bending the naming tree to support new applications. SRV was bad enough, with its extra names for protocol elements that have to be introduced, but it is general enough, and needed enough, that there was little other choice. But we should never need to do that again. So, if any new RR type fits the normal naming tree, and has some kind of a plausible possible use, then let it be defined, no-one needs to implement it just because it is defined, only if the users actually want to use the thing. On the other hand, any new RR type that wants to bend the naming tree, that is, which requires magic names, ought to be told that what it is doing is really inventing a new protocol, and ought to be using some port other than 53 - and then use (if relevant) SRV to find that port (and server). It is a little hard to see how an application key can be stored in the DNS without adding something to identify the application - that's bending the naming tree, and so should be done some other way, using some kind of key server, which can itself be located using the DNS, rather than being implemented directly in the DNS itself. On the other hand, if one needs keys, certificates, or anything else, that map directly from the domain names we have now (my company's certificate or something) then I see no harm in defining an RR type to carry that. I also see no merit at all in the argument that adding a new server is somehow more difficult than adding new RR types to the DNS, so requiring the former would be imposing n insurmountable barrier to implementation. The problem (the barrier) is getting people to actually decide that they need to make keys/certificates/... available in the first place. Once they have decided they should do that, whether the method to do it is to stick a whole bunch of new RR's in the zone file, or to build some other kind of database and run a new server to return records from it is pretty close to irrelevant. As long as someone supplies the recipe, they will follow it - after they're convinced to take any kind of action at all. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 1 07:44:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13054 for ; Thu, 1 Nov 2001 07:44:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15zGZL-000BAq-00 for namedroppers-data@psg.com; Thu, 01 Nov 2001 04:03:35 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15zGZK-000BAk-00 for namedroppers@ops.ietf.org; Thu, 01 Nov 2001 04:03:34 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15zGZK-0004ed-00 for namedroppers@ops.ietf.org; Thu, 01 Nov 2001 04:03:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: To: namedroppers@ops.ietf.org Subject: list policy From: Randy Bush Date: Thu, 01 Nov 2001 03:00:00 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is ietf-process@lists.elistx.com. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 1 11:17:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22799 for ; Thu, 1 Nov 2001 11:17:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15zK9S-000ESJ-00 for namedroppers-data@psg.com; Thu, 01 Nov 2001 07:53:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15zK9S-000ESD-00 for namedroppers@ops.ietf.org; Thu, 01 Nov 2001 07:53:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15zK9S-000AnF-00 for namedroppers@ops.ietf.org; Thu, 01 Nov 2001 07:53:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200111011345.IAA13041@error-messages.mit.edu> In-Reply-To: Your message of "Thu, 01 Nov 2001 12:49:22 +0700." <1916.1004593762@brandenburg.cs.mu.OZ.AU> To: Robert Elz cc: namedroppers@ops.ietf.org Subject: Re: Admitting more documents: application keys in DNS Date: Thu, 01 Nov 2001 08:45:16 -0500 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On the other hand, I very much don't like bending the naming tree > to support new applications. Essentially, you seem to be saying that DNS should only talk about hosts (and mail domains). This is a valid position, if perhaps a little disappointing to someone like me who is used to using DNS to talk about users, printers, network filesystems, and so forth (Hesiod). > I also see no merit at all in the argument that adding a new server > is somehow more difficult than adding new RR types to the DNS, so > requiring the former would be imposing n insurmountable barrier to > implementation. Assuming we ever deploy DNSSEC at the root, the diference has to do with the technical mechanisms of trust, not implementation difficulty. Here are two rough scenarios for an application which requires some global notion of authentication, one using a DNS RR for a key and one using a separate server: 1. The root signs edu (NS,KEY) which signs mit.edu (NS,KEY) which signs error-messages.mit.edu (A,KEY or APPKEY) which is used to contact some application. 2. The root signs edu (NS,KEY) which signs mit.edu (NS,KEY) which signs _keyserver._tcp.error-messages.mit.edu (SRV) which points to keyserver.mit.edu (A) which is also signed by mit.edu. Separately, some CA root signs a certificate which is used to contact some application. (Or maybe there's a chain of certificates involved; the point is that the application key has no trust relationship to the DNS.) In scenario 1, the DNS root has ultimate control over all application keys, and delegates that control through DNS zones. In scenario 2, some CA root has ultimate control over all application keys, and may delegate that control in some way not necessarily related to DNS zones. Some of us have argued that any kind of standard enabling scenario 1 is a bad idea--that it is never appropriate, or that it is too dangerous to justify the limited situations where it is appropriate. Some others of us have argued that it is a good idea, or at least interesting enough to pursue, and that it was already envisioned by RFC 2535. Either way, framing the argument as purely one about implementation is deceptive. I guess it's *possible* to follow the trust chain from DNS to another protocol without signing keys in the DNS, but at the very least it would involve sharing a private key between the implementations of two different protocols (the private key for mit.edu KEY would have to be used to sign both DNS records and data for some key server protocol), and I don't think anyone would be happy with that. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 1 11:22:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22965 for ; Thu, 1 Nov 2001 11:22:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15zKMr-000ElP-00 for namedroppers-data@psg.com; Thu, 01 Nov 2001 08:06:57 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15zKMr-000ElJ-00 for namedroppers@ops.ietf.org; Thu, 01 Nov 2001 08:06:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15zKMr-000BAQ-00 for namedroppers@ops.ietf.org; Thu, 01 Nov 2001 08:06:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200111011345.IAA13041@error-messages.mit.edu> References: <200111011345.IAA13041@error-messages.mit.edu> Message-ID: <1064.1004623994@brandenburg.cs.mu.OZ.AU> From: Robert Elz To: Greg Hudson cc: namedroppers@ops.ietf.org Subject: Re: Admitting more documents: application keys in DNS Date: Thu, 01 Nov 2001 21:13:14 +0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 01 Nov 2001 08:45:16 -0500 From: Greg Hudson Message-ID: <200111011345.IAA13041@error-messages.mit.edu> | Essentially, you seem to be saying that DNS should only talk about | hosts (and mail domains). No, not at all. Rather that I should be able to name anything and everything in my DNS domain in any way I see fit - allocating names to anything I like, or not. If you choose to do that for users, etc that's just fine (MB was one of the original RR types of course). Where things go wrong is where something tells me that I have to reserve this particular name for some specific purpose, because there's some protocol out there that simply assumes it can construct names (within some domain) for its own ends. That's broken. That's also SRV, where the impact is lessened by the use of the _ chars in the constructed names (lessened, not avoided). That kind of technique could perhaps be used once or twice more - then the results would start to become absurd. It is bad enough when this is a convention (like www.) it is truly horrid when it is a protocol element (which it would need to be for applications to be able to locate the relevant key). | Assuming we ever deploy DNSSEC at the root, the diference has to do | with the technical mechanisms of trust, not implementation difficulty. I was replying to one minor point I noticed during this long discussion, but never mind... And yes, trust chains are important, but things are rarely as black and white as suggested here. Assuming that one buys the argument that domain names are a suitable identifier for a unit of trust, there's no reason at all that a DNS RR (DNSSEC signed, etc) that contains an organisation's public key, or CA signed certificate, or whatever the security needs, which can then be used to authenticate all of the organisation's application keys, obtained from some completely different mechanism. What's more, the DNS might be just one way to obtain that data, CA's might offer other methods for you to obtain a verified organisation certificate that you can then use to validate all the rest of their keys. Certainly just because DNSSEC exists, and has its trust model, is no reason that it needs to be used exclusively to validate everything that might possibly exist. What counts here is that the data being put into the DNS fits it logically already. Then the part that doesn't make a good fit is done other ways. That is assuming that DNS names are in fact the right kind of identity to use (if they're not, then obviously the whole question of using the DNS becomes irrelevant). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 2 10:39:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08148 for ; Fri, 2 Nov 2001 10:39:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15zg0S-000EnX-00 for namedroppers-data@psg.com; Fri, 02 Nov 2001 07:13:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15zg0S-000EnR-00 for namedroppers@ops.ietf.org; Fri, 02 Nov 2001 07:13:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15zg0R-000MzF-00 for namedroppers@ops.ietf.org; Fri, 02 Nov 2001 07:13:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011102095823.00b0fec0@localhost> Date: Fri, 02 Nov 2001 10:03:12 -0500 To: erik Nordmark , Thomas Narten From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: draft-ietf-dnsext-dnssec-okbit-03.txt Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The informal WGLC has concluded, there have been no objections to any of the changes from version 02, this chair received some support for the changes via private email. Please advance this document as fast as possible. thanks Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 2 13:05:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13687 for ; Fri, 2 Nov 2001 13:05:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ziT0-000IGx-00 for namedroppers-data@psg.com; Fri, 02 Nov 2001 09:50:54 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ziSz-000IGr-00 for namedroppers@ops.ietf.org; Fri, 02 Nov 2001 09:50:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ziSz-0001Ic-00 for namedroppers@ops.ietf.org; Fri, 02 Nov 2001 09:50:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011102122523.024ea0a0@localhost> Date: Fri, 02 Nov 2001 12:27:55 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC summary: obsolete IQUERY Cc: tail@nominum.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This working group last call has completed, the consensus of the working group is to advance this document. Before the document is sent to the IESG the author needs to fix few minor wording issues for clarity. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Nov 5 10:25:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23611 for ; Mon, 5 Nov 2001 10:25:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 160l7A-0004Vj-00 for namedroppers-data@psg.com; Mon, 05 Nov 2001 06:52:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 160l79-0004Vd-00 for namedroppers@ops.ietf.org; Mon, 05 Nov 2001 06:52:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 160l79-000IQl-00 for namedroppers@ops.ietf.org; Mon, 05 Nov 2001 06:52:39 -0800 Message-Id: <200111051209.HAA11899@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-01.txt Date: Mon, 05 Nov 2001 07:09:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC Opt-in Author(s) : R. Arends, M. Kosters, D. Blacka Filename : draft-ietf-dnsext-dnssec-opt-in-01.txt Pages : 16 Date : 02-Nov-01 RFC 2535 defines a secure zone as completely signed. There are cases where there is no need, it is not practical, or simply not possible to maintain a completely signed zone. To allow administrators to gradually adopt DNSSEC, a model, 'Opt-In', is proposed that generalizes the inclusion of unsigned records within a secure zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-opt-in-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011102133044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011102133044.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Nov 5 10:25:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23623 for ; Mon, 5 Nov 2001 10:25:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 160lJ2-0004mf-00 for namedroppers-data@psg.com; Mon, 05 Nov 2001 07:04:56 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 160lJ2-0004mZ-00 for namedroppers@ops.ietf.org; Mon, 05 Nov 2001 07:04:56 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 160lJ2-000IlT-00 for namedroppers@ops.ietf.org; Mon, 05 Nov 2001 07:04:56 -0800 Message-Id: <200111051210.HAA12086@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-schlyter-pkix-dns-00.txt Date: Mon, 05 Nov 2001 07:10:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS as X.509 PKIX Certificate Storage Author(s) : J. Schlyter, L. Johansson Filename : draft-schlyter-pkix-dns-00.txt Pages : 6 Date : 02-Nov-01 A major problem facing PKIX deployment and implementation is the problem of constructing certificate paths for input to the path validation algorithm. This draft describes the use of the DNS as a certificate store and it's implication for path validation in PKIX. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schlyter-pkix-dns-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schlyter-pkix-dns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schlyter-pkix-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011102140657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schlyter-pkix-dns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schlyter-pkix-dns-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011102140657.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Nov 5 10:35:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24050 for ; Mon, 5 Nov 2001 10:35:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 160lSt-00052c-00 for namedroppers-data@psg.com; Mon, 05 Nov 2001 07:15:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 160lSt-00052W-00 for namedroppers@ops.ietf.org; Mon, 05 Nov 2001 07:15:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 160lSt-000J2n-00 for namedroppers@ops.ietf.org; Mon, 05 Nov 2001 07:15:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Date: Mon, 5 Nov 2001 16:07:49 +0100 (MET) From: Jakob Schlyter To: IETF DNSEXT WG Subject: I-D ACTION:draft-schlyter-pkix-dns-00.txt (fwd) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: this draft might be interesting to this wg. jakob ---------- Forwarded message ---------- Date: Mon, 05 Nov 2001 07:10:01 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-schlyter-pkix-dns-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS as X.509 PKIX Certificate Storage Author(s) : J. Schlyter, L. Johansson Filename : draft-schlyter-pkix-dns-00.txt Pages : 6 Date : 02-Nov-01 A major problem facing PKIX deployment and implementation is the problem of constructing certificate paths for input to the path validation algorithm. This draft describes the use of the DNS as a certificate store and it's implication for path validation in PKIX. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schlyter-pkix-dns-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schlyter-pkix-dns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schlyter-pkix-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-schlyter-pkix-dns-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 6 11:50:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21099 for ; Tue, 6 Nov 2001 11:50:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1618xE-0008DB-00 for namedroppers-data@psg.com; Tue, 06 Nov 2001 08:20:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 1618xD-0008D5-00 for namedroppers@ops.ietf.org; Tue, 06 Nov 2001 08:19:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 1618xD-0008Z6-00 for namedroppers@ops.ietf.org; Tue, 06 Nov 2001 08:19:59 -0800 Message-Id: <200111061215.HAA06980@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-renewal-mode-00.txt Date: Tue, 06 Nov 2001 07:15:30 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : TKEY Secret Key Renewal Mode Author(s) : Y. Kamite, M. Nakayama Filename : draft-ietf-dnsext-tkey-renewal-mode-00.txt Pages : 18 Date : 05-Nov-01 This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing periodically secret keys for TSIG [RFC2845]. This method is intended to prevent signing messages with old and non-safe keys permanently. A server checks the valid periods of keys whenever it receives queries, and if any key is too old, it is demanded that the client sharing it should send a secret renewal request. After secret establishment and a query with a new signature is received, the key becomes valid formally and the previous one is invalidated A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-tkey-renewal-mode-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011105132012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-renewal-mode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011105132012.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 7 10:38:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12129 for ; Wed, 7 Nov 2001 10:38:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 161U9c-0007HE-00 for namedroppers-data@psg.com; Wed, 07 Nov 2001 06:58:12 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 161U9b-0007H8-00 for namedroppers@ops.ietf.org; Wed, 07 Nov 2001 06:58:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 161U9b-000Itm-00 for namedroppers@ops.ietf.org; Wed, 07 Nov 2001 06:58:11 -0800 Message-Id: <200111071204.HAA01252@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-00.txt Date: Wed, 07 Nov 2001 07:04:51 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Limiting the Scope of the KEY Resource Record Author(s) : D. Massey, S. Rose Filename : draft-ietf-dnsext-restrict-key-for-dnssec-00.txt Pages : 8 Date : 06-Nov-01 This document limits the KEY resource record to only DNS zone keys. The original KEY resource record used sub-typing to store both DNS zone keys and arbitrary application keys. DNS security keys and application keys differ in almost every respect and should not be combined in a single sub-typed resource record. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RDATA. Three existing application key sub-types are changed to historic, but the format of the KEY record is not changed. This document updates RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-restrict-key-for-dnssec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011106142640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-restrict-key-for-dnssec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011106142640.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 8 13:23:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03432 for ; Thu, 8 Nov 2001 13:22:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 161tOt-000Dkf-00 for namedroppers-data@psg.com; Thu, 08 Nov 2001 09:55:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 161tOt-000DkZ-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 09:55:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 161tOs-000A9Y-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 09:55:38 -0800 Message-ID: <9B2635C00D654F4CA36B89C22364F0C313803F@esebe008.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Mikael.Latvala@nokia.com To: namedroppers@ops.ietf.org Subject: library function for SRV RR Date: Thu, 8 Nov 2001 19:53:29 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, Has there been any discussion about specifying a funtion call for SRV RRs? For example: struct hostent2 *getipnodebyservice(const char *name, int af, int flags, int *error_num); where struct hostent2 { char *h_name; char **h_alias; int h_addrtype; int h_length; char **h_addr_list; int *protocol_list; } /Mikael to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 8 14:25:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04591 for ; Thu, 8 Nov 2001 14:25:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 161uX2-000F7O-00 for namedroppers-data@psg.com; Thu, 08 Nov 2001 11:08:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 161uX2-000F7E-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 11:08:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 161uX2-000C7M-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 11:08:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BEAD635.5A7DB023@zk3.dec.com> References: <9B2635C00D654F4CA36B89C22364F0C313803F@esebe008.NOE.Nokia.com> Date: Thu, 08 Nov 2001 14:00:05 -0500 From: Vladislav Yasevich To: Mikael.Latvala@nokia.com Cc: namedroppers@ops.ietf.org Subject: Re: library function for SRV RR Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mikael I think getaddrinfo/getnameinfo can be adopted to use SRV RRs. They already take all the parameters you've specified and more. -vlad Mikael.Latvala@nokia.com wrote: > > Hello, > > Has there been any discussion about specifying a funtion call for SRV RRs? > > For example: > > struct hostent2 *getipnodebyservice(const char *name, int af, int flags, int > *error_num); > > where > > struct hostent2 { > char *h_name; > char **h_alias; > int h_addrtype; > int h_length; > char **h_addr_list; > int *protocol_list; > } > > /Mikael > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 8 14:27:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04633 for ; Thu, 8 Nov 2001 14:27:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 161ufK-000FLP-00 for namedroppers-data@psg.com; Thu, 08 Nov 2001 11:16:42 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 161ufK-000FLJ-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 11:16:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 161ufK-000CMH-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 11:16:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200111081916.fA8JG2H16733@as.vix.com> In-Reply-To: Message from Vladislav Yasevich of "Thu, 08 Nov 2001 14:00:05 EST." <3BEAD635.5A7DB023@zk3.dec.com> To: namedroppers@ops.ietf.org Subject: Re: library function for SRV RR Date: Thu, 08 Nov 2001 11:16:02 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit how about bind8/contrib/srv, whose .h file contains the following /**************************************************************************** ** $Id: srv.h,v 1.1 1998/07/30 21:56:39 vixie Exp $ ** ** Definition of something or other ** ** Created : 979899 ** ** Copyright (C) 1997 by Troll Tech AS. All rights reserved. ** ****************************************************************************/ #ifndef SRV_H #define SRV_H struct srvhost { unsigned int pref; struct srvhost * next; unsigned int port; unsigned int weight; unsigned int rweight; char name[1]; }; extern void freesrvhost ( struct srvhost * ); extern struct srvhost * getsrv( const char * domain, const char * service, const char * protocol ); #endif to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 8 14:49:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04984 for ; Thu, 8 Nov 2001 14:49:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 161uun-000FhM-00 for namedroppers-data@psg.com; Thu, 08 Nov 2001 11:32:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 161uun-000FhG-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 11:32:41 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 161uum-000Cnw-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 11:32:40 -0800 Message-ID: <20011108142907.A10915@research.netsol.com> References: <9B2635C00D654F4CA36B89C22364F0C313803F@esebe008.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C313803F@esebe008.NOE.Nokia.com> Date: Thu, 8 Nov 2001 14:29:07 -0500 From: Mike Schiraldi To: Mikael.Latvala@nokia.com Cc: namedroppers@ops.ietf.org Subject: Re: library function for SRV RR Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Has there been any discussion about specifying a funtion call for SRV RRs? There are a few libraries out there that implement a nice API for this. One is libsrv, available at http://cvs.vanrein.org/~libsrv/browse/ (though at this moment, the site appears to be down) Another, called RULI, is at http://ruli.sourceforge.net/. I haven't tried this project, but at least their site is up. --=20 Mike Schiraldi Verisign Applied Research --opJtzjQTFsWo+cga Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIKIAYJKoZIhvcNAQcCoIIKETCCCg0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B6wwggR2MIID36ADAgECAhAyACTCO7tQsBTRNUR0/tTjMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMDMyMjAwMDAw MFoXDTAyMDMyMjIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pa2UgU2NoaXJhbGRpMSgwJgYJKoZI hvcNAQkBFhlyYWxkaUByZXNlYXJjaC5uZXRzb2wuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDu28IxMPojtN900dqX3LO3rfhirsJstpbSOzKVwPH9GwIgycFIn3YFkmOpeB40 cBkqNC1HzreGuFFAo9f3Y9xPjbvnEWlNo6oBu/wGL53gUtsUcNcj7tOngfjTr/4V3rohPuWU 4qRAZxjd5qaFUSP3bLh/U/7MoRwRB2Sz82HCqwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAYOkgLNF2 HYrK+ucdU0TN2PIAtbB3vV0cLhHJfE6zzyL9u5PlAKnxqwVYozd5S/u4Lg1WvDFE3vG3mVIE Fobol2RmSNIo6kOgED48B6oWgU/21lysVZ6DRPnGTSX7FsIH12L0mHj7jSDkzTqtkbzY6is/ YBkKDmeAuXnmljJ7H7wwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG 9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNV BAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN OTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQW u1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0Rc qkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqn sX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4w PAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOB gQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s 3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg 5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAyACTCO7tQsBTRNUR0/tTjMAkGBSsOAwIa BQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMTA4 MTkyOTA3WjAjBgkqhkiG9w0BCQQxFgQUzdv8nH+V2JcKvBjnwnMvMtt2UxcwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDXhHMJcaiKur+JFbm/9EQN Q050HDWysKg8XIuTaKR86lSQN5VGU2vPhsLhbatUM385cDAFObeCSQiyeU94rt1CyZrnsKiM COjrIo+7O/p/AFbm7gV8O1d5Qnaec2LbH1LE8eh7Kb3OYQUNtQq0WqCi3Wqbm6ydFG/XagzJ MIXhpg== --opJtzjQTFsWo+cga-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 8 21:49:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14795 for ; Thu, 8 Nov 2001 21:49:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1621Ns-000NUH-00 for namedroppers-data@psg.com; Thu, 08 Nov 2001 18:27:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 1621Nr-000NUB-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 18:27:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 1621Nr-000PIF-00 for namedroppers@ops.ietf.org; Thu, 08 Nov 2001 18:27:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 8 Nov 2001 19:23:27 -0700 Subject: DHCID RR draft status? Cc: Mark Stapp , rdroms@cisco.com, namedroppers To: ogud@ogud.com, Randy Bush From: Ted Lemon Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The last I saw of this was a laundry list of suggestions forwarded to the list by Randy, many of which didn't seem to me to be terribly important, and some of which actually seemed wrong, followed by a message from Mark Stapp that responded to only one of these objections, and then silence. I am not convinced that all the points Randy mentioned need to be fixed - Randy did not appear to be willing to act as an advocate for those points, and apparently the people who made these points to him privately aren't willing to advocate them publicly. Are we ready to go to PS now, or not? If not, why not? What is the next step that needs to be taken, and who needs to take it? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 9 06:58:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07002 for ; Fri, 9 Nov 2001 06:58:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1629rH-00098w-00 for namedroppers-data@psg.com; Fri, 09 Nov 2001 03:30:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 1629rH-00098q-00 for namedroppers@ops.ietf.org; Fri, 09 Nov 2001 03:30:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 1629rG-000Dut-00 for namedroppers@ops.ietf.org; Fri, 09 Nov 2001 03:30:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: "Your message with ID" Message-ID: Date: Fri, 9 Nov 2001 10:33:45 +0100 (CET) From: Erik Nordmark Subject: Re: DHCID RR draft status? To: Ted Lemon Cc: ogud@ogud.com, Randy Bush , Mark Stapp , rdroms@cisco.com, namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If I recall correctly most of the points that Randy forwarded seemed to be of the nature "the document would be more clear if X". There is a range of approaches for dealing with such comments; from arguing that the document is clear enough and the changes aren't needed to an approach of suggesting and interating on language that makes the spec clearer in the eyes of the reader. I think the first end of the range is far from ideal since it sends the message that comments asking for clarifications are not openly invited but instead are ignored or rejected. That doesn't help us produce clear specifications. When I've been an author I've found something closer to the other end of the range work quite well - making sure that I understand what the reader thinks is unclear and trying to figure out ways to clarify things. That approach also seems to result in folks continuing to be interested in asking for clarifications in the spec, which is the only way I know to produce clear specifications. So if I was concerned about getting a clear specification finished rapidly I know which path I'd take :^) Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 9 06:58:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07013 for ; Fri, 9 Nov 2001 06:58:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1629s9-00099a-00 for namedroppers-data@psg.com; Fri, 09 Nov 2001 03:30:57 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 1629s9-00099U-00 for namedroppers@ops.ietf.org; Fri, 09 Nov 2001 03:30:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 1629s9-000DwQ-00 for namedroppers@ops.ietf.org; Fri, 09 Nov 2001 03:30:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <3B379EE7-D4F6-11D5-A947-00039317663C@fugue.com> Date: Fri, 9 Nov 2001 02:43:29 -0700 Subject: Re: DHCID RR draft status? Cc: namedroppers , rdroms@cisco.com, Mark Stapp , Randy Bush , ogud@ogud.com To: Erik Nordmark From: Ted Lemon Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think the first end of the range is far from ideal since it sends the > message that comments asking for clarifications are not openly invited > but instead are ignored or rejected. That doesn't help us produce > clear specifications. > I agree with you up to a point, and that is the attitude that I try to maintain when writing drafts, but I have also found that there is always a change that you can make to any document to make it clearer, so if your algorithm is to persist in updating the document until nobody can think of any way to make it clearer, the document never goes to PS. What I would really appreciate is that if any of the comments Randy forwarded along appeal to Mark as reasonable changes to make, he make them, quickly, and resubmit the draft. And then, unless somebody comes up with a showstopper, we go to PS. As an incentive for the WG, if we can make this happen, I promise that I won't get up and grumble about this draft again in Salt Lake City. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 9 17:27:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29027 for ; Fri, 9 Nov 2001 17:27:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 162JnH-0000Ja-00 for namedroppers-data@psg.com; Fri, 09 Nov 2001 14:06:35 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 162JnG-0000JU-00 for namedroppers@ops.ietf.org; Fri, 09 Nov 2001 14:06:34 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 162JnG-0005Fi-00 for namedroppers@ops.ietf.org; Fri, 09 Nov 2001 14:06:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011109115636.02aafdd0@localhost> Date: Fri, 09 Nov 2001 12:03:03 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: 52'nd IETF DNSEXT agenda items Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please send me any items you want discussed in the meeting. I hope to post WG agenda around Nov 28'th so get the items in before then. The main focus of this meeting will be DNSSEC and related issues. Currently the WG meeting is scheduled for Monday night slot. Document editors, please submit revised versions of drafts well before deadline. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Nov 11 13:36:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27852 for ; Sun, 11 Nov 2001 13:36:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 162yyy-0004I8-00 for namedroppers-data@psg.com; Sun, 11 Nov 2001 10:05:24 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 162yyx-0004Hp-00 for namedroppers@ops.ietf.org; Sun, 11 Nov 2001 10:05:23 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 162yyx-000OaK-00 for namedroppers@ops.ietf.org; Sun, 11 Nov 2001 10:05:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 11 Nov 2001 09:54:05 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed changes to mdns-06 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Proposed changes to mdns-06 =========================== Proposer: Dave Thaler Date: 11/1/01 Section affected: 2 Rationale: In various sections in the draft, it is assumed that link == Subnet. In IPv6, with multilink subnets, this may not necessarily be the case. The use of the word "subnet" should therefore be changed to "link" throughout the document. Proposal: Change the following text: "Propagation of multicast DNS packets within the local subnet is considered sufficient to enable DNS name resolution in small adhoc networks." To: "Propagation of multicast DNS packets on the local link is considered sufficient to enable DNS name resolution in small adhoc networks." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Dave Thaler Date: 11/1/01 Section affected: 2 Rationale: In various sections in the draft, it is assumed that link == Subnet. In IPv6, with multilink subnets, this may not necessarily be the case. The use of the word "subnet" should therefore be changed to "link" throughout the document. Proposal: Change the following text: "In the future, mDNS may be defined to support greater than LINKLOCAL multicast scope. This would occur if LINKLOCAL mDNS deployment is successful, the assumption that mDNS is not needed in multiple subnets proves incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios." To: "In the future, mDNS may be defined to support greater than LINKLOCAL multicast scope. This would occur if LINKLOCAL mDNS deployment is successful, the assumption that mDNS is not needed on multiple links proves incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Dave Thaler Date: 11/1/01 Section affected: 5.1 Rationale: Distinction between subnet and link needs to be made. Proposal: Change the following text: "If host myhost is configured to use mDNS on both interfaces, it will send mDNS queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different subnet. Therefore it will continue using its name. Indeed, host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists: [A] | | ----- ----- | | [myhost] Figure 3. Multiple paths to same host This illustrates that the proposed name conflict resolution mechanism does not support detection or resolution of conflicts between hosts on different subnets. This problem can also occur with unicast DNS when a multi-homed host is connected to two different networks with separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS." To: "If host myhost is configured to use mDNS on both interfaces, it will send mDNS queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different link. Therefore it will continue using its name. Indeed, host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists: [A] | | ----- ----- | | [myhost] Figure 3. Multiple paths to same host This illustrates that the proposed name conflict resolution mechanism does not support detection or resolution of conflicts between hosts on different links. This problem can also occur with unicast DNS when a multi-homed host is connected to two different networks with separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Bernard Aboba Date: 11/1/01 Section affected: 2 Rationale: It should not be assumed that DHCPv6 will be implemented in IPv6 home networks. It is much more likely that such networks will use stateless autoconfiguration. Scenarios for IPv6 use of mDNS should be more completely described. Proposal: Change the following text: "The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy. By implementing DHCP as well as a DNS proxy and dynamic DNS, routers can provide name resolution for the names of the hosts on the local network. This functionality is easily provided, and so in such cases it is assumed that multicast DNS need not be enabled by default." To: "The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers can provide name resolution for the names of IPv4 hosts on the local network. Where all IPv6 hosts also support IPv4, and the DNS proxy supports AAAA RRs, resolution for the names of IPv6 hosts on the local network can also be provided. For IPv6, stateful autoconfiguration is the most likely mechanism for configuration within small adhoc networks. It is possible that such networks will contain IPv6-only hosts, and that DHCPv6 will not be used. In this case, in order to support resolution for the names of IPv6-only hosts on the local network, the DNS proxy will need to support dynamic client update as well as DNS over IPv6. While DNS proxies do not support dynamic client update today, it is believed that this functionalty is implementable. Since using the above mechanisms it is possible for small networks with a router to enable DNS name resolution, it is assumed that multicast DNS need not be enabled by default." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 2 Rationale: This paragraph is outside the scope of the draft and should be removed. Proposal: Remove the following text: "The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy. By implementing DHCP as well as a DNS proxy and dynamic DNS, routers can provide name resolution for the names of the hosts on the local network. This functionality is easily provided, and so in such cases it is assumed that multicast DNS need not be enabled by default." Recommendation: Discuss -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 2 Rationale: Sentence is redundant Proposal: Remove: "Namely, this extension allows multicast DNS queries to be sent to and received on port 53." Since this is repeated in the next paragraph. Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 2.1.2 Rationale: Clarification required Proposal: Replace: "A response to an mDNS query MUST have RCODE set to zero, since mDNS responders MUST NOT send error replies in response to mDNS queries." With the following: "A response to an mDNS query MUST have RCODE set to zero. mDNS responders may respond only to queries which they can resolve positively." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 3 Rationale: Current text prevents a DNS server from responding to queries for its own name. This restriction can be loosened. Proposal: Change the following text: "If a DNS server is running on a host, the host MUST NOT listen for multicast DNS queries, to prevent the host from listening on port 53 and intercepting DNS queries directed to a DNS server. By default, a DNS server MUST NOT listen to multicast DNS queries." To: "If a DNS server is running on a host, then responder MUST NOT listen for the multicast DNS queries on the same IP addresses on which the DNS server listens, since otherwise they would intercept DNS queries directed to a DNS server. The DNS server MUST respond to the multicast DNS queries only for the RRSets owned by the host on which the server is running, but MUST NOT respond for the records for which the server is authoritative." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 3.1 Rationale: DNS discovery also occurs on a per interface basis, so it is not global as the current text indicates. Proposal: Change the following text: "For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [19] can be used to discover whether multicast DNS is globally enabled or disabled." To: "For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [19] can be used to discover whether multicast DNS should be enabled or disabled." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 2.1.1 Rationale: Description of IPv6 multicast address behavior should be in section 2.1.1 instead of 2.1.2 Proposal: Change the following text: "The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit." To: "The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit. The IPv6 LINKLOCAL address a given responder listens to, and to which a sender sends, is a link-local multicast address formed as follows: The name of the resource record in question is expressed in its canonical form (see RFC 2535 [15], section 8.1), which is uncompressed with all alphabetic characters in lower case. The first label of the resource record name is then hashed using the MD5 algorithm (see RFC 1321 [16]). The first 32 bits of the resultant 128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast address". (Note: this procedure is intended to be the same as that specified in section 3 of "IPv6 Node Information Queries" [14]). A responder that listens for queries for multiple names will necessarily listen to multiple of these solicited name multicast addresses." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 2.1.2 Rationale: If descripton of IPv6 multicast address behavior is in section 2.1.1, it need not also be in section 2.1.2. Proposal: Remove the following text: "The IPv6 LINKLOCAL address a given responder listens to, and to which a sender sends, is a link-local multicast address formed as follows: The name of the resource record in question is expressed in its canonical form (see RFC 2535 [15], section 8.1), which is uncompressed with all alphabetic characters in lower case. The first label of the resource record name is then hashed using the MD5 algorithm (see RFC 1321 [16]). The first 32 bits of the resultant 128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast address". (Note: this procedure is intended to be the same as that specified in section 3 of "IPv6 Node Information Queries" [14]). A responder that listens for queries for multiple names will necessarily listen to multiple of these solicited name multicast addresses." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 5 Rationale: currrent text is too strict with respect to conflicts on alternate interfaces. Proposal: Change the following text: "After the client receives an YXRRSET response to its dynamic update request that a UNIQUE resource record does not exist, the host MUST NOT use the UNIQUE resource record in responses to multicast queries and dynamic update requests." To: "After client receives an YXRRSET response to its dynamic update request that a UNIQUE resource record does not exist, the host MUST check whether the response arrived on another interface. If this is the case, then the client can use the UNIQUE resource record in response to multicast queries and dynamic update requests. If not, then it MUST NOT use the UNIQUE resource record in response to multicast queries and dynamic update requests." Recommendation: Accept -------------------------------------------------------------------------------- Proposer: Levon Esibov Date: 11/1/01 Section affected: 3.1 Rationale: The following paragraph means that mDNS will not work in home environments with an ISP-provided DHCP server unless it is upgraded. Proposal: Delete the following paragraph: "If an interface has been configured for a given protocol via any automatic configuration mechanism which is able to supply DNS configuration information, then multicast DNS SHOULD NOT be used on that interface for that protocol unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the DNS LINKLOCAL multicast address, nor will it send queries to that address." Recommendation: Discuss -------------------------------------------------------------------------------- Proposer: Erik Guttman and Levon Esibov Date: 10/28/01 Section affected: 3 Rationale: The proposed change allows us to completely avoid use of ".local.arpa", aliasing, etc. Note that this suggestion *does* change the search order behavior, by adding a new rule to just try the name. But section 3 of mdns-06 also changes the rules, by requiring the adding of local.arpa suffixes to the search order. Proposal: Replace section 3 text: " Multicast DNS usage is determined by special treatment of the ".local.arpa." namespace. The sender treats queries for ".local.arpa." as a special case. A sender MUST NOT send a unicast query for names ending with the ".local.arpa." suffix except when: a. A sender repeats a query after it received a response to the previous multicast query with the TC bit set, or b. The sender's cache contains an NS resource record that enables the sender to send a query directly to the hosts authoritative for the name in the query. It is not expected that a host named "host.example.com." will be manually configured to have the additional name "host.example.com.local.arpa." when it is configured to use multicast DNS. Instead, a responder with a name "host.example.com." configured with ".local.arpa." suffix in its domain search configuration is authoritative for the name "host.example.com.local.arpa.". For example, when a responder with the name "host.example.com." receives an A type query for the name "host.example.com.local.arpa." it authoritatively responds to the query. The same host MAY use multicast DNS queries for the resolution of names ending with ".local.arpa.", and unicast DNS queries for resolution of all other names. When a user or application requests a DNS client to resolve a dot-terminated name that contains a ".local.arpa" suffix, the query for such a name MUST be multicast and the name SHOULD NOT be concatenated with any suffix." with the following text: A mDNS "sender" MAY multicast requests for any name. If the name to be resolved does not end in a trailing dot, for the purposes of mDNS, the implicit search order is as follows: A. If the name contains at least one dot, then submit the name itself B. For each DNS suffix in the suffix search list submit the name with the current suffix appended. C. If the name contains no dots, then submit just the name. The name resolution process should stop as soon as query is resolved. Recommendation: Discuss -------------------------------------------------------------------------------- Proposer: Dave Thaler Date: 11/1/01 Section affected: 7 Rationale: Removal of references to "local.arpa" Proposal: Delete section 7. Recommendation: Discuss -------------------------------------------------------------------------------- Proposer: Dave Thaler Date: 11/1/01 Section affected: 2.1 Rationale: Removal of references to "local.arpa" Proposal: Change section 2.1 text from: "Responders MUST respond to multicast queries to those and only those names for which they are authoritative. As an example, computer "host.example.com.local.arpa." is authoritative for the domain "host.example.com.local.arpa.". On receiving a multicast DNS A record query for the name "host.example.com.local.arpa." such a host responds with A record(s) that contain IP address(es) in the RDATA of the record. In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, a responder is authoritative only for the zone root. For example the host "host.example.com.local.arpa." is not authoritative for the name "child.host.example.com.local.arpa." unless the host is configured with multiple names, including "host.example.com.local.arpa." and "child.host.example.com.local.arpa.". The purpose of limiting the name authority scope of a responder is to prevent complications that could be caused by coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "host.example.com.local.arpa." and "child.host.example.com.local.arpa.". In this example (unless this limitation is introduced) a multicast query for an A record for the name "child.host.example.com.local.arpa." would result in two authoritative responses: name error received from "host.example.com.local.arpa.", and a requested A record - from "child.host.example.com.local.arpa.". To prevent this ambiguity, multicast enabled hosts could perform a dynamic update of the parent (or grandparent) zone with a delegation to a child zone. In this example a host "child.host.example.com.local.arpa." would send a dynamic update for the NS and glue A record to "host.example.com.local.arpa.", but this approach significantly complicates implementation of multicast DNS and would not be acceptable for lightweight hosts." To: "Responders MUST respond to multicast queries to those and only those names for which they are authoritative. As an example, computer "host.example.com." is authoritative for the domain "host.example.com.". On receiving a multicast DNS A record query for the name "host.example.com." such a host responds with A record(s) that contain IP address(es) in the RDATA of the record. In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, a responder is authoritative only for the zone root. For example the host "host.example.com." is not authoritative for the name "child.host.example.com." unless the host is configured with multiple names, including "host.example.com." and "child.host.example.com.". The purpose of limiting the name authority scope of a responder is to prevent complications that could be caused by coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "host.example.com." and "child.host.example.com.". In this example (unless this limitation is introduced) a multicast query for an A record for the name "child.host.example.com." would result in two authoritative responses: name error received from "host.example.com.", and a requested A record - from "child.host.example.com.". To prevent this ambiguity, multicast enabled hosts could perform a dynamic update of the parent (or grandparent) zone with a delegation to a child zone. In this example a host "child.host.example.com." would send a dynamic update for the NS and glue A record to "host.example.com.", but this approach significantly complicates implementation of multicast DNS and would not be acceptable for lightweight hosts." Recommendation: Discuss -------------------------------------------------------------------------------- Proposer: Dave Thaler Date: 11/1/01 Section affected: 4 Rationale: Removal of references to "local.arpa" Proposal: Change the text of section 4 from: "The sequence of events for multicast DNS usage is as follows: 1. If a sender needs to resolve a query for a name "host.example.com.local.arpa", then it sends a multicast query to the LINKLOCAL multicast address. 2. A responder responds to this query only if it is authoritative for the domain name "host.example.com.local.arpa". The responder sends a response to the sender via unicast over UDP. 3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255. The sender then verifies compliance with the addressing requirements for IPv4, described in [18], and IPv6, described in RFC 2373 [9]. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response." To: "The sequence of events for multicast DNS usage is as follows: 1. If a sender needs to resolve a query for a name "host.example.com", then it sends a multicast query to the LINKLOCAL multicast address. 2. A responder responds to this query only if it is authoritative for the domain name "host.example.com". The responder sends a response to the sender via unicast over UDP. 3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255. The sender then verifies compliance with the addressing requirements for IPv4, described in [18], and IPv6, described in RFC 2373 [9]. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response." Recommendation: Discuss -------------------------------------------------------------------------------- Proposer: Dave Thaler Date: 11/1/01 Section affected: 2.1.1 Rationale: Removal of "local.arpa" references Change: "A sender sends multicast DNS query for any legal Type of resource record (e.g. A, PTR, etc.) for a name within the ".local.arpa." domain to the LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit." To: "A sender sends multicast DNS query for any legal Type of resource record (e.g. A, PTR, etc.) to the LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit. -------------------------------------------------------------------------------- Proposer: Dave Thaler Date: 11/1/01 Section affected: 9 Rationale: Removal of "local.arpa" references Change: "The mechanism specified in this draft does not require use of DNSSEC. As a result, responses to multicast DNS queries MAY NOT be authenticated. If a network contains a "signed key distribution center" for some of the DNS zones that the responders are authoritative for, and senders on that network are configured with the key for the top zone "local.arpa." (hosted by "signed keys distribution center"), then senders MAY authenticate the responses using DNSSEC." To: "The mechanism specified in this draft does not require use of DNSSEC. As a result, responses to multicast DNS queries MAY NOT be authenticated. If a network contains a "signed key distribution center" for some of the DNS zones that the responders are authoritative for, and senders on that network are configured with the key for the top zone hosted by "signed keys distribution center", then senders MAY authenticate the responses using DNSSEC." Recommendation: Discuss -------------------------------------------------------------------------------- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 13 13:57:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12480 for ; Tue, 13 Nov 2001 13:57:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163hcc-0002Z2-00 for namedroppers-data@psg.com; Tue, 13 Nov 2001 09:45:18 -0800 Received: from dhcp38-242.meeting.icann.org ([192.0.38.242] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 163hcb-0002Yw-00 for namedroppers@ops.ietf.org; Tue, 13 Nov 2001 09:45:17 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 163hcb-0000dS-00 for namedroppers@ops.ietf.org; Tue, 13 Nov 2001 09:45:17 -0800 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6EEFC02@vsvapostal3.prod.netsol.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Larson, Matt" To: namedroppers@ops.ietf.org Subject: FW: I-D ACTION:draft-larson-bad-dns-res-00.txt Date: Tue, 13 Nov 2001 10:59:58 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments solicited and gratefully received... -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, November 13, 2001 7:08 AM To: IETF-Announce; @loki.ietf.org Subject: I-D ACTION:draft-larson-bad-dns-res-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Observed DNS Resolution Misbehavior Author(s) : P. Barber, J. Brady, M. Larson Filename : draft-larson-bad-dns-res-00.txt Pages : 14 Date : 12-Nov-01 This Internet-Draft describes DNS name server and stub resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. In some cases we recommend minor additions to the DNS protocol specification and corresponding changes in name server implementations to alleviate these unnecessary queries. In one case, we have highlighted behavior of a popular name server implementation that does not conform to the DNS specification. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net/org TLD name servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-larson-bad-dns-res-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-larson-bad-dns-res-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-larson-bad-dns-res-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 14 10:10:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27141 for ; Wed, 14 Nov 2001 10:10:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1641Ef-0007pL-00 for namedroppers-data@psg.com; Wed, 14 Nov 2001 06:41:53 -0800 Received: from dhcp38-242.meeting.icann.org ([192.0.38.242] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 1641Ef-0007pE-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 06:41:53 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 1641EY-0001Di-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 06:41:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD6EEFC02@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD6EEFC02@vsvapostal3.prod.netsol.com> Message-ID: <2181.1005725495@brandenburg.cs.mu.OZ.AU> From: Robert Elz To: "Larson, Matt" cc: namedroppers@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-larson-bad-dns-res-00.txt Date: Wed, 14 Nov 2001 15:11:35 +0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Most of the draft looks good to me, I have a concern over just one part of it ... For this query of the parent zone to be useful, the target zone's entire set of name servers would have to change AND the former set of name servers would have to be deconfigured and/or decomissioned AND the delegation information in the parent zone would have to be updated with the new set of name servers, all within the TTL of the target zone's NS RRset. We believe this scenario is uncommon: Unfortunately, not, though it doesn't happen quite as set out there. The usual happening is for the old servers to vanish first (possibly carted away on a truck when their owner went bust). Then the domain owner gets some new servers, and has them configured (to this point the parent is still replying with the old defunct servers with full TTL - a day or two). The domain then updates its delegation (which is reflected by the parent, which goes in an instant from the old NS set with full TTL to the new NS set with full TTL) Then we have exactly the scenario where the query of the parent domain is useful - instead of waiting for the TTL to expire before the new servers are visible, they are found as soon as (near enough) there's a query after the delegation has changed. That has the effect of getting the domain back working again as quickly as is possible - which is exactly what the domain owner needs after their previous host has vanished. Prohibiting this will only have the effect of the end users demanding that the TTLs in the parent zones be reduced from something measured in days, to something measured in hours (at most), so they're effectively disconnected by circumstances outside their control for the smallest time possible. This "cure" might be worse than the disease. So, I'd suggest that instead of prohibiting this extra lookup, it would be better to simply scale it better - require that it not be repeated within an hour of a previous lookup. That's short enough that dead domains can be resurrected quickly, yet long enough that it should provide some respite for the servers. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 14 11:43:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02679 for ; Wed, 14 Nov 2001 11:43:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1642t5-000Coz-00 for namedroppers-data@psg.com; Wed, 14 Nov 2001 08:27:43 -0800 Received: from dhcp38-242.meeting.icann.org ([192.0.38.242] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 1642t4-000Cor-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 08:27:43 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 1642oN-0001KL-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 08:22:51 -0800 Message-Id: <200111132357.fADNvM824732@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Mon, 12 Nov 2001 12:32:58 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII To: design@lists.freeswan.org, namedroppers@ops.ietf.org, ipsec@lists.tislabs.com cc: Simon Josefsson Subject: Re: draft-richardson-ipsec-opportunistic-02.txt Date: Tue, 13 Nov 2001 18:57:22 -0500 From: Michael Richardson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Guys, I'm reposting to the design list and namedroppers, if for no other reason than for a record... The movie so far: 1) Simon emailed Henry, DHR and I about our use of TXT and KEY. 2) Michael responded, saying that we use KEY to store raw RSA keys for the endpoints. We use TXT records (see the draft) to provide authorization of delegation from end-nodes to gateways (and to discover the gateways) 3) Henry has responded, with the text below, which I'm quoting. 4) A large Aladdin-type Genie, but with Bruce Schneier's voice, pops out, and solves the global-PKI problem. >>>>> "Henry" == Henry Spencer >>>>> "Simon" == Simon Josefsson Simon> Ok -- right now the trends within the DNSEXT group seems to be that Simon> KEY should only be used for DNSSEC internal purposes as well, and to Simon> have some other RR for application related purposes. (The DNSSEC Simon> specs are being revised.) Henry> As Michael said, we're already using KEY for the purposes endorsed in RFC Henry> 2535. Changing that will involve some difficulties, because of the need Henry> to get support for an alternative record into BIND etc., but it could be Henry> done if necessary, sigh. Simon, your above statement suggests to me that you don't want us to use KEY to identify host info at all. Is there a document that explains this in detail? KEY seems to have lots of bits designed to distinguish different uses. We could certainly use two kinds of CERT record - one for the raw RSA host key, and the second for delegation authorization. The second one is discussed below: Simon> I have intended to write a draft that says CERT RRs should be regarded Simon> as containing "application security related information". Requiring Simon> that CERT must contained signed data is irrelevant from a DNS point of Simon> view... Henry> Indeed so. Relax *that* requirement -- which could be read as an accident Henry> of wording rather than a matter of fundamental intent -- and CERT would be Henry> a good match for our needs. I think that we are in agreement. I didn't take the "signed" part of the note too heavily anyway. Simon> With your permission, I'd like to include your IPSEC usage as a Simon> example of what the CERT RR could have as sub-types... Henry> Yes, by all means, go ahead. As Michael noted, there are two or three Henry> variations involved (IPv4 address, IPv6 address, DNS name), but that's Henry> a secondary issue if it's being used purely as an example. Simon> You would need to write the CERT sub-type registration yourself, if you Simon> think CERT RR's is a good idea. What do you think? I think that this would be appropriate for a "Opportunistic Encryption version 2" specification. We believe that there are a number of things unrelated to the syntax used to store the keys that need to be solved first. Our solution, while in-elegant is functionally identical to one that had CERT RRs instead. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO/GzXYqHRg3pndX9AQESNwQAp1yZ71ETFaJMWRFiPUfFQ03ynEtF+NG4 QVo/i21MXDDcAcx1qwST/Saa6gCTO1HCipTwCVi+Whi/wCFv+gAOySIvC4Ge6s23 CmhzhyKi8YNlSQNPlXs52RjGKhJNlokTilY69LPGdC6GHJFME8UeaTev52KzeuYQ 28ecYXHPfd0= =YQkQ -----END PGP SIGNATURE----- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 14 12:36:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06138 for ; Wed, 14 Nov 2001 12:36:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1643n5-000FmR-00 for namedroppers-data@psg.com; Wed, 14 Nov 2001 09:25:35 -0800 Received: from dhcp38-242.meeting.icann.org ([192.0.38.242] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 1643n3-000FmI-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 09:25:34 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 1643n1-0001Pt-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 09:25:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <019d01c16d30$1eeb9d20$e32600c0@jamessonyvaio> From: "James Seng/Personal" To: Subject: Fw: DNSSEC (RE: Software for PKI) Date: Thu, 15 Nov 2001 01:16:20 +0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric Rescorla" To: Cc: "Anders Rundgren" ; ; ; Sent: Friday, November 09, 2001 11:58 PM Subject: Re: DNSSEC (RE: Software for PKI) > > lynn.wheeler@firstdata.com writes: > > 5) In a DNSSEC world, browser could obtain a valid ip-address and public > > key in the same DNS transaction. By definition, the ip-address is trusted > > (so the issue of domain name to ip-address translation is eliminated). > > Also, by definition the public key for that "domain name/ip-address/public > > key" tuble is trusted. Majority of the protocol setup chatter in the > > existingf SSL is eliminated ... since there is real-time trusted key > > distribution (as part of real-time trusted ip-address distribution). So the > > only real SSL setup step that is left is the validaty of some signed > > something from the server. > Actually, very little of the SSL protocol overhead is concerned with > certificate issues. Most of it is concerned with ciphersuite negotiation, > key exchange and handshake verification, none of which would be > affected significantly by DNSSEC. > > The typical SSL handshake is: > > C: ClientHello (ciphersuites, random, session id) > S: ServerHello (ciphersuite selection, random, session id) > S: Certificate > S: ServerHelloDone > C: ClientKeyExchange > C: ChangeCipherSpec > C: Finished > S: ChangeCipherSpec > S: Finished > > In a hypothetical world in which we had DNSSEC we'd be able to eliminate > exactly one of these messages, the server Certificate. > > I agree that a world with DNSSEC would be potentially more secure than > the current world of SSL certificates, but it wouldn't make SSL > much simpler. > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 14 15:02:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14208 for ; Wed, 14 Nov 2001 15:02:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1645sO-000N54-00 for namedroppers-data@psg.com; Wed, 14 Nov 2001 11:39:12 -0800 Received: from dhcp38-242.meeting.icann.org ([192.0.38.242] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 1645sO-000N4y-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 11:39:12 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 1645sD-0001Z8-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 11:39:01 -0800 In-Reply-To: <019d01c16d30$1eeb9d20$e32600c0@jamessonyvaio> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 14 Nov 2001 11:26:47 -0800 (PST) From: Brian Wellington To: James Seng/Personal cc: Subject: Re: Fw: DNSSEC (RE: Software for PKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (If anyone wants to forward this to the original sender, go ahead. I'm not going anywhere near a PKIX mailing list) On Thu, 15 Nov 2001, James Seng/Personal wrote: > ----- Original Message ----- > From: "Eric Rescorla" > To: > Cc: "Anders Rundgren" ; ; > ; > Sent: Friday, November 09, 2001 11:58 PM > Subject: Re: DNSSEC (RE: Software for PKI) > > > > > > lynn.wheeler@firstdata.com writes: > > > 5) In a DNSSEC world, browser could obtain a valid ip-address and > public > > > key in the same DNS transaction. Not true. There is no good way of obtaining records of multiple DNS types in a single transaction. ANY queries don't always work correctly. While a KEY record will often be returned in the additional section of an A query, it is the key for the zone, not the host. > > > By definition, the ip-address is trusted > > > (so the issue of domain name to ip-address translation is eliminated). True, but there's still the issue about whether the SSL connection is to the correct machine. > > > Also, by definition the public key for that "domain name/ip-address/public > > > key" tuble is trusted. Yes, although an additional DNS query is needed to get the public key. > > > Majority of the protocol setup chatter in the > > > existingf SSL is eliminated ... since there is real-time trusted key > > > distribution (as part of real-time trusted ip-address distribution). So the > > > only real SSL setup step that is left is the validaty of some signed > > > something from the server. I don't think this will really help anything all that much. It just moves a bit of work from the SSL client into the DNS client. The same amount of work still needs to be done. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Nov 14 16:28:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17331 for ; Wed, 14 Nov 2001 16:28:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1647Jg-0001mm-00 for namedroppers-data@psg.com; Wed, 14 Nov 2001 13:11:28 -0800 Received: from dhcp38-242.meeting.icann.org ([192.0.38.242] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 1647Jf-0001lR-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 13:11:27 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 1647JX-0001eh-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 13:11:19 -0800 Message-ID: <00ce01c16d4a$769d1ca0$b9370681@antd.nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Scott Rose" To: "DNSEXT WG Mailing list" , "dougm" , Subject: first results from DNSSEC testbed Date: Wed, 14 Nov 2001 15:25:12 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The first series of DNSSEC test results are done and put up on the NIST DNSSEC project webpage: http://www.antd.nist.gov/proj/dnssec/results.html The tests that were performed were a "day in the life" of our DNS server (antd.nist.gov domain answering both local and external traffic). With the zone signed and the use of EDNS being the only differences. TSIGs were also used for another set of experiments to see the impact of digest creation/verification on performance. The results are pretty much to be expected from the test runs, and a 500 Mhz PIII had no problem running BIND 9.2.0rcX. The page is still pretty raw, and there are comparison traffic tests using DSA keys/sigs (the current numbers are using a 2048 RSA key). If there are any questions on improving the reporting/stat taking - let me know Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.antd.nist.gov =============================================================== to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 15 00:32:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28632 for ; Thu, 15 Nov 2001 00:32:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164Epd-000NmL-00 for namedroppers-data@psg.com; Wed, 14 Nov 2001 21:12:57 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 164Epd-000NmF-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 21:12:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 164Epc-0000nK-00 for namedroppers@ops.ietf.org; Wed, 14 Nov 2001 21:12:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011114142440.0235a6b0@dcrocker.net> In-Reply-To: <00ce01c16d4a$769d1ca0$b9370681@antd.nist.gov> Date: Wed, 14 Nov 2001 14:25:48 -0800 To: "Scott Rose" From: Dave Crocker Subject: Re: first results from DNSSEC testbed Cc: "DNSEXT WG Mailing list" , "dougm" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 03:25 PM 11/14/2001 -0500, Scott Rose wrote: >The first series of DNSSEC test results are done and put up on the NIST >DNSSEC project webpage: given that IETF working group lists limit their involvement in actual interoperability testing -- in fact limiting the involvement to just the kind of notice you sent -- is there a separate mailing list to assist coordination of dnssec testing and deployment? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 15 09:43:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25731 for ; Thu, 15 Nov 2001 09:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164NOp-000LKt-00 for namedroppers-data@psg.com; Thu, 15 Nov 2001 06:21:51 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 164NOo-000LKn-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 06:21:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 164NOo-000F7n-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 06:21:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <5.1.0.14.2.20011114142440.0235a6b0@dcrocker.net> Message-ID: Date: Thu, 15 Nov 2001 08:33:25 +0100 (MET) From: Jakob Schlyter To: Dave Crocker Cc: Scott Rose , DNSEXT WG Mailing list , dougm , Subject: Re: first results from DNSSEC testbed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 14 Nov 2001, Dave Crocker wrote: > given that IETF working group lists limit their involvement in actual > interoperability testing -- in fact limiting the involvement to just the > kind of notice you sent -- is there a separate mailing list to assist > coordination of dnssec testing and deployment? dnssec@cafax.se (handled by majordomo@cafax.se). jakob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 15 09:58:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26419 for ; Thu, 15 Nov 2001 09:58:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164NnR-000MRh-00 for namedroppers-data@psg.com; Thu, 15 Nov 2001 06:47:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 164NnR-000MRb-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 06:47:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 164NnR-000Fni-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 06:47:17 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft-ietf-ngtrans-6to4-dns-00.txt Message-Id: Date: Thu, 15 Nov 2001 06:47:17 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ngtrans folk suggest that this draft should be reviewed by dnsext. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 15 14:17:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13043 for ; Thu, 15 Nov 2001 14:17:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164Rn9-0005OJ-00 for namedroppers-data@psg.com; Thu, 15 Nov 2001 11:03:15 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 164Rn9-0005OD-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 11:03:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 164Rn9-000Mt9-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 11:03:15 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft-hall-dm-idns-00.txt Message-Id: Date: Thu, 15 Nov 2001 11:03:15 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i suspect that dnsext folk might want to look at draft-hall-dm-idns-00.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 15 19:51:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00220 for ; Thu, 15 Nov 2001 19:51:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164Wg8-000Bjb-00 for namedroppers-data@psg.com; Thu, 15 Nov 2001 16:16:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 164Wg7-000BjU-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 16:16:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 164Wg7-0005GT-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 16:16:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1616554169-1005867401=:73304" Date: Thu, 15 Nov 2001 15:36:41 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: SECOND REQUEST for discussion of proposed changes to mdns-06 draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1616554169-1005867401=:73304 Content-Type: TEXT/PLAIN; charset=US-ASCII Find enclosed the proposed changes to the mdns-06 draft, along with a copy of the draft containing all the changes with a proposed resolution of "accept". The term "change made" refers to changes incorporated into this early -07 draft. If there are objections to the proposed changes resolved "accept" or "discuss", please speak up now. Otherwise, these changes will be incorporated by the 11/21/01 draft submission deadline. Proposed changes to mdns-06 =========================== Change #06-1 Proposer: Dave Thaler Date: 11/1/01 Section affected: 2 Rationale: In various sections in the draft, it is assumed that link == Subnet. In IPv6, with multilink subnets, this may not necessarily be the case. The use of the word "subnet" should therefore be changed to "link" throughout the document. Proposal: Change the following text: "Propagation of multicast DNS packets within the local subnet is considered sufficient to enable DNS name resolution in small adhoc networks." To: "Propagation of multicast DNS packets on the local link is considered sufficient to enable DNS name resolution in small adhoc networks." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-2 Proposer: Dave Thaler Date: 11/1/01 Section affected: 2 Rationale: In various sections in the draft, it is assumed that link == Subnet. In IPv6, with multilink subnets, this may not necessarily be the case. The use of the word "subnet" should therefore be changed to "link" throughout the document. Proposal: Change the following text: "In the future, mDNS may be defined to support greater than LINKLOCAL multicast scope. This would occur if LINKLOCAL mDNS deployment is successful, the assumption that mDNS is not needed in multiple subnets proves incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios." To: "In the future, mDNS may be defined to support greater than LINKLOCAL multicast scope. This would occur if LINKLOCAL mDNS deployment is successful, the assumption that mDNS is not needed on multiple links proves incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-3 Proposer: Dave Thaler Date: 11/1/01 Section affected: 5.1 Rationale: Distinction between subnet and link needs to be made. Proposal: Change the following text: "If host myhost is configured to use mDNS on both interfaces, it will send mDNS queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different subnet. Therefore it will continue using its name. Indeed, host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists: [A] | | ----- ----- | | [myhost] Figure 3. Multiple paths to same host This illustrates that the proposed name conflict resolution mechanism does not support detection or resolution of conflicts between hosts on different subnets. This problem can also occur with unicast DNS when a multi-homed host is connected to two different networks with separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS." To: "If host myhost is configured to use mDNS on both interfaces, it will send mDNS queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different link. Therefore it will continue using its name. Indeed, host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists: [A] | | ----- ----- | | [myhost] Figure 3. Multiple paths to same host This illustrates that the proposed name conflict resolution mechanism does not support detection or resolution of conflicts between hosts on different links. This problem can also occur with unicast DNS when a multi-homed host is connected to two different networks with separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-4 Proposer: Bernard Aboba Date: 11/1/01 Section affected: 2 Rationale: It should not be assumed that DHCPv6 will be implemented in IPv6 home networks. It is much more likely that such networks will use stateless autoconfiguration. Scenarios for IPv6 use of mDNS should be more completely described. Proposal: Change the following text: "The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy. By implementing DHCP as well as a DNS proxy and dynamic DNS, routers can provide name resolution for the names of the hosts on the local network. This functionality is easily provided, and so in such cases it is assumed that multicast DNS need not be enabled by default." To: "The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers can provide name resolution for the names of IPv4 hosts on the local network. Where all IPv6 hosts also support IPv4, and the DNS proxy supports AAAA RRs, resolution for the names of dual stack IPv6 hosts on the local network can also be provided using this mechanism. Within small adhoc IPv6 networks, stateful autoconfiguration is the most likely configuration mechanism. If DHCPv6 is not present, then in order to support resolution of names of IPv6-only hosts on the local network, the DNS proxy will need to support dynamic client update as well as DNS over IPv6. Given the above mechanisms enabling DNS name resolution in small networks with a router, it is assumed that multicast DNS need not be enabled by default." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-5 Proposer: Levon Esibov Date: 11/1/01 Section affected: 2 Rationale: This paragraph is outside the scope of the draft and should be removed. Proposal: Remove the following text: "The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy. By implementing DHCP as well as a DNS proxy and dynamic DNS, routers can provide name resolution for the names of the hosts on the local network. This functionality is easily provided, and so in such cases it is assumed that multicast DNS need not be enabled by default." Recommendation: Discuss -------------------------------------------------------------------------------- Change #06-6 Proposer: Levon Esibov Date: 11/1/01 Section affected: 2 Rationale: Sentence is redundant Proposal: Remove: "Namely, this extension allows multicast DNS queries to be sent to and received on port 53." Since this is repeated in the next paragraph. Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-7 Proposer: Levon Esibov Date: 11/1/01 Section affected: 2.1.2 Rationale: Clarification required Proposal: Replace: "A response to an mDNS query MUST have RCODE set to zero, since mDNS responders MUST NOT send error replies in response to mDNS queries." With the following: "A response to an mDNS query MUST have RCODE set to zero. mDNS responders may respond only to queries which they can resolve positively." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-8 Proposer: Levon Esibov Date: 11/1/01 Section affected: 3 Rationale: Current text prevents a DNS server from responding to queries for its own name. This restriction can be loosened. Proposal: Change the following text: "If a DNS server is running on a host, the host MUST NOT listen for multicast DNS queries, to prevent the host from listening on port 53 and intercepting DNS queries directed to a DNS server. By default, a DNS server MUST NOT listen to multicast DNS queries." To: "If a DNS server is running on a host, then responder MUST NOT listen for the multicast DNS queries on the same IP addresses on which the DNS server listens, since otherwise they would intercept DNS queries directed to a DNS server. The DNS server MUST respond to the multicast DNS queries only for the RRSets owned by the host on which the server is running, but MUST NOT respond for the records for which the server is authoritative." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-9 Proposer: Levon Esibov Date: 11/1/01 Section affected: 3.1 Rationale: DNS discovery also occurs on a per interface basis, so it is not global as the current text indicates. Proposal: Change the following text: "For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [19] can be used to discover whether multicast DNS is globally enabled or disabled." To: "For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [19] can be used to discover whether multicast DNS should be enabled or disabled on a per-interface basis." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-10 Proposer: Levon Esibov Date: 11/1/01 Section affected: 2.1.1 Rationale: Description of IPv6 multicast address behavior should be in section 2.1.1 instead of 2.1.2 Proposal: Change the following text: "The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit." To: "The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit. The IPv6 LINKLOCAL address a given responder listens to, and to which a sender sends, is a link-local multicast address formed as follows: The name of the resource record in question is expressed in its canonical form (see RFC 2535 [15], section 8.1), which is uncompressed with all alphabetic characters in lower case. The first label of the resource record name is then hashed using the MD5 algorithm (see RFC 1321 [16]). The first 32 bits of the resultant 128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast address". (Note: this procedure is intended to be the same as that specified in section 3 of "IPv6 Node Information Queries" [14]). A responder that listens for queries for multiple names will necessarily listen to multiple of these solicited name multicast addresses." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-11 Proposer: Levon Esibov Date: 11/1/01 Section affected: 2.1.2 Rationale: If descripton of IPv6 multicast address behavior is in section 2.1.1, it need not also be in section 2.1.2. Proposal: Remove the following text: "The IPv6 LINKLOCAL address a given responder listens to, and to which a sender sends, is a link-local multicast address formed as follows: The name of the resource record in question is expressed in its canonical form (see RFC 2535 [15], section 8.1), which is uncompressed with all alphabetic characters in lower case. The first label of the resource record name is then hashed using the MD5 algorithm (see RFC 1321 [16]). The first 32 bits of the resultant 128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast address". (Note: this procedure is intended to be the same as that specified in section 3 of "IPv6 Node Information Queries" [14]). A responder that listens for queries for multiple names will necessarily listen to multiple of these solicited name multicast addresses." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-12 Proposer: Levon Esibov Date: 11/1/01 Section affected: 5 Rationale: currrent text is too strict with respect to conflicts on alternate interfaces. Proposal: Change the following text: "After the client receives an YXRRSET response to its dynamic update request that a UNIQUE resource record does not exist, the host MUST NOT use the UNIQUE resource record in responses to multicast queries and dynamic update requests." To: "After client receives an YXRRSET response to its dynamic update request that a UNIQUE resource record does not exist, the host MUST check whether the response arrived on another interface. If this is the case, then the client can use the UNIQUE resource record in response to multicast queries and dynamic update requests. If not, then it MUST NOT use the UNIQUE resource record in response to multicast queries and dynamic update requests." Recommendation: Accept Change made. -------------------------------------------------------------------------------- Change #06-13 Proposer: Levon Esibov Date: 11/1/01 Section affected: 3.1 Rationale: The following paragraph means that mDNS will not work in home environments with an ISP-provided DHCP server unless it is upgraded. Proposal: Delete the following paragraph: "If an interface has been configured for a given protocol via any automatic configuration mechanism which is able to supply DNS configuration information, then multicast DNS SHOULD NOT be used on that interface for that protocol unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the DNS LINKLOCAL multicast address, nor will it send queries to that address." Recommendation: Discuss -------------------------------------------------------------------------------- Change #06-14 Proposer: Erik Guttman and Levon Esibov Date: 10/28/01 Section affected: 3 Rationale: The proposed change allows us to completely avoid use of ".local.arpa", aliasing, etc. Note that this suggestion *does* change the search order behavior, by adding a new rule to just try the name. But section 3 of mdns-06 also changes the rules, by requiring the adding of local.arpa suffixes to the search order. Proposal: Replace section 3 text: " Multicast DNS usage is determined by special treatment of the ".local.arpa." namespace. The sender treats queries for ".local.arpa." as a special case. A sender MUST NOT send a unicast query for names ending with the ".local.arpa." suffix except when: a. A sender repeats a query after it received a response to the previous multicast query with the TC bit set, or b. The sender's cache contains an NS resource record that enables the sender to send a query directly to the hosts authoritative for the name in the query. It is not expected that a host named "host.example.com." will be manually configured to have the additional name "host.example.com.local.arpa." when it is configured to use multicast DNS. Instead, a responder with a name "host.example.com." configured with ".local.arpa." suffix in its domain search configuration is authoritative for the name "host.example.com.local.arpa.". For example, when a responder with the name "host.example.com." receives an A type query for the name "host.example.com.local.arpa." it authoritatively responds to the query. The same host MAY use multicast DNS queries for the resolution of names ending with ".local.arpa.", and unicast DNS queries for resolution of all other names. When a user or application requests a DNS client to resolve a dot-terminated name that contains a ".local.arpa" suffix, the query for such a name MUST be multicast and the name SHOULD NOT be concatenated with any suffix." with the following text: A mDNS "sender" MAY multicast requests for any name. If the name to be resolved does not end in a trailing dot, for the purposes of mDNS, the implicit search order is as follows: A. If the name contains at least one dot, then submit the name itself B. For each DNS suffix in the suffix search list submit the name with the current suffix appended. C. If the name contains no dots, then submit just the name. The name resolution process should stop as soon as query is resolved. Recommendation: Discuss -------------------------------------------------------------------------------- Change #06-15 Proposer: Dave Thaler Date: 11/1/01 Section affected: 7 Rationale: Removal of references to "local.arpa" Proposal: Delete section 7. Recommendation: Discuss -------------------------------------------------------------------------------- Change #06-16 Proposer: Dave Thaler Date: 11/1/01 Section affected: 2.1 Rationale: Removal of references to "local.arpa" Proposal: Change section 2.1 text from: "Responders MUST respond to multicast queries to those and only those names for which they are authoritative. As an example, computer "host.example.com.local.arpa." is authoritative for the domain "host.example.com.local.arpa.". On receiving a multicast DNS A record query for the name "host.example.com.local.arpa." such a host responds with A record(s) that contain IP address(es) in the RDATA of the record. In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, a responder is authoritative only for the zone root. For example the host "host.example.com.local.arpa." is not authoritative for the name "child.host.example.com.local.arpa." unless the host is configured with multiple names, including "host.example.com.local.arpa." and "child.host.example.com.local.arpa.". The purpose of limiting the name authority scope of a responder is to prevent complications that could be caused by coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "host.example.com.local.arpa." and "child.host.example.com.local.arpa.". In this example (unless this limitation is introduced) a multicast query for an A record for the name "child.host.example.com.local.arpa." would result in two authoritative responses: name error received from "host.example.com.local.arpa.", and a requested A record - from "child.host.example.com.local.arpa.". To prevent this ambiguity, multicast enabled hosts could perform a dynamic update of the parent (or grandparent) zone with a delegation to a child zone. In this example a host "child.host.example.com.local.arpa." would send a dynamic update for the NS and glue A record to "host.example.com.local.arpa.", but this approach significantly complicates implementation of multicast DNS and would not be acceptable for lightweight hosts." To: "Responders MUST respond to multicast queries to those and only those names for which they are authoritative. As an example, computer "host.example.com." is authoritative for the domain "host.example.com.". On receiving a multicast DNS A record query for the name "host.example.com." such a host responds with A record(s) that contain IP address(es) in the RDATA of the record. In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, a responder is authoritative only for the zone root. For example the host "host.example.com." is not authoritative for the name "child.host.example.com." unless the host is configured with multiple names, including "host.example.com." and "child.host.example.com.". The purpose of limiting the name authority scope of a responder is to prevent complications that could be caused by coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "host.example.com." and "child.host.example.com.". In this example (unless this limitation is introduced) a multicast query for an A record for the name "child.host.example.com." would result in two authoritative responses: name error received from "host.example.com.", and a requested A record - from "child.host.example.com.". To prevent this ambiguity, multicast enabled hosts could perform a dynamic update of the parent (or grandparent) zone with a delegation to a child zone. In this example a host "child.host.example.com." would send a dynamic update for the NS and glue A record to "host.example.com.", but this approach significantly complicates implementation of multicast DNS and would not be acceptable for lightweight hosts." Proposed resolution: Discuss -------------------------------------------------------------------------------- Change #06-17 Proposer: Dave Thaler Date: 11/1/01 Section affected: 4 Rationale: Removal of references to "local.arpa" Proposal: Change the text of section 4 from: "The sequence of events for multicast DNS usage is as follows: 1. If a sender needs to resolve a query for a name "host.example.com.local.arpa", then it sends a multicast query to the LINKLOCAL multicast address. 2. A responder responds to this query only if it is authoritative for the domain name "host.example.com.local.arpa". The responder sends a response to the sender via unicast over UDP. 3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255. The sender then verifies compliance with the addressing requirements for IPv4, described in [18], and IPv6, described in RFC 2373 [9]. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response." To: "The sequence of events for multicast DNS usage is as follows: 1. If a sender needs to resolve a query for a name "host.example.com", then it sends a multicast query to the LINKLOCAL multicast address. 2. A responder responds to this query only if it is authoritative for the domain name "host.example.com". The responder sends a response to the sender via unicast over UDP. 3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255. The sender then verifies compliance with the addressing requirements for IPv4, described in [18], and IPv6, described in RFC 2373 [9]. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response." Proposed resolution: Discuss -------------------------------------------------------------------------------- Change #06-18 Proposer: Dave Thaler Date: 11/1/01 Section affected: 2.1.1 Rationale: Removal of "local.arpa" references Change: "A sender sends multicast DNS query for any legal Type of resource record (e.g. A, PTR, etc.) for a name within the ".local.arpa." domain to the LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit." To: "A sender sends multicast DNS query for any legal Type of resource record (e.g. A, PTR, etc.) to the LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit. Proposed resolution: Discuss -------------------------------------------------------------------------------- Change #06-19 Proposer: Dave Thaler Date: 11/1/01 Section affected: 9 Rationale: Removal of "local.arpa" references Change: "The mechanism specified in this draft does not require use of DNSSEC. As a result, responses to multicast DNS queries MAY NOT be authenticated. If a network contains a "signed key distribution center" for some of the DNS zones that the responders are authoritative for, and senders on that network are configured with the key for the top zone "local.arpa." (hosted by "signed keys distribution center"), then senders MAY authenticate the responses using DNSSEC." To: "The mechanism specified in this draft does not require use of DNSSEC. As a result, responses to multicast DNS queries MAY NOT be authenticated. If a network contains a "signed key distribution center" for some of the DNS zones that the responders are authoritative for, and senders on that network are configured with the key for the top zone hosted by "signed keys distribution center", then senders MAY authenticate the responses using DNSSEC." Proposed resolution: Discuss -------------------------------------------------------------------------------- --0-1616554169-1005867401=:73304 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-dnsext-mdns-07.txt" Content-ID: Content-Description: mdns-06 draft with changes resolved Accept included Content-Disposition: attachment; filename="draft-ietf-dnsext-mdns-07.txt" Content-Transfer-Encoding: BASE64 DQoNCg0KDQoNCg0KRE5TRVhUIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTGV2b24gRXNpYm92DQpJTlRF Uk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEJlcm5hcmQgQWJvYmENCkNhdGVnb3J5OiBTdGFuZGFyZHMg VHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEYXZl IFRoYWxlcg0KPGRyYWZ0LWlldGYtZG5zZXh0LW1kbnMtMDcudHh0PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0DQoxNSBOb3Zl bWJlciAyMDAxDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBN dWx0aWNhc3QgRE5TDQoNClRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQt RHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCBhbGwNCnBy b3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMgMjAyNi4NCg0KSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJu ZXQgRW5naW5lZXJpbmcgVGFzaw0KRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMs IGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3Jv dXBzDQptYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LSBEcmFmdHMuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cw0KYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCnRpbWUuICBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl IG1hdGVyaWFsDQpvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcy4iDQoNClRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KaHR0cDovL3d3dy5pZXRm Lm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNClRoZSBsaXN0IG9mIElu dGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCkNv cHlyaWdodCBOb3RpY2UNCg0KQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwMSkuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0 cmFjdA0KDQpUb2RheSwgd2l0aCB0aGUgcmlzZSBvZiBob21lIG5ldHdvcmtp bmcsIHRoZXJlIGFyZSBhbiBpbmNyZWFzaW5nIG51bWJlcg0Kb2YgYWQtaG9j IG5ldHdvcmtzIG9wZXJhdGluZyB3aXRob3V0IGEgRE5TIHNlcnZlci4gSW4g b3JkZXIgdG8gYWxsb3cgRE5TDQpuYW1lIHJlc29sdXRpb24gaW4gc3VjaCBl bnZpcm9ubWVudHMsIHRoZSB1c2Ugb2YgYSBtdWx0aWNhc3QgRE5TIGlzDQpw cm9wb3NlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpFc2lib3Ys IEFib2JhICYgVGhhbGVyICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0NCg0KDQoNCg0KDQpJTlRFUk5FVC1EUkFG VCAgICAgICAgICAgICAgIE11bHRpY2FzdCBETlMgICAgICAgICAgICAgIDE1 IE5vdmVtYmVyIDIwMDENCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQoxLiAg ICAgSW50cm9kdWN0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiAgICAzDQoyLiAgICAgTmFtZSByZXNvbHV0aW9uIHVz aW5nIG11bHRpY2FzdCBETlMgLi4uLi4uLi4uLi4uLi4uLi4uLiAgICAzDQog ICAyLjEgICAgICAgQmVoYXZpb3Igb2YgdGhlIHNlbmRlciBhbmQgcmVzcG9u ZGVyIC4uLi4uLi4uLi4uLiAgICA0DQozLiAgICAgVXNhZ2UgbW9kZWwgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgICA3 DQogICAzLjEgICAgICAgbUROUyBjb25maWd1cmF0aW9uIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLiAgICA4DQo0LiAgICAgU2VxdWVuY2Ugb2Yg ZXZlbnRzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAg ICA5DQo1LiAgICAgQ29uZmxpY3QgcmVzb2x1dGlvbiAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgICA5DQogICA1LjEgICAgICAgQ29u c2lkZXJhdGlvbnMgZm9yIG11bHRpcGxlIGludGVyZmFjZXMgLi4uLi4uLi4u LiAgIDExDQogICA1LjIgICAgICAgQVBJIGlzc3VlcyAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDEyDQo2LiAgICAgSUFOQSBj b25zaWRlcmF0aW9ucyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLiAgIDEzDQo3LiAgICAgQVJQQSBkb21haW4gY29uc2lkZXJhdGlvbnMg Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDEzDQo4LiAgICAgUmVm ZXJlbmNlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLiAgIDE0DQo5LiAgICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDE1DQpBY2tub3ds ZWRnbWVudHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLiAgIDE2DQpBdXRob3JzJyBBZGRyZXNzZXMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDE2DQpJbnRl bGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiAgIDE2DQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQg Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDE3DQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KRXNpYm92LCBBYm9iYSAmIFRoYWxlciAgICAg ICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJd DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICBNdWx0 aWNhc3QgRE5TICAgICAgICAgICAgICAxNSBOb3ZlbWJlciAyMDAxDQoNCg0K MS4gIEludHJvZHVjdGlvbg0KDQpNdWx0aWNhc3QgRE5TIGVuYWJsZXMgRE5T IG5hbWUgcmVzb2x1dGlvbiBpbiB0aGUgc2NlbmFyaW9zIHdoZW4NCmNvbnZl bnRpb25hbCBETlMgbmFtZSByZXNvbHV0aW9uIGlzIG5vdCBwb3NzaWJsZS4g TmFtZWx5LCB3aGVuIHRoZXJlIGFyZQ0Kbm8gRE5TIHNlcnZlcnMgYXZhaWxh YmxlIG9uIHRoZSBuZXR3b3JrIG9yIGF2YWlsYWJsZSBETlMgc2VydmVycyBk byBub3QNCnByb3ZpZGUgbmFtZSByZXNvbHV0aW9uIGZvciB0aGUgbmFtZXMg b2YgdGhlIGhvc3RzIG9uIHRoZSBsb2NhbCBuZXR3b3JrLg0KVGhlIGxhdHRl ciBjYXNlLCBmb3IgZXhhbXBsZSwgY29ycmVzcG9uZHMgdG8gYSBzY2VuYXJp byB3aGVuIGEgbmV0d29yaw0KdGhhdCBkb2Vzbid0IGhhdmUgYSBETlMgc2Vy dmVyIGlzIGNvbm5lY3RlZCB0byB0aGUgSW50ZXJuZXQgdGhyb3VnaCBhbg0K SVNQIGFuZCB0aGUgbmV0d29yayBob3N0cyBhcmUgY29uZmlndXJlZCB3aXRo IHRoZSBJU1AncyBETlMgc2VydmVyIGZvcg0KdGhlIG5hbWUgcmVzb2x1dGlv bi4gVGhlIElTUCdzIEROUyBzZXJ2ZXIgcHJvdmlkZXMgdGhlIG5hbWUgcmVz b2x1dGlvbg0KZm9yIHRoZSBuYW1lcyByZWdpc3RlcmVkIG9uIHRoZSBJbnRl cm5ldCwgYnV0IGRvZXNuJ3QgcHJvdmlkZSBuYW1lDQpyZXNvbHV0aW9uIGZv ciB0aGUgbmFtZXMgb2YgdGhlIGhvc3RzIG9uIHRoZSBuZXR3b3JrLg0KDQpU aGlzIGRvY3VtZW50IGRpc2N1c3NlcyBtdWx0aWNhc3QgRE5TLCBhbiBleHRl bnNpb24gdG8gdGhlIEROUyBwcm90b2NvbA0Kd2hpY2ggY29uc2lzdHMgb2Yg YSBzaW5nbGUgY2hhbmdlIHRvIHRoZSBtZXRob2Qgb2YgdXNlLCBhbmQgbm8g Y2hhbmdlIHRvDQp0aGUgZm9ybWF0IG9mIEROUyBwYWNrZXRzLg0KDQpTZXJ2 aWNlIGRpc2NvdmVyeSBpbiBnZW5lcmFsIGFzIHdlbGwgYXMgZGlzY292ZXJ5 IG9mIEROUyBzZXJ2ZXJzIHVzaW5nDQptRE5TIGluIHBhcnRpY3VsYXIgaXMg b3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCwgYXMgaXMg bmFtZQ0KcmVzb2x1dGlvbiBvdmVyIG5vbi1tdWx0aWNhc3QgY2FwYWJsZSBt ZWRpYS4NCg0KSW4gdGhpcyBkb2N1bWVudCwgdGhlIGtleSB3b3JkcyAiTUFZ IiwgIk1VU1QsICAiTVVTVCAgTk9UIiwgIk9QVElPTkFMIiwNCiJSRUNPTU1F TkRFRCIsICAiU0hPVUxEIiwgIGFuZCAgIlNIT1VMRCAgTk9UIiwgIGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcw0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFsx XS4NCg0KMi4gIE5hbWUgcmVzb2x1dGlvbiB1c2luZyBNdWx0aWNhc3QgRE5T DQoNClRoaXMgZXh0ZW5zaW9uIHRvIHRoZSBETlMgcHJvdG9jb2wgY29uc2lz dHMgb2YgYSBzaW5nbGUgY2hhbmdlIHRvIHRoZQ0KbWV0aG9kIG9mIHVzZSwg YW5kIG5vIGNoYW5nZSB0byB0aGUgY3VycmVudCBmb3JtYXQgb2YgRE5TIHBh Y2tldHMsIEl0DQphbGxvd3MgbXVsdGljYXN0IEROUyBxdWVyaWVzIHRvIGJl IHNlbnQgdG8gYW5kIHJlY2VpdmVkIG9uIHBvcnQgNTMgdXNpbmcNCmEgTElO S0xPQ0FMIGFkZHJlc3MgYXMgc3BlY2lmaWVkIGluICJBZG1pbmlzdHJhdGl2 ZWx5IFNjb3BlZCBJUA0KTXVsdGljYXN0IiBbMl0gZm9yIElQdjQgYW5kIHRo ZSAic29saWNpdGVkIG5hbWUiIExJTktMT0NBTCBtdWx0aWNhc3QNCmFkZHJl c3NlcyBmb3IgSVB2Ni4gIFRoZSBtRE5TIExJTktMT0NBTCBhZGRyZXNzIHRv IGJlIHVzZWQgZm9yIElQdjQgaXMNCjxUQkQ+LiAgTElOS0xPQ0FMIGFkZHJl c3NlcyBhcmUgdXNlZCB0byBwcmV2ZW50IHByb3BhZ2F0aW9uIG9mIG11bHRp Y2FzdA0KRE5TIHRyYWZmaWMgYWNyb3NzIHJvdXRlcnMsIHBvdGVudGlhbGx5 IGZsb29kaW5nIHRoZSBuZXR3b3JrLg0KDQpQcm9wYWdhdGlvbiBvZiBtdWx0 aWNhc3QgRE5TIHBhY2tldHMgb24gdGhlIGxvY2FsIGxpbmsgaXMgY29uc2lk ZXJlZA0Kc3VmZmljaWVudCB0byBlbmFibGUgRE5TIG5hbWUgcmVzb2x1dGlv biBpbiBzbWFsbCBhZGhvYyBuZXR3b3Jrcy4gVGhlDQphc3N1bXB0aW9uIGlz IHRoYXQgaWYgYSBuZXR3b3JrIGhhcyBhIHJvdXRlciwgdGhlbiB0aGUgbmV0 d29yayBlaXRoZXINCmhhcyBhIEROUyBzZXJ2ZXIgb3IgdGhlIHJvdXRlciBj YW4gZnVuY3Rpb24gYXMgYSBETlMgcHJveHkuDQoNCkJ5IGltcGxlbWVudGlu ZyBESENQdjQgYXMgd2VsbCBhcyBhIEROUyBwcm94eSBhbmQgZHluYW1pYyBE TlMsIHJvdXRlcnMNCmNhbiBwcm92aWRlIG5hbWUgcmVzb2x1dGlvbiBmb3Ig dGhlIG5hbWVzIG9mIElQdjQgaG9zdHMgb24gdGhlIGxvY2FsDQpuZXR3b3Jr LiBXaGVyZSBhbGwgSVB2NiBob3N0cyBhbHNvIHN1cHBvcnQgSVB2NCwgYW5k IHRoZSBETlMgcHJveHkNCnN1cHBvcnRzIEFBQUEgUlJzLCByZXNvbHV0aW9u IGZvciB0aGUgbmFtZXMgb2YgZHVhbCBzdGFjayBJUHY2IGhvc3RzIG9uDQp0 aGUgbG9jYWwgbmV0d29yayBjYW4gYWxzbyBiZSBwcm92aWRlZCB1c2luZyB0 aGlzIG1lY2hhbmlzbS4NCg0KDQoNCg0KDQpFc2lib3YsIEFib2JhICYgVGhh bGVyICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAg W1BhZ2UgM10NCg0KDQoNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAg ICAgIE11bHRpY2FzdCBETlMgICAgICAgICAgICAgIDE1IE5vdmVtYmVyIDIw MDENCg0KDQpXaXRoaW4gc21hbGwgYWRob2MgSVB2NiBuZXR3b3Jrcywgc3Rh dGVmdWwgYXV0b2NvbmZpZ3VyYXRpb24gaXMgdGhlIG1vc3QNCmxpa2VseSBj b25maWd1cmF0aW9uIG1lY2hhbmlzbS4gSWYgREhDUHY2IGlzIG5vdCBwcmVz ZW50LCB0aGVuIGluIG9yZGVyDQp0byBzdXBwb3J0IHJlc29sdXRpb24gb2Yg bmFtZXMgb2YgSVB2Ni1vbmx5IGhvc3RzIG9uIHRoZSBsb2NhbCBuZXR3b3Jr LA0KdGhlIEROUyBwcm94eSB3aWxsIG5lZWQgdG8gc3VwcG9ydCBkeW5hbWlj IGNsaWVudCB1cGRhdGUgYXMgd2VsbCBhcyBETlMNCm92ZXIgSVB2Ni4NCg0K R2l2ZW4gdGhlIGFib3ZlIG1lY2hhbmlzbXMgZW5hYmxpbmcgRE5TIG5hbWUg cmVzb2x1dGlvbiBpbiBzbWFsbA0KbmV0d29ya3Mgd2l0aCBhIHJvdXRlciwg aXQgaXMgYXNzdW1lZCB0aGF0IG11bHRpY2FzdCBETlMgbmVlZCBub3QgYmUN CmVuYWJsZWQgYnkgZGVmYXVsdC4NCg0KSW4gdGhlIGZ1dHVyZSwgbUROUyBt YXkgYmUgZGVmaW5lZCB0byBzdXBwb3J0IGdyZWF0ZXIgdGhhbiBMSU5LTE9D QUwNCm11bHRpY2FzdCBzY29wZS4gIFRoaXMgd291bGQgb2NjdXIgaWYgTElO S0xPQ0FMIG1ETlMgZGVwbG95bWVudCBpcw0Kc3VjY2Vzc2Z1bCwgdGhlIGFz c3VtcHRpb24gdGhhdCBtRE5TIGlzIG5vdCBuZWVkZWQgb24gbXVsdGlwbGUg bGlua3MNCnByb3ZlcyBpbmNvcnJlY3QsIGFuZCBtdWx0aWNhc3Qgcm91dGlu ZyBiZWNvbWVzIHViaXF1aXRvdXMuICBGb3INCmV4YW1wbGUsIGl0IGlzIG5v dCBjbGVhciB0aGF0IHRoaXMgYXNzdW1wdGlvbiB3aWxsIGJlIHZhbGlkIGlu IGxhcmdlDQphZGhvYyBuZXR3b3JraW5nIHNjZW5hcmlvcy4NCg0KT25jZSB3 ZSBoYXZlIGV4cGVyaWVuY2UgaW4gbUROUyBkZXBsb3ltZW50IGluIHRlcm1z IG9mIGFkbWluaXN0cmF0aXZlDQppc3N1ZXMsIHVzYWJpbGl0eSBhbmQgaW1w YWN0IG9uIHRoZSBuZXR3b3JrIGl0IHdpbGwgYmUgcG9zc2libGUNCnJlZXZh bHVhdGUgd2hpY2ggbXVsdGljYXN0IHNjb3BlcyBhcmUgYXBwcm9wcmlhdGUg Zm9yIHVzZSB3aXRoIG1ETlMuDQoNCjIuMS4gIEJlaGF2aW9yIG9mIHRoZSBz ZW5kZXIgYW5kIHJlc3BvbmRlcg0KDQpGb3IgdGhlIHB1cnBvc2Ugb2YgdGhp cyBkb2N1bWVudCBhIGhvc3QgdGhhdCBzZW5kcyBhIG11bHRpY2FzdCBxdWVy eSBpcw0KY2FsbGVkIGEgInNlbmRlciIsIHdoaWxlIGEgaG9zdCB0aGF0IGxp c3RlbnMgdG8gKGJ1dCBub3QgbmVjZXNzYXJpbHkNCnJlc3BvbmRzIHRvKSBh IG11bHRpY2FzdCBxdWVyeSBpcyBjYWxsZWQgInJlc3BvbmRlciIuIEEgaG9z dCBjb25maWd1cmVkDQp0byBiZSBhICJyZXNwb25kZXIiIG1heSBhbHNvIGJl IGEgInNlbmRlciIuIEEgaG9zdCBjb25maWd1cmVkIHRvIG5vdCBiZQ0KYSAi cmVzcG9uZGVyIiBjYW5ub3QgYmUgYSAic2VuZGVyIi4NCg0KMi4xLjEuICBC ZWhhdmlvciBvZiBzZW5kZXJzDQoNCkEgc2VuZGVyIHNlbmRzIG11bHRpY2Fz dCBETlMgcXVlcnkgZm9yIGFueSBsZWdhbCBUeXBlIG9mIHJlc291cmNlIHJl Y29yZA0KKGUuZy4gQSwgUFRSLCBldGMuKSBmb3IgYSBuYW1lIHdpdGhpbiB0 aGUgIi5sb2NhbC5hcnBhLiIgZG9tYWluIHRvIHRoZQ0KTElOS0xPQ0FMIGFk ZHJlc3MuIFRoZSBSRCAoUmVjdXJzaW9uIERlc2lyZWQpIGJpdCBNVVNUIE5P VCBiZSBzZXQuIElmIGENCnJlc3BvbmRlciByZWNlaXZlcyBhIHF1ZXJ5IHdp dGggdGhlIGhlYWRlciBjb250YWluaW5nIFJEIHNldCBiaXQsIHRoZQ0KcmVz cG9uZGVyIE1VU1QgaWdub3JlIHRoZSBSRCBiaXQuDQoNClRoZSBJUHY2IExJ TktMT0NBTCBhZGRyZXNzIGEgZ2l2ZW4gcmVzcG9uZGVyICBsaXN0ZW5zIHRv LCBhbmQgdG8gd2hpY2ggYQ0Kc2VuZGVyIHNlbmRzLCBpcyBhIGxpbmstbG9j YWwgbXVsdGljYXN0IGFkZHJlc3MgZm9ybWVkIGFzIGZvbGxvd3M6IFRoZQ0K bmFtZSBvZiB0aGUgcmVzb3VyY2UgcmVjb3JkIGluIHF1ZXN0aW9uIGlzIGV4 cHJlc3NlZCBpbiBpdHMgY2Fub25pY2FsDQpmb3JtIChzZWUgUkZDIDI1MzUg WzE1XSwgc2VjdGlvbiA4LjEpLCB3aGljaCBpcyB1bmNvbXByZXNzZWQgd2l0 aCBhbGwNCmFscGhhYmV0aWMgY2hhcmFjdGVycyBpbiBsb3dlciBjYXNlLiAg VGhlIGZpcnN0IGxhYmVsIG9mIHRoZSByZXNvdXJjZQ0KcmVjb3JkIG5hbWUg aXMgdGhlbiBoYXNoZWQgdXNpbmcgdGhlIE1ENSBhbGdvcml0aG0gKHNlZSBS RkMgMTMyMSBbMTZdKS4NClRoZSBmaXJzdCAzMiBiaXRzIG9mIHRoZSByZXN1 bHRhbnQgMTI4LWJpdCBoYXNoIGlzIHRoZW4gYXBwZW5kZWQgdG8gdGhlDQpw cmVmaXggRkYwMjowOjA6MDowOjI6Oi85NiB0byB5aWVsZCB0aGUgMTI4LWJp dCAic29saWNpdGVkIG5hbWUNCm11bHRpY2FzdCBhZGRyZXNzIi4gIChOb3Rl OiB0aGlzIHByb2NlZHVyZSBpcyBpbnRlbmRlZCB0byBiZSB0aGUgc2FtZSBh cw0KdGhhdCBzcGVjaWZpZWQgaW4gc2VjdGlvbiAzIG9mICJJUHY2IE5vZGUg SW5mb3JtYXRpb24gUXVlcmllcyIgWzE0XSkuICBBDQpyZXNwb25kZXIgdGhh dCBsaXN0ZW5zIGZvciBxdWVyaWVzIGZvciBtdWx0aXBsZSBuYW1lcyB3aWxs IG5lY2Vzc2FyaWx5DQoNCg0KDQpFc2lib3YsIEFib2JhICYgVGhhbGVyICAg ICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug NF0NCg0KDQoNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgIE11 bHRpY2FzdCBETlMgICAgICAgICAgICAgIDE1IE5vdmVtYmVyIDIwMDENCg0K DQpsaXN0ZW4gdG8gbXVsdGlwbGUgb2YgdGhlc2Ugc29saWNpdGVkIG5hbWUg bXVsdGljYXN0IGFkZHJlc3Nlcy4NCg0KSWYgdGhlIG11bHRpY2FzdCBxdWVy eSBpcyBub3QgcG9zaXRpdmVseSByZXNvbHZlZCAoInBvc2l0aXZlbHkgcmVz b2x2ZWQiDQpyZWZlcnMgaW4gdGhpcyBkb2N1bWVudCB0byBhIHJlc3BvbnNl IHdpdGggdGhlIFJDT0RFIHNldCB0byAwKSBkdXJpbmcgYQ0KbGltaXRlZCBh bW91bnQgb2YgdGltZSwgdGhlbiBhIHNlbmRlciBNQVkgcmVwZWF0IHRoZSB0 cmFuc21pc3Npb24gb2YgYQ0KcXVlcnkgaW4gb3JkZXIgdG8gYXNzdXJlIHRo ZW1zZWx2ZXMgdGhhdCB0aGUgcXVlcnkgaGFzIGJlZW4gcmVjZWl2ZWQgYnkN CmEgaG9zdCBjYXBhYmxlIG9mIHJlc3BvbmRpbmcgdG8gdGhlIHF1ZXJ5Lg0K DQpSZXBldGl0aW9uIE1VU1QgTk9UIGJlIGF0dGVtcHRlZCBtb3JlIHRoYW4g MyB0aW1lcyBhbmQgU0hPVUxEIE5PVCBiZQ0KcmVwZWF0ZWQgbW9yZSBvZnRl biB0aGFuIG9uY2UgcGVyIHNlY29uZCB0byByZWR1Y2UgdW5uZWNlc3Nhcnkg bmV0d29yaw0KdHJhZmZpYy4gVGhlIGRlbGF5IGJldHdlZW4gYXR0ZW1wdHMg c2hvdWxkIGJlIHJhbmRvbWl6ZWQgc28gYXMgdG8gYXZvaWQNCnN5bmNocm9u aXphdGlvbiBlZmZlY3RzLg0KDQoyLjEuMi4gIEJlaGF2aW9yIG9mIHJlc3Bv bmRlcnMNCg0KQSByZXNwb25kZXIgbGlzdGVucyBvbiBwb3J0IDUzIG9uIHRo ZSBMSU5LTE9DQUwgYWRkcmVzcy4gIFJlc3BvbmRlcnMNCk1VU1QgcmVzcG9u ZCB0byBtdWx0aWNhc3QgcXVlcmllcyB0byB0aG9zZSBhbmQgb25seSB0aG9z ZSBuYW1lcyBmb3INCndoaWNoIHRoZXkgYXJlIGF1dGhvcml0YXRpdmUuIEFz IGFuIGV4YW1wbGUsIGNvbXB1dGVyDQoiaG9zdC5leGFtcGxlLmNvbS5sb2Nh bC5hcnBhLiIgaXMgYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIGRvbWFpbg0KImhv c3QuZXhhbXBsZS5jb20ubG9jYWwuYXJwYS4iLiBPbiByZWNlaXZpbmcgYSBt dWx0aWNhc3QgRE5TIEEgcmVjb3JkDQpxdWVyeSBmb3IgdGhlIG5hbWUgImhv c3QuZXhhbXBsZS5jb20ubG9jYWwuYXJwYS4iIHN1Y2ggYSBob3N0IHJlc3Bv bmRzDQp3aXRoIEEgcmVjb3JkKHMpIHRoYXQgY29udGFpbiBJUCBhZGRyZXNz KGVzKSBpbiB0aGUgUkRBVEEgb2YgdGhlIHJlY29yZC4NCg0KSW4gY29udmVu dGlvbmFsIEROUyB0ZXJtaW5vbG9neSBhIEROUyBzZXJ2ZXIgYXV0aG9yaXRh dGl2ZSBmb3IgYSB6b25lIGlzDQphdXRob3JpdGF0aXZlIGZvciBhbGwgdGhl IGRvbWFpbiBuYW1lcyB1bmRlciB0aGUgem9uZSByb290IGV4Y2VwdCBmb3IN CnRoZSBicmFuY2hlcyBkZWxlZ2F0ZWQgaW50byBzZXBhcmF0ZSB6b25lcy4g Q29udHJhcnkgdG8gY29udmVudGlvbmFsIEROUw0KdGVybWlub2xvZ3ksIGEg cmVzcG9uZGVyIGlzIGF1dGhvcml0YXRpdmUgb25seSBmb3IgdGhlIHpvbmUg cm9vdC4gRm9yDQpleGFtcGxlIHRoZSBob3N0ICJob3N0LmV4YW1wbGUuY29t LmxvY2FsLmFycGEuIiBpcyBub3QgYXV0aG9yaXRhdGl2ZSBmb3INCnRoZSBu YW1lICJjaGlsZC5ob3N0LmV4YW1wbGUuY29tLmxvY2FsLmFycGEuIiB1bmxl c3MgdGhlIGhvc3QgaXMNCmNvbmZpZ3VyZWQgd2l0aCBtdWx0aXBsZSBuYW1l cywgaW5jbHVkaW5nICJob3N0LmV4YW1wbGUuY29tLmxvY2FsLmFycGEuIg0K YW5kICJjaGlsZC5ob3N0LmV4YW1wbGUuY29tLmxvY2FsLmFycGEuIi4gVGhl IHB1cnBvc2Ugb2YgbGltaXRpbmcgdGhlDQpuYW1lIGF1dGhvcml0eSBzY29w ZSBvZiBhIHJlc3BvbmRlciBpcyB0byBwcmV2ZW50IGNvbXBsaWNhdGlvbnMg dGhhdA0KY291bGQgYmUgY2F1c2VkIGJ5IGNvZXhpc3RlbmNlIG9mIHR3byBv ciBtb3JlIGhvc3RzIHdpdGggdGhlIG5hbWVzDQpyZXByZXNlbnRpbmcgY2hp bGQgYW5kIHBhcmVudCAob3IgZ3JhbmRwYXJlbnQpIG5vZGVzIGluIHRoZSBE TlMgdHJlZSwNCmZvciBleGFtcGxlLCAiaG9zdC5leGFtcGxlLmNvbS5sb2Nh bC5hcnBhLiIgYW5kDQoiY2hpbGQuaG9zdC5leGFtcGxlLmNvbS5sb2NhbC5h cnBhLiIuDQoNCkluIHRoaXMgZXhhbXBsZSAodW5sZXNzIHRoaXMgbGltaXRh dGlvbiBpcyBpbnRyb2R1Y2VkKSBhIG11bHRpY2FzdCBxdWVyeQ0KZm9yIGFu IEEgcmVjb3JkIGZvciB0aGUgbmFtZSAiY2hpbGQuaG9zdC5leGFtcGxlLmNv bS5sb2NhbC5hcnBhLiIgd291bGQNCnJlc3VsdCBpbiB0d28gYXV0aG9yaXRh dGl2ZSByZXNwb25zZXM6IG5hbWUgZXJyb3IgcmVjZWl2ZWQgZnJvbQ0KImhv c3QuZXhhbXBsZS5jb20ubG9jYWwuYXJwYS4iLCBhbmQgYSByZXF1ZXN0ZWQg QSByZWNvcmQgLSBmcm9tDQoiY2hpbGQuaG9zdC5leGFtcGxlLmNvbS5sb2Nh bC5hcnBhLiIuIFRvIHByZXZlbnQgdGhpcyBhbWJpZ3VpdHksDQptdWx0aWNh c3QgZW5hYmxlZCBob3N0cyBjb3VsZCBwZXJmb3JtIGEgZHluYW1pYyB1cGRh dGUgb2YgdGhlIHBhcmVudCAob3INCmdyYW5kcGFyZW50KSB6b25lIHdpdGgg YSBkZWxlZ2F0aW9uIHRvIGEgY2hpbGQgem9uZS4gSW4gdGhpcyBleGFtcGxl IGENCmhvc3QgImNoaWxkLmhvc3QuZXhhbXBsZS5jb20ubG9jYWwuYXJwYS4i IHdvdWxkIHNlbmQgYSBkeW5hbWljIHVwZGF0ZQ0KZm9yIHRoZSBOUyBhbmQg Z2x1ZSBBIHJlY29yZCB0byAiaG9zdC5leGFtcGxlLmNvbS5sb2NhbC5hcnBh LiIsIGJ1dCB0aGlzDQphcHByb2FjaCBzaWduaWZpY2FudGx5IGNvbXBsaWNh dGVzIGltcGxlbWVudGF0aW9uIG9mIG11bHRpY2FzdCBETlMgYW5kDQp3b3Vs ZCBub3QgYmUgYWNjZXB0YWJsZSBmb3IgbGlnaHR3ZWlnaHQgaG9zdHMuDQoN Cg0KDQpFc2lib3YsIEFib2JhICYgVGhhbGVyICAgICAgIFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCg0KDQoNCg0KDQpJ TlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgIE11bHRpY2FzdCBETlMgICAg ICAgICAgICAgIDE1IE5vdmVtYmVyIDIwMDENCg0KDQpBIHJlc3BvbnNlIHRv IGEgbXVsdGljYXN0IHF1ZXJ5IGlzIGNvbXBvc2VkIGluIGV4YWN0bHkgdGhl IHNhbWUgbWFubmVyDQphcyBhIHJlc3BvbnNlIHRvIHRoZSB1bmljYXN0IERO UyBxdWVyeSBhcyBzcGVjaWZpZWQgaW4gUkZDIDEwMzUgWzRdLg0KUmVzcG9u ZGVycyBNVVNUIG5ldmVyIHJlc3BvbmQgdXNpbmcgY2FjaGVkIGRhdGEsIGFu ZCB0aGUgQUENCihBdXRob3JpdGF0aXZlIEFuc3dlcikgYml0IE1VU1QgYmUg c2V0LiBUaGUgcmVzcG9uc2UgaXMgc2VudCB0byB0aGUNCnNlbmRlciB2aWEg dW5pY2FzdC4gIEEgcmVzcG9uc2UgdG8gYW4gbUROUyBxdWVyeSBNVVNUIGhh dmUgUkNPREUgc2V0IHRvDQp6ZXJvLiBtRE5TIHJlc3BvbmRlcnMgbWF5IHJl c3BvbmQgb25seSB0byBxdWVyaWVzIHdoaWNoIHRoZXkgY2FuIHJlc29sdmUN CnBvc2l0aXZlbHkuDQoNCklmIGEgVEMgKHRydW5jYXRpb24pIGJpdCBpcyBz ZXQgaW4gdGhlIHJlc3BvbnNlLCB0aGVuIHRoZSBzZW5kZXIgTUFZIHVzZQ0K dGhlIHJlc3BvbnNlIGlmIGl0IGNvbnRhaW5zIGFsbCBuZWNlc3NhcnkgaW5m b3JtYXRpb24sIG9yIHRoZSBzZW5kZXIgTUFZDQpkaXNjYXJkIHRoZSByZXNw b25zZSBhbmQgcmVzZW5kIHRoZSBxdWVyeSBvdmVyIFRDUCBvciB1c2luZyBF RE5TMCB3aXRoDQpsYXJnZXIgd2luZG93IHVzaW5nIHRoZSB1bmljYXN0IGFk ZHJlc3Mgb2YgdGhlIHJlc3BvbmRlci4gVGhlIFJBDQooUmVjdXJzaW9uIEF2 YWlsYWJsZSkgYml0IGluIHRoZSBoZWFkZXIgb2YgdGhlIHJlc3BvbnNlIE1V U1QgTk9UIGJlIHNldC4NCkV2ZW4gaWYgdGhlIFJBIGJpdCBpcyBzZXQgaW4g dGhlIHJlc3BvbnNlIGhlYWRlciwgdGhlIHNlbmRlciBNVVNUIGlnbm9yZQ0K aXQuDQoNCjIuMS4zLiAgbUROUyBhZGRyZXNzaW5nDQoNCkZvciBJUHY0IExJ TktMT0NBTCBhZGRyZXNzaW5nLCBzZWN0aW9uIDIuNCBvZiAiRHluYW1pYyBD b25maWd1cmF0aW9uIG9mDQpJUHY0IExpbmstTG9jYWwgQWRkcmVzc2VzIiBb MThdIGxheXMgb3V0IHRoZSBydWxlcyB3aXRoIHJlc3BlY3QgdG8NCnNvdXJj ZSBhZGRyZXNzIHNlbGVjdGlvbiwgVFRMIHNldHRpbmdzLCBhbmQgYWNjZXB0 YWJsZQ0Kc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJlc3MgY29tYmluYXRpb25z LiBJUHY2IExJTktMT0NBTCBhZGRyZXNzaW5nIGlzDQpkZXNjcmliZWQgaW4g UkZDIDIzNzMgWzldLiBtRE5TIHF1ZXJpZXMgYW5kIHJlc3BvbnNlcyBNVVNU IG9iZXkgdGhlDQpydWxlcyBsYWlkIG91dCBpbiB0aGVzZSBkb2N1bWVudHMu DQoNCkluIGNvbXBvc2luZyBhbiBtRE5TIHJlc3BvbnNlLCB0aGUgcmVzcG9u ZGVyIE1VU1Qgc2V0IHRoZSBIb3AgTGltaXQNCmZpZWxkIGluIHRoZSBJUHY2 IGhlYWRlciBhbmQgdGhlIFRUTCBmaWVsZCBpbiBJUHY0IGhlYWRlciBvZiB0 aGUNCm11bHRpY2FzdCBETlMgcmVzcG9uc2UgdG8gMjU1LiBUaGUgc2VuZGVy IE1VU1QgdmVyaWZ5IHRoYXQgdGhlIEhvcCBMaW1pdA0KZmllbGQgaW4gSVB2 NiBoZWFkZXIgYW5kIFRUTCBmaWVsZCBpbiBJUHY0IGhlYWRlciBvZiBlYWNo IHJlc3BvbnNlIHRvDQp0aGUgbXVsdGljYXN0IEROUyBxdWVyeSBpcyBzZXQg dG8gMjU1LiBJZiBpdCBpcyBub3QsIHRoZW4gc2VuZGVyIE1VU1QNCmlnbm9y ZSB0aGUgcmVzcG9uc2UuDQoNCiAgIEltcGxlbWVudGF0aW9uIG5vdGU6DQoN CiAgIEluIHRoZSBzb2NrZXRzIEFQSSBmb3IgSVB2NCwgdGhlIElQX1RUTCBh bmQgSVBfTVVMVElDQVNUX1RUTCBzb2NrZXQNCiAgIG9wdGlvbnMgYXJlIHVz ZWQgdG8gc3BlY2lmeSB0aGUgVFRMIG9mIG91dGdvaW5nIHVuaWNhc3QgYW5k IG11bHRpY2FzdA0KICAgcGFja2V0cy4gVGhlIElQX1JFQ1ZUVEwgc29ja2V0 IG9wdGlvbiBpcyBhdmFpbGFibGUgb24gc29tZSBwbGF0Zm9ybXMNCiAgIHRv IHJlY2VpdmUgdGhlIElQdjQgVFRMIG9mIHJlY2VpdmVkIHBhY2tldHMgd2l0 aCByZWN2bXNnKCkuIFJGQyAyMjkyDQogICBbMjBdIHNwZWNpZmllcyBzaW1p bGFyIG9wdGlvbnMgZm9yIHNwZWNpZnlpbmcgYW5kIHJlY2VpdmluZyB0aGUg SVB2Ng0KICAgSG9wIExpbWl0Lg0KDQoyLjEuNC4gIFVzZSBvZiBETlMgVFRM DQoNClRoZSByZXNwb25kZXIgc2hvdWxkIHVzZSBhIHByZS1jb25maWd1cmVk IFRUTCB2YWx1ZSBpbiB0aGUgcmVjb3Jkcw0KcmV0dXJuZWQgaW4gdGhlIG11 bHRpY2FzdCBETlMgcXVlcnkgcmVzcG9uc2UuIER1ZSB0byB0aGUgVFRMDQpt aW5pbWFsaXphdGlvbiBuZWNlc3Nhcnkgd2hlbiBjYWNoaW5nIGFuIFJSc2V0 LCBhbGwgVFRMcyBpbiBhbiBSUnNldA0KTVVTVCBiZSBzZXQgdG8gdGhlIHNh bWUgdmFsdWUuICBJbiB0aGUgYWRkaXRpb25hbCBhbmQgYXV0aG9yaXR5IHNl Y3Rpb24NCm9mIHRoZSByZXNwb25zZSB0aGUgcmVzcG9uZGVyIGluY2x1ZGVz IHRoZSBzYW1lIHJlY29yZHMgYXMgYSBETlMgc2VydmVyDQoNCg0KDQpFc2li b3YsIEFib2JhICYgVGhhbGVyICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0KDQoNCg0KDQpJTlRFUk5FVC1E UkFGVCAgICAgICAgICAgICAgIE11bHRpY2FzdCBETlMgICAgICAgICAgICAg IDE1IE5vdmVtYmVyIDIwMDENCg0KDQp3b3VsZCBpbnNlcnQgaW4gdGhlIHJl c3BvbnNlIHRvIHRoZSB1bmljYXN0IEROUyBxdWVyeS4NCg0KMi4xLjUuICBO by9tdWx0aXBsZSByZXNwb25zZXMNCg0KVGhlIHNlbmRlciBNVVNUIGFudGlj aXBhdGUgcmVjZWl2aW5nIG5vIHJlcGxpZXMgdG8gc29tZSBtdWx0aWNhc3QN CnF1ZXJpZXMsIGluIHRoZSBldmVudCB0aGF0IG5vIHJlc3BvbmRlcnMgYXJl IGF2YWlsYWJsZSB3aXRoaW4gdGhlDQptdWx0aWNhc3Qgc2NvcGUsIG9yIGlu IHRoZSBldmVudCB0aGF0IG5vIHBvc2l0aXZlIG5vbi1udWxsIHJlc3BvbnNl cw0KZXhpc3QgZm9yIHRoZSB0cmFuc21pdHRlZCBxdWVyeS4NCg0KSWYgbm8g cG9zaXRpdmUgcmVzcG9uc2UgaXMgcmVjZWl2ZWQsIGEgcmVzb2x2ZXIgdHJl YXRzIGl0IGFzIGEgcmVzcG9uc2UNCnRoYXQgbm8gcmVjb3JkcyBvZiB0aGUg c3BlY2lmaWVkIHR5cGUgYW5kIGNsYXNzIGZvciB0aGUgc3BlY2lmaWVkIG5h bWUNCmV4aXN0IChOWFJSU0VUKS4NCg0KVGhlIHNlbmRlciBNVVNUIGFudGlj aXBhdGUgcmVjZWl2aW5nIG11bHRpcGxlIHJlcGxpZXMgdG8gdGhlIHNhbWUN Cm11bHRpY2FzdCBxdWVyeSwgaW4gdGhlIGV2ZW50IHRoYXQgc2V2ZXJhbCBt dWx0aWNhc3QgRE5TIGVuYWJsZWQNCmNvbXB1dGVycyByZWNlaXZlIHRoZSBx dWVyeSBhbmQgcmVzcG9uZCB3aXRoIHZhbGlkIGFuc3dlcnMuICBXaGVuIHRo aXMNCm9jY3VycywgdGhlIHJlc3BvbnNlcyBNQVkgZmlyc3QgYmUgY29uY2F0 ZW5hdGVkLCBhbmQgdGhlbiB0cmVhdGVkIGluIHRoZQ0Kc2FtZSBtYW5uZXIg dGhhdCBtdWx0aXBsZSBSUnMgcmVjZWl2ZWQgZnJvbSB0aGUgc2FtZSBETlMg c2VydmVyIHdvdWxkLA0Kb3JkaW5hcmlseS4NCg0KMy4gIFVzYWdlIG1vZGVs DQoNCkEgaG9zdCBjb25maWd1cmVkIHRvIGJlIGFuIG1ETlMgInJlc3BvbmRl ciIgTVVTVCBhbHNvIGJlIGNvbmZpZ3VyZWQgYXMgYQ0KInNlbmRlciIuIEEg aG9zdCBub3QgY29uZmlndXJlZCBhcyBhICJyZXNwb25kZXIiIE1VU1QgTk9U IGJlIGEgInNlbmRlciIuDQoNCk11bHRpY2FzdCBETlMgdXNhZ2UgaXMgZGV0 ZXJtaW5lZCBieSBzcGVjaWFsIHRyZWF0bWVudCBvZiB0aGUNCiIubG9jYWwu YXJwYS4iICBuYW1lc3BhY2UuIFRoZSBzZW5kZXIgdHJlYXRzIHF1ZXJpZXMg Zm9yICIubG9jYWwuYXJwYS4iDQphcyBhIHNwZWNpYWwgY2FzZS4gIEEgc2Vu ZGVyIE1VU1QgTk9UIHNlbmQgYSB1bmljYXN0IHF1ZXJ5IGZvciBuYW1lcw0K ZW5kaW5nIHdpdGggdGhlICIubG9jYWwuYXJwYS4iIHN1ZmZpeCBleGNlcHQg d2hlbjoNCg0KICBhLiBBIHNlbmRlciByZXBlYXRzIGEgcXVlcnkgYWZ0ZXIg aXQgcmVjZWl2ZWQgYSByZXNwb25zZQ0KICAgICB0byB0aGUgcHJldmlvdXMg bXVsdGljYXN0IHF1ZXJ5IHdpdGggdGhlIFRDIGJpdCBzZXQsIG9yDQoNCiAg Yi4gVGhlIHNlbmRlcidzIGNhY2hlIGNvbnRhaW5zIGFuIE5TIHJlc291cmNl IHJlY29yZCB0aGF0IGVuYWJsZXMNCiAgICAgdGhlIHNlbmRlciB0byBzZW5k IGEgcXVlcnkgZGlyZWN0bHkgdG8gdGhlIGhvc3RzDQogICAgIGF1dGhvcml0 YXRpdmUgZm9yIHRoZSBuYW1lIGluIHRoZSBxdWVyeS4NCg0KSXQgaXMgbm90 IGV4cGVjdGVkIHRoYXQgYSBob3N0IG5hbWVkICJob3N0LmV4YW1wbGUuY29t LiIgd2lsbCBiZQ0KbWFudWFsbHkgY29uZmlndXJlZCB0byBoYXZlIHRoZSBh ZGRpdGlvbmFsIG5hbWUNCiJob3N0LmV4YW1wbGUuY29tLmxvY2FsLmFycGEu IiB3aGVuIGl0IGlzIGNvbmZpZ3VyZWQgdG8gdXNlIG11bHRpY2FzdA0KRE5T LiBJbnN0ZWFkLCBhIHJlc3BvbmRlciB3aXRoIGEgbmFtZSAiaG9zdC5leGFt cGxlLmNvbS4iIGNvbmZpZ3VyZWQNCndpdGggIi5sb2NhbC5hcnBhLiIgc3Vm Zml4IGluIGl0cyBkb21haW4gc2VhcmNoIGNvbmZpZ3VyYXRpb24gaXMNCmF1 dGhvcml0YXRpdmUgZm9yIHRoZSBuYW1lICJob3N0LmV4YW1wbGUuY29tLmxv Y2FsLmFycGEuIi4gRm9yIGV4YW1wbGUsDQp3aGVuIGEgcmVzcG9uZGVyIHdp dGggdGhlIG5hbWUgImhvc3QuZXhhbXBsZS5jb20uIiByZWNlaXZlcyBhbiBB IHR5cGUNCnF1ZXJ5IGZvciB0aGUgbmFtZSAiaG9zdC5leGFtcGxlLmNvbS5s b2NhbC5hcnBhLiIgaXQgYXV0aG9yaXRhdGl2ZWx5DQpyZXNwb25kcyB0byB0 aGUgcXVlcnkuDQoNCg0KDQoNCg0KRXNpYm92LCBBYm9iYSAmIFRoYWxlciAg ICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgIFtQYWdl IDddDQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICBN dWx0aWNhc3QgRE5TICAgICAgICAgICAgICAxNSBOb3ZlbWJlciAyMDAxDQoN Cg0KVGhlIHNhbWUgaG9zdCBNQVkgdXNlIG11bHRpY2FzdCBETlMgcXVlcmll cyBmb3IgdGhlIHJlc29sdXRpb24gb2YgbmFtZXMNCmVuZGluZyB3aXRoICIu bG9jYWwuYXJwYS4iLCBhbmQgdW5pY2FzdCBETlMgcXVlcmllcyBmb3IgcmVz b2x1dGlvbiBvZg0KYWxsIG90aGVyIG5hbWVzLiBXaGVuIGEgdXNlciBvciBh cHBsaWNhdGlvbiByZXF1ZXN0cyBhIEROUyBjbGllbnQgdG8NCnJlc29sdmUg YSBkb3QtdGVybWluYXRlZCBuYW1lIHRoYXQgY29udGFpbnMgYSAiLmxvY2Fs LmFycGEiIHN1ZmZpeCwgdGhlDQpxdWVyeSBmb3Igc3VjaCBhIG5hbWUgTVVT VCBiZSBtdWx0aWNhc3QgYW5kIHRoZSBuYW1lIFNIT1VMRCBOT1QgYmUNCmNv bmNhdGVuYXRlZCB3aXRoIGFueSBzdWZmaXguDQoNCklmIGEgRE5TIHNlcnZl ciBpcyBydW5uaW5nIG9uIGEgaG9zdCwgdGhlbiByZXNwb25kZXIgTVVTVCBO T1QgbGlzdGVuIGZvcg0KdGhlIG11bHRpY2FzdCBETlMgcXVlcmllcyBvbiB0 aGUgc2FtZSBJUCBhZGRyZXNzZXMgb24gd2hpY2ggdGhlIEROUw0Kc2VydmVy IGxpc3RlbnMsICBzaW5jZSBvdGhlcndpc2UgdGhleSB3b3VsZCBpbnRlcmNl cHQgRE5TIHF1ZXJpZXMNCmRpcmVjdGVkIHRvIGEgRE5TIHNlcnZlci4gVGhl IEROUyBzZXJ2ZXIgTVVTVCByZXNwb25kIHRvIHRoZSBtdWx0aWNhc3QNCkRO UyBxdWVyaWVzIG9ubHkgZm9yIHRoZSBSUlNldHMgb3duZWQgYnkgdGhlIGhv c3Qgb24gd2hpY2ggdGhlIHNlcnZlciBpcw0KcnVubmluZywgYnV0IE1VU1Qg Tk9UIHJlc3BvbmQgZm9yIHRoZSByZWNvcmRzIGZvciB3aGljaCB0aGUgc2Vy dmVyIGlzDQphdXRob3JpdGF0aXZlLg0KDQozLjEuICBtRE5TIGNvbmZpZ3Vy YXRpb24NCg0KTXVsdGljYXN0IEROUyB1c2FnZSBjYW4gYmUgY29uZmlndXJl ZCBtYW51YWxseSBvciBhdXRvbWF0aWNhbGx5LiAgT24NCmludGVyZmFjZXMg d2hlcmUgbm8gbWFudWFsIG9yIGF1dG9tYXRpYyBjb25maWd1cmF0aW9uIGhh cyBiZWVuIHBlcmZvcm1lZA0KZm9yIGEgZ2l2ZW4gcHJvdG9jb2wgKElQdjQg b3IgSVB2NiksIG11bHRpY2FzdCBETlMgU0hPVUxEIGJlIGVuYWJsZWQgYnkN CmRlZmF1bHQgZm9yIHRoYXQgcHJvdG9jb2wuDQoNCkZvciBJUHY2LCB0aGUg c3RhdGVsZXNzIEROUyBkaXNjb3ZlcnkgbWVjaGFuaXNtcyBkZXNjcmliZWQg aW4gIklQdjYNClN0YXRlbGVzcyBETlMgRGlzY292ZXJ5IiBbMTldIGNhbiBi ZSB1c2VkIHRvIGRpc2NvdmVyIHdoZXRoZXIgbXVsdGljYXN0DQpETlMgc2hv dWxkIGJlIGVuYWJsZWQgb3IgZGlzYWJsZWQgb24gYSBwZXItaW50ZXJmYWNl IGJhc2lzLg0KDQpXaGVyZSBESENQdjQgb3IgREhDUHY2IGlzIGltcGxlbWVu dGVkLCBESENQIG9wdGlvbnMgY2FuIGJlIHVzZWQgdG8NCmNvbmZpZ3VyZSBt dWx0aWNhc3QgRE5TIG9uIGFuIGludGVyZmFjZS4gIFRoZSBtRE5TIEVuYWJs ZSBPcHRpb24sDQpkZXNjcmliZWQgaW4gWzZdLCBjYW4gYmUgdXNlZCB0byBl eHBsaWNpdGx5IGVuYWJsZSBvciBkaXNhYmxlIHVzZSBvZg0KbXVsdGljYXN0 IEROUyBvbiBhbiBpbnRlcmZhY2UgZm9yIGEgZ2l2ZW4gcHJvdG9jb2wsIGFz IHdlbGwgYXMgdG8NCnNwZWNpZnkgdGhlIG9yZGVyIGluIHdoaWNoIEROUyBh bmQgbXVsdGljYXN0IEROUyBpcyB1c2VkIG9uIHRoYXQNCmludGVyZmFjZS4N Cg0KVGhlIG1ETlMgRW5hYmxlIE9wdGlvbiBhZmZlY3RzIG9ubHkgRE5TIHJl c29sdmVyIGJlaGF2aW9yLCB0aGF0IGlzLCBob3cNCkROUyByZXNvbHV0aW9u IGlzIHBlcmZvcm1lZCwgYW5kIHdoZXRoZXIgbXVsdGljYXN0IEROUyBpcyB1 c2VkLiAgVGhlDQptRE5TIEVuYWJsZSBPcHRpb24gZG9lcyBub3QgZGV0ZXJt aW5lIHdoZXRoZXIgb3IgaW4gd2hpY2ggb3JkZXIgRE5TDQppdHNlbGYgaXMg dXNlZCBmb3IgbmFtZSByZXNvbHV0aW9uLiAgVGhpcyBjYW4gYmUgc3BlY2lm aWVkLCBmb3IgZXhhbXBsZSwNCnVzaW5nIHRoZSBOYW1lIFNlcnZpY2UgU2Vh cmNoIE9wdGlvbiBmb3IgREhDUCwgUkZDIDI5MzcgWzNdLCB3aGljaCBjYW4N CmJlIHVzZWQgdG8gZ2xvYmFsbHkgZGV0ZXJtaW5lIHdoZXJlIEROUyBpcyB1 c2VkIHdpdGhpbiB0aGUgbmFtZSBzZXJ2aWNlDQpzZWFyY2ggb3JkZXIuDQoN CklmIGFuIGludGVyZmFjZSBoYXMgYmVlbiBjb25maWd1cmVkIGZvciBhIGdp dmVuIHByb3RvY29sIHZpYSBhbnkNCmF1dG9tYXRpYyBjb25maWd1cmF0aW9u IG1lY2hhbmlzbSB3aGljaCBpcyBhYmxlIHRvIHN1cHBseSBETlMNCmNvbmZp Z3VyYXRpb24gaW5mb3JtYXRpb24sIHRoZW4gbXVsdGljYXN0IEROUyBTSE9V TEQgTk9UIGJlIHVzZWQgb24gdGhhdA0KaW50ZXJmYWNlIGZvciB0aGF0IHBy b3RvY29sIHVubGVzcyBpdCBoYXMgYmVlbiBleHBsaWNpdGx5IGVuYWJsZWQs DQp3aGV0aGVyIHZpYSB0aGF0IG1lY2hhbmlzbSBvciBhbnkgb3RoZXIuIFRo aXMgZW5zdXJlcyB0aGF0IHVwZ3JhZGVkDQpob3N0cyBkbyBub3QgY2hhbmdl IHRoZWlyIGRlZmF1bHQgYmVoYXZpb3IsIHdpdGhvdXQgcmVxdWlyaW5nIHRo ZSBzb3VyY2UNCm9mIHRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRv IGJlIHNpbXVsdGFuZW91c2x5IHVwZGF0ZWQuICBUaGlzDQoNCg0KDQpFc2li b3YsIEFib2JhICYgVGhhbGVyICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgOF0NCg0KDQoNCg0KDQpJTlRFUk5FVC1E UkFGVCAgICAgICAgICAgICAgIE11bHRpY2FzdCBETlMgICAgICAgICAgICAg IDE1IE5vdmVtYmVyIDIwMDENCg0KDQppbXBsaWVzIHRoYXQgb24gdGhlIGlu dGVyZmFjZSwgdGhlIGhvc3Qgd2lsbCBuZWl0aGVyIGxpc3RlbiBvbiB0aGUg RE5TDQpMSU5LTE9DQUwgbXVsdGljYXN0IGFkZHJlc3MsIG5vciB3aWxsIGl0 IHNlbmQgcXVlcmllcyB0byB0aGF0IGFkZHJlc3MuDQoNCk5vdGUgdGhhdCBp dCBpcyBwb3NzaWJsZSBmb3IgbUROUyB0byBiZSBlbmFibGVkIGZvciB1c2Ug d2l0aCBJUHY2IGF0IHRoZQ0Kc2FtZSB0aW1lIGl0IGlzIGRpc2FibGVkIGZv ciBJUHY0LCBhbmQgdmljZSB2ZXJzYS4gRm9yIGV4YW1wbGUsIHdoZXJlIGEN CmhvbWUgZ2F0ZXdheSBpbXBsZW1lbnRzIGEgRE5TIHByb3h5IGFuZCBESENQ djQsIGJ1dCBub3QgREhDUHY2IG9yIEROUw0KYXV0b2NvbmZpZ3VyYXRpb24s IHRoZXJlIG1heSBiZSBubyBtZWNoYW5pc20gZm9yIGFsbG93aW5nIElQdjYg aG9zdHMgdG8NCnJlc29sdmUgdGhlIG5hbWVzIG9mIG90aGVyIElQdjYgaG9z dHMgb24gdGhlIGhvbWUgbmV0d29yay4gSW4gdGhpcw0Kc2l0dWF0aW9uLCBt RE5TIGlzIHVzZWZ1bCBmb3IgcmVzb2x1dGlvbiBvZiBkeW5hbWljIG5hbWVz LCBhbmQgaXQgd2lsbA0KYmUgZW5hYmxlZCBmb3IgdXNlIHdpdGggSVB2Niwg ZXZlbiB0aG91Z2ggaXQgaXMgZGlzYWJsZWQgZm9yIHVzZSB3aXRoDQpJUHY0 Lg0KDQo0LiAgU2VxdWVuY2Ugb2YgZXZlbnRzDQoNClRoZSBzZXF1ZW5jZSBv ZiBldmVudHMgZm9yIG11bHRpY2FzdCBETlMgdXNhZ2UgaXMgYXMgZm9sbG93 czoNCg0KMS4gSWYgYSBzZW5kZXIgbmVlZHMgdG8gcmVzb2x2ZSBhIHF1ZXJ5 IGZvciBhIG5hbWUNCiAgImhvc3QuZXhhbXBsZS5jb20ubG9jYWwuYXJwYSIs IHRoZW4gaXQgc2VuZHMgYSBtdWx0aWNhc3QgcXVlcnkgdG8gdGhlDQogICBM SU5LTE9DQUwgbXVsdGljYXN0IGFkZHJlc3MuDQoNCjIuIEEgcmVzcG9uZGVy IHJlc3BvbmRzIHRvIHRoaXMgcXVlcnkgb25seSBpZiBpdCBpcyBhdXRob3Jp dGF0aXZlDQogICBmb3IgdGhlIGRvbWFpbiBuYW1lICJob3N0LmV4YW1wbGUu Y29tLmxvY2FsLmFycGEiLiBUaGUgcmVzcG9uZGVyIHNlbmRzDQogICBhIHJl c3BvbnNlIHRvIHRoZSBzZW5kZXIgdmlhIHVuaWNhc3Qgb3ZlciBVRFAuDQoN CjMuIFVwb24gdGhlIHJlY2VwdGlvbiBvZiB0aGUgcmVzcG9uc2UsIHRoZSBz ZW5kZXIgdmVyaWZpZXMgdGhhdCB0aGUgSG9wDQogICBMaW1pdCBmaWVsZCBp biBJUHY2IGhlYWRlciBvciBUVEwgZmllbGQgaW4gSVB2NCBoZWFkZXIgKGRl cGVuZGluZyBvbg0KICAgdGhlIHByb3RvY29sIHVzZWQpIG9mIHRoZSByZXNw b25zZSBpcyBzZXQgdG8gMjU1LiBUaGUgc2VuZGVyIHRoZW4NCiAgIHZlcmlm aWVzIGNvbXBsaWFuY2Ugd2l0aCB0aGUgYWRkcmVzc2luZyByZXF1aXJlbWVu dHMgZm9yIElQdjQsDQogICBkZXNjcmliZWQgaW4gWzE4XSwgYW5kIElQdjYs IGRlc2NyaWJlZCBpbiBSRkMgMjM3MyBbOV0uIElmIHRoZXNlDQogICBjb25k aXRpb25zIGFyZSBtZXQsIHRoZW4gdGhlIHNlbmRlciB1c2VzIGFuZCBjYWNo ZXMgdGhlIHJldHVybmVkDQogICByZXNwb25zZS4gSWYgbm90LCB0aGVuIHRo ZSBzZW5kZXIgaWdub3JlcyB0aGUgcmVzcG9uc2UgYW5kIGNvbnRpbnVlcw0K ICAgd2FpdGluZyBmb3IgdGhlIHJlc3BvbnNlLg0KDQo1LiAgQ29uZmxpY3Qg cmVzb2x1dGlvbg0KDQpUaGVyZSBhcmUgc29tZSBzY2VuYXJpb3Mgd2hlbiBt dWx0aXBsZSByZXNwb25kZXJzIE1BWSByZXNwb25kIHRvIHRoZQ0Kc2FtZSBx dWVyeS4gVGhlcmUgYXJlIG90aGVyIHNjZW5hcmlvcyB3aGVuIG9ubHkgb25l IHJlc3BvbmRlciBtYXkNCnJlc3BvbmQgdG8gYSBxdWVyeS4gUmVzb3VyY2Ug cmVjb3JkcyBmb3Igd2hpY2ggdGhlIGxhdHRlciBxdWVyaWVzIGFyZQ0Kc3Vi bWl0dGVkIGFyZSByZWZlcnJlZCBhcyBVTklRVUUgdGhyb3VnaG91dCB0aGlz IGRvY3VtZW50LiBUaGUNCnVuaXF1ZW5lc3Mgb2YgYSByZXNvdXJjZSByZWNv cmQgZGVwZW5kcyBvbiBhIG5hdHVyZSBvZiB0aGUgbmFtZSBpbiB0aGUNCnF1 ZXJ5IGFuZCB0eXBlIG9mIHRoZSBxdWVyeS4gRm9yIGV4YW1wbGUgaXQgaXMg ZXhwZWN0ZWQgdGhhdDoNCg0KICAgLSBtdWx0aXBsZSBob3N0cyBtYXkgcmVz cG9uZCB0byBhIHF1ZXJ5IGZvciBhIFNSViB0eXBlIHJlY29yZA0KICAgLSBt dWx0aXBsZSBob3N0cyBtYXkgcmVzcG9uZCB0byBhIHF1ZXJ5IGZvciBhbiBB IHR5cGUgcmVjb3JkIGZvciBhDQogICAgIGNsdXN0ZXIgbmFtZSAoYXNzaWdu ZWQgdG8gbXVsdGlwbGUgaG9zdHMgaW4gdGhlIGNsdXN0ZXIpDQogICAtIG9u bHkgYSBzaW5nbGUgaG9zdCBtYXkgcmVzcG9uZCB0byBhIHF1ZXJ5IGZvciBh biBBIHR5cGUgcmVjb3JkIGZvcg0KICAgICBhIGhvc3RuYW1lLg0KDQoNCg0K DQpFc2lib3YsIEFib2JhICYgVGhhbGVyICAgICAgIFN0YW5kYXJkcyBUcmFj ayAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCg0KDQoNCg0KDQpJTlRF Uk5FVC1EUkFGVCAgICAgICAgICAgICAgIE11bHRpY2FzdCBETlMgICAgICAg ICAgICAgIDE1IE5vdmVtYmVyIDIwMDENCg0KDQpFdmVyeSByZXNwb25kZXIg dGhhdCByZXNwb25kcyB0byBhIG11bHRpY2FzdCBETlMgcXVlcnkgYW5kL29y IGR5bmFtaWMNCnVwZGF0ZSByZXF1ZXN0IEFORCBpbmNsdWRlcyBhIFVOSVFV RSByZWNvcmQgaW4gdGhlIHJlc3BvbnNlOg0KDQogICAxLiBNVVNUIHZlcmlm eSB0aGF0IHRoZXJlIGlzIG5vIG90aGVyIGhvc3Qgd2l0aGluIHRoZSBzY29w ZSBvZiB0aGUNCiAgICAgIG11bHRpY2FzdCBETlMgcXVlcnkgcHJvcGFnYXRp b24gdGhhdCBjYW4gcmV0dXJuIGEgRE5TIHJlY29yZA0KICAgICAgZm9yIHRo ZSBzYW1lIG5hbWUsIHR5cGUgYW5kIGNsYXNzLg0KICAgMi4gTVVTVCBOT1Qg aW5jbHVkZSBhIFVOSVFVRSByZXNvdXJjZSByZWNvcmQgaW4gdGhlDQogICAg ICByZXNwb25zZSB3aXRob3V0IGhhdmluZyB2ZXJpZmllZCBpdHMgdW5pcXVl bmVzcy4NCg0KV2hlcmUgYSBob3N0IGlzIGNvbmZpZ3VyZWQgdG8gcmVzcG9u ZCB0byBtdWx0aWNhc3QgRE5TIHF1ZXJpZXMgb24gbW9yZQ0KdGhhbiBvbmUg aW50ZXJmYWNlLCB0aGUgaG9zdCBNVVNUIHZlcmlmeSByZXNvdXJjZSByZWNv cmQgdW5pcXVlbmVzcyBvbg0KZWFjaCBpbnRlcmZhY2UgZm9yIGVhY2ggVU5J UVVFIHJlc291cmNlIHJlY29yZCB0aGF0IGNvdWxkIGJlIHVzZWQgb24NCnRo YXQgaW50ZXJmYWNlLiBUbyBhY2NvbXBsaXNoIHRoaXMsIHRoZSBob3N0IE1V U1QgbXVsdGljYXN0IGEgZHluYW1pYw0KRE5TIHVwZGF0ZSByZXF1ZXN0IGFz IHNwZWNpZmllZCBpbiBSRkMgMjEzNiBbMTFdIGZvciBlYWNoIG5ldyBVTklR VUUNCnJlc291cmNlIHJlY29yZC4gVW5pcXVlbmVzcyB2ZXJpZmljYXRpb24g aXMgY2FycmllZCBvdXQgd2hlbiB0aGUgaG9zdDoNCg0KICAtIHN0YXJ0cyB1 cCBvcg0KICAtIGlzIGNvbmZpZ3VyZWQgdG8gcmVzcG9uZCB0byB0aGUgbXVs dGljYXN0IEROUyBxdWVyaWVzIG9uDQogICAgc29tZSBpbnRlcmZhY2Ugb3IN CiAgLSBpcyBjb25maWd1cmVkIHRvIHJlc3BvbmQgdG8gdGhlIG11bHRpY2Fz dCBETlMgcXVlcmllcyB1c2luZw0KICAgIGFkZGl0aW9uYWwgVU5JUVVFIERO UyByZWNvcmRzLg0KDQpCZWxvdyB3ZSBkZXNjcmliZSB0aGUgZGF0YSB0byBi ZSBzcGVjaWZpZWQgaW4gdGhlIGR5bmFtaWMgdXBkYXRlDQpyZXF1ZXN0Og0K DQpIZWFkZXIgc2VjdGlvbg0KICAgICBjb250YWlucyB2YWx1ZXMgYWNjb3Jk aW5nIHRvIFJGQyAyMTM2IFsxMV0uDQoNClpvbmUgc2VjdGlvbg0KICAgICBU aGUgem9uZSBuYW1lIGluIHRoZSB6b25lIHNlY3Rpb24gTVVTVCBiZSBzZXQg dG8gdGhlIG5hbWUgb2YgdGhlDQogICAgIFVOSVFVRSByZWNvcmQuIFRoZSB6 b25lIHR5cGUgaW4gdGhlIHpvbmUgc2VjdGlvbiBNVVNUIGJlIHNldCB0bw0K ICAgICBTT0EuIFRoZSB6b25lIGNsYXNzIGluIHRoZSB6b25lIHNlY3Rpb24g TVVTVCBiZSBzZXQgdG8gdGhlIGNsYXNzIG9mDQogICAgIHRoZSBVTklRVUUg cmVjb3JkLg0KDQpQcmVyZXF1aXNpdGUgc2VjdGlvbg0KICAgICBUaGlzIHNl Y3Rpb24gTVVTVCBjb250YWluIGEgcmVjb3JkIHNldCB3aG9zZSBzZW1hbnRp Y3MgYXJlDQogICAgIGRlc2NyaWJlZCBpbiBSRkMgMjEzNiBbMTFdLCBTZWN0 aW9uIDIuNC4zICJSUnNldCBEb2VzIE5vdCBFeGlzdCIsDQogICAgIHJlcXVl c3RpbmcgdGhhdCBSUnMgd2l0aCB0aGUgTkFNRSBhbmQgVFlQRSBvZiB0aGUg VU5JUVVFIHJlY29yZCBkbw0KICAgICBub3QgZXhpc3QuDQoNClVwZGF0ZSBz ZWN0aW9uDQogICAgIFRoaXMgc2VjdGlvbiBNVVNUIGJlIGxlZnQgZW1wdHku DQoNCkFkZGl0aW9uYWwgc2VjdGlvbg0KICAgICBUaGlzIHNlY3Rpb24gaXMg c2V0IGFjY29yZGluZyB0byBSRkMgMjEzNi4NCg0KV2hlbiBhIGhvc3QgdGhh dCBvd25zIGEgVU5JUVVFIHJlY29yZCByZWNlaXZlcyBhIGR5bmFtaWMgdXBk YXRlIHJlcXVlc3QNCnRoYXQgcmVxdWVzdHMgdGhhdCB0aGUgVU5JUVVFIHJl c291cmNlIHJlY29yZCBzZXQgZG9lcyBub3QgZXhpc3QsIHRoZQ0KDQoNCg0K RXNpYm92LCBBYm9iYSAmIFRoYWxlciAgICAgICBTdGFuZGFyZHMgVHJhY2sg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoNCg0KDQoNCg0KSU5URVJO RVQtRFJBRlQgICAgICAgICAgICAgICBNdWx0aWNhc3QgRE5TICAgICAgICAg ICAgICAxNSBOb3ZlbWJlciAyMDAxDQoNCg0KaG9zdCBNVVNUIHJlc3BvbmQg dmlhIHVuaWNhc3Qgd2l0aCB0aGUgWVhSUlNFVCBlcnJvciwgYWNjb3JkaW5n IHRvIHRoZQ0KcnVsZXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMyBvZiBSRkMg MjEzNiBbMTFdLg0KDQpBZnRlciBjbGllbnQgcmVjZWl2ZXMgYW4gWVhSUlNF VCByZXNwb25zZSB0byBpdHMgZHluYW1pYyB1cGRhdGUgcmVxdWVzdA0KdGhh dCBhIFVOSVFVRSByZXNvdXJjZSByZWNvcmQgZG9lcyBub3QgZXhpc3QsIHRo ZSBob3N0IE1VU1QgY2hlY2sNCndoZXRoZXIgdGhlIHJlc3BvbnNlIGFycml2 ZWQgb24gYW5vdGhlciBpbnRlcmZhY2UuIElmIHRoaXMgaXMgdGhlIGNhc2Us DQp0aGVuIHRoZSBjbGllbnQgY2FuIHVzZSB0aGUgVU5JUVVFIHJlc291cmNl IHJlY29yZCBpbiByZXNwb25zZSB0bw0KbXVsdGljYXN0IHF1ZXJpZXMgYW5k IGR5bmFtaWMgdXBkYXRlIHJlcXVlc3RzLiBJZiBub3QsIHRoZW4gaXQgTVVT VCBOT1QNCnVzZSB0aGUgVU5JUVVFIHJlc291cmNlIHJlY29yZCBpbiByZXNw b25zZSB0byBtdWx0aWNhc3QgcXVlcmllcyBhbmQNCmR5bmFtaWMgdXBkYXRl IHJlcXVlc3RzLg0KDQpOb3RlIHRoYXQgdGhpcyBuYW1lIGNvbmZsaWN0IGRl dGVjdGlvbiBtZWNoYW5pc20gZG9lc24ndCBwcmV2ZW50IG5hbWUNCmNvbmZs aWN0cyB3aGVuIHByZXZpb3VzbHkgcGFydGl0aW9uZWQgc2VnbWVudHMgYXJl IGNvbm5lY3RlZCBieSBhDQpicmlkZ2UuICBJbiBzdWNoIGEgc2l0dWF0aW9u LCBuYW1lIGNvbmZsaWN0cyBhcmUgZGV0ZWN0ZWQgd2hlbiBhIHNlbmRlcg0K cmVjZWl2ZXMgbW9yZSB0aGFuIG9uZSByZXNwb25zZSB0byBpdHMgbXVsdGlj YXN0IEROUyBxdWVyeS4gIEluIHRoaXMNCmNhc2UsIHRoZSBzZW5kZXIgc2Vu ZHMgdGhlIGZpcnN0IHJlc3BvbnNlIHRoYXQgaXQgcmVjZWl2ZWQgdG8gYWxs DQpyZXNwb25kZXJzIHRoYXQgcmVzcG9uZGVkIHRvIHRoaXMgcXVlcnkgZXhj ZXB0IHRoZSBmaXJzdCBvbmUsIHVzaW5nDQp1bmljYXN0LiBBIGhvc3QgdGhh dCByZWNlaXZlcyBhIHF1ZXJ5IHJlc3BvbnNlIGNvbnRhaW5pbmcgYSBVTklR VUUNCnJlc291cmNlIHJlY29yZCB0aGF0IGl0IG93bnMsIGV2ZW4gaWYgaXQg ZGlkbid0IHNlbmQgc3VjaCBhIHF1ZXJ5LCBNVVNUDQp2ZXJpZnkgdGhhdCBu byBvdGhlciBob3N0IHdpdGhpbiB0aGUgbXVsdGljYXN0IEROUyBzY29wZSBp cw0KYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIHNhbWUgbmFtZSwgdXNpbmcgdGhl IGR5bmFtaWMgRE5TIHVwZGF0ZSByZXF1ZXN0DQptZWNoYW5pc20gZGVzY3Jp YmVkIGFib3ZlLg0KDQpCYXNlZCBvbiB0aGUgcmVzdWx0LCB0aGUgaG9zdCBk ZXRlY3RzIHdoZXRoZXIgdGhlcmUgaXMgYSBuYW1lIGNvbmZsaWN0DQphbmQg YWN0cyBhcyBkZXNjcmliZWQgYWJvdmUuDQoNCjUuMS4gIENvbnNpZGVyYXRp b25zIGZvciBNdWx0aXBsZSBJbnRlcmZhY2VzDQoNCkEgbXVsdGktaG9tZWQg aG9zdCBtYXkgZWxlY3QgdG8gY29uZmlndXJlIG11bHRpY2FzdCBETlMgb24g b25seSBvbmUgb2YNCml0cyBhY3RpdmUgaW50ZXJmYWNlcy4gSW4gbWFueSBz aXR1YXRpb25zIHRoaXMgd2lsbCBiZSBhZGVxdWF0ZS4NCkhvd2V2ZXIsIHNo b3VsZCBhIGhvc3Qgd2lzaCB0byBjb25maWd1cmUgbXVsdGljYXN0IEROUyBv biBtb3JlIHRoYW4gb25lDQpvZiBpdHMgYWN0aXZlIGludGVyZmFjZXMsIHRo ZXJlIGFyZSBzb21lIGFkZGl0aW9uYWwgcHJlY2F1dGlvbnMgaXQgTVVTVA0K dGFrZS4gSW1wbGVtZW50ZXJzIHdobyBhcmUgbm90IHBsYW5uaW5nIHRvIHN1 cHBvcnQgbXVsdGljYXN0IEROUyBvbg0KbXVsdGlwbGUgaW50ZXJmYWNlcyBz aW11bHRhbmVvdXNseSBtYXkgc2tpcCB0aGlzIHNlY3Rpb24uDQoNCkEgbXVs dGktaG9tZWQgaG9zdCBjaGVja3MgdGhlIHVuaXF1ZW5lc3Mgb2YgVU5JUVVF IHJlY29yZHMgYXMgZGVzY3JpYmVkDQppbiBTZWN0aW9uIDUuIFRoZSBzaXR1 YXRpb24gaXMgaWxsdXN0cmF0ZWQgaW4gZmlndXJlIDEgYmVsb3c6DQoNCiAg ICAgLS0tLS0tLS0tLSAgLS0tLS0tLS0tLQ0KICAgICAgfCAgICAgIHwgICAg fCAgICAgIHwNCiAgICAgW0FdICAgIFtteWhvc3RdICAgW215aG9zdF0NCg0K ICAgRmlndXJlIDEuIExJTktMT0NBTCBuYW1lIGNvbmZsaWN0DQoNCkluIHRo aXMgc2l0dWF0aW9uLCB0aGUgbXVsdGktaG9tZWQgbXlob3N0IHdpbGwgcHJv YmUgZm9yLCBhbmQgZGVmZW5kLA0KaXRzIGhvc3QgbmFtZSBvbiBib3RoIGlu dGVyZmFjZXMuIEEgY29uZmxpY3Qgd2lsbCBiZSBkZXRlY3RlZCBvbiBvbmUN CmludGVyZmFjZSwgYnV0IG5vdCB0aGUgb3RoZXIuIFRoZSBtdWx0aS1ob21l ZCBteWhvc3Qgd2lsbCBub3QgYmUgYWJsZSB0bw0KcmVzcG9uZCB3aXRoIGEg aG9zdCBSUiBmb3IgIm15aG9zdCIgb24gdGhlIGludGVyZmFjZSBvbiB0aGUg cmlnaHQgKHNlZQ0KDQoNCg0KRXNpYm92LCBBYm9iYSAmIFRoYWxlciAgICAg ICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTFd DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICBNdWx0 aWNhc3QgRE5TICAgICAgICAgICAgICAxNSBOb3ZlbWJlciAyMDAxDQoNCg0K RmlndXJlIDEpLiBUaGUgbXVsdGktaG9tZWQgaG9zdCBtYXksIGhvd2V2ZXIs IGJlIGNvbmZpZ3VyZWQgdG8gdXNlIHRoZQ0KIm15aG9zdCIgbmFtZSBvbiB0 aGUgaW50ZXJmYWNlIG9uIHRoZSBsZWZ0Lg0KDQpTaW5jZSBuYW1lcyBhcmUg b25seSB1bmlxdWUgcGVyLWxpbmssIGhvc3RzIG9uIGRpZmZlcmVudCBsaW5r cyBjb3VsZCBiZQ0KdXNpbmcgdGhlIHNhbWUgbmFtZS4gIElmIGFuIG1ETlMg Y2xpZW50IHNlbmRzIHJlcXVlc3RzIG92ZXIgbXVsdGlwbGUNCmludGVyZmFj ZXMsIGFuZCByZWNlaXZlcyByZXBsaWVzIGZyb20gbW9yZSB0aGFuIG9uZSwg dGhlIHJlc3VsdCByZXR1cm5lZA0KdG8gdGhlIGNsaWVudCBpcyBkZWZpbmVk IGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi4gIFRoZSBzaXR1YXRpb24gaXMNCmls bHVzdHJhdGVkIGluIGZpZ3VyZSAyIGJlbG93Lg0KDQogICAgIC0tLS0tLS0t LS0gIC0tLS0tLS0tLS0NCiAgICAgIHwgICAgICB8ICAgIHwgICAgIHwNCiAg ICAgW0FdICAgIFtteWhvc3RdICAgW0FdDQoNCg0KICAgRmlndXJlIDIuIE9m Zi1zZWdtZW50IG5hbWUgY29uZmxpY3QNCg0KSWYgaG9zdCBteWhvc3QgaXMg Y29uZmlndXJlZCB0byB1c2UgbUROUyBvbiBib3RoIGludGVyZmFjZXMsIGl0 IHdpbGwNCnNlbmQgbUROUyBxdWVyaWVzIG9uIGJvdGggaW50ZXJmYWNlcy4g IFdoZW4gaG9zdCBteWhvc3Qgc2VuZHMgYSBxdWVyeQ0KZm9yIHRoZSBob3N0 IFJSIGZvciBuYW1lICJBIiBpdCB3aWxsIHJlY2VpdmUgYSByZXNwb25zZSBm cm9tIGhvc3RzIG9uDQpib3RoIGludGVyZmFjZXMuICBIb3N0IG15aG9zdCB3 aWxsIHRoZW4gZm9yd2FyZCBhIHJlc3BvbnNlIGZyb20gdGhlDQpmaXJzdCBy ZXNwb25kZXIgdG8gdGhlIHNlY29uZCByZXNwb25kZXIsIHdobyB3aWxsIGF0 dGVtcHQgdG8gdmVyaWZ5IHRoZQ0KdW5pcXVlbmVzcyBvZiBob3N0IFJSIGZv ciBpdHMgbmFtZSwgYnV0IHdpbGwgbm90IGRpc2NvdmVyIGEgY29uZmxpY3Qs DQpzaW5jZSB0aGUgY29uZmxpY3RpbmcgaG9zdCByZXNpZGVzIG9uIGEgZGlm ZmVyZW50IGxpbmsuICBUaGVyZWZvcmUgaXQNCndpbGwgY29udGludWUgdXNp bmcgaXRzIG5hbWUuDQoNCkluZGVlZCwgaG9zdCBteWhvc3QgY2Fubm90IGRp c3Rpbmd1aXNoIGJldHdlZW4gdGhlIHNpdHVhdGlvbiBzaG93biBpbg0KRmln dXJlIDIsIGFuZCB0aGF0IHNob3duIGluIEZpZ3VyZSAzIHdoZXJlIG5vIGNv bmZsaWN0IGV4aXN0czoNCg0KDQogICAgICAgICAgICAgW0FdDQogICAgICAg ICAgICB8ICAgfA0KICAgICAgICAtLS0tLSAgIC0tLS0tDQogICAgICAgICAg ICB8ICAgfA0KICAgICAgICAgICBbbXlob3N0XQ0KDQogICBGaWd1cmUgMy4g TXVsdGlwbGUgcGF0aHMgdG8gc2FtZSBob3N0DQoNClRoaXMgaWxsdXN0cmF0 ZXMgdGhhdCB0aGUgcHJvcG9zZWQgbmFtZSBjb25mbGljdCByZXNvbHV0aW9u IG1lY2hhbmlzbQ0KZG9lcyBub3Qgc3VwcG9ydCBkZXRlY3Rpb24gb3IgcmVz b2x1dGlvbiBvZiBjb25mbGljdHMgYmV0d2VlbiBob3N0cyBvbg0KZGlmZmVy ZW50IGxpbmtzLiAgVGhpcyBwcm9ibGVtIGNhbiBhbHNvIG9jY3VyIHdpdGgg dW5pY2FzdCBETlMgd2hlbiBhDQptdWx0aS1ob21lZCBob3N0IGlzIGNvbm5l Y3RlZCB0byB0d28gZGlmZmVyZW50IG5ldHdvcmtzIHdpdGggc2VwYXJhdGVk DQpuYW1lIHNwYWNlcy4gSXQgaXMgbm90IHRoZSBpbnRlbnQgb2YgdGhpcyBk b2N1bWVudCB0byBhZGRyZXNzIHRoZSBpc3N1ZQ0Kb2YgdW5pcXVlbmVzcyBv ZiBuYW1lcyB3aXRoaW4gRE5TLg0KDQo1LjIuICBBUEkgaXNzdWVzDQoNClJG QyAyNTUzIFsxM10gcHJvdmlkZXMgYW4gQVBJIHdoaWNoIGNhbiBwYXJ0aWFs bHkgc29sdmUgdGhlIG5hbWUNCmFtYmlndWl0eSBwcm9ibGVtIGZvciBhcHBs aWNhdGlvbnMgd3JpdHRlbiB0byB1c2UgdGhpcyBBUEksIHNpbmNlIHRoZQ0K DQoNCg0KRXNpYm92LCBBYm9iYSAmIFRoYWxlciAgICAgICBTdGFuZGFyZHMg VHJhY2sgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoNCg0KDQoNCg0K SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICBNdWx0aWNhc3QgRE5TICAg ICAgICAgICAgICAxNSBOb3ZlbWJlciAyMDAxDQoNCg0Kc29ja2FkZHJfaW42 IHN0cnVjdHVyZSBleHBvc2VzIHRoZSBzY29wZSB3aXRoaW4gd2hpY2ggZWFj aCBzY29wZWQNCmFkZHJlc3MgZXhpc3RzLCBhbmQgdGhpcyBzdHJ1Y3R1cmUg Y2FuIGJlIHVzZWQgZm9yIGJvdGggSVB2NCAodXNpbmcNCnY0LW1hcHBlZCBJ UHY2IGFkZHJlc3NlcykgYW5kIElQdjYgYWRkcmVzc2VzLg0KDQpGb2xsb3dp bmcgdGhlIGV4YW1wbGUgaW4gRmlndXJlIDIsIGFuIGFwcGxpY2F0aW9uIG9u ICdteWhvc3QnIGlzc3VlcyB0aGUNCnJlcXVlc3QgZ2V0YWRkcmluZm8oIkEi LCAuLi4pIHdpdGggYWlfZmFtaWx5PUFGX0lORVQ2IGFuZA0KYWlfZmxhZ3M9 QUlfQUxMfEFJX1Y0TUFQUEVELiAgbUROUyByZXF1ZXN0cyB3aWxsIGJlIHNl bnQgZnJvbSBib3RoDQppbnRlcmZhY2VzIGFuZCB0aGUgcmVzb2x2ZXIgbGli cmFyeSB3aWxsIHJldHVybiBhIGxpc3QgY29udGFpbmluZw0KbXVsdGlwbGUg YWRkcmluZm8gc3RydWN0dXJlcywgZWFjaCB3aXRoIGFuIGFzc29jaWF0ZWQg c29ja2FkZHJfaW42DQpzdHJ1Y3R1cmUuICBUaGlzIGxpc3Qgd2lsbCB0aHVz IGNvbnRhaW4gdGhlIElQdjQgYW5kIElQdjYgYWRkcmVzc2VzIG9mDQpib3Ro IGhvc3RzIHJlc3BvbmRpbmcgdG8gdGhlIG5hbWUgJ0EnLiAgTGluay1sb2Nh bCBhZGRyZXNzZXMgd2lsbCBoYXZlIGENCnNpbjZfc2NvcGVfaWQgdmFsdWUg dGhhdCBkaXNhbWJpZ3VhdGVzIHdoaWNoIGludGVyZmFjZSBpcyB1c2VkIHRv IHJlYWNoDQp0aGUgYWRkcmVzcy4gIE9mIGNvdXJzZSwgdG8gdGhlIGFwcGxp Y2F0aW9uLCBGaWd1cmVzIDIgYW5kIDMgYXJlIHN0aWxsDQppbmRpc3Rpbmd1 aXNoYWJsZSwgYnV0IHRoaXMgQVBJIGFsbG93cyB0aGUgYXBwbGljYXRpb24g dG8gY29tbXVuaWNhdGUNCnN1Y2Nlc3NmdWxseSB3aXRoIGFueSBhZGRyZXNz IGluIHRoZSBsaXN0Lg0KDQo2LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQpU aGlzIHNwZWNpZmljYXRpb24gcmVxdWlyZXMgYWxsb2NhdGlvbiBvZiBhIGxp bmsgc2NvcGUgSVB2NCBtdWx0aWNhc3QNCmFkZHJlc3NlcyBmb3IgdXNlIGJ5 IG11bHRpY2FzdCBETlMuDQoNCjcuICBBUlBBIGRvbWFpbiBjb25zaWRlcmF0 aW9ucw0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgdXNlIG9mIGEg bmV3IHN1Yi1kb21haW4gb2YgdGhlICJBUlBBIg0KZG9tYWluLiAgQWNjb3Jk aW5nIHRvIFNlY3Rpb24gMi4xIG9mIHRoZSBBUlBBIEd1aWRlbGluZXMgWzEy XSwgdGhpcw0Kc3BlY2lmaWNhdGlvbiByZXF1aXJlcyBkZXNjcmlwdGlvbiBh bmQganVzdGlmaWNhdGlvbi4NCg0KVGhlICdsb2NhbC5hcnBhJyBkb21haW4g aXMgdXNlZCB0byBkaXN0aW5ndWlzaCBhIGxvY2FsIG5hbWVzcGFjZS4gIFRo aXMNCm5hbWVzcGFjZSBkaWZmZXJzIGZyb20gb3RoZXJzIGluIHRoZSBmb2xs b3dpbmcgcmVzcGVjdHM6DQoNCiAgICAtIE5hbWUgc2VydmVycyByZXNwb25k aW5nIHRvIHJlcXVlc3RzIGZvciBuYW1lcyBpbiB0aGlzDQogICAgICBkb21h aW4gaGF2ZSBkaWZmZXJlbnQgcnVsZXMgY29uY2VybmluZyBhdXRob3JpdHku ICBBcw0KICAgICAgZXhwbGFpbmVkIGluIFNlY3Rpb24gMi4xLCBtRE5TIHNl cnZlcnMgaGF2ZSBsaW1pdGVkDQogICAgICBzY29wZSBvZiBhdXRob3JpdHks IG5vdCBleHRlbmRpbmcgdG8gc3ViLWRvbWFpbnMgb2YNCiAgICAgIGRvbWFp biB0aGV5IGFyZSBhdXRob3JpdGF0aXZlIGZvci4NCg0KICAgIC0gRE5TIHNl cnZlcnMgU0hPVUxEIE5PVCBmb3J3YXJkIG9yIHJlY3Vyc2l2ZWx5IHJlc29s dmUNCiAgICAgIHF1ZXJpZXMgZm9yIGRvbWFpbiBuYW1lcyBpbiB0aGUgbG9j YWwuYXJwYSBkb21haW4gLSBpZiB0aGUNCiAgICAgIHNlcnZlciBjYW5ub3Qg YW5zd2VyIHRoZSBxdWVyeSBmcm9tIGl0cyBvd24gZGF0YWJhc2UsDQogICAg ICBpdCBNVVNUIE5PVCByZXBseS4NCg0KICAgIC0gSG9zdHMgbWF5IGRlcml2 ZSB0aGVpciBvd24gbmFtZXMgaW4gdGhpcyBuYW1lc3BhY2UsDQogICAgICBp bmRlcGVuZGVudCBvZiBjZW50cmFsaXplZCBhdXRob3JpemF0aW9uIGFuZCBy ZWdpc3RyYXRpb24NCiAgICAgIChhcyBkZWZpbmVkIGluIHNlY3Rpb24gMyBh bmQgc2VjdGlvbiA1KS4NCg0KICAgIC0gVGhlcmUgaXMgbm8gZGVsZWdhdGlv biBvciBhZG1pbmlzdHJhdGl2ZSBzdHJ1Y3R1cmUgdG8NCiAgICAgIHN1Yi1k b21haW5zIG9mICcubG9jYWwuYXJwYScuDQoNCg0KDQoNCkVzaWJvdiwgQWJv YmEgJiBUaGFsZXIgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAg ICAgICAgIFtQYWdlIDEzXQ0KDQoNCg0KDQoNCklOVEVSTkVULURSQUZUICAg ICAgICAgICAgICAgTXVsdGljYXN0IEROUyAgICAgICAgICAgICAgMTUgTm92 ZW1iZXIgMjAwMQ0KDQoNCkhvdyBwcm90b2NvbCBvYmplY3RzIGFyZSBtYXBw ZWQgaW50byBsb29rdXAga2V5czoNCg0KICAgICAgTmFtZXMgYXJlIGFzc29j aWF0ZWQgd2l0aCByZXNvdXJjZXMgd2hpY2ggY2FuIGJlIHJlcXVlc3RlZA0K ICAgICAgYWNjb3JkaW5nIHRvIHRoZSBETlMgcHJvdG9jb2wuICBIb3dldmVy LCByZWN1cnNpdmUgbG9va3VwDQogICAgICBpcyBpbXBvc3NpYmxlLiAgRnVy dGhlciwgbUROUyBzcGVjaWZpZXMgb25seSB0aGUgdXNlIG9mDQogICAgICBt dWx0aWNhc3QgdG8gdHJhbnNtaXQgdGhlc2UgcmVxdWVzdHMuDQoNCjguICBS ZWZlcmVuY2VzDQoNClsxXSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50DQogICAgIExl dmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNClsyXSAg TWV5ZXIsIEQuLCAiQWRtaW5pc3RyYXRpdmVseSBTY29wZWQgSVAgTXVsdGlj YXN0IiwgQkNQIDIzLCBSRkMNCiAgICAgMjM2NSwgSnVseSAxOTk4Lg0KDQpb M10gIFNtaXRoLCBDLiwgIlRoZSBOYW1lIFNlcnZpY2UgU2VhcmNoIE9wdGlv biBmb3IgREhDUCIsIFJGQyAyOTM3LA0KICAgICBTZXB0ZW1iZXIgMjAwMC4N Cg0KWzRdICBNb2NrYXBldHJpcywgUC4sICJEb21haW4gTmFtZXMgLSBJbXBs ZW1lbnRhdGlvbiBhbmQgU3BlY2lmaWNhdGlvbiIsDQogICAgIFJGQyAxMDM1 LCBOb3ZlbWJlciAxOTg3Lg0KDQpbNV0gIE1vY2thcGV0cmlzLCBQLiwgIkRP TUFJTiBOQU1FUyAtIENPTkNFUFRTIEFORCBGQUNJTElUSUVTIiwgUkZDDQog ICAgIDEwMzQsIE5vdmVtYmVyLCAxOTg3Lg0KDQpbNl0gIEd1dHRtYW4sIEUu LCAiREhDUCBtRE5TIEVuYWJsZSBPcHRpb24iLCBJbnRlcm5ldCBkcmFmdCAo d29yayBpbg0KICAgICBwcm9ncmVzcyksIGRyYWZ0LWd1dHRtYW4tbWRucy1l bmFibGUtMDEudHh0LCBKdWx5IDIwMDEuDQoNCls3XSAgQWx2ZXN0cmFuZCwg SC4gYW5kIFQuIE5hcnRlbiwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4g SUFOQQ0KICAgICBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBC Q1AgMjYsIFJGQyAyNDM0LCBPY3RvYmVyIDE5OTguDQoNCls4XSAgRGVlcmlu ZywgUy4gYW5kIFIuIEhpbmRlbiwgIkludGVybmV0IFByb3RvY29sLCBWZXJz aW9uIDYgKElQdjYpDQogICAgIFNwZWNpZmljYXRpb24iLCBSRkMgMjQ2MCwg RGVjZW1iZXIgMTk5OC4NCg0KWzldICBIaW5kZW4sIFIuLCBEZWVyaW5nLCBT LiwgIklQIFZlcnNpb24gNiBBZGRyZXNzaW5nIEFyY2hpdGVjdHVyZSIsDQog ICAgIFJGQyAyMzczLCBKdWx5IDE5OTguDQoNClsxMF0gSW5mb3JtYXRpb24g dGVjaG5vbG9neSAtIFRlbGVjb21tdW5pY2F0aW9ucyBhbmQgaW5mb3JtYXRp b24NCiAgICAgZXhjaGFuZ2UgYmV0d2VlbiBzeXN0ZW1zIC0gTG9jYWwgYW5k IG1ldHJvcG9saXRhbiBhcmVhIG5ldHdvcmtzIC0NCiAgICAgU3BlY2lmaWMg UmVxdWlyZW1lbnRzIFBhcnQgMTE6ICBXaXJlbGVzcyBMQU4gTWVkaXVtIEFj Y2VzcyBDb250cm9sDQogICAgIChNQUMpIGFuZCBQaHlzaWNhbCBMYXllciAo UEhZKSBTcGVjaWZpY2F0aW9ucywgSUVFRSBTdGQuDQogICAgIDgwMi4xMS0x OTk3LCAxOTk3Lg0KDQpbMTFdIFZpeGllLCBQLiwgVGhvbXNvbiwgUy4sIFJl a2h0ZXIsIFkuLCBCb3VuZCwgSi4sICJEeW5hbWljIFVwZGF0ZXMgaW4NCiAg ICAgdGhlIERvbWFpbiBOYW1lIFN5c3RlbSAoRE5TIFVQREFURSkiLCBSRkMg MjEzNiwgQXByaWwgMTk5Ny4NCg0KWzEyXSBIdXN0b24sIEcuLCAiTWFuYWdl bWVudCBHdWlkZWxpbmVzICYgT3BlcmF0aW9uYWwgUmVxdWlyZW1lbnRzIGZv cg0KICAgICB0aGUgSW50ZXJuZXQgSW5mcmFzdHJ1Y3R1cmUgRG9tYWluICgi QVJQQSIpIiwgSW50ZXJuZXQgZHJhZnQgKHdvcmsNCiAgICAgaW4gcHJvZ3Jl c3MpLCBkcmFmdC1pYWItYXJwYS0wMy50eHQsICBKdWx5IDIwMDEuDQoNCg0K DQpFc2lib3YsIEFib2JhICYgVGhhbGVyICAgICAgIFN0YW5kYXJkcyBUcmFj ayAgICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCg0KDQoNCg0KDQpJTlRF Uk5FVC1EUkFGVCAgICAgICAgICAgICAgIE11bHRpY2FzdCBETlMgICAgICAg ICAgICAgIDE1IE5vdmVtYmVyIDIwMDENCg0KDQpbMTNdIEdpbGxpZ2FuLCBS LiwgVGhvbXNvbiwgUy4sIEJvdW5kLCBKLiwgU3RldmVucywgVy4sICJCYXNp YyBTb2NrZXQNCiAgICAgSW50ZXJmYWNlIEV4dGVuc2lvbnMgZm9yIElQdjYi LCBSRkMgMjU1MywgTWFyY2ggMTk5OS4NCg0KWzE0XSBDcmF3Zm9yZCwgTWF0 dCwgIklQdjYgTm9kZSBJbmZvcm1hdGlvbiBRdWVyaWVzIiwgSW50ZXJuZXQg ZHJhZnQNCiAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBkcmFmdC1pZXRmLWlw bi1nd2ctaWNtcC1uYW1lLWxvb2t1cHMtMDcudHh0LA0KICAgICBBdWd1c3Qg MjAwMC4NCg0KWzE1XSBFYXN0bGFrZSwgRC4sICJEb21haW4gTmFtZSBTeXN0 ZW0gU2VjdXJpdHkgRXh0ZW5zaW9ucyIsIFJGQyAyNTM1LA0KICAgICBNYXJj aCAxOTk5Lg0KDQpbMTZdIFJpdmVzdCwgUi4sICJUaGUgTUQ1IE1lc3NhZ2Ut RGlnZXN0IEFsZ29yaXRobSIsIFJGQyAxMzIxLCBBcHJpbA0KICAgICAxOTky Lg0KDQpbMTddIEFib2JhLCBCLiwgIkRIQ1AgRG9tYWluIFNlYXJjaCBPcHRp b24iLCBJbnRlcm5ldCBkcmFmdCAod29yayBpbg0KICAgICBwcm9ncmVzcyks IGRyYWZ0LWFib2JhLWRoYy1kb21zZWFyY2gtMDgudHh0LCBOb3ZlbWJlciAy MDAxLg0KDQpbMThdIENoZXNoaXJlLCBTLiwgQWJvYmEsIEIuLCAiRHluYW1p YyBDb25maWd1cmF0aW9uIG9mIElQdjQgTGluay1Mb2NhbA0KICAgICBBZGRy ZXNzZXMiLCBJbnRlcm5ldCBkcmFmdCAod29yayBpbiBwcm9ncmVzcyksIGRy YWZ0LWlldGYtemVyb2NvbmYtDQogICAgIGlwdjQtbGlua2xvY2FsLTA1LnR4 dCwgTm92ZW1iZXIgMjAwMS4NCg0KWzE5XSBUaGFsZXIsIEQuLCBIYWdpbm8s IEkuLCAiSVB2NiBTdGF0ZWxlc3MgRE5TIERpc2NvdmVyeSIsIEludGVybmV0 DQogICAgIGRyYWZ0ICh3b3JrIGluIHByb2dyZXNzKSwgZHJhZnQtaWV0Zi1p cG5nd2ctZG5zLWRpc2NvdmVyeS0wMi50eHQsDQogICAgIEp1bHkgMjAwMS4N Cg0KWzIwXSBTdGV2ZW5zLCBXLiwgVGhvbWFzLCBNLiwgIkFkdmFuY2VkIFNv Y2tldHMgQVBJIGZvciBJUHY2IiwgUkZDIDIyOTIsDQogICAgIEZlYnJ1YXJ5 IDE5OTguDQoNCjkuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpUaGlz IGRyYWZ0IGRvZXMgbm90IHByZXNjcmliZSBhIG1lYW5zIG9mIHNlY3VyaW5n IHRoZSBtdWx0aWNhc3QgRE5TDQptZWNoYW5pc20uIEl0IGlzIHBvc3NpYmxl IHRoYXQgaG9zdHMgd2lsbCBhbGxvY2F0ZSBjb25mbGljdGluZyBuYW1lcyBm b3INCmEgcGVyaW9kIG9mIHRpbWUsIG9yIHRoYXQgbm9uLWNvbmZvcm1pbmcg aG9zdHMgd2lsbCBhdHRlbXB0IHRvIGRlbnkNCnNlcnZpY2UgdG8gb3RoZXIg aG9zdHMgYnkgYWxsb2NhdGluZyB0aGUgc2FtZSBuYW1lLiBTdWNoIGF0dGFj a3MgYWxzbw0KYWxsb3cgbm9kZXMgdG8gcmVjZWl2ZSBwYWNrZXRzIGRlc3Rp bmVkIGZvciBvdGhlciBub2Rlcy4gVGhlIHByb3RvY29sDQpyZWR1Y2VzIHRo ZSBleHBvc3VyZSB0byBzdWNoIHRocmVhdHMgaW4gdGhlIGFic2VuY2Ugb2Yg YXV0aGVudGljYXRpb24gYnkNCmlnbm9yaW5nIG11bHRpY2FzdCBETlMgcXVl cnkgcmVzcG9uc2UgcGFja2V0cyByZWNlaXZlZCBmcm9tIG9mZi1saW5rDQpz ZW5kZXJzLg0KDQpJbiBhbGwgcmVjZWl2ZWQgcmVzcG9uc2VzLCB0aGUgSG9w IExpbWl0IGZpZWxkIGluIElQdjYgYW5kIHRoZSBUVEwgZmllbGQNCmluIElQ djQgYXJlIHZlcmlmaWVkIHRvIGNvbnRhaW4gMjU1LCB0aGUgbWF4aW11bSBs ZWdhbCB2YWx1ZS4gIFNpbmNlDQpyb3V0ZXJzIGRlY3JlbWVudCB0aGUgSG9w IExpbWl0IG9uIGFsbCBwYWNrZXRzIHRoZXkgZm9yd2FyZCwgcmVjZWl2ZWQN CnBhY2tldHMgY29udGFpbmluZyBhIEhvcCBMaW1pdCBvZiAyNTUgbXVzdCBo YXZlIG9yaWdpbmF0ZWQgZnJvbSBhDQpuZWlnaGJvci4NCg0KVGhlc2UgdGhy ZWF0cyBhcmUgbW9zdCBzZXJpb3VzIGluIHdpcmVsZXNzIG5ldHdvcmtzIHN1 Y2ggYXMgODAyLjExLA0Kc2luY2UgYXR0YWNrZXJzIG9uIGEgd2lyZWQgbmV0 d29yayB3aWxsIHJlcXVpcmUgcGh5c2ljYWwgYWNjZXNzIHRvIHRoZQ0KaG9t ZSBuZXR3b3JrLCB3aGlsZSB3aXJlbGVzcyBhdHRhY2tlcnMgbWF5IHJlc2lk ZSBvdXRzaWRlIHRoZSBob21lLg0KTGluay1sYXllciBzZWN1cml0eSB3aWxs IHNlcnZlIHRvIHNlY3VyZSBtRE5TIGFnYWluc3QgdGhlIGFib3ZlIHRocmVh dHMNCg0KDQoNCkVzaWJvdiwgQWJvYmEgJiBUaGFsZXIgICAgICAgU3RhbmRh cmRzIFRyYWNrICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDQoNCg0K DQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgTXVsdGljYXN0IERO UyAgICAgICAgICAgICAgMTUgTm92ZW1iZXIgMjAwMQ0KDQoNCmlmIGl0IGlz IGF2YWlsYWJsZS4gRm9yIGV4YW1wbGUsIHdoZXJlIDgwMi4xMSAiV2lyZWQg RXF1aXZhbGVuY3kNClByaXZhY3kiIChXRVApIFsxMF0gaXMgaW1wbGVtZW50 ZWQsIGEgY2FzdWFsIGF0dGFja2VyIGlzIGxpa2VseSB0byBiZQ0KZGV0ZXJy ZWQgZnJvbSBnYWluaW5nIGFjY2VzcyB0byB0aGUgaG9tZSBuZXR3b3JrLg0K DQpUaGUgIG1lY2hhbmlzbSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCBkb2Vz IG5vdCByZXF1aXJlIHVzZSBvZiBETlNTRUMuDQpBcyBhIHJlc3VsdCwgcmVz cG9uc2VzIHRvIG11bHRpY2FzdCBETlMgcXVlcmllcyBNQVkgTk9UIGJlDQph dXRoZW50aWNhdGVkLiBJZiBhIG5ldHdvcmsgY29udGFpbnMgYSAic2lnbmVk IGtleSBkaXN0cmlidXRpb24gY2VudGVyIg0KZm9yIHNvbWUgb2YgdGhlIERO UyB6b25lcyB0aGF0IHRoZSByZXNwb25kZXJzIGFyZSBhdXRob3JpdGF0aXZl IGZvciwgYW5kDQpzZW5kZXJzIG9uIHRoYXQgbmV0d29yayBhcmUgY29uZmln dXJlZCB3aXRoIHRoZSBrZXkgZm9yIHRoZSB0b3Agem9uZQ0KImxvY2FsLmFy cGEuIiAoaG9zdGVkIGJ5ICJzaWduZWQga2V5cyBkaXN0cmlidXRpb24gY2Vu dGVyIiksIHRoZW4NCnNlbmRlcnMgTUFZIGF1dGhlbnRpY2F0ZSB0aGUgcmVz cG9uc2VzIHVzaW5nIEROU1NFQy4NCg0KQWNrbm93bGVkZ21lbnRzDQoNClRo aXMgd29yayBidWlsZHMgdXBvbiBvcmlnaW5hbCB3b3JrIGRvbmUgb24gbXVs dGljYXN0IEROUyBieSBCaWxsDQpNYW5uaW5nIGFuZCBCaWxsIFdvb2Rjb2Nr LiBCaWxsIE1hbm5pbmcncyB3b3JrIHdhcyBmdW5kZWQgdW5kZXIgREFSUEEN CmdyYW50ICNGMzA2MDItOTktMS0wNTIzLiBUaGUgYXV0aG9ycyBncmF0ZWZ1 bGx5IGFja25vd2xlZGdlIHRoZWlyDQpjb250cmlidXRpb24gdG8gdGhlIGN1 cnJlbnQgc3BlY2lmaWNhdGlvbi4gIENvbnN0cnVjdGl2ZSBpbnB1dCBoYXMg YWxzbw0KYmVlbiByZWNlaXZlZCBmcm9tIE1hcmsgQW5kcmV3cywgU3R1YXJ0 IENoZXNoaXJlLCBSb2JlcnQgRWx6LCBKYW1lcw0KR2lscm95LCBPbGFmdXIg R3VkbXVuZHNzb24sIEVyaWsgR3V0dG1hbiwgTXlyb24gSGF0dGlnLCBUaG9t YXMgTmFydGVuLA0KRXJpayBOb3JkbWFyaywgU2FuZGVyIFZhbi1WYWxrZW5i dXJnIGFuZCBUb21vaGlkZSBOYWdhc2hpbWEuDQoNCkF1dGhvcnMnIEFkZHJl c3Nlcw0KDQpMZXZvbiBFc2lib3YNCk1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0K T25lIE1pY3Jvc29mdCBXYXkNClJlZG1vbmQsIFdBIDk4MDUyDQoNCkVNYWls OiBsZXZvbmVAbWljcm9zb2Z0LmNvbQ0KDQpCZXJuYXJkIEFib2JhDQpNaWNy b3NvZnQgQ29ycG9yYXRpb24NCk9uZSBNaWNyb3NvZnQgV2F5DQpSZWRtb25k LCBXQSA5ODA1Mg0KDQpQaG9uZTogKzEgNDI1IDkzNiA2NjA1DQpFTWFpbDog YmVybmFyZGFAbWljcm9zb2Z0LmNvbQ0KDQpEYXZlIFRoYWxlcg0KTWljcm9z b2Z0IENvcnBvcmF0aW9uDQpPbmUgTWljcm9zb2Z0IFdheQ0KUmVkbW9uZCwg V0EgOTgwNTINCg0KUGhvbmU6ICsxIDQyNSA3MDMgODgzNQ0KRU1haWw6IGR0 aGFsZXJAbWljcm9zb2Z0LmNvbQ0KDQoNCg0KDQoNCkVzaWJvdiwgQWJvYmEg JiBUaGFsZXIgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAg ICAgIFtQYWdlIDE2XQ0KDQoNCg0KDQoNCklOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgTXVsdGljYXN0IEROUyAgICAgICAgICAgICAgMTUgTm92ZW1i ZXIgMjAwMQ0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQN Cg0KVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2 YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCmludGVsbGVjdHVhbCBwcm9wZXJ0 eSBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvICBw ZXJ0YWluDQp0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0 ZWNobm9sb2d5IGRlc2NyaWJlZCBpbiB0aGlzDQpkb2N1bWVudCBvciB0aGUg ZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRz IG1pZ2h0IG9yDQptaWdodCBub3QgYmUgYXZhaWxhYmxlOyBuZWl0aGVyIGRv ZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIG1hZGUgYW55DQplZmZvcnQg dG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24gb24g dGhlIElFVEYncw0KcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRz IGluIHN0YW5kYXJkcy10cmFjayBhbmQgc3RhbmRhcmRzLQ0KcmVsYXRlZCBk b2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEuICBDb3BpZXMg b2YgY2xhaW1zIG9mDQpyaWdodHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1Ymxp Y2F0aW9uIGFuZCBhbnkgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0bw0KYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gYXR0ZW1wdCBt YWRlIHRvIG9idGFpbiBhIGdlbmVyYWwNCmxpY2Vuc2Ugb3IgcGVybWlzc2lv biBmb3IgdGhlIHVzZSBvZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieQ0K aW1wbGVtZW50b3JzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBj YW4gYmUgb2J0YWluZWQgZnJvbSB0aGUNCklFVEYgU2VjcmV0YXJpYXQuDQoN ClRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJp bmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCmNvcHlyaWdodHMsIHBhdGVudHMg b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkg cmlnaHRzDQp3aGljaCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBi ZSByZXF1aXJlZCB0byBwcmFjdGljZSB0aGlzDQpzdGFuZGFyZC4gIFBsZWFz ZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBFeGVjdXRp dmUNCkRpcmVjdG9yLg0KDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0K Q29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMSkuICBB bGwgUmlnaHRzIFJlc2VydmVkLg0KVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNs YXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0bw0K b3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24g b3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQgb3INCmFzc2lzdCBpbiBpdHMgaW1w bGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hl ZCBhbmQNCmRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRo b3V0IHJlc3RyaWN0aW9uIG9mIGFueSBraW5kLA0KcHJvdmlkZWQgdGhhdCB0 aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGgg YXJlIGluY2x1ZGVkDQpvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRp dmUgd29ya3MuICBIb3dldmVyLCB0aGlzIGRvY3VtZW50IGl0c2VsZg0KbWF5 IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92 aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlDQpvciByZWZlcmVuY2VzIHRvIHRo ZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXph dGlvbnMsDQpleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiBk ZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbg0Kd2hpY2ggY2FzZSB0 aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJ bnRlcm5ldA0KU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZSBmb2xsb3dlZCwg b3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8NCmxhbmd1YWdl cyBvdGhlciB0aGFuIEVuZ2xpc2guICBUaGUgbGltaXRlZCBwZXJtaXNzaW9u cyBncmFudGVkIGFib3ZlIGFyZQ0KcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBi ZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cw0Kc3Vj Y2Vzc29ycyBvciBhc3NpZ25zLiAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZA0KaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFu ICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBU SEUNCklOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1T IEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SDQpJTVBMSUVELCBJTkNMVURJ TkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBV U0UgT0YgVEhFDQpJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UuIg0KDQpFeHBpcmF0aW9uIERhdGUNCg0KDQoNCg0KDQpFc2lib3Ys IEFib2JhICYgVGhhbGVyICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAg ICAgICAgICAgICBbUGFnZSAxN10NCg0KDQoNCg0KDQpJTlRFUk5FVC1EUkFG VCAgICAgICAgICAgICAgIE11bHRpY2FzdCBETlMgICAgICAgICAgICAgIDE1 IE5vdmVtYmVyIDIwMDENCg0KDQpUaGlzIG1lbW8gaXMgZmlsZWQgYXMgPGRy YWZ0LWlldGYtZG5zZXh0LW1kbnMtMDcudHh0PiwgIGFuZCAgZXhwaXJlcyBN YXkNCjIyLCAyMDAyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpFc2lib3YsIEFib2JhICYgVGhhbGVy ICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICBbUGFn ZSAxOF0NCg0KDQo= --0-1616554169-1005867401=:73304-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 16 01:52:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13755 for ; Fri, 16 Nov 2001 01:52:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164ceV-000JbI-00 for namedroppers-data@psg.com; Thu, 15 Nov 2001 22:39:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 164ceV-000JbC-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 22:39:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 164ceV-000FaH-00 for namedroppers@ops.ietf.org; Thu, 15 Nov 2001 22:39:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BF4B3C9.DAE36631@email.mot.com> References: Date: Fri, 16 Nov 2001 17:35:53 +1100 From: Aidan Williams To: Bernard Aboba CC: namedroppers@ops.ietf.org Subject: Re: SECOND REQUEST for discussion of proposed changes to mdns-06 draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | Change #06-5 | Proposer: Levon Esibov | Date: 11/1/01 | Section affected: 2 | | Rationale: | This paragraph is outside the scope of the draft and should be removed. | | Proposal: | | Remove the following text: | | "The assumption is that if a network has a router, then the | network either has a DNS server or the router can function as a DNS | proxy. By implementing DHCP as well as a DNS proxy and dynamic DNS, | routers can provide name resolution for the names of the hosts on the | local network. This functionality is easily provided, and so in such | cases it is assumed that multicast DNS need not be enabled by default." | | Recommendation: Discuss I agree with Levon, but I think the text accurately reflects what I perceive as a desire to specify mDNS in a way that ensures that it isn't used when DNS is potentially available. These sections on "why you wouldn't use mDNS" seem to be at odds with the first paragraph of the introduction, which states: "Namely, when there are no DNS servers available on the network or available DNS servers do not provide name resolution for the names of the hosts on the local network." and seems to imply some kind of co-existance, with mDNS resolving the "local names". If we go with the unicast DNS/DDNS approach for the home, I would like to see the .local.arpa domain become usable for DDNS updates of local names in the home, presumably via the "DNS proxy" becoming authoritative for that domain. To that end, I think it would be useful if the local.arpa domain were not tied to tightly to mDNS. | Change #06-8 | Proposer: Levon Esibov | Date: 11/1/01 | Section affected: 3 | Rationale: Current text prevents a DNS server from responding to queries for | its own name. This restriction can be loosened. | | Proposal: | | Change the following text: | | "If a DNS server is running on a host, the host MUST NOT listen for | multicast DNS queries, to prevent the host from listening on port 53 and | intercepting DNS queries directed to a DNS server. By default, a DNS | server MUST NOT listen to multicast DNS queries." | | To: | | "If a DNS server is running on a host, then responder MUST NOT | listen for the multicast DNS queries on the same IP addresses on | which the DNS server listens, since otherwise they would intercept | DNS queries directed to a DNS server. The DNS server MUST respond | to the multicast DNS queries only for the RRSets owned by the host | on which the server is running, but MUST NOT respond for the | records for which the server is authoritative." | | Recommendation: Accept | Change made. Is there an `m' missing in "The [m]DNS server MUST respond to the multicast .."? The text doesn't seem to quite address the issue completely. Why should we preclude a unicast DNS server from incorporating mDNS functionality and running on the same interface? I would have thought this was desirable from a software point of view. A server cannot blindly assume that mDNS requests will all be multicast either because of the truncation behaviour. A multicast request can be checked to ensure that it is in .local.arpa, but unicast requests would need to examine the query itself. Also, just because a DNS server is running doesn't mean anybody else is using it. Various versions of redhat linux have shipped with a dns server running by default as a local cache listening on all interfaces. Perhaps we could say: "Hosts running both DNS and mDNS MUST ensure that the two protocols do not interfere with each other." It would be nice to define what an RRSet "owned by the host" is. | Change #06-13 | Proposer: Levon Esibov | Date: 11/1/01 | Section affected: 3.1 | Rationale: | | The following paragraph means that mDNS will not work in home | environments with an ISP-provided DHCP server unless it is | upgraded. | | Proposal: | Delete the following paragraph: | | "If an interface has been configured for a given protocol via any | automatic configuration mechanism which is able to supply DNS | configuration information, then multicast DNS SHOULD NOT be used on that | interface for that protocol unless it has been explicitly enabled, | whether via that mechanism or any other. This ensures that upgraded | hosts do not change their default behavior, without requiring the source | of the configuration information to be simultaneously updated. This | implies that on the interface, the host will neither listen on the DNS | LINKLOCAL multicast address, nor will it send queries to that address." | | Recommendation: Discuss Again I agree, however I thought we had already discussed this a fair bit on the list and the above paragraph was the result. Some references to messages in the dnsext email archive: <3BAECDE8.7DA9E8C0@email.mot.com> | Removal of references to "local.arpa" | Change #06-14 | Change #06-15 | Change #06-16 | Change #06-17 | Change #06-18 | Change #06-19 I'm in favour of allowing mDNS to be used for non-local.arpa names. I think that having a scoped namespace (local.arpa) is a good idea, and as I said earlier it shouldn't be tied tightly to mDNS. regards aidan ____ :wq! Communications and Networks Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://cnlab.arc.corp.mot.com/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Nov 16 19:21:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00276 for ; Fri, 16 Nov 2001 19:21:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 164svL-000Gll-00 for namedroppers-data@psg.com; Fri, 16 Nov 2001 16:01:31 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 164svL-000Glf-00 for namedroppers@ops.ietf.org; Fri, 16 Nov 2001 16:01:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 164svL-000ICM-00 for namedroppers@ops.ietf.org; Fri, 16 Nov 2001 16:01:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <3BF4B3C9.DAE36631@email.mot.com> Message-ID: Date: Fri, 16 Nov 2001 15:49:31 -0800 (PST) From: Bernard Aboba To: Aidan Williams cc: namedroppers@ops.ietf.org Subject: Re: SECOND REQUEST for discussion of proposed changes to mdns-06 draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | Change #06-5 > | Proposer: Levon Esibov > | Date: 11/1/01 > | Section affected: 2 > | > These sections on "why you wouldn't use mDNS" seem to be at odds with > the first paragraph of the introduction, which states: > > "Namely, when there are no DNS servers available on the network or > available DNS servers do not provide name resolution for the names > of the hosts on the local network." > > and seems to imply some kind of co-existance, with mDNS resolving the > "local names". I think part of the confusion is that for IPv6, it is not clear whether there will be a DNS proxy present that will be able to handle AAAA and DDNS. At the moment most IPv6 implementations don't support DHCPv6, and most DNS proxies don't support AAAA queries or responses, whether over IPv4 or IPv6. Therefore mDNS seems to like a practical way to resolve "local names" to IPv6 addresses, with creating any dependencies on home router functionality. > If we go with the unicast DNS/DDNS approach for the home, I would like > to see the .local.arpa domain become usable for DDNS updates of local > names in the home, presumably via the "DNS proxy" becoming > authoritative for that domain. To that end, I think it would be > useful if the local.arpa domain were not tied to tightly to mDNS. Not sure why this would be necessary, since the client provides an FQDN option to the mini-DHCP server. Therefore the DNS proxy can respond to a query for the FQDN, or potentially to a query for a name with no "."s in it at all. > Is there an [m] missing? I don't think so. > The text doesn't seem to quite address the issue completely. > Why should we preclude a unicast DNS server from incorporating mDNS > functionality and running on the same interface? I would have thought > this was desirable from a software point of view. Imagine the IPv6 case with mDNS. How would one resolve a query for "www.yahoo.com" in the case where there is no mini-DHCPv6 server or DNS discovery functionality on the router? If the host is dual stack, it could send AAAA queries over IPv4 to the DNS proxy, whose address it found via DHCPv4. But what if the host is IPv6-only and the home gateway or client doesn't implement DHCPv6 or DNS Discovery? What does it do then? One possible answer is for it to send all queries using mDNS, and for the DNS proxy to retrieve the answer via unicast queries, whether over IPv4 or IPv6. > A server cannot blindly assume that mDNS requests will all be > multicast either because of the truncation behaviour. By definition, an mDNS request is distinguished from an ordinary DNS request because it is sent via multicast, no? If it isn't sent via multicast how would we know it is an mDNS packet, as opposed to an ordinary DNS request? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Nov 19 17:23:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00016 for ; Mon, 19 Nov 2001 17:23:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 165wUL-0002WL-00 for namedroppers-data@psg.com; Mon, 19 Nov 2001 14:02:01 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 165wUK-0002WF-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 14:02:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 165wUK-000KpF-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 14:02:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3BF4B3C9.DAE36631@email.mot.com> Message-Id: From: Randy Bush To: Bernard Aboba Cc: namedroppers@ops.ietf.org Subject: Re: SECOND REQUEST for discussion of proposed changes to Date: Mon, 19 Nov 2001 13:59:05 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit you were quoting someone or other: >> If we go with the unicast DNS/DDNS approach for the home, I would like >> to see the .local.arpa domain become usable for DDNS updates of local >> names in the home this is sorely broken. local.arpa would need far more thrust than rfc 1925 seec 2.3 ever envisioned to get past the iesg and the dns curmudgeons. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 00:01:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13815 for ; Tue, 20 Nov 2001 00:01:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1662lL-000D77-00 for namedroppers-data@psg.com; Mon, 19 Nov 2001 20:43:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 1662lL-000D71-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 20:43:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 1662lL-0006bj-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 20:43:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BF9D76C.76768028@email.mot.com> References: Date: Tue, 20 Nov 2001 15:09:16 +1100 From: Aidan Williams To: Bernard Aboba CC: namedroppers@ops.ietf.org Subject: Re: SECOND REQUEST for discussion of proposed changes to mdns-06draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > A server cannot blindly assume that mDNS requests will all be > > multicast either because of the truncation behaviour. > > By definition, an mDNS request is distinguished from an ordinary DNS > request because it is sent via multicast, no? If it isn't sent via > multicast how would we know it is an mDNS packet, as opposed to an > ordinary DNS request? I might have the wrong end of the stick, but clients may retry truncated mDNS requests with unicast TCP or EDNS0: If a TC (truncation) bit is set in the response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the query over TCP or using EDNS0 with larger window using the unicast address of the responder. The RA (Recursion Available) bit in the header of the response MUST NOT be set. Even if the RA bit is set in the response header, the sender MUST ignore it. Given that the format of the DNS requests is the same, I don't see how the server can tell that this is an "mDNS request" .. - aidan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 01:14:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15781 for ; Tue, 20 Nov 2001 01:14:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166435-000EtN-00 for namedroppers-data@psg.com; Mon, 19 Nov 2001 22:06:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 166435-000EtH-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 22:06:23 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 166435-00093h-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 22:06:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.0.14.2.20011023224452.00b17830@localhost> Message-ID: Date: Tue, 20 Nov 2001 00:59:54 -0500 (EST) From: Olafur Gudmundsson To: DNSEXT mailing list Subject: DNSEXT WGLC Summary GSS-tsig-03 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, 23 Oct 2001, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > The TSIG protocol provides transaction level authentication for DNS. > TSIG is extensible through the definition of new algorithms. This > document specifies an algorithm based on the Generic Security Service > Application Program Interface (GSS-API) (RFC2743). > > This WG last call ends November 8'th 2001. > The Working group last call has completed, with minor comments. Following are minor clarifications that the chairs and document editors have agreed on for clarity. There seems to be consensus that this document is complete and implementable. Thus the working group recommends to advance it to proposed standard. Minor comments that need to be fixed before advancement: 1. (Introduction, second line. ) "lightweight end to end authentication", To avoid confusion that the words "end to end" should be dropped. In DNS context I think of end-to-end as the whole path from authorative server to resolver. In this context you are talking about protecting one hop. 1. (third paragraph (bottom of page 2)), the word "may" shows up 2 times is this supposed to be MAY ? 1. (last paragraph) add "MUST NOT" and the other negatives to your list as some of them are used in the document. 3.1.1 OBJECT IDENTIFIFIER this is the location where the use of Kerberos 5 is first required. For clarity reasons please state this in the second paragraph in section 3. 3.1.2 (last line) uses MUST NOT, not on the list of required keywords (see section 1 comments). 3.1.3.1 (second paragraph second sentence from bottom). "The client MUST continue to waiting for a response to ..." This is a new requirement on servers and clients that it can not abort after getting the first answer. It can be argued that this is a good thing to do and we may want to add this capability in other places but this is not the document to update RFC1035. For now tone the MUST down to SHOULD or MAY. 3.1.3.2 (first paragraph last sentence). s/must/MUST/ and suggest a firm limit or point to section that suggests a limit. NOTE this text is replaced in 3 different places in this section please update all. 7. Security considerations, add a sentence that says that all the security considerations from RFC2845 and RFC2930 apply here as well as the ones for GSS-API. 12. Author addresses, 3 of 6 authors do not have e-mail addresses. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 01:15:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15812 for ; Tue, 20 Nov 2001 01:15:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16642t-000Et9-00 for namedroppers-data@psg.com; Mon, 19 Nov 2001 22:06:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16642t-000Et1-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 22:06:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16642t-00093M-00 for namedroppers@ops.ietf.org; Mon, 19 Nov 2001 22:06:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <3BF9EBE2.D9D30802@email.mot.com> Message-ID: Date: Mon, 19 Nov 2001 21:48:32 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org cc: randy@psg.com Subject: Re: mdns-06 changes Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Randy Bush spake thusly: > > > > >> If we go with the unicast DNS/DDNS approach for the home, I would like > > >> to see the .local.arpa domain become usable for DDNS updates of local > > >> names in the home > > > > this is sorely broken. local.arpa would need far more thrust than rfc 1925 > > seec 2.3 ever envisioned to get past the iesg and the dns curmudgeons. > > > > randy A request for clarification. Do you mean that "local.arpa" is broken and support should be removed from the mDNS draft? Or do you mean that use of "local.arpa" in unicast DNS/DDNS is broken and should not be permitted in the draft? If the latter, do you have an opinion on the removal of "local.arpa" from the draft? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 08:36:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07592 for ; Tue, 20 Nov 2001 08:36:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166AhI-000P7C-00 for namedroppers-data@psg.com; Tue, 20 Nov 2001 05:12:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 166AhH-000P75-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 05:12:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 166AhH-000Mqp-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 05:12:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <3BF9D76C.76768028@email.mot.com> References: <3BF9D76C.76768028@email.mot.com> Message-ID: <2008.1006249318@brandenburg.cs.mu.OZ.AU> From: Robert Elz To: Aidan Williams cc: Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: SECOND REQUEST for discussion of proposed changes to mdns-06draft Date: Tue, 20 Nov 2001 16:41:58 +0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 20 Nov 2001 15:09:16 +1100 From: Aidan Williams Message-ID: <3BF9D76C.76768028@email.mot.com> | Given that the format of the DNS requests is the same, I don't see how | the server can tell that this is an "mDNS request" .. By the destination address of the packet it received? kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 08:48:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08305 for ; Tue, 20 Nov 2001 08:48:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166B2M-000Pfr-00 for namedroppers-data@psg.com; Tue, 20 Nov 2001 05:34:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 166B2M-000Pfk-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 05:34:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 166B2M-000NRt-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 05:34:06 -0800 Message-Id: <200111201212.HAA04343@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-00.txt Date: Tue, 20 Nov 2001 07:12:00 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-00.txt Pages : 11 Date : 19-Nov-01 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dns-threats-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011119140415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011119140415.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 08:50:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08460 for ; Tue, 20 Nov 2001 08:50:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166B8n-000Psj-00 for namedroppers-data@psg.com; Tue, 20 Nov 2001 05:40:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 166B8n-000Psd-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 05:40:45 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 166B8n-000NdK-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 05:40:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: "Your message with ID" Message-ID: Date: Tue, 20 Nov 2001 14:36:36 +0100 (CET) From: Erik Nordmark Subject: Re: DNSEXT WGLC Summary GSS-tsig-03 To: Olafur Gudmundsson Cc: DNSEXT mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Should the AD wait for an updated document before starting to review it for the IESG? Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 15:19:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03034 for ; Tue, 20 Nov 2001 15:19:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166GiJ-000Acp-00 for namedroppers-data@psg.com; Tue, 20 Nov 2001 11:37:47 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 166GiI-000Aca-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 11:37:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 166GiI-0007gx-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 11:37:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: Date: Tue, 20 Nov 2001 14:28:34 -0500 (EST) From: Olafur Gudmundsson To: Erik Nordmark cc: DNSEXT mailing list , Levon Esibov Subject: Re: DNSEXT WGLC Summary GSS-tsig-03 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 20 Nov 2001, Erik Nordmark wrote: > > Should the AD wait for an updated document before starting to review it > for the IESG? > Yes, it should be submitted today. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Nov 20 19:15:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12167 for ; Tue, 20 Nov 2001 19:15:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166Kl9-000KnB-00 for namedroppers-data@psg.com; Tue, 20 Nov 2001 15:56:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 166Kl9-000Kn5-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 15:56:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 166Kl9-000F64-00 for namedroppers@ops.ietf.org; Tue, 20 Nov 2001 15:56:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BFAE6E6.55AC423E@email.mot.com> References: <3BF9D76C.76768028@email.mot.com> <2008.1006249318@brandenburg.cs.mu.OZ.AU> Date: Wed, 21 Nov 2001 10:27:34 +1100 From: Aidan Williams To: Robert Elz CC: Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: SECOND REQUEST for discussion of proposed changes to mdns-06draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > | Given that the format of the DNS requests is the same, I don't see how > | the server can tell that this is an "mDNS request" .. > > By the destination address of the packet it received? > .. but the destination address isn't always going to be multicast. Either I'm missing something fundamental, or I'm not explaining myself well. I think we're talking about a combination mDNS responder and DNS server listening on port 53. This is the scenario I think is the problem: 1. mDNS sender sends a multicast DNS request 2. mDNS responder sends a truncated response (TC set) 3. mDNS sender retries the DNS request with *unicast* TCP or EDNS0 request 4. The combination mDNS responder/DNS server then gets a request with a unicast destination address. This is why I don't think that the server can tell *in general* that a request is an mDNS request by checking for a multicast destination address. - aidan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Nov 22 01:58:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00046 for ; Thu, 22 Nov 2001 01:58:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166nOs-000H4k-00 for namedroppers-data@psg.com; Wed, 21 Nov 2001 22:31:54 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 166nOr-000H4e-00 for namedroppers@ops.ietf.org; Wed, 21 Nov 2001 22:31:53 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 166n6n-0007RW-00 for namedroppers@ops.ietf.org; Wed, 21 Nov 2001 22:13:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20011120150342.01e852f8@funnel.cisco.com> In-Reply-To: References: Date: Wed, 21 Nov 2001 16:39:57 -0500 To: namedroppers From: Mark Stapp Subject: Re: wg last call for draft-ietf-dnsext-dhcid-rr-03.txt to ps Cc: mellon@nominum.com, gson@nominum.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 02:37 PM 10/19/2001 -0700, Randy Bush wrote: >there seem to be folk too tired to speak for themselves on the mailing list, >so they send this stuff to me in email. as 2026 does not specify that one >has the right to confront one's accusors, i will forward anonymously :-) I've made revisions that address these comments and submitted a new draft. The notification will show up as soon as the draft editor processes my submission. Specifics inline: -- Mark >1. Canonical format redefined instead of being inherited. Done. >2. Does not define that this type is only allowed in class IN Done. >3. Does not explicitly state if this is a singleton type or multiple > DHCID RR can be in a set. Done. >4. Section 3.4 should be structured something like: > "digest is calculated over |