From owner-namedroppers@ops.ietf.org Wed Feb 01 02:41:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Cbx-0006Pq-45 for dnsext-archive@megatron.ietf.org; Wed, 01 Feb 2006 02:41:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18966 for ; Wed, 1 Feb 2006 02:39:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4CW8-0001Jb-Ve for namedroppers-data@psg.com; Wed, 01 Feb 2006 07:35:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4CW7-0001JN-Pv for namedroppers@ops.ietf.org; Wed, 01 Feb 2006 07:35:04 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k117Z1fE054446 for ; Wed, 1 Feb 2006 08:35:01 +0100 (CET) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k117Z1wN054443 for namedroppers@ops.ietf.org; Wed, 1 Feb 2006 08:35:01 +0100 (CET) (envelope-from olaf) Date: Wed, 1 Feb 2006 08:35:01 +0100 (CET) From: Olaf Kolkman Message-Id: <200602010735.k117Z1wN054443@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. 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. - Specific items that are not not appropriate for posting 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, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. 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 poised@lists.tislabs.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. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From andrew@101greatbooks.com Wed Feb 01 10:07:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JaI-0007VY-Ok for dnsext-archive@megatron.ietf.org; Wed, 01 Feb 2006 10:07:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06373 for ; Wed, 1 Feb 2006 10:06:13 -0500 (EST) Received: from p54a26f0f.dip.t-dialin.net ([84.162.111.15] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4JlP-0000i8-5Y for dnsext-archive@ietf.org; Wed, 01 Feb 2006 10:19:24 -0500 Message-ID: <000001c6276b$2a38fe80$0100007f@localhost> From: "Cameron Harris" To: Subject: Buy OEM Software Date: Wed, 01 Feb 2006 16:07:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6276B.2A38FE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6276B.2A38FE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C6276B.2A38FE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 33 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 41 reviews)!

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 44 reviews)

------=_NextPart_000_0001_01C6276B.2A38FE80-- From owner-namedroppers@ops.ietf.org Wed Feb 01 10:14:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JgV-0004ih-BB for dnsext-archive@megatron.ietf.org; Wed, 01 Feb 2006 10:14:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06765 for ; Wed, 1 Feb 2006 10:12:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4JcV-0002a0-Aw for namedroppers-data@psg.com; Wed, 01 Feb 2006 15:10:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.55.12.40] (helo=ll.mit.edu) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4JcU-0002Zm-BL for namedroppers@ops.ietf.org; Wed, 01 Feb 2006 15:10:06 +0000 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id k11FA56u029512 for ; Wed, 1 Feb 2006 10:10:05 -0500 (EST) Received: from UNKNOWN( ), claiming to be "[192.5.135.97]" via SMTP by llmail, id smtpdAAAsPayx4; Wed Feb 1 10:09:45 2006 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 01 Feb 2006 10:09:08 -0500 Subject: Re: RFC 2538bis security problem with the indirect types From: "Stuart E. Schechter" To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: Simon Josefsson ... > I do agree that standardizing URI schemes to embed a hash of the > content would be useful. I believe this has been proposed before, but hasn't happened because you can't use hashes in URIs in any environment with circular references. (e.g., web pages that link to each other.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 01 10:35:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4K0Z-0005W4-9m for dnsext-archive@megatron.ietf.org; Wed, 01 Feb 2006 10:35:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07971 for ; Wed, 1 Feb 2006 10:33:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Jwk-00042a-BA for namedroppers-data@psg.com; Wed, 01 Feb 2006 15:31:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Jwi-00042N-OF for namedroppers@ops.ietf.org; Wed, 01 Feb 2006 15:31:01 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k11FUq24019967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Feb 2006 16:30:54 +0100 From: Simon Josefsson To: "Stuart E. Schechter" Cc: Subject: Re: RFC 2538bis security problem with the indirect types References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060201:ses@ll.mit.edu::jBlGdQcMMSfLu3Pp:0fWM X-Hashcash: 1:21:060201:namedroppers@ops.ietf.org::/sZC8ZKPA3E6Qqu9:B9IP Date: Wed, 01 Feb 2006 16:30:50 +0100 In-Reply-To: (Stuart E. Schechter's message of "Wed, 01 Feb 2006 10:09:08 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Stuart E. Schechter" writes: >> From: Simon Josefsson > ... >> I do agree that standardizing URI schemes to embed a hash of the >> content would be useful. > > I believe this has been proposed before, but hasn't happened because you > can't use hashes in URIs in any environment with circular references. > (e.g., web pages that link to each other.) Right, the idea is not appropriate for all applications. Still, it may be useful to use when the target is an OpenPGP key. However, in this case, it seems more appropriate to modify the CERT I* types, to add a potentially optional field for a hash value. Thanks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 01 10:38:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4K4O-0008Ca-7e for dnsext-archive@megatron.ietf.org; Wed, 01 Feb 2006 10:38:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08234 for ; Wed, 1 Feb 2006 10:37:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4K1y-0004QS-Fv for namedroppers-data@psg.com; Wed, 01 Feb 2006 15:36:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4K1w-0004QF-LR for namedroppers@ops.ietf.org; Wed, 01 Feb 2006 15:36:24 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k11FaM5d024733; Wed, 1 Feb 2006 07:36:22 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k11FaMvH024730; Wed, 1 Feb 2006 07:36:22 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 1 Feb 2006 07:36:22 -0800 (PST) From: "william(at)elan.net" To: "Stuart E. Schechter" cc: namedroppers@ops.ietf.org Subject: Re: RFC 2538bis security problem with the indirect types In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 1 Feb 2006, Stuart E. Schechter wrote: >> From: Simon Josefsson > ... >> I do agree that standardizing URI schemes to embed a hash of the >> content would be useful. > > I believe this has been proposed before, but hasn't happened because > you can't use hashes in URIs in any environment with circular references. > (e.g., web pages that link to each other.) I doubt it is main reason it did not happen. The bigger reason is that those who are being referenced want easy way to keep track as to who is referencing them, so that in case of changes the url with hash could also be updated. So until we have standardized trackback notification with authorization, URL with hash is useful only for certain specific environments. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 01 14:36:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4NmG-0002Eo-4A for dnsext-archive@megatron.ietf.org; Wed, 01 Feb 2006 14:36:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24694 for ; Wed, 1 Feb 2006 14:34:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Ngn-0001MG-SP for namedroppers-data@psg.com; Wed, 01 Feb 2006 19:30:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Ngl-0001Lq-0Q for namedroppers@ops.ietf.org; Wed, 01 Feb 2006 19:30:47 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F4Ngj-0008Hb-Mi; Wed, 01 Feb 2006 14:30:45 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Wed, 01 Feb 2006 14:30:45 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following document: - 'Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-04.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 01 15:55:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4P0g-0005W5-Fu for dnsext-archive@megatron.ietf.org; Wed, 01 Feb 2006 15:55:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04809 for ; Wed, 1 Feb 2006 15:53:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Ova-0000dw-Ka for namedroppers-data@psg.com; Wed, 01 Feb 2006 20:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4OvW-0000c5-4d for namedroppers@ops.ietf.org; Wed, 01 Feb 2006 20:50:07 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F4OvS-0007Dr-HQ; Wed, 01 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tsig-sha-06.txt Message-Id: Date: Wed, 01 Feb 2006 15:50:02 -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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-06.txt Pages : 9 Date : 2006-2-1 Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC MD5 (Message Digest) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-tsig-sha-06.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-tsig-sha-06.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: <2006-2-1151851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-sha-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-1151851.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. archive: From bryanpost@ambassade-egypte.com Thu Feb 02 06:01:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4cDe-0006G5-5B for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 06:01:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21488 for ; Thu, 2 Feb 2006 05:59:41 -0500 (EST) Received: from [221.156.16.139] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4cOc-0006LS-Cc for dnsext-archive@ietf.org; Thu, 02 Feb 2006 06:13:04 -0500 Message-ID: <000001c62811$e5b46e00$0100007f@localhost> From: "Braxton Clark" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Thu, 02 Feb 2006 20:01:05 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62811.E5B46E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62811.E5B46E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62811.E5B46E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 38 revi! ews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 39 reviews)

------=_NextPart_000_0001_01C62811.E5B46E00-- From owner-namedroppers@ops.ietf.org Thu Feb 02 06:04:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4cGH-0006ob-8E for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 06:04:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21705 for ; Thu, 2 Feb 2006 06:02:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4c7j-000Hin-Kk for namedroppers-data@psg.com; Thu, 02 Feb 2006 10:55:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4c7g-000HiE-De for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 10:55:32 +0000 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id k12AtT0f065261 for ; Thu, 2 Feb 2006 19:55:30 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Received: from thinkpad.64translator.com (dhcp248.64translator.com [10.21.32.248]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id k12AtK6R033395 for ; Thu, 2 Feb 2006 19:55:21 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Date: Thu, 2 Feb 2006 19:54:50 +0900 From: Hideshi Enokihara To: namedroppers@ops.ietf.org Subject: [question]What is an accurate meaning of "client" in RFC2181? Message-Id: <20060202195450.105f0583.Hideshi.Enokihara@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have a question regarding the word "client" in RFC2181. For example, section 5.2 says, ------------------- Should a client receive a response containing RRs from an RRSet with differing TTLs, it should treat this as an error. If the RRSet concerned is from a non-authoritative source for this data, the client should simply ignore the RRSet, and if the values were required, seek to acquire them from an authoritative source. Clients that are configured to send all queries to one, or more, particular servers should treat those servers as authoritative for this purpose. Should an authoritative source send such a malformed RRSet, the client should treat the RRs for all purposes as if all TTLs in the RRSet had been set to the value of the lowest TTL in the RRSet. In no case may a server send an RRSet with TTLs not all equal. ------------------- In this paragraph, the word "clinet" appears four times. Does all of these "client" mean just only client(simple resolver client)? Or, does these "cleint" mean include the server acting as client for the purposes of recursive query resolution? I think that this word "client" is unclear. There is a similar problem also in section 9. ------------------ Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. ------------------ What do you think? Best Regards, -- ************************************* Hideshi Enokihara IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 02 07:22:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4dTQ-0005Kx-3M for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 07:22:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27183 for ; Thu, 2 Feb 2006 07:20:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4dQe-000MeR-K7 for namedroppers-data@psg.com; Thu, 02 Feb 2006 12:19:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4dQc-000Me9-DN for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 12:19:10 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 5B60BE6087 for ; Thu, 2 Feb 2006 12:19:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k12CIrkn049316; Thu, 2 Feb 2006 23:18:54 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200602021218.k12CIrkn049316@drugs.dv.isc.org> To: Hideshi Enokihara Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [question]What is an accurate meaning of "client" in RFC2181? In-reply-to: Your message of "Thu, 02 Feb 2006 19:54:50 +0900." <20060202195450.105f0583.Hideshi.Enokihara@jp.yokogawa.com> Date: Thu, 02 Feb 2006 23:18:53 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Hi all, > > I have a question regarding the word "client" in RFC2181. > > For example, section 5.2 says, > > ------------------- > Should a client receive a response containing RRs from an RRSet with > differing TTLs, it should treat this as an error. If the RRSet > concerned is from a non-authoritative source for this data, the > client should simply ignore the RRSet, and if the values were > required, seek to acquire them from an authoritative source. Clients > that are configured to send all queries to one, or more, particular > servers should treat those servers as authoritative for this purpose. > Should an authoritative source send such a malformed RRSet, the > client should treat the RRs for all purposes as if all TTLs in the > RRSet had been set to the value of the lowest TTL in the RRSet. In > no case may a server send an RRSet with TTLs not all equal. > ------------------- > > In this paragraph, the word "clinet" appears four times. > Does all of these "client" mean just only client(simple resolver client)? > Or, does these "cleint" mean include the server acting as client for the purp > oses of recursive query resolution? It also means the resolver in the nameserver. RRset with differing TTLs was a common indication that the answer had come from a nameserver that had merged RRsets or had got a answer from another nameserver that had merged RRsets. > I think that this word "client" is unclear. The DNS is a client / server protocol. A recursive server has a client component that iterates. > There is a similar problem also in section 9. > ------------------ > > Where TC is set, the partial RRSet that would not completely fit may > be left in the response. When a DNS client receives a reply with TC > set, it should ignore that response, and query again, using a > mechanism, such as a TCP connection, that will permit larger replies. > ------------------ > > What do you think? Again this is clear. If you ask a question over UDP and get TC in the response you need to re-ask the question using TCP. The problem then becomes what do you do when you get TC over TCP? Mark > Best Regards, > -- > ************************************* > Hideshi Enokihara > IPv6 Business > Network & Software Development Dept. > Yokogawa Electric Corporation > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From vandh@gci.net Thu Feb 02 07:22:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4dUA-0005mw-3k for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 07:22:50 -0500 Received: from tpmfg.com ([196.1.210.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27265 for ; Thu, 2 Feb 2006 07:21:03 -0500 (EST) Received: from existent.irresponsible.com (algenib [154.196.154.252]) by berne.com (franca) with lady id 24989798548949 for ; Thu, 02 Feb 2006 16:29:26 -0500 Date: Thu, 02 Feb 2006 14:33:47 -0500 Message-Id: <114927320410490912355468@microsoft.com> From: Teresa Pickens To: dnsext-archive@ietf.org Subject: Amazing, Jerrold X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: biconnected 3.20.65777 X-MimeOLE: khan 5.72.2088396 Content-Type: multipart/mixed; boundary="------=928582990079998" Content-Transfer-Encoding: 7bit --------=928582990079998 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Bad times have a scientific value. These are occasions a good learner would not miss.People usually are the happiest at home.
Like swimming, riding, writing, or playing golf, happiness can be learned.There's a way to do better... find it.Editing is the same as quarreling with writers -- same thing exactly. --------=928582990079998 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Brooke-> http://gpddga.trialtry.info/?62319308 --------=928582990079998-- From mfigg@bargadgets.com Thu Feb 02 08:10:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4eED-0000JV-Ha for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 08:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01161 for ; Thu, 2 Feb 2006 08:08:44 -0500 (EST) Received: from [220.119.59.66] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4ePW-0002Sm-C1 for dnsext-archive@ietf.org; Thu, 02 Feb 2006 08:22:07 -0500 Message-ID: <000001c62823$d6d6b700$0100007f@localhost> From: "Skyler Washington" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Thu, 02 Feb 2006 22:10:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62823.D6D6B700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.2 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62823.D6D6B700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62823.D6D6B700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 36 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 47 revi! ews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)

------=_NextPart_000_0001_01C62823.D6D6B700-- From owner-namedroppers@ops.ietf.org Thu Feb 02 08:15:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4eJO-0001yc-UU for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 08:15:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01502 for ; Thu, 2 Feb 2006 08:14:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4eFn-000Q0O-8r for namedroppers-data@psg.com; Thu, 02 Feb 2006 13:12:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4eFj-000Q05-UG for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 13:12:00 +0000 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id k12DAgHE065752; Thu, 2 Feb 2006 22:10:42 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Received: from thinkpad.64translator.com (dhcp248.64translator.com [10.21.32.248]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id k12DAX67034530; Thu, 2 Feb 2006 22:10:33 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Date: Thu, 2 Feb 2006 22:10:03 +0900 From: Hideshi Enokihara To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: [question]What is an accurate meaning of "client" in RFC2181? Message-Id: <20060202221003.36237fcc.Hideshi.Enokihara@jp.yokogawa.com> In-Reply-To: <200602021218.k12CIrkn049316@drugs.dv.isc.org> References: <20060202195450.105f0583.Hideshi.Enokihara@jp.yokogawa.com> <200602021218.k12CIrkn049316@drugs.dv.isc.org> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you for your reply. The purpose of this question is to want to avoid the confusion of the meaning of the word "client" and "resolver". RFC2308 that you wrote doesn't use the word "client". The word "resolver" is clearly used instead of "client". I personally thought that the word "resolver" include "Recursion server" and "Client", and the word "cleint" is just simple client. Can I think that "Clinet" and "Resolver" are the same meanings in RFC? Best Regards, On Thu, 02 Feb 2006 23:18:53 +1100 Mark Andrews wrote: > > > Hi all, > > > > I have a question regarding the word "client" in RFC2181. > > > > For example, section 5.2 says, > > > > ------------------- > > Should a client receive a response containing RRs from an RRSet with > > differing TTLs, it should treat this as an error. If the RRSet > > concerned is from a non-authoritative source for this data, the > > client should simply ignore the RRSet, and if the values were > > required, seek to acquire them from an authoritative source. Clients > > that are configured to send all queries to one, or more, particular > > servers should treat those servers as authoritative for this purpose. > > Should an authoritative source send such a malformed RRSet, the > > client should treat the RRs for all purposes as if all TTLs in the > > RRSet had been set to the value of the lowest TTL in the RRSet. In > > no case may a server send an RRSet with TTLs not all equal. > > ------------------- > > > > In this paragraph, the word "clinet" appears four times. > > Does all of these "client" mean just only client(simple resolver client)? > > Or, does these "cleint" mean include the server acting as client for the purp > > oses of recursive query resolution? > > It also means the resolver in the nameserver. > > RRset with differing TTLs was a common indication that the > answer had come from a nameserver that had merged RRsets > or had got a answer from another nameserver that had merged > RRsets. > > > I think that this word "client" is unclear. > > The DNS is a client / server protocol. A recursive server > has a client component that iterates. > > > There is a similar problem also in section 9. > > ------------------ > > > > Where TC is set, the partial RRSet that would not completely fit may > > be left in the response. When a DNS client receives a reply with TC > > set, it should ignore that response, and query again, using a > > mechanism, such as a TCP connection, that will permit larger replies. > > ------------------ > > > > What do you think? > > Again this is clear. If you ask a question over UDP and > get TC in the response you need to re-ask the question using > TCP. The problem then becomes what do you do when you get > TC over TCP? > > Mark > > > Best Regards, > > -- > > ************************************* > > Hideshi Enokihara > > IPv6 Business > > Network & Software Development Dept. > > Yokogawa Electric Corporation > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- ************************************* Hideshi Enokihara IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 02 09:54:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4fqg-0002sE-CY for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 09:54:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09291 for ; Thu, 2 Feb 2006 09:52:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4fnV-0006Of-Cv for namedroppers-data@psg.com; Thu, 02 Feb 2006 14:50:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4fnS-0006OS-V4 for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 14:50:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5000811426; Thu, 2 Feb 2006 14:50:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Hideshi Enokihara cc: namedroppers@ops.ietf.org Subject: Re: [question]What is an accurate meaning of "client" in RFC2181? In-Reply-To: Your message of "Thu, 02 Feb 2006 19:54:50 +0900." <20060202195450.105f0583.Hideshi.Enokihara@jp.yokogawa.com> References: <20060202195450.105f0583.Hideshi.Enokihara@jp.yokogawa.com> Date: Thu, 02 Feb 2006 14:50:54 +0000 Message-Id: <20060202145054.5000811426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i believe that the terms "client" and "server" are inadequate to describe the roles of the various protocol agents in DNS, and as in RFC 2136, i suggest the terms "initiator" and "responder" instead. the the parts of RFC 2181 which you've quoted here, "client" really means "initiator". the DNS protocol specification must be understood in terms of messages -- their format and meaning. two messages make up a transaction, and each transaction is initiated by some protocol agent and responded to by others. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 02 13:39:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jMr-0008Oq-PW for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 13:39:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27750 for ; Thu, 2 Feb 2006 13:37:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jJI-000Ls4-5f for namedroppers-data@psg.com; Thu, 02 Feb 2006 18:36:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.0 Received: from [208.17.35.58] (helo=cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jJE-000Lrl-SS for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 18:35:57 +0000 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16768110; Thu, 02 Feb 2006 13:35:37 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 13:35:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [question]What is an accurate meaning of "client" in RFC2181? Date: Thu, 2 Feb 2006 13:35:36 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7304321E2D@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [question]What is an accurate meaning of "client" in RFC2181? Thread-Index: AcYoIvpLqId7ZF1xRdSVdjTPumpLywAAUh1A From: "Durand, Alain" To: "Paul Vixie" , "Hideshi Enokihara" Cc: X-OriginalArrivalTime: 02 Feb 2006 18:35:37.0012 (UTC) FILETIME=[75B2B740:01C62827] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I think the current terminology is consistent with the client/server model definitions but still carries a lot of confusion with it. In the client/server model, the "client" is,as you mention, the one that "initiates" the connection [read: performs connect()]and the "server" is the one that accept [read: performs accpet()] the connection request. So, it is perfectly normal that a piece of software that, for example, is doing recursive DNS resolution, can be at turns a client and a server... The problem is that people get confused by the IT terminology, where PCs are client and big machines are servers... Or by web-like architecture where firefox is a web client/browser running on a PC and apache a web server running on a big iron. There are several pieces in the DNS architecture, and having a well defined, commonly accepted terminology for that will really helps. Those pieces includes (I'm sure I'm missing some): A) the "things" in the OS of most nodes, a.k.a. the stub resolver/local resolver/local name servie caching...Things of course get more complex as soon as local caching is involved. B) the "things" that IT/Service providers set up to resolve DNS names, a.k.a. DNS cache/DNS forwarders/DNS servers/DNS recursive resolvers. Those things come in different flavor, perform different roles, but there is no good name for the generic role they provide. C) the "things" that DNS administrator set to manage particular DNS zones, a.k.a. DNS servers as well. Of course, that fact that the same piece of software is often use in those three roleS does not really help to clear the perceived confusion! It would help a lot in various documents (sometime done outside of the DNS wgs) if there was an agreed, referencable, terminoly for those three roles. - Alain. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org=20 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Paul Vixie > Sent: Thursday, February 02, 2006 9:51 AM > To: Hideshi Enokihara > Cc: namedroppers@ops.ietf.org > Subject: Re: [question]What is an accurate meaning of=20 > "client" in RFC2181?=20 >=20 > i believe that the terms "client" and "server" are inadequate=20 > to describe the roles of the various protocol agents in DNS,=20 > and as in RFC 2136, i suggest the terms "initiator" and=20 > "responder" instead. the the parts of RFC 2181 which you've=20 > quoted here, "client" really means "initiator". the DNS=20 > protocol specification must be understood in terms of=20 > messages -- their format and meaning. two messages make up a=20 > transaction, and each transaction is initiated by some=20 > protocol agent and responded to by others. >=20 > -- > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with the word 'unsubscribe'=20 > in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 02 16:42:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mDL-000144-VX for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 16:42:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15998 for ; Thu, 2 Feb 2006 16:40:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4mA6-0008fD-Fa for namedroppers-data@psg.com; Thu, 02 Feb 2006 21:38:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,RCVD_NUMERIC_HELO autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4mA2-0008eu-QE for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 21:38:38 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2006 13:38:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,81,1139212800"; d="scan'208"; a="21093072:sNHT23211392" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k12LcHPc019399; Thu, 2 Feb 2006 16:38:34 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 16:38:26 -0500 Received: from 161.44.65.204 ([161.44.65.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 21:38:26 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 02 Feb 2006 16:38:27 -0500 Subject: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs From: Ralph Droms To: , dhcwg CC: Stig Venaas , Olaf Kolkman , =?UTF-8?B?w5M=?=lafur Gu=?UTF-8?B?4oC6?=mundsson /DNSEXT co-chair , Message-ID: Thread-Topic: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcYoQQBSPx16PpQ0EdqhogARJOT6eg== In-Reply-To: <6.2.5.6.2.20060202093930.02e611a8@ogud.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 21:38:26.0581 (UTC) FILETIME=[00121C50:01C62841] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Included below is a summary list of the open issues in this package of documents: draft-ietf-dnsext-dhcid-rr-10.txt draft-ietf-dhc-ddns-resolution-10.txt draft-ietf-dhc-dhcpv6-fqdn-03.txt draft-ietf-dhc-fqdn-option-11.txt 1. Which DHCID RR encoding does an IPv4 client/server use (Brian Carpenter; Bernie has submitted text to resolve the issue) 2. Editorial comment on resolution doc section 6.3.2 and AAAA records (Ted Hardie) 3. s/byte/octet/g (Scott Hollenbeck) 4. Use example. or example.com. in examples (Scott Hollenbeck) 5. s/signature/hash value/g (Russ Housley) 6. In the resolution doc "security considerations" s/where or/whether or/ (Jon Peterson) 7. Add an 8-bit algorithm identifier to the DHCID RR to support algorithm agility (Allison Mankin) 8. Use of MD5 as opposed to a stronger hash function (Sam Hartman, Russ Housley) 9. Hash agility (Sam Hartman, Allison Mankin) 10. Russ's comment that an attacker that has some knowledge of MAC addresses does not need to do lot of work. I think this can be addressed in security considerations by saying this is not privacy but just obfuscation (Russ Housley) 11. UTF-8 character set usage (Harald Alvestrand, gen-art) Issues 1-6 are strictly editorial and the document editors will revise the documents to resolve those issues in the next revision. Issues 7-10 are all related to the hash algorithm specified in the documents and the requirements for algorithm agility. We will resolve those issues through an e-mail discussion to follow. Issue 11 needs some clarification; Harald, I hope you'll kick off a separate thread to discuss how to resolve this issue. - Ralph, for Olafur, Stig and Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 02 18:20:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4nks-0003ed-KX for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 18:20:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25715 for ; Thu, 2 Feb 2006 18:18:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4nh6-000FH2-Gn for namedroppers-data@psg.com; Thu, 02 Feb 2006 23:16:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4nh4-000FGp-8W for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 23:16:50 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C42E72596C9; Fri, 3 Feb 2006 00:15:34 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02418-04; Fri, 3 Feb 2006 00:15:30 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F8072596C6; Fri, 3 Feb 2006 00:15:27 +0100 (CET) Date: Thu, 02 Feb 2006 15:13:16 -0800 From: Harald Tveit Alvestrand To: Ralph Droms , namedroppers@ops.ietf.org, dhcwg Cc: Stig Venaas , Olaf Kolkman , =?UTF-8?Q?=C3=93lafur_Gu=E2=80=BAmundsson_=2FDNSEXT_co-chair?= Subject: UTF-8 issues (Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs) Message-ID: <3192DE48D9B41D1C2EC33A65@B50854F0A9192E8EC6CDA126> In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========26E6B02998774739D698==========" X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========26E6B02998774739D698========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 2. februar 2006 16:38 -0500 Ralph Droms wrote: > Included below is a summary list of the open issues in this package of > documents: > > draft-ietf-dnsext-dhcid-rr-10.txt > draft-ietf-dhc-ddns-resolution-10.txt > draft-ietf-dhc-dhcpv6-fqdn-03.txt > draft-ietf-dhc-fqdn-option-11.txt > 11. UTF-8 character set usage (Harald Alvestrand, gen-art) > > Issue 11 needs some clarification; Harald, I hope you'll kick off a > separate thread to discuss how to resolve this issue. > > - Ralph, for Olafur, Stig and Olaf I'll try.... back in the days (November - how time flies), my comments on=20 draft-ietf-dhc-fqdn-option-11.txt said: >A smaller piece of missing material is this, from section 3.3.1 of the v4 >document: > > Clients and servers SHOULD follow the character-set recommendations > of RFC 1034 [2] and RFC 1035 [3]. However, implementers SHOULD also > be aware that some client software could be using UTF-8 [10] > character encoding. This specification does not require any support > for UTF-8. > >Given DNS experts' insistence that the DNS protocol does not place any >limits on character sets, it would be good to have a clearer pointer to >what recommendations are intended here. >Given that it's in section 3.3.1 (Deprecated ASCII encoding), one can >assume that this refers to a character set recommendation for characters=20 in >the ASCII encoding; a DNS encoded name should probably be used "as is", no >matter what it contains (although it would be good if the doc said so). > > >It's also unclear from the text whether or not there's a trailing dot on >the name in the deprecated ASCII encoding (there's no need for one, since=20 a >non-FQDN name can only be one component, but other fields of use have done >this in the past, so it's best to be clear that this field does not do = so). On the point of character set recommendations, I think what you should be=20 pointing at is not 1034 and 1035 in general, but say that they SHOULD=20 follow the recommendation of RFC 1035 section 2.3.1. Since the rule was actually relaxed in RFC 1123 section 2.1, I think the=20 sentence should say "SHOULD follow the character set recommendation of RFC=20 1035 section 2.3.1, as modified by RFC 1123 section 2.1". That's not an UTF-8 issue, but is a charset issue. The UTF-8 text is a=20 cop-out (I think), but it's appropriate to cop-out here; you're basically=20 saying "don't be surprised if people don't do what this spec recommends". Does this make sense now? Harald --==========26E6B02998774739D698========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD4pIMOMj+2+WY0F4RAvZIAJ0X6mjMkoIMa7z8MyFxFx1RwWB0uACg6DyN s8bXurZt6s6CWcvE9ELeS/A= =I6Vk -----END PGP SIGNATURE----- --==========26E6B02998774739D698==========-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 02 19:02:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4oP2-00012m-PB for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 19:02:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28570 for ; Thu, 2 Feb 2006 19:00:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4oLn-000IQH-HE for namedroppers-data@psg.com; Thu, 02 Feb 2006 23:58:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4oLk-000IPs-US for namedroppers@ops.ietf.org; Thu, 02 Feb 2006 23:58:53 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 1078BE6097 for ; Thu, 2 Feb 2006 23:58:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k12NwKaB076140; Fri, 3 Feb 2006 10:58:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200602022358.k12NwKaB076140@drugs.dv.isc.org> To: Harald Tveit Alvestrand Cc: Ralph Droms , namedroppers@ops.ietf.org, dhcwg , Stig Venaas , Olaf Kolkman , =?UTF-8?Q?=C3=93lafur_Gu=E2=80=BAmundsson_=2FDNSEXT_co-chair?= From: Mark Andrews Subject: Re: UTF-8 issues (Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs) In-reply-to: Your message of "Thu, 02 Feb 2006 15:13:16 -0800." <3192DE48D9B41D1C2EC33A65@B50854F0A9192E8EC6CDA126> Date: Fri, 03 Feb 2006 10:58:20 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > --On 2. februar 2006 16:38 -0500 Ralph Droms wrote: > > > Included below is a summary list of the open issues in this package of > > documents: > > > > draft-ietf-dnsext-dhcid-rr-10.txt > > draft-ietf-dhc-ddns-resolution-10.txt > > draft-ietf-dhc-dhcpv6-fqdn-03.txt > > draft-ietf-dhc-fqdn-option-11.txt > > 11. UTF-8 character set usage (Harald Alvestrand, gen-art) > > > > Issue 11 needs some clarification; Harald, I hope you'll kick off a > > separate thread to discuss how to resolve this issue. > > > > - Ralph, for Olafur, Stig and Olaf > > I'll try.... > back in the days (November - how time flies), my comments on=20 > draft-ietf-dhc-fqdn-option-11.txt said: > > >A smaller piece of missing material is this, from section 3.3.1 of the v4 > >document: > > > > Clients and servers SHOULD follow the character-set recommendations > > of RFC 1034 [2] and RFC 1035 [3]. However, implementers SHOULD also > > be aware that some client software could be using UTF-8 [10] > > character encoding. This specification does not require any support > > for UTF-8. > > > >Given DNS experts' insistence that the DNS protocol does not place any > >limits on character sets, it would be good to have a clearer pointer to > >what recommendations are intended here. > >Given that it's in section 3.3.1 (Deprecated ASCII encoding), one can > >assume that this refers to a character set recommendation for characters=20 > in > >the ASCII encoding; a DNS encoded name should probably be used "as is", no > >matter what it contains (although it would be good if the doc said so). > > > > > >It's also unclear from the text whether or not there's a trailing dot on > >the name in the deprecated ASCII encoding (there's no need for one, since=20 > a > >non-FQDN name can only be one component, but other fields of use have done > >this in the past, so it's best to be clear that this field does not do = > so). > > On the point of character set recommendations, I think what you should be=20 > pointing at is not 1034 and 1035 in general, but say that they SHOULD=20 > follow the recommendation of RFC 1035 section 2.3.1. > Since the rule was actually relaxed in RFC 1123 section 2.1, I think the=20 > sentence should say "SHOULD follow the character set recommendation of RFC=20 > 1035 section 2.3.1, as modified by RFC 1123 section 2.1". RFC 1123 relaxed RFC 952 (and RFC 822 by implication) not RFC 1035. It relaxed to *hostnames* not domain names. Domain names were already general enough to support mapping the expanded hostnames to domainnames using the null mapping. The rest follows from that relaxation. RFC 1035 section 2.3.1 is advisary based on the state of RFC 952 and RFC 822 when it was written. > That's not an UTF-8 issue, but is a charset issue. The UTF-8 text is a=20 > cop-out (I think), but it's appropriate to cop-out here; you're basically=20 > saying "don't be surprised if people don't do what this spec recommends". For IDN's I would recommend using the output of ToASCII. > Does this make sense now? > > Harald > > > > --==========26E6B02998774739D698========== > Content-Type: application/pgp-signature > Content-Transfer-Encoding: 7bit > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (MingW32) > > iD8DBQFD4pIMOMj+2+WY0F4RAvZIAJ0X6mjMkoIMa7z8MyFxFx1RwWB0uACg6DyN > s8bXurZt6s6CWcvE9ELeS/A= > =I6Vk > -----END PGP SIGNATURE----- > > --==========26E6B02998774739D698==========-- > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 02 21:14:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qT2-0004aU-W7 for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 21:14:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11288 for ; Thu, 2 Feb 2006 21:12:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4qOc-0001so-1d for namedroppers-data@psg.com; Fri, 03 Feb 2006 02:09:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4qOY-0001sP-4i for namedroppers@ops.ietf.org; Fri, 03 Feb 2006 02:09:54 +0000 Received: (qmail 43748 invoked from network); 3 Feb 2006 03:01:18 -0000 Received: from softbank219001188003.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.3) by necom830.hpcl.titech.ac.jp with SMTP; 3 Feb 2006 03:01:18 -0000 Message-ID: <43E2BB9D.2000407@necom830.hpcl.titech.ac.jp> Date: Fri, 03 Feb 2006 11:10:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Mark Andrews CC: Harald Tveit Alvestrand , Ralph Droms , namedroppers@ops.ietf.org, dhcwg , Stig Venaas , Olaf Kolkman , =?ISO-2022-JP?B?TydsYWZ1ciBHdT5tdW5kc3M=?= =?ISO-2022-JP?B?b24gL0ROU0VYVCBjby1jaGFpcg==?= Subject: Re: UTF-8 issues (Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs) References: <200602022358.k12NwKaB076140@drugs.dv.isc.org> In-Reply-To: <200602022358.k12NwKaB076140@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Andrews wrote: >>On the point of character set recommendations, I think what you should be=20 >>pointing at is not 1034 and 1035 in general, but say that they SHOULD=20 >>follow the recommendation of RFC 1035 section 2.3.1. >>Since the rule was actually relaxed in RFC 1123 section 2.1, I think the=20 >>sentence should say "SHOULD follow the character set recommendation of RFC=20 >>1035 section 2.3.1, as modified by RFC 1123 section 2.1". > > > RFC 1123 relaxed RFC 952 (and RFC 822 by implication) not > RFC 1035. It relaxed to *hostnames* not domain names. > Domain names were already general enough to support mapping > the expanded hostnames to domainnames using the null mapping. > > The rest follows from that relaxation. RFC 1035 section > 2.3.1 is advisary based on the state of RFC 952 and RFC > 822 when it was written. DHCP should not try to define or give improper descriptions on anything about domainnames nor hostnames. DHCP should just refer relevant STDs and RFCs without referring to UTF-8, ASCII nor character sets. That's how we can keep standards orthogonal. Extra infromation is useless to those who knows them and harmful to those who don't already have enough knowledge on them. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From faurkyou@bandarbinsultan.com Thu Feb 02 23:24:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4sUg-0002Bt-Ud for dnsext-archive@megatron.ietf.org; Thu, 02 Feb 2006 23:24:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19686 for ; Thu, 2 Feb 2006 23:22:27 -0500 (EST) Received: from [201.154.179.132] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4sfg-0004bZ-1T for dnsext-archive@ietf.org; Thu, 02 Feb 2006 23:35:59 -0500 Message-ID: <000001c628a3$7dae6800$0100007f@localhost> From: "Aden Butler" To: Subject: Buy OEM Software Date: Thu, 02 Feb 2006 22:23:53 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C628A3.7DAE6800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C628A3.7DAE6800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C628A3.7DAE6800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Norton Antivirus 2005

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downlo! ad!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 50 ! reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 31 reviews)

------=_NextPart_000_0001_01C628A3.7DAE6800-- From owner-namedroppers@ops.ietf.org Fri Feb 03 02:57:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4von-0003EQ-W9 for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 02:57:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03119 for ; Fri, 3 Feb 2006 02:55:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4vjW-000OnL-9V for namedroppers-data@psg.com; Fri, 03 Feb 2006 07:51:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4vjV-000On7-FV for namedroppers@ops.ietf.org; Fri, 03 Feb 2006 07:51:53 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 518442596D1; Fri, 3 Feb 2006 08:50:37 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19203-02; Fri, 3 Feb 2006 08:50:32 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0EFF2596C9; Fri, 3 Feb 2006 08:50:14 +0100 (CET) Date: Thu, 02 Feb 2006 23:25:42 -0800 From: Harald Tveit Alvestrand To: "Bernie Volz (volz)" , Mark Andrews Cc: Olaf Kolkman , namedroppers@ops.ietf.org, dhcwg , Stig Venaas , =?UTF-8?Q?=C3=93lafur_Gu=3Emundsson_=2FDNSEXT_co-chair?= , "Ralph Droms (rdroms)" Subject: RE: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs) Message-ID: <5EE566F545BC29C241FA03A2@B50854F0A9192E8EC6CDA126> In-Reply-To: <8E296595B6471A4689555D5D725EBB21012DC25E@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21012DC25E@xmb-rtp-20a.amer.cisco .com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========5947F3AB260E64470B3A==========" X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========5947F3AB260E64470B3A========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 2. februar 2006 23:12 -0500 "Bernie Volz (volz)" =20 wrote: > Actually, I do now have a suggestion: > > Clients and servers SHOULD follow the character-set recommendations > of RFC 1035 section 2.3.1. However, implementers SHOULD also > be aware that some client software may use other character-sets. > This specification does not require support for any other > character-sets. > > If you don't like this, PLEASE SUGGEST ALTERNATIVE TEXT. Bernie - are my messages not getting through to the DHCWG list? I like this text, but you need to add the reference to RFC 1123 section 2.1 = I mentioned earlier (the text that allows 3com) - and Mark Andrews seems to = want to reference RFC 952 rather than RFC 1035. My suggestion (slight modification) would be: > Clients and servers SHOULD follow the character-set recommendations > of RFC 1035 section 2.3.1, as modified by RFC 1123 section 2.1. > However, implementers SHOULD also > be aware that some client software may send data intended to be > in other character sets. > This specification does not require support for any other > character sets. If referring to 952: Clients and servers SHOULD follow the character-set rules of RFC 952, fourth section, first 2 sentences, as modified by RFC 1123 section 2.1. However, implementers SHOULD also be aware that some client software may send data intended to be in other character sets. This specification does not require support for any other character sets. That's specific... Harald --==========5947F3AB260E64470B3A========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD4wV2OMj+2+WY0F4RAhTsAKDHkND0Z8wF4EaiYDFwBH4YQ/p2mQCfYQ42 T2tUN+aCVfNDVB33LKs+Vhg= =csid -----END PGP SIGNATURE----- --==========5947F3AB260E64470B3A==========-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From storm@hendrix.net Fri Feb 03 04:37:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4xNT-0002RR-L4 for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 04:37:16 -0500 Received: from catv-50630881.catv.broadband.hu (catv-50630881.catv.broadband.hu [80.99.8.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09712 for ; Fri, 3 Feb 2006 04:35:36 -0500 (EST) Received: from mail by microsoft.com with local id 06-2-4; Fri, 03 Feb 2006 00:03:49 -0600 Message-ID: <2413@resistor> From: Mayra Shoemaker To: dnsext-archive@ietf.org Subject: Amazing, Felix Date: Thu, 02 Feb 2006 21:37:54 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 33589236.9542.31567073.94511 X-MimeOLE: Produced By Microsoft MimeOLE 81465028.94530.203670.0181319 Content-Type: multipart/mixed; boundary="------=5648718917243" Content-Transfer-Encoding: 7bit --------=5648718917243 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Time is generally the best doctor.Loyalty to petrified opinions never yet broke a chain or freed a human soul in this world -- and never will.
Beauty when unadorned is adorned the most. --------=5648718917243 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Karina-> http://pcewul.winnote.info/?70843356 --------=5648718917243-- From kleinerwu@antiquewoodsource.com Fri Feb 03 09:00:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51UM-0001yd-Ig for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 09:00:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29802 for ; Fri, 3 Feb 2006 08:58:40 -0500 (EST) Received: from 535230b9.cable.casema.nl ([83.82.48.185] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F51fZ-0002oD-MB for dnsext-archive@ietf.org; Fri, 03 Feb 2006 09:12:17 -0500 Message-ID: <000001c628f3$b37b3d00$0100007f@localhost> From: "Bryant Foster" To: Subject: Photoshop, Windows, Office Date: Fri, 03 Feb 2006 14:59:55 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C628F3.B37B3D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C628F3.B37B3D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C628F3.B37B3D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 42 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 32 revi! ews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 38 reviews)

------=_NextPart_000_0001_01C628F3.B37B3D00-- From owner-namedroppers@ops.ietf.org Fri Feb 03 09:22:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51pF-0003GC-ND for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 09:22:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02079 for ; Fri, 3 Feb 2006 09:20:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F51hd-000Pz6-00 for namedroppers-data@psg.com; Fri, 03 Feb 2006 14:14:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F51hc-000Pyn-42 for namedroppers@ops.ietf.org; Fri, 03 Feb 2006 14:14:20 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO000A84; 3 Feb 2006 09:15:16 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 3 Feb 2006 09:15:08 -0500 Received: from connotech.com (209.71.204.111) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG000A83; 3 Feb 2006 09:15:06 -0500 Message-ID: <43E36DB4.6060906@connotech.com> Date: Fri, 03 Feb 2006 09:50:28 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Implementation work done on DNSSEC trust anchor key rollover solution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the solution space for trust anchor key rollover, there are two individual Internet drafts: http://www.ietf.org/internet-drafts/draft-moreau-dnsext-sdda-rr-01.txt http://www.ietf.org/internet-drafts/draft-moreau-dnsext-takrem-dns-01.txt Implementation work has been done, so that updated software tools are now available (GPL'ed free software). See http://www.connotech.com/takrem_tools/trust-anchor-foundry_02.tar.gz This update includes a complete solution for DNS zone management procedures (i.e. trust anchor key management and DNS authoritative nameserver operations), and an API for TAKREM support in DNSSEC-aware resolver software. The software development planning aspects are covered in two documents, respectively for the server side at http://www.connotech.com/trustanchfoundry_09.pdf and the client side at http://www.connotech.com/takrollover_06.pdf. If the DNSSEC security services are important enough to deserve good trust anchor key procedures, here they are. Enjoy! -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 03 10:18:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52hv-0006tP-PH for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 10:18:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09084 for ; Fri, 3 Feb 2006 10:17:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F52eT-00058p-Au for namedroppers-data@psg.com; Fri, 03 Feb 2006 15:15:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F52eQ-00057x-Cc for namedroppers@ops.ietf.org; Fri, 03 Feb 2006 15:15:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F2CD111426 for ; Fri, 3 Feb 2006 15:15:05 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Implementation work done on DNSSEC trust anchor key rollover solution In-Reply-To: Your message of "Fri, 03 Feb 2006 09:50:28 EST." <43E36DB4.6060906@connotech.com> References: <43E36DB4.6060906@connotech.com> Date: Fri, 03 Feb 2006 15:15:05 +0000 Message-Id: <20060203151505.F2CD111426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # In the solution space for trust anchor key rollover, there are two # individual Internet drafts: # # http://www.ietf.org/internet-drafts/draft-moreau-dnsext-sdda-rr-01.txt # http://www.ietf.org/internet-drafts/draft-moreau-dnsext-takrem-dns-01.txt and there's the mstjohns draft, and the ihren/kolkman draft, and my slides which i may yet turn into a draft, and the unpublished "requirements draft". # Implementation work has been done, so that updated software tools are now # available (GPL'ed free software). See # http://www.connotech.com/takrem_tools/trust-anchor-foundry_02.tar.gz to reiterate from the most recent dnsext meeting, GPL isn't adequate for ISC nor for any member of the BIND Forum who has spoken up or been asked about it. unless takrem's specification is released without IPR limitations, so that dnsext can rewrite it any way they want to and implementors can put it into products without worrying about patents or licensing, we'll ignore it. # This update includes a complete solution for DNS zone management # procedures (i.e. trust anchor key management and DNS authoritative # nameserver operations), and an API for TAKREM support in DNSSEC-aware # resolver software. truly, the quality of this implementation sounds very high indeed. it's a shame that the IPR limitations on takrem have poisoned it before the outset. # The software development planning aspects are covered in two documents, # respectively for the server side at # http://www.connotech.com/trustanchfoundry_09.pdf and the client side at # http://www.connotech.com/takrollover_06.pdf. # # If the DNSSEC security services are important enough to deserve good # trust anchor key procedures, here they are. they are that important, but takrem has self-deselected from the solution space for non-quality reasons. i admire the heck out of the document and implementation quality, and the marketing push behind it. but there are other workable solutions which do not depend on patented technology, and speaking now as president of ISC, as an implementor of BIND, and as a member of the DNS protocol development community, i am committed to helping bringing about an IPR-free solution. which means, apparently, that i have to turn my slide set into an I-D -- the WG's plan for a requirments draft having now fallen by the wayside, it's a going to be free for all and i need to get my own dog into this fight. (sad.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From daniel@apartca.com Fri Feb 03 14:21:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F56V5-0002KF-Fn for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 14:21:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01044 for ; Fri, 3 Feb 2006 14:19:45 -0500 (EST) Received: from cpe-66-69-100-166.satx.res.rr.com ([66.69.100.166] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F56gO-0008V3-7N for dnsext-archive@ietf.org; Fri, 03 Feb 2006 14:33:25 -0500 Message-ID: <000001c62920$f0115d80$0100007f@localhost> From: "Brian Diaz" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Fri, 03 Feb 2006 13:21:30 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62920.F0115D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62920.F0115D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62920.F0115D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 34 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 47 revi! ews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 47 reviews)

------=_NextPart_000_0001_01C62920.F0115D80-- From rebecca@aroojiswineroom.com Fri Feb 03 16:42:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58hM-0003NA-Ts for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 16:42:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17968 for ; Fri, 3 Feb 2006 16:40:54 -0500 (EST) Received: from 69-175-61-228.ontrca.adelphia.net ([69.175.61.228] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F58t0-0007yO-St for dnsext-archive@ietf.org; Fri, 03 Feb 2006 16:54:35 -0500 Message-ID: <000001c62934$5a7fc900$0100007f@localhost> From: "Jimmy Russell" To: Subject: Buy OEM Software Date: Fri, 03 Feb 2006 13:42:24 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62934.5A7FC900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62934.5A7FC900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62934.5A7FC900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 34 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 31 revi! ews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)

------=_NextPart_000_0001_01C62934.5A7FC900-- From owner-namedroppers@ops.ietf.org Fri Feb 03 19:09:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5Azq-0003xM-NL for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 19:09:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29381 for ; Fri, 3 Feb 2006 19:07:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5AuO-000HEL-Rx for namedroppers-data@psg.com; Sat, 04 Feb 2006 00:04:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5AuN-000HE8-Cf for namedroppers@ops.ietf.org; Sat, 04 Feb 2006 00:04:07 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E6922596E0; Sat, 4 Feb 2006 01:02:51 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09443-05; Sat, 4 Feb 2006 01:02:47 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C76522596DF; Sat, 4 Feb 2006 01:02:44 +0100 (CET) Date: Fri, 03 Feb 2006 15:49:12 -0800 From: Harald Tveit Alvestrand To: "Bernie Volz (volz)" , Mark Andrews Cc: Olaf Kolkman , namedroppers@ops.ietf.org, dhcwg , Stig Venaas , =?UTF-8?Q?=C3=93lafur_Gu=3Emundsson_=2FDNSEXT_co-chair?= , "Ralph Droms (rdroms)" Subject: RE: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs) Message-ID: <55F1F311DFEF54D9F8A0ADF4@B50854F0A9192E8EC6CDA126> In-Reply-To: <8E296595B6471A4689555D5D725EBB21012DC532@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21012DC532@xmb-rtp-20a.amer.cisco .com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1399869266E8D596B77B==========" X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========1399869266E8D596B77B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 3. februar 2006 17:54 -0500 "Bernie Volz (volz)" =20 wrote: > So, I'll change the text to what you suggested with one minor change: > > Clients and servers SHOULD follow the character-set rules of RFC 952, > fourth section ("Assumptions"), first 5 sentences, as modified by RFC > 1123 section 2.1. However, implementers SHOULD also be aware that > some client software may send data intended to be in other character > sets. This specification does not require support for other character > sets. > > Note that I changed it to cover the 5 sentences because I believe the > additional sentences are required (lower case and space rules)? Agreed - my writing was sloppy; I wanted to avoid the "-gw" language, but=20 saying "character set rules" accomplishes that. (Do omit the hyphen..... "character set" is much more common than=20 "character-set"...) Harald --==========1399869266E8D596B77B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD4+v5OMj+2+WY0F4RAm7ZAKDpJqCnQG+wLR6GLEJJd/ormIpeowCgqYBJ j7mUJcVniX4nzio5FpecbY0= =8bf6 -----END PGP SIGNATURE----- --==========1399869266E8D596B77B==========-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 03 20:40:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5CPy-0005Ko-Ty for dnsext-archive@megatron.ietf.org; Fri, 03 Feb 2006 20:40:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19355 for ; Fri, 3 Feb 2006 20:39:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5CMZ-000Nv0-3G for namedroppers-data@psg.com; Sat, 04 Feb 2006 01:37:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5CMY-000Nuk-BO for namedroppers@ops.ietf.org; Sat, 04 Feb 2006 01:37:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6BD8111427 for ; Sat, 4 Feb 2006 01:37:17 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: the RD bit is troubling me today Date: Sat, 04 Feb 2006 01:37:17 +0000 Message-Id: <20060204013717.6BD8111427@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk We've spent about half of the total DNSSEC development era to date (that is around six years out of the twelve) going down ratholes due to misunderstanding 1034/1035. Sometimes we amend 1034/1035 to explain something that didn't used to need to be explained; sometimes we amend 1034/1035 to explain something that we thought had been explained that turned out to have ambiguities... The result of DNSSEC is that we now understand far more about the delegation model and wildcards (among other things) than we used to know. Sort of like one of the great side-benefits of NASA's moon programme was the ballpoint pen. There's been some interest recently in the question "should a nameserver also be recursive, if it's authoritative for any zones?" The old, sad, answer has been "don't do it, since BIND4 was terrible about mixing recursive and authority data, and dual-purpose nameservers are a recipe for cache pollution" but it turns out that since BIND8, BIND9, and all modern non-BIND servers can safely mix authority and recursive data, folks are starting to do this again. It's not that hard to run two nameservers on a host, and just use different IP addresses for your resolv.conf file vs. your NS RR -> A/AAAA RR chain, but even though it's not hard, it's not as easy as just using one nameserver. While the RD bit in a query can disambiguate the case of a name-below-zonecut such that if RD=0 a dual-use server will return a delegation whereas if RD=1 it will go fetch the data, I don't think this helps when the qname is equal to a zonecut name. An authority server should respond with a non-AA delegation in that case, since the zone ends above the zonecut. A recursive server should respond with a non-AA answer in that case. But the non-AA answer should be first retrieved from the apex of the subzone, by following the delegation, all without allowing an RD=1 query to affect subsequent RD=0 results. A dual-use server would therefore have to maintain separate NS RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers. 1034/1035 does not anywhere say this, but it's the implication of the other "intent of the framers" clarifications we've made to 1034/1035 during the DNSSEC development era. But if we were going to write another clarification document on this point, I'd rather we just said "nameservers that offer both authority and recursive service are undefined, please just don't do it" than to try to describe how many RD bits should be dancing on the head of this pin. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From pollypink@143desi.com Sat Feb 04 06:18:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5LQe-00057J-Ii for dnsext-archive@megatron.ietf.org; Sat, 04 Feb 2006 06:18:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27503 for ; Sat, 4 Feb 2006 06:16:26 -0500 (EST) Received: from [219.255.138.138] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5LcL-0004BM-BS for dnsext-archive@ietf.org; Sat, 04 Feb 2006 06:30:15 -0500 Message-ID: <000001c629a6$7623b780$0100007f@localhost> From: "Lance Gray" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Sat, 04 Feb 2006 20:17:56 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C629A6.7623B780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C629A6.7623B780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C629A6.7623B780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 33 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 35 revi! ews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)

------=_NextPart_000_0001_01C629A6.7623B780-- From jennim@biramor.com Sat Feb 04 14:41:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5THg-000153-NF for dnsext-archive@megatron.ietf.org; Sat, 04 Feb 2006 14:41:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02111 for ; Sat, 4 Feb 2006 14:39:35 -0500 (EST) Received: from host2-141.pool877.interbusiness.it ([87.7.141.2] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5TT4-0002FU-ST for dnsext-archive@ietf.org; Sat, 04 Feb 2006 14:53:30 -0500 Message-ID: <000001c629ec$ddfcf100$0100007f@localhost> From: "Brennan Green" To: Subject: Buy OEM Software Date: Sat, 04 Feb 2006 20:49:54 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C629EC.DDFCF100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C629EC.DDFCF100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C629EC.DDFCF100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    ! Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 34 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 50 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 40 reviews)

------=_NextPart_000_0001_01C629EC.DDFCF100-- From xiko_vila69@badsuf.com Sat Feb 04 17:01:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5VT7-0001dc-1h for dnsext-archive@megatron.ietf.org; Sat, 04 Feb 2006 17:01:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11463 for ; Sat, 4 Feb 2006 16:59:11 -0500 (EST) Received: from [85.21.218.63] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5VeT-0001CM-Cq for dnsext-archive@ietf.org; Sat, 04 Feb 2006 17:13:06 -0500 Message-ID: <000001c62a00$35588c80$0100007f@localhost> From: "Caleb Ramirez" To: Subject: Buy OEM Software Date: Sun, 05 Feb 2006 01:00:22 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62A00.35588C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62A00.35588C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62A00.35588C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    ! Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 31 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 40 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)

------=_NextPart_000_0001_01C62A00.35588C80-- From gzpqnzcidf6@ocn.ne.jp Sat Feb 04 19:56:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5YCW-0002aO-Iv for dnsext-archive@megatron.ietf.org; Sat, 04 Feb 2006 19:56:24 -0500 Received: from ocn.ne.jp ([221.212.56.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22115 for ; Sat, 4 Feb 2006 19:54:11 -0500 (EST) Date: Sat, 4 Feb 2006 19:54:11 -0500 (EST) Message-Id: <200602050054.TAA22115@ietf.org> Received: from dccezk1 (unknown [188.58.231.109]) by smtp72 (Coremail) with SMTP id oyR4vApqyYosp1LP.1 for ; Tue, 28 Jan 2003 16:38:33 +0800 (CST) X-Originating-IP: [188.58.231.109] Subject: =?iso-2022-jp?B?GyRCOGE4ZSROJEgkLSRhJC0bKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2C460.5A9CB880" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2C460.5A9CB880 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCJEgkLSRhJC0kLE1fJDckJCEiTH4kNSRsJD8kJCQiJEokPyEiJGIkQyRIJWolQyVBJEskSiRq JD8kJCQiJEokPyRLISIbKEINChskQiRUJEMkPyRqJE49d0AtJCwkJCRrJTUlJCVIJCwkMyQzISob KEJodHRwOi8vd3d3LmF3ZzUubmV0Lz8yMDA1GyRCPWMwJiEiSVROUSEiQk4kQCQxJE40WDc4IUQk IiRKJD8kTiVLITwlOiRLMX4kKCReJDkhIxsoQg0KGyRCOkc2YSEiJCIkSiQ/JE42YSQvJEsweiRD MVskNyRGJC0kPz13QC1DIyROJT8lJCVXJHI+UjJwJDckXiQ5ISMbKEINChskQiEmI007UiFEIVY7 ZCROTFYlPyUkJURHSyQkJEYkLyRAJDUkJCEjQlQkQyRGJCQkXiQ5ISMhVxsoQg0KGyRCISYjUztS IUQhViRfJEMkNyRqJCo/LCRORnkkSz8pJCQ5fiRzJEA7ZCROQyYkLiQ/JEYkTiNUJVAbKEINCiAg ICAgICAgIBskQiVDJS8kTj0tJCRTTCQuJD8kJCRHJDkkKyEpJVIlQyVXJWklJCVzJEg1UyRLJE88 Kz8uJCwkIiRrJHMkRyQ5ISMhVxsoQg0KGyRCISYjQUh+IUQhViRoJDEkbCRQJCoycSQkJDckPyQk JEckOSRNISMxWEEwJE4lXiVzJTclZxsoQg0KICAgICAgICAgGyRCJXMkSz07JHMkRyQkJF4kOSEj IVcbKEINChskQiQiJEokPyROJT8lJCVXJCxBKiRZJF4kOSEjJEkkJiQ+MXNOOCQ5JGskMyRIJEok LyQ0QWpDTCQvJEAkNSQkISobKEINChskQiQqNSQ3WiRLJDRNeE1RJC8kQCQ1JCQhIxsoQg0KaHR0 cDovL3d3dy5hd2c1Lm5ldC8/MjAwNRskQkZDJEslOyVsJVYkShsoQjMwGyRCQmUkTj13QC0kTkp9 JHJDZj80JEtJfTktJCRHL05wQVgkTkp9JEskNE14TVFEOiQkJEYkKiRqJF4kORsoQg0KGyRCISMb KEINChskQiQtJEMkSCQiJEokPyRyJDckIiRvJDskSyQ5JGskRyQ3JGckJiEqGyhCDQobJEIiKDNG PG89NTQpO28kSyRiOS05cCRyN0c6XCQ3JEYkJCReJDkhIxsoQg0KGyRCIiglbyVzJS8laiVDJS86 PjU9RXkwbEBaTDUkJCQzJEgkckpdPlokNyReJDkhIxsoQg0KDQoNCg0KGyRCR1s/LkRkO18kcjR1 Sz4kNSRsJGtKfSRPGyhCDQpwcmlvcml0eTZfbmV0QHlhaG9vLmNhGyRCJF4kRyVhITwlayRyJCpB dyRqMjwkNSQkISMbKEINCg== ------=_NextPart_000_0006_01C2C460.5A9CB880 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj IiBzaXplPTI+PEZPTlQgc2l6ZT0zPjxQUkU+PFRUPjxGT05UIGNsYXNzPWx0YnByZT4bJEIkSCQt JGEkLSQsTV8kNyQkISJMfiQ1JGwkPyQkJCIkSiQ/ISIkYiRDJEglaiVDJUEkSyRKJGokPyQkJCIk SiQ/JEshIhsoQg0KGyRCJFQkQyQ/JGokTj13QC0kLCQkJGslNSUkJUgkLCQzJDMhKhsoQjwvRk9O VD48L1RUPjwvUFJFPjxQUkU+PFRUPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxB IGhyZWY9Imh0dHA6Ly93d3cuYXdnNS5uZXQvPzIwMDUiPmh0dHA6Ly93d3cuYXdnNS5uZXQvPzIw MDU8L0E+PC9GT05UPjwvVFQ+PC9QUkU+PFBSRT48VFQ+PEZPTlQgY2xhc3M9bHRicHJlPhskQj1j MCYhIklUTlEhIkJOJEAkMSRONFg3OCFEJCIkSiQ/JE4lSyE8JTokSzF+JCgkXiQ5ISMbKEINChsk QjpHNmEhIiQiJEokPyRONmEkLyRLMHokQzFbJDckRiQtJD89d0AtQyMkTiU/JSQlVyRyPlIycCQ3 JF4kOSEjGyhCDQobJEIhJiNNO1IhRCFWO2QkTkxWJT8lJCVER0skJCRGJC8kQCQ1JCQhI0JUJEMk RiQkJF4kOSEjIVcbKEINChskQiEmI1M7UiFEIVYkXyRDJDckaiQqPywkTkZ5JEs/KSQkOX4kcyRA O2QkTkMmJC4kPyRGJE4jVCVQGyhCDQogICAgICAgICAbJEIlQyUvJE49LSQkU0wkLiQ/JCQkRyQ5 JCshKSVSJUMlVyVpJSQlcyRINVMkSyRPPCs/LiQsJCIkayRzJEckOSEjIVcbKEINChskQiEmI0FI fiFEIVYkaCQxJGwkUCQqMnEkJCQ3JD8kJCRHJDkkTSEjMVhBMCROJV4lcyU3JWcbKEINCiAgICAg ICAgIBskQiVzJEs9OyRzJEckJCReJDkhIyFXGyhCDQobJEIkIiRKJD8kTiU/JSQlVyQsQSokWSRe JDkhIyRJJCYkPjFzTjgkOSRrJDMkSCRKJC8kNEFqQ0wkLyRAJDUkJCEqGyhCDQobJEIkKjUkN1ok SyQ0TXhNUSQvJEAkNSQkISMbKEINCjwvRk9OVD48L1RUPjxUVD48Rk9OVCBmYWNlPSJNUyBVSSBH b3RoaWMiIHNpemU9Mj48QSBocmVmPSJodHRwOi8vd3d3LmF3ZzUubmV0Lz8yMDA1Ij5odHRwOi8v d3d3LmF3ZzUubmV0Lz8yMDA1PC9BPjwvRk9OVD48L1RUPjwvUFJFPjxQUkU+PFRUPjxGT05UIGNs YXNzPWx0YnByZT4bJEJGQyRLJTslbCVWJEobKEIzMBskQkJlJE49d0AtJE5KfSRyQ2Y/NCRLSX05 LSQkRy9OcEFYJE5KfSRLJDRNeE1RRDokJCRGJCokaiReJDkbKEINChskQiEjGyhCDQobJEIkLSRD JEgkIiRKJD8kciQ3JCIkbyQ7JEskOSRrJEckNyRnJCYhKhsoQg0KGyRCIigzRjxvPTU0KTtvJEsk YjktOXAkcjdHOlwkNyRGJCQkXiQ5ISMbKEINChskQiIoJW8lcyUvJWolQyUvOj41PUV5MGxAWkw1 JCQkMyRIJHJKXT5aJDckXiQ5ISMbKEINCg0KDQoNChskQkdbPy5EZDtfJHI0dUs+JDUkbCRrSn0k TxsoQg0KcHJpb3JpdHk2X25ldEB5YWhvby5jYTwvRk9OVD48L1RUPjxUVD48Rk9OVCBjbGFzcz1s dGJwcmU+GyRCJF4kRyVhITwlayRyJCpBdyRqMjwkNSQkISMbKEINCjwvRk9OVD48L1RUPjwvUFJF PjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C2C460.5A9CB880-- From sylv.ler@asafeplaceonline.com Sun Feb 05 06:59:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5iXl-00055K-2J for dnsext-archive@megatron.ietf.org; Sun, 05 Feb 2006 06:59:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01625 for ; Sun, 5 Feb 2006 06:57:15 -0500 (EST) Received: from host86-136-132-230.range86-136.btcentralplus.com ([86.136.132.230] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5ijM-0007T8-5o for dnsext-archive@ietf.org; Sun, 05 Feb 2006 07:11:06 -0500 Message-ID: <000001c62a75$311a8680$0100007f@localhost> From: "Brody James" To: Subject: Corel Draw Date: Sun, 05 Feb 2006 11:59:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62A75.311A8680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62A75.311A8680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62A75.311A8680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 39 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 41 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 49 reviews)

------=_NextPart_000_0001_01C62A75.311A8680-- From pl@bastacosi.com Sun Feb 05 10:40:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5lzi-0002OV-RZ for dnsext-archive@megatron.ietf.org; Sun, 05 Feb 2006 10:40:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20014 for ; Sun, 5 Feb 2006 10:38:01 -0500 (EST) Received: from 218-164-22-130.dynamic.hinet.net ([218.164.22.130] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5mAU-0004Cf-8c for dnsext-archive@ietf.org; Sun, 05 Feb 2006 10:52:05 -0500 Message-ID: <000001c62a94$20c5d400$0100007f@localhost> From: "Erick Parker" To: Subject: Photoshop, Windows, Office Date: Sun, 05 Feb 2006 23:33:29 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62A94.20C5D400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62A94.20C5D400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62A94.20C5D400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 33 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 46 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 48 reviews)

------=_NextPart_000_0001_01C62A94.20C5D400-- From AnneAddison@2010yp.com Sun Feb 05 10:50:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5m9u-0005vC-SX for dnsext-archive@megatron.ietf.org; Sun, 05 Feb 2006 10:50:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20741 for ; Sun, 5 Feb 2006 10:48:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5mLm-0005bm-EV for dnsext-archive@ietf.org; Sun, 05 Feb 2006 11:02:55 -0500 Received: from i216-58-49-63.cybersurf.com ([216.58.49.63]) by mx2.foretec.com with smtp (Exim 4.24) id 1F5m9c-0002QP-5R for dnsext-archive@ietf.org; Sun, 05 Feb 2006 10:50:20 -0500 Received: from V6qb@localhost by c1W.int (8.11.6/8.11.6); Sun, 05 Feb 2006 17:02:16 +0200 Message-ID: <9c0QyLxPgIrXyDKgywqcdE5ip.17k9easTu3@claysmith.biz> From: "White Tiger Tamer Siegfried Fischbacher" Reply-To: "White Tiger Tamer Siegfried Fischbacher" To: dnsext-archive@ietf.org Subject: Systemworks Photoshop CS2 9.0 $69.95 MS 2003 at Allison's softweb Date: Sun, 05 Feb 2006 19:02:16 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LauraMansfield@claysmith.biz Content-Type: multipart/mixed; boundary="--PBokmcuJkoDWVM4" X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db RjdjnZ4ur ----PBokmcuJkoDWVM4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable u6Wj8pLNwtRqjR= <= td width=3D18 height=3D231>


<= /b>f!

 Y
 .

 O
 O
 = ;O
 O
 O

 O
 O
 O
&nb= sp;O
 O

 O
 O
 O

Ov
&n= bsp;



e
.

29
49
29
29
00

79
29 49
49
49

29
49
09

50
 




D

=
M





A





M



= A
 


ow


ic





do  




ac



ut
 		 
=   V

nlo


ros





be
 =




rom



ode
 
isi
 = ;
ad
 

oft





Acr
Pho
Cr= e
Go
Ill

edi



sk 
 		 t Ou

Inst


 Win
 Off
 Off
=  Ser
 Ser

obat
tosh
ativ
Live
ustr
a St
  Dr
  Fl

Auto
  		r On

antl
 

dows
ice
ice
ver
ver=

 v7.
op C
e Su
 CS2
ator

u= dio
eamw
ash

CAD
 


li

y!

 X
 X
2K
2K
 2

0
S2
it
 1

 M
ea
MX

20
 <= /p>


ne




P
P
3
3
K

Pr

e=

1.

X
ve
 P

05
 

<= /td>

&nb= sp;
 Sto

 

 
Pro
Pro
Pro
= Ent.
Pro

o

2

0 CS

2004
r 8
ro=


 


re

Re
..

















 


=  &

t.
..

 $
 $
 $
=  $
 $

 $
 $
 $
 $  $

 $
 $
 $
 
 $  


 S

 P
..

27
49
= 59
79
66

44
59
11
39
49

99
39=
54

37
 

<= p>
av

ri
..

9.<= br> 9.
9.
9.
9.

9.
9.
99
9.
9.

= 9.
9.
9.

50
 


e

ce
..
00
00
00
00
00

00
00
.0
00
0= 0

00
00
00

.0
 


Up

&nbs= p;










0






0
 


 t

Ou
..

















&nb= sp;


o

r
..

$4
$4
$6<= br> $6
$6

$6
$6
$9
$4
$4

$6
$4
= $3

$9
 

<= p>
90

Pr
..
9.
9.
9.
9.
9.

9.
9.
9.
9.
= 9.

9.
9.
9.

9.
 


= %

ic
..

99
99
99
99
99

99 99
99
99
99

99
99
99

95
 <= /b>


Of

e
.

















 




ou
..

ve
ve
ve
ve=
ve

ve
ve
vr
ve
ve

ve
ve
ve
er
 

<= font face=3D"Courier New" size=3D2>


 S
..

r r
r
r
r

r
r
 $
r
r

r r
r

 $
 




av
.=

$2
$4
$5
$7
$7

$3
$5
10
$3 $4

$9
$3
$5

36
 

http://tributeware.com/?BOJ5mNKCvm= 7IT3f3Jxf6BbM0Q

----PBokmcuJkoDWVM4-- From carsontipper@avascctv.com Sun Feb 05 12:50:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5o1Z-0003W2-IO for dnsext-archive@megatron.ietf.org; Sun, 05 Feb 2006 12:50:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29317 for ; Sun, 5 Feb 2006 12:48:17 -0500 (EST) Received: from 168.red-88-1-168.dynamicip.rima-tde.net ([88.1.168.168] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5oDJ-0003AZ-Ku for dnsext-archive@ietf.org; Sun, 05 Feb 2006 13:02:23 -0500 Message-ID: <000001c62aa6$22989300$0100007f@localhost> From: "Bryan Wilson" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Sun, 05 Feb 2006 17:49:30 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62AA6.22989300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62AA6.22989300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62AA6.22989300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 50 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 39 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C62AA6.22989300-- From gilbert@yahoo.com Sun Feb 05 13:20:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5oUg-0004e3-Gh for dnsext-archive@megatron.ietf.org; Sun, 05 Feb 2006 13:20:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01322 for ; Sun, 5 Feb 2006 13:18:26 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5oga-0006ue-CP for dnsext-archive@ietf.org; Sun, 05 Feb 2006 13:32:32 -0500 Received: from p9231ed.sigant01.ap.so-net.ne.jp ([59.146.49.237] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1F5oUW-0000ar-HH for dnsext-archive@ietf.org; Sun, 05 Feb 2006 13:20:05 -0500 Date: Lun, 06 Feb 2006 03:19:50 +0100 From: "Fleischer" To: Subject: Any med for your girl to be happy! Message-ID: <000001c62a4e$7b3c4180$0100007f@neska> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="------------ms020700070106060404020304" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.4 (++++) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 This is a multi-part message in MIME format. --------------ms020700070106060404020304 Content-Type: multipart/alternative; boundary="------------ms020507090000070002040500" --------------ms020507090000070002040500 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable --------------ms020507090000070002040500 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""
 
--------------ms020507090000070002040500-- --------------ms020700070106060404020304 Content-Type: image/jpeg; name="image.jpg" Content-Transfer-Encoding: base64 Content-ID: <000701c62a48$e2358cd0$aa0fa8c0@sanya> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCACnAhwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDYooor 4MwGO/l4JHy9z6UI+/IIww6j0ofecKnGeren4U2KLGGYYx91c/d9ee9apQ5Lvf8Ar+v61CWmSsVh dgcEKSKfTJVLQuoGSVIFZLcDj4vEV2/h/SJRfRm9mvBHOAE3FCzDlcccBecVqjxXZmRR9lvBE1x9 mExRdm/0+9n9KyovDt2nh/SIhYxi9hvBJOQU3BAzHls88FeM0xdH1byYbM2BCJqf2ozeam3Zz2zn 9K9SUMPJvbd9Uuv9WNbRZq6TrF3deItTtJYpzBGyCPKKBEMHO45zzjjr+FF5qd5F4gvrVJsQxaa0 6LtHDg9c4z+HSpNPtL208TanM1qTa3ZjKzCRcLtU9RnPU+lVdVsdRGvXN3bWRuIp7A2wKyIu1ie+ 4isUqbqdLcq7b6fiTpcgi1+7iOhy3E5MM1tNNcgIuX2IW9OOnbFX08W2ZCtJa3kSvC06M6Lh1UZO MMaxRour3ENjC9gYfstnPCXaZCGZ4yoxg+pFPtvDt3JprrPa3SXcVo0URluUZCSMYUDoPrW06eHe ra+TXd/8D5FNRL974rVrCb7Pb3VvcNbG4geZFwV9Rgmq9n4juJ/D926fbJLmGJma5kijVUcLnGAf y4qCPw9dy6VKJLS7F5HaCCPzblGVvUKAeB9TU8uiahAlzHbW+6O809Y5VDqNsyrgdT39qOXDpcqt v/X4B7po2XiOE6eTcLM89vZR3M7BVw25QeOev5U/W9Vlh8JyapZMY3eOOSMsoJAYr1HIzg1zl3aX 2lWt2ZrUFJtNihJ85AUZUAbjOTgjtXU6fn/hFbLFt9pP2SL9z8vz/KOPm4rKpTpwcakdVdf8ElpL Uqw34sraW9uNaN8kcW9oI1iyOnPGDTX8X2UKu09rew7YROA6LlkLBRjDeprF1qwumNzff2Utjbx2 TowDxncxPopqO70jVdYt1mjsDGv9nRQpulT5yHVsjB449a1jQoytKbWvmlb7tCuVdToJPFtnAs5n tbyFoUWQo6LkhiAMYb3p91rDA2ReK+svNu0hCvFGTJnseThfcc1i3fh27utJu2S1uhfOscYFxco+ 9QwJwRwOnc1qalBqOqvpkh054Ps99HI6tKhOwdW4P6dazdOgmrW631XYVol2412K0vorWezu0E0w hjmKLsZj075x+FZGieKJJNPtI7qK5vL2YO/7iNPuhiPUDtVC28P6kLqyMunsJYr4TS3LTqQyBs9N 2f0qWz0G5ttJtEn0q4kvI1kXfDdLHsBYkDO4Zq/ZYeMbXTfqvPz/AFC0TsreUzwJK0UkJYZ2SAbh 9cE1JWboEF5baHbQ6gWN0obfufcfvHHPfjFaVedNJSaRm9woooqQCiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKAO/07TtPbSbSSSyhd3jXJ2Lz8o56e9WP7O0z/AKB8P/fC/wDxNGnf8gSx/wCua/8A oK1Iz7TjGa9r3YxWi2XTyKI/7O0z/oHw/wDfC/8AxNH9naZ/0D4f++F/+Jp/mn+7+tHmn+7+tHNH svuQrjP7O0z/AKB8P/fC/wDxNH9naZ/0D4f++F/+Jp/mn+7+tOVt2eMUXj2X3ILkX9naZ/0D4f8A vhf/AImj+ztM/wCgfD/3wv8A8TU9FPTsvuQyD+ztM/6B8P8A3wv/AMTR/Z2mf9A+H/vhf/ianoo0 7L7kBB/Z2mf9A+H/AL4X/wCJo/s7TP8AoHw/98L/APE1PRRp2X3ICD+ztM/6B8P/AHwv/wATR/Z2 mf8AQPh/74X/AOJqeijTsvuQFC48PeH7xw9zodjOwGA0sEbED8VqddM0pECJpsCqowAEUAD/AL5q xRVOV1b9EFytLpOkTxNFLpdvJGwwyvGhBHuNtKumaUiKiabAqqMBQigAf981YopX6WX3ICD+ztM/ 6B8P/fC//E0f2dpn/QPh/wC+F/8Aianopadl9yAg/s7TP+gfD/3wv/xNH9naZ/0D4f8Avhf/AImp 6KNOy+5AQf2dpn/QPh/74X/4mj+ztM/6B8P/AHwv/wATU9FGnZfcgIP7O0z/AKB8P/fC/wDxNH9n aZ/0D4f++F/+JqeijTsvuQEH9naZ/wBA+H/vhf8A4mj+ztM/6B8P/fC//E1PRRp2X3ICD+ztM/6B 8P8A3wv/AMTR/Z2mf9A+H/vhf/ianoo07L7kBB/Z2mf9A+H/AL4X/wCJo/s7TP8AoHw/98L/APE1 PRRp2X3ICD+ztM/6B8P/AHwv/wATR/Z2mf8AQPh/74X/AOJqeijTsvuQEH9naZ/0D4f++F/+Jo/s 7TP+gfD/AN8L/wDE1PRRp2X3ICD+ztM/6B8P/fC//E0f2dpn/QPh/wC+F/8Aianoo07L7kBB/Z2m f9A+H/vhf/iaP7O0z/oHw/8AfC//ABNT0Uadl9yAg/s7TP8AoHw/98L/APE0f2dpn/QPh/74X/4m p6KNOy+5AQf2dpn/AED4f++F/wDiaP7O0z/oHw/98L/8TU9FGnZfcgIP7O0z/oHw/wDfC/8AxNH9 naZ/0D4f++F/+JqeijTsvuQGdrkemaNYw3P9lwzeawXbhVxxnrtNYH/CQ6Z/0AIf++1/+Ira8cf8 gOy/66j/ANBNcKkMsiO6ROyoMuyqSF+vpXBmFapSxDhTtay6Lt6H02WZfhq2H56sbu/d/wCZ0H/C Q6Z/0AIf++1/+Io/4SHTP+gBD/32v/xFYf2K63on2abc4yo8s5Yeo9agIwcHrXC8XXW/5L/I9BZT gXtD8X/mdH/wkOmf9ACH/vtf/iKP+Eh0z/oAQ/8Afa//ABFc8iNI4RFLMxwFUZJNKYpBN5Jjfzc7 dmOc+mPWj65X8vuX+Q/7JwX8n4v/ADOg/wCEh0z/AKAEP/fa/wDxFH/CQ6Z/0AIf++1/+IrnzDKJ vJMT+bnGzad2fTFPNpchZGNvKFjOHOw4U+/pR9bxH9RX+Qv7KwP8n4v/ADN3/hIdM/6AEP8A32v/ AMRR/wAJDpn/AEAIf++1/wDiKw3s7qNSz20yqoBJKEAA9DUaQyyK7RxuyoMsVUkKPf0o+t4hO3/t q/yD+ysC1fk/F/5nQf8ACQ6Z/wBACH/vtf8A4ij/AISHTP8AoAQ/99r/APEVzlFL67W7r7l/kP8A sjBfyfi/8zo/+Eh0z/oAQ/8Afa//ABFOj13T5XCR+HY3c8BVZST/AOOUaX4dgSzOo61Ibe1Ayqk7 S319v1qnfePraxVrfw/YRRL085l5bHfHf8a9GlCvyqdaain05U2/lY4J4XBuThQpczXW7SXzudJb 2stwob/hFoY1P/PWVFP5bM1cGkEjJ0XTx7GYf/Gq8mvfEmsag2bi/mI/uq2B+QrMZ3dtzMSfUmtv rFKOyb9eVflEX9jxluor05n/AO3Hs8umyRj5fDtnJ/uTp/VBWPd6jBYttuvC4i5wCxXB+h2YNecW +p31owNvdzREdNrkV0unfELVLb93fKl7AeGDjnH170nVpT2bi/SLX5Jh/ZcYa8ikvWSf5tGz/wAJ Dpn/AEAIf++1/wDiKP8AhIdM/wCgBD/32v8A8RVmCDQPFdu0mmEWl8Bkw9AT9P6iuZu7SeyuXt7i MxyL1BrkxLxVC0m04vZpK35G+HwWX1m4+ztJbpt3/M3f+Eh0z/oAQ/8Afa//ABFb9jBp9/p8F2un W8YlBOworYwxHXA9K89r0Hw//wAi9Y/7r/8AoxqeCrzrTlGdnp2Xddkcmb4DD4egp0o2d7bvs+5b 07/kCWP/AFzX/wBBWnuCzgDkngCmad/yBLH/AK5r/wCgrVm1AbUI1PZS39P616sIc7jHvb8j5zcy 9Y12y0DEJj+03pGfLzhU+tYq+P73fmXT7Zos/dGQfz/+tXOrOt7qxub0uUlm3S4+9tzzj8K6TXTa S+GNNktLYQQtK+Ezk8EjJPc8VwPG1ZqcqUlGMdlbV6pfqcTrzldxdkjoLG/stZs2ubIlWT/WQt1W p4+9cT4LmeHxTDEpISZXVx2ICkj+VdsmMyKP4ZGX8jiuqjUVeiq1rO9mdFKp7SHMPoritGiufFF5 rt1danqFtJZ6o9nbLZ3BjSJIiCDs5Vy2Tu3hs9AAKp2viq+T+0YYDF9qbXLm0t4dstzLKE2cKjSq FABLM29UUL935uNOU1PQaK8Xv/HGp3sDauC8YbQVla1S4lSLzReiIuNjKwJAPQ5wcEkZz2f/AAlm qReMP7KvobSwikvPJtkuopF+1RbfvxzglC+Sp2FR94Lu3U3BgdrRRRUAFFFFABRRSE4BNAFe5u1g GBy38qy31rDlRJkg87V4H1rJ1XUCX2mTZvk2Fv7uTiovtUcMYUYjjXoM8VV0tD1aOGioJtXudCNV dBlyuB1zVqLU4ZAMnGe/UVyEl4p2kJukfhN4/M/SmNdBYwEmOUYRoox83Tr9c0uZFSwkJdLHeo6S DKMCPanVxq6i8LblfGD1zXT6bdG8sIpz1Yc+9HocFfDulZ3LdFFFI5wpjzRxvGjyIrStsjDMAXbB OB6nAJ+gNPrz7x4v2XX9M1OWOK/tIP8AX2ivtngAjnYyxtkbcqGbsS0CYORw0rgeg0V5B/zMf27/ AKnD7P8A2h/y8/cx5GP+eP8ADnf0/g7VN4Ws7q08ReFQIPMmb+0Te6nbSJLHfLnIZpEYswDFP9YB hiO9VyAes0UUVABRRRQAUUUUAFFFFABVe9vIdPs5bqckRxjJ2jJPYAfjVisbxV/yLV3/AMA/9DWr pxUpqL6sFuU/+E303/nhd/8AfC//ABVH/Cb6b/zwu/8Avhf/AIqsjwxapPpGsSfZ/Nnj8nyytotw 65Zs7Ubg8dfz7VszaXZS3bxWljbSGLW4xKkKiTZCUGd3HC53ZHQHI7V6n1OkacqG/wDCb6b/AM8L v/vhf/iqP+E303/nhd/98L/8VVNZNOMGrXq6fay/2VcP5G1V8udZXKrvGPmC9RgjjA461jaTHpz6 Xe/2ijKrzQxpcIMtASsh3Y/iHyjI9PcCj6nSDlR0v/Cb6b/zwu/++F/+Ko/4TfTf+eF3/wB8L/8A FVVutOFtpUw020tru/Sa3SQwwLP+7+zqdwBBwC2TuwM1YltNIbVdYtkt7YJYTR3yhEBLIoHnRk8j HXC8cn0HB9TpByod/wAJvpv/ADwu/wDvhf8A4qtnTNTt9WtPtFvvChipVxggj/6xH51xviSOytNP tUtoYlkvZHvifLAaONj+7QEDgYzleeR6YrZ8Ef8AIFm/6+G/9BWsMThoU4c0ROKSL/jj/kB2X/XU f+gmsfwcFuLu9sJDhLm2ZSff/wDUTWx44/5Adl/11H/oJrldCi1KXUlOlcXCKTuOMKOhznjvXh4q fJmMXa+2i66an1GAhz5dJXtvqz0Cae3eO6vkwG05JoV+u1T/AExXPQeH9Ne1gtGikN1NZG6+1Bzh Txxjpjn/ADms+S08QW93JpTEB9QLSMMriQ8knPbp7VWtdR1mRBosNxwcxBTtBA7jceg49a0rYuFS a9rSd9Vt100+62u6CjhJwj+6qK2j36a6/ffTZmxaWem2LaFIts5u7sxt5m84QgjJx75xVqKxsk1K fUJ4WmnbVRDHtcjyzuBB965ObUr+Ke3R5hvsTsiwq/Jg/Tnp3zUkHiHVLdp2iuipnfzHOxfveo44 /CueGNoRfK46LyXa333udE8FXkrqWr833/KxPrMxtvF0846xXAf8sGu7uYbXzJdPJH/Ez8x8jsQi jP8AWvOJory/huNUlKuN4Ej5AJY47U5tc1J7m2uGuSZbZdsTbF+UYx6c/jSoY6NCU3OLtN3Xpd3+ 9aBXwUq0YKEleKs/Wyt+Op1WtbbmPX2DuBbrDGqq5Cn1yOh5JqR7Gy0yw1iztoWWRLJTJKXJEhIb t26dq45tWvmS7Qz5W7bdONo+c5z6cfhU8niLVZbT7M90TEY/KI2LyvucZ/Gq/tCg5Obi7tPourl5 6br7rE/UKyioKStddX0UfLyf33N+80DSLXTZImZFulthKJjMdzNzxt6Acdaq6NZ2mj6W2vaqOF5g jbv6HHqe1Hh6/wBR1W6h02actZRrukG0ZKL0UnGSM4H0rm/HOvtqurNaxN/olsdigdC3c1vH6u4r FRja2iVuvfzt36mfLiHN4aUr31bv07eV+3QzfEHiO81+7MkzFYVP7uIHhR/jWPWjp2hanqsbyWNl LMifeZRx9M1reHPC0GsW/n3V8IFZiiKoDEY7tzwM4HuTWPs61ed3q2dvtKNCFlol2MC1sri9crBE zAFQzY4XJAGT25IrpNb8IQ6Vpsky3kj3MLYliaLAI4+ZfbJxk9f1rUmu9L0ez1XT7m3fT9RFt5O2 IEpOQco49D/jXM6j4q1XVLIWtzMmwqquUQK0gHTce9aunRpQanrJ/gYKpXrTUoaRX4rQxaKKK4jv JILiW1nSaCRo5EOVZTgivS9F1e18Z6edO1DbHqMS5jlH8XuP6ivMKntLuaxu4rm3cpLGwZSK3oVv Zvlkrxe6OfEYdVVeOklszo7m2ltLmS3nQpLGcMDXeeH/APkXrH/df/0Y1ZWtyxa94YtNbhQeahCz Y7A8HP0OPzrV8P8A/IvWP+6//oxqqhhvq+JlFO6cbp+TaPKzTEOvgoyas1KzXmky3p3/ACBLH/rm v/oK02e5+xXUF02fKQ7ZMdlPf8OtO07/AJAlj/1zX/0FakkjWWMowyCMV6EJcrjJeX5HzRwPiHR5 dH1F5FXdZzMXhkXkYPOKkvtUtZfC2m2kcubiF5DIm0jaCxI56d66QpqGmxNBDHHe2J/5d5v4f909 v1qlH5cc3mReEoFkzkM1yWAP021zTwEXKUqUklJWad9NU9PuOaWG1bi9yv4S097Nn128BjhiQiFT wZGIxx/L8a6ez3/ZlaT77ks31PNUo7e9v50uNSdcJ/q4IxhE/wAT71qdK6FCFKmqVPZfizeEFCPK jHvvC2jajeSXV1Z75JfL85RK6pNsOU8xAQsmP9oH06UxvCWiM7OLR45WupLzzYriRJBLIMOQ6sGU MMZUEDgcVt0Urso5v/hAvDP2X7N/Zv7n7P8AZtvnyf6vzfN253Z+/wA569unFXP+EW0b+0vt/wBj /ffaPtW3zX8rzsY8zy87N+P4sZzz15rYoouwCiiikAUUUUAFHUUUUAcJ4ksZbW6d2iaS2k5OBnbW AlxZxsGHJX7u9i236AmvV5Yo5kKSKGU9jWa/h3TnYsYFyfam1F6s7aONlTjytXR5617bysGIMrDp wTVm3hv7yXdbWe1j/wAtHHNd7DoenwEFLdcj2q8kSRjCIFHsKLRXmOePqPSKschZeEZ5mWS/nLDr sHArroIUt4VijGFUYFSUUN3OOc5Td5O4UUUUiQqneaVYahc2lxd2kU01nJ5tu7rkxtjGR+h+oB6g EXKKAKf9k6b/AGl/aP8AZ9p9u/5+fJXzem372M9OOvTin22n2VnNPNa2dvBLcNvmeKJVaVuTliBy eT19TVmigAooooAKKKKACiiigAooooAKqanYrqenTWbuUEgHzAZwQQR+oq3RTTad0Bx3/CB/9RL/ AMgf/ZUf8IH/ANRL/wAgf/ZV2NFdH1ut3/IfMzjv+ED/AOol/wCQP/sqP+ED/wCol/5A/wDsq7Gi j63W7/kHMzjv+ED/AOol/wCQP/sqP+ED/wCol/5A/wDsq7Gij63W7/kHMzjv+ED/AOol/wCQP/sq 6DRdJXRrE2yymUs5dmIxycDgfQCtGionXqTVpMG2zJ8cf8gOy/66j/0E1ieEftRvLoWywSAwnfBK xBkHoDj/ADmtvxx/yA7L/rqP/QTXCRyPE4eN2Rx0ZTgivJx9X2WOVTsl+R9bllL2uAcO7Z6ALVIP EehsPNhZ45c2rylxF8h6c8en4Uzy7e8n0Wd7WBS9xOjKqDBA3AZ9egrhGuJ2m85ppDL/AHyxz+dA nmG3Esg2klfmPB9qX9pw1XJo3f8A9J8v7v4m39mz0fPqlb/0rz8/wO70u1H2Z3gsYJXGqMjFowdk ecHH0FOsrOKOO9NlZwTMmqbBlA2xPl3Y9hk/SuQTWriPSPsCZX9953nKxDZxjFEGsz2+kPYRgrvm 87zVYhgcAY/StI5hQSirbL8ey0/EzlgKzcnfd/h33/A6S5s7OO11TyoYsJqEaqQo+XJXIHoMk8VY 1mGzNjq0TWkEUdtPBhkTB+bZuP5EiuEE0oUqJHwTuI3Hk+tKbiY7syudxBbLZzjpn1rB5jDlaUN/ /tv819xssvnzJue3/wBr/k/vO91y0jXStVb7HbJEiRfZpERcleM/rmvPq3LzxH9p0+a1hsILbz9v nNH/ABY9B2rDrLMa9OtUTp9v1b7I1y+jUo02qnf9EvM6bSJv7J8I6rqe7Dv+6TjuB/8AZfpXmpJZ ixOSTkmu/wBbYw/DO0x/y2u8H/x//wCJrz+uur7tKlBbKKf36meG96dSb3cmvu0PQfC+qLf6Gumf ZLMfZATuubkxo4Y85Ufe4zntjjvVHVvEttpWr30ehQWpt540Dt5eV8xedyf5681xlbmm+H5LrR5d YBSeC2mUTWyN85TqT7cf19K1jiKs4qEVquvkv+AZyw1KnNzm9H083/wTJmmuL25Ms0kk88h5ZiWZ jXTWHhOG68MXOoy3Dx3duzM9uEy20Y4I6jPPNdDBp+kWGs217axxpY6rDttZ+ptZgOMZ9f5is3xL r91o+r2n2eUHVIIDDeS+XhZumOD1+vvWiw8KSc6zv0+/r+voZvEzqtQoq3X7un6epc1yPSodDvk8 ux+w+Sjac8WBLv6FWHU85JJrziprq5mvLmS4nffLIxZjjGTW1p3g7VNStEnjMEfmKWhjlk2vKB3U envWFWUsTP3I7HRSjHCw/eS3/r/hzAwcZxx60ldLPbGLwFteIJPDqhjfjn7nQ1Qn8M6zbaf9umsJ Ut9u4seoHqR1FZyoyWyvpc1jXg93bW3qdN8Prj7Xa6norvhZ4SUJ5wSMH+ea6jw4SfDliD1CuD/3 8auC+H8pTxhaoOkiyA/98E/0ru9MfybR4h0juJ0/KZ676C56UZdrr8Ys8DN/ccorq4v8Gi5YSFdF scRu37sdMf3V96mEjH/li/6f40zTv+QJY/8AXNf/AEFanos7LXovyPBGb2/55P8AmP8AGje3/PJ/ zH+NSSGG2tzcXc6QQ/3nPX6VSXxB4ekfYupgN6sjAfmRirdO1uaSV+7SBtLdlne3/PJ/zH+NG9v+ eT/mP8amePaiyKyvG33XU5BplKUJRdmOwze3/PJ/zH+NG9v+eT/mP8afRU28xDN7f88n/Mf40b2/ 55P+Y/xp9FFvMBm9v+eT/mP8aN7f88n/ADH+NPoot5gM3t/zyf8AMf40b2/55P8AmP8AGn0UW8wG b2/55P8AmP8AGje3/PJ/zH+NPoot5gM3t/zyf8x/jRvb/nk/5j/Gn1A1zlzHAvmuOvOFX6n+nWrh SnUdo6g9CTe3/PJ/zH+NG9v+eT/mP8aj8uUnLXqof7qxZA/EnJ/Smm4aE/vsOn/PSMHj6jqP1ron gK8VfcVybe3/ADyf8x/jRvb/AJ5P+Y/xpysrqGVgynkEHINLXJZjGb2/55P+Y/xo3t/zyf8AMf40 +ii3mAze3/PJ/wAx/jRvb/nk/wCY/wAafRRbzAZvb/nk/wCY/wAaN7f88n/Mf40+ii3mAze3/PJ/ zH+NG9v+eT/mP8afRRbzAZvb/nk/5j/Gje3/ADyf8x/jT6KLeYDN7f8APJ/zH+NG9v8Ank/5j/Gn 0UW8wGb2/wCeT/mP8aN7f88n/Mf40+ii3mAze3/PJ/zH+NG9v+eT/mP8afRRbzAZvb/nk/5j/Gje 3/PJ/wAx/jT6KLeYDN7f88n/ADH+NG9v+eT/AJj/ABp9FFvMBm9v+eT/AJj/ABo3t/zyf8x/jT6K LeYDN7f88n/Mf40hkYf8sn/T/GpKKLPuBm+MYJrnRLJYYZJG8wEqiliBtPpXEf2ZqH/Pjc/9+m/w r1K5/wBRb/7v9BVassdg41azk30X5HsYTNp4Wn7OMUzzb+zNQ/58bn/v03+FH9mah/z43P8A36b/ AAr0miuP+zYfzHT/AKwVf5Eebf2ZqH/Pjc/9+m/wo/szUP8Anxuf+/Tf4V6TRR/ZsP5g/wBYKv8A Ijzb+zNQ/wCfG5/79N/hR/Zmof8APjc/9+m/wr0mij+zYfzB/rBV/kR5t/Zmof8APjc/9+m/wo/s zUP+fG5/79N/hXpNFH9mw/mD/WCr/Iji9dtpj8NrdJYnjeC63FXUggfN6/71ed17nqNkNT0O9sSA S6Er9e38q8OkRopGjcYZSQR6GunF0+WNNra1vu0O7K8T7eM29Hdv7xta2ga/ceH7x5oUWWKVdksL n5XH+NZNFckJyhJSi9UelOEZxcZK6Zsa14hn1f7PGsMVra22fJghGApPJP1qCys9Q8RassEbPPdS nl3bOAO5PoBXQ6L4De8s4rzVL1LGGfHkqcb3J6demfzrQ0azj8F+PY7O4nDw3UG1JCMY3HjPpyuP xrtWHqzlGdbSLa/4BwyxNKEZQoaySf8Awdeo1vhqj2ky2urxTX0I+eMAbQeflPOR+NMOt6Un9nNq qXdrqukARFIV4lC9Bnt2/M1Lq8F74R8aDU7dXezvJNzYGQdx5U+/ORUHxPsoYdWtLuPAe4jO8Af3 cYP6/pXTUjGlCUqcbOLs1v6M5acpVZwjUldSTaa0tpqiKPVBeaBqOpSwjaurxXLRZ4we3v0rSn13 S7O71LVoNV+0RX9uVNgVJbzCABnsAOa4a31R7fRbzTVjUpdOjsx6jbnpVCuT644pW1f66/ozr+pR k3fRfpp+qOp+HsJk8XW8gHESOx/FSP612Glu0tm0pBHmXE74PHBlcj+dYvgO3On6PqetsFDLGUhL dCf/ANeBXT6ZbFNLtgeuz+prsoQ5MMr9bv8AL/I8PN6ylXcV0t+v+Zb07/kCWP8A1zX/ANBWrMKi S6jjPT7x+gqtp3/IEsf+ua/+grUsUwg1S33HCyAx5PqeR/KqopOcU/L8jyVuef6rqv8AbGvGa68x rNJNqxocYQHt7mtiODRtYsdRWHTBaLawmSOcSEnI6Bvrj3rnGsLi31d9O8tjMJPLVfXniu1vvD+o QaNFpmnwq4f57mXeF3t2HPYf4V5VBV6s6kpR5rXvpd32SXVfLax50FOTk2rmT4I1KVNQOkysWt51 YopP3WAzx+RrrQeoPVSVP1FcR4LgebxLHcgYit0d5G7DKkD+f6V2VtIJo2lHSR2cfQnNdeDcpYSL n0bS9NP1OnDNulqc3ceN7a38Oa3q7Wcp/sq8ks3iDD946uFUg9gdyk8cc8HHNmx8V200Nx9qCC4g upLZobFZrlgybd3AiVsAsASFK8rzk4rL1HwVc3njiPVUniGnSXFveXClz53nQI6oEG3Gw7lzk564 IqsfBerK9wGksrqzm1q41CXT5JXSO4RwPLDsEJyrLkpgqe/QV0WibnQSeNPDsVtDcNqkRimt2uVZ VZsRg4LNgfL83ygNglvlGW4p9r4t0S8uHhgu3YxwpPI5t5BHFG0fmKzuV2qCvPJHp14rzuTwpq/h vTBDt+0Tvodzp7fZ7aadSXleQbdi5yQwX59gG4EF8Mo6rwp4W1XSYdSlluIrWe90+zghZf3jQSRQ eWxYfdOG5GCQcUOMbAdHY69p+o3klnBJKl1HGJTBcW8kDlCSNwWRQSMjGR0/GtKuH8K+D9Q0bxGm p3SWSD+zTazNDcPLJcTmQO0zlkHLc9zjgdOncVLST0AKKKKQBRRSEZBFAHD+JPGi2U00MUbvBEwV yjAFjkA8+grFHj0KsSJbOA24gblACq+3I9eeQKTxdoFxDNcssbPbzg7tvUZ9K4uaC2eOGFnkAgTy 8ZGWGQeePUZr7HA06M6K9h21738zzKs5wm+fv+B3sXjZJr+SzBwyFgcsO2O3YcjFOfxgiTzxE/6l CzHdyQBkgDqeK4VWhS7a6BPmszueeMtjPb2FNk8mWWSSSR23qy7C3yruGCRxwcCu76u7bGPttfke h6d4tYs0yDaFfbJGTkMcA/1613ttcJdW0U8f3JFDDPoa8V0PTbq6YQ2olZXbc0rnkngZ7dgK9l06 2Npp8MB/gUCvm84jRTio/H1t+vmd2Gc3dvboWqKKK8Q6wrK1PxFp2kXdrbXcjh7hsZVCyxLtZt8h H3F+RuT/AHWPRWI1a4TxvBcw6/o1/pQu01bzNkREZkguMRzERuoOAckruO3CyscnaSrirsDqbjXt MtdSisJ7nZPLIIlJjbZ5hG4IXxtDkchScnI45GYbHxTo2o3kdra3m+SXzPJYxOqTbDh/LcgLJj/Z J9elcPZ6frOn+IZltINSiu5vEzzy7fM+zPYuuWYn/VE4/wCB5AHUCpvDfh69i1vQEhW4TT9Ea9yl 7aNDKnmkhV3hmSYkkncmAAOeSBVcqA9KoooqACiiigAooooAKKKKACs7Xbyaw0W5uYCBKgAUkZxl gM/rWjWN4q/5Fq7/AOAf+hrWlJJ1Ip90C3OZs9X8S38M80F0nlQbfNeTyY1XdwMlsdcVM954tjYK 7MpNyLTDJEP3pGQOncEHPT3qhomrW1hp2pWs+8NdeVsdYEmVdpJOVcgHrWo/ijT7m5dpYrqKNdSS +jK4lZgqhdpyw29M8EgZx0Fe17Gn/KvuNbIYLnxebiCDf+9uHkSJcRfMYyQ49sYPXr2qkniDxDLa zXKXDNDCVEjiJPl3Zxnj2PP+IoXxFmw12H9/G+oyiSJUbKpliXBOR1XA4HOOap6ZrEml2s6Q8ySy xsysuY5ECuGRx3B3Dj+RApexp/yr7gsjVTUPFLxGX7QkcQ2fvJTDGpLLvUAtgE7SDgcjvTnvPFsb BXZlJuRaYZIh+9IyB07gg56e9RXut6ZqOnyWJiubSHzopo9iiXG2ERlDll6Y4OefQVM3iyFtU1i5 8h1jvERoOAWSWPHlsecYyMkc9hyOp7Gn/KvuCyIJ9W8TW1vLPNPtiiuDbO2yM4kAyV4H69K6Xwvq NzqelNLdMHkSUpuC4yMA84471x+u60mqwWEUaMogjZpWYYLzOd0h4OME8jp1PtXS+CP+QLN/18N/ 6Ctc2LpwjTukkTJaHXXP+ot/93+gqtVm5/1Fv/u/0FVq4cR/E+78iXuFFFFYiCiiigAooooAKKKK AJIX8uUN2715v4/8PGxv/wC07dc21wctj+F//r16JRJHBd2klndoHgkGDntWnLGrB0pfJ+Z2YHFv DVebp1PB6Bwc10vibwjdaFMZog01ixysoGdvsa5qvIqU5U5cs1Zn2VKrCrFTg7o9h0rU9O8U6Ot/ c2DmTS/nA/2wM/Ljr0FQpPp3jfw9fXdzYC3mtwyiVjypAJBDenPSuF8L+K7jw1NKFiE9tNjfGTjB HcH1qzr/AI4vdYtTZwQpZ2jf6xI+rnvk+lessdTdK83d21Vt+2p5DwFRVWqasr6O+y6qxasPiRqN rYpb3FtDdPHjbJISDx0z6n3rmNV1a81q+a8vZd8pGAAMBR6AelUqK8ypiKtSKjOV0j1KeGo05OcI 2bCrml6dPquoRWduuXkOM9gO5NN0/TbvVLtbazhaSRvQcD3NejWdvZ+DLQ28BS61ucAMBz5efX0H 861wuFdaV3pFbswxuNhhof3uiLd/DbwW9j4esn3CBg8+0+g4B+pOfwFbqoI4IVHZP6msbQ9MNpCZ ZSXmkO53bkknqTW4/wByP/d/qa9OpNSbtskfGzk5tyZV07/kCWP/AFzX/wBBWkvLb7TAUBKsOVYd QfWl07/kCWP/AFzX/wBBWp6wTtb0X5EnO6gdP1TbDrge0vYxtW8jX5XHv/8AXrP/AOEa0RPmk8UW zJ/dQLu/9CP8q66W3inXEiKw9xVVdIsFbcLdAfpVTjQqvmqwu/n+hEqdOTvJFC2MD2v9m6NA8dkx zPcyD5pfb6VtogjRUXoBihEWNdqKAPanUTnzWS0S6F+SCiiioAKKKKACiiigAooooAKKKKAI5oI7 iMpKgZT6iuL1/wABW19ulthsf/Z4ruKK1pVp0pc0HZiaUlZnhs/gfV45iiLuXPU5rpNB+HbblmvW J9j/AIV6btB7Clruq5viqkORy+4xjhqUXdIp2OmW2nxBIYwMd8VcoorzW7m4UUUUgCiiigAooooA KKKKACiiigAooooAKKKKACmuiyIyOoZGGGVhkEehp1FAFP8AsjTf+gdaf9+V/wAKP7I03/oHWn/f lf8ACrlFVzy7hcp/2Rpv/QOtP+/K/wCFH9kab/0DrT/vyv8AhVyijnl3C5T/ALI03/oHWn/flf8A Cj+yNN/6B1p/35X/AAq5RRzy7hcp/wBkab/0DrT/AL8r/hVmKGKCIRQxpHGvRUUAD8BT6KTk3uwG ay7pBZ7WZcqc4OOwrgIPGd6uiQapqVrFaQXdqbm1ZLx5VJERl2SYjBU7FY5VXHyt32hu91v/AFFn /un+QrztfB9zP4dTR7/U4Zo7aya1tGhtTHsJhaHzHBdt5CsQACo+ZsgnaVzxLh7eXO+3fsKW5unx PYrcywPfvH5e/dNIrpCSgJcCUjYSoVsgEkbWz904hbxjpscatNe3MLNIIlint5o5GYqzKBGyhju2 MF4+YqVGTxVG58LNeXmoNPeottfQyQzeRbiOeRXXaBI+SrhAflOwMMAbiC++0uk6hPd2VzqGpQzP aXHnKkFr5SY8qSPGC7Nk+bkncRhQAByTzfu7bv8Ar5E6Fo+J7FbmWB794/L37ppFdISUBLgSkbCV CtkAkja2funFKTxpbC/060i+3NJeXHkMsltPG0Q2OwcqyZwSmATgcOc4RsZ7+BbOW5vi/wBkWG6+ 0FpY7JBd5mDhwZznIHmNgBQcBQSQCGfZ+EWsri1uYZNLtpYLpZ2Wy0wQRugjkQggOW3ESt8xYgYG F67q/c2+Jhoamo6/f2+rQ6bZx273EsfmL9svWtxL1ysWEcuVCksMDaGU854jtPF8M2o3NhctNa3M M0cWx2L7S8UbrvZcqhLOUGWwzKQpJ4p+s6Xd6khhjuLFrWRQsttf2P2mNiDkEAOnOeuSw+VcAc5r ReGPKsp7b7fNL5l7a3XmzDe58gQDDHPzFvIyW45bpxzMZU+XV/mGhNp/jPT74W6Lf/v5FiLrGJGS NpEV0BcqMBg4Clgu48AbgQCLxnp93bxTWV/5qytCI2cSIsiySImUO07iC4BA+6xCsVzkY2jeEb2y WSymvv8AQI7i0cL5S5m+zw24V1IbKZeIhg27IUY2/eJpXhG9bR9GTUr7E1hb2yRx+UuY9skMsiMw bD8wKqkAYGc7zzVtUU/i7f1sGhu23jHTbu2NxHe3KxmMSoZbeaMzKSADGGUGTJZR8meXUdWGbmna 5b6tHM9ldvKIZPKlBDKUfaGKkHBBAYZHUHIOCCBzl74Ykg0fSkhkmuZtKskt4kijQGV1kgdXw7qM AwAldwJBIDA4rQ8M2d/bxahc6jvE97deftkCBlHlRpghCygZQ4AZjt25JbNRJQ5XKMvxDQ6a31B4 EaKZPtFu3VGOcfTP8qxNQ8IaFq0hfTrsWVwx/wBTJwpJ7AH+ma0ajlgjlXDqDVQxT5eSquZfj95v h8XVoO9N2OPvfAWvWjfLbC4X+9E2f061mN4b1tWwdIvj9Ldj/Su9EN3Au20vriFR0VZDtH4dKa11 4iUYTVnx7xRn+a1XLhJa3a+5nrQz2ql70UzjLfwfr9ywC6bMme8q7P51tw+BbfTkWfxBqtvax4JE auNzY6gev4ZrQkXXrjiXWboD/pmwT/0ECq8PhyASmWYmWRjlnc7iT7k1S+qQ1s5epnVzuvNWjZFo a9ZWVq1h4VsWG4YN5Iu38QCMk/XH41HpelNakzzSyPO53O7MSSfUmtCG1igUBFAqas62LnUXKtF2 R5FSrKbvJ6jxNKBgSv8A99GtpCTbW5JyTGOfxNYVbqf8ett/1yH8zTwrb5r9v1FEq2EMb6LYlkU/ uweR/sr/AIVMIIR/yyT/AL5FM07/AJAlj/1zX/0FasKpeRY16scV0qClZJa2X5FWGpbq5wsKk+y1 IbBgM+Qv5CuV8Q+KJxenTNKlEEaNsknB5Zu/PYD1qG5stdtbSW7t/ELXbW+DMkVyzbPwPBqXUopu MU5cu9rf0zF1optJXsdWYEU4MSg+hWk8qP8A55p/3yKy/DXiBtbjayvABexruSQDHmD/ABrWByM1 VoSipw1TNIuMlzR2G+VH/wA80/75FHlR/wDPNP8AvkU+ilZDsM8qP/nmn/fIo8qP/nmn/fIp9FFk FhnlR/8APNP++RR5Uf8AzzT/AL5FPoosgsM8qP8A55p/3yKPKj/55p/3yKfRRZBYZ5Uf/PNP++RR 5UX/ADzT/vmn03vRyoLCeXF/zzT/AL5pDHFjlE/Kh3WNGdzhVGSa5u61uK6lMcdwijOAu4AmqjBM 1p0XN6G+0tmpwzRA/hT0+zyD5BG30Arjm8za3+ubMhxsByfk4AA7ZxVgXCxS7VlVZBwQG5z6Vp7K LOh4VdGdZ5cX/PNP++aPLi/55p/3zWZpup+fJ9nlI8zGVP8AeFalZOCRySg4uzE8qP8A55p/3zR5 Uf8AzzT/AL5FOHSlpcqJsM8qP/nmn/fIo8qP/nmn/fIp9FFkFhnlR/8APNP++RR5Uf8AzzT/AL5F PoosgsM8qP8A55p/3yKPKj/55p/3yKfRRZBYZ5Uf/PNP++RR5Uf/ADzT/vkU+iiyCwzyo/8Anmn/ AHyKPKj/AOeaf98in0UWQWGeVH/zzT/vkUeVH/zzT/vkU+iiyCwzyo/+eaf98ijyo/8Anmn/AHyK fTXdY0Z3YKijLMxwAPU0cq7BYTyo/wDnmn/fIo8qP/nmn/fIqt/a+m/9BG0/7/L/AI0f2vpv/QRt P+/y/wCNV7N9h2LPlR/880/75FHlR/8APNP++RVb+19N/wCgjaf9/l/xo/tfTf8AoI2n/f5f8aPZ vsFiz5Uf/PNP++RR5Uf/ADzT/vkVW/tfTf8AoI2n/f5f8aP7X03/AKCNp/3+X/Gj2b7BYs+VH/zz T/vkUhgiPWNPyqv/AGvpv/QRtP8Av8v+NWYpop4hLDIkkbdGRgQfxFJ07boVhNYby7ezChcbTwVB 7Cuai8QWU2oGySTMu5kDG2Ijd1zuRZCuxmGGyoJI2tkfKcdJrf8AqLP/AHT/ACFefRWmsweGj4ct bV4pYLBrWLUzOqRkiMrG67SZA2dpIKgL82GbA3Z4tJ1pXfb8kKW51vnN6J/3wv8AhR5zeif98L/h XBL4aN5qlq6aH/Z2kC4jaWw3RoMrDcq8hWJipDeZChGSWCkMNo5yR4dudLTw7aSaSjQMtoJrOOVY 1muFtrvz84OGYrsB3fK+ArNtyRiqSf2/6+8VvM9MXUI3vZbNWQ3EUaSunlDhXLBTnGOSjfl9KF1C N72WzVkNxFGkrp5Q4VywU5xjko35fSvPZ/C2qyq3mW032M+UWtYWgdjEJLtkgCS5iPliaDg/KNny klVoTwjeRJepBp80b3Nlbr9oLW7SlUuXeSA4AXLRGNAm0xYUISVUEv2UP5wt5npPnN6J/wB8L/hW fY+ILLUZ2htZNzbd6F7YosqZA3xsygSLyPmUkfMvPIzhaZ4dc+EdT0hhcWkd6ssca3HkloVeMJ9y ELGozltqk5zknLECHxFY6t4j0ma2/sx7WW2huGXfNGy3Er28sSrGQfu5kJ3OEPC/LydsKMb2cv6/ UDrLzUI7CynvLlkS3t42llfygdqqMk4AyeB2qfzm9E/74X/CuC8TeGZ5ra+trDSvtay6cYLNvtAQ 202ZTI5djuzJvQEjPmFSJCAc1Tv/AApqU0utOkF3JeXEd6Fn32yRTJIkgij3bfOfAaMbXIQFMg4R QajTi1fn/r7wt5noV3qC2Vs9xKjMiYyIbYytyccKilj17CodL1q31myW8stzW742PJatFvBAIIDq CQQRgjg0+0tILG2S3t02RpnAySSSckknkkkkknJJJJyTXM6X4fnH/CK/brXjTdKaKVTICEnH2faC AcNgxsR1AKg9QprOPK07v+ten/BEdh5zeif98L/hUDahGl7FZsyC4ljeVE8ocqhUMc4xwXX8/rXn Vv4X1qG5kYWbrFJCPt0fmQhbuRZ4XdRgBpFdBMqtMzMdzB9u4lr9zoN3LcWk1lon2KxijnEmnGZM So0luWjKK21d4jlIVW2Egbzh3U6eyin8f9feO3mdzFd+chZVwAzL88O05BIPBA4yOD0IwRkEVJ5z eif98L/hXnjeE7uRNfuJNNhe+a3n/syZtheOY3N3IpRs5Q4khbORgkdwcMtPIl8a2UMK2899b6nd S3lzDdK7tGyTiMOiktiMMkeZAuw4VchjR7JO/LK9v67hY9G85vRP++F/wo85vRP++F/wqOiubmfc kk85vRP++F/wo85vRP8Avhf8Kjoo5n3Ak85vRP8Avhf8K2UOba3PrGP5msKt1P8Aj1tv+uQ/ma6s K2+a/b9S4kGnf8gSx/65r/6CtWbVgNTjUnqjY+vH9M1W07/kCWP/AFzX/wBBWo73zYvLuYADLC24 A9x3Fd1GSjOLfl+Ra3PNVDCeQSZ8wMd2fXPNdbpLQXHh3UbWzQw3nk75pG5EiAngc8en+eE1HRTq F0Nb0LZI+8PLbNjcjj2P8qbcXfiS8hmtIdCW1acbZpIrcoX9fmPFeXDCTw9WTkm73Ssr3uuj6M89 UnTk7/kZ3g8E+LrTbnAEm7/vhq7mNg7SkdPNfH0yawNM05fDMTGRkl1i4XakaHIiU9zW7bReTboh 5IHJrtw9GVDDqnPdu/odVCDhTszyfxXqN34L17xXbWMUzf8ACQWMdxp6QMYtt2WEDiIAHfKd6ykr hvlGf71Qa9rWqeCNKn03w7eeYnhq1tBeAQRQ2+52QAMhVpJHkJkdiroFBHJbO71m70vT7+e2nvLG 1uJrVt9vJNCrtE2QcoSMqcgcj0FQah4e0TVp1n1LR9PvZlXYslzbJIwXJOMsCcZJ4966o1o6cy/r /hja54h/a95pGu6lLZGFJRrHiKZZHt45HR47ZGUqzKSvPXGM9DkVpa98RPEFtp4ey1dPOTwtZ302 2KJil1JPEGYjacEpJ93phgQOhr2GPRdKhu1uotMskuVlkmWZbdQ4kkADuDjO5gACepxzUH/CL+H/ ACfJ/sLTPK8rydn2SPb5e/fsxj7u/wCbHTPPWq9vBtNxC6PM9d8V+K9Fn8ZyDW0mTQm0+SOJrOML IZiu9OORH8zDGS/C/Pw272GqM+i6Vdfa/tGmWU32zZ9q8y3VvP2fc35Hzbe2enar1YzmpJWX9WQm FFFFZgFN706m96AMbxJcGDTtoOPMbH4Vyel6Xp97qTx3CgNN8yH37j+v510vi2Jm0rzFGfLbcfpX BrelZAUfa6kEH0I5z/KrTaO+jTU6NkbuuC50ZlghDSNIdkZPOPfP0qe38PWlnpYu9QJMh5xnkmr8 PiTSLu1ha+fbMo5G0nmue8QeI4r26Cxttt04RfXtnFVzW2FGFSo1GaskW31FYbm2mQ4InUAD0PBH 613sbb41b1Ga8ijla81aztI8k+YJHx2A6fr/ACr1yFdsKA9hUva7M8WkppIkHSlpB0pag5QrkPH2 qXulWthKk13a6ebiP7VeWqhmhxLHjdkH5CvmdFOWCA8EhuvrK1zRm1m3hRL+4s3imjkDxYYELIr4 KsCpOUGDjIPqCys1uB5r4r8eazpF1rsya1bwnT4dPl0y3WKMRamshBlcBtzuvUfu3GAOuQTU03jj WbfxOIZtUSO4PildLGkPHGAbJlAWbBHm5OQwfdtJI4xxXbTeDNOmdYpLi9fTPLhjfSpJRJauIf8A V/K4LLjC5CsA20bg2Tmb/hFrR9V+23V3e3kSXX2yCzupBLDbz7dodMjeMZbC7iqliQoIGOhVKdtv 60HdG7RRRXMIKKKKACiiigAooooAKxvFX/ItXf8AwD/0Na2aztds5r/Rbm2gAMrgFQTjOGBx+laU mlUi33QLc4jRNJtr/TtSup95a18rYizpCrbiQcs4IHStK58LWUEqoJ7lgdWSyywC/u2UNnBHXnGe h645qtZ6R4lsIZ4YLVPKn2+aknkyK23kZDZ6Zqwlt4vSaSUpveSUTHzTE4DjgMobIUgccY4A9BXt e2p/zL7zW6Gf2DpAN3K9zcrBp00sd4uRvI3FYvL+XByRg5x36CsvStITVLO6K3Cx3SSRpAjnCysw c7M9idvGeM8d+Lq6N4lWC7h8lil2VafdJGS5ByCSTnqc1EPDevLbvALT907q7L5kfJUEA9f9o/nR 7an/ADL7wuia50Oz03S2vbtLp2EsUPkq4jZGaESMSSp7nGMDGOpq5J4Ts0u723Wec/YrqHznYgAW 8gBJ6H5l5JJwMDNRfYvFjCQSRLMJCrMJ/JlBZV2hsNnnHGep71H/AGZ4p+1XVyY2M13G0UztJGdy tjI5PHQdOmOKXtqf8y+8Lora1ottpenxzK8rPcXMotzkFTApwGPA5OQQRwQc10Pgj/kCzf8AXw3/ AKCtYV1oXiK98n7Rbb/IiWGP54xtReg4PvXUeF9OudM0porpQkjyl9obOBgDnHHaubF1ISp2TTJk 9DX1lgsFnlFb5T1z6D0rmYvEOiz6gdPhv9OkvQzIbdLkGQMudw2hs5GDn0wa6TW/9RZ/7p/kK8li tbuZjZLc6yJRrbXH2N7HbbeWL0ylvNMQ42DeP3nJwBnIWvIxMFKvK/l+X9f5mctz0bzF/wCeKfm3 +NRm6gWdYCsIldS6xljuZQQCQM9AWXP1HrXnulQ66LO6N5faoZ2tcXix2cw8ubcuSpeX5wB5nFsF yudpDeVVnRrST/hJNIu5k1ZlFvdwpJMbjy85hIJV/mQNiQ4lydwwCwWM1zuklfX8PImx2H9t6V/a f9m/a7H7f/z6+ePN6bvubs9OenTmrJuoFnWArCJXUusZY7mUEAkDPQFlz9R61y0WkX17resCaZId ObU4LkRm3bzJWjit2UrIWxt3xgH5T91hkHpkxW+uW+j6GTNq0skunCTUS7OXBMlp5i4HIcRCYKFG /IYjLkkipxdrP+rXCx35uoFnWArCJXUusZY7mUEAkDPQFlz9R61J5i/88U/Nv8a8/vor2d7KHTTr 40522sZnmRwpubQN8xIlA2+fy53Ab8fJip5YtRttRmtXOsnTIJpFtGt3d5TKYrdovnYksu5rjmQm MHhuAoB7K63Cx3PmL/zxT82/xo8xf+eKfm3+NYvhaaW48I6LPPI8sslhA7yOxZmYxqSST1JNa1YS vFtCJPMX/nin5t/jR5i/88U/Nv8AGo6KXMxEnmL/AM8U/Nv8aPMX/nin5t/jUdFHMwJPMX/nin5t /jR5i/8APFPzb/Go6KOZgSeYv/PFPzb/ABo8xf8Anin5t/jUdFHMwJPMX/nin5t/jR5i/wDPFPzb /Go6KOZgSeYv/PFPzb/GtlOba3OMfuxx+JrCrdT/AI9bb/rkP5murCu/N6fqXEg07/kCWP8A1zX/ ANBWpyMjBqDTv+QJY/8AXNf/AEFanrp6L0X5FGXc6Orz/aLWaS2n/vxMVJ+tR/ZNccbJNZm2f7IU H8wM1sUVpGrOKsmFyjY6XDZZYZeQ/edjkn8avUUVDberAKKKKQBRRRQAUUUUAFFFFABTe9OpMUAQ 3MC3Nu8TjIYYrybxDodxpM8g8tzbOc70GfoD7V6/iop7WK5QpKgYe9Un3NaVaVJ3R4Qb6Ik7riMD cSfn5xio0uDcsiWsJupckhgMIDx1P4dq9fn8GaVPJvaFc/SrVn4bsLNgyRAkdzVLlOp47TRHNeC/ DD2jG+u8tM/JJGOfb0Fd3QECgAAAClxUylc4ZScndgOlLQKKkQUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADNZKCCz3Kx+U4wcdh7VzK67pDwWEwnxHfqr2xZsb1YDB wV4BLKOcfM6r1YA9Jrf+os/90/yFedxeFp5m1JZ5vLKSSnTptoPltJN9pMu0HnEnlrtbr5GejkVn iuV15cz7fkiZbnUwXlncS3MUW9ntpBFKN2NrFFfHTn5XU8etE95Z28ttFLvV7mQxRDdncwRnx04+ VGPPpXBzeHNRe0lMumefd3lu72r74z/ZV1JLNKzbiwI2mWMb4wWPk5wMKKmufC+oNpx+xR/Z9Rl1 G/ma4M2DGrpdrCwYElQDKhwvQuxxktWPs4fzfkKyOwudX0yz+2ee7p9itxdXHU7Ijvw3C8/6t+Bk 8e4p76lp0eoR2DyYupF3JGX5I59upCsQOpCORna2Of8ADmlyWetaldJpH9l2U9vbpBb+Yh2lGmLf IhKx/fBwpIO7d94sBTsfDV7YaKs4XzdVsPKSzXKrvit1aNU67R5qtMcnJTz++wVPLC7V+3br/kGh 1llqNjqCTPbCZlhmeBywKDeh2sBuUbgCCMjIyDzxVaS00DxJZWl5cadb39u8Ylt3uIlfCuAcgMuR kYrj7Xwpe6c6wSWX9pWkOIoV81YsyC2tY0uOuY9phlG5cyLu+UHNQ6R4U1K3u9LkvILv7RBHZhJY 3tglukcUayRmQqZhllkysfyMHwSNzkackFrGf5BY7m+1vTdPnWCZLySUrvMdtBJOyqSQCwjRtoJB xnGcHGcGprPUtO1EStZyeesTKrMj5XLIrjBxggq6nIyOaxtct7j7alxa2GotN5YVbvTbiJXGCcrI krBHGD8uQ+Cz4CnBOYnh/UGlutRubWE6u+o2cqzQyfKsYS3WcxbjlAQsqnozKADkYrOMYON27fcB 2UM0E8EcyRzBXUMA+UYAjPKlQQfYjIolmghQM0cxBZV+TLHJIA4CnjJ5PQDJOADXmnhzQ72Nzbtp 229tbiwQ3nnqfsvl21qZkxn5d6gplM784bCgGjQNDvbjQtCmtdO+zqtvZPcSeerfa8T28ivkncfL jjkGGA27tqbhVujFP4u3bqFj0/MX9x/++x/hRmL+4/8A32P8K82k8PnQ/D2lv9ltLCGPTo11YeZH Es8iy2xMchyFcsonQFjtO8gkBjnc8EeU1tq09tAkNnPf77ZY5hKnl+REuFYZXAKlcKSqlSoJCiol TSi5J3+SCx1uYv7j/wDfY/wozF/cf/vsf4VHRWHMySTMX9x/++x/hRmL+4//AH2P8Kjoo5mBJmL+ 4/8A32P8KMxf3H/77H+FR0UczAkzF/cf/vsf4Vspj7Nb46eWP5msKt1P+PW2/wCuQ/ma6sK783p+ pcTnrLxVaW1jBbtFMTHGqn5FIyAAcZPtU/8AwmFl/wA8Zv8Av0n+NFFcyxlZKyY7sP8AhMLL/njN /wB+k/xo/wCEwsv+eM3/AH6T/Giin9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKP rtbuF2H/AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3 /fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hM LL/njN/36T/Giij67W7hdh/wmFl/zxm/79J/jR/wmFl/zxm/79J/jRRR9drdwuw/4TCy/wCeM3/f pP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF2H/CYWX/ADxm/wC/Sf40f8JhZf8APGb/AL9J/jRRR9dr dwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKPrtbuF2H/AAmFl/zxm/79J/jR/wAJhZf8 8Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3/fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH /CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hMLL/njN/36T/Giij67W7hdh/wmFl/zxm/ 79J/jR/wmFl/zxm/79J/jRRR9drdwuw/4TCy/wCeM3/fpP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF 2H/CYWX/ADxm/wC/Sf40f8JhZf8APGb/AL9J/jRRR9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54 zf8AfpP8aKKPrtbuF2H/AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP 8aP+Ewsv+eM3/fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/n jN/36T/Gj/hMLL/njN/36T/Giij67W7hdinxnaMADFOQOmY04/Wk/wCEwsv+eM3/AH6T/Giin9er PqF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFL67W7hdh/wmFl/zxm/79J/jR/wmFl/zxm/79J/ jRRR9drdwuw/4TCy/wCeM3/fpP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF2H/CYWX/ADxm/wC/Sf40 f8JhZf8APGb/AL9J/jRRR9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKPrtbuF2H/ AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3/fpP8aKK PrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hMLL/njN/3 6T/Giij67W7hdh/wmFl/zxm/79J/jTW8XWT4zFccDAwij+tFFDxlZ7sLs//Z --------------ms020700070106060404020304-- From necojp@citiz.net Sun Feb 05 18:08:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5szo-0007Y0-Hy for dnsext-archive@megatron.ietf.org; Sun, 05 Feb 2006 18:08:40 -0500 Received: from a-net.ne.jp ([221.207.130.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21995 for ; Sun, 5 Feb 2006 18:06:58 -0500 (EST) Date: Sun, 5 Feb 2006 18:06:58 -0500 (EST) Message-Id: <200602052306.SAA21995@ietf.org> Received: from frnby7 (unknown [127.122.32.198]) by smtp87 (Coremail) with SMTP id RuI8psxfiUQR5nzl.1 for ; Wed, 12 Mar 2003 20:00:53 +0800 (CST) X-Originating-IP: [127.122.32.198] Subject: =?iso-2022-jp?B?GyRCS1xGfCReJEckRyQ5JCwhIiQkJCskLCQkJD8kNyReJDckZyQmGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: base64 GyRCIihNLTh6NHw4QkZ8JEckOSIoGyhCDQobJEIkKk1CJCskaiROGyhCMjAbJEJLfDFfJE48dTxo NHw4QkZ8JCxLXEZ8JEgkSiRDJEYkKiRqJF4kOSEjQmc7ajVeJDMkQSRpJGgkaiQqPHUkMTxoJGoy PCQ1JCQhIxsoQg0KDQpodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjcNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQobJEIlYSE8JWtJVE1XJEpKfSRPJDMk QSRpIi0bKEINCmNvbmNlcHQyX25ldEB5YWhvby5jYQ0KDQoNCg== From owner-namedroppers@ops.ietf.org Sun Feb 05 22:17:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5wt1-00023r-Uy for dnsext-archive@megatron.ietf.org; Sun, 05 Feb 2006 22:17:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07844 for ; Sun, 5 Feb 2006 22:16:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5wo3-000Hn0-5X for namedroppers-data@psg.com; Mon, 06 Feb 2006 03:12:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5wo1-000Hmi-Ev for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 03:12:46 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k163BRV4001385; Mon, 6 Feb 2006 04:12:41 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20060204013717.6BD8111427@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--241922200" Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: the RD bit is troubling me today Date: Sun, 5 Feb 2006 09:02:31 +0100 To: Paul Vixie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--241922200 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Feb 4, 2006, at 2:37 AM, Paul Vixie wrote: > 1034/1035 does not anywhere say this, but it's the implication of > the other > "intent of the framers" clarifications we've made to 1034/1035 > during the > DNSSEC development era. But if we were going to write another > clarification > document on this point, I read your mail as a request for such clarification document. > I'd rather we just said "nameservers that offer both > authority and recursive service are undefined, please just don't do > it" than > to try to describe how many RD bits should be dancing on the head > of this pin. I guess that once others agree you have to add boilerplate text to your mail and submit as an I-D. Do others think this clarification is needed and useful and that the proposed "solution" is appropriate? Without my hats I'd answer yes to both questions. Documentation and education on the cornercases will help developers and operators. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-4--241922200 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFD5bEXtN/ca3YJIocRAlxgAJ9dvpzOOZEmvCkEmzNc5wFO43wjgACfT2kU /d/GUYNIKTG6rklwGLM6oHg= =OSpB -----END PGP SIGNATURE----- --Apple-Mail-4--241922200-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From necojp@citiz.net Mon Feb 06 03:16:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F61Xa-0006bO-PO for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 03:16:06 -0500 Received: from ocn.ne.jp ([221.212.56.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27134 for ; Mon, 6 Feb 2006 03:14:16 -0500 (EST) Date: Mon, 6 Feb 2006 03:14:16 -0500 (EST) Message-Id: <200602060814.DAA27134@ietf.org> Received: from seym1 (unknown [108.39.73.29]) by smtp78 (Coremail) with SMTP id MaSTqN8ihSW9iEry.1 for ; Mon, 03 Mar 2003 01:04:37 +0800 (CST) X-Originating-IP: [108.39.73.29] Subject: =?iso-2022-jp?B?GyRCS1xGfCReJEckRyQ5JCwhIiQkJCskLCQkJD8kNyReJDckZyQmGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: base64 GyRCIihNLTh6NHw4QkZ8JEckOSIoGyhCDQobJEIkKk1CJCskaiROGyhCMjAbJEJLfDFfJE48dTxo NHw4QkZ8JCxLXEZ8JEgkSiRDJEYkKiRqJF4kOSEjQmc7ajVeJDMkQSRpJGgkaiQqPHUkMTxoJGoy PCQ1JCQhIxsoQg0KDQpodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjENCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNChskQiVhITwla0lUTVckSkp9JE8k MyRBJGkiLRsoQg0KY29uY2VwdDJfbmV0QHlhaG9vLmNhDQoNCg0K From cacrowell1@austrelo.com Mon Feb 06 05:29:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F63cw-0004Ij-ML for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 05:29:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04951 for ; Mon, 6 Feb 2006 05:27:54 -0500 (EST) Received: from aan5.internetdsl.tpnet.pl ([83.16.13.5] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F63or-0004G7-Q6 for dnsext-archive@ietf.org; Mon, 06 Feb 2006 05:42:09 -0500 Message-ID: <000001c62b32$37226d00$0100007f@localhost> From: "Brian Turner" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Mon, 06 Feb 2006 11:36:17 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62B32.37226D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62B32.37226D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62B32.37226D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 32 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 47 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 42 reviews)

------=_NextPart_000_0001_01C62B32.37226D00-- From owner-namedroppers@ops.ietf.org Mon Feb 06 05:40:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F63n8-0008C7-Hj for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 05:40:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05866 for ; Mon, 6 Feb 2006 05:38:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F63jT-000Jts-32 for namedroppers-data@psg.com; Mon, 06 Feb 2006 10:36:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F63jS-000Jtg-6V for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 10:36:30 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k16AaPKe036992; Mon, 6 Feb 2006 11:36:25 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200602061036.k16AaPKe036992@bartok.nlnetlabs.nl> To: "Olaf M. Kolkman" cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: the RD bit is troubling me today In-reply-to: Your message of Sun, 05 Feb 2006 09:02:31 +0100. Date: Mon, 06 Feb 2006 11:36:25 +0100 From: Jaap Akkerhuis Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I read your mail as a request for such clarification document. > I'd rather we just said "nameservers that offer both > authority and recursive service are undefined, please just don't do > it" than > to try to describe how many RD bits should be dancing on the head > of this pin. I guess that once others agree you have to add boilerplate text to your mail and submit as an I-D. Do others think this clarification is needed and useful and that the proposed "solution" is appropriate? Without my hats I'd answer yes to both questions. Documentation and education on the cornercases will help developers and operators. Me Too jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 06 08:18:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66Fy-0004SP-0v for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 08:18:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17365 for ; Mon, 6 Feb 2006 08:16:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F66BH-000570-1F for namedroppers-data@psg.com; Mon, 06 Feb 2006 13:13:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F66BE-00056d-V8 for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 13:13:21 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k16DDEs3032621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2006 14:13:14 +0100 From: Simon Josefsson To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: the RD bit is troubling me today References: <20060204013717.6BD8111427@sa.vix.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060206:paul@vix.com::tF4fDIjrjhDt6MTc:F4k X-Hashcash: 1:21:060206:namedroppers@ops.ietf.org::lYGx/9+r+1b0t4zG:10/4 Date: Mon, 06 Feb 2006 14:13:12 +0100 In-Reply-To: <20060204013717.6BD8111427@sa.vix.com> (Paul Vixie's message of "Sat, 04 Feb 2006 01:37:17 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > We've spent about half of the total DNSSEC development era to date (that is > around six years out of the twelve) going down ratholes due to > misunderstanding 1034/1035. Sometimes we amend 1034/1035 to explain something > that didn't used to need to be explained; sometimes we amend 1034/1035 to > explain something that we thought had been explained that turned out to have > ambiguities... The result of DNSSEC is that we now understand far more about > the delegation model and wildcards (among other things) than we used to know. > Sort of like one of the great side-benefits of NASA's moon programme was the > ballpoint pen. > > There's been some interest recently in the question "should a nameserver also > be recursive, if it's authoritative for any zones?" The old, sad, answer has > been "don't do it, since BIND4 was terrible about mixing recursive and > authority data, and dual-purpose nameservers are a recipe for cache pollution" > but it turns out that since BIND8, BIND9, and all modern non-BIND servers can > safely mix authority and recursive data, folks are starting to do this again. > It's not that hard to run two nameservers on a host, and just use different > IP addresses for your resolv.conf file vs. your NS RR -> A/AAAA RR chain, but > even though it's not hard, it's not as easy as just using one nameserver. > > While the RD bit in a query can disambiguate the case of a name-below-zonecut > such that if RD=0 a dual-use server will return a delegation whereas if RD=1 > it will go fetch the data, I don't think this helps when the qname is equal to > a zonecut name. An authority server should respond with a non-AA delegation > in that case, since the zone ends above the zonecut. A recursive server > should respond with a non-AA answer in that case. But the non-AA answer > should be first retrieved from the apex of the subzone, by following the > delegation, all without allowing an RD=1 query to affect subsequent RD=0 > results. A dual-use server would therefore have to maintain separate NS > RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers. > > 1034/1035 does not anywhere say this, but it's the implication of the other > "intent of the framers" clarifications we've made to 1034/1035 during the > DNSSEC development era. But if we were going to write another clarification > document on this point, I'd rather we just said "nameservers that offer both > authority and recursive service are undefined, please just don't do it" than > to try to describe how many RD bits should be dancing on the head of this pin. This discussion is missing a crucial part: What happens when a dual-server does not maintain a separate NS RRset for RD=0 and RD=1? In other words, I'm looking for the failure mode caused by this problem. There are two cases two consider. The first case is when the dual-use server always send the RD=0 answer, and the second case where it always send the RD=1 answer. Forbidding dual-use servers seem like a slightly unrealistic solution to me, given deployed use. Without understanding what the actual interoperability problems are (in contrast to implementation problems), it seems that there is no justification for that solution. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From simon@yahoo.com Mon Feb 06 09:02:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66xC-0006tw-06 for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 09:02:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20734 for ; Mon, 6 Feb 2006 09:01:05 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F679G-0007eG-B5 for dnsext-archive@ietf.org; Mon, 06 Feb 2006 09:15:22 -0500 Received: from adijon-152-1-36-73.w83-194.abo.wanadoo.fr ([83.194.54.73] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1F66x0-0002bl-PA for dnsext-archive@ietf.org; Mon, 06 Feb 2006 09:02:43 -0500 Date: lun., 06 févr. 2006 15:02:25 +0100 From: "Fink" To: Subject: All love enhancers on one portal! Message-ID: <000001c62a4e$7b3c4180$0100007f@neska> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="------------ms020700070106060404020304" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 This is a multi-part message in MIME format. --------------ms020700070106060404020304 Content-Type: multipart/alternative; boundary="------------ms020507090000070002040500" --------------ms020507090000070002040500 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable --------------ms020507090000070002040500 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""
 
--------------ms020507090000070002040500-- --------------ms020700070106060404020304 Content-Type: image/jpeg; name="image.jpg" Content-ID: <000701c62a48$e2358cd0$aa0fa8c0@sanya> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCACnAhwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDYooor 4MwGO/l4JHy9z6UI+/IIww6j0ofecKnGeren4U2KLGGYYx91c/d9ee9apQ5Lvf8Ar+v61CWmSsVh dgcEKSKfTJVLQuoGSVIFZLcDj4vEV2/h/SJRfRm9mvBHOAE3FCzDlcccBecVqjxXZmRR9lvBE1x9 mExRdm/0+9n9KyovDt2nh/SIhYxi9hvBJOQU3BAzHls88FeM0xdH1byYbM2BCJqf2ozeam3Zz2zn 9K9SUMPJvbd9Uuv9WNbRZq6TrF3deItTtJYpzBGyCPKKBEMHO45zzjjr+FF5qd5F4gvrVJsQxaa0 6LtHDg9c4z+HSpNPtL208TanM1qTa3ZjKzCRcLtU9RnPU+lVdVsdRGvXN3bWRuIp7A2wKyIu1ie+ 4isUqbqdLcq7b6fiTpcgi1+7iOhy3E5MM1tNNcgIuX2IW9OOnbFX08W2ZCtJa3kSvC06M6Lh1UZO MMaxRour3ENjC9gYfstnPCXaZCGZ4yoxg+pFPtvDt3JprrPa3SXcVo0URluUZCSMYUDoPrW06eHe ra+TXd/8D5FNRL974rVrCb7Pb3VvcNbG4geZFwV9Rgmq9n4juJ/D926fbJLmGJma5kijVUcLnGAf y4qCPw9dy6VKJLS7F5HaCCPzblGVvUKAeB9TU8uiahAlzHbW+6O809Y5VDqNsyrgdT39qOXDpcqt v/X4B7po2XiOE6eTcLM89vZR3M7BVw25QeOev5U/W9Vlh8JyapZMY3eOOSMsoJAYr1HIzg1zl3aX 2lWt2ZrUFJtNihJ85AUZUAbjOTgjtXU6fn/hFbLFt9pP2SL9z8vz/KOPm4rKpTpwcakdVdf8ElpL Uqw34sraW9uNaN8kcW9oI1iyOnPGDTX8X2UKu09rew7YROA6LlkLBRjDeprF1qwumNzff2Utjbx2 TowDxncxPopqO70jVdYt1mjsDGv9nRQpulT5yHVsjB449a1jQoytKbWvmlb7tCuVdToJPFtnAs5n tbyFoUWQo6LkhiAMYb3p91rDA2ReK+svNu0hCvFGTJnseThfcc1i3fh27utJu2S1uhfOscYFxco+ 9QwJwRwOnc1qalBqOqvpkh054Ps99HI6tKhOwdW4P6dazdOgmrW631XYVol2412K0vorWezu0E0w hjmKLsZj075x+FZGieKJJNPtI7qK5vL2YO/7iNPuhiPUDtVC28P6kLqyMunsJYr4TS3LTqQyBs9N 2f0qWz0G5ttJtEn0q4kvI1kXfDdLHsBYkDO4Zq/ZYeMbXTfqvPz/AFC0TsreUzwJK0UkJYZ2SAbh 9cE1JWboEF5baHbQ6gWN0obfufcfvHHPfjFaVedNJSaRm9woooqQCiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKAO/07TtPbSbSSSyhd3jXJ2Lz8o56e9WP7O0z/AKB8P/fC/wDxNGnf8gSx/wCua/8A oK1Iz7TjGa9r3YxWi2XTyKI/7O0z/oHw/wDfC/8AxNH9naZ/0D4f++F/+Jp/mn+7+tHmn+7+tHNH svuQrjP7O0z/AKB8P/fC/wDxNH9naZ/0D4f++F/+Jp/mn+7+tOVt2eMUXj2X3ILkX9naZ/0D4f8A vhf/AImj+ztM/wCgfD/3wv8A8TU9FPTsvuQyD+ztM/6B8P8A3wv/AMTR/Z2mf9A+H/vhf/ianoo0 7L7kBB/Z2mf9A+H/AL4X/wCJo/s7TP8AoHw/98L/APE1PRRp2X3ICD+ztM/6B8P/AHwv/wATR/Z2 mf8AQPh/74X/AOJqeijTsvuQFC48PeH7xw9zodjOwGA0sEbED8VqddM0pECJpsCqowAEUAD/AL5q xRVOV1b9EFytLpOkTxNFLpdvJGwwyvGhBHuNtKumaUiKiabAqqMBQigAf981YopX6WX3ICD+ztM/ 6B8P/fC//E0f2dpn/QPh/wC+F/8Aianopadl9yAg/s7TP+gfD/3wv/xNH9naZ/0D4f8Avhf/AImp 6KNOy+5AQf2dpn/QPh/74X/4mj+ztM/6B8P/AHwv/wATU9FGnZfcgIP7O0z/AKB8P/fC/wDxNH9n aZ/0D4f++F/+JqeijTsvuQEH9naZ/wBA+H/vhf8A4mj+ztM/6B8P/fC//E1PRRp2X3ICD+ztM/6B 8P8A3wv/AMTR/Z2mf9A+H/vhf/ianoo07L7kBB/Z2mf9A+H/AL4X/wCJo/s7TP8AoHw/98L/APE1 PRRp2X3ICD+ztM/6B8P/AHwv/wATR/Z2mf8AQPh/74X/AOJqeijTsvuQEH9naZ/0D4f++F/+Jo/s 7TP+gfD/AN8L/wDE1PRRp2X3ICD+ztM/6B8P/fC//E0f2dpn/QPh/wC+F/8Aianoo07L7kBB/Z2m f9A+H/vhf/iaP7O0z/oHw/8AfC//ABNT0Uadl9yAg/s7TP8AoHw/98L/APE0f2dpn/QPh/74X/4m p6KNOy+5AQf2dpn/AED4f++F/wDiaP7O0z/oHw/98L/8TU9FGnZfcgIP7O0z/oHw/wDfC/8AxNH9 naZ/0D4f++F/+JqeijTsvuQGdrkemaNYw3P9lwzeawXbhVxxnrtNYH/CQ6Z/0AIf++1/+Ira8cf8 gOy/66j/ANBNcKkMsiO6ROyoMuyqSF+vpXBmFapSxDhTtay6Lt6H02WZfhq2H56sbu/d/wCZ0H/C Q6Z/0AIf++1/+Io/4SHTP+gBD/32v/xFYf2K63on2abc4yo8s5Yeo9agIwcHrXC8XXW/5L/I9BZT gXtD8X/mdH/wkOmf9ACH/vtf/iKP+Eh0z/oAQ/8Afa//ABFc8iNI4RFLMxwFUZJNKYpBN5Jjfzc7 dmOc+mPWj65X8vuX+Q/7JwX8n4v/ADOg/wCEh0z/AKAEP/fa/wDxFH/CQ6Z/0AIf++1/+IrnzDKJ vJMT+bnGzad2fTFPNpchZGNvKFjOHOw4U+/pR9bxH9RX+Qv7KwP8n4v/ADN3/hIdM/6AEP8A32v/ AMRR/wAJDpn/AEAIf++1/wDiKw3s7qNSz20yqoBJKEAA9DUaQyyK7RxuyoMsVUkKPf0o+t4hO3/t q/yD+ysC1fk/F/5nQf8ACQ6Z/wBACH/vtf8A4ij/AISHTP8AoAQ/99r/APEVzlFL67W7r7l/kP8A sjBfyfi/8zo/+Eh0z/oAQ/8Afa//ABFOj13T5XCR+HY3c8BVZST/AOOUaX4dgSzOo61Ibe1Ayqk7 S319v1qnfePraxVrfw/YRRL085l5bHfHf8a9GlCvyqdaain05U2/lY4J4XBuThQpczXW7SXzudJb 2stwob/hFoY1P/PWVFP5bM1cGkEjJ0XTx7GYf/Gq8mvfEmsag2bi/mI/uq2B+QrMZ3dtzMSfUmtv rFKOyb9eVflEX9jxluor05n/AO3Hs8umyRj5fDtnJ/uTp/VBWPd6jBYttuvC4i5wCxXB+h2YNecW +p31owNvdzREdNrkV0unfELVLb93fKl7AeGDjnH170nVpT2bi/SLX5Jh/ZcYa8ikvWSf5tGz/wAJ Dpn/AEAIf++1/wDiKP8AhIdM/wCgBD/32v8A8RVmCDQPFdu0mmEWl8Bkw9AT9P6iuZu7SeyuXt7i MxyL1BrkxLxVC0m04vZpK35G+HwWX1m4+ztJbpt3/M3f+Eh0z/oAQ/8Afa//ABFb9jBp9/p8F2un W8YlBOworYwxHXA9K89r0Hw//wAi9Y/7r/8AoxqeCrzrTlGdnp2Xddkcmb4DD4egp0o2d7bvs+5b 07/kCWP/AFzX/wBBWnuCzgDkngCmad/yBLH/AK5r/wCgrVm1AbUI1PZS39P616sIc7jHvb8j5zcy 9Y12y0DEJj+03pGfLzhU+tYq+P73fmXT7Zos/dGQfz/+tXOrOt7qxub0uUlm3S4+9tzzj8K6TXTa S+GNNktLYQQtK+Ezk8EjJPc8VwPG1ZqcqUlGMdlbV6pfqcTrzldxdkjoLG/stZs2ubIlWT/WQt1W p4+9cT4LmeHxTDEpISZXVx2ICkj+VdsmMyKP4ZGX8jiuqjUVeiq1rO9mdFKp7SHMPoritGiufFF5 rt1danqFtJZ6o9nbLZ3BjSJIiCDs5Vy2Tu3hs9AAKp2viq+T+0YYDF9qbXLm0t4dstzLKE2cKjSq FABLM29UUL935uNOU1PQaK8Xv/HGp3sDauC8YbQVla1S4lSLzReiIuNjKwJAPQ5wcEkZz2f/AAlm qReMP7KvobSwikvPJtkuopF+1RbfvxzglC+Sp2FR94Lu3U3BgdrRRRUAFFFFABRRSE4BNAFe5u1g GBy38qy31rDlRJkg87V4H1rJ1XUCX2mTZvk2Fv7uTiovtUcMYUYjjXoM8VV0tD1aOGioJtXudCNV dBlyuB1zVqLU4ZAMnGe/UVyEl4p2kJukfhN4/M/SmNdBYwEmOUYRoox83Tr9c0uZFSwkJdLHeo6S DKMCPanVxq6i8LblfGD1zXT6bdG8sIpz1Yc+9HocFfDulZ3LdFFFI5wpjzRxvGjyIrStsjDMAXbB OB6nAJ+gNPrz7x4v2XX9M1OWOK/tIP8AX2ivtngAjnYyxtkbcqGbsS0CYORw0rgeg0V5B/zMf27/ AKnD7P8A2h/y8/cx5GP+eP8ADnf0/g7VN4Ws7q08ReFQIPMmb+0Te6nbSJLHfLnIZpEYswDFP9YB hiO9VyAes0UUVABRRRQAUUUUAFFFFABVe9vIdPs5bqckRxjJ2jJPYAfjVisbxV/yLV3/AMA/9DWr pxUpqL6sFuU/+E303/nhd/8AfC//ABVH/Cb6b/zwu/8Avhf/AIqsjwxapPpGsSfZ/Nnj8nyytotw 65Zs7Ubg8dfz7VszaXZS3bxWljbSGLW4xKkKiTZCUGd3HC53ZHQHI7V6n1OkacqG/wDCb6b/AM8L v/vhf/iqP+E303/nhd/98L/8VVNZNOMGrXq6fay/2VcP5G1V8udZXKrvGPmC9RgjjA461jaTHpz6 Xe/2ijKrzQxpcIMtASsh3Y/iHyjI9PcCj6nSDlR0v/Cb6b/zwu/++F/+Ko/4TfTf+eF3/wB8L/8A FVVutOFtpUw020tru/Sa3SQwwLP+7+zqdwBBwC2TuwM1YltNIbVdYtkt7YJYTR3yhEBLIoHnRk8j HXC8cn0HB9TpByod/wAJvpv/ADwu/wDvhf8A4qtnTNTt9WtPtFvvChipVxggj/6xH51xviSOytNP tUtoYlkvZHvifLAaONj+7QEDgYzleeR6YrZ8Ef8AIFm/6+G/9BWsMThoU4c0ROKSL/jj/kB2X/XU f+gmsfwcFuLu9sJDhLm2ZSff/wDUTWx44/5Adl/11H/oJrldCi1KXUlOlcXCKTuOMKOhznjvXh4q fJmMXa+2i66an1GAhz5dJXtvqz0Cae3eO6vkwG05JoV+u1T/AExXPQeH9Ne1gtGikN1NZG6+1Bzh Txxjpjn/ADms+S08QW93JpTEB9QLSMMriQ8knPbp7VWtdR1mRBosNxwcxBTtBA7jceg49a0rYuFS a9rSd9Vt100+62u6CjhJwj+6qK2j36a6/ffTZmxaWem2LaFIts5u7sxt5m84QgjJx75xVqKxsk1K fUJ4WmnbVRDHtcjyzuBB965ObUr+Ke3R5hvsTsiwq/Jg/Tnp3zUkHiHVLdp2iuipnfzHOxfveo44 /CueGNoRfK46LyXa333udE8FXkrqWr833/KxPrMxtvF0846xXAf8sGu7uYbXzJdPJH/Ez8x8jsQi jP8AWvOJory/huNUlKuN4Ej5AJY47U5tc1J7m2uGuSZbZdsTbF+UYx6c/jSoY6NCU3OLtN3Xpd3+ 9aBXwUq0YKEleKs/Wyt+Op1WtbbmPX2DuBbrDGqq5Cn1yOh5JqR7Gy0yw1iztoWWRLJTJKXJEhIb t26dq45tWvmS7Qz5W7bdONo+c5z6cfhU8niLVZbT7M90TEY/KI2LyvucZ/Gq/tCg5Obi7tPourl5 6br7rE/UKyioKStddX0UfLyf33N+80DSLXTZImZFulthKJjMdzNzxt6Acdaq6NZ2mj6W2vaqOF5g jbv6HHqe1Hh6/wBR1W6h02actZRrukG0ZKL0UnGSM4H0rm/HOvtqurNaxN/olsdigdC3c1vH6u4r FRja2iVuvfzt36mfLiHN4aUr31bv07eV+3QzfEHiO81+7MkzFYVP7uIHhR/jWPWjp2hanqsbyWNl LMifeZRx9M1reHPC0GsW/n3V8IFZiiKoDEY7tzwM4HuTWPs61ed3q2dvtKNCFlol2MC1sri9crBE zAFQzY4XJAGT25IrpNb8IQ6Vpsky3kj3MLYliaLAI4+ZfbJxk9f1rUmu9L0ez1XT7m3fT9RFt5O2 IEpOQco49D/jXM6j4q1XVLIWtzMmwqquUQK0gHTce9aunRpQanrJ/gYKpXrTUoaRX4rQxaKKK4jv JILiW1nSaCRo5EOVZTgivS9F1e18Z6edO1DbHqMS5jlH8XuP6ivMKntLuaxu4rm3cpLGwZSK3oVv Zvlkrxe6OfEYdVVeOklszo7m2ltLmS3nQpLGcMDXeeH/APkXrH/df/0Y1ZWtyxa94YtNbhQeahCz Y7A8HP0OPzrV8P8A/IvWP+6//oxqqhhvq+JlFO6cbp+TaPKzTEOvgoyas1KzXmky3p3/ACBLH/rm v/oK02e5+xXUF02fKQ7ZMdlPf8OtO07/AJAlj/1zX/0FakkjWWMowyCMV6EJcrjJeX5HzRwPiHR5 dH1F5FXdZzMXhkXkYPOKkvtUtZfC2m2kcubiF5DIm0jaCxI56d66QpqGmxNBDHHe2J/5d5v4f909 v1qlH5cc3mReEoFkzkM1yWAP021zTwEXKUqUklJWad9NU9PuOaWG1bi9yv4S097Nn128BjhiQiFT wZGIxx/L8a6ez3/ZlaT77ks31PNUo7e9v50uNSdcJ/q4IxhE/wAT71qdK6FCFKmqVPZfizeEFCPK jHvvC2jajeSXV1Z75JfL85RK6pNsOU8xAQsmP9oH06UxvCWiM7OLR45WupLzzYriRJBLIMOQ6sGU MMZUEDgcVt0Urso5v/hAvDP2X7N/Zv7n7P8AZtvnyf6vzfN253Z+/wA569unFXP+EW0b+0vt/wBj /ffaPtW3zX8rzsY8zy87N+P4sZzz15rYoouwCiiikAUUUUAFHUUUUAcJ4ksZbW6d2iaS2k5OBnbW AlxZxsGHJX7u9i236AmvV5Yo5kKSKGU9jWa/h3TnYsYFyfam1F6s7aONlTjytXR5617bysGIMrDp wTVm3hv7yXdbWe1j/wAtHHNd7DoenwEFLdcj2q8kSRjCIFHsKLRXmOePqPSKschZeEZ5mWS/nLDr sHArroIUt4VijGFUYFSUUN3OOc5Td5O4UUUUiQqneaVYahc2lxd2kU01nJ5tu7rkxtjGR+h+oB6g EXKKAKf9k6b/AGl/aP8AZ9p9u/5+fJXzem372M9OOvTin22n2VnNPNa2dvBLcNvmeKJVaVuTliBy eT19TVmigAooooAKKKKACiiigAooooAKqanYrqenTWbuUEgHzAZwQQR+oq3RTTad0Bx3/CB/9RL/ AMgf/ZUf8IH/ANRL/wAgf/ZV2NFdH1ut3/IfMzjv+ED/AOol/wCQP/sqP+ED/wCol/5A/wDsq7Gi j63W7/kHMzjv+ED/AOol/wCQP/sqP+ED/wCol/5A/wDsq7Gij63W7/kHMzjv+ED/AOol/wCQP/sq 6DRdJXRrE2yymUs5dmIxycDgfQCtGionXqTVpMG2zJ8cf8gOy/66j/0E1ieEftRvLoWywSAwnfBK xBkHoDj/ADmtvxx/yA7L/rqP/QTXCRyPE4eN2Rx0ZTgivJx9X2WOVTsl+R9bllL2uAcO7Z6ALVIP EehsPNhZ45c2rylxF8h6c8en4Uzy7e8n0Wd7WBS9xOjKqDBA3AZ9egrhGuJ2m85ppDL/AHyxz+dA nmG3Esg2klfmPB9qX9pw1XJo3f8A9J8v7v4m39mz0fPqlb/0rz8/wO70u1H2Z3gsYJXGqMjFowdk ecHH0FOsrOKOO9NlZwTMmqbBlA2xPl3Y9hk/SuQTWriPSPsCZX9953nKxDZxjFEGsz2+kPYRgrvm 87zVYhgcAY/StI5hQSirbL8ey0/EzlgKzcnfd/h33/A6S5s7OO11TyoYsJqEaqQo+XJXIHoMk8VY 1mGzNjq0TWkEUdtPBhkTB+bZuP5EiuEE0oUqJHwTuI3Hk+tKbiY7syudxBbLZzjpn1rB5jDlaUN/ /tv819xssvnzJue3/wBr/k/vO91y0jXStVb7HbJEiRfZpERcleM/rmvPq3LzxH9p0+a1hsILbz9v nNH/ABY9B2rDrLMa9OtUTp9v1b7I1y+jUo02qnf9EvM6bSJv7J8I6rqe7Dv+6TjuB/8AZfpXmpJZ ixOSTkmu/wBbYw/DO0x/y2u8H/x//wCJrz+uur7tKlBbKKf36meG96dSb3cmvu0PQfC+qLf6Gumf ZLMfZATuubkxo4Y85Ufe4zntjjvVHVvEttpWr30ehQWpt540Dt5eV8xedyf5681xlbmm+H5LrR5d YBSeC2mUTWyN85TqT7cf19K1jiKs4qEVquvkv+AZyw1KnNzm9H083/wTJmmuL25Ms0kk88h5ZiWZ jXTWHhOG68MXOoy3Dx3duzM9uEy20Y4I6jPPNdDBp+kWGs217axxpY6rDttZ+ptZgOMZ9f5is3xL r91o+r2n2eUHVIIDDeS+XhZumOD1+vvWiw8KSc6zv0+/r+voZvEzqtQoq3X7un6epc1yPSodDvk8 ux+w+Sjac8WBLv6FWHU85JJrziprq5mvLmS4nffLIxZjjGTW1p3g7VNStEnjMEfmKWhjlk2vKB3U envWFWUsTP3I7HRSjHCw/eS3/r/hzAwcZxx60ldLPbGLwFteIJPDqhjfjn7nQ1Qn8M6zbaf9umsJ Ut9u4seoHqR1FZyoyWyvpc1jXg93bW3qdN8Prj7Xa6norvhZ4SUJ5wSMH+ea6jw4SfDliD1CuD/3 8auC+H8pTxhaoOkiyA/98E/0ru9MfybR4h0juJ0/KZ676C56UZdrr8Ys8DN/ccorq4v8Gi5YSFdF scRu37sdMf3V96mEjH/li/6f40zTv+QJY/8AXNf/AEFanos7LXovyPBGb2/55P8AmP8AGje3/PJ/ zH+NSSGG2tzcXc6QQ/3nPX6VSXxB4ekfYupgN6sjAfmRirdO1uaSV+7SBtLdlne3/PJ/zH+NG9v+ eT/mP8amePaiyKyvG33XU5BplKUJRdmOwze3/PJ/zH+NG9v+eT/mP8afRU28xDN7f88n/Mf40b2/ 55P+Y/xp9FFvMBm9v+eT/mP8aN7f88n/ADH+NPoot5gM3t/zyf8AMf40b2/55P8AmP8AGn0UW8wG b2/55P8AmP8AGje3/PJ/zH+NPoot5gM3t/zyf8x/jRvb/nk/5j/Gn1A1zlzHAvmuOvOFX6n+nWrh SnUdo6g9CTe3/PJ/zH+NG9v+eT/mP8aj8uUnLXqof7qxZA/EnJ/Smm4aE/vsOn/PSMHj6jqP1ron gK8VfcVybe3/ADyf8x/jRvb/AJ5P+Y/xpysrqGVgynkEHINLXJZjGb2/55P+Y/xo3t/zyf8AMf40 +ii3mAze3/PJ/wAx/jRvb/nk/wCY/wAafRRbzAZvb/nk/wCY/wAaN7f88n/Mf40+ii3mAze3/PJ/ zH+NG9v+eT/mP8afRRbzAZvb/nk/5j/Gje3/ADyf8x/jT6KLeYDN7f8APJ/zH+NG9v8Ank/5j/Gn 0UW8wGb2/wCeT/mP8aN7f88n/Mf40+ii3mAze3/PJ/zH+NG9v+eT/mP8afRRbzAZvb/nk/5j/Gje 3/PJ/wAx/jT6KLeYDN7f88n/ADH+NG9v+eT/AJj/ABp9FFvMBm9v+eT/AJj/ABo3t/zyf8x/jT6K LeYDN7f88n/Mf40hkYf8sn/T/GpKKLPuBm+MYJrnRLJYYZJG8wEqiliBtPpXEf2ZqH/Pjc/9+m/w r1K5/wBRb/7v9BVassdg41azk30X5HsYTNp4Wn7OMUzzb+zNQ/58bn/v03+FH9mah/z43P8A36b/ AAr0miuP+zYfzHT/AKwVf5Eebf2ZqH/Pjc/9+m/wo/szUP8Anxuf+/Tf4V6TRR/ZsP5g/wBYKv8A Ijzb+zNQ/wCfG5/79N/hR/Zmof8APjc/9+m/wr0mij+zYfzB/rBV/kR5t/Zmof8APjc/9+m/wo/s zUP+fG5/79N/hXpNFH9mw/mD/WCr/Iji9dtpj8NrdJYnjeC63FXUggfN6/71ed17nqNkNT0O9sSA S6Er9e38q8OkRopGjcYZSQR6GunF0+WNNra1vu0O7K8T7eM29Hdv7xta2ga/ceH7x5oUWWKVdksL n5XH+NZNFckJyhJSi9UelOEZxcZK6Zsa14hn1f7PGsMVra22fJghGApPJP1qCys9Q8RassEbPPdS nl3bOAO5PoBXQ6L4De8s4rzVL1LGGfHkqcb3J6demfzrQ0azj8F+PY7O4nDw3UG1JCMY3HjPpyuP xrtWHqzlGdbSLa/4BwyxNKEZQoaySf8Awdeo1vhqj2ky2urxTX0I+eMAbQeflPOR+NMOt6Un9nNq qXdrqukARFIV4lC9Bnt2/M1Lq8F74R8aDU7dXezvJNzYGQdx5U+/ORUHxPsoYdWtLuPAe4jO8Af3 cYP6/pXTUjGlCUqcbOLs1v6M5acpVZwjUldSTaa0tpqiKPVBeaBqOpSwjaurxXLRZ4we3v0rSn13 S7O71LVoNV+0RX9uVNgVJbzCABnsAOa4a31R7fRbzTVjUpdOjsx6jbnpVCuT644pW1f66/ozr+pR k3fRfpp+qOp+HsJk8XW8gHESOx/FSP612Glu0tm0pBHmXE74PHBlcj+dYvgO3On6PqetsFDLGUhL dCf/ANeBXT6ZbFNLtgeuz+prsoQ5MMr9bv8AL/I8PN6ylXcV0t+v+Zb07/kCWP8A1zX/ANBWrMKi S6jjPT7x+gqtp3/IEsf+ua/+grUsUwg1S33HCyAx5PqeR/KqopOcU/L8jyVuef6rqv8AbGvGa68x rNJNqxocYQHt7mtiODRtYsdRWHTBaLawmSOcSEnI6Bvrj3rnGsLi31d9O8tjMJPLVfXniu1vvD+o QaNFpmnwq4f57mXeF3t2HPYf4V5VBV6s6kpR5rXvpd32SXVfLax50FOTk2rmT4I1KVNQOkysWt51 YopP3WAzx+RrrQeoPVSVP1FcR4LgebxLHcgYit0d5G7DKkD+f6V2VtIJo2lHSR2cfQnNdeDcpYSL n0bS9NP1OnDNulqc3ceN7a38Oa3q7Wcp/sq8ks3iDD946uFUg9gdyk8cc8HHNmx8V200Nx9qCC4g upLZobFZrlgybd3AiVsAsASFK8rzk4rL1HwVc3njiPVUniGnSXFveXClz53nQI6oEG3Gw7lzk564 IqsfBerK9wGksrqzm1q41CXT5JXSO4RwPLDsEJyrLkpgqe/QV0WibnQSeNPDsVtDcNqkRimt2uVZ VZsRg4LNgfL83ygNglvlGW4p9r4t0S8uHhgu3YxwpPI5t5BHFG0fmKzuV2qCvPJHp14rzuTwpq/h vTBDt+0Tvodzp7fZ7aadSXleQbdi5yQwX59gG4EF8Mo6rwp4W1XSYdSlluIrWe90+zghZf3jQSRQ eWxYfdOG5GCQcUOMbAdHY69p+o3klnBJKl1HGJTBcW8kDlCSNwWRQSMjGR0/GtKuH8K+D9Q0bxGm p3SWSD+zTazNDcPLJcTmQO0zlkHLc9zjgdOncVLST0AKKKKQBRRSEZBFAHD+JPGi2U00MUbvBEwV yjAFjkA8+grFHj0KsSJbOA24gblACq+3I9eeQKTxdoFxDNcssbPbzg7tvUZ9K4uaC2eOGFnkAgTy 8ZGWGQeePUZr7HA06M6K9h21738zzKs5wm+fv+B3sXjZJr+SzBwyFgcsO2O3YcjFOfxgiTzxE/6l CzHdyQBkgDqeK4VWhS7a6BPmszueeMtjPb2FNk8mWWSSSR23qy7C3yruGCRxwcCu76u7bGPttfke h6d4tYs0yDaFfbJGTkMcA/1613ttcJdW0U8f3JFDDPoa8V0PTbq6YQ2olZXbc0rnkngZ7dgK9l06 2Npp8MB/gUCvm84jRTio/H1t+vmd2Gc3dvboWqKKK8Q6wrK1PxFp2kXdrbXcjh7hsZVCyxLtZt8h H3F+RuT/AHWPRWI1a4TxvBcw6/o1/pQu01bzNkREZkguMRzERuoOAckruO3CyscnaSrirsDqbjXt MtdSisJ7nZPLIIlJjbZ5hG4IXxtDkchScnI45GYbHxTo2o3kdra3m+SXzPJYxOqTbDh/LcgLJj/Z J9elcPZ6frOn+IZltINSiu5vEzzy7fM+zPYuuWYn/VE4/wCB5AHUCpvDfh69i1vQEhW4TT9Ea9yl 7aNDKnmkhV3hmSYkkncmAAOeSBVcqA9KoooqACiiigAooooAKKKKACs7Xbyaw0W5uYCBKgAUkZxl gM/rWjWN4q/5Fq7/AOAf+hrWlJJ1Ip90C3OZs9X8S38M80F0nlQbfNeTyY1XdwMlsdcVM954tjYK 7MpNyLTDJEP3pGQOncEHPT3qhomrW1hp2pWs+8NdeVsdYEmVdpJOVcgHrWo/ijT7m5dpYrqKNdSS +jK4lZgqhdpyw29M8EgZx0Fe17Gn/KvuNbIYLnxebiCDf+9uHkSJcRfMYyQ49sYPXr2qkniDxDLa zXKXDNDCVEjiJPl3Zxnj2PP+IoXxFmw12H9/G+oyiSJUbKpliXBOR1XA4HOOap6ZrEml2s6Q8ySy xsysuY5ECuGRx3B3Dj+RApexp/yr7gsjVTUPFLxGX7QkcQ2fvJTDGpLLvUAtgE7SDgcjvTnvPFsb BXZlJuRaYZIh+9IyB07gg56e9RXut6ZqOnyWJiubSHzopo9iiXG2ERlDll6Y4OefQVM3iyFtU1i5 8h1jvERoOAWSWPHlsecYyMkc9hyOp7Gn/KvuCyIJ9W8TW1vLPNPtiiuDbO2yM4kAyV4H69K6Xwvq NzqelNLdMHkSUpuC4yMA84471x+u60mqwWEUaMogjZpWYYLzOd0h4OME8jp1PtXS+CP+QLN/18N/ 6Ctc2LpwjTukkTJaHXXP+ot/93+gqtVm5/1Fv/u/0FVq4cR/E+78iXuFFFFYiCiiigAooooAKKKK AJIX8uUN2715v4/8PGxv/wC07dc21wctj+F//r16JRJHBd2klndoHgkGDntWnLGrB0pfJ+Z2YHFv DVebp1PB6Bwc10vibwjdaFMZog01ixysoGdvsa5qvIqU5U5cs1Zn2VKrCrFTg7o9h0rU9O8U6Ot/ c2DmTS/nA/2wM/Ljr0FQpPp3jfw9fXdzYC3mtwyiVjypAJBDenPSuF8L+K7jw1NKFiE9tNjfGTjB HcH1qzr/AI4vdYtTZwQpZ2jf6xI+rnvk+lessdTdK83d21Vt+2p5DwFRVWqasr6O+y6qxasPiRqN rYpb3FtDdPHjbJISDx0z6n3rmNV1a81q+a8vZd8pGAAMBR6AelUqK8ypiKtSKjOV0j1KeGo05OcI 2bCrml6dPquoRWduuXkOM9gO5NN0/TbvVLtbazhaSRvQcD3NejWdvZ+DLQ28BS61ucAMBz5efX0H 861wuFdaV3pFbswxuNhhof3uiLd/DbwW9j4esn3CBg8+0+g4B+pOfwFbqoI4IVHZP6msbQ9MNpCZ ZSXmkO53bkknqTW4/wByP/d/qa9OpNSbtskfGzk5tyZV07/kCWP/AFzX/wBBWkvLb7TAUBKsOVYd QfWl07/kCWP/AFzX/wBBWp6wTtb0X5EnO6gdP1TbDrge0vYxtW8jX5XHv/8AXrP/AOEa0RPmk8UW zJ/dQLu/9CP8q66W3inXEiKw9xVVdIsFbcLdAfpVTjQqvmqwu/n+hEqdOTvJFC2MD2v9m6NA8dkx zPcyD5pfb6VtogjRUXoBihEWNdqKAPanUTnzWS0S6F+SCiiioAKKKKACiiigAooooAKKKKAI5oI7 iMpKgZT6iuL1/wABW19ulthsf/Z4ruKK1pVp0pc0HZiaUlZnhs/gfV45iiLuXPU5rpNB+HbblmvW J9j/AIV6btB7Clruq5viqkORy+4xjhqUXdIp2OmW2nxBIYwMd8VcoorzW7m4UUUUgCiiigAooooA KKKKACiiigAooooAKKKKACmuiyIyOoZGGGVhkEehp1FAFP8AsjTf+gdaf9+V/wAKP7I03/oHWn/f lf8ACrlFVzy7hcp/2Rpv/QOtP+/K/wCFH9kab/0DrT/vyv8AhVyijnl3C5T/ALI03/oHWn/flf8A Cj+yNN/6B1p/35X/AAq5RRzy7hcp/wBkab/0DrT/AL8r/hVmKGKCIRQxpHGvRUUAD8BT6KTk3uwG ay7pBZ7WZcqc4OOwrgIPGd6uiQapqVrFaQXdqbm1ZLx5VJERl2SYjBU7FY5VXHyt32hu91v/AFFn /un+QrztfB9zP4dTR7/U4Zo7aya1tGhtTHsJhaHzHBdt5CsQACo+ZsgnaVzxLh7eXO+3fsKW5unx PYrcywPfvH5e/dNIrpCSgJcCUjYSoVsgEkbWz904hbxjpscatNe3MLNIIlint5o5GYqzKBGyhju2 MF4+YqVGTxVG58LNeXmoNPeottfQyQzeRbiOeRXXaBI+SrhAflOwMMAbiC++0uk6hPd2VzqGpQzP aXHnKkFr5SY8qSPGC7Nk+bkncRhQAByTzfu7bv8Ar5E6Fo+J7FbmWB794/L37ppFdISUBLgSkbCV CtkAkja2funFKTxpbC/060i+3NJeXHkMsltPG0Q2OwcqyZwSmATgcOc4RsZ7+BbOW5vi/wBkWG6+ 0FpY7JBd5mDhwZznIHmNgBQcBQSQCGfZ+EWsri1uYZNLtpYLpZ2Wy0wQRugjkQggOW3ESt8xYgYG F67q/c2+Jhoamo6/f2+rQ6bZx273EsfmL9svWtxL1ysWEcuVCksMDaGU854jtPF8M2o3NhctNa3M M0cWx2L7S8UbrvZcqhLOUGWwzKQpJ4p+s6Xd6khhjuLFrWRQsttf2P2mNiDkEAOnOeuSw+VcAc5r ReGPKsp7b7fNL5l7a3XmzDe58gQDDHPzFvIyW45bpxzMZU+XV/mGhNp/jPT74W6Lf/v5FiLrGJGS NpEV0BcqMBg4Clgu48AbgQCLxnp93bxTWV/5qytCI2cSIsiySImUO07iC4BA+6xCsVzkY2jeEb2y WSymvv8AQI7i0cL5S5m+zw24V1IbKZeIhg27IUY2/eJpXhG9bR9GTUr7E1hb2yRx+UuY9skMsiMw bD8wKqkAYGc7zzVtUU/i7f1sGhu23jHTbu2NxHe3KxmMSoZbeaMzKSADGGUGTJZR8meXUdWGbmna 5b6tHM9ldvKIZPKlBDKUfaGKkHBBAYZHUHIOCCBzl74Ykg0fSkhkmuZtKskt4kijQGV1kgdXw7qM AwAldwJBIDA4rQ8M2d/bxahc6jvE97deftkCBlHlRpghCygZQ4AZjt25JbNRJQ5XKMvxDQ6a31B4 EaKZPtFu3VGOcfTP8qxNQ8IaFq0hfTrsWVwx/wBTJwpJ7AH+ma0ajlgjlXDqDVQxT5eSquZfj95v h8XVoO9N2OPvfAWvWjfLbC4X+9E2f061mN4b1tWwdIvj9Ldj/Su9EN3Au20vriFR0VZDtH4dKa11 4iUYTVnx7xRn+a1XLhJa3a+5nrQz2ql70UzjLfwfr9ywC6bMme8q7P51tw+BbfTkWfxBqtvax4JE auNzY6gev4ZrQkXXrjiXWboD/pmwT/0ECq8PhyASmWYmWRjlnc7iT7k1S+qQ1s5epnVzuvNWjZFo a9ZWVq1h4VsWG4YN5Iu38QCMk/XH41HpelNakzzSyPO53O7MSSfUmtCG1igUBFAqas62LnUXKtF2 R5FSrKbvJ6jxNKBgSv8A99GtpCTbW5JyTGOfxNYVbqf8ett/1yH8zTwrb5r9v1FEq2EMb6LYlkU/ uweR/sr/AIVMIIR/yyT/AL5FM07/AJAlj/1zX/0FasKpeRY16scV0qClZJa2X5FWGpbq5wsKk+y1 IbBgM+Qv5CuV8Q+KJxenTNKlEEaNsknB5Zu/PYD1qG5stdtbSW7t/ELXbW+DMkVyzbPwPBqXUopu MU5cu9rf0zF1optJXsdWYEU4MSg+hWk8qP8A55p/3yKy/DXiBtbjayvABexruSQDHmD/ABrWByM1 VoSipw1TNIuMlzR2G+VH/wA80/75FHlR/wDPNP8AvkU+ilZDsM8qP/nmn/fIo8qP/nmn/fIp9FFk FhnlR/8APNP++RR5Uf8AzzT/AL5FPoosgsM8qP8A55p/3yKPKj/55p/3yKfRRZBYZ5Uf/PNP++RR 5UX/ADzT/vmn03vRyoLCeXF/zzT/AL5pDHFjlE/Kh3WNGdzhVGSa5u61uK6lMcdwijOAu4AmqjBM 1p0XN6G+0tmpwzRA/hT0+zyD5BG30Arjm8za3+ubMhxsByfk4AA7ZxVgXCxS7VlVZBwQG5z6Vp7K LOh4VdGdZ5cX/PNP++aPLi/55p/3zWZpup+fJ9nlI8zGVP8AeFalZOCRySg4uzE8qP8A55p/3zR5 Uf8AzzT/AL5FOHSlpcqJsM8qP/nmn/fIo8qP/nmn/fIp9FFkFhnlR/8APNP++RR5Uf8AzzT/AL5F PoosgsM8qP8A55p/3yKPKj/55p/3yKfRRZBYZ5Uf/PNP++RR5Uf/ADzT/vkU+iiyCwzyo/8Anmn/ AHyKPKj/AOeaf98in0UWQWGeVH/zzT/vkUeVH/zzT/vkU+iiyCwzyo/+eaf98ijyo/8Anmn/AHyK fTXdY0Z3YKijLMxwAPU0cq7BYTyo/wDnmn/fIo8qP/nmn/fIqt/a+m/9BG0/7/L/AI0f2vpv/QRt P+/y/wCNV7N9h2LPlR/880/75FHlR/8APNP++RVb+19N/wCgjaf9/l/xo/tfTf8AoI2n/f5f8aPZ vsFiz5Uf/PNP++RR5Uf/ADzT/vkVW/tfTf8AoI2n/f5f8aP7X03/AKCNp/3+X/Gj2b7BYs+VH/zz T/vkUhgiPWNPyqv/AGvpv/QRtP8Av8v+NWYpop4hLDIkkbdGRgQfxFJ07boVhNYby7ezChcbTwVB 7Cuai8QWU2oGySTMu5kDG2Ijd1zuRZCuxmGGyoJI2tkfKcdJrf8AqLP/AHT/ACFefRWmsweGj4ct bV4pYLBrWLUzOqRkiMrG67SZA2dpIKgL82GbA3Z4tJ1pXfb8kKW51vnN6J/3wv8AhR5zeif98L/h XBL4aN5qlq6aH/Z2kC4jaWw3RoMrDcq8hWJipDeZChGSWCkMNo5yR4dudLTw7aSaSjQMtoJrOOVY 1muFtrvz84OGYrsB3fK+ArNtyRiqSf2/6+8VvM9MXUI3vZbNWQ3EUaSunlDhXLBTnGOSjfl9KF1C N72WzVkNxFGkrp5Q4VywU5xjko35fSvPZ/C2qyq3mW032M+UWtYWgdjEJLtkgCS5iPliaDg/KNny klVoTwjeRJepBp80b3Nlbr9oLW7SlUuXeSA4AXLRGNAm0xYUISVUEv2UP5wt5npPnN6J/wB8L/hW fY+ILLUZ2htZNzbd6F7YosqZA3xsygSLyPmUkfMvPIzhaZ4dc+EdT0hhcWkd6ssca3HkloVeMJ9y ELGozltqk5zknLECHxFY6t4j0ma2/sx7WW2huGXfNGy3Er28sSrGQfu5kJ3OEPC/LydsKMb2cv6/ UDrLzUI7CynvLlkS3t42llfygdqqMk4AyeB2qfzm9E/74X/CuC8TeGZ5ra+trDSvtay6cYLNvtAQ 202ZTI5djuzJvQEjPmFSJCAc1Tv/AApqU0utOkF3JeXEd6Fn32yRTJIkgij3bfOfAaMbXIQFMg4R QajTi1fn/r7wt5noV3qC2Vs9xKjMiYyIbYytyccKilj17CodL1q31myW8stzW742PJatFvBAIIDq CQQRgjg0+0tILG2S3t02RpnAySSSckknkkkkknJJJJyTXM6X4fnH/CK/brXjTdKaKVTICEnH2faC AcNgxsR1AKg9QprOPK07v+ten/BEdh5zeif98L/hUDahGl7FZsyC4ljeVE8ocqhUMc4xwXX8/rXn Vv4X1qG5kYWbrFJCPt0fmQhbuRZ4XdRgBpFdBMqtMzMdzB9u4lr9zoN3LcWk1lon2KxijnEmnGZM So0luWjKK21d4jlIVW2Egbzh3U6eyin8f9feO3mdzFd+chZVwAzL88O05BIPBA4yOD0IwRkEVJ5z eif98L/hXnjeE7uRNfuJNNhe+a3n/syZtheOY3N3IpRs5Q4khbORgkdwcMtPIl8a2UMK2899b6nd S3lzDdK7tGyTiMOiktiMMkeZAuw4VchjR7JO/LK9v67hY9G85vRP++F/wo85vRP++F/wqOiubmfc kk85vRP++F/wo85vRP8Avhf8Kjoo5n3Ak85vRP8Avhf8K2UOba3PrGP5msKt1P8Aj1tv+uQ/ma6s K2+a/b9S4kGnf8gSx/65r/6CtWbVgNTjUnqjY+vH9M1W07/kCWP/AFzX/wBBWo73zYvLuYADLC24 A9x3Fd1GSjOLfl+Ra3PNVDCeQSZ8wMd2fXPNdbpLQXHh3UbWzQw3nk75pG5EiAngc8en+eE1HRTq F0Nb0LZI+8PLbNjcjj2P8qbcXfiS8hmtIdCW1acbZpIrcoX9fmPFeXDCTw9WTkm73Ssr3uuj6M89 UnTk7/kZ3g8E+LrTbnAEm7/vhq7mNg7SkdPNfH0yawNM05fDMTGRkl1i4XakaHIiU9zW7bReTboh 5IHJrtw9GVDDqnPdu/odVCDhTszyfxXqN34L17xXbWMUzf8ACQWMdxp6QMYtt2WEDiIAHfKd6ykr hvlGf71Qa9rWqeCNKn03w7eeYnhq1tBeAQRQ2+52QAMhVpJHkJkdiroFBHJbO71m70vT7+e2nvLG 1uJrVt9vJNCrtE2QcoSMqcgcj0FQah4e0TVp1n1LR9PvZlXYslzbJIwXJOMsCcZJ4966o1o6cy/r /hja54h/a95pGu6lLZGFJRrHiKZZHt45HR47ZGUqzKSvPXGM9DkVpa98RPEFtp4ey1dPOTwtZ302 2KJil1JPEGYjacEpJ93phgQOhr2GPRdKhu1uotMskuVlkmWZbdQ4kkADuDjO5gACepxzUH/CL+H/ ACfJ/sLTPK8rydn2SPb5e/fsxj7u/wCbHTPPWq9vBtNxC6PM9d8V+K9Fn8ZyDW0mTQm0+SOJrOML IZiu9OORH8zDGS/C/Pw272GqM+i6Vdfa/tGmWU32zZ9q8y3VvP2fc35Hzbe2enar1YzmpJWX9WQm FFFFZgFN706m96AMbxJcGDTtoOPMbH4Vyel6Xp97qTx3CgNN8yH37j+v510vi2Jm0rzFGfLbcfpX BrelZAUfa6kEH0I5z/KrTaO+jTU6NkbuuC50ZlghDSNIdkZPOPfP0qe38PWlnpYu9QJMh5xnkmr8 PiTSLu1ha+fbMo5G0nmue8QeI4r26Cxttt04RfXtnFVzW2FGFSo1GaskW31FYbm2mQ4InUAD0PBH 613sbb41b1Ga8ijla81aztI8k+YJHx2A6fr/ACr1yFdsKA9hUva7M8WkppIkHSlpB0pag5QrkPH2 qXulWthKk13a6ebiP7VeWqhmhxLHjdkH5CvmdFOWCA8EhuvrK1zRm1m3hRL+4s3imjkDxYYELIr4 KsCpOUGDjIPqCys1uB5r4r8eazpF1rsya1bwnT4dPl0y3WKMRamshBlcBtzuvUfu3GAOuQTU03jj WbfxOIZtUSO4PildLGkPHGAbJlAWbBHm5OQwfdtJI4xxXbTeDNOmdYpLi9fTPLhjfSpJRJauIf8A V/K4LLjC5CsA20bg2Tmb/hFrR9V+23V3e3kSXX2yCzupBLDbz7dodMjeMZbC7iqliQoIGOhVKdtv 60HdG7RRRXMIKKKKACiiigAooooAKxvFX/ItXf8AwD/0Na2aztds5r/Rbm2gAMrgFQTjOGBx+laU mlUi33QLc4jRNJtr/TtSup95a18rYizpCrbiQcs4IHStK58LWUEqoJ7lgdWSyywC/u2UNnBHXnGe h645qtZ6R4lsIZ4YLVPKn2+aknkyK23kZDZ6Zqwlt4vSaSUpveSUTHzTE4DjgMobIUgccY4A9BXt e2p/zL7zW6Gf2DpAN3K9zcrBp00sd4uRvI3FYvL+XByRg5x36CsvStITVLO6K3Cx3SSRpAjnCysw c7M9idvGeM8d+Lq6N4lWC7h8lil2VafdJGS5ByCSTnqc1EPDevLbvALT907q7L5kfJUEA9f9o/nR 7an/ADL7wuia50Oz03S2vbtLp2EsUPkq4jZGaESMSSp7nGMDGOpq5J4Ts0u723Wec/YrqHznYgAW 8gBJ6H5l5JJwMDNRfYvFjCQSRLMJCrMJ/JlBZV2hsNnnHGep71H/AGZ4p+1XVyY2M13G0UztJGdy tjI5PHQdOmOKXtqf8y+8Lora1ottpenxzK8rPcXMotzkFTApwGPA5OQQRwQc10Pgj/kCzf8AXw3/ AKCtYV1oXiK98n7Rbb/IiWGP54xtReg4PvXUeF9OudM0porpQkjyl9obOBgDnHHaubF1ISp2TTJk 9DX1lgsFnlFb5T1z6D0rmYvEOiz6gdPhv9OkvQzIbdLkGQMudw2hs5GDn0wa6TW/9RZ/7p/kK8li tbuZjZLc6yJRrbXH2N7HbbeWL0ylvNMQ42DeP3nJwBnIWvIxMFKvK/l+X9f5mctz0bzF/wCeKfm3 +NRm6gWdYCsIldS6xljuZQQCQM9AWXP1HrXnulQ66LO6N5faoZ2tcXix2cw8ubcuSpeX5wB5nFsF yudpDeVVnRrST/hJNIu5k1ZlFvdwpJMbjy85hIJV/mQNiQ4lydwwCwWM1zuklfX8PImx2H9t6V/a f9m/a7H7f/z6+ePN6bvubs9OenTmrJuoFnWArCJXUusZY7mUEAkDPQFlz9R61y0WkX17resCaZId ObU4LkRm3bzJWjit2UrIWxt3xgH5T91hkHpkxW+uW+j6GTNq0skunCTUS7OXBMlp5i4HIcRCYKFG /IYjLkkipxdrP+rXCx35uoFnWArCJXUusZY7mUEAkDPQFlz9R61J5i/88U/Nv8a8/vor2d7KHTTr 40522sZnmRwpubQN8xIlA2+fy53Ab8fJip5YtRttRmtXOsnTIJpFtGt3d5TKYrdovnYksu5rjmQm MHhuAoB7K63Cx3PmL/zxT82/xo8xf+eKfm3+NYvhaaW48I6LPPI8sslhA7yOxZmYxqSST1JNa1YS vFtCJPMX/nin5t/jR5i/88U/Nv8AGo6KXMxEnmL/AM8U/Nv8aPMX/nin5t/jUdFHMwJPMX/nin5t /jR5i/8APFPzb/Go6KOZgSeYv/PFPzb/ABo8xf8Anin5t/jUdFHMwJPMX/nin5t/jR5i/wDPFPzb /Go6KOZgSeYv/PFPzb/GtlOba3OMfuxx+JrCrdT/AI9bb/rkP5murCu/N6fqXEg07/kCWP8A1zX/ ANBWpyMjBqDTv+QJY/8AXNf/AEFanrp6L0X5FGXc6Orz/aLWaS2n/vxMVJ+tR/ZNccbJNZm2f7IU H8wM1sUVpGrOKsmFyjY6XDZZYZeQ/edjkn8avUUVDberAKKKKQBRRRQAUUUUAFFFFABTe9OpMUAQ 3MC3Nu8TjIYYrybxDodxpM8g8tzbOc70GfoD7V6/iop7WK5QpKgYe9Un3NaVaVJ3R4Qb6Ik7riMD cSfn5xio0uDcsiWsJupckhgMIDx1P4dq9fn8GaVPJvaFc/SrVn4bsLNgyRAkdzVLlOp47TRHNeC/ DD2jG+u8tM/JJGOfb0Fd3QECgAAAClxUylc4ZScndgOlLQKKkQUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADNZKCCz3Kx+U4wcdh7VzK67pDwWEwnxHfqr2xZsb1YDB wV4BLKOcfM6r1YA9Jrf+os/90/yFedxeFp5m1JZ5vLKSSnTptoPltJN9pMu0HnEnlrtbr5GejkVn iuV15cz7fkiZbnUwXlncS3MUW9ntpBFKN2NrFFfHTn5XU8etE95Z28ttFLvV7mQxRDdncwRnx04+ VGPPpXBzeHNRe0lMumefd3lu72r74z/ZV1JLNKzbiwI2mWMb4wWPk5wMKKmufC+oNpx+xR/Z9Rl1 G/ma4M2DGrpdrCwYElQDKhwvQuxxktWPs4fzfkKyOwudX0yz+2ee7p9itxdXHU7Ijvw3C8/6t+Bk 8e4p76lp0eoR2DyYupF3JGX5I59upCsQOpCORna2Of8ADmlyWetaldJpH9l2U9vbpBb+Yh2lGmLf IhKx/fBwpIO7d94sBTsfDV7YaKs4XzdVsPKSzXKrvit1aNU67R5qtMcnJTz++wVPLC7V+3br/kGh 1llqNjqCTPbCZlhmeBywKDeh2sBuUbgCCMjIyDzxVaS00DxJZWl5cadb39u8Ylt3uIlfCuAcgMuR kYrj7Xwpe6c6wSWX9pWkOIoV81YsyC2tY0uOuY9phlG5cyLu+UHNQ6R4U1K3u9LkvILv7RBHZhJY 3tglukcUayRmQqZhllkysfyMHwSNzkackFrGf5BY7m+1vTdPnWCZLySUrvMdtBJOyqSQCwjRtoJB xnGcHGcGprPUtO1EStZyeesTKrMj5XLIrjBxggq6nIyOaxtct7j7alxa2GotN5YVbvTbiJXGCcrI krBHGD8uQ+Cz4CnBOYnh/UGlutRubWE6u+o2cqzQyfKsYS3WcxbjlAQsqnozKADkYrOMYON27fcB 2UM0E8EcyRzBXUMA+UYAjPKlQQfYjIolmghQM0cxBZV+TLHJIA4CnjJ5PQDJOADXmnhzQ72Nzbtp 229tbiwQ3nnqfsvl21qZkxn5d6gplM784bCgGjQNDvbjQtCmtdO+zqtvZPcSeerfa8T28ivkncfL jjkGGA27tqbhVujFP4u3bqFj0/MX9x/++x/hRmL+4/8A32P8K82k8PnQ/D2lv9ltLCGPTo11YeZH Es8iy2xMchyFcsonQFjtO8gkBjnc8EeU1tq09tAkNnPf77ZY5hKnl+REuFYZXAKlcKSqlSoJCiol TSi5J3+SCx1uYv7j/wDfY/wozF/cf/vsf4VHRWHMySTMX9x/++x/hRmL+4//AH2P8Kjoo5mBJmL+ 4/8A32P8KMxf3H/77H+FR0UczAkzF/cf/vsf4Vspj7Nb46eWP5msKt1P+PW2/wCuQ/ma6sK783p+ pcTnrLxVaW1jBbtFMTHGqn5FIyAAcZPtU/8AwmFl/wA8Zv8Av0n+NFFcyxlZKyY7sP8AhMLL/njN /wB+k/xo/wCEwsv+eM3/AH6T/Giin9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKP rtbuF2H/AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3 /fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hM LL/njN/36T/Giij67W7hdh/wmFl/zxm/79J/jR/wmFl/zxm/79J/jRRR9drdwuw/4TCy/wCeM3/f pP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF2H/CYWX/ADxm/wC/Sf40f8JhZf8APGb/AL9J/jRRR9dr dwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKPrtbuF2H/AAmFl/zxm/79J/jR/wAJhZf8 8Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3/fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH /CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hMLL/njN/36T/Giij67W7hdh/wmFl/zxm/ 79J/jR/wmFl/zxm/79J/jRRR9drdwuw/4TCy/wCeM3/fpP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF 2H/CYWX/ADxm/wC/Sf40f8JhZf8APGb/AL9J/jRRR9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54 zf8AfpP8aKKPrtbuF2H/AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP 8aP+Ewsv+eM3/fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/n jN/36T/Gj/hMLL/njN/36T/Giij67W7hdinxnaMADFOQOmY04/Wk/wCEwsv+eM3/AH6T/Giin9er PqF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFL67W7hdh/wmFl/zxm/79J/jR/wmFl/zxm/79J/ jRRR9drdwuw/4TCy/wCeM3/fpP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF2H/CYWX/ADxm/wC/Sf40 f8JhZf8APGb/AL9J/jRRR9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKPrtbuF2H/ AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3/fpP8aKK PrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hMLL/njN/3 6T/Giij67W7hdh/wmFl/zxm/79J/jTW8XWT4zFccDAwij+tFFDxlZ7sLs//Z --------------ms020700070106060404020304-- From owner-namedroppers@ops.ietf.org Mon Feb 06 11:20:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6967-0002FC-LH for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 11:20:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00609 for ; Mon, 6 Feb 2006 11:18:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F691D-000J4i-VO for namedroppers-data@psg.com; Mon, 06 Feb 2006 16:15:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F691C-000J3h-G2 for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 16:15:11 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k16GF2E2027207 for ; Mon, 6 Feb 2006 11:15:02 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k16GF2B8027206 for namedroppers@ops.ietf.org; Mon, 6 Feb 2006 11:15:02 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4sIt-000AEc-6L for namedroppers@ops.ietf.org; Fri, 03 Feb 2006 04:12:11 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2006 23:12:11 -0500 X-IronPort-AV: i="4.02,81,1139202000"; d="scan'208"; a="81625592:sNHT35618088" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k134C36H025862; Thu, 2 Feb 2006 23:12:04 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 23:12:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs) Date: Thu, 2 Feb 2006 23:12:01 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21012DC25E@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs) Thread-Index: AcYoWDPS8hgrBiVHS5uaCBgzKmjumwAHUs2Q From: "Bernie Volz \(volz\)" To: "Mark Andrews" , "Harald Tveit Alvestrand" Cc: "Olaf Kolkman" , , "dhcwg" , "Stig Venaas" , =?iso-8859-1?Q?=D3lafur_Gu=3Emundsson_/DNSEXT_co-chair?= , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 03 Feb 2006 04:12:03.0170 (UTC) FILETIME=[FCA79C20:01C62877] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] I'm confused by what this means in terms of changes to the draft? This UTF-8 reference is in the following section: 3.3.1. Deprecated ASCII Encoding A substantial population of clients implemented an earlier draft version of this specification, which permitted an ASCII encoding of the Domain Name field. Server implementations SHOULD be aware that clients which send the Client FQDN option with the "E" bit set to 0 are using an ASCII encoding of the Domain Name field. Servers MAY be prepared to return an ASCII encoded version of the Domain Name field to such clients. Servers that are not prepared to return an ASCII encoded version MUST ignore the Client FQDN option if the "E" bit is 0. The use of ASCII encoding in this option SHOULD be considered deprecated. A DHCP client which used ASCII encoding was permitted to suggest a single label if it was not configured with a fully-qualified name. Such clients send a single label as a series of ASCII characters in the Domain Name field, excluding the "." (dot) character. Clients and servers SHOULD follow the character-set recommendations of RFC 1034 [2] and RFC 1035 [3]. However, implementers SHOULD also be aware that some client software could be using UTF-8 [10] character encoding. This specification does not require any support for UTF-8. This is *DEPRECATED* and all we wanted to point out is that this data is = *NOT* just ASCII, although the encoding is called "ASCII encoding". So, I think we want to drop or replace the LAST paragarph in section = 3.3.1 of draft-ietf-dhc-fqdn-option-11.txt. Can folks suggest explicit = text? But please remember all we're trying to do is give people a = warning that this data is *NOT* necessarily strict ASCII although that = it what the encoding was called. Perhaps one solution is to use a = different term than "ASCII encoding", although I don't have a = suggestion. This really seems like a whole lot of effort for something that we're = trying to get people NOT to use and is there for historical completeness = (as it has been implemented since the FQDN option has been in active use = for many many years even though there is no RFC). Actually, I do now have a suggestion: Clients and servers SHOULD follow the character-set recommendations of RFC 1035 section 2.3.1. However, implementers SHOULD also be aware that some client software may use other character-sets. This specification does not require support for any other character-sets. If you don't like this, PLEASE SUGGEST ALTERNATIVE TEXT. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Mark Andrews > Sent: Thursday, February 02, 2006 6:58 PM > To: Harald Tveit Alvestrand > Cc: Olaf Kolkman; namedroppers@ops.ietf.org; dhcwg; Stig=20 > Venaas; =D3lafur Gu>mundsson /DNSEXT co-chair; Ralph Droms (rdroms) > Subject: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP=20 > FQDN,DHCID and DDNS-DHCP Related RFCs)=20 >=20 >=20 > > --On 2. februar 2006 16:38 -0500 Ralph Droms=20 > wrote: > >=20 > > > Included below is a summary list of the open issues in=20 > this package of > > > documents: > > > > > > draft-ietf-dnsext-dhcid-rr-10.txt > > > draft-ietf-dhc-ddns-resolution-10.txt > > > draft-ietf-dhc-dhcpv6-fqdn-03.txt > > > draft-ietf-dhc-fqdn-option-11.txt > > > 11. UTF-8 character set usage (Harald Alvestrand, gen-art) > > > > > > Issue 11 needs some clarification; Harald, I hope you'll=20 > kick off a > > > separate thread to discuss how to resolve this issue. > > > > > > - Ralph, for Olafur, Stig and Olaf > >=20 > > I'll try.... > > back in the days (November - how time flies), my comments on=3D20 > > draft-ietf-dhc-fqdn-option-11.txt said: > >=20 > > >A smaller piece of missing material is this, from section=20 > 3.3.1 of the v4 > > >document: > > > > > > Clients and servers SHOULD follow the character-set=20 > recommendations > > > of RFC 1034 [2] and RFC 1035 [3]. However,=20 > implementers SHOULD also > > > be aware that some client software could be using UTF-8 [10] > > > character encoding. This specification does not=20 > require any support > > > for UTF-8. > > > > > >Given DNS experts' insistence that the DNS protocol does=20 > not place any > > >limits on character sets, it would be good to have a=20 > clearer pointer to > > >what recommendations are intended here. > > >Given that it's in section 3.3.1 (Deprecated ASCII=20 > encoding), one can > > >assume that this refers to a character set recommendation=20 > for characters=3D20 > > in > > >the ASCII encoding; a DNS encoded name should probably be=20 > used "as is", no > > >matter what it contains (although it would be good if the=20 > doc said so). > > > > > > > > >It's also unclear from the text whether or not there's a=20 > trailing dot on > > >the name in the deprecated ASCII encoding (there's no need=20 > for one, since=3D20 > > a > > >non-FQDN name can only be one component, but other fields=20 > of use have done > > >this in the past, so it's best to be clear that this field=20 > does not do =3D > > so). > >=20 > > On the point of character set recommendations, I think what=20 > you should be=3D20 > > pointing at is not 1034 and 1035 in general, but say that=20 > they SHOULD=3D20 > > follow the recommendation of RFC 1035 section 2.3.1. > > Since the rule was actually relaxed in RFC 1123 section=20 > 2.1, I think the=3D20 > > sentence should say "SHOULD follow the character set=20 > recommendation of RFC=3D20 > > 1035 section 2.3.1, as modified by RFC 1123 section 2.1". >=20 > RFC 1123 relaxed RFC 952 (and RFC 822 by implication) not > RFC 1035. It relaxed to *hostnames* not domain names. > Domain names were already general enough to support mapping > the expanded hostnames to domainnames using the null mapping. >=20 > The rest follows from that relaxation. RFC 1035 section > 2.3.1 is advisary based on the state of RFC 952 and RFC > 822 when it was written. >=20 > > That's not an UTF-8 issue, but is a charset issue. The=20 > UTF-8 text is a=3D20 > > cop-out (I think), but it's appropriate to cop-out here;=20 > you're basically=3D20 > > saying "don't be surprised if people don't do what this=20 > spec recommends". >=20 > For IDN's I would recommend using the output of ToASCII. > =20 > > Does this make sense now? > >=20 > > Harald > >=20 > >=20 > >=20 > > = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D26E6B02998774739D698=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > Content-Type: application/pgp-signature > > Content-Transfer-Encoding: 7bit > >=20 > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.2 (MingW32) > >=20 > > iD8DBQFD4pIMOMj+2+WY0F4RAvZIAJ0X6mjMkoIMa7z8MyFxFx1RwWB0uACg6DyN > > s8bXurZt6s6CWcvE9ELeS/A=3D > > =3DI6Vk > > -----END PGP SIGNATURE----- > >=20 > > = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D26E6B02998774739D698=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D-- > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 06 11:20:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6967-0002FB-Kc for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 11:20:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00610 for ; Mon, 6 Feb 2006 11:18:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F691n-000J7k-Vm for namedroppers-data@psg.com; Mon, 06 Feb 2006 16:15:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F691m-000J7X-SJ for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 16:15:47 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k16GFe2a027246 for ; Mon, 6 Feb 2006 11:15:40 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k16GFec1027245 for namedroppers@ops.ietf.org; Mon, 6 Feb 2006 11:15:40 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F59pA-000CTu-Lb for namedroppers@ops.ietf.org; Fri, 03 Feb 2006 22:54:40 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2006 14:54:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,85,1139212800"; d="scan'208"; a="21164947:sNHT24647460" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k13MsSPQ018098; Fri, 3 Feb 2006 17:54:36 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 17:54:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs) Date: Fri, 3 Feb 2006 17:54:30 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21012DC532@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs) Thread-Index: AcYolrTBXItwfUeMRxagqabhxd6t+gAekqmw From: "Bernie Volz \(volz\)" To: "Harald Tveit Alvestrand" , "Mark Andrews" Cc: "Olaf Kolkman" , , "dhcwg" , "Stig Venaas" , =?iso-8859-1?Q?=D3lafur_Gu=3Emundsson_/DNSEXT_co-chair?= , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 03 Feb 2006 22:54:31.0920 (UTC) FILETIME=[CBA34F00:01C62914] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Harald: Yes, your messages are going to the DHC WG mailing list. I guess the reference is very convoluted because RFC 1035 technically = references RFC 952, though not as explicitly as we might like. RFC 1035 = states (in section 2.3.1): The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. So, I'll change the text to what you suggested with one minor change: Clients and servers SHOULD follow the character-set rules of RFC 952, fourth section ("Assumptions"), first 5 sentences, as modified by RFC 1123 section 2.1. However, implementers SHOULD also be aware that some client software may send data intended to be in other character sets. This specification does not require support for other character sets. Note that I changed it to cover the 5 sentences because I believe the = additional sentences are required (lower case and space rules)? - Bernie > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: Friday, February 03, 2006 2:26 AM > To: Bernie Volz (volz); Mark Andrews > Cc: Olaf Kolkman; namedroppers@ops.ietf.org; dhcwg; Stig=20 > Venaas; =D3lafur Gu>mundsson /DNSEXT co-chair; Ralph Droms (rdroms) > Subject: RE: [dhcwg] Re: UTF-8 issues (Re: Open issues in=20 > DHCP FQDN,DHCID and DDNS-DHCP Related RFCs)=20 >=20 >=20 >=20 > --On 2. februar 2006 23:12 -0500 "Bernie Volz (volz)"=20 > =20 > wrote: >=20 > > Actually, I do now have a suggestion: > > > > Clients and servers SHOULD follow the character-set=20 > recommendations > > of RFC 1035 section 2.3.1. However, implementers SHOULD also > > be aware that some client software may use other character-sets. > > This specification does not require support for any other > > character-sets. > > > > If you don't like this, PLEASE SUGGEST ALTERNATIVE TEXT. >=20 > Bernie - are my messages not getting through to the DHCWG list? >=20 > I like this text, but you need to add the reference to RFC=20 > 1123 section 2.1=20 > I mentioned earlier (the text that allows 3com) - and Mark=20 > Andrews seems to=20 > want to reference RFC 952 rather than RFC 1035. >=20 > My suggestion (slight modification) would be: >=20 > > Clients and servers SHOULD follow the character-set=20 > recommendations > > of RFC 1035 section 2.3.1, as modified by RFC 1123 section 2.1. > > However, implementers SHOULD also > > be aware that some client software may send data intended to be > > in other character sets. > > This specification does not require support for any other > > character sets. >=20 > If referring to 952: >=20 > Clients and servers SHOULD follow the character-set rules=20 > of RFC 952, > fourth section, first 2 sentences, as modified by RFC 1123=20 > section 2.1. >=20 > However, implementers SHOULD also > be aware that some client software may send data intended to be in > other character sets. > This specification does not require support for any other > character sets. >=20 > That's specific... >=20 > Harald >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 06 11:21:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F696r-0002QD-Ty for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 11:21:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00685 for ; Mon, 6 Feb 2006 11:19:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6936-000JFw-8P for namedroppers-data@psg.com; Mon, 06 Feb 2006 16:17:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, X_PRIORITY_HIGH autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6934-000JFj-T4 for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 16:17:07 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k16GH1iT027331 for ; Mon, 6 Feb 2006 11:17:01 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k16GH1NW027330 for namedroppers@ops.ietf.org; Mon, 6 Feb 2006 11:17:01 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F67pr-000DCf-NN for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 14:59:23 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Feb 2006 06:59:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,92,1139212800"; d="scan'208"; a="21268345:sNHT24228576" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k16Ex6PY008649; Mon, 6 Feb 2006 09:59:18 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Feb 2006 09:59:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Mon, 6 Feb 2006 09:59:11 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21012DC765@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcYoQQBSPx16PpQ0EdqhogARJOT6egC6F3Yg X-Priority: 1 Importance: high From: "Bernie Volz \(volz\)" To: , "dhcwg" Cc: "Olaf Kolkman" , , "Stig Venaas" , =?iso-8859-1?Q?=D3lafur_Gu=3Emundsson_/DNSEXT_co-chair?= , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 06 Feb 2006 14:59:12.0588 (UTC) FILETIME=[E407D8C0:01C62B2D] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] As I'd like to re-submit these drafts as soon as possible, we need to = resolve >7. Add an 8-bit algorithm identifier to the DHCID RR to > support algorithm agility (Allison Mankin) >8. Use of MD5 as opposed to a stronger hash function (Sam Hartman, > Russ Housley) >9. Hash agility (Sam Hartman, Allison Mankin) >10. Russ's comment that an attacker that has some knowledge of MAC > addresses does not need to do lot of work. I think this can be > addressed in security considerations by saying this is not privacy > but just obfuscation (Russ Housley) Possible solutions to the hash algorithm issue are: 1. Switch from MD5 to SHA-1 or SHA-256 as the "base" algorithm. This = won't help down the road if these are found to have significant = weaknesses. 2. Add a field (octet) to the DHCID RR RDATA to specify the algorithm = used (perhaps using the digest type field and assignments used by the DS = record, RFC 3658, and http://www.iana.org/assignments/ds-rr-types). The = RDATA would thus be formatted as . This also means a change to SHA-1 as the = base algorithm or we'd need to request IANA to allocate a MD5 digest = code. (The SHA-1 digest is 20 octets instead of MD5's 16 octets.) 3. Incorporate the hash algorithm into the existing RR type code field, = which means a change of algorithm requires new RR type codes to be = assigned (likely 3 new codes per algorithm). 4. Don't change the RDATA format or algorithm. Though this would likely = block this work from proceeding through the IESG? Perhaps there's other solutions? I'm inclined to pick 2 as I believe it meets all of the IESG = requirements and is the most flexible. Whether we switch to SHA-1 or = request a digest type assignment for MD5 is debatable, but unless there = are significantly different export restrictions or licensing issues for = MD5 vs. SHA-1, let's just switch to SHA-1?=20 Comments please! - Bernie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From cb4@ach21.com Mon Feb 06 11:26:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F69Bo-0003RE-Cd for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 11:26:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01169 for ; Mon, 6 Feb 2006 11:24:14 -0500 (EST) Received: from 84-50-0-130-dsl.jhv.estpak.ee ([84.50.0.130] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F69Nl-0006Xm-L6 for dnsext-archive@ietf.org; Mon, 06 Feb 2006 11:38:32 -0500 Message-ID: <000001c62b63$a9f80c00$0100007f@localhost> From: "Robert Bryant" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Mon, 06 Feb 2006 18:25:34 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62B63.A9F80C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62B63.A9F80C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62B63.A9F80C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 47 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 31 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 44 reviews)

------=_NextPart_000_0001_01C62B63.A9F80C00-- From owner-namedroppers@ops.ietf.org Mon Feb 06 12:32:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6AED-00064s-MB for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 12:32:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06310 for ; Mon, 6 Feb 2006 12:30:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6AAc-000PYk-5H for namedroppers-data@psg.com; Mon, 06 Feb 2006 17:28:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6AAZ-000PYM-Cu for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 17:28:55 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id k16HSq2L009434; Mon, 6 Feb 2006 18:28:52 +0100 (MET) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id k16HSpK23505; Mon, 6 Feb 2006 18:28:51 +0100 (MET) Message-Id: <200602061728.k16HSpK23505@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org From: Peter Koch Subject: Re: the RD bit is troubling me today In-reply-to: Your message of "Mon, 06 Feb 2006 14:13:12 +0100." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 06 Feb 2006 18:28:51 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Paul Vixie writes: > > in that case, since the zone ends above the zonecut. A recursive server > > should respond with a non-AA answer in that case. But the non-AA answer > > should be first retrieved from the apex of the subzone, by following the > > delegation, all without allowing an RD=1 query to affect subsequent RD=0 > > results. A dual-use server would therefore have to maintain separate NS > > RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers. Algorithms 4.3.2 and 5.3.3 in RFC 1034 say that in the case RD=1 the query will be answered by local data. So, if a server is authoritative for the parent, but not for the child, a query would be satisfied from "local data", i.e. the NS RRSet that's present in the parent. The response won't be authoritative, but why should that matter? The problem seems to be that you won't be able to receive a signed response this way. But then, why would one ask for an NS RRSet in the first place (yeah, DynUpd, I know, but QTYPE SOA is better here anyway)? > Forbidding dual-use servers seem like a slightly unrealistic solution > to me, given deployed use. Without understanding what the actual > interoperability problems are (in contrast to implementation > problems), it seems that there is no justification for that solution. Agreed. "Don't" won't work. "Education" (quoting Olaf) will need to explain the (theoretical) problem and its practical relevance. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 06 14:30:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6C4U-0001Wy-MX for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 14:30:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15137 for ; Mon, 6 Feb 2006 14:29:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6C1i-0009EC-1Y for namedroppers-data@psg.com; Mon, 06 Feb 2006 19:27:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6C1h-0009DS-36 for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 19:27:53 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7214611425 for ; Mon, 6 Feb 2006 19:27:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: the RD bit is troubling me today In-Reply-To: Your message of "Mon, 06 Feb 2006 14:13:12 +0100." References: <20060204013717.6BD8111427@sa.vix.com> Date: Mon, 06 Feb 2006 19:27:52 +0000 Message-Id: <20060206192752.7214611425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk peter wrote: # Algorithms 4.3.2 and 5.3.3 in RFC 1034 say that in the case RD=1 the query # will be answered by local data. So, if a server is authoritative for the # parent, but not for the child, a query would be satisfied from "local data", # i.e. the NS RRSet that's present in the parent. that's an odd "i.e.", one i consider nonsequitur. 1034/1035 are at best unclear and at worst inconsistent and at least guideance-free on this point, as they were on some other dnssec-relevant definitions like ownership of data at delegation points, and the real meaning of wildcards. # The response won't be authoritative, but why should that matter? The problem # seems to be that you won't be able to receive a signed response this # way. But then, why would one ask for an NS RRSet in the first place (yeah, # DynUpd, I know, but QTYPE SOA is better here anyway)? what i want to know is, what's the right answer. the rest of 1034/1035, and common programmer-in-the-street intepretation, is that a non-empty response to an RD=1 query will contain data that came from the authority zone. we know (because dnssec required that we learn) that an authority-only server should not respond to queries for its out-of-zone glue. we know (again, from dnssec) that zone-bottom NS RRs are only authoritative in the child zone (where they would be apex NS RRs) and that an authority server should return delegations rather than answers when queried about them. what we don't know, and what i really do want to know now, is what the right answer is to an RD=1 query that matches a zone-bottom NS RRset. the answer to this will bear on how we handle future debates on the merits of wildcard NS RRsets, among other things. simon wrote: # This discussion is missing a crucial part: What happens when a # dual-server does not maintain a separate NS RRset for RD=0 and RD=1? that leads to the fallacy of the argument from utility. i didn't want to go there but see below. # In other words, I'm looking for the failure mode caused by this # problem. There are two cases two consider. The first case is when # the dual-use server always send the RD=0 answer, and the second case # where it always send the RD=1 answer. there are more than two cases. it can answer with one type of answer unless it has ever answered with the other type of answer; it can return SERVFAIL or an upward delegation; it can return inconsistent answers across a loadbalance set if some loadbalance members are also configured for recursion and others not. there are all kinds of undefined things that can happen -- that's why i called them "undefined" in my previous mail on this topic. # Forbidding dual-use servers seem like a slightly unrealistic solution # to me, given deployed use. Without understanding what the actual # interoperability problems are (in contrast to implementation # problems), it seems that there is no justification for that solution. rfc's have no power to forbid. however, they are looked at by folks who want to hold eachother to a standard when negotiating a contract, and they are even sometimes looked at by people who are wondering what the right thing to do would be, either out of curiousity or because they want to do the right thing. peter added: # Agreed. "Don't" won't work. "Education" (quoting Olaf) will need to explain # the (theoretical) problem and its practical relevance. i'm not really as interested in practical relevance as i am in nailing down the definition of the protocol so that we know what "the right answer" is, and under what conditions, and so on. but consider the case where the parent's zone-bottom delegation is wrong or out of date -- a VERY common case, as most of you know first hand. (and it's likely to remain the common case until the DNS protocol or a new protocol adds the ability for parent-zone delegation glue to be updated by child zone servers or child zone operators, and yes, i know this is being discussed in conjunction with the key rollover feature set, but that's not relevant here.) if the parent zone-bottom NS RRset and the child zone-apex NS RRset differ, then by definition, the parent is wrong. we know this because the parent's zozne-bottom NS RRset is called glue and is not authoritative for dnssec purposes; we know because other recursive/caching DNS protocol agents will prefer to cache the authority data from the child zone as "more credible", and we know it because it's the least-strenuous interpretation of 1034/1035's words on the topic. if the parent's zone-bottom NS RRset happens to be wrong, or for that matter, can be wrong or is known to be sometimes or often wrong, then we ought to be limiting the use of that data. it ought to be used not only as seldom as possible, but also, for as few purposes as possible. there is only one real purpose for it, and that's delegation. if it's so wrong that delegation won't work, then we're done, because the child's apex NS RRset will never be seen. if it's only partly wrong, such that some of the nameservers designated by the parent's zone-bottom NS RRset exist, some don't, some have had their names changed, and so on... but there is some "data path" through the bad data that does in fact lead to the right and proper and intended child zone, then we're not done, and we have to ask, what NS RRset should a dual-purpose server give out if asked for an NS RRset at its zone-bottom? the rule of least astonishment demands, in my interpretation, that if RD=1 and a response's answer section will be nonempty (that is, it's not a referral), the answer section contain only data that came, originally, from the authority zone. that would require the dual-purpose server recurse for names equalling a delegation point, just as they do for names below a delegation point. but such recursion should not change the content of referrals, or else an authority server will respond with a different below-zonecut referral after an equal-to- zonecut referral, than it did before the equal-to-zonecut referral. that way lies madness, from a conformance testing and interoperability testing and operational debugging standpoint. also it would still be inconsistent, even if no longer undefined. therefore let me repeat my previous observation. a dual-purpose server would have to maintain discrete NS RRset data for all zonecut nodes ("delegation points") in order to satisfy the other protocol invariants we know about. we all believe that this is overly burdensome. we can therefore recommend that no server be configured for both authority and recursive service. although i guess we can also define the proper behaviour so that those implementors who don't find it burdensome can just operate in the "right" way. let me show my colours for a moment. BIND4 taught me to hate dual-purpose servers, and there is no nameserver within reach of my keyboard that is configured that way, or is allowed to be configured that way. i find the whole idea of dual-purpose servers disturbing and repellent. this knowledge may help some of you to decide to ignore my tirade on the topic, but in the spirit of full disclosure, now you know where i'm coming from. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 06 14:44:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CHh-0005mM-O8 for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 14:44:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16248 for ; Mon, 6 Feb 2006 14:42:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CFj-000Aih-6I for namedroppers-data@psg.com; Mon, 06 Feb 2006 19:42:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CFi-000AiV-NS for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 19:42:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5399E11427 for ; Mon, 6 Feb 2006 19:42:22 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie to: namedroppers@ops.ietf.org Subject: Re: the RD bit is troubling me today In-Reply-To: Your message of "Mon, 06 Feb 2006 19:27:52 GMT." <20060206192752.7214611425@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> <20060206192752.7214611425@sa.vix.com> Date: Mon, 06 Feb 2006 19:42:22 +0000 Message-Id: <20060206194222.5399E11427@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i was curious so i googled. # that leads to the fallacy of the argument from utility. [...] has a writeup "COMPETING PRINCIPLES AND THE ARGUMENT FROM UTILITY" which talks about laws, constitutions, majorities, and supermajorities. highly apropos to our discussion about what the spec means vs. how it's been implemented. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 06 15:02:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CZ1-00018l-Or for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 15:02:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17434 for ; Mon, 6 Feb 2006 15:00:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CWe-000CjX-KB for namedroppers-data@psg.com; Mon, 06 Feb 2006 19:59:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CWb-000Cj9-8G for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 19:59:49 +0000 Received: (qmail 48914 invoked from network); 6 Feb 2006 20:52:21 -0000 Received: from softbank219001188003.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.3) by necom830.hpcl.titech.ac.jp with SMTP; 6 Feb 2006 20:52:21 -0000 Message-ID: <43E7AAE2.6050108@necom830.hpcl.titech.ac.jp> Date: Tue, 07 Feb 2006 05:00:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: "Bernie Volz (volz)" CC: Mark Andrews , Harald Tveit Alvestrand , Olaf Kolkman , namedroppers@ops.ietf.org, dhcwg , Stig Venaas , "Ralph Droms (rdroms)" Subject: Re: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs) References: <8E296595B6471A4689555D5D725EBB21012DC25E@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21012DC25E@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernie Volz (volz) wrote: > So, I think we want to drop or replace the LAST paragarph in section > 3.3.1 of draft-ietf-dhc-fqdn-option-11.txt. Sure. > Actually, I do now have a suggestion: > > Clients and servers SHOULD follow the character-set recommendations > of RFC 1035 section 2.3.1. However, implementers SHOULD also > be aware that some client software may use other character-sets. > This specification does not require support for any other > character-sets. > > If you don't like this, PLEASE SUGGEST ALTERNATIVE TEXT. We should also give reference to section 2.3.3. We don't have to say anything about "character-sets". So, the text could be: > Clients and servers SHOULD follow the character-set recommendations > of RFC 1035 section 2.3.1. However, implementers SHOULD also > be aware that some client software may "use the full binary octet > capabilities in names" as described in section 2.3.3 of RFC1035. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 06 22:32:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Jar-0004VY-Kj for dnsext-archive@megatron.ietf.org; Mon, 06 Feb 2006 22:32:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11309 for ; Mon, 6 Feb 2006 22:30:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6JUe-000Ozv-Q7 for namedroppers-data@psg.com; Tue, 07 Feb 2006 03:26:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6JUd-000Ozg-Rb for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 03:26:16 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k173euan028328 for ; Mon, 6 Feb 2006 20:40:56 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k173cJRd009372 for ; Mon, 6 Feb 2006 21:38:20 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Feb 2006 22:26:13 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810C9A26EF@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: FW: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SH A)' to Informational RFC Date: Mon, 6 Feb 2006 22:26:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This draft with SHA-256, etc., code, which is now referenced by more than one draft in DNSEXT, has been approved as Informational. Donald -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, February 06, 2006 5:05 PM To: IETF-Announce Cc: Internet Architecture Board; RFC Editor Subject: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)' to Informational RFC The IESG has approved the following document: - 'US Secure Hash Algorithms (SHA and HMAC-SHA) ' as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-sha2-02.txt Technical Summary NIST has adopted a suite of secure hash algorithms as part of a Federal Information Processing Standard (FIPS) 180-2: SHA-224, SHA-256, SHA-384, and SHA-512. The purpose of this document is to make open source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. Also, the SHA-1 (from FIPS 180-1) sample code from RFC 3174 has also been updated to handle an input string of arbitrary length. Code to perform SHA-based HMACs is also included. Most of the text in the document was adapted by the authors from FIPS 180-2. Working Group Summary This is an Individual submission. No IETF Working Group was involved. Protocol Quality This document was reviewed by Russ Housley for the IESG. Note to the RFC Editor To resolve the concerns with the term "open source", please make the following changes: In the Abstract: OLD: The purpose of this document is to make open source code performing these hash functions conveniently available to the Internet community. NEW: The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. In Section 10: OLD: This document is intended to provide convenient open source access by the Internet community to the United States of America Federal Information Processing Standard Secure Hash Algorithms (SHAs) [FIPS 180-2] and HMACs based thereon. NEW: This document provides the Internet community convenient access to source code that implements the United States of America Federal Information Processing Standard Secure Hash Algorithms (SHAs) [FIPS 180-2] and HMACs based upon these one-way hash functions. See license in Section 1.1. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 07 09:47:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6U7V-0003yH-OH for dnsext-archive@megatron.ietf.org; Tue, 07 Feb 2006 09:47:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00828 for ; Tue, 7 Feb 2006 09:45:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6U3Y-000Mh1-Aa for namedroppers-data@psg.com; Tue, 07 Feb 2006 14:43:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, HTML_MESSAGE autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6U3U-000MgX-WA for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 14:42:57 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k17Egn8D038908 for ; Tue, 7 Feb 2006 09:42:50 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k17EgndA038907 for namedroppers@ops.ietf.org; Tue, 7 Feb 2006 09:42:49 -0500 (EST) (envelope-from namedroppers) Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6EKx-000Moq-NZ for namedroppers@ops.ietf.org; Mon, 06 Feb 2006 21:55:55 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Feb 2006 13:55:55 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 13:54:35 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 13:54:35 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 13:54:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62B67.EB1EC8E2" Subject: Re: DNSEXT Document Review: LLMNR-45 Date: Mon, 6 Feb 2006 13:54:32 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1158BD267@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Re: DNSEXT Document Review: LLMNR-45 Thread-Index: AcYrZ+mFYaBQ6bQaSCKhGdbC9XWJlg== From: "Dave Thaler" To: X-OriginalArrivalTime: 06 Feb 2006 21:54:35.0543 (UTC) FILETIME=[EB44FA70:01C62B67] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This is a multi-part message in MIME format. ------_=_NextPart_001_01C62B67.EB1EC8E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that issue #1 is out of scope for the LLMNR spec. On issue 2: > (2) Security concerns have been raised about the fact that > applications on hosts that implement LLMNR will not be able to tell > if a response has come from the DNS or from a local lookup. Tony Finch wrote: > What changes should be made to RFC 3493 as a consequence of LLMNR? Stephane Bortzmeyer wrote: > I regard issue 2, above, as a non-issue: other name resolution > Techniques like /etc/hosts or LDAP have the same behavior and nobody > complained that getnameinfo() cannot tell you from which service you > got the IP address. >=20 > May be just a small addition in Security Considerations: >=20 > Implementations should [lowercase, not RFC 2119] allow the system > administrator to disable completely the use of LLMNR [like what you > can do with a typical /etc/host.conf or equivalent]. Eric Hall wrote: > This is a feature not a bug. [That is, if multiple ~standardized naming > services are going to be ~supported, then application interoperability > between them would be a feature. I mean, NIS and NetBIOS names (and > /etc/hosts too) can be used by applications without needing to understand > the actual resolution service and providing similar functionality here > would be a competitive feature.] Re issue #2, I agree with Stephane and Eric. There is nothing in RFC 3493 which needs to change as a result of LLMNR specifically. The same security concerns are independent of the protocol. If anything in RFC 3493 were to change in the future, I would suggest that the addrinfo structs returned be able to include information about any important characteristics of the=20 results, and those characteristics be protocol independent. For example, "whether it was obtained securely or not" might be interesting, which in DNS might mean whether they were DNSSec protected, or whatever. This would be a much better way to address the concerns, and it is out of scope for LLMNR in my view, but in scope for the WG (under the debatable assumption=20 that APIs are in scope in the IETF in the first place). On issue #3, I am fine with draft -45 for the same reasons as above. -Dave ------_=_NextPart_001_01C62B67.EB1EC8E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: DNSEXT Document Review: LLMNR-45

I agree that issue = #1 is out of scope for the = LLMNR spec.

On issue 2:

> (2) Security concerns have been raised about the fact = that

> applications on hosts that implement LLMNR will not be able to = tell

> if a response has come from the DNS or from a local = lookup.

Tony Finch wrote:

> What changes should be made to RFC 3493 as a = consequence of LLMNR?

Stephane Bortzmeyer wrote:

> I regard issue 2, above, as a non-issue: = other name = resolution

> Techniques like = /etc/hosts or LDAP have the same behavior and nobody

> complained that getnameinfo() cannot tell you from = which service you

> got the IP address.

>

> May be just a small addition in Security = Considerations:

>

> Implementations should [lowercase, not RFC 2119] allow the = system

> administrator to disable completely the use of = LLMNR [like what you

> can do with a typical /etc/host.conf or = equivalent].

Eric Hall wrote:

> This is a feature not a bug. [That is, if multiple = ~~standardized naming

> services are going to be ~supported, then application = interoperability

> between them would be a feature. I mean, NIS and = NetBIOS names (and

> /etc/hosts too) can be used by applications without = needing to understand

> the actual resolution service and providing similar = functionality here

> would be a competitive feature.]

Re issue #2, I agree with Stephane and Eric.  There is nothing in RFC 3493

which needs to change as a result of LLMNR = specifically.  The same = security

concerns are independent of the protocol.  If anything in RFC 3493 were to

change in the future, I would = suggest that the addrinfo = structs returned be

able to include information about = any important characteristics of = the

results, and those characteristics = be protocol independent.  For example,

“whether it was obtained = securely or = not” might be interesting, which in =

DNS might mean whether they were DNSSec protected, or = whatever.  This would

be a much better way to address the concerns, = and it is out of scope = for

LLMNR in my view, but in scope for the WG (under the debatable assumption

that APIs are in scope in the IETF in the first = place).

On issue #3, I am fine with draft -45 for the = same reasons as above.

-Dave

------_=_NextPart_001_01C62B67.EB1EC8E2-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 07 09:47:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6U7V-0003yG-C3 for dnsext-archive@megatron.ietf.org; Tue, 07 Feb 2006 09:47:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00827 for ; Tue, 7 Feb 2006 09:45:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6U41-000Mkp-6t for namedroppers-data@psg.com; Tue, 07 Feb 2006 14:43:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6U40-000Mkc-BL for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 14:43:28 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k17EhMs6038914 for ; Tue, 7 Feb 2006 09:43:22 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k17EhL8M038913 for namedroppers@ops.ietf.org; Tue, 7 Feb 2006 09:43:22 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6ItW-000MBN-0G for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 02:47:54 +0000 Received: from [10.10.10.138] (207-114-177-82.vtc.net [207.114.177.82]) by toccata.fugue.com (Postfix) with ESMTP id 3BBB01B202D; Mon, 6 Feb 2006 19:47:53 -0700 (MST) From: Ted Lemon Organization: Diamond Mountain To: dhcwg@ietf.org Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Mon, 6 Feb 2006 19:47:50 -0700 User-Agent: KMail/1.8.3 Cc: "Bernie Volz (volz)" , namedroppers@ops.ietf.org, Olaf Kolkman , Harald@alvestrand.no, Stig Venaas , ogud@ogud.com, "Ralph Droms (rdroms)" References: <8E296595B6471A4689555D5D725EBB21012DC765@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21012DC765@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602061947.51052.mellon@fugue.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Monday 06 February 2006 07:59, Bernie Volz (volz) wrote: > Perhaps there's other solutions? My vote would be to take out the hash entirely - it was unnecessary to begin with, and the idea of radically complexifying the protocol to make it more secure when there was no real need for it in the first place strikes me as a huge and painful mistake. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 07 17:27:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6bJ2-0002ON-U7 for dnsext-archive@megatron.ietf.org; Tue, 07 Feb 2006 17:27:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07475 for ; Tue, 7 Feb 2006 17:25:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6bE3-000N59-QQ for namedroppers-data@psg.com; Tue, 07 Feb 2006 22:22:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6bE1-000N4t-6W for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 22:22:17 +0000 Received: from [10.31.32.190] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k17MM5l8042055; Tue, 7 Feb 2006 17:22:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060204013717.6BD8111427@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> Date: Tue, 7 Feb 2006 17:21:58 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: the RD bit is troubling me today Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think that... A DNS server is always supposed to answer a query with the best available data, with best being defined as most trustworthy. (I have been using "credible" for a while by mistake, I should have been saying "trustworthy.") BTW, It sounds like there is a small problem with RFC 2181, 5.4.1. Where "glue" is mentioned, it should be "glue and zone cut [NS Set]" data. What this means is that no matter what the setting of the RD is the server ought to answer with the learned NS set over the authoritative NS set when the learned set is more trustworthy. (Applying to the case where the QNAME is a zone cut, etc.) It's tempting to make (a) DNS (server) be able to answer with the authoritative data when RD=0 and the learned data when RD=1, but I'd say this is a "siren's call." 1) Wanting to know the authoritative data in this case is something only a maintainer or reverse engineer would want to do. (I.e., it's unusual.) 2) It's more work that just meeting the mission of a simple lookup service. I.e., Complicates the code (to achieve the unusual case). 3) Let's keep the design such that servers are as aggressive as possible in returning the final result quickly. (No one likes a slow librarian.) As far as clarification ... to me this is pretty clear. However, I won't say "don't clarify this" because clarity is in the eye of the beholder and clarity doesn't mean "right." (Ignorance is bliss and all that.) I'm no longer against mixing caching and authoritative servers. I think that the reasons once used to justify separating the two have largely vanished. I think that there are now valid reasons to combine them into one (at times). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 07 17:37:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6bSy-00078Y-9D for dnsext-archive@megatron.ietf.org; Tue, 07 Feb 2006 17:37:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08110 for ; Tue, 7 Feb 2006 17:35:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6bR2-000O8m-Ln for namedroppers-data@psg.com; Tue, 07 Feb 2006 22:35:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6bR1-000O8a-Mh for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 22:35:43 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56956259746; Tue, 7 Feb 2006 23:34:25 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22711-07; Tue, 7 Feb 2006 23:34:21 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9535259744; Tue, 7 Feb 2006 23:34:20 +0100 (CET) Date: Tue, 07 Feb 2006 23:35:37 +0100 From: Harald Tveit Alvestrand To: "Bernie Volz (volz)" , Ted Lemon , dhcwg@ietf.org Cc: namedroppers@ops.ietf.org, Olaf Kolkman , Stig Venaas , ogud@ogud.com, "Ralph Droms (rdroms)" Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Message-ID: <042E94136CB0AFDDA8644C74@svartdal.hjemme.alvestrand.no> In-Reply-To: <8E296595B6471A4689555D5D725EBB21013400FF@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21013400FF@xmb-rtp-20a.amer.cisco .com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On tirsdag, februar 07, 2006 17:28:54 -0500 "Bernie Volz (volz)" wrote: > Well, that certainly would be an easy solution (in terms of changes to > the draft and also the conflict resolution draft). But, do how practical > is this? How likely is the IESG to accept this? (speaking as DHCP-head, not security-head) would removing the hash entirely increase the probability of confusion over "who does what"? I thought it had a differentiation function too.... Harald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 07 20:52:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6eVS-0007O1-Lk for dnsext-archive@megatron.ietf.org; Tue, 07 Feb 2006 20:52:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00057 for ; Tue, 7 Feb 2006 20:50:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6eSk-000C57-GT for namedroppers-data@psg.com; Wed, 08 Feb 2006 01:49:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS,SPF_PASS autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6eSj-000C4w-P6 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 01:49:41 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 0ACC85689E; Tue, 7 Feb 2006 17:49:41 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Tue, 7 Feb 2006 18:49:36 -0700 User-Agent: KMail/1.8.3 Cc: "Bernie Volz (volz)" , "David W. Hankins" , Olaf Kolkman , namedroppers@ops.ietf.org, Harald@alvestrand.no, Stig Venaas , ogud@ogud.com, "Ralph Droms (rdroms)" References: <8E296595B6471A4689555D5D725EBB210134016C@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210134016C@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602071849.37429.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 07 February 2006 18:04, Bernie Volz (volz) wrote: > I also don't recall the history (because I either wasn't involved or was > fairly disinterested at the time) the reason for encoding this, but suspect > it was to make it somewhat difficult for someone to find the client's > identity and potentially track the user through the Internet as they > connect to different access networks (assuming the DHCID RR was available). > I don't believe the goal was ever to make it impossible, just somewhat > difficult so that most folks wouldn't bother. The original motivation for using MD5 was to protect the privacy of the client by not publishing its client identifier (typically the MAC address of the ethernet card) in the DNS. But we're already publishing the client's identity in the DNS in the form of the hostname it sends to the server. So someone who is determined to track this client's motion across the network can do so by tracking its A record. We should bear in mind that while MD5 isn't terribly secure, it's not completely insecure either. In practice, the case where somebody's privacy is going to be violated in this way is where someone is doing data mining, and wants to be able to combine data mined about one host with data mined about another host that happens to be the same host. It's going to be much easier to do this with the hostname than to reverse-engineer the MD5 hash. It's easier still to use the client identifier, if that's stored in the DNS, so there is some limited value in doing *something* to increase the cost of matching two identifiers, but the value of that really is quite limited. So the problem I see here is that we want to do some obfuscation that is of extremely limited value. And in order to "do it right," we need to add extra steps to the DNS registration protocol to account for different possible hash algorithms that might be used for obfuscation. So if the choice is between doing it right and not doing it at all, I'm 100% behind not doing it at all. However, if the IESG is willing to accept a single algorithm, in hopes that it will provide enough obfuscatory value that statistical analysis based on the hostname portion of the client's FQDN is cheaper, I don't object to that. It's only the additional complexification required to "do it right" to which I object, because I don't think it adds any value. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 07 22:36:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6g82-00073E-7g for dnsext-archive@megatron.ietf.org; Tue, 07 Feb 2006 22:36:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08769 for ; Tue, 7 Feb 2006 22:34:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6g5M-000JrN-AN for namedroppers-data@psg.com; Wed, 08 Feb 2006 03:33:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6g5L-000Jr9-I6 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 03:33:39 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0699D11426 for ; Wed, 8 Feb 2006 03:33:39 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: the RD bit is troubling me today In-Reply-To: Your message of "Tue, 07 Feb 2006 17:21:58 EST." References: <20060204013717.6BD8111427@sa.vix.com> Date: Wed, 08 Feb 2006 03:33:38 +0000 Message-Id: <20060208033339.0699D11426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # ... # What this means is that no matter what the setting of the RD is the server # ought to answer with the learned NS set over the authoritative NS set when # the learned set is more trustworthy. (Applying to the case where the QNAME # is a zone cut, etc.) i disagree with this interpretation in two ways. first, an authority server doesn't send answers when asked for non-apex NS, it sends a referral. that is, if you ask the COM-zone servers for VIX.COM NS, you should get back a response with an empty answer section and a non-empty authority section. second, an authority server should not, in general, fetch any glue or otherwise send any packets to anybody, and especially, it should never answer differently unless its own authority zone data has been made different. # It's tempting to make (a) DNS (server) be able to answer with the # authoritative data when RD=0 and the learned data when RD=1, but I'd say # this is a "siren's call." i'm not tempted by any sirens here. i just want to know what the right thing is, so that i can do it, and complain if/when others don't, and test for it in conformance suites, and so on. none of that is possible while this case remains undefined. # I'm no longer against mixing caching and authoritative servers. I think # that the reasons once used to justify separating the two have largely # vanished. I think that there are now valid reasons to combine them into # one (at times). i think i've pointed out a case where a server's answer not defined by the spec, where authority and recursion are done on the same IP/UDP listener address. since undefined is not what we usually want in a spec, and isn't what folks think this spec offers, i'm calling that a problem. we can decide that it's not really undefined, or that it's always been undefined and everybody knew it but me and i'm chasing parked cars again, or that it's not defined but the operational cost is low so we'll just document it as undefined, or we can say that it's undefined and should become defined, or we can say that it's undefined and therefore not a recommended practice. our chairs will have to take the lead on determining which way we want to go. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:15:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ibf-0006l8-6q for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:15:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18696 for ; Wed, 8 Feb 2006 01:13:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iYo-0005WB-Q7 for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:12:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iYn-0005Vw-Py for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:12:14 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186C3L0044349 for ; Wed, 8 Feb 2006 01:12:03 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186C3Fi044348 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:12:03 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6bWP-000Oej-Am for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 22:41:17 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2006 17:41:17 -0500 X-IronPort-AV: i="4.02,95,1139202000"; d="scan'208"; a="81904976:sNHT32103480" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k17Mf5PQ007728; Tue, 7 Feb 2006 17:41:09 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Feb 2006 17:41:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Tue, 7 Feb 2006 17:41:04 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2101340106@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcYsNtyqADW11I0/QrCTjtpK7q7B9QAAIyFw From: "Bernie Volz \(volz\)" To: "Harald Tveit Alvestrand" , "Ted Lemon" , Cc: , "Olaf Kolkman" , "Stig Venaas" , , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 07 Feb 2006 22:41:05.0171 (UTC) FILETIME=[946E2E30:01C62C37] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Harald: No, this would just mean that the client identity would be stored in raw octet form instead of "encrypting" the data. It would have no impact on anything else that I can see. - Bernie > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: Tuesday, February 07, 2006 5:36 PM > To: Bernie Volz (volz); Ted Lemon; dhcwg@ietf.org > Cc: namedroppers@ops.ietf.org; Olaf Kolkman; Stig Venaas;=20 > ogud@ogud.com; Ralph Droms (rdroms) > Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and=20 > DDNS-DHCP Related RFCs >=20 >=20 >=20 > --On tirsdag, februar 07, 2006 17:28:54 -0500 "Bernie Volz (volz)"=20 > wrote: >=20 > > Well, that certainly would be an easy solution (in terms of=20 > changes to > > the draft and also the conflict resolution draft). But, do=20 > how practical > > is this? How likely is the IESG to accept this? >=20 > (speaking as DHCP-head, not security-head) >=20 > would removing the hash entirely increase the probability of=20 > confusion over=20 > "who does what"? > I thought it had a differentiation function too.... >=20 > Harald >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:15:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ibg-0006lT-A3 for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:15:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18701 for ; Wed, 8 Feb 2006 01:13:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iZ7-0005X8-Fg for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:12:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iZ6-0005Ww-DL for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:12:33 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186CMoP044355 for ; Wed, 8 Feb 2006 01:12:22 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186CMMZ044354 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:12:22 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6bvH-0000WI-D3 for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 23:06:59 +0000 Received: from abhaya.fugue.com (lam.fugue.com [66.93.162.226]) by toccata.fugue.com (Postfix) with ESMTP id A43C01B206E; Tue, 7 Feb 2006 16:06:54 -0700 (MST) From: Ted Lemon Organization: Diamond Mountain To: "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Tue, 7 Feb 2006 16:06:52 -0700 User-Agent: KMail/1.8.3 Cc: "Harald Tveit Alvestrand" , dhcwg@ietf.org, namedroppers@ops.ietf.org, "Olaf Kolkman" , "Stig Venaas" , ogud@ogud.com, "Ralph Droms \(rdroms\)" References: <8E296595B6471A4689555D5D725EBB2101340106@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB2101340106@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602071606.53067.mellon@fugue.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Tuesday 07 February 2006 15:41, Bernie Volz (volz) wrote: > No, this would just mean that the client identity would be stored in raw > octet form instead of "encrypting" the data. It would have no impact on > anything else that I can see. Essentially, the concern is that you'd be publishing a stable token identifying a specific client in the DNS. My counterargument to this concern is that the client's hostname is also a stable token identifying the client. If you are concerned about privacy, you shouldn't be publishing _any_ tokens that identify the client in the DNS. If you are not concerned about privacy, in the sense that for some reason you consider the value of putting your client's contact information into a public registry (the DNS) more important than keeping your client's identity private, then the fact that you are publishing two tokens in the DNS (the DUID and the hostname) that identify your client isn't a problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:15:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ibj-0006lg-K4 for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:15:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18704 for ; Wed, 8 Feb 2006 01:13:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iaQ-0005gy-O3 for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:13:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iaP-0005gK-KY for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:13:54 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186Dhbx044382 for ; Wed, 8 Feb 2006 01:13:43 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186Dhgv044381 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:13:43 -0500 (EST) (envelope-from namedroppers) Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6gf5-000MmJ-79 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 04:10:35 +0000 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EE518E0053; Tue, 7 Feb 2006 23:10:29 -0500 (EST) To: "Bernie Volz (volz)" Cc: "Ted Lemon" , , , Olaf Kolkman , "David W. Hankins" , Harald@alvestrand.no, namedroppers@ops.ietf.org, Stig Venaas , ogud@ogud.com, "Ralph Droms (rdroms)" Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs References: <8E296595B6471A4689555D5D725EBB2101340174@xmb-rtp-20a.amer.cisco.com> From: Sam Hartman Date: Tue, 07 Feb 2006 23:10:29 -0500 In-Reply-To: <8E296595B6471A4689555D5D725EBB2101340174@xmb-rtp-20a.amer.cisco.com> (Bernie Volz's message of "Tue, 7 Feb 2006 20:53:52 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] I think the main think I at least am asking for is multiple algorithms. Russ is asking for some analysis based on comments from Steve Bellovin. I think we may need to spend some time on this--either in Dallas or a conference call to make any progress. I think the primary issue in my mind is whether this mechanism works at all. Once you figure out a client identifier you can test whether a particular lease is a particular client. So, while I may not be able to easily track everyone, this supports targeted tracking fairly easily. I don't see a way around that without having shared secrets known by the DHCP servers. I'm not saying that we should mandate that or perhaps even that we should support it. But I'm becoming even more convinced that Steve Bellovin is right and that we need to understand what problem we're solving here. I do still feel strongly about the multiple algorithms issue. However I don't think I'm going to be in a position to understand and appreciate arguments on that issue until we have a discussion about what we're trying to accomplish and about what the mechanisms are. The one argument I explicitly do not accept is the deployed base argument. This is a new option that is first before the IETF and has first received cross-area review now. RR types have not even been assigned. I'm sorry the process has taken a long time. The right fix for that is to work on process efficiency; I think we are all trying to do that. I know the DHCP working group has improved a lot recently and I believe the IESG has as well. --Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:15:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ibk-0006ls-2M for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:15:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18707 for ; Wed, 8 Feb 2006 01:13:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iYV-0005Uo-5d for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:11:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iYU-0005UQ-0o for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:11:54 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186BgfL044343 for ; Wed, 8 Feb 2006 01:11:42 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186BgBJ044342 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:11:42 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6bKh-000NdL-Te for namedroppers@ops.ietf.org; Tue, 07 Feb 2006 22:29:11 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2006 17:29:11 -0500 X-IronPort-AV: i="4.02,95,1139202000"; d="scan'208"; a="81904147:sNHT32434452" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k17MSw6N019919; Tue, 7 Feb 2006 17:29:07 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Feb 2006 17:28:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Tue, 7 Feb 2006 17:28:54 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21013400FF@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcYrkOg+3BmLDhdhRoW1K3zF3PeAVQApNoEA From: "Bernie Volz \(volz\)" To: "Ted Lemon" , Cc: , "Olaf Kolkman" , , "Stig Venaas" , , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 07 Feb 2006 22:28:57.0682 (UTC) FILETIME=[E2D02B20:01C62C35] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Well, that certainly would be an easy solution (in terms of changes to the draft and also the conflict resolution draft). But, do how practical is this? How likely is the IESG to accept this? - Bernie=20 > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com]=20 > Sent: Monday, February 06, 2006 9:48 PM > To: dhcwg@ietf.org > Cc: Bernie Volz (volz); namedroppers@ops.ietf.org; Olaf=20 > Kolkman; Harald@alvestrand.no; Stig Venaas; ogud@ogud.com;=20 > Ralph Droms (rdroms) > Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and=20 > DDNS-DHCP Related RFCs >=20 > On Monday 06 February 2006 07:59, Bernie Volz (volz) wrote: > > Perhaps there's other solutions? >=20 > My vote would be to take out the hash entirely - it was=20 > unnecessary to begin=20 > with, and the idea of radically complexifying the protocol to=20 > make it more=20 > secure when there was no real need for it in the first place=20 > strikes me as a=20 > huge and painful mistake. >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:15:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ibf-0006l9-6s for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:15:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18697 for ; Wed, 8 Feb 2006 01:13:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iZT-0005Zu-P8 for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:12:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iZS-0005Zf-Ki for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:12:55 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186ChMO044361 for ; Wed, 8 Feb 2006 01:12:43 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186ChDY044360 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:12:43 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.187.72] (helo=kaboom.isc.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6dEt-0006UX-O6 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 00:31:19 +0000 Received: by kaboom.isc.org (Postfix, from userid 10200) id EDF4F8A31E; Tue, 7 Feb 2006 16:31:18 -0800 (PST) Date: Tue, 7 Feb 2006 16:31:18 -0800 From: "David W. Hankins" To: "Bernie Volz (volz)" Cc: namedroppers@ops.ietf.org, dhcwg , Olaf Kolkman , Harald@Alvestrand.no, Stig Venaas , =?iso-8859-1?Q?=D3lafur_Gu=3Emundsson?= /DNSEXT co-chair , "Ralph Droms (rdroms)" Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Message-ID: <20060208003118.GL23573@isc.org> References: <8E296595B6471A4689555D5D725EBB21012DC765@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2NLGdgz3UMHa/lqP" Content-Disposition: inline In-Reply-To: <8E296595B6471A4689555D5D725EBB21012DC765@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.9i X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] --2NLGdgz3UMHa/lqP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 06, 2006 at 09:59:11AM -0500, Bernie Volz (volz) wrote: > Possible solutions to the hash algorithm issue are: >=20 > 1. Switch from MD5 to SHA-1 or SHA-256 as the "base" algorithm. This won'= t help down the road if these are found to have significant weaknesses. >=20 > 2. Add a field (octet) to the DHCID RR RDATA to specify the algorithm use= d (perhaps using the digest type field and assignments used by the DS recor= d, RFC 3658, and http://www.iana.org/assignments/ds-rr-types). The RDATA wo= uld thus be formatted as . This also means a change to SHA-1 as the base algorithm or we= 'd need to request IANA to allocate a MD5 digest code. (The SHA-1 digest is= 20 octets instead of MD5's 16 octets.) >=20 > 3. Incorporate the hash algorithm into the existing RR type code field, w= hich means a change of algorithm requires new RR type codes to be assigned = (likely 3 new codes per algorithm). >=20 > 4. Don't change the RDATA format or algorithm. Though this would likely b= lock this work from proceeding through the IESG? >=20 > Perhaps there's other solutions? >=20 > I'm inclined to pick 2 as I believe it meets all of the IESG requirements= and is the most flexible. Whether we switch to SHA-1 or request a digest t= ype assignment for MD5 is debatable, but unless there are significantly dif= ferent export restrictions or licensing issues for MD5 vs. SHA-1, let's jus= t switch to SHA-1?=20 Funny, I was going to say '2 is right out'. I don't like the implications of people trying to be reverse-algorithm compatible, or the fact that there's no way to roll between algorithms except all-stop, delete, restart. There's a contradiction in Ted's and Bernie's statements here I want to point out. Bernie says if SHA-X is found weak, that's a problem. Ted says we can just remove the encoding. One of these two statements has to be false if the other is true. If we can remove the encoding, then we don't care if SHA-X is weak. If we care if SHA-X is weak, then we can't remove the encoding. Obviously I agree with Ted, I think the encoding is more political problem than technical reward. In that case, there's no reason to care if SHA-x is weak because the alternative was cleartext. So why not just go with door #1 if that makes the IESG happy? One of my coworkers (who, wishing not to be named "bad idea fairy" will for the moment be kept anonymous) suggests we adopt ROT13. Actually, some zone admins might be able to read that without a filter, so perhaps we should just XOR the field by 0xFF. If cleartext is an acceptable answer, which I think it is, than any obfuscation that makes plaintext unreadable is equivalent, even if that equivalent obfuscation is a *different* weak digest algorithm. MD5 was the right answer. There's no other way to say it. So in my final analysis, if switching to SHA-1 or SHA-256 gets it past IESG, I think that's better than ROT13 or XOR 0xFF, which I think is better than removing the encoding entirely, which I think is better than switching to an encoding byte, which I think is better than making the encoding part of the type field. But really, the success story here would be if we made no changes and just stuck with MD5. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --2NLGdgz3UMHa/lqP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD6TvWcXeLeWu2vmoRAgBxAJ9NIOHDfcEKab3mTYVuwAY+1kZgKgCgpYL3 HsDsLuAaia2w5zGrMgC7y64= =LGGa -----END PGP SIGNATURE----- --2NLGdgz3UMHa/lqP-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:15:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ibo-0006nu-PG for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:15:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18713 for ; Wed, 8 Feb 2006 01:13:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6ia7-0005bz-DG for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:13:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6ia6-0005bS-1N for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:13:34 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186DNUJ044374 for ; Wed, 8 Feb 2006 01:13:23 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186DNQl044373 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:13:23 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6eWv-000CQZ-Il for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 01:54:01 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2006 17:54:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,96,1139212800"; d="scan'208"; a="21399193:sNHT26872376" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k181rq6J024031; Tue, 7 Feb 2006 20:53:54 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Feb 2006 20:53:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Tue, 7 Feb 2006 20:53:52 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2101340174@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcYsUe778ij2PKxKTIaU+SSg8H/meAAAFpIA From: "Bernie Volz \(volz\)" To: "Ted Lemon" , , Cc: "David W. Hankins" , "Olaf Kolkman" , , , "Stig Venaas" , , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 08 Feb 2006 01:53:54.0386 (UTC) FILETIME=[84384B20:01C62C52] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Well, let's ask the IESG (added to TO:) ... > However, if the IESG is willing to accept a single algorithm, in hopes that it=20 > will provide enough obfuscatory value that statistical analysis based on the=20 > hostname portion of the client's FQDN is cheaper, I don't object to that. =20 > It's only the additional complexification required to "do it right" to which=20 > I object, because I don't think it adds any value. - Bernie > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Tuesday, February 07, 2006 8:50 PM > To: dhcwg@ietf.org > Cc: Bernie Volz (volz); David W. Hankins; Olaf Kolkman;=20 > namedroppers@ops.ietf.org; Harald@alvestrand.no; Stig Venaas;=20 > ogud@ogud.com; Ralph Droms (rdroms) > Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and=20 > DDNS-DHCP Related RFCs >=20 > On Tuesday 07 February 2006 18:04, Bernie Volz (volz) wrote: > > I also don't recall the history (because I either wasn't=20 > involved or was > > fairly disinterested at the time) the reason for encoding=20 > this, but suspect > > it was to make it somewhat difficult for someone to find=20 > the client's > > identity and potentially track the user through the Internet as they > > connect to different access networks (assuming the DHCID RR=20 > was available). > > I don't believe the goal was ever to make it impossible,=20 > just somewhat > > difficult so that most folks wouldn't bother. >=20 > The original motivation for using MD5 was to protect the=20 > privacy of the client=20 > by not publishing its client identifier (typically the MAC=20 > address of the=20 > ethernet card) in the DNS. But we're already publishing the=20 > client's=20 > identity in the DNS in the form of the hostname it sends to=20 > the server. >=20 > So someone who is determined to track this client's motion=20 > across the network=20 > can do so by tracking its A record. >=20 > We should bear in mind that while MD5 isn't terribly secure, it's not=20 > completely insecure either. In practice, the case where=20 > somebody's privacy=20 > is going to be violated in this way is where someone is doing=20 > data mining,=20 > and wants to be able to combine data mined about one host=20 > with data mined=20 > about another host that happens to be the same host. It's=20 > going to be much=20 > easier to do this with the hostname than to reverse-engineer=20 > the MD5 hash. =20 > It's easier still to use the client identifier, if that's=20 > stored in the DNS,=20 > so there is some limited value in doing *something* to=20 > increase the cost of=20 > matching two identifiers, but the value of that really is=20 > quite limited. >=20 > So the problem I see here is that we want to do some=20 > obfuscation that is of=20 > extremely limited value. And in order to "do it right," we=20 > need to add=20 > extra steps to the DNS registration protocol to account for different=20 > possible hash algorithms that might be used for obfuscation. =20 > So if the=20 > choice is between doing it right and not doing it at all, I'm=20 > 100% behind not=20 > doing it at all. >=20 > However, if the IESG is willing to accept a single algorithm,=20 > in hopes that it=20 > will provide enough obfuscatory value that statistical=20 > analysis based on the=20 > hostname portion of the client's FQDN is cheaper, I don't=20 > object to that. =20 > It's only the additional complexification required to "do it=20 > right" to which=20 > I object, because I don't think it adds any value. >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:15:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ibt-0006sS-60 for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:15:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18729 for ; Wed, 8 Feb 2006 01:13:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iZk-0005al-Pv for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:13:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6iZj-0005aO-H6 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:13:12 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186D0v2044367 for ; Wed, 8 Feb 2006 01:13:00 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186D0lv044366 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:13:00 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6dkf-0008ns-Cu for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 01:04:09 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2006 20:04:09 -0500 X-IronPort-AV: i="4.02,96,1139202000"; d="scan'208"; a="81912953:sNHT35296524" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1813uPU003578; Tue, 7 Feb 2006 20:04:05 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Feb 2006 20:04:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Tue, 7 Feb 2006 20:04:02 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210134016C@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcYsRv243CpzNOPWQwWpL/nCtoko6QAApB3A From: "Bernie Volz \(volz\)" To: "David W. Hankins" Cc: , "dhcwg" , "Olaf Kolkman" , , "Stig Venaas" , =?iso-8859-1?Q?=D3lafur_Gu=3Emundsson_/DNSEXT_co-chair?= , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 08 Feb 2006 01:04:03.0617 (UTC) FILETIME=[8D952910:01C62C4B] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] David: I'm perfectly happy with MD5 too. I'm only doing this because this was = apparently a blocking issue with the IESG. I'm not even an author on the = DHCID RR draft, but have volunteered to sheppard it through because the = authors have lost interest. (Though if one or more of the authors wants = to pick this up, let me know and I'll send along the xml file for the = draft.) While we could do as Ted suggests (drop the encoding), I personally am = uncomfortable with that because I think the information will leak out = and better for it not to be obvious (though I guess if it was obvious it = would teach folks quickly not to let it leak?). I also don't recall the = history (because I either wasn't involved or was fairly disinterested at = the time) the reason for encoding this, but suspect it was to make it = somewhat difficult for someone to find the client's identity and = potentially track the user through the Internet as they connect to = different access networks (assuming the DHCID RR was available). I don't = believe the goal was ever to make it impossible, just somewhat difficult = so that most folks wouldn't bother. BTW, most of the options are definitely not fun for me because it will = require more changes to the DHCID RR draft and the conflict resolution = draft, since there needs to be something said about what happens if a = DHCID RR exists and the data doesn't match -- if the "digest type" is = different, then the updater might have to switch to that digest (if = supported), ... If not supported, well, I guess one must assume the FQDN = is in use and try a different FQDN. - Bernie=20 > -----Original Message----- > From: David W. Hankins [mailto:David_Hankins@isc.org]=20 > Sent: Tuesday, February 07, 2006 7:31 PM > To: Bernie Volz (volz) > Cc: namedroppers@ops.ietf.org; dhcwg; Olaf Kolkman;=20 > Harald@Alvestrand.no; Stig Venaas; =D3lafur Gu>mundsson /DNSEXT=20 > co-chair; Ralph Droms (rdroms) > Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and=20 > DDNS-DHCP Related RFCs >=20 > On Mon, Feb 06, 2006 at 09:59:11AM -0500, Bernie Volz (volz) wrote: > > Possible solutions to the hash algorithm issue are: > >=20 > > 1. Switch from MD5 to SHA-1 or SHA-256 as the "base"=20 > algorithm. This won't help down the road if these are found=20 > to have significant weaknesses. > >=20 > > 2. Add a field (octet) to the DHCID RR RDATA to specify the=20 > algorithm used (perhaps using the digest type field and=20 > assignments used by the DS record, RFC 3658, and=20 > http://www.iana.org/assignments/ds-rr-types). The RDATA would=20 > thus be formatted as octet)>. This also means a change to SHA-1=20 > as the base algorithm or we'd need to request IANA to=20 > allocate a MD5 digest code. (The SHA-1 digest is 20 octets=20 > instead of MD5's 16 octets.) > >=20 > > 3. Incorporate the hash algorithm into the existing RR type=20 > code field, which means a change of algorithm requires new RR=20 > type codes to be assigned (likely 3 new codes per algorithm). > >=20 > > 4. Don't change the RDATA format or algorithm. Though this=20 > would likely block this work from proceeding through the IESG? > >=20 > > Perhaps there's other solutions? > >=20 > > I'm inclined to pick 2 as I believe it meets all of the=20 > IESG requirements and is the most flexible. Whether we switch=20 > to SHA-1 or request a digest type assignment for MD5 is=20 > debatable, but unless there are significantly different=20 > export restrictions or licensing issues for MD5 vs. SHA-1,=20 > let's just switch to SHA-1?=20 >=20 >=20 > Funny, I was going to say '2 is right out'. I don't like the > implications of people trying to be reverse-algorithm compatible, or > the fact that there's no way to roll between algorithms except > all-stop, delete, restart. >=20 >=20 > There's a contradiction in Ted's and Bernie's statements here=20 > I want to > point out. Bernie says if SHA-X is found weak, that's a problem. Ted > says we can just remove the encoding. >=20 > One of these two statements has to be false if the other is true. If > we can remove the encoding, then we don't care if SHA-X is weak. If > we care if SHA-X is weak, then we can't remove the encoding. >=20 > Obviously I agree with Ted, I think the encoding is more political > problem than technical reward. >=20 > In that case, there's no reason to care if SHA-x is weak because the > alternative was cleartext. So why not just go with door #1 if that > makes the IESG happy? >=20 > One of my coworkers (who, wishing not to be named "bad idea=20 > fairy" will > for the moment be kept anonymous) suggests we adopt ROT13. Actually, > some zone admins might be able to read that without a filter,=20 > so perhaps > we should just XOR the field by 0xFF. >=20 > If cleartext is an acceptable answer, which I think it is, than any > obfuscation that makes plaintext unreadable is equivalent, even if > that equivalent obfuscation is a *different* weak digest algorithm. >=20 >=20 > MD5 was the right answer. There's no other way to say it. >=20 >=20 > So in my final analysis, if switching to SHA-1 or SHA-256 gets it past > IESG, I think that's better than ROT13 or XOR 0xFF, which I think is > better than removing the encoding entirely, which I think is better > than switching to an encoding byte, which I think is better=20 > than making > the encoding part of the type field. >=20 > But really, the success story here would be if we made no changes and > just stuck with MD5. >=20 > --=20 > David W. Hankins "If you don't do it right the=20 > first time, > Software Engineer you'll just have to do=20 > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 01:16:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6icb-0006wA-Sv for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:16:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18756 for ; Wed, 8 Feb 2006 01:14:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6ib8-0005o5-0x for namedroppers-data@psg.com; Wed, 08 Feb 2006 06:14:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,HEADER_SPAM,HTML_10_20,HTML_MESSAGE autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6ib6-0005nV-D1 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 06:14:37 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k186ENNN044392 for ; Wed, 8 Feb 2006 01:14:23 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186ENKt044391 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:14:23 -0500 (EST) (envelope-from namedroppers) Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6hKA-000Pmm-5Q for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 04:53:02 +0000 Received: from Pivo.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 98631568E3; Tue, 7 Feb 2006 20:52:58 -0800 (PST) (envelope-from pvm@nominum.com) Message-Id: <6.0.3.0.0.20060207055855.084c3d60@127.0.0.1> X-Sender: pvm@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 07 Feb 2006 06:24:57 -0800 To: Paul Vixie , namedroppers@ops.ietf.org From: "Paul V. Mockapetris" Subject: Re: the RD bit is troubling me today In-Reply-To: <20060204013717.6BD8111427@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1139379267-41854-97" Content-Transfer-Encoding: binary X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format... ------------=_1139379267-41854-97 Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k186ENKt044391 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:14:23 -0500 (EST) (envelope-from namedroppers) Approved: bert X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24, DNS_FROM_RFC_WHOIS,HTML_10_20,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6hKA-000Pmm-5Q for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 04:53:02 +0000 Received: from Pivo.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 98631568E3; Tue, 7 Feb 2006 20:52:58 -0800 (PST) (envelope-from pvm@nominum.com) Message-Id: <6.0.3.0.0.20060207055855.084c3d60@127.0.0.1> X-Sender: pvm@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 07 Feb 2006 06:24:57 -0800 To: Paul Vixie , namedroppers@ops.ietf.org From: "Paul V. Mockapetris" Subject: Re: the RD bit is troubling me today In-Reply-To: <20060204013717.6BD8111427@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_37909500==.ALT" [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] --=====================_37909500==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Disposition: inline At 05:37 PM 2/3/2006, Paul Vixie wrote: >We've spent about half of the total DNSSEC development era to date (that is >around six years out of the twelve) going down ratholes due to >misunderstanding 1034/1035. Sometimes we amend 1034/1035 to explain something >that didn't used to need to be explained; sometimes we amend 1034/1035 to >explain something that we thought had been explained that turned out to have >ambiguities... The result of DNSSEC is that we now understand far more about >the delegation model and wildcards (among other things) than we used to know. >Sort of like one of the great side-benefits of NASA's moon programme was the >ballpoint pen. > >There's been some interest recently in the question "should a nameserver also >be recursive, if it's authoritative for any zones?" The old, sad, answer has >been "don't do it, since BIND4 was terrible about mixing recursive and >authority data, and dual-purpose nameservers are a recipe for cache pollution" >but it turns out that since BIND8, BIND9, and all modern non-BIND servers can >safely mix authority and recursive data, folks are starting to do this again. >It's not that hard to run two nameservers on a host, and just use different >IP addresses for your resolv.conf file vs. your NS RR -> A/AAAA RR chain, but >even though it's not hard, it's not as easy as just using one nameserver. > >While the RD bit in a query can disambiguate the case of a name-below-zonecut >such that if RD=0 a dual-use server will return a delegation whereas if RD=1 >it will go fetch the data, I don't think this helps when the qname is equal to >a zonecut name. An authority server should respond with a non-AA delegation >in that case, since the zone ends above the zonecut. A recursive server >should respond with a non-AA answer in that case. But the non-AA answer >should be first retrieved from the apex of the subzone, by following the >delegation, all without allowing an RD=1 query to affect subsequent RD=0 >results. A dual-use server would therefore have to maintain separate NS >RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers. I'm assuming we are operating in the RA=1 world. That is the server is willing to honor the request for recursive service. The intent of the framer was that authoritative data would always take precedence over cached data and that hints were even lower in priority. A common metaphor for this was that the authoritative data in zones were like windows on a screen and the cache was the background. At a zone cut, the parent was definitive with regard to controlling whether a child zone was recognized as a legitimate descendant, but the child, once recognized by the parent, was authoritative for the contents of that zone, including the top node. Thus the NS records marking a zone cut in the parent, as well as glue data, were part of the zone, but not part of the zone's authoritative data. >1034/1035 does not anywhere say this, but it's the implication of the other >"intent of the framers" clarifications we've made to 1034/1035 during the >DNSSEC development era. But if we were going to write another clarification >document on this point, I'd rather we just said "nameservers that offer both >authority and recursive service are undefined, please just don't do it" than >to try to describe how many RD bits should be dancing on the head of this pin. Well, this intent again was that a recursive name server was just a name server that executed the resolver logic to fetch data if necessary, and that having access to authoritative data as well as a cache was possible. -- Anyway, if RD=0, I'd argue that the authority section of the response should contain a delegation and the answer section cached data if available. If RD=1, the answer section has the answer, with aa set if the answer came from a zone's authoritative data, 0 otherwise. -- I can imagine lots of reasons where I might want to have a server configured to be authoritative only or caching only, but I don't think the one can credibly argue that the behaviour is "undefined" for a mixed server. >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: --=====================_37909500==.ALT Content-Type: text/html; charset="us-ascii" Content-Disposition: inline At 05:37 PM 2/3/2006, Paul Vixie wrote:
We've spent about half of the total DNSSEC development era to date (that is
around six years out of the twelve) going down ratholes due to
misunderstanding 1034/1035.  Sometimes we amend 1034/1035 to explain something
that didn't used to need to be explained; sometimes we amend 1034/1035 to
explain something that we thought had been explained that turned out to have
ambiguities... The result of DNSSEC is that we now understand far more about
the delegation model and wildcards (among other things) than we used to know.
Sort of like one of the great side-benefits of NASA's moon programme was the
ballpoint pen.

There's been some interest recently in the question "should a nameserver also
be recursive, if it's authoritative for any zones?"  The old, sad, answer has
been "don't do it, since BIND4 was terrible about mixing recursive and
authority data, and dual-purpose nameservers are a recipe for cache pollution"
but it turns out that since BIND8, BIND9, and all modern non-BIND servers can
safely mix authority and recursive data, folks are starting to do this again.
It's not that hard to run two nameservers on a host, and just use different
IP addresses for your resolv.conf file vs. your NS RR -> A/AAAA RR chain, but
even though it's not hard, it's not as easy as just using one nameserver.

While the RD bit in a query can disambiguate the case of a name-below-zonecut
such that if RD=0 a dual-use server will return a delegation whereas if RD=1
it will go fetch the data, I don't think this helps when the qname is equal to
a zonecut name.  An authority server should respond with a non-AA delegation
in that case, since the zone ends above the zonecut.  A recursive server
should respond with a non-AA answer in that case.  But the non-AA answer
should be first retrieved from the apex of the subzone, by following the
delegation, all without allowing an RD=1 query to affect subsequent RD=0
results.  A dual-use server would therefore have to maintain separate NS
RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers.

I'm assuming we are operating in the RA=1 world.  That is the server is willing to honor the request for recursive service.

The intent of the framer was that authoritative data would always take precedence over cached data and that hints were even lower in priority.  A common metaphor for this was that the authoritative data in zones were like windows on a screen and the cache was the background.  At a zone cut, the parent was definitive with regard to controlling whether a child zone was recognized as a legitimate descendant, but the child, once recognized by the parent, was authoritative for the contents of that zone, including the top node.  Thus the NS records marking a zone cut in the parent, as well as glue data, were part of the zone, but not part of the zone's authoritative data.

1034/1035 does not anywhere say this, but it's the implication of the other
"intent of the framers" clarifications we've made to 1034/1035 during the
DNSSEC development era.  But if we were going to write another clarification
document on this point, I'd rather we just said "nameservers that offer both
authority and recursive service are undefined, please just don't do it" than
to try to describe how many RD bits should be dancing on the head of this pin.

Well, this intent again was that a recursive name server was just a name server that executed the resolver logic to fetch data if necessary, and that having access to authoritative data as well as a cache was possible.

--

Anyway, if RD=0, I'd argue that the authority section of the response should contain a delegation and the answer section cached data if available.

If RD=1, the answer section has the answer, with aa set if the answer came from a zone's authoritative data, 0 otherwise.

--

I can imagine lots of reasons where I might want to have a server configured to be authoritative only or caching only, but I don't think the one can credibly argue that the behaviour is "undefined" for a mixed server.

<And yes, there are lots of ways to implement mixed mode incorrectly, and bind wasn't alone in exploring that space>

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--=====================_37909500==.ALT-- ------------=_1139379267-41854-97 Content-Type: text/plain; name="SpamAssassinReport.txt" Content-Disposition: inline; filename="SpamAssassinReport.txt" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.418 (Entity 5.418) Content-Transfer-Encoding: 7bit Spam detection software, running on the system "hlid.ogud.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: At 05:37 PM 2/3/2006, Paul Vixie wrote: >We've spent about half of the total DNSSEC development era to date (that is >around six years out of the twelve) going down ratholes due to >misunderstanding 1034/1035. Sometimes we amend 1034/1035 to explain something >that didn't used to need to be explained; sometimes we amend 1034/1035 to >explain something that we thought had been explained that turned out to have >ambiguities... The result of DNSSEC is that we now understand far more about >the delegation model and wildcards (among other things) than we used to know. >Sort of like one of the great side-benefits of NASA's moon programme was the >ballpoint pen. > >There's been some interest recently in the question "should a nameserver also >be recursive, if it's authoritative for any zones?" The old, sad, answer has >been "don't do it, since BIND4 was terrible about mixing recursive and >authority data, and dual-purpose nameservers are a recipe for cache pollution" >but it turns out that since BIND8, BIND9, and all modern non-BIND servers can >safely mix authority and recursive data, folks are starting to do this again. >It's not that hard to run two nameservers on a host, and just use different >IP addresses for your resolv.conf file vs. your NS RR -> A/AAAA RR chain, but >even though it's not hard, it's not as easy as just using one nameserver. > >While the RD bit in a query can disambiguate the case of a name-below-zonecut >such that if RD=0 a dual-use server will return a delegation whereas if RD=1 >it will go fetch the data, I don't think this helps when the qname is equal to >a zonecut name. An authority server should respond with a non-AA delegation >in that case, since the zone ends above the zonecut. A recursive server >should respond with a non-AA answer in that case. But the non-AA answer >should be first retrieved from the apex of the subzone, by following the >delegation, all without allowing an RD=1 query to affect subsequent RD=0 >results. A dual-use server would therefore have to maintain separate NS > [...] Content analysis details: (5.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.2 HEADER_SPAM Bulk email fingerprint (header-based) found 1.0 DATE_IN_PAST_12_24 Date: is 12 to 24 hours before Received: date 0.0 HTML_MESSAGE BODY: HTML included in message 0.9 HTML_10_20 BODY: Message is 10% to 20% HTML ------------=_1139379267-41854-97-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 02:51:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6k6V-0005pP-1v for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 02:51:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24869 for ; Wed, 8 Feb 2006 02:49:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6k3I-000E1P-Sk for namedroppers-data@psg.com; Wed, 08 Feb 2006 07:47:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6k3I-000E0z-9f for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 07:47:48 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D16E92596D8; Wed, 8 Feb 2006 08:46:29 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09213-04; Wed, 8 Feb 2006 08:46:25 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47CDF2596D5; Wed, 8 Feb 2006 08:46:22 +0100 (CET) Date: Wed, 08 Feb 2006 08:45:39 +0100 From: Harald Tveit Alvestrand To: "Bernie Volz (volz)" , "David W. Hankins" Cc: namedroppers@ops.ietf.org, dhcwg , Olaf Kolkman , Stig Venaas , =?UTF-8?Q?=C3=93lafur_Gu=3Emundsson_=2FDNSEXT_co-chair?= , "Ralph Droms (rdroms)" Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Message-ID: In-Reply-To: <8E296595B6471A4689555D5D725EBB210134016C@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB210134016C@xmb-rtp-20a.amer.cisco .com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========738ABD0FBC74BD0D4272==========" X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========738ABD0FBC74BD0D4272========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 7. februar 2006 20:04 -0500 "Bernie Volz (volz)" =20 wrote: > David: > > I'm perfectly happy with MD5 too. I'm only doing this because this was > apparently a blocking issue with the IESG. My reading (which is about as reliable as tea leaves) is that keeping MD5,=20 and changing the document to say that it doesn't purport to protect=20 identities, is also a valid way forward. It's the inconsistency between the claim that MD5 helps security and the=20 known weakness of MD5 that's got the security ADs up in arms. Harald --==========738ABD0FBC74BD0D4272========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD6aGjOMj+2+WY0F4RAkVkAKCW0IdvI/U6KCqLTdxbzKcFepfRFACfaIId QZbZIDkc/TvLfA2nSi8VgZg= =7nc6 -----END PGP SIGNATURE----- --==========738ABD0FBC74BD0D4272==========-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 03:09:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6kNs-0006A8-Vw for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 03:09:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26398 for ; Wed, 8 Feb 2006 03:07:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6kLk-000FjY-Rk for namedroppers-data@psg.com; Wed, 08 Feb 2006 08:06:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6kLk-000FjM-6I for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 08:06:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B93A311426; Wed, 8 Feb 2006 08:06:51 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Paul V. Mockapetris" cc: namedroppers@ops.ietf.org Subject: Re: the RD bit is troubling me today In-Reply-To: Your message of "Tue, 07 Feb 2006 06:24:57 PST." <6.0.3.0.0.20060207055855.084c3d60@127.0.0.1> References: <20060204013717.6BD8111427@sa.vix.com> <6.0.3.0.0.20060207055855.084c3d60@127.0.0.1> Date: Wed, 08 Feb 2006 08:06:51 +0000 Message-Id: <20060208080651.B93A311426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # -- # # Anyway, if RD=0, I'd argue that the authority section of the response # should contain a delegation and the answer section cached data if available. # # If RD=1, the answer section has the answer, with aa set if the answer came # from a zone's authoritative data, 0 otherwise. I am pleasantly surprised by your RD=0 clarification, but the RD=1 baffles me. For the RD=0 case, no existing server of which I'm aware works this way, and noone I've spoken to about this who has read 1034 and 1035 interpreted it this way. However, I can see the consistency in it and I can live with the ruling. In the RD=1 case, you'd have a dual-purpose server respond with data that did not come about by recursion, and is in practical terms "less credible than" what would result from querying the child zone's authority servers for it. To help understand my bafflement, consider that regeneration is all the rage, and AA=1 never occurs after recursion in BIND9. In BIND4 and early BIND8, we passed through the initial AA=1 from the authority server but gave back AA=0 on subsequent queries for the same data. For a BIND9 recursive server, AA=0 on all responses. I regard the current BIND9 behaviour as "more correct." # -- # # I can imagine lots of reasons where I might want to have a server configured # to be authoritative only or caching only, but I don't think the one can # credibly argue that the behaviour is "undefined" for a mixed server. I hope you're right, but I'd like to understand more about your reasoning in the RD=1 case. I really think that if a requestor wants recursion, that the data they should be given should be the result of recursion. If any other RA=1 server were to respond with parent-zone-glue rather than child-zone-data in this case, we would call that server "defective". --- There's another, more extreme problem with dual-purpose servers, and that's security. Recursive nameservers which are open to the internet are, because of the widespread ridicule heaped upon RFC2827/BCP38 and SAC004, "dangerous". (I am aware of a multi-gigabit attack occuring against a neighbor, even as I type this, involving a few thousand open-to-recursion nameservers, 4K TXT RRs, a low-intensity spoofed source query stream from a botnet, and EDNS0.) Since it's operationally difficult to use different ACLs for recursion vs authority, most people just don't do it. So most dual-purpose nameservers are fully open and thus "dangerous". So if we do manage to nail down a practical interpretation of dual-purpose, I'll want the resulting clarification document to sing most expansively the damnation against open recursive servers, and if I am an author of such a document, it will advise "just don't do it" as the safest course of action. --- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From drasler@ambersplace.com Wed Feb 08 03:38:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6kqb-0002ql-SB for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 03:38:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29403 for ; Wed, 8 Feb 2006 03:36:53 -0500 (EST) Received: from [61.5.65.93] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6l2L-0002QE-Ql for dnsext-archive@ietf.org; Wed, 08 Feb 2006 03:51:34 -0500 Message-ID: <000001c62cb4$ee46f180$0100007f@localhost> From: "Dean Hall" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Wed, 08 Feb 2006 15:37:26 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62CB4.EE46F180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62CB4.EE46F180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62CB4.EE46F180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 50 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 47 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 35 reviews)

------=_NextPart_000_0001_01C62CB4.EE46F180-- From owner-namedroppers@ops.ietf.org Wed Feb 08 08:03:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6oyQ-000278-Py for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 08:03:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19730 for ; Wed, 8 Feb 2006 08:01:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6ou8-000Ey2-AA for namedroppers-data@psg.com; Wed, 08 Feb 2006 12:58:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6ou6-000ExX-CV for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 12:58:39 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k18CvrHa019880; Wed, 8 Feb 2006 14:57:53 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k18Cvh50019877; Wed, 8 Feb 2006 14:57:43 +0200 Date: Wed, 8 Feb 2006 14:57:43 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: namedroppers@ops.ietf.org, dhcwg , Stig Venaas , Olaf Kolkman , =?UTF-8?B?w5M=?=lafur Gu=?UTF-8?B?4oC6?=mundsson /DNSEXT co-chair , Harald@Alvestrand.no Subject: Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 12:11:53 2006 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 2 Feb 2006, Ralph Droms wrote: > Included below is a summary list of the open issues in this package > of documents: > > draft-ietf-dnsext-dhcid-rr-10.txt > draft-ietf-dhc-ddns-resolution-10.txt > draft-ietf-dhc-dhcpv6-fqdn-03.txt > draft-ietf-dhc-fqdn-option-11.txt Just checking, did you also check the following mails: http://www1.ietf.org/mail-archive/web/ietf/current/msg38995.html http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05678.html ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From nicholas@paramed.biz Wed Feb 08 08:10:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6p62-0005nV-6b for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 08:10:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20644 for ; Wed, 8 Feb 2006 08:09:16 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6pIc-0003tg-3s for dnsext-archive@ietf.org; Wed, 08 Feb 2006 08:23:59 -0500 Received: from 61-223-174-212.dynamic.hinet.net ([61.223.174.212] helo=friend) by mx2.foretec.com with esmtp (Exim 4.24) id 1F6p5w-0008Ge-Bc for dnsext-archive@ietf.org; Wed, 08 Feb 2006 08:10:52 -0500 Message-ID: <000001c62cb1$06b50d00$0100007f@jd-yv8gueh73dyn> From: "Reginald" To: Subject: V1agra 10 P1lls 100 mg $69.95 Date: Wed, 08 Feb 2006 21:10:26 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="------------ms060006060509040207060202" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 This is a multi-part message in MIME format. --------------ms060006060509040207060202 Content-Type: multipart/alternative; boundary="------------ms010207010901080606080805" --------------ms010207010901080606080805 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable --------------ms010207010901080606080805 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""
 
--------------ms010207010901080606080805-- --------------ms060006060509040207060202 Content-Type: image/jpeg; name="image.jpg" Content-Transfer-Encoding: base64 Content-ID: <000701c62a48$e2358cd0$aa0fa8c0@sanya> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCACnAhwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDYooor 4MwGO/l4JHy9z6UI+/IIww6j0ofecKnGeren4U2KLGGYYx91c/d9ee9apQ5Lvf8Ar+v61CWmSsVh dgcEKSKfTJVLQuoGSVIFZLcDj4vEV2/h/SJRfRm9mvBHOAE3FCzDlcccBecVqjxXZmRR9lvBE1x9 mExRdm/0+9n9KyovDt2nh/SIhYxi9hvBJOQU3BAzHls88FeM0xdH1byYbM2BCJqf2ozeam3Zz2zn 9K9SUMPJvbd9Uuv9WNbRZq6TrF3deItTtJYpzBGyCPKKBEMHO45zzjjr+FF5qd5F4gvrVJsQxaa0 6LtHDg9c4z+HSpNPtL208TanM1qTa3ZjKzCRcLtU9RnPU+lVdVsdRGvXN3bWRuIp7A2wKyIu1ie+ 4isUqbqdLcq7b6fiTpcgi1+7iOhy3E5MM1tNNcgIuX2IW9OOnbFX08W2ZCtJa3kSvC06M6Lh1UZO MMaxRour3ENjC9gYfstnPCXaZCGZ4yoxg+pFPtvDt3JprrPa3SXcVo0URluUZCSMYUDoPrW06eHe ra+TXd/8D5FNRL974rVrCb7Pb3VvcNbG4geZFwV9Rgmq9n4juJ/D926fbJLmGJma5kijVUcLnGAf y4qCPw9dy6VKJLS7F5HaCCPzblGVvUKAeB9TU8uiahAlzHbW+6O809Y5VDqNsyrgdT39qOXDpcqt v/X4B7po2XiOE6eTcLM89vZR3M7BVw25QeOev5U/W9Vlh8JyapZMY3eOOSMsoJAYr1HIzg1zl3aX 2lWt2ZrUFJtNihJ85AUZUAbjOTgjtXU6fn/hFbLFt9pP2SL9z8vz/KOPm4rKpTpwcakdVdf8ElpL Uqw34sraW9uNaN8kcW9oI1iyOnPGDTX8X2UKu09rew7YROA6LlkLBRjDeprF1qwumNzff2Utjbx2 TowDxncxPopqO70jVdYt1mjsDGv9nRQpulT5yHVsjB449a1jQoytKbWvmlb7tCuVdToJPFtnAs5n tbyFoUWQo6LkhiAMYb3p91rDA2ReK+svNu0hCvFGTJnseThfcc1i3fh27utJu2S1uhfOscYFxco+ 9QwJwRwOnc1qalBqOqvpkh054Ps99HI6tKhOwdW4P6dazdOgmrW631XYVol2412K0vorWezu0E0w hjmKLsZj075x+FZGieKJJNPtI7qK5vL2YO/7iNPuhiPUDtVC28P6kLqyMunsJYr4TS3LTqQyBs9N 2f0qWz0G5ttJtEn0q4kvI1kXfDdLHsBYkDO4Zq/ZYeMbXTfqvPz/AFC0TsreUzwJK0UkJYZ2SAbh 9cE1JWboEF5baHbQ6gWN0obfufcfvHHPfjFaVedNJSaRm9woooqQCiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKAO/07TtPbSbSSSyhd3jXJ2Lz8o56e9WP7O0z/AKB8P/fC/wDxNGnf8gSx/wCua/8A oK1Iz7TjGa9r3YxWi2XTyKI/7O0z/oHw/wDfC/8AxNH9naZ/0D4f++F/+Jp/mn+7+tHmn+7+tHNH svuQrjP7O0z/AKB8P/fC/wDxNH9naZ/0D4f++F/+Jp/mn+7+tOVt2eMUXj2X3ILkX9naZ/0D4f8A vhf/AImj+ztM/wCgfD/3wv8A8TU9FPTsvuQyD+ztM/6B8P8A3wv/AMTR/Z2mf9A+H/vhf/ianoo0 7L7kBB/Z2mf9A+H/AL4X/wCJo/s7TP8AoHw/98L/APE1PRRp2X3ICD+ztM/6B8P/AHwv/wATR/Z2 mf8AQPh/74X/AOJqeijTsvuQFC48PeH7xw9zodjOwGA0sEbED8VqddM0pECJpsCqowAEUAD/AL5q xRVOV1b9EFytLpOkTxNFLpdvJGwwyvGhBHuNtKumaUiKiabAqqMBQigAf981YopX6WX3ICD+ztM/ 6B8P/fC//E0f2dpn/QPh/wC+F/8Aianopadl9yAg/s7TP+gfD/3wv/xNH9naZ/0D4f8Avhf/AImp 6KNOy+5AQf2dpn/QPh/74X/4mj+ztM/6B8P/AHwv/wATU9FGnZfcgIP7O0z/AKB8P/fC/wDxNH9n aZ/0D4f++F/+JqeijTsvuQEH9naZ/wBA+H/vhf8A4mj+ztM/6B8P/fC//E1PRRp2X3ICD+ztM/6B 8P8A3wv/AMTR/Z2mf9A+H/vhf/ianoo07L7kBB/Z2mf9A+H/AL4X/wCJo/s7TP8AoHw/98L/APE1 PRRp2X3ICD+ztM/6B8P/AHwv/wATR/Z2mf8AQPh/74X/AOJqeijTsvuQEH9naZ/0D4f++F/+Jo/s 7TP+gfD/AN8L/wDE1PRRp2X3ICD+ztM/6B8P/fC//E0f2dpn/QPh/wC+F/8Aianoo07L7kBB/Z2m f9A+H/vhf/iaP7O0z/oHw/8AfC//ABNT0Uadl9yAg/s7TP8AoHw/98L/APE0f2dpn/QPh/74X/4m p6KNOy+5AQf2dpn/AED4f++F/wDiaP7O0z/oHw/98L/8TU9FGnZfcgIP7O0z/oHw/wDfC/8AxNH9 naZ/0D4f++F/+JqeijTsvuQGdrkemaNYw3P9lwzeawXbhVxxnrtNYH/CQ6Z/0AIf++1/+Ira8cf8 gOy/66j/ANBNcKkMsiO6ROyoMuyqSF+vpXBmFapSxDhTtay6Lt6H02WZfhq2H56sbu/d/wCZ0H/C Q6Z/0AIf++1/+Io/4SHTP+gBD/32v/xFYf2K63on2abc4yo8s5Yeo9agIwcHrXC8XXW/5L/I9BZT gXtD8X/mdH/wkOmf9ACH/vtf/iKP+Eh0z/oAQ/8Afa//ABFc8iNI4RFLMxwFUZJNKYpBN5Jjfzc7 dmOc+mPWj65X8vuX+Q/7JwX8n4v/ADOg/wCEh0z/AKAEP/fa/wDxFH/CQ6Z/0AIf++1/+IrnzDKJ vJMT+bnGzad2fTFPNpchZGNvKFjOHOw4U+/pR9bxH9RX+Qv7KwP8n4v/ADN3/hIdM/6AEP8A32v/ AMRR/wAJDpn/AEAIf++1/wDiKw3s7qNSz20yqoBJKEAA9DUaQyyK7RxuyoMsVUkKPf0o+t4hO3/t q/yD+ysC1fk/F/5nQf8ACQ6Z/wBACH/vtf8A4ij/AISHTP8AoAQ/99r/APEVzlFL67W7r7l/kP8A sjBfyfi/8zo/+Eh0z/oAQ/8Afa//ABFOj13T5XCR+HY3c8BVZST/AOOUaX4dgSzOo61Ibe1Ayqk7 S319v1qnfePraxVrfw/YRRL085l5bHfHf8a9GlCvyqdaain05U2/lY4J4XBuThQpczXW7SXzudJb 2stwob/hFoY1P/PWVFP5bM1cGkEjJ0XTx7GYf/Gq8mvfEmsag2bi/mI/uq2B+QrMZ3dtzMSfUmtv rFKOyb9eVflEX9jxluor05n/AO3Hs8umyRj5fDtnJ/uTp/VBWPd6jBYttuvC4i5wCxXB+h2YNecW +p31owNvdzREdNrkV0unfELVLb93fKl7AeGDjnH170nVpT2bi/SLX5Jh/ZcYa8ikvWSf5tGz/wAJ Dpn/AEAIf++1/wDiKP8AhIdM/wCgBD/32v8A8RVmCDQPFdu0mmEWl8Bkw9AT9P6iuZu7SeyuXt7i MxyL1BrkxLxVC0m04vZpK35G+HwWX1m4+ztJbpt3/M3f+Eh0z/oAQ/8Afa//ABFb9jBp9/p8F2un W8YlBOworYwxHXA9K89r0Hw//wAi9Y/7r/8AoxqeCrzrTlGdnp2Xddkcmb4DD4egp0o2d7bvs+5b 07/kCWP/AFzX/wBBWnuCzgDkngCmad/yBLH/AK5r/wCgrVm1AbUI1PZS39P616sIc7jHvb8j5zcy 9Y12y0DEJj+03pGfLzhU+tYq+P73fmXT7Zos/dGQfz/+tXOrOt7qxub0uUlm3S4+9tzzj8K6TXTa S+GNNktLYQQtK+Ezk8EjJPc8VwPG1ZqcqUlGMdlbV6pfqcTrzldxdkjoLG/stZs2ubIlWT/WQt1W p4+9cT4LmeHxTDEpISZXVx2ICkj+VdsmMyKP4ZGX8jiuqjUVeiq1rO9mdFKp7SHMPoritGiufFF5 rt1danqFtJZ6o9nbLZ3BjSJIiCDs5Vy2Tu3hs9AAKp2viq+T+0YYDF9qbXLm0t4dstzLKE2cKjSq FABLM29UUL935uNOU1PQaK8Xv/HGp3sDauC8YbQVla1S4lSLzReiIuNjKwJAPQ5wcEkZz2f/AAlm qReMP7KvobSwikvPJtkuopF+1RbfvxzglC+Sp2FR94Lu3U3BgdrRRRUAFFFFABRRSE4BNAFe5u1g GBy38qy31rDlRJkg87V4H1rJ1XUCX2mTZvk2Fv7uTiovtUcMYUYjjXoM8VV0tD1aOGioJtXudCNV dBlyuB1zVqLU4ZAMnGe/UVyEl4p2kJukfhN4/M/SmNdBYwEmOUYRoox83Tr9c0uZFSwkJdLHeo6S DKMCPanVxq6i8LblfGD1zXT6bdG8sIpz1Yc+9HocFfDulZ3LdFFFI5wpjzRxvGjyIrStsjDMAXbB OB6nAJ+gNPrz7x4v2XX9M1OWOK/tIP8AX2ivtngAjnYyxtkbcqGbsS0CYORw0rgeg0V5B/zMf27/ AKnD7P8A2h/y8/cx5GP+eP8ADnf0/g7VN4Ws7q08ReFQIPMmb+0Te6nbSJLHfLnIZpEYswDFP9YB hiO9VyAes0UUVABRRRQAUUUUAFFFFABVe9vIdPs5bqckRxjJ2jJPYAfjVisbxV/yLV3/AMA/9DWr pxUpqL6sFuU/+E303/nhd/8AfC//ABVH/Cb6b/zwu/8Avhf/AIqsjwxapPpGsSfZ/Nnj8nyytotw 65Zs7Ubg8dfz7VszaXZS3bxWljbSGLW4xKkKiTZCUGd3HC53ZHQHI7V6n1OkacqG/wDCb6b/AM8L v/vhf/iqP+E303/nhd/98L/8VVNZNOMGrXq6fay/2VcP5G1V8udZXKrvGPmC9RgjjA461jaTHpz6 Xe/2ijKrzQxpcIMtASsh3Y/iHyjI9PcCj6nSDlR0v/Cb6b/zwu/++F/+Ko/4TfTf+eF3/wB8L/8A FVVutOFtpUw020tru/Sa3SQwwLP+7+zqdwBBwC2TuwM1YltNIbVdYtkt7YJYTR3yhEBLIoHnRk8j HXC8cn0HB9TpByod/wAJvpv/ADwu/wDvhf8A4qtnTNTt9WtPtFvvChipVxggj/6xH51xviSOytNP tUtoYlkvZHvifLAaONj+7QEDgYzleeR6YrZ8Ef8AIFm/6+G/9BWsMThoU4c0ROKSL/jj/kB2X/XU f+gmsfwcFuLu9sJDhLm2ZSff/wDUTWx44/5Adl/11H/oJrldCi1KXUlOlcXCKTuOMKOhznjvXh4q fJmMXa+2i66an1GAhz5dJXtvqz0Cae3eO6vkwG05JoV+u1T/AExXPQeH9Ne1gtGikN1NZG6+1Bzh Txxjpjn/ADms+S08QW93JpTEB9QLSMMriQ8knPbp7VWtdR1mRBosNxwcxBTtBA7jceg49a0rYuFS a9rSd9Vt100+62u6CjhJwj+6qK2j36a6/ffTZmxaWem2LaFIts5u7sxt5m84QgjJx75xVqKxsk1K fUJ4WmnbVRDHtcjyzuBB965ObUr+Ke3R5hvsTsiwq/Jg/Tnp3zUkHiHVLdp2iuipnfzHOxfveo44 /CueGNoRfK46LyXa333udE8FXkrqWr833/KxPrMxtvF0846xXAf8sGu7uYbXzJdPJH/Ez8x8jsQi jP8AWvOJory/huNUlKuN4Ej5AJY47U5tc1J7m2uGuSZbZdsTbF+UYx6c/jSoY6NCU3OLtN3Xpd3+ 9aBXwUq0YKEleKs/Wyt+Op1WtbbmPX2DuBbrDGqq5Cn1yOh5JqR7Gy0yw1iztoWWRLJTJKXJEhIb t26dq45tWvmS7Qz5W7bdONo+c5z6cfhU8niLVZbT7M90TEY/KI2LyvucZ/Gq/tCg5Obi7tPourl5 6br7rE/UKyioKStddX0UfLyf33N+80DSLXTZImZFulthKJjMdzNzxt6Acdaq6NZ2mj6W2vaqOF5g jbv6HHqe1Hh6/wBR1W6h02actZRrukG0ZKL0UnGSM4H0rm/HOvtqurNaxN/olsdigdC3c1vH6u4r FRja2iVuvfzt36mfLiHN4aUr31bv07eV+3QzfEHiO81+7MkzFYVP7uIHhR/jWPWjp2hanqsbyWNl LMifeZRx9M1reHPC0GsW/n3V8IFZiiKoDEY7tzwM4HuTWPs61ed3q2dvtKNCFlol2MC1sri9crBE zAFQzY4XJAGT25IrpNb8IQ6Vpsky3kj3MLYliaLAI4+ZfbJxk9f1rUmu9L0ez1XT7m3fT9RFt5O2 IEpOQco49D/jXM6j4q1XVLIWtzMmwqquUQK0gHTce9aunRpQanrJ/gYKpXrTUoaRX4rQxaKKK4jv JILiW1nSaCRo5EOVZTgivS9F1e18Z6edO1DbHqMS5jlH8XuP6ivMKntLuaxu4rm3cpLGwZSK3oVv Zvlkrxe6OfEYdVVeOklszo7m2ltLmS3nQpLGcMDXeeH/APkXrH/df/0Y1ZWtyxa94YtNbhQeahCz Y7A8HP0OPzrV8P8A/IvWP+6//oxqqhhvq+JlFO6cbp+TaPKzTEOvgoyas1KzXmky3p3/ACBLH/rm v/oK02e5+xXUF02fKQ7ZMdlPf8OtO07/AJAlj/1zX/0FakkjWWMowyCMV6EJcrjJeX5HzRwPiHR5 dH1F5FXdZzMXhkXkYPOKkvtUtZfC2m2kcubiF5DIm0jaCxI56d66QpqGmxNBDHHe2J/5d5v4f909 v1qlH5cc3mReEoFkzkM1yWAP021zTwEXKUqUklJWad9NU9PuOaWG1bi9yv4S097Nn128BjhiQiFT wZGIxx/L8a6ez3/ZlaT77ks31PNUo7e9v50uNSdcJ/q4IxhE/wAT71qdK6FCFKmqVPZfizeEFCPK jHvvC2jajeSXV1Z75JfL85RK6pNsOU8xAQsmP9oH06UxvCWiM7OLR45WupLzzYriRJBLIMOQ6sGU MMZUEDgcVt0Urso5v/hAvDP2X7N/Zv7n7P8AZtvnyf6vzfN253Z+/wA569unFXP+EW0b+0vt/wBj /ffaPtW3zX8rzsY8zy87N+P4sZzz15rYoouwCiiikAUUUUAFHUUUUAcJ4ksZbW6d2iaS2k5OBnbW AlxZxsGHJX7u9i236AmvV5Yo5kKSKGU9jWa/h3TnYsYFyfam1F6s7aONlTjytXR5617bysGIMrDp wTVm3hv7yXdbWe1j/wAtHHNd7DoenwEFLdcj2q8kSRjCIFHsKLRXmOePqPSKschZeEZ5mWS/nLDr sHArroIUt4VijGFUYFSUUN3OOc5Td5O4UUUUiQqneaVYahc2lxd2kU01nJ5tu7rkxtjGR+h+oB6g EXKKAKf9k6b/AGl/aP8AZ9p9u/5+fJXzem372M9OOvTin22n2VnNPNa2dvBLcNvmeKJVaVuTliBy eT19TVmigAooooAKKKKACiiigAooooAKqanYrqenTWbuUEgHzAZwQQR+oq3RTTad0Bx3/CB/9RL/ AMgf/ZUf8IH/ANRL/wAgf/ZV2NFdH1ut3/IfMzjv+ED/AOol/wCQP/sqP+ED/wCol/5A/wDsq7Gi j63W7/kHMzjv+ED/AOol/wCQP/sqP+ED/wCol/5A/wDsq7Gij63W7/kHMzjv+ED/AOol/wCQP/sq 6DRdJXRrE2yymUs5dmIxycDgfQCtGionXqTVpMG2zJ8cf8gOy/66j/0E1ieEftRvLoWywSAwnfBK xBkHoDj/ADmtvxx/yA7L/rqP/QTXCRyPE4eN2Rx0ZTgivJx9X2WOVTsl+R9bllL2uAcO7Z6ALVIP EehsPNhZ45c2rylxF8h6c8en4Uzy7e8n0Wd7WBS9xOjKqDBA3AZ9egrhGuJ2m85ppDL/AHyxz+dA nmG3Esg2klfmPB9qX9pw1XJo3f8A9J8v7v4m39mz0fPqlb/0rz8/wO70u1H2Z3gsYJXGqMjFowdk ecHH0FOsrOKOO9NlZwTMmqbBlA2xPl3Y9hk/SuQTWriPSPsCZX9953nKxDZxjFEGsz2+kPYRgrvm 87zVYhgcAY/StI5hQSirbL8ey0/EzlgKzcnfd/h33/A6S5s7OO11TyoYsJqEaqQo+XJXIHoMk8VY 1mGzNjq0TWkEUdtPBhkTB+bZuP5EiuEE0oUqJHwTuI3Hk+tKbiY7syudxBbLZzjpn1rB5jDlaUN/ /tv819xssvnzJue3/wBr/k/vO91y0jXStVb7HbJEiRfZpERcleM/rmvPq3LzxH9p0+a1hsILbz9v nNH/ABY9B2rDrLMa9OtUTp9v1b7I1y+jUo02qnf9EvM6bSJv7J8I6rqe7Dv+6TjuB/8AZfpXmpJZ ixOSTkmu/wBbYw/DO0x/y2u8H/x//wCJrz+uur7tKlBbKKf36meG96dSb3cmvu0PQfC+qLf6Gumf ZLMfZATuubkxo4Y85Ufe4zntjjvVHVvEttpWr30ehQWpt540Dt5eV8xedyf5681xlbmm+H5LrR5d YBSeC2mUTWyN85TqT7cf19K1jiKs4qEVquvkv+AZyw1KnNzm9H083/wTJmmuL25Ms0kk88h5ZiWZ jXTWHhOG68MXOoy3Dx3duzM9uEy20Y4I6jPPNdDBp+kWGs217axxpY6rDttZ+ptZgOMZ9f5is3xL r91o+r2n2eUHVIIDDeS+XhZumOD1+vvWiw8KSc6zv0+/r+voZvEzqtQoq3X7un6epc1yPSodDvk8 ux+w+Sjac8WBLv6FWHU85JJrziprq5mvLmS4nffLIxZjjGTW1p3g7VNStEnjMEfmKWhjlk2vKB3U envWFWUsTP3I7HRSjHCw/eS3/r/hzAwcZxx60ldLPbGLwFteIJPDqhjfjn7nQ1Qn8M6zbaf9umsJ Ut9u4seoHqR1FZyoyWyvpc1jXg93bW3qdN8Prj7Xa6norvhZ4SUJ5wSMH+ea6jw4SfDliD1CuD/3 8auC+H8pTxhaoOkiyA/98E/0ru9MfybR4h0juJ0/KZ676C56UZdrr8Ys8DN/ccorq4v8Gi5YSFdF scRu37sdMf3V96mEjH/li/6f40zTv+QJY/8AXNf/AEFanos7LXovyPBGb2/55P8AmP8AGje3/PJ/ zH+NSSGG2tzcXc6QQ/3nPX6VSXxB4ekfYupgN6sjAfmRirdO1uaSV+7SBtLdlne3/PJ/zH+NG9v+ eT/mP8amePaiyKyvG33XU5BplKUJRdmOwze3/PJ/zH+NG9v+eT/mP8afRU28xDN7f88n/Mf40b2/ 55P+Y/xp9FFvMBm9v+eT/mP8aN7f88n/ADH+NPoot5gM3t/zyf8AMf40b2/55P8AmP8AGn0UW8wG b2/55P8AmP8AGje3/PJ/zH+NPoot5gM3t/zyf8x/jRvb/nk/5j/Gn1A1zlzHAvmuOvOFX6n+nWrh SnUdo6g9CTe3/PJ/zH+NG9v+eT/mP8aj8uUnLXqof7qxZA/EnJ/Smm4aE/vsOn/PSMHj6jqP1ron gK8VfcVybe3/ADyf8x/jRvb/AJ5P+Y/xpysrqGVgynkEHINLXJZjGb2/55P+Y/xo3t/zyf8AMf40 +ii3mAze3/PJ/wAx/jRvb/nk/wCY/wAafRRbzAZvb/nk/wCY/wAaN7f88n/Mf40+ii3mAze3/PJ/ zH+NG9v+eT/mP8afRRbzAZvb/nk/5j/Gje3/ADyf8x/jT6KLeYDN7f8APJ/zH+NG9v8Ank/5j/Gn 0UW8wGb2/wCeT/mP8aN7f88n/Mf40+ii3mAze3/PJ/zH+NG9v+eT/mP8afRRbzAZvb/nk/5j/Gje 3/PJ/wAx/jT6KLeYDN7f88n/ADH+NG9v+eT/AJj/ABp9FFvMBm9v+eT/AJj/ABo3t/zyf8x/jT6K LeYDN7f88n/Mf40hkYf8sn/T/GpKKLPuBm+MYJrnRLJYYZJG8wEqiliBtPpXEf2ZqH/Pjc/9+m/w r1K5/wBRb/7v9BVassdg41azk30X5HsYTNp4Wn7OMUzzb+zNQ/58bn/v03+FH9mah/z43P8A36b/ AAr0miuP+zYfzHT/AKwVf5Eebf2ZqH/Pjc/9+m/wo/szUP8Anxuf+/Tf4V6TRR/ZsP5g/wBYKv8A Ijzb+zNQ/wCfG5/79N/hR/Zmof8APjc/9+m/wr0mij+zYfzB/rBV/kR5t/Zmof8APjc/9+m/wo/s zUP+fG5/79N/hXpNFH9mw/mD/WCr/Iji9dtpj8NrdJYnjeC63FXUggfN6/71ed17nqNkNT0O9sSA S6Er9e38q8OkRopGjcYZSQR6GunF0+WNNra1vu0O7K8T7eM29Hdv7xta2ga/ceH7x5oUWWKVdksL n5XH+NZNFckJyhJSi9UelOEZxcZK6Zsa14hn1f7PGsMVra22fJghGApPJP1qCys9Q8RassEbPPdS nl3bOAO5PoBXQ6L4De8s4rzVL1LGGfHkqcb3J6demfzrQ0azj8F+PY7O4nDw3UG1JCMY3HjPpyuP xrtWHqzlGdbSLa/4BwyxNKEZQoaySf8Awdeo1vhqj2ky2urxTX0I+eMAbQeflPOR+NMOt6Un9nNq qXdrqukARFIV4lC9Bnt2/M1Lq8F74R8aDU7dXezvJNzYGQdx5U+/ORUHxPsoYdWtLuPAe4jO8Af3 cYP6/pXTUjGlCUqcbOLs1v6M5acpVZwjUldSTaa0tpqiKPVBeaBqOpSwjaurxXLRZ4we3v0rSn13 S7O71LVoNV+0RX9uVNgVJbzCABnsAOa4a31R7fRbzTVjUpdOjsx6jbnpVCuT644pW1f66/ozr+pR k3fRfpp+qOp+HsJk8XW8gHESOx/FSP612Glu0tm0pBHmXE74PHBlcj+dYvgO3On6PqetsFDLGUhL dCf/ANeBXT6ZbFNLtgeuz+prsoQ5MMr9bv8AL/I8PN6ylXcV0t+v+Zb07/kCWP8A1zX/ANBWrMKi S6jjPT7x+gqtp3/IEsf+ua/+grUsUwg1S33HCyAx5PqeR/KqopOcU/L8jyVuef6rqv8AbGvGa68x rNJNqxocYQHt7mtiODRtYsdRWHTBaLawmSOcSEnI6Bvrj3rnGsLi31d9O8tjMJPLVfXniu1vvD+o QaNFpmnwq4f57mXeF3t2HPYf4V5VBV6s6kpR5rXvpd32SXVfLax50FOTk2rmT4I1KVNQOkysWt51 YopP3WAzx+RrrQeoPVSVP1FcR4LgebxLHcgYit0d5G7DKkD+f6V2VtIJo2lHSR2cfQnNdeDcpYSL n0bS9NP1OnDNulqc3ceN7a38Oa3q7Wcp/sq8ks3iDD946uFUg9gdyk8cc8HHNmx8V200Nx9qCC4g upLZobFZrlgybd3AiVsAsASFK8rzk4rL1HwVc3njiPVUniGnSXFveXClz53nQI6oEG3Gw7lzk564 IqsfBerK9wGksrqzm1q41CXT5JXSO4RwPLDsEJyrLkpgqe/QV0WibnQSeNPDsVtDcNqkRimt2uVZ VZsRg4LNgfL83ygNglvlGW4p9r4t0S8uHhgu3YxwpPI5t5BHFG0fmKzuV2qCvPJHp14rzuTwpq/h vTBDt+0Tvodzp7fZ7aadSXleQbdi5yQwX59gG4EF8Mo6rwp4W1XSYdSlluIrWe90+zghZf3jQSRQ eWxYfdOG5GCQcUOMbAdHY69p+o3klnBJKl1HGJTBcW8kDlCSNwWRQSMjGR0/GtKuH8K+D9Q0bxGm p3SWSD+zTazNDcPLJcTmQO0zlkHLc9zjgdOncVLST0AKKKKQBRRSEZBFAHD+JPGi2U00MUbvBEwV yjAFjkA8+grFHj0KsSJbOA24gblACq+3I9eeQKTxdoFxDNcssbPbzg7tvUZ9K4uaC2eOGFnkAgTy 8ZGWGQeePUZr7HA06M6K9h21738zzKs5wm+fv+B3sXjZJr+SzBwyFgcsO2O3YcjFOfxgiTzxE/6l CzHdyQBkgDqeK4VWhS7a6BPmszueeMtjPb2FNk8mWWSSSR23qy7C3yruGCRxwcCu76u7bGPttfke h6d4tYs0yDaFfbJGTkMcA/1613ttcJdW0U8f3JFDDPoa8V0PTbq6YQ2olZXbc0rnkngZ7dgK9l06 2Npp8MB/gUCvm84jRTio/H1t+vmd2Gc3dvboWqKKK8Q6wrK1PxFp2kXdrbXcjh7hsZVCyxLtZt8h H3F+RuT/AHWPRWI1a4TxvBcw6/o1/pQu01bzNkREZkguMRzERuoOAckruO3CyscnaSrirsDqbjXt MtdSisJ7nZPLIIlJjbZ5hG4IXxtDkchScnI45GYbHxTo2o3kdra3m+SXzPJYxOqTbDh/LcgLJj/Z J9elcPZ6frOn+IZltINSiu5vEzzy7fM+zPYuuWYn/VE4/wCB5AHUCpvDfh69i1vQEhW4TT9Ea9yl 7aNDKnmkhV3hmSYkkncmAAOeSBVcqA9KoooqACiiigAooooAKKKKACs7Xbyaw0W5uYCBKgAUkZxl gM/rWjWN4q/5Fq7/AOAf+hrWlJJ1Ip90C3OZs9X8S38M80F0nlQbfNeTyY1XdwMlsdcVM954tjYK 7MpNyLTDJEP3pGQOncEHPT3qhomrW1hp2pWs+8NdeVsdYEmVdpJOVcgHrWo/ijT7m5dpYrqKNdSS +jK4lZgqhdpyw29M8EgZx0Fe17Gn/KvuNbIYLnxebiCDf+9uHkSJcRfMYyQ49sYPXr2qkniDxDLa zXKXDNDCVEjiJPl3Zxnj2PP+IoXxFmw12H9/G+oyiSJUbKpliXBOR1XA4HOOap6ZrEml2s6Q8ySy xsysuY5ECuGRx3B3Dj+RApexp/yr7gsjVTUPFLxGX7QkcQ2fvJTDGpLLvUAtgE7SDgcjvTnvPFsb BXZlJuRaYZIh+9IyB07gg56e9RXut6ZqOnyWJiubSHzopo9iiXG2ERlDll6Y4OefQVM3iyFtU1i5 8h1jvERoOAWSWPHlsecYyMkc9hyOp7Gn/KvuCyIJ9W8TW1vLPNPtiiuDbO2yM4kAyV4H69K6Xwvq NzqelNLdMHkSUpuC4yMA84471x+u60mqwWEUaMogjZpWYYLzOd0h4OME8jp1PtXS+CP+QLN/18N/ 6Ctc2LpwjTukkTJaHXXP+ot/93+gqtVm5/1Fv/u/0FVq4cR/E+78iXuFFFFYiCiiigAooooAKKKK AJIX8uUN2715v4/8PGxv/wC07dc21wctj+F//r16JRJHBd2klndoHgkGDntWnLGrB0pfJ+Z2YHFv DVebp1PB6Bwc10vibwjdaFMZog01ixysoGdvsa5qvIqU5U5cs1Zn2VKrCrFTg7o9h0rU9O8U6Ot/ c2DmTS/nA/2wM/Ljr0FQpPp3jfw9fXdzYC3mtwyiVjypAJBDenPSuF8L+K7jw1NKFiE9tNjfGTjB HcH1qzr/AI4vdYtTZwQpZ2jf6xI+rnvk+lessdTdK83d21Vt+2p5DwFRVWqasr6O+y6qxasPiRqN rYpb3FtDdPHjbJISDx0z6n3rmNV1a81q+a8vZd8pGAAMBR6AelUqK8ypiKtSKjOV0j1KeGo05OcI 2bCrml6dPquoRWduuXkOM9gO5NN0/TbvVLtbazhaSRvQcD3NejWdvZ+DLQ28BS61ucAMBz5efX0H 861wuFdaV3pFbswxuNhhof3uiLd/DbwW9j4esn3CBg8+0+g4B+pOfwFbqoI4IVHZP6msbQ9MNpCZ ZSXmkO53bkknqTW4/wByP/d/qa9OpNSbtskfGzk5tyZV07/kCWP/AFzX/wBBWkvLb7TAUBKsOVYd QfWl07/kCWP/AFzX/wBBWp6wTtb0X5EnO6gdP1TbDrge0vYxtW8jX5XHv/8AXrP/AOEa0RPmk8UW zJ/dQLu/9CP8q66W3inXEiKw9xVVdIsFbcLdAfpVTjQqvmqwu/n+hEqdOTvJFC2MD2v9m6NA8dkx zPcyD5pfb6VtogjRUXoBihEWNdqKAPanUTnzWS0S6F+SCiiioAKKKKACiiigAooooAKKKKAI5oI7 iMpKgZT6iuL1/wABW19ulthsf/Z4ruKK1pVp0pc0HZiaUlZnhs/gfV45iiLuXPU5rpNB+HbblmvW J9j/AIV6btB7Clruq5viqkORy+4xjhqUXdIp2OmW2nxBIYwMd8VcoorzW7m4UUUUgCiiigAooooA KKKKACiiigAooooAKKKKACmuiyIyOoZGGGVhkEehp1FAFP8AsjTf+gdaf9+V/wAKP7I03/oHWn/f lf8ACrlFVzy7hcp/2Rpv/QOtP+/K/wCFH9kab/0DrT/vyv8AhVyijnl3C5T/ALI03/oHWn/flf8A Cj+yNN/6B1p/35X/AAq5RRzy7hcp/wBkab/0DrT/AL8r/hVmKGKCIRQxpHGvRUUAD8BT6KTk3uwG ay7pBZ7WZcqc4OOwrgIPGd6uiQapqVrFaQXdqbm1ZLx5VJERl2SYjBU7FY5VXHyt32hu91v/AFFn /un+QrztfB9zP4dTR7/U4Zo7aya1tGhtTHsJhaHzHBdt5CsQACo+ZsgnaVzxLh7eXO+3fsKW5unx PYrcywPfvH5e/dNIrpCSgJcCUjYSoVsgEkbWz904hbxjpscatNe3MLNIIlint5o5GYqzKBGyhju2 MF4+YqVGTxVG58LNeXmoNPeottfQyQzeRbiOeRXXaBI+SrhAflOwMMAbiC++0uk6hPd2VzqGpQzP aXHnKkFr5SY8qSPGC7Nk+bkncRhQAByTzfu7bv8Ar5E6Fo+J7FbmWB794/L37ppFdISUBLgSkbCV CtkAkja2funFKTxpbC/060i+3NJeXHkMsltPG0Q2OwcqyZwSmATgcOc4RsZ7+BbOW5vi/wBkWG6+ 0FpY7JBd5mDhwZznIHmNgBQcBQSQCGfZ+EWsri1uYZNLtpYLpZ2Wy0wQRugjkQggOW3ESt8xYgYG F67q/c2+Jhoamo6/f2+rQ6bZx273EsfmL9svWtxL1ysWEcuVCksMDaGU854jtPF8M2o3NhctNa3M M0cWx2L7S8UbrvZcqhLOUGWwzKQpJ4p+s6Xd6khhjuLFrWRQsttf2P2mNiDkEAOnOeuSw+VcAc5r ReGPKsp7b7fNL5l7a3XmzDe58gQDDHPzFvIyW45bpxzMZU+XV/mGhNp/jPT74W6Lf/v5FiLrGJGS NpEV0BcqMBg4Clgu48AbgQCLxnp93bxTWV/5qytCI2cSIsiySImUO07iC4BA+6xCsVzkY2jeEb2y WSymvv8AQI7i0cL5S5m+zw24V1IbKZeIhg27IUY2/eJpXhG9bR9GTUr7E1hb2yRx+UuY9skMsiMw bD8wKqkAYGc7zzVtUU/i7f1sGhu23jHTbu2NxHe3KxmMSoZbeaMzKSADGGUGTJZR8meXUdWGbmna 5b6tHM9ldvKIZPKlBDKUfaGKkHBBAYZHUHIOCCBzl74Ykg0fSkhkmuZtKskt4kijQGV1kgdXw7qM AwAldwJBIDA4rQ8M2d/bxahc6jvE97deftkCBlHlRpghCygZQ4AZjt25JbNRJQ5XKMvxDQ6a31B4 EaKZPtFu3VGOcfTP8qxNQ8IaFq0hfTrsWVwx/wBTJwpJ7AH+ma0ajlgjlXDqDVQxT5eSquZfj95v h8XVoO9N2OPvfAWvWjfLbC4X+9E2f061mN4b1tWwdIvj9Ldj/Su9EN3Au20vriFR0VZDtH4dKa11 4iUYTVnx7xRn+a1XLhJa3a+5nrQz2ql70UzjLfwfr9ywC6bMme8q7P51tw+BbfTkWfxBqtvax4JE auNzY6gev4ZrQkXXrjiXWboD/pmwT/0ECq8PhyASmWYmWRjlnc7iT7k1S+qQ1s5epnVzuvNWjZFo a9ZWVq1h4VsWG4YN5Iu38QCMk/XH41HpelNakzzSyPO53O7MSSfUmtCG1igUBFAqas62LnUXKtF2 R5FSrKbvJ6jxNKBgSv8A99GtpCTbW5JyTGOfxNYVbqf8ett/1yH8zTwrb5r9v1FEq2EMb6LYlkU/ uweR/sr/AIVMIIR/yyT/AL5FM07/AJAlj/1zX/0FasKpeRY16scV0qClZJa2X5FWGpbq5wsKk+y1 IbBgM+Qv5CuV8Q+KJxenTNKlEEaNsknB5Zu/PYD1qG5stdtbSW7t/ELXbW+DMkVyzbPwPBqXUopu MU5cu9rf0zF1optJXsdWYEU4MSg+hWk8qP8A55p/3yKy/DXiBtbjayvABexruSQDHmD/ABrWByM1 VoSipw1TNIuMlzR2G+VH/wA80/75FHlR/wDPNP8AvkU+ilZDsM8qP/nmn/fIo8qP/nmn/fIp9FFk FhnlR/8APNP++RR5Uf8AzzT/AL5FPoosgsM8qP8A55p/3yKPKj/55p/3yKfRRZBYZ5Uf/PNP++RR 5UX/ADzT/vmn03vRyoLCeXF/zzT/AL5pDHFjlE/Kh3WNGdzhVGSa5u61uK6lMcdwijOAu4AmqjBM 1p0XN6G+0tmpwzRA/hT0+zyD5BG30Arjm8za3+ubMhxsByfk4AA7ZxVgXCxS7VlVZBwQG5z6Vp7K LOh4VdGdZ5cX/PNP++aPLi/55p/3zWZpup+fJ9nlI8zGVP8AeFalZOCRySg4uzE8qP8A55p/3zR5 Uf8AzzT/AL5FOHSlpcqJsM8qP/nmn/fIo8qP/nmn/fIp9FFkFhnlR/8APNP++RR5Uf8AzzT/AL5F PoosgsM8qP8A55p/3yKPKj/55p/3yKfRRZBYZ5Uf/PNP++RR5Uf/ADzT/vkU+iiyCwzyo/8Anmn/ AHyKPKj/AOeaf98in0UWQWGeVH/zzT/vkUeVH/zzT/vkU+iiyCwzyo/+eaf98ijyo/8Anmn/AHyK fTXdY0Z3YKijLMxwAPU0cq7BYTyo/wDnmn/fIo8qP/nmn/fIqt/a+m/9BG0/7/L/AI0f2vpv/QRt P+/y/wCNV7N9h2LPlR/880/75FHlR/8APNP++RVb+19N/wCgjaf9/l/xo/tfTf8AoI2n/f5f8aPZ vsFiz5Uf/PNP++RR5Uf/ADzT/vkVW/tfTf8AoI2n/f5f8aP7X03/AKCNp/3+X/Gj2b7BYs+VH/zz T/vkUhgiPWNPyqv/AGvpv/QRtP8Av8v+NWYpop4hLDIkkbdGRgQfxFJ07boVhNYby7ezChcbTwVB 7Cuai8QWU2oGySTMu5kDG2Ijd1zuRZCuxmGGyoJI2tkfKcdJrf8AqLP/AHT/ACFefRWmsweGj4ct bV4pYLBrWLUzOqRkiMrG67SZA2dpIKgL82GbA3Z4tJ1pXfb8kKW51vnN6J/3wv8AhR5zeif98L/h XBL4aN5qlq6aH/Z2kC4jaWw3RoMrDcq8hWJipDeZChGSWCkMNo5yR4dudLTw7aSaSjQMtoJrOOVY 1muFtrvz84OGYrsB3fK+ArNtyRiqSf2/6+8VvM9MXUI3vZbNWQ3EUaSunlDhXLBTnGOSjfl9KF1C N72WzVkNxFGkrp5Q4VywU5xjko35fSvPZ/C2qyq3mW032M+UWtYWgdjEJLtkgCS5iPliaDg/KNny klVoTwjeRJepBp80b3Nlbr9oLW7SlUuXeSA4AXLRGNAm0xYUISVUEv2UP5wt5npPnN6J/wB8L/hW fY+ILLUZ2htZNzbd6F7YosqZA3xsygSLyPmUkfMvPIzhaZ4dc+EdT0hhcWkd6ssca3HkloVeMJ9y ELGozltqk5zknLECHxFY6t4j0ma2/sx7WW2huGXfNGy3Er28sSrGQfu5kJ3OEPC/LydsKMb2cv6/ UDrLzUI7CynvLlkS3t42llfygdqqMk4AyeB2qfzm9E/74X/CuC8TeGZ5ra+trDSvtay6cYLNvtAQ 202ZTI5djuzJvQEjPmFSJCAc1Tv/AApqU0utOkF3JeXEd6Fn32yRTJIkgij3bfOfAaMbXIQFMg4R QajTi1fn/r7wt5noV3qC2Vs9xKjMiYyIbYytyccKilj17CodL1q31myW8stzW742PJatFvBAIIDq CQQRgjg0+0tILG2S3t02RpnAySSSckknkkkkknJJJJyTXM6X4fnH/CK/brXjTdKaKVTICEnH2faC AcNgxsR1AKg9QprOPK07v+ten/BEdh5zeif98L/hUDahGl7FZsyC4ljeVE8ocqhUMc4xwXX8/rXn Vv4X1qG5kYWbrFJCPt0fmQhbuRZ4XdRgBpFdBMqtMzMdzB9u4lr9zoN3LcWk1lon2KxijnEmnGZM So0luWjKK21d4jlIVW2Egbzh3U6eyin8f9feO3mdzFd+chZVwAzL88O05BIPBA4yOD0IwRkEVJ5z eif98L/hXnjeE7uRNfuJNNhe+a3n/syZtheOY3N3IpRs5Q4khbORgkdwcMtPIl8a2UMK2899b6nd S3lzDdK7tGyTiMOiktiMMkeZAuw4VchjR7JO/LK9v67hY9G85vRP++F/wo85vRP++F/wqOiubmfc kk85vRP++F/wo85vRP8Avhf8Kjoo5n3Ak85vRP8Avhf8K2UOba3PrGP5msKt1P8Aj1tv+uQ/ma6s K2+a/b9S4kGnf8gSx/65r/6CtWbVgNTjUnqjY+vH9M1W07/kCWP/AFzX/wBBWo73zYvLuYADLC24 A9x3Fd1GSjOLfl+Ra3PNVDCeQSZ8wMd2fXPNdbpLQXHh3UbWzQw3nk75pG5EiAngc8en+eE1HRTq F0Nb0LZI+8PLbNjcjj2P8qbcXfiS8hmtIdCW1acbZpIrcoX9fmPFeXDCTw9WTkm73Ssr3uuj6M89 UnTk7/kZ3g8E+LrTbnAEm7/vhq7mNg7SkdPNfH0yawNM05fDMTGRkl1i4XakaHIiU9zW7bReTboh 5IHJrtw9GVDDqnPdu/odVCDhTszyfxXqN34L17xXbWMUzf8ACQWMdxp6QMYtt2WEDiIAHfKd6ykr hvlGf71Qa9rWqeCNKn03w7eeYnhq1tBeAQRQ2+52QAMhVpJHkJkdiroFBHJbO71m70vT7+e2nvLG 1uJrVt9vJNCrtE2QcoSMqcgcj0FQah4e0TVp1n1LR9PvZlXYslzbJIwXJOMsCcZJ4966o1o6cy/r /hja54h/a95pGu6lLZGFJRrHiKZZHt45HR47ZGUqzKSvPXGM9DkVpa98RPEFtp4ey1dPOTwtZ302 2KJil1JPEGYjacEpJ93phgQOhr2GPRdKhu1uotMskuVlkmWZbdQ4kkADuDjO5gACepxzUH/CL+H/ ACfJ/sLTPK8rydn2SPb5e/fsxj7u/wCbHTPPWq9vBtNxC6PM9d8V+K9Fn8ZyDW0mTQm0+SOJrOML IZiu9OORH8zDGS/C/Pw272GqM+i6Vdfa/tGmWU32zZ9q8y3VvP2fc35Hzbe2enar1YzmpJWX9WQm FFFFZgFN706m96AMbxJcGDTtoOPMbH4Vyel6Xp97qTx3CgNN8yH37j+v510vi2Jm0rzFGfLbcfpX BrelZAUfa6kEH0I5z/KrTaO+jTU6NkbuuC50ZlghDSNIdkZPOPfP0qe38PWlnpYu9QJMh5xnkmr8 PiTSLu1ha+fbMo5G0nmue8QeI4r26Cxttt04RfXtnFVzW2FGFSo1GaskW31FYbm2mQ4InUAD0PBH 613sbb41b1Ga8ijla81aztI8k+YJHx2A6fr/ACr1yFdsKA9hUva7M8WkppIkHSlpB0pag5QrkPH2 qXulWthKk13a6ebiP7VeWqhmhxLHjdkH5CvmdFOWCA8EhuvrK1zRm1m3hRL+4s3imjkDxYYELIr4 KsCpOUGDjIPqCys1uB5r4r8eazpF1rsya1bwnT4dPl0y3WKMRamshBlcBtzuvUfu3GAOuQTU03jj WbfxOIZtUSO4PildLGkPHGAbJlAWbBHm5OQwfdtJI4xxXbTeDNOmdYpLi9fTPLhjfSpJRJauIf8A V/K4LLjC5CsA20bg2Tmb/hFrR9V+23V3e3kSXX2yCzupBLDbz7dodMjeMZbC7iqliQoIGOhVKdtv 60HdG7RRRXMIKKKKACiiigAooooAKxvFX/ItXf8AwD/0Na2aztds5r/Rbm2gAMrgFQTjOGBx+laU mlUi33QLc4jRNJtr/TtSup95a18rYizpCrbiQcs4IHStK58LWUEqoJ7lgdWSyywC/u2UNnBHXnGe h645qtZ6R4lsIZ4YLVPKn2+aknkyK23kZDZ6Zqwlt4vSaSUpveSUTHzTE4DjgMobIUgccY4A9BXt e2p/zL7zW6Gf2DpAN3K9zcrBp00sd4uRvI3FYvL+XByRg5x36CsvStITVLO6K3Cx3SSRpAjnCysw c7M9idvGeM8d+Lq6N4lWC7h8lil2VafdJGS5ByCSTnqc1EPDevLbvALT907q7L5kfJUEA9f9o/nR 7an/ADL7wuia50Oz03S2vbtLp2EsUPkq4jZGaESMSSp7nGMDGOpq5J4Ts0u723Wec/YrqHznYgAW 8gBJ6H5l5JJwMDNRfYvFjCQSRLMJCrMJ/JlBZV2hsNnnHGep71H/AGZ4p+1XVyY2M13G0UztJGdy tjI5PHQdOmOKXtqf8y+8Lora1ottpenxzK8rPcXMotzkFTApwGPA5OQQRwQc10Pgj/kCzf8AXw3/ AKCtYV1oXiK98n7Rbb/IiWGP54xtReg4PvXUeF9OudM0porpQkjyl9obOBgDnHHaubF1ISp2TTJk 9DX1lgsFnlFb5T1z6D0rmYvEOiz6gdPhv9OkvQzIbdLkGQMudw2hs5GDn0wa6TW/9RZ/7p/kK8li tbuZjZLc6yJRrbXH2N7HbbeWL0ylvNMQ42DeP3nJwBnIWvIxMFKvK/l+X9f5mctz0bzF/wCeKfm3 +NRm6gWdYCsIldS6xljuZQQCQM9AWXP1HrXnulQ66LO6N5faoZ2tcXix2cw8ubcuSpeX5wB5nFsF yudpDeVVnRrST/hJNIu5k1ZlFvdwpJMbjy85hIJV/mQNiQ4lydwwCwWM1zuklfX8PImx2H9t6V/a f9m/a7H7f/z6+ePN6bvubs9OenTmrJuoFnWArCJXUusZY7mUEAkDPQFlz9R61y0WkX17resCaZId ObU4LkRm3bzJWjit2UrIWxt3xgH5T91hkHpkxW+uW+j6GTNq0skunCTUS7OXBMlp5i4HIcRCYKFG /IYjLkkipxdrP+rXCx35uoFnWArCJXUusZY7mUEAkDPQFlz9R61J5i/88U/Nv8a8/vor2d7KHTTr 40522sZnmRwpubQN8xIlA2+fy53Ab8fJip5YtRttRmtXOsnTIJpFtGt3d5TKYrdovnYksu5rjmQm MHhuAoB7K63Cx3PmL/zxT82/xo8xf+eKfm3+NYvhaaW48I6LPPI8sslhA7yOxZmYxqSST1JNa1YS vFtCJPMX/nin5t/jR5i/88U/Nv8AGo6KXMxEnmL/AM8U/Nv8aPMX/nin5t/jUdFHMwJPMX/nin5t /jR5i/8APFPzb/Go6KOZgSeYv/PFPzb/ABo8xf8Anin5t/jUdFHMwJPMX/nin5t/jR5i/wDPFPzb /Go6KOZgSeYv/PFPzb/GtlOba3OMfuxx+JrCrdT/AI9bb/rkP5murCu/N6fqXEg07/kCWP8A1zX/ ANBWpyMjBqDTv+QJY/8AXNf/AEFanrp6L0X5FGXc6Orz/aLWaS2n/vxMVJ+tR/ZNccbJNZm2f7IU H8wM1sUVpGrOKsmFyjY6XDZZYZeQ/edjkn8avUUVDberAKKKKQBRRRQAUUUUAFFFFABTe9OpMUAQ 3MC3Nu8TjIYYrybxDodxpM8g8tzbOc70GfoD7V6/iop7WK5QpKgYe9Un3NaVaVJ3R4Qb6Ik7riMD cSfn5xio0uDcsiWsJupckhgMIDx1P4dq9fn8GaVPJvaFc/SrVn4bsLNgyRAkdzVLlOp47TRHNeC/ DD2jG+u8tM/JJGOfb0Fd3QECgAAAClxUylc4ZScndgOlLQKKkQUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADNZKCCz3Kx+U4wcdh7VzK67pDwWEwnxHfqr2xZsb1YDB wV4BLKOcfM6r1YA9Jrf+os/90/yFedxeFp5m1JZ5vLKSSnTptoPltJN9pMu0HnEnlrtbr5GejkVn iuV15cz7fkiZbnUwXlncS3MUW9ntpBFKN2NrFFfHTn5XU8etE95Z28ttFLvV7mQxRDdncwRnx04+ VGPPpXBzeHNRe0lMumefd3lu72r74z/ZV1JLNKzbiwI2mWMb4wWPk5wMKKmufC+oNpx+xR/Z9Rl1 G/ma4M2DGrpdrCwYElQDKhwvQuxxktWPs4fzfkKyOwudX0yz+2ee7p9itxdXHU7Ijvw3C8/6t+Bk 8e4p76lp0eoR2DyYupF3JGX5I59upCsQOpCORna2Of8ADmlyWetaldJpH9l2U9vbpBb+Yh2lGmLf IhKx/fBwpIO7d94sBTsfDV7YaKs4XzdVsPKSzXKrvit1aNU67R5qtMcnJTz++wVPLC7V+3br/kGh 1llqNjqCTPbCZlhmeBywKDeh2sBuUbgCCMjIyDzxVaS00DxJZWl5cadb39u8Ylt3uIlfCuAcgMuR kYrj7Xwpe6c6wSWX9pWkOIoV81YsyC2tY0uOuY9phlG5cyLu+UHNQ6R4U1K3u9LkvILv7RBHZhJY 3tglukcUayRmQqZhllkysfyMHwSNzkackFrGf5BY7m+1vTdPnWCZLySUrvMdtBJOyqSQCwjRtoJB xnGcHGcGprPUtO1EStZyeesTKrMj5XLIrjBxggq6nIyOaxtct7j7alxa2GotN5YVbvTbiJXGCcrI krBHGD8uQ+Cz4CnBOYnh/UGlutRubWE6u+o2cqzQyfKsYS3WcxbjlAQsqnozKADkYrOMYON27fcB 2UM0E8EcyRzBXUMA+UYAjPKlQQfYjIolmghQM0cxBZV+TLHJIA4CnjJ5PQDJOADXmnhzQ72Nzbtp 229tbiwQ3nnqfsvl21qZkxn5d6gplM784bCgGjQNDvbjQtCmtdO+zqtvZPcSeerfa8T28ivkncfL jjkGGA27tqbhVujFP4u3bqFj0/MX9x/++x/hRmL+4/8A32P8K82k8PnQ/D2lv9ltLCGPTo11YeZH Es8iy2xMchyFcsonQFjtO8gkBjnc8EeU1tq09tAkNnPf77ZY5hKnl+REuFYZXAKlcKSqlSoJCiol TSi5J3+SCx1uYv7j/wDfY/wozF/cf/vsf4VHRWHMySTMX9x/++x/hRmL+4//AH2P8Kjoo5mBJmL+ 4/8A32P8KMxf3H/77H+FR0UczAkzF/cf/vsf4Vspj7Nb46eWP5msKt1P+PW2/wCuQ/ma6sK783p+ pcTnrLxVaW1jBbtFMTHGqn5FIyAAcZPtU/8AwmFl/wA8Zv8Av0n+NFFcyxlZKyY7sP8AhMLL/njN /wB+k/xo/wCEwsv+eM3/AH6T/Giin9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKP rtbuF2H/AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3 /fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hM LL/njN/36T/Giij67W7hdh/wmFl/zxm/79J/jR/wmFl/zxm/79J/jRRR9drdwuw/4TCy/wCeM3/f pP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF2H/CYWX/ADxm/wC/Sf40f8JhZf8APGb/AL9J/jRRR9dr dwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKPrtbuF2H/AAmFl/zxm/79J/jR/wAJhZf8 8Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3/fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH /CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hMLL/njN/36T/Giij67W7hdh/wmFl/zxm/ 79J/jR/wmFl/zxm/79J/jRRR9drdwuw/4TCy/wCeM3/fpP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF 2H/CYWX/ADxm/wC/Sf40f8JhZf8APGb/AL9J/jRRR9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54 zf8AfpP8aKKPrtbuF2H/AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP 8aP+Ewsv+eM3/fpP8aKKPrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/n jN/36T/Gj/hMLL/njN/36T/Giij67W7hdinxnaMADFOQOmY04/Wk/wCEwsv+eM3/AH6T/Giin9er PqF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFL67W7hdh/wmFl/zxm/79J/jR/wmFl/zxm/79J/ jRRR9drdwuw/4TCy/wCeM3/fpP8AGj/hMLL/AJ4zf9+k/wAaKKPrtbuF2H/CYWX/ADxm/wC/Sf40 f8JhZf8APGb/AL9J/jRRR9drdwuw/wCEwsv+eM3/AH6T/Gj/AITCy/54zf8AfpP8aKKPrtbuF2H/ AAmFl/zxm/79J/jR/wAJhZf88Zv+/Sf40UUfXa3cLsP+Ewsv+eM3/fpP8aP+Ewsv+eM3/fpP8aKK PrtbuF2H/CYWX/PGb/v0n+NH/CYWX/PGb/v0n+NFFH12t3C7D/hMLL/njN/36T/Gj/hMLL/njN/3 6T/Giij67W7hdh/wmFl/zxm/79J/jTW8XWT4zFccDAwij+tFFDxlZ7sLs//Z --------------ms060006060509040207060202-- From wannko_2006@yahoo.co.jp Wed Feb 08 11:07:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rqe-0007vZ-Hl for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 11:07:16 -0500 Received: from ocn.ne.jp ([221.212.59.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04877 for ; Wed, 8 Feb 2006 11:05:32 -0500 (EST) Date: Wed, 8 Feb 2006 11:05:32 -0500 (EST) Message-Id: <200602081605.LAA04877@ietf.org> Received: from hjdlzbaj6 (unknown [200.231.39.58]) by smtp57 (Coremail) with SMTP id GR8mBdtw9g0y72ia.1 for ; Wed, 05 Mar 2003 09:06:09 +0800 (CST) X-Originating-IP: [200.231.39.58] Subject: =?iso-2022-jp?B?GyRCTl4kR0o4O3okLCRLJDgkXyReJDkbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: base64 GyRCNkgzJj1pIzFGfCMxREwlYSE8JWshKiQ9JE5MPiROREwkakNLQC0kYj13QC0kYkFqPGokSyVh ITwlayRyIzFGfCMxREwkNyQrQXckbCReJDskcyEqGyhCDQobJEIkSSQmJDckRiEpJEg7VyRvJGwk P0p9JGJCPyQkJEgkTztXJCQkXiQ5JCwhIjtkPCs/SCQsPychOSRKPVAycSQkN08lNSUkJUgkck14 TVEkNyQ/N2syTCEiGyhCDQobJEJFUE8/JHI6USReJDskP0Q+OGVMNT90JE4lYSE8JWskLDtkJE4l YSE8JWslXCVDJS8lOSRyS2QkYSREJC8kNyReJDckPyEjGyhCDQobJEIkMyRsJEckT0ZJJGAkTiRL QDowbEdVISI3eTAtNDYkYj1QJEAkNyQ9JGwkKyRpMGxAWk14TVEkOSRrO3YkcjwtJGEkPyROJCxN fU0zJEskSiRqJF4kOSEjO2QkLDojMnNOKSRBPmUkMiQ/JTUlJCVIJE8bKEINChskQj13QC0kTjUk O30kQSRLR1tOOCQ3JD89UDJxJCQ3TyRIJEokQyRGJCokaiReJDkhIiQ9JDckRj13QC07KDtvJEsk NyQrOS05cDdHOlwkNyRGJCQkSiQkMFkhIkZ8ITk9d0AtMnEwdyQsQX0yQyQ3JEYkKiRqJF4kOSEj GyhCDQobJEIkNyQrJGIkMyROJTclOSVGJWAkQCRIJTUlLyVpNkg8VCRiRn4kajl+JGA7diQsPVBN aCReJDskcyEjIzFGfCMxREwkQCQxJEgkJCQmJE4kT0NLQC1CJiQrJGkkXyRsJFAlYSVqJUMlSCQs TDUkJE1NJEsbKEINChskQjtXJCgkXiQ5JCwhIj13QC1CJiQrJGkkOSRsJFA7ZCRyQSokcyRHJWEh PCVrJHI9UCQ3JEYkLyRsJD8kTiRAJEg7VyQkP0Y2YTQ2JGIkbyQvO3YkRyQ3JGckJiEjGyhCDQoN ChskQiQzJE4lNSUkJUgkT0tcRXYkS054P00kLCRbJDckJCRIO1ckJkNLPXckTjBZJEs6biRpJGwk PyU1JSQlSCRHJDkhIzpyOiMlOyVVJWwkZDFnPXU4cjpdJEokSSRHQC0kTkJQPl0kRyQ3JCskSiQk GyhCDQobJEI9UDJxJCQ3TyU1JSQlSCRHJDkkLCEiJD0kTk1NJEolNSUkJUgkSCRPMGxAfiRyMHok JCQ/JGIkTiRIOEAkQyRGJGIkaCQkJEckNyRnJCYhIxsoQiANCg0KDQobJEIkXiQ/NDBBNEw1TkEk RyQ5JE4kRyEiNj1MIyROJCIka0p9JE9AJ0hzJDRNeE1RJE5EeCQqQlQkQT89JDc+ZSQyJEYkKiRq JF4kOSEjGyhCDQobJEI6IzJzRXYlNSUkJUgkTj4hPGokSiVhITwlayRLJGgkajUkSiwkcjMyJDUk bCQ/Sn0kYiQkJGs7diRIJE87VyQkJF4kOSEiQmdKUT89JDdMdSQiJGokXiQ7JHMkRyQ3JD8hIhso Qg0KGyRCPzwkLyQqT00kUz89JDc+ZSQyJF4kOSEjGyhCDQoNClVSTBskQiEhGyhCaHR0cDovL2F3 Zy53ZWJjaHUuY29tL2Nhc2Fub3ZhLz8xOTIzDQobJEIlYSE8JWtJVE1XJEpKfSRPJDMkQSRpIi0b KEINCmNvbmNlcHQzX25ldEB5YWhvby5jYQ0KDQo= From owner-namedroppers@ops.ietf.org Wed Feb 08 13:27:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6u2Y-0005jY-MN for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 13:27:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19026 for ; Wed, 8 Feb 2006 13:25:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6txw-000I3f-0H for namedroppers-data@psg.com; Wed, 08 Feb 2006 18:22:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6txu-000I3H-9W for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 18:22:54 +0000 Received: from [10.31.32.190] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k18IMhqU047425; Wed, 8 Feb 2006 13:22:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060208033339.0699D11426@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> <20060208033339.0699D11426@sa.vix.com> Date: Wed, 8 Feb 2006 12:27:50 -0500 To: Paul Vixie From: Edward Lewis Subject: Re: the RD bit is troubling me today Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:33 +0000 2/8/06, Paul Vixie wrote: ># ... ># What this means is that no matter what the setting of the RD is the server ># ought to answer with the learned NS set over the authoritative NS set when ># the learned set is more trustworthy. (Applying to the case where the QNAME ># is a zone cut, etc.) > >i disagree with this interpretation in two ways. > >first, an authority server doesn't send answers when asked for non-apex NS, >it sends a referral. that is, if you ask the COM-zone servers for VIX.COM NS, >you should get back a response with an empty answer section and a non-empty >authority section. > >second, an authority server should not, in general, fetch any glue or >otherwise send any packets to anybody, and especially, it should never answer >differently unless its own authority zone data has been made different. I think what you said agrees with my interpretation. ;) In my text I refer to "learned NS set" - which may be a null set, which is what a nominal authority server would have. (I.e., authority only means not learning.) Looking at the COM-zone servers you do see what I call hybrid responses (sorry, in my text, where I said answer, I should have said response) that have the NS records in the answer section. In this instance, "learned" is not from caching but from being fed by the registry behind the servers. No non-recursive server ought to do more than the priming queries for the root zone. That's clear. To underscore this, when I say "learned" I am assuming "passively learned" in this case - the result of the server learning for another reason. ># It's tempting to make (a) DNS (server) be able to answer with the ># authoritative data when RD=0 and the learned data when RD=1, but I'd say ># this is a "siren's call." > >i'm not tempted by any sirens here. i just want to know what the right thing >is, so that i can do it, and complain if/when others don't, and test for it in >conformance suites, and so on. none of that is possible while this case >remains undefined. I understand. Nevertheless I think that if we open up the protocol to say "RD=0" means that a server expose data that would otherwise be obscured by what's learned passively relative to the query at hand then we are reacting to a siren's call. (I.e., undesirable feature creep in the protocol.) ># I'm no longer against mixing caching and authoritative servers. I think ># that the reasons once used to justify separating the two have largely ># vanished. I think that there are now valid reasons to combine them into ># one (at times). > >i think i've pointed out a case where a server's answer not defined by the >spec, where authority and recursion are done on the same IP/UDP listener >address. since undefined is not what we usually want in a spec, and isn't >what folks think this spec offers, i'm calling that a problem. > >we can decide that it's not really undefined, or that it's always been >undefined and everybody knew it but me and i'm chasing parked cars again, or >that it's not defined but the operational cost is low so we'll just document >it as undefined, or we can say that it's undefined and should become defined, >or we can say that it's undefined and therefore not a recommended practice. I don't like to say that "because X is undefined, don't do it." If X solves a need, do it and clarify it. Don't let the specification lead the code, don't let the code lead the service, don't let the service lead the demand. As engineers, we have to remain ready to answer the needs of the populace, not the other way around. I say this in support of defining what needs defining in this case and not because I saw you falling behind in a race with a parked car. >our chairs will have to take the lead on determining which way we want to go. The only thing I disagree with is that the chairs don't need to lead, we need to have the WG talk about this. The chairs only need to detect when we've gotten to tired to fight and they declare "consensus." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 13:33:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6u8M-0008NM-Q7 for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 13:33:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19483 for ; Wed, 8 Feb 2006 13:32:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6u6d-000Ipj-4R for namedroppers-data@psg.com; Wed, 08 Feb 2006 18:31:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6u6c-000IpT-As for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 18:31:54 +0000 Received: from [10.31.32.190] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k18IVWFb047465; Wed, 8 Feb 2006 13:31:43 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060208080651.B93A311426@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> <6.0.3.0.0.20060207055855.084c3d60@127.0.0.1> <20060208080651.B93A311426@sa.vix.com> Date: Wed, 8 Feb 2006 13:31:29 -0500 To: Paul Vixie From: Edward Lewis Subject: Limiting recursion...was Re: the RD bit is troubling me today Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:06 +0000 2/8/06, Paul Vixie wrote: >There's another, more extreme problem with dual-purpose servers, and that's >security. Recursive nameservers which are open to the internet are, because >of the widespread ridicule heaped upon RFC2827/BCP38 and SAC004, "dangerous". >(I am aware of a multi-gigabit attack occuring against a neighbor, even as I >type this, involving a few thousand open-to-recursion nameservers, 4K TXT RRs, >a low-intensity spoofed source query stream from a botnet, and EDNS0.) Since >it's operationally difficult to use different ACLs for recursion vs authority, >most people just don't do it. So most dual-purpose nameservers are fully open >and thus "dangerous". So if we do manage to nail down a practical >interpretation of dual-purpose, I'll want the resulting clarification document >to sing most expansively the damnation against open recursive servers, and if >I am an author of such a document, it will advise "just don't do it" as the >safest course of action. When you say "security" you mean potential for abuse on the public Internet, not security as in the safety of what you learn, right? Just because "most dual-purpose nameservers are fully open" doesn't mean that dual-purpose shouldn't be clarified if the specs are unclear. What needs to be made more clear is that open recursers are a problem - regardless if whether they are also dual-pupose. Perhaps default settings of nameserver implementations ought to limit recursion to the loopback address, forcing a conscious decision on the deployer of the server to know what they are driving on the street. For me, my most common use of dual-purpose has been with BIND views, defining one view that has no recursion and answers to the outside world and another view that has my split-brained zones and recursion allowed for internal machines. This is my "most common"...I will say that when I dual-purpose a server it usually is done with BIND's views whether or not split-brain is involved. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 13:33:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6u8V-0008O4-7n for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 13:33:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19512 for ; Wed, 8 Feb 2006 13:32:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6u6W-000Ioa-Jo for namedroppers-data@psg.com; Wed, 08 Feb 2006 18:31:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6u6V-000IoM-Jt for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 18:31:48 +0000 Received: from [10.31.32.190] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k18IVWFZ047465; Wed, 8 Feb 2006 13:31:33 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060208080651.B93A311426@sa.vix.com> References: <20060204013717.6BD8111427@sa.vix.com> <6.0.3.0.0.20060207055855.084c3d60@127.0.0.1> <20060208080651.B93A311426@sa.vix.com> Date: Wed, 8 Feb 2006 13:24:29 -0500 To: Paul Vixie From: Edward Lewis Subject: Re: the RD bit is troubling me today Cc: "Paul V. Mockapetris" , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've been trying to understand why mixing authority data and cached data is confusing or ill-defined. Perhaps there are two angles. 1) CNAME?DNAME that "crosses" from authority to cache or vice versa. 2) At a delegation point, when considering the algorithm in 1034/4.3.2. (I.e., the RD bit is the tip of the iceberg.) At 8:06 +0000 2/8/06, Paul Vixie wrote: ># -- ># ># Anyway, if RD=0, I'd argue that the authority section of the response ># should contain a delegation and the answer section cached data if available. This sounds like what the COM-zone servers appear to do today, if you interpret "cached data" as "otherwise learned data." ># If RD=1, the answer section has the answer, with aa set if the answer came ># from a zone's authoritative data, 0 otherwise. > >I am pleasantly surprised by your RD=0 clarification, but the RD=1 baffles me. > >For the RD=0 case, no existing server of which I'm aware works this way, and >noone I've spoken to about this who has read 1034 and 1035 interpreted it this >way. However, I can see the consistency in it and I can live with the ruling. > >In the RD=1 case, you'd have a dual-purpose server respond with data that did >not come about by recursion, and is in practical terms "less credible than" >what would result from querying the child zone's authority servers for it. I don't see a problem here. If I ask a server for data, I may assume some context like "I'm asking the tld server and expect to get back a referral to the next-level server." The server doesn't have the context and would say "I'm being asked about this Q-tuple, let me find the most specific answer I can." The disconnect we often make (and this came up repeatedly when developing the DS record years back) is that we forget the context assumed by the client is not the same context assumed by the server. Ergo - the client shouldn't be surprised to find data it would label less credible/trustworthy from a server because it thought the server wouldn't answer from cached data. The client should always expect the most trustworthy data it can get. >To help understand my bafflement, consider that regeneration is all the rage, >and AA=1 never occurs after recursion in BIND9. In BIND4 and early BIND8, we >passed through the initial AA=1 from the authority server but gave back AA=0 >on subsequent queries for the same data. For a BIND9 recursive server, AA=0 >on all responses. I regard the current BIND9 behaviour as "more correct." I think that BIND9 is "more correct." But I don't see why regeneration is baffling in this case. (Unless it has to do with 4.3.2.) If any part of the answer section comes from learned data (passively or actively cached), then the AA is off. Otherwise it is on. When I say "part" I am thinking of CNAME situations, in particular. If a wild card domain name is in the cache, that is not a source of synthesis. One more thing to keep in mind. ># -- ># ># I can imagine lots of reasons where I might want to have a server configured ># to be authoritative only or caching only, but I don't think the one can ># credibly argue that the behaviour is "undefined" for a mixed server. > >I hope you're right, but I'd like to understand more about your reasoning in >the RD=1 case. I really think that if a requestor wants recursion, that the >data they should be given should be the result of recursion. If any other >RA=1 server were to respond with parent-zone-glue rather than child-zone-data >in this case, we would call that server "defective". I disagree with "if a requestor wants recursion, that the data they should be given should be the result of recursion." Maybe this is where some confusion lies. I see that the RD bit is a direction from the client to the server on how to handle the query. Ordinarily the RD=1 only from stub to recursive cache, RD=0 for all full resolvers. Exceptions to this are not a problem though, I would think. If an implementation of a full resolver wanted to send RD=1 all the time to off-load it's work. I don't think the server ought to determine what the resolver is asking for based on the header bits. Yes, RD=0 says give me what you have but don't go looking elsewhere. To me that's query management, not data lookup management. That's my interpretation though, not based on any portion of a spec. > >--- > >There's another, more extreme problem with dual-purpose servers, and that's >security. Recursive nameservers which are open to the internet are, because >of the widespread ridicule heaped upon RFC2827/BCP38 and SAC004, "dangerous". >(I am aware of a multi-gigabit attack occuring against a neighbor, even as I >type this, involving a few thousand open-to-recursion nameservers, 4K TXT RRs, >a low-intensity spoofed source query stream from a botnet, and EDNS0.) Since >it's operationally difficult to use different ACLs for recursion vs authority, >most people just don't do it. So most dual-purpose nameservers are fully open >and thus "dangerous". So if we do manage to nail down a practical >interpretation of dual-purpose, I'll want the resulting clarification document >to sing most expansively the damnation against open recursive servers, and if >I am an author of such a document, it will advise "just don't do it" as the >safest course of action. I think that deserves another Subj: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 14:30:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6v1h-0002wN-Ig for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 14:30:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24299 for ; Wed, 8 Feb 2006 14:29:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6uy5-000NVn-7r for namedroppers-data@psg.com; Wed, 08 Feb 2006 19:27:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6uy3-000NVW-D1 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 19:27:07 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k18JR0uM047709 for ; Wed, 8 Feb 2006 14:27:00 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k18JR0nf047708 for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 14:27:00 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6uGM-000Jr1-L3 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 18:41:58 +0000 Received: from abhaya.fugue.com (lam.fugue.com [66.93.162.226]) by toccata.fugue.com (Postfix) with ESMTP id E896E1B2098; Wed, 8 Feb 2006 11:41:53 -0700 (MST) From: Ted Lemon Organization: Diamond Mountain To: Pekka Savola Subject: Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Wed, 8 Feb 2006 11:41:51 -0700 User-Agent: KMail/1.8.3 Cc: Ralph Droms , namedroppers@ops.ietf.org, dhcwg , Stig Venaas , Olaf Kolkman , =?utf-8?q?=C3=93lafur_Gu=E2=80=BAmundsson_/DNSEXT_co-chair?= , Harald@alvestrand.no References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602081141.52073.mellon@fugue.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Wednesday 08 February 2006 05:57, Pekka Savola wrote: > http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html It's because of this one that I'm arguing that we should just not do the hash at all. Algorithm-switching is expensive. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From necojp@citiz.net Wed Feb 08 15:31:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vxu-00049b-4P for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 15:31:02 -0500 Received: from ocn.ne.jp ([218.8.50.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29720 for ; Wed, 8 Feb 2006 15:29:13 -0500 (EST) Date: Wed, 8 Feb 2006 15:29:13 -0500 (EST) Message-Id: <200602082029.PAA29720@ietf.org> Received: from aan4 (unknown [77.110.40.181]) by smtp69 (Coremail) with SMTP id BCevuhttpGpXrzFE.1 for ; Sun, 30 Mar 2003 14:40:56 +0800 (CST) X-Originating-IP: [77.110.40.181] Subject: =?iso-2022-jp?B?GyRCOEJEaiM1IzA/TSROMnEwd01NJEtBdz8uJDUkOyRGRDokJCRGGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2F640.3E3118A0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2F640.3E3118A0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCJCo1Uk1NJEszTjxCJEckaCRqTkkkJD1QMnEkJCRyJCpGTyQxJDkkazBZJEshIkV2PFI0SU19 JE4lRyE8JT8lWSE8JTkkKyRpISIlaSVzJUAlYCRLIzUjMD9NJE4ycTB3TU0kSyVHITwlPyRyQXck aSQ7JEZEOiQkJEYkKiRqJF4kOSEjJC0kSyRKJGs9d0AtJCwkJCReJDckPyRpISIyPDUtJE4laiVz JS8lVyVtJVUlIyE8JWslWiE8JTg6OD5lJE4lXCU/JXMkciUvJWolQyUvJDkkbCRQRD5AXCVhJUMl OyE8JTgkciQqJC8kayQzJEgkLCRHJC0kXiQ5ISMbKEINCg0KDQoNChskQjo7PyUhShsoQjI1GyRC IUsbKEI6OhskQjI7M1okOSQtJEo/TSQsJCQkJCUrJUohQSEjRVRGYiROMjtCZyRyJEckRjI7M1o2 NTw8JEdAaEA4JGQkQyRGJF4kOSEjJEkkcyRKMjszWiRiJC0kLyROJEchIiQkJCRPQ0FqPGokSyRK JGokXiQ5JGghSj5QIUsbKEINCmh0dHA6Ly9hd2cud2ViY2h1LmNvbS9jYXNhbm92YS8/MTkzMQ0K DQoNChskQiVKJUohShsoQjMzGyRCIUsbKEI6OhskQj8/N3UkSz1QMnEkJCRyNWEkYSRGJF4kOSEq JF4kOiRPJWEhPCVrJCskaSQqT0MkNyRGJF8kXiQ7JHMkKyEpPmUkKyRpIzgjNiElIzYjMCElIzgj OD9IRDkkTzliJGEkRyEiJCo7UDdPJEozSjklJDckRiReJDkhIxsoQg0KaHR0cDovL2F3Zy53ZWJj aHUuY29tL2Nhc2Fub3ZhLz8xOTMxDQoNCg0KDQoNCg0KDQovLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8NChskQiVhITwla0lUTVckTkp9JE8kMyRBJGkkSyVhITwlayRyIi0bKEINCmNv bmNlcHQzX25ldEB5YWhvby5jYQ0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vDQoN Cg0K ------=_NextPart_000_0006_01C2F640.3E3118A0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgDQpmYWNlPSJNUyBVSSBHb3Ro aWMiPhskQiQqNVJNTSRLM048QiRHJGgkak5JJCQ9UDJxJCQkciQqRk8kMSQ5JGswWSRLISJFdjxS NElNfSROJUchPCU/JVkhPCU5JCskaSEiJWklcyVAJWAkSyM1IzA/TSROMnEwd01NJEslRyE8JT8k ckF3JGkkOyRGRDokJCRGJCokaiReJDkhIyQtJEskSiRrPXdALSQsJCQkXiQ3JD8kaSEiMjw1LSRO JWolcyUvJVclbSVVJSMhPCVrJVohPCU4Ojg+ZSROJVwlPyVzJHIlLyVqJUMlLyQ5JGwkUEQ+QFwl YSVDJTshPCU4JHIkKiQvJGskMyRIJCwkRyQtJF4kOSEjGyhCPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPRskQkFXQk4bKEIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0iTVMgVUkgR290aGljIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCANCmZhY2U9Ik1TIFVJIEdvdGhpYyI+GyRCOjs/JSFKGyhCMjUbJEIh SxsoQjo6GyRCMjszWiQ5JC0kSj9NJCwkJCQkJSslSiFBISNFVEZiJE4yO0JnJHIkRyRGMjszWjY1 PDwkR0BoQDgkZCRDJEYkXiQ5ISMkSSRzJEoyOzNaJGIkLSQvJE4kRyEiJCQkJE9DQWo8aiRLJEok aiReJDkkaCFKPlAhSxsoQjxCUj48QSANCmhyZWY9Imh0dHA6Ly9hd2cud2ViY2h1LmNvbS9jYXNh bm92YS8/MTkzMSI+aHR0cDovL2F3Zy53ZWJjaHUuY29tL2Nhc2Fub3ZhLz8xOTMxPC9BPjxBIA0K aHJlZj0iaHR0cDovL3d3dy5kZWFpLXN0eWxlLm5ldC9jYXNhbm92YS8/MTkzMSI+PC9BPjwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIj4NCjxE SVY+PEJSPhskQiVKJUohShsoQjMzGyRCIUsbKEI6OhskQj8/N3UkSz1QMnEkJCRyNWEkYSRGJF4k OSEqJF4kOiRPJWEhPCVrJCskaSQqT0MkNyRGJF8kXiQ7JHMkKyEpPmUkKyRpIzgjNiElIzYjMCEl IzgjOD9IRDkkTzliJGEkRyEiJCo7UDdPJEozSjklJDckRiReJDkhIxsoQjxCUj48QSANCmhyZWY9 Imh0dHA6Ly9hd2cud2ViY2h1LmNvbS9jYXNhbm92YS8/MTkzMSI+aHR0cDovL2F3Zy53ZWJjaHUu Y29tL2Nhc2Fub3ZhLz8xOTMxPC9BPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy88QlI+GyRCJWEhPCVrSVRNVyROSn0kTyQzJEEkaSRLJWEhPCVrJHIiLRso QjxCUj48QSANCmhyZWY9Im1haWx0bzpjb25jZXB0M19uZXRAeWFob28uY2EiPmNvbmNlcHQzX25l dEB5YWhvby5jYTwvQT48QSANCmhyZWY9Im1haWx0bzpjb25jZXB0X25ldEB5YWhvby5jYSI+PC9B PjwvRElWPg0KPERJVj4vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy88QlI+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPjwvRk9OVD4mbmJz cDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0006_01C2F640.3E3118A0-- From owner-namedroppers@ops.ietf.org Wed Feb 08 16:16:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wg2-0001Xf-5L for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 16:16:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03915 for ; Wed, 8 Feb 2006 16:14:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6wcs-00050g-Qv for namedroppers-data@psg.com; Wed, 08 Feb 2006 21:13:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS,SPF_FAIL autolearn=no version=3.1.0 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6wcs-00050S-2d for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 21:13:22 +0000 Received: from abhaya.fugue.com (lam.fugue.com [66.93.162.226]) by toccata.fugue.com (Postfix) with ESMTP id A1D091B2099; Wed, 8 Feb 2006 14:13:21 -0700 (MST) From: Ted Lemon Organization: Nominum, Inc. To: dhcwg@ietf.org Subject: Re: DDNS IESG Issue resolution. Date: Wed, 8 Feb 2006 14:13:19 -0700 User-Agent: KMail/1.8.3 Cc: Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602081413.20233.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I just had a conversation on the phone with Sam Hartman, which I hope will turn out to have been constructive. Basically, Sam agrees that it's unlikely that we will need to change the hash algorithm in the future, but won't go so far as to say that he's sure we won't. So what he asked us to do is to put an algorithm identifier on the DHCID, but not make any other changes (we could change to SHA-1 or SHA-256 as our initial algorithm, and that might mollify some folks; since it's basically a search and replace on the document, I think it's worth doing). The idea is that in the unlikely event that we at some future date need to change the hash, then AT THAT TIME we write a draft that tells us how to do updates in the transitional state where more than one hash might still be present in the DNS. For now, we just put the identifier there and don't change anything else. This seems like a reasonable compromise - since we're claiming that we're never going to need the additional complexity, hopefully this postpones the work to describe and implement that complexity forever; if it turns out that we're wrong, we have a path forward. I can go more into the reasons why we agreed on this particular approach if anyone's interested, but unless you are, I'll just leave it at 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 16:21:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wkS-0003gy-Vn for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 16:21:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04274 for ; Wed, 8 Feb 2006 16:19:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6who-0005QC-TK for namedroppers-data@psg.com; Wed, 08 Feb 2006 21:18:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6whk-0005Pv-Px for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 21:18:28 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2006 13:18:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="21468845:sNHT23086128" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k18LHm6l026019; Wed, 8 Feb 2006 16:18:21 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 16:18:09 -0500 Received: from 10.86.240.172 ([10.86.240.172]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Feb 2006 21:18:09 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 08 Feb 2006 16:18:07 -0500 Subject: Re: DDNS IESG Issue resolution. From: Ralph Droms To: Ted Lemon , CC: , "Hartman, Sam" , Message-ID: Thread-Topic: DDNS IESG Issue resolution. Thread-Index: AcYs9SefZeRH55joEdqe0AARJOT6eg== In-Reply-To: <200602081413.20233.Ted.Lemon@nominum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 21:18:09.0494 (UTC) FILETIME=[291BDF60:01C62CF5] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Are there any export or other restrictions on SHA-1 or SHA-256 at this time? Otherwise, sounds like a reasonable compromise. Late binding to pay the price when we need to solve the problem. - Ralph On 2/8/06 4:13 PM, "Ted Lemon" wrote: > I just had a conversation on the phone with Sam Hartman, which I hope will > turn out to have been constructive. Basically, Sam agrees that it's > unlikely that we will need to change the hash algorithm in the future, but > won't go so far as to say that he's sure we won't. > > So what he asked us to do is to put an algorithm identifier on the DHCID, but > not make any other changes (we could change to SHA-1 or SHA-256 as our > initial algorithm, and that might mollify some folks; since it's basically a > search and replace on the document, I think it's worth doing). > > The idea is that in the unlikely event that we at some future date need to > change the hash, then AT THAT TIME we write a draft that tells us how to do > updates in the transitional state where more than one hash might still be > present in the DNS. For now, we just put the identifier there and don't > change anything else. > > This seems like a reasonable compromise - since we're claiming that we're > never going to need the additional complexity, hopefully this postpones the > work to describe and implement that complexity forever; if it turns out that > we're wrong, we have a path forward. > > I can go more into the reasons why we agreed on this particular approach if > anyone's interested, but unless you are, I'll just leave it at 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. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 16:42:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6x5U-0003kj-1g for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 16:42:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06029 for ; Wed, 8 Feb 2006 16:41:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6x3G-0006zk-FC for namedroppers-data@psg.com; Wed, 08 Feb 2006 21:40:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6x3F-0006zU-KU for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 21:40:37 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO000D53; 8 Feb 2006 16:41:42 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 8 Feb 2006 16:41:37 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG000D52; 8 Feb 2006 16:41:26 -0500 Message-ID: <43EA6DF6.1060606@connotech.com> Date: Wed, 08 Feb 2006 17:17:26 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: A least a draft now exists for trust anchor key rollover requirements. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: A least a draft now exists for trust anchor key rollover requirements. See http://www.connotech.com/draft-moreau-dnsext-tak-req-00.txt (submitted today as an individual submission draft) Perhaps it is not an ideal situation that a requirements document is authored by the promoter of an alternative in the solution space. In this perspective, you are kindly invited to bring forward a better set of TAK requirement statements, and/or suggestions to improve the above one. Best regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 16:59:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6xLj-0003FI-R1 for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 16:59:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07763 for ; Wed, 8 Feb 2006 16:57:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6xIa-000850-5Z for namedroppers-data@psg.com; Wed, 08 Feb 2006 21:56:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS,SPF_FAIL autolearn=no version=3.1.0 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6xIZ-00084p-I6 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 21:56:27 +0000 Received: from abhaya.fugue.com (lam.fugue.com [66.93.162.226]) by toccata.fugue.com (Postfix) with ESMTP id DCFBE1B209A; Wed, 8 Feb 2006 14:56:26 -0700 (MST) From: Ted Lemon Organization: Nominum, Inc. To: Ralph Droms Subject: Re: DDNS IESG Issue resolution. Date: Wed, 8 Feb 2006 14:56:24 -0700 User-Agent: KMail/1.8.3 Cc: dhcwg@ietf.org, Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602081456.25200.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 08 February 2006 14:18, Ralph Droms wrote: > Are there any export or other restrictions on SHA-1 or SHA-256 at this > time? They're hash algorithms, not encruption algorithms, so while I suppose anything's possible, it seems unlikely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 08 17:00:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6xMA-0003WP-Br for dnsext-archive@megatron.ietf.org; Wed, 08 Feb 2006 17:00:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07812 for ; Wed, 8 Feb 2006 16:58:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6xKR-0008DU-TR for namedroppers-data@psg.com; Wed, 08 Feb 2006 21:58:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6xKR-0008DJ-C3 for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 21:58:23 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2006 13:58:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="21472416:sNHT21106168" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k18Lvd6p003881; Wed, 8 Feb 2006 16:58:19 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 16:58:18 -0500 Received: from 10.86.240.172 ([10.86.240.172]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Feb 2006 21:58:17 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 08 Feb 2006 16:58:16 -0500 Subject: Re: DDNS IESG Issue resolution. From: Ralph Droms To: Ted Lemon CC: , , "Hartman, Sam" , Message-ID: Thread-Topic: DDNS IESG Issue resolution. Thread-Index: AcYs+sN/AfnWb5juEdqe0AARJOT6eg== In-Reply-To: <200602081456.25200.Ted.Lemon@nominum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 21:58:18.0291 (UTC) FILETIME=[C4DD2030:01C62CFA] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agreed,. Just checking... - Ralph On 2/8/06 4:56 PM, "Ted Lemon" wrote: > On Wednesday 08 February 2006 14:18, Ralph Droms wrote: >> Are there any export or other restrictions on SHA-1 or SHA-256 at this >> time? > > They're hash algorithms, not encruption algorithms, so while I suppose > anything's possible, it seems unlikely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 09 00:22:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F74GG-0003PT-7H for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 00:22:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16355 for ; Thu, 9 Feb 2006 00:20:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F749f-0009xm-En for namedroppers-data@psg.com; Thu, 09 Feb 2006 05:15:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F749d-0009x1-1s for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 05:15:41 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k195FOKQ053439; Thu, 9 Feb 2006 06:15:28 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <43EA6DF6.1060606@connotech.com> References: <43EA6DF6.1060606@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-48-93651226" Message-Id: <2FF4CA6A-E374-42F6-92A9-96A468B1FDB2@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: A least a draft now exists for trust anchor key rollover requirements. Date: Thu, 9 Feb 2006 06:15:24 +0100 To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-48-93651226 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > > Perhaps it is not an ideal situation that a requirements document > is authored by the promoter of an alternative in the solution space. > > In this perspective, you are kindly invited to bring forward a > better set of TAK requirement statements, and/or suggestions to > improve the above one. Dear Thierry, Thanks for your contribution but I would prefer if we could leave this document shelved just a little while. We have assigned editors to produce a requirement document for the working group and I am still confident that they will deliver, albeit the delay. At this moment we as a working group should not raise the amount of entropy by having multiple requirement documents floating around. On the other hand I see that you, and others (myself included) are anxious to see output. I propose that we wait for the assigned editors to produce. If the editors fail to produce before the cutt-off we will have to use your document as the basis for further discussion. I am not saying that your contribution is out of scope for this group, by no means. But I'd prefer if we could focus on just one document, that of the volunteer editors. I share frustration about the speed of this process and except for the Vixie Beer Fund there are very few ways we can force/motivate people to do work. On the other hand I do think a good set of requirements is important so that we can then continue with selection of the appropriate technology. Those technologies all seem pretty advanced. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-48-93651226 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFD6s/stN/ca3YJIocRAmfnAJ0SyZabAgfrobPirQARWTmK2KtNEACfZ+wV uUP/fp57ai9DdPalOqtVdso= =v3ly -----END PGP SIGNATURE----- --Apple-Mail-48-93651226-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From akgvxkav@acquarioweb.com Thu Feb 09 00:47:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F74eg-0005mN-Tg for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 00:47:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17680 for ; Thu, 9 Feb 2006 00:46:02 -0500 (EST) Received: from [58.147.84.72] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F74qw-0008Ua-Mu for dnsext-archive@ietf.org; Thu, 09 Feb 2006 01:00:56 -0500 Message-ID: <000001c62d65$c95e8700$0100007f@localhost> From: "Sean Price" To: Subject: 0EM Software Date: Wed, 08 Feb 2006 21:46:50 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62D65.C95E8700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62D65.C95E8700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62D65.C95E8700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 35 reviews)

------=_NextPart_000_0001_01C62D65.C95E8700-- From owner-namedroppers@ops.ietf.org Thu Feb 09 00:51:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F74hv-0006xS-9H for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 00:51:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17865 for ; Thu, 9 Feb 2006 00:49:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F74fe-000Bto-Q0 for namedroppers-data@psg.com; Thu, 09 Feb 2006 05:48:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [207.65.203.98] (helo=goose.ntrg.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F74fd-000BtZ-AA for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 05:48:45 +0000 Received: from [207.65.71.19] (pool-70-21-79-77.res.east.verizon.net [70.21.79.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 2E05E25542 for ; Wed, 8 Feb 2006 23:48:44 -0600 (CST) Message-ID: <43EAD7AE.5000904@ehsco.com> Date: Thu, 09 Feb 2006 00:48:30 -0500 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT Document Review: LLMNR-45 References: <2E33960095B58E40A4D3345AB9F65EC1158BD267@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1158BD267@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've been thinking about the security and naming scope problems a little bit and have reached the conclusion that we need to do something here. On 2/6/2006 4:54 PM, Dave Thaler wrote: > Re issue #2, I agree with Stephane and Eric. There is nothing in RFC 3493 > which needs to change as a result of LLMNR specifically. The same security > concerns are independent of the protocol. This is true but it also ignores the fact that we are responsible for *this* protocol. Being broken elsewhere doesn't mean we should design for broken here too, and if anything we are kind of incumbent to put our money where our mouths are. I think there's an easy hack here that gets us about 80% through the problem space--just limit the namespace to single-label names, so that there's no overlap with the DNS namespace. On the security side, do we really need handhelds claiming to be www.paypal.com? On the namespace side, forbidding such claims prevents collisions with the authoritative space. This leaves the security hole of single-label names resolving to forged nodes (a handheld claims to be an HR server), and we're all undoubtedly aware that any risk is a 100% risk once it's widely exploited, but these kind of relative-name attacks can also be dealt with at application layers (certs, etc). This also leaves some opportunity for vendors to put their own .local interoperability hacks together without our blessing or permission. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 09 01:36:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F75Pi-0007U6-2V for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 01:36:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20874 for ; Thu, 9 Feb 2006 01:34:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F75M5-000EZS-P9 for namedroppers-data@psg.com; Thu, 09 Feb 2006 06:32:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F75M4-000EZE-PW for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 06:32:36 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1F75M3-000LTu-BH for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 01:32:35 -0500 Received: by internaut.com (Postfix, from userid 1000) id 94F3A59010; Wed, 8 Feb 2006 22:32:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 8935A5900D for ; Wed, 8 Feb 2006 22:32:34 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 8 Feb 2006 22:32:34 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: DNSEXT Document Review: LLMNR-45 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Eric Hall said: "I think there's an easy hack here that gets us about 80% through the problem space--just limit the namespace to single-label names, so that there's no overlap with the DNS namespace." If there is no security in place, in most cases it makes sense to only send LLMNR queries only for single-label names. So not much would be lost if this were to be required. "On the security side, do we really need handhelds claiming to be www.paypal.com? On the namespace side, forbidding such claims prevents collisions with the authoritative space." If the query sender has no ability to validate the claim, then I would agree that an FQDN query should not be sent. But what if the sender is DNSSEC validating, and the responder also supports DNSSEC, and appropriate trust anchors are in place? Then it would be possible for the sender to determine whether the claim was valid or not. "This leaves the security hole of single-label names resolving to forged nodes (a handheld claims to be an HR server), and we're all undoubtedly aware that any risk is a 100% risk once it's widely exploited, but these kind of relative-name attacks can also be dealt with at application layers (certs, etc)." Actually that is more true of the FQDN spoofing case than it is of the single-label case. After all, you aren't going to see Verisign distributing certs with an AltSubjectName of "foo" any time soon. "This also leaves some opportunity for vendors to put their own .local interoperability hacks together without our blessing or permission." Since the .local issue was about the behavior of existing resolvers, I think that fixing it would require some documentation. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From decanofu@anyvacation.com Thu Feb 09 07:43:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7B9M-00038J-Pg for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 07:43:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16616 for ; Thu, 9 Feb 2006 07:42:01 -0500 (EST) Received: from [211.210.163.9] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7BM0-0005lZ-9a for dnsext-archive@ietf.org; Thu, 09 Feb 2006 07:56:57 -0500 Message-ID: <000001c62da0$5f170800$0100007f@localhost> From: "Christian Taylor" To: Subject: Software At Low Pr1ce Date: Thu, 09 Feb 2006 21:43:50 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62DA0.5F170800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62DA0.5F170800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62DA0.5F170800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 41 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 50 reviews)

------=_NextPart_000_0001_01C62DA0.5F170800-- From owner-namedroppers@ops.ietf.org Thu Feb 09 10:21:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7DcG-0001bl-I2 for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 10:21:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29852 for ; Thu, 9 Feb 2006 10:19:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7DU1-000Kpk-Ib for namedroppers-data@psg.com; Thu, 09 Feb 2006 15:13:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [207.65.203.98] (helo=goose.ntrg.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7DU0-000KpN-4C for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 15:13:20 +0000 Received: from [207.65.71.19] (pool-70-21-79-77.res.east.verizon.net [70.21.79.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 3BD8D14A65; Thu, 9 Feb 2006 09:13:18 -0600 (CST) Message-ID: <43EB5C02.8020605@ehsco.com> Date: Thu, 09 Feb 2006 10:13:06 -0500 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT Document Review: LLMNR-45 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2/9/2006 1:32 AM, Bernard Aboba wrote: > "This leaves the security hole of single-label names resolving to forged > nodes (a handheld claims to be an HR server), and we're all undoubtedly > aware that any risk is a 100% risk once it's widely exploited, but these > kind of relative-name attacks can also be dealt with at application layers > (certs, etc)." > > Actually that is more true of the FQDN spoofing case than it is of the > single-label case. After all, you aren't going to see Verisign > distributing certs with an AltSubjectName of "foo" any time soon. Couple of other factors here though. For one, the real "HR" host would have a delegated cert for something like "hr.intranet.example.com". So even if the key is compromised the name won't match. It's also possible for local nets to publish LLMNR names for important systems on the local level. That further reduces the scope of the vector to (a) being outside the premises, and (b) mimicing the correct name, (c) redirecting to insecured application [http instead of https], and (d) faking the application to being the right fake site enough to pull off the phish (where "hr" has to look like the "hr" that the user is trying to connect to, which is pretty unlikely if the attack space is off-site public areas). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 09 11:45:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Eva-0003z4-T1 for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 11:45:54 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07635 for ; Thu, 9 Feb 2006 11:44:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7Erx-0000se-Mr for namedroppers-data@psg.com; Thu, 09 Feb 2006 16:42:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [207.65.203.98] (helo=goose.ntrg.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7Erw-0000sT-TI for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 16:42:09 +0000 Received: from [207.65.71.19] (pool-70-21-79-77.res.east.verizon.net [70.21.79.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id B3614255F8 for ; Thu, 9 Feb 2006 10:42:07 -0600 (CST) Message-ID: <43EB70D3.3040607@ehsco.com> Date: Thu, 09 Feb 2006 11:41:55 -0500 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT Document Review: LLMNR-45 References: <43EB5C02.8020605@ehsco.com> In-Reply-To: <43EB5C02.8020605@ehsco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2/9/2006 10:13 AM, Eric A. Hall wrote: > It's also possible for local nets to publish LLMNR names for important > systems on the local level. That further reduces the scope of the vector Another attack vector would of course be denial-of-service, such that the attacker did not need to redirect the victim but just to block them. This could work with TLD names like "com" or the like (keep any names within that space from resolving). Simple fix here is to make it JUST ONE label (really, just one), so that lookup for "com" would really be a lookup for "com" instead of "com.". That would limit the attack scope to the root domain itself (ie, spoofing the zero-length label), which is a single-instance attack that can be handled with an explicit prohibition in the spec ("do not generate/process zero-length labels"). Similarly, maybe a prohibition against the dot character (0x2E) or each of the IDN equivalents would also be useful to prevent some kinds of look-alike attacks from occurring. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 09 12:14:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FNW-0005Im-62 for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 12:14:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09874 for ; Thu, 9 Feb 2006 12:13:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7FIV-0002m4-3W for namedroppers-data@psg.com; Thu, 09 Feb 2006 17:09:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7FIU-0002lp-6J for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 17:09:34 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k19H9Sbq053216 for ; Thu, 9 Feb 2006 12:09:28 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k19H9SIp053215 for namedroppers@ops.ietf.org; Thu, 9 Feb 2006 12:09:28 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.187.72] (helo=kaboom.isc.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6x3i-00072C-To for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 21:41:06 +0000 Received: by kaboom.isc.org (Postfix, from userid 10200) id 35B9F89585; Wed, 8 Feb 2006 13:41:06 -0800 (PST) Date: Wed, 8 Feb 2006 13:41:06 -0800 From: "David W. Hankins" To: Ralph Droms Cc: Ted Lemon , dhcwg@ietf.org, Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: DDNS IESG Issue resolution. Message-ID: <20060208214106.GF27596@isc.org> References: <200602081413.20233.Ted.Lemon@nominum.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zjcmjzIkjQU2rmur" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] --zjcmjzIkjQU2rmur Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 08, 2006 at 04:18:07PM -0500, Ralph Droms wrote: > Are there any export or other restrictions on SHA-1 or SHA-256 at this ti= me? ISC DHCP is a consumer of this protocol, I see no reason why it can't adopt SHA-*. We already have sources we're familiar with which I understand can be bent to this purpose. I have no complaints with this compromise. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --zjcmjzIkjQU2rmur Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD6mVycXeLeWu2vmoRAmvZAJ41NFLFgS9/aUOQZ4WtucgXzQqHvACfbchR DxFE38DcyY0mrj6WU7aYe6k= =N4kz -----END PGP SIGNATURE----- --zjcmjzIkjQU2rmur-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 09 12:14:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FNT-0005HE-P4 for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 12:14:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09861 for ; Thu, 9 Feb 2006 12:12:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7FHo-0002iB-UK for namedroppers-data@psg.com; Thu, 09 Feb 2006 17:08:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7FHn-0002hz-U9 for namedroppers@ops.ietf.org; Thu, 09 Feb 2006 17:08:52 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k19H8jr6053210 for ; Thu, 9 Feb 2006 12:08:45 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k19H8jLR053209 for namedroppers@ops.ietf.org; Thu, 9 Feb 2006 12:08:45 -0500 (EST) (envelope-from namedroppers) Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6whY-0005Ot-Sc for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 21:18:13 +0000 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2E06BE0053; Wed, 8 Feb 2006 16:18:11 -0500 (EST) To: Ted Lemon Cc: dhcwg@ietf.org, Harald@alvestrand.no, namedroppers@ops.ietf.org Subject: Re: DDNS IESG Issue resolution. References: <200602081413.20233.Ted.Lemon@nominum.com> From: Sam Hartman Date: Wed, 08 Feb 2006 16:18:11 -0500 In-Reply-To: <200602081413.20233.Ted.Lemon@nominum.com> (Ted Lemon's message of "Wed, 8 Feb 2006 14:13:19 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] >>>>> "Ted" == Ted Lemon writes: Ted> So what he asked us to do is to put an algorithm identifier Ted> on the DHCID, but not make any other changes (we could change Ted> to SHA-1 or SHA-256 as our initial algorithm, and that might Ted> mollify some folks; since it's basically a search and replace Ted> on the document, I think it's worth doing). I'd also ask you to note that registering new algorithms requires standards action. The reason that it would require standards action is that you'd need to describe the update mechanism at the second registration. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From pooh@art-tes.com Thu Feb 09 13:25:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7GU6-0002d0-6z for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 13:25:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18241 for ; Thu, 9 Feb 2006 13:23:34 -0500 (EST) Received: from e178232147.adsl.alicedsl.de ([85.178.232.147] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7GgX-00027f-EO for dnsext-archive@ietf.org; Thu, 09 Feb 2006 13:38:32 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for dnsext-archive@ietf.org; Thu, 09 Feb 2006 19:24:58 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for dnsext-archive@ietf.org; Thu, 09 Feb 2006 19:24:58 +0100 Message-ID: <000001c62dd0$0495a000$0100007f@localhost> From: "Conner Clark" To: Subject: Last offer- Discount special for PE patch almost over! Date: Thu, 09 Feb 2006 19:24:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62DD0.0495A000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62DD0.0495A000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.beratont.biz/pt/?46&hxebsj ------=_NextPart_000_0001_01C62DD0.0495A000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C62DD0.0495A000-- From doris@barbyoungs.com Thu Feb 09 14:56:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7HtZ-0005GA-8b for dnsext-archive@megatron.ietf.org; Thu, 09 Feb 2006 14:56:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24841 for ; Thu, 9 Feb 2006 14:54:06 -0500 (EST) Received: from abordeaux-152-1-41-33.w83-193.abo.wanadoo.fr ([83.193.183.33] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7I68-0005Cu-4p for dnsext-archive@ietf.org; Thu, 09 Feb 2006 15:09:06 -0500 Message-ID: <000001c62ddc$46c4de80$0100007f@localhost> From: "Dylan Rodriguez" To: Subject: cheap oem soft shipping //orldwide Date: Fri, 10 Feb 2006 20:52:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62DDC.46C4DE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.1 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62DDC.46C4DE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C62DDC.46C4DE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
  &! nbsp; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 46 rev! iews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 47 reviews)

------=_NextPart_000_0001_01C62DDC.46C4DE80-- From owner-namedroppers@ops.ietf.org Fri Feb 10 14:35:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7e3U-0001eb-Go for dnsext-archive@megatron.ietf.org; Fri, 10 Feb 2006 14:35:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21896 for ; Fri, 10 Feb 2006 14:34:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7dyv-00026R-4T for namedroppers-data@psg.com; Fri, 10 Feb 2006 19:31:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7dyu-00026D-0f for namedroppers@ops.ietf.org; Fri, 10 Feb 2006 19:31:00 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9164633C1C; Fri, 10 Feb 2006 19:30:55 +0000 (GMT) Message-ID: <43ECE9F0.3060902@algroup.co.uk> Date: Fri, 10 Feb 2006 19:30:56 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060123) MIME-Version: 1.0 To: Ted Lemon CC: Ralph Droms , dhcwg@ietf.org, Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org Subject: Re: DDNS IESG Issue resolution. References: <200602081456.25200.Ted.Lemon@nominum.com> In-Reply-To: <200602081456.25200.Ted.Lemon@nominum.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lemon wrote: > On Wednesday 08 February 2006 14:18, Ralph Droms wrote: >> Are there any export or other restrictions on SHA-1 or SHA-256 at this >> time? > > They're hash algorithms, not encruption algorithms, so while I suppose > anything's possible, it seems unlikely. There haven't been troublesome export restrictions even on encryption for some time - from the US. But if you are going to worry about export, then you have to bear in mind that the IETF is international. US export laws are hardly the issue. There are plenty of jurisdictions where _use_, let alone export, of crypto is completely illegal. Also, FWIW, hash algorithms are perfectly usable as encryption algorithms. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 10 19:10:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7iLS-00008S-Ja for dnsext-archive@megatron.ietf.org; Fri, 10 Feb 2006 19:10:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19342 for ; Fri, 10 Feb 2006 19:08:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7iHI-000JR5-Qp for namedroppers-data@psg.com; Sat, 11 Feb 2006 00:06:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7iHI-000JQj-0f for namedroppers@ops.ietf.org; Sat, 11 Feb 2006 00:06:16 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1FCEDC2DAA; Sat, 11 Feb 2006 00:06:15 +0000 (GMT) Date: Sat, 11 Feb 2006 00:06:07 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , Ted Lemon Cc: Ralph Droms , dhcwg@ietf.org, Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: DDNS IESG Issue resolution. Message-ID: <7CC9AE8AAD7575CEEF5155EF@[192.168.100.25]> In-Reply-To: <43ECE9F0.3060902@algroup.co.uk> References: <200602081456.25200.Ted.Lemon@nominum.com> <43ECE9F0.3060902@algroup.co.uk> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 10 February 2006 19:30 +0000 Ben Laurie wrote: > Also, FWIW, hash algorithms are perfectly usable as encryption algorithms. Pardon? One of the features of most hashes is that they are not invertible, and another features is that the range is far smaller than the domain. I agree that most encryption algorithms are usable as hash algorithms (as without the decrypt key, a good encryption algorithm is not invertible) if a subset of the output range is taken (i.e. a limited number of bits), but encryption algorithms with a range of less size than their domain are not in general helpful, so the converse as far as I know is not true. But we'd all be grateful for the SHA-256 "decryption" algorithm if you have one! Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From melanie.weir@annuairerp.com Sat Feb 11 11:25:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7xYy-0007VD-GI for dnsext-archive@megatron.ietf.org; Sat, 11 Feb 2006 11:25:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14766 for ; Sat, 11 Feb 2006 11:23:48 -0500 (EST) Received: from [60.31.71.104] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7xm2-0001gv-1x for dnsext-archive@ietf.org; Sat, 11 Feb 2006 11:39:13 -0500 Message-ID: <000001c62f51$cd4efc80$0100007f@localhost> From: "Ryan Hill" To: Subject: Buy OEM Software Date: Sun, 12 Feb 2006 00:25:08 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62F51.CCB66600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62F51.CCB66600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C62F51.CCB66600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELLY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be download INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C62F51.CCB66600-- From owner-namedroppers@ops.ietf.org Sat Feb 11 13:54:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7zt2-00066V-P4 for dnsext-archive@megatron.ietf.org; Sat, 11 Feb 2006 13:54:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22939 for ; Sat, 11 Feb 2006 13:52:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7znC-000K4c-Tc for namedroppers-data@psg.com; Sat, 11 Feb 2006 18:48:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7znB-000K4I-Eh for namedroppers@ops.ietf.org; Sat, 11 Feb 2006 18:48:21 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 262BC33C1C; Sat, 11 Feb 2006 18:48:06 +0000 (GMT) Message-ID: <43EE3165.8010809@algroup.co.uk> Date: Sat, 11 Feb 2006 18:48:05 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060123) MIME-Version: 1.0 To: Alex Bligh CC: Ted Lemon , Ralph Droms , dhcwg@ietf.org, Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org Subject: Re: DDNS IESG Issue resolution. References: <200602081456.25200.Ted.Lemon@nominum.com> <43ECE9F0.3060902@algroup.co.uk> <7CC9AE8AAD7575CEEF5155EF@[192.168.100.25]> In-Reply-To: <7CC9AE8AAD7575CEEF5155EF@[192.168.100.25]> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 10 February 2006 19:30 +0000 Ben Laurie wrote: > >> Also, FWIW, hash algorithms are perfectly usable as encryption >> algorithms. > > Pardon? One of the features of most hashes is that they are not invertible, > and another features is that the range is far smaller than the domain. I > agree that most encryption algorithms are usable as hash algorithms (as > without the decrypt key, a good encryption algorithm is not invertible) if > a subset of the output range is taken (i.e. a limited number of bits), but > encryption algorithms with a range of less size than their domain are not > in general helpful, so the converse as far as I know is not true. > > But we'd all be grateful for the SHA-256 "decryption" algorithm if you > have one! I didn't say you could decrypt a hash function, I said you could use one for encryption. The construction is known as "Chaffing and Winnowing", was invented by Ron Rivest, is hugely inefficient and was designed to show the foolishness of crypto export laws. http://theory.lcs.mit.edu/~rivest/chaffing.txt Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 11 14:51:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F80mP-0006bf-Dp for dnsext-archive@megatron.ietf.org; Sat, 11 Feb 2006 14:51:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25353 for ; Sat, 11 Feb 2006 14:49:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F80jU-000MZp-E4 for namedroppers-data@psg.com; Sat, 11 Feb 2006 19:48:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F80jT-000MZe-H1 for namedroppers@ops.ietf.org; Sat, 11 Feb 2006 19:48:35 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 07979C2DA3; Sat, 11 Feb 2006 19:48:34 +0000 (GMT) Date: Sat, 11 Feb 2006 19:48:25 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: Ted Lemon , Ralph Droms , dhcwg@ietf.org, Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: DDNS IESG Issue resolution. Message-ID: <41408B1B7DC7E8601BBF4DE1@[192.168.100.25]> In-Reply-To: <43EE3165.8010809@algroup.co.uk> References: <200602081456.25200.Ted.Lemon@nominum.com> <43ECE9F0.3060902@algroup.co.uk> <7CC9AE8AAD7575CEEF5155EF@[192.168.100.25]> <43EE3165.8010809@algroup.co.uk> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (Rapidly moving off-topic) --On 11 February 2006 18:48 +0000 Ben Laurie wrote: >>> Also, FWIW, hash algorithms are perfectly usable as encryption >>> algorithms. >> >> Pardon? ... > I didn't say you could decrypt a hash function, I said you could use one > for encryption. > > The construction is known as "Chaffing and Winnowing", was invented by > Ron Rivest, is hugely inefficient and was designed to show the > foolishness of crypto export laws. This is merely a semantic point (meaning of the word encryption). Even the author of the paper explicitly describes both stenography and chaffing & winnowing as "not employ[ing] encryption". >From the paper: There are two major techniques for achieving confidentiality: ... Stenography ... Encryption ... This paper introduces a new technique, which we call ``chaffing and winnowing'' Then: "Winnowing does not employ encryption" His perfectly adequate definition of encryption is: Encryption: transforming the message to a ciphertext such that an adversary who overhears the ciphertext can not determine the message sent. The legitimate receiver possesses a secret decryption key that allows him to reverse the encryption transformation and retrieve the message. The sender may have used the same key to encrypt the message (with symmetric encryption schemes) or used a different, but related key (with public-key schemes). DES and RSA are familiar examples of encryption schemes. A hash function doesn't do that. Chaffing & winnowing doesn't do that. The hash/MAC function is just a component of the algorithm here, and is no more an "encryption" function here than when (say) it is used to produce a private key from a secret string. If we go this way, addition could be described as encryption on the basis it's used in just about every encryption algorithm. The key thing he's doing is adding chaff, PLUS the original plaintext (wheat), giving a range space FAR larger than the original domain (as is the case in stenography, under whose bracket one might argue this technique actually falls). (and back on topic) And whilst indeed the point he is making (well) is that that crypto export laws are dumb, he himself says: We have the transformation of appending a MAC thus: packet --> packet, MAC The packet is still ``in the clear''; no encryption has been performed. We note that software that merely authenticates messages by adding MACs is automatically approved for export, as it is deemed not to encrypt. So at least this generation of dumb crypto laws do not cover MAC (hash) functions, which is what was, I think, the original question. Unfortunately pointing out laws are dumb does not allow us to ignore them. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From champion@asymmetrix.com Sat Feb 11 20:50:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F86Nf-0001PM-T8 for dnsext-archive@megatron.ietf.org; Sat, 11 Feb 2006 20:50:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13255 for ; Sat, 11 Feb 2006 20:48:44 -0500 (EST) Received: from ip112-60-166-62.adsl.versatel.nl ([62.166.60.112] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F86ax-00079q-QP for dnsext-archive@ietf.org; Sat, 11 Feb 2006 21:04:13 -0500 Message-ID: <000001c62fa0$a2d86000$0100007f@localhost> From: "Angel Ward" To: Subject: Buy OEM Software Date: Sun, 12 Feb 2006 02:50:25 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62FA0.A2D86000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.2 (+++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62FA0.A2D86000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C62FA0.A2D86000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

!
Regular price:$550.00
Our offer:$69.95
You save :$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C62FA0.A2D86000-- From chopino@bargains2hotel.com Sun Feb 12 10:12:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Iu3-0005ek-0m for dnsext-archive@megatron.ietf.org; Sun, 12 Feb 2006 10:12:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21989 for ; Sun, 12 Feb 2006 10:10:58 -0500 (EST) Received: from [59.144.19.14] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8J4w-000522-DL for dnsext-archive@ietf.org; Sun, 12 Feb 2006 10:26:36 -0500 Message-ID: <000001c6300f$cf779080$0100007f@localhost> From: "Landon Nelson" To: Subject: Need S0ftware? Date: Sat, 12 Feb 2005 20:39:32 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6300F.CF779080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.3 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6300F.CF779080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C6300F.CF779080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C6300F.CF779080-- From owner-namedroppers@ops.ietf.org Sun Feb 12 12:26:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Kzk-00036q-69 for dnsext-archive@megatron.ietf.org; Sun, 12 Feb 2006 12:26:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01613 for ; Sun, 12 Feb 2006 12:24:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8KvG-000Mf2-2h for namedroppers-data@psg.com; Sun, 12 Feb 2006 17:22:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8KvF-000Meo-Ch for namedroppers@ops.ietf.org; Sun, 12 Feb 2006 17:22:05 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 12 Feb 2006 09:22:04 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Feb 2006 09:21:41 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Feb 2006 09:21:41 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Feb 2006 09:21:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DDNS IESG Issue resolution. Date: Sun, 12 Feb 2006 09:21:40 -0800 Message-ID: In-Reply-To: <41408B1B7DC7E8601BBF4DE1@[192.168.100.25]> Thread-Topic: DDNS IESG Issue resolution. thread-index: AcYvRNmyN6hSJypfTpSnIfo1Y6gzbAAspFZA From: "Christian Huitema" To: "Alex Bligh" , "Ben Laurie" Cc: "Ted Lemon" , "Ralph Droms" , , , "Hartman, Sam" , X-OriginalArrivalTime: 12 Feb 2006 17:21:41.0335 (UTC) FILETIME=[C9F59E70:01C62FF8] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > >>> Also, FWIW, hash algorithms are perfectly usable as encryption > >>> algorithms. > >> > >> Pardon? > ... > > The construction is known as "Chaffing and Winnowing", was invented by > > Ron Rivest, is hugely inefficient and was designed to show the > > foolishness of crypto export laws. >=20 > This is merely a semantic point (meaning of the word encryption). Even the > author of the paper explicitly describes both stenography and chaffing & > winnowing as "not employ[ing] encryption". Clearly, Ron Rivest's chaffin and winnowing construct is more a gedanken experiment than a practical tool. However, hash functions can be used to hide data, using a different construct: generate a bit string by hashing a shared secret and a random number present in the message, and then XOR the message text with that bit string. That construct is actually used in the Radius specification (RFC 2685, section 5.2 "Passords", page 27): On transmission, the password is hidden. The password is first padded at the end with nulls to a multiple of 16 octets. A one- way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the Request Authenticator. This value is XORed with the first 16 octet segment of the password and placed in the first 16 octets of the String field of the User- Password Attribute. The Radius specification used MD5, but that construct can actually be used with pretty much any hash function.=20 > So at least this generation of dumb crypto laws do not cover MAC (hash) > functions, which is what was, I think, the original question. > Unfortunately > pointing out laws are dumb does not allow us to ignore them. Let's say that these laws do not prevent the use of hash functions for message authentication purposes, and leave it at that. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From masif167@a2corporation.com Sun Feb 12 13:33:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8M2h-0005x6-R7 for dnsext-archive@megatron.ietf.org; Sun, 12 Feb 2006 13:33:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05622 for ; Sun, 12 Feb 2006 13:32:06 -0500 (EST) Received: from i216-58-91-165.cybersurf.com ([216.58.91.165] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8MG2-00029l-U2 for dnsext-archive@ietf.org; Sun, 12 Feb 2006 13:47:46 -0500 Message-ID: <000001c6302c$a6192d80$0100007f@localhost> From: "Braxton Patterson" To: Subject: Software At Low Pr1ce Date: Mon, 13 Feb 2006 13:33:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6302C.A6192D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6302C.A6192D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C6302C.A6192D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C6302C.A6192D80-- From rmheller@altosite.com Sun Feb 12 23:50:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8VfW-0002NZ-R7 for dnsext-archive@megatron.ietf.org; Sun, 12 Feb 2006 23:50:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11164 for ; Sun, 12 Feb 2006 23:48:49 -0500 (EST) Received: from 88-142.124-70.tampabay.res.rr.com ([70.124.142.88] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8Vsz-0001F4-ET for dnsext-archive@ietf.org; Mon, 13 Feb 2006 00:04:35 -0500 Message-ID: <000001c63082$fd49ed00$0100007f@localhost> From: "Marc Cooper" To: Subject: Need S0ftware? Date: Sun, 12 Feb 2006 23:50:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63082.FD49ED00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63082.FD49ED00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C63082.FD49ED00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C63082.FD49ED00-- From carrolund@atlantahouses4rent.com Mon Feb 13 01:08:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Wsw-0005Wo-WD for dnsext-archive@megatron.ietf.org; Mon, 13 Feb 2006 01:08:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16560 for ; Mon, 13 Feb 2006 01:06:45 -0500 (EST) Received: from flh1adi125.kng.mesh.ad.jp ([60.239.13.125] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8X6Q-0003V1-Pe for dnsext-archive@ietf.org; Mon, 13 Feb 2006 01:22:32 -0500 Message-ID: <000001c6308e$055b5a00$0100007f@localhost> From: "Cole Wright" To: Subject: Photoshop, Windows, Office Date: Mon, 13 Feb 2006 15:08:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6308E.055B5A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6308E.055B5A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C6308E.055B5A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Nort! on Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C6308E.055B5A00-- From lady2201@arizona-excellence.com Mon Feb 13 04:20:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZsV-0007vl-EA for dnsext-archive@megatron.ietf.org; Mon, 13 Feb 2006 04:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28199 for ; Mon, 13 Feb 2006 04:18:30 -0500 (EST) Received: from adsl_237_225.intnet.bj ([81.91.237.225] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8a5s-0000J2-LJ for dnsext-archive@ietf.org; Mon, 13 Feb 2006 04:34:18 -0500 Message-ID: <000001c630a8$3052a780$0100007f@localhost> From: "Matthew Barnes" To: Subject: Software At Low Pr1ce Date: Mon, 13 Feb 2006 10:21:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C630A8.3052A780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C630A8.3052A780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C630A8.3052A780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C630A8.3052A780-- From gregory.stevens@1800funvegas.com Mon Feb 13 17:52:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8mYA-0006j6-Nz for dnsext-archive@megatron.ietf.org; Mon, 13 Feb 2006 17:52:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29558 for ; Mon, 13 Feb 2006 17:50:20 -0500 (EST) Received: from pha-84-242-95-6.nat.karneval.cz ([84.242.95.6] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8mln-0000GM-0m for dnsext-archive@ietf.org; Mon, 13 Feb 2006 18:06:16 -0500 Message-ID: <000001c6311a$15b91680$0100007f@localhost> From: "Devin Sanders" To: Subject: cheap oem soft shipping //orldwide Date: Mon, 13 Feb 2006 23:51:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6311A.15B91680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6311A.15B91680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C6311A.15B91680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C6311A.15B91680-- From ruschi@actofpassion.com Mon Feb 13 20:22:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ou6-0005n2-Oi for dnsext-archive@megatron.ietf.org; Mon, 13 Feb 2006 20:22:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08641 for ; Mon, 13 Feb 2006 20:21:08 -0500 (EST) Received: from [218.7.197.228] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8p7e-0005NR-6G for dnsext-archive@ietf.org; Mon, 13 Feb 2006 20:37:05 -0500 Message-ID: <000001c6312e$f37dc380$0100007f@localhost> From: "Juan Clark" To: Subject: Software At Low Pr1ce Date: Tue, 14 Feb 2006 09:23:14 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6312E.F37DC380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6312E.F37DC380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 2 Photo shop 9.0 3 XP 4 Acro bat 7 5 MX 2O04 6 Draw 12 7 Anti virus 2005 8 Server 9 10 Illustrator 11 Lst: $550.00 ur: $69.95 Sv: $480.05 ( 87%) ---------------- List: $200.00 Our: $49.95 You: $150.05 ( 75%) ---------------- V 9.0 Lis: $599.00 Or: $69.95 Sav: $529.05 ( 88%) ------=_NextPart_000_0001_01C6312E.F37DC380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

1Office Pro 2003
2Adobe Photoshop 9.0
3Windows XP Pro
4Adobe Acrobat 7 Pro
5Flash MX 2004
6Corel Draw 12
7Norton Antivirus 2005
8Windows 2003 Server
9Alias Maya 6 Wavefrt
10Adobe Illustrator 11
See more by this manufacturer
 Microsoft
 Symantec
 Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

Regular price:$550.00
Our offer:$69.95
You save:$480.05 ( 87%)



Availability: Pay and download IMMEDIATELY!


Sales Rank: #1
Average Customer Review:3D"5
(based on 44 reviews)

Microsoft Windows XP Professional
   by Microsoft

Market price:$200.00
We propose:$49.95
Your profit:$150.05 ( 75%)



Availability: Available for INSTANT download!


Top-ranked item!
Average Customer Review:3D"5
(based on 47 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

Retail price:$599.00
Proposition:$69.95
Your benefit:$529.05 ( 88%)



Availability: Can be downloaded INSTANTLY!


Best choice for professional!
Average Customer Review:3D"5
(based on 43 reviews)

------=_NextPart_000_0001_01C6312E.F37DC380-- From wcfbzyg6@dnsd21.vicp.net Tue Feb 14 06:38:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8yVq-0007vY-74 for dnsext-archive@megatron.ietf.org; Tue, 14 Feb 2006 06:38:30 -0500 Received: from dnsd21.vicp.net ([61.236.89.135]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18110 for ; Tue, 14 Feb 2006 06:36:42 -0500 (EST) Received: from vozg4 (unknown [151.62.187.142]) by smtp20 (Coremail) with SMTP id H2AMoMrz1Kt1cWfA.1 for ; Tue, 14 Feb 2006 19:38:10 +0800 (CST) X-Originating-IP: [151.62.187.142] Date: Tue, 14 Feb 2006 19:38:10 +0800 From: =?shift-jis?B?dWFwdGNvZXkx?= <> To: Subject: =?shift-jis?B?jViQVoLMgqiSbYLngrk=?= Mime-Version: 1.0 Content-Type: text/plain; charset="shift-jis" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express X-MimeOLE: Produced By Microsoft MimeOLE Message-ID: <2006021454522.47710@dnsd21.vicp.net> Content-Transfer-Encoding: base64 gZ4gRCtQTFVTDQqRzIyxjuaN3oK1gr2V0o9Xg1iDXoNig3SC4ILRgsGCrYLogrWCxIKigtyCtYK9 gUINCo52gsGCvYjIj+OCyZC3guiP44KqgsGCxIKigumCzILFgUGWs5e/kcyMsYKugueCooLNDQqC tYLEgt2CxILggqKCooLGjnaCooLcgreBQg0KDQqBQCAgaHR0cDovL3d3dy5iZWF0LWkuY29tL3No b3V0DQoNCo64l+eCtYLcgreBQg== From toij6565@yahoo.co.jp Tue Feb 14 15:27:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F96mF-0002y7-9N for dnsext-archive@megatron.ietf.org; Tue, 14 Feb 2006 15:27:59 -0500 Received: from ocn.ne.jp ([221.207.130.184]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24572 for ; Tue, 14 Feb 2006 15:26:10 -0500 (EST) Date: Tue, 14 Feb 2006 15:26:10 -0500 (EST) Message-Id: <200602142026.PAA24572@ietf.org> Received: from cgtost3 (unknown [184.3.98.30]) by smtp50 (Coremail) with SMTP id hHtXVbShepXQLAeR.1 for ; Wed, 15 Feb 2006 05:28:23 +0800 (CST) X-Originating-IP: [184.3.98.30] Subject: =?iso-2022-jp?B?GyRCO2QkTjdIQlNIVjlmJEckOSEjGyhC?= From: =?gb2312?B??= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C62CB8.EF99DA80" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C62CB8.EF99DA80 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCQj4kRyRPPVBNaCReJDskcyQsISIbKEIgDQpodHRwOi8vd3d3LmRlYWktc3R5bGUubmV0L2Nh c2Fub3ZhLz8xOTM1GyRCJEckTxsoQg0KGyRCJWElayUiJUk4cjQ5JGQ3SEJTSFY5ZjhyNDkkLDRK QzEkSz1QTWgkXiQ5ISMbKEINCg0KGyRCIWM0MEE0TDVOQSFkGyhCDQobJEJCPiRIJE4wYyQkJHI7 biQ3JEYkXyRGRzxGQCQsOVQkKyRKJCQ+bDlnJE9CYDJxJDckRhsoQg0KGyRCJGIkaSRDJEY5PSQk JF4kOyRzISMbKEINChskQiVXJWklJCVQJTchPCRyPGkkayQ/JGEkSyVVJWohPCVhITwlayRHJE5F UE8/JGI8dSQxSVUkMSRGGyhCDQobJEIkKiRqJF4kOSEjGyhCDQpodHRwOi8vd3d3LmRlYWktc3R5 bGUubmV0L2Nhc2Fub3ZhLz8xOTM1DQoNCg0KDQoNCg0KDQoNChskQiVhITwla0lUTVckTkp9JE8k MyRBJGkiLRsoQg0KY29uY2VwdDNfbmV0QHlhaG9vLmNhDQo= ------=_NextPart_000_0006_01C62CB8.EF99DA80 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj Ij48Rk9OVCBzaXplPTI+GyRCQj4kRyRPPVBNaCReJDskcyQsISIbKEIgPEJSPjxBIA0KaHJlZj0i aHR0cDovL3d3dy5kZWFpLXN0eWxlLm5ldC9jYXNhbm92YS8/MTkzNSI+aHR0cDovL3d3dy5kZWFp LXN0eWxlLm5ldC9jYXNhbm92YS8/MTkzNTwvQT4bJEIkRyRPGyhCPEJSPhskQiVhJWslIiVJOHI0 OSRkN0hCU0hWOWY4cjQ5JCw0SkMxJEs9UE1oJF4kOSEjGyhCPC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiPjxGT05UIA0Kc2l6ZT0yPhskQiFjNDBB NEw1TkEhZBsoQjxCUj4bJEJCPiRIJE4wYyQkJHI7biQ3JEYkXyRGRzxGQCQsOVQkKyRKJCQ+bDln JE9CYDJxJDckRhsoQjxCUj4bJEIkYiRpJEMkRjk9JCQkXiQ7JHMhIxsoQjxCUj4bJEIlVyVpJSQl UCU3ITwkcjxpJGskPyRhJEslVSVqITwlYSE8JWskRyRORVBPPyRiPHUkMUlVJDEkRhsoQjxCUj4b JEIkKiRqJF4kOSEjGyhCPEJSPjwvRk9OVD48L0ZPTlQ+PEZPTlQgDQpmYWNlPSJNUyBVSSBHb3Ro aWMiIHNpemU9Mj48QSANCmhyZWY9Imh0dHA6Ly93d3cuZGVhaS1zdHlsZS5uZXQvY2FzYW5vdmEv PzE5MzUiPmh0dHA6Ly93d3cuZGVhaS1zdHlsZS5uZXQvY2FzYW5vdmEvPzE5MzU8L0E+PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIj48Rk9OVCBzaXplPTI+ PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj Ij48Rk9OVCBzaXplPTI+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iTVMgVUkgR290aGljIj48Rk9OVCBzaXplPTI+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEJS PjxGT05UIA0Kc2l6ZT0yPhskQiVhITwla0lUTVckTkp9JE8kMyRBJGkiLRsoQjxCUj48L0ZPTlQ+ PEZPTlQgZmFjZT0bJEJBV0JOGyhCIHNpemU9Mj48QSANCmhyZWY9Im1haWx0bzpjb25jZXB0M19u ZXRAeWFob28uY2EiPmNvbmNlcHQzX25ldEB5YWhvby5jYTwvQT48L0ZPTlQ+PEEgDQpocmVmPSJt YWlsdG86Y29uY2VwdF9uZXRAeWFob28uY2EiPjxGT05UIA0Kc2l6ZT0yPjwvRk9OVD48L0E+PEJS PjwvRElWPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0006_01C62CB8.EF99DA80-- From owner-namedroppers@ops.ietf.org Tue Feb 14 15:55:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F97DJ-0003Mg-Ln for dnsext-archive@megatron.ietf.org; Tue, 14 Feb 2006 15:55:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26958 for ; Tue, 14 Feb 2006 15:54:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F977l-000AUr-1q for namedroppers-data@psg.com; Tue, 14 Feb 2006 20:50:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F977k-000AUc-Al for namedroppers@ops.ietf.org; Tue, 14 Feb 2006 20:50:12 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1EKo2BX005728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F977a-0004NE-3E; Tue, 14 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-rsasha256-00.txt Message-Id: Date: Tue, 14 Feb 2006 15:50:02 -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 : Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-00.txt Pages : 7 Date : 2006-2-14 This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rsasha256-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-dnssec-rsasha256-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: <2006-2-14133710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-rsasha256-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-14133710.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. archive: From realdick_kiko@hotmail.co.jp Wed Feb 15 08:05:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MLB-0003mo-Cc for dnsext-archive@megatron.ietf.org; Wed, 15 Feb 2006 08:05:05 -0500 Received: from ocn.ne.jp ([221.212.57.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06946 for ; Wed, 15 Feb 2006 08:03:16 -0500 (EST) Date: Wed, 15 Feb 2006 08:03:16 -0500 (EST) Message-Id: <200602151303.IAA06946@ietf.org> Received: from vhosjmpgn9 (unknown [240.112.16.168]) by smtp35 (Coremail) with SMTP id XIPU3biNFGxjy1up.1 for ; Sat, 08 Feb 2003 07:22:12 +0800 (CST) X-Originating-IP: [240.112.16.168] Subject: =?iso-2022-jp?B?GyRCOHg8MCU1JSQlSCFWNF04KyQoPi89dyFXGyhC?= From: =?shift-jis?B?a2FzdW1pZGF5bw==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C631AB.66A13F50" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C631AB.66A13F50 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $BL5NA2hA|!&F02hG[?.Cf!*(B $B"((B18$B:PL$K~$NJ}$O$4Mw$K$J$l$^$;$s$N$G$4Cm0U2<$5$$"((B $B8x<0%5%$%H!V4]8+$(>/=w!W$r$4MwD:$/$K$"$?$C$F$NJ}K!$r5-F~CW$7$^$9!#(B $B#1!&2<5-(BURL$B$r%/%j%C%/$7!J2>!K=P2q$$7O%5%$%H$KEPO?$r9T$&!#(B $B#2!&Aw$i$l$F$-$?%Q%9!"%"%I%l%9$r;HMQ$7EPO?$r9T$C$?=P2q$$7O$KF~>l!#(B $B#3!&%5%$%HFb$N7G<(HD$K=q$-9~$^$l$F$$$k!V%_%/(B0055$B!W$H$$$&=w@-$r%/%j%C%/$7$FD:$/$H$4MwD:$1$k;EAH$_$H$J$C$F$*$j$^$9!#(B $B",>/!9$4LLE]$r$*$+$1$$$?$7$^$9$,!"$J$K$;L5NAL5=$@52hA|!&F02h$rG[?.$7$F$*$j$^$9!#5,@)$N0Y$G$9$N$G(B $B!!$"$7$+$i$:!&!&!&!&!#(B http://www.awg5.net/?2014 $B%a!<%kITMW"-(B priority7_net@yahoo.ca ------=_NextPart_000_0024_01C631AB.66A13F50 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$BL5NA2hA|!&F02hG[?.Cf!*=1B(B
=1B$B"(=1B(B18=1B$B:PL$K~$NJ}$O$4Mw$K$J$l$^$;$s$N$G$4Cm0U2<$5$$"= (=1B(B
 
=1B$B8x<0%5%$%H!V4]8+$(>/=3Dw!W$r$4MwD:$/$K$"$?$C$F$NJ}K!$r5-F~C= W$7$^$9!#=1B(B
=1B$B#1!&2<5-=1B(BURL=1B$B$r%/%j%C%/$7!J2>!K=3DP2q$$7O%5%$%H$KEP= O?$r9T$&!#=1B(B
=1B$B#2!&Aw$i$l$F$-$?%Q%9!"%"%I%l%9$r;HMQ$7EPO?$r9T$C$?=3DP2q$$7= O$KF~>l!#=1B(B
=1B$B#3!&%5%$%HFb$N7G<(HD$K=3Dq$-9~$^$l$F$$$k!V%_%/=1B(B0055=1B$= B!W$H$$$&=3Dw@-$r%/%j%C%/$7$FD:$/$H$4MwD:$1$k;EAH$_$H$J$C$F$*$j$^$9!#=1B(= B
 
=1B$B",>/!9$4LLE]$r$*$+$1$$$?$7$^$9$,!"$J$K$;L5NAL5=3D$@52hA|!&F= 02h$rG[?.$7$F$*$j$^$9!#5,@)$N0Y$G$9$N$G=1B(B
=1B$B!!$"$7$+$i$:!&!&!&!&!#=1B(B
 
http://www.awg5.net/?2014
 
 
 
 
 
 
 
 
 
 
 
=1B$B%a!<%kITMW"-=1B(B
priority7_net@yahoo.ca
 
------=_NextPart_000_0024_01C631AB.66A13F50-- From coniwyss@barrierefrei.com Thu Feb 16 08:20:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9j3O-00026C-0r for dnsext-archive@megatron.ietf.org; Thu, 16 Feb 2006 08:20:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21954 for ; Thu, 16 Feb 2006 08:18:26 -0500 (EST) Received: from [222.108.220.117] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9jHW-0004bu-7A for dnsext-archive@ietf.org; Thu, 16 Feb 2006 08:34:56 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for dnsext-archive@ietf.org; Thu, 16 Feb 2006 22:19:51 +0900 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for dnsext-archive@ietf.org; Thu, 16 Feb 2006 22:19:51 +0900 Message-ID: <000001c63325$b62f5680$0100007f@localhost> From: "Avery Evans" To: Subject: Don't be inadequate anymore! Date: Thu, 16 Feb 2006 22:19:51 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63325.B62F5680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63325.B62F5680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.all-love-pillzz.net/pt/?46&acoqi ------=_NextPart_000_0001_01C63325.B62F5680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C63325.B62F5680-- From ane.moeller@aseks.com Thu Feb 16 10:43:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lHa-000624-1y for dnsext-archive@megatron.ietf.org; Thu, 16 Feb 2006 10:43:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04766 for ; Thu, 16 Feb 2006 10:41:13 -0500 (EST) Received: from [61.58.146.105] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9lVR-00021j-2t for dnsext-archive@ietf.org; Thu, 16 Feb 2006 10:57:46 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for dnsext-archive@ietf.org; Thu, 16 Feb 2006 23:42:01 +0800 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for dnsext-archive@ietf.org; Thu, 16 Feb 2006 23:42:01 +0800 Message-ID: <000001c63339$b8031500$0100007f@localhost> From: "Richard Garcia" To: Subject: Other guys are improving themselves..are you? Date: Thu, 16 Feb 2006 23:42:01 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63339.B8031500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63339.B8031500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.all-love-pillzz.net/pt/?46&cadss ------=_NextPart_000_0001_01C63339.B8031500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C63339.B8031500-- From ketchyawl@artfirefilms.com Fri Feb 17 09:46:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6sF-0000cg-Qb for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 09:46:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14138 for ; Fri, 17 Feb 2006 09:44:31 -0500 (EST) Received: from e176095016.adsl.alicedsl.de ([85.176.95.16] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FA76e-0002Wy-98 for dnsext-archive@ietf.org; Fri, 17 Feb 2006 10:01:15 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for dnsext-archive@ietf.org; Fri, 17 Feb 2006 15:16:01 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for dnsext-archive@ietf.org; Fri, 17 Feb 2006 15:16:01 +0100 Message-ID: <000001c633fa$cebd7080$0100007f@localhost> From: "Salvador Russell" To: Subject: Last offer- Discount special for PE patch almost over! Date: Fri, 17 Feb 2006 15:16:01 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C633FA.CEBD7080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C633FA.CEBD7080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.all-love-pillzz.net/pt/?46&vjduk ------=_NextPart_000_0001_01C633FA.CEBD7080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C633FA.CEBD7080-- From pat.funderburk@pellicano.biz Fri Feb 17 10:00:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA712-0003ws-AX for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 09:55:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06528 for ; Fri, 17 Feb 2006 09:13:04 -0500 (EST) Received: from i577ac5c4.versanet.de ([87.122.197.196] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9wt6-00020H-SU for dnsext-archive@ietf.org; Thu, 16 Feb 2006 23:06:35 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for dnsext-archive@ietf.org; Fri, 17 Feb 2006 04:52:11 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for dnsext-archive@ietf.org; Fri, 17 Feb 2006 04:52:11 +0100 Message-ID: <000001c6339f$99d00000$0100007f@localhost> From: "Lane Thomas" To: Subject: Last chance to supercharge your performance! Date: Fri, 17 Feb 2006 04:52:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6339F.99D00000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6339F.99D00000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.all-love-pillzz.net/pt/?46&ofobr ------=_NextPart_000_0001_01C6339F.99D00000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C6339F.99D00000-- From owner-namedroppers@ops.ietf.org Fri Feb 17 10:09:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7EF-0003sB-97 for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:09:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19214 for ; Fri, 17 Feb 2006 10:07:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9wcE-000MDV-Ce for namedroppers-data@psg.com; Fri, 17 Feb 2006 03:49:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9wcC-000MD9-N7 for namedroppers@ops.ietf.org; Fri, 17 Feb 2006 03:49:04 +0000 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.17038546; Thu, 16 Feb 2006 22:48:50 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 22:48:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR consensus statement Date: Thu, 16 Feb 2006 22:48:48 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73046E1553@PACDCEXCMB01.cable.comcast.com> Thread-Topic: LLMNR consensus statement Thread-Index: AcYzU0Kynxp4ken8TtukOjSZx5L9fwAIRktg From: "Durand, Alain" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , X-OriginalArrivalTime: 17 Feb 2006 03:48:50.0023 (UTC) FILETIME=[100EBF70:01C63375] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > That means that only Sullivan, Borzmeyer, Thaler, and Hall=20 > indicated that they had read the document in detail which=20 > does hardly meet the set quorum (Aboba clearly read the said=20 > doc, but think we do not include him in the count). I would really hate to see this work come to an end because not enough people read the final draft. This would be a shame On the wg and the IETF as a whole. Question to the chairs: If one more person was to speak up, would it help saving the draft? If the answer is yes, I will commit myself to re-read the document (I read a version of it not long ago) and pledge support. - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 17 10:09:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7EK-0003us-04 for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:09:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19223 for ; Fri, 17 Feb 2006 10:07:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9stB-0008VE-1p for namedroppers-data@psg.com; Thu, 16 Feb 2006 23:50:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9st8-0008Uf-9h for namedroppers@ops.ietf.org; Thu, 16 Feb 2006 23:50:18 +0000 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k1GNoH5i028650 for ; Thu, 16 Feb 2006 15:50:17 -0800 (PST) Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay7.apple.com (Apple SCV relay) with SMTP id 93776A9 for ; Thu, 16 Feb 2006 15:50:17 -0800 (PST) Subject: Re: LLMNR consensus statement Date: Thu, 16 Feb 2006 15:50:18 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <20060216235017.93776A9@relay7.apple.com> X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >We are sad we have to ask for this consensus position. Bernard has >been an excellent document editor and we, the chairs and others >involved, should have gauged the quorum for this work earlier, and at >several stages of development. This is not the most elegant end of >this process. If you think there are more elegant ways forward please >let us know. > >Our apologies to Bernard and others that have been constructively and >co-operatively working on this document. I have great respect for Benard. We worked well together on RFC 3927, and I was never happy that in this instance we found ourselves on opposite sides of a debate concerning two documents that were very much like two twins separated at birth. I view this as an opportunity to move forward productively, and I welcome the prospect of working constructively with Bernard and other interested parties to improve draft-cheshire-dnsext-multicastdns.txt. This gives us the chance to improve and enhance the protocol currently being used on tens of millions of deployed devices, rather than architecting a competing document which may well have gone nowhere. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 17 10:09:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7EK-0003ve-Tz for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:09:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19226 for ; Fri, 17 Feb 2006 10:07:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA6gH-00070A-G8 for namedroppers-data@psg.com; Fri, 17 Feb 2006 14:33:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA6gF-0006zE-Q6 for namedroppers@ops.ietf.org; Fri, 17 Feb 2006 14:33:56 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1HEXjQw031525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2006 15:33:45 +0100 From: Simon Josefsson To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> <20060217133415.GA24796@nic.fr> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060217:bortzmeyer@nic.fr::VAJNgg/Lfjklpf/z:0XjN X-Hashcash: 1:21:060217:namedroppers@ops.ietf.org::mEuNEuFc4MOfGxcT:4dB8 Date: Fri, 17 Feb 2006 15:33:40 +0100 In-Reply-To: <20060217133415.GA24796@nic.fr> (Stephane Bortzmeyer's message of "Fri, 17 Feb 2006 14:34:15 +0100") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA19226 Stephane Bortzmeyer writes: > On Thu, Feb 16, 2006 at 06:26:56PM -0500, > =D3lafur Gu=F0mundsson wrote=20 > a message of 52 lines which said: > >> We would also like to working group for support to work on DNS and >> naming API interfaces, such as are in RFC 3493-bis ,in the light of >> DNSSEC, ldap, mdns and llmnr. > > Is there a kind soul which can provide a list of pointers to API > proposals? I find no 3493-bis anywhere and no actual proposals, just > vague ideas about how to extend getaddrinfo(). For IDN, I have proposed an extension for getaddrinfo: http://josefsson.org/libidn/getaddrinfo-idn.txt That is widely deployed today, and may be on the path towards POSIX standardization. There are other C APIs for generic DNS lookups, compare BINDv9's getrrsetbyname. It doesn't provide asynchronous operations, though, as far as I know, so it has limited applicability. I'm not sure IETF is the best place to standardize any of this though. It doesn't seem to be within this WG's charter. I'd rather see other documents get done (like NSEC3) before this WG take on additional work. If the WG isn't reviewing its own work items, it doesn't seem like it should take on even more stuff. Cheers, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 17 10:09:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7EN-0003wO-01 for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:09:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19235 for ; Fri, 17 Feb 2006 10:07:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA1ki-000EJI-H3 for namedroppers-data@psg.com; Fri, 17 Feb 2006 09:18:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA1kf-000EIu-MR for namedroppers@ops.ietf.org; Fri, 17 Feb 2006 09:18:10 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1H9HpmG013435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2006 10:17:52 +0100 From: Simon Josefsson To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060217:ogud@ogud.com::ujgXCzqG5EwgV9Uf:+Br X-Hashcash: 1:21:060217:namedroppers@ops.ietf.org::zgRV4MTM/V+ljFcN:ExPg Date: Fri, 17 Feb 2006 10:17:47 +0100 In-Reply-To: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> (=?iso-8859-1?Q?=D3lafur=09Gu=F0mundsson's?= message of "Thu, 16 Feb 2006 18:26:56 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA19235 =D3lafur Gu=F0mundsson writes: > Therefore we propose to Inform the AD that this working group has no > quorum to continue work on this document and that it be published as > an informational document. If this WG didn't have the resources to review it, moving it forward on the standards track as an individual submission is another option. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 17 10:09:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7EN-00040n-PM for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:09:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19245 for ; Fri, 17 Feb 2006 10:07:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA1QR-000Cye-R0 for namedroppers-data@psg.com; Fri, 17 Feb 2006 08:57:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA1QQ-000CyP-Mk for namedroppers@ops.ietf.org; Fri, 17 Feb 2006 08:57:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6A15726C0F4 for ; Fri, 17 Feb 2006 09:57:13 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 25FAC26C0DD for ; Fri, 17 Feb 2006 09:57:12 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2180358ECE2 for ; Fri, 17 Feb 2006 09:57:12 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 1A89316AAFC; Fri, 17 Feb 2006 09:57:12 +0100 (CET) Date: Fri, 17 Feb 2006 09:57:12 +0100 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Message-ID: <20060217085712.GA29218@nic.fr> References: <20060216235017.93776A9@relay7.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060216235017.93776A9@relay7.apple.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Feb 16, 2006 at 03:50:18PM -0800, Stuart Cheshire wrote a message of 31 lines which said: > I welcome the prospect of working constructively with Bernard and > other interested parties to improve > draft-cheshire-dnsext-multicastdns.txt. The SPF (Sender Policy Framework, for email authentication) people were always turned down by the IETF when trying to push their protocol as a RFC, with the reasoning that IETF is not here to "rubber stamp" any external proprietary protocol, even widely deployed. > the chance to improve and enhance the protocol currently being used > on tens of millions of deployed devices, rather than architecting a > competing document which may well have gone nowhere. Is there somewhere IETF guidance about this issue? Basically, you suggest that Apple's protocol should be approved by IETF, just because of prior deployment, which may encourage other people to deploy first (and think later), in the hope of using the same argument. In working groups like MARID, there has been a lot of discussion about the strength of the "prior deployment" argument but I do not remember a clear conclusion. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 17 10:09:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7EQ-00042b-IM for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:09:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19252 for ; Fri, 17 Feb 2006 10:07:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9sWd-0006ze-R6 for namedroppers-data@psg.com; Thu, 16 Feb 2006 23:27:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9sWc-0006zK-MX for namedroppers@ops.ietf.org; Thu, 16 Feb 2006 23:27:02 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1GNQu2X002415 for ; Thu, 16 Feb 2006 18:26:56 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2006 18:26:56 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: LLMNR consensus statement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, In http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00028.html we asked this working group to review the LLMNR specifications and answer a number of questions. In this mail we want to address the following: "If we do not get sufficient feedback on this i.e. fewer than 5 people" Our assessment is as follows: - Vixie and Lewis responded with doubts on putting this document on standards track. Lewis explicitly stated he did not read the document. - Sullivan and Borzmeyer explicitly stated they read and supported the draft - Finch only posed a (guiding) question and made no statement - Thaler supports the document. - Hall raised a number of security issues and does not seem to support publication of the document in its current form. That means that only Sullivan, Borzmeyer, Thaler, and Hall indicated that they had read the document in detail which does hardly meet the set quorum (Aboba clearly read the said doc, but think we do not include him in the count). Therefore we propose to Inform the AD that this working group has no quorum to continue work on this document and that it be published as an informational document. (Possibly after addressing the issues that Eric came up with). We would also like to working group for support to work on DNS and naming API interfaces, such as are in RFC 3493-bis ,in the light of DNSSEC, ldap, mdns and llmnr. We would need volunteers to pull this work. We are sad we have to ask for this consensus position. Bernard has been an excellent document editor and we, the chairs and others involved, should have gauged the quorum for this work earlier, and at several stages of development. This is not the most elegant end of this process. If you think there are more elegant ways forward please let us know. Our apologies to Bernard and others that have been constructively and co-operatively working on this document. --Olafur and Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 17 10:09:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7EL-0003vg-TY for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:09:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19233 for ; Fri, 17 Feb 2006 10:07:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA5kY-0003FH-Vj for namedroppers-data@psg.com; Fri, 17 Feb 2006 13:34:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA5kX-0003F1-QX for namedroppers@ops.ietf.org; Fri, 17 Feb 2006 13:34:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6606B26C0FB for ; Fri, 17 Feb 2006 14:34:16 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 752AD26C0DD for ; Fri, 17 Feb 2006 14:34:15 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 72CC258ECE2 for ; Fri, 17 Feb 2006 14:34:15 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 6BB8716AAFC; Fri, 17 Feb 2006 14:34:15 +0100 (CET) Date: Fri, 17 Feb 2006 14:34:15 +0100 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Message-ID: <20060217133415.GA24796@nic.fr> References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA19233 On Thu, Feb 16, 2006 at 06:26:56PM -0500, =D3lafur Gu=F0mundsson wrote=20 a message of 52 lines which said: > We would also like to working group for support to work on DNS and > naming API interfaces, such as are in RFC 3493-bis ,in the light of > DNSSEC, ldap, mdns and llmnr. Is there a kind soul which can provide a list of pointers to API proposals? I find no 3493-bis anywhere and no actual proposals, just vague ideas about how to extend getaddrinfo(). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 17 10:15:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7K4-0007JU-VV for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:15:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20738 for ; Fri, 17 Feb 2006 10:13:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA6nl-0007d6-ST for namedroppers-data@psg.com; Fri, 17 Feb 2006 14:41:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FA6nl-0007ct-4w for namedroppers@ops.ietf.org; Fri, 17 Feb 2006 14:41:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6192026C10B; Fri, 17 Feb 2006 15:41:40 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 3E03626C109; Fri, 17 Feb 2006 15:41:39 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3B02C58ECE2; Fri, 17 Feb 2006 15:41:39 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 2D72916AAFC; Fri, 17 Feb 2006 15:41:39 +0100 (CET) Date: Fri, 17 Feb 2006 15:41:39 +0100 From: Stephane Bortzmeyer To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Message-ID: <20060217144139.GA31819@nic.fr> References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> <20060217133415.GA24796@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Feb 17, 2006 at 03:33:40PM +0100, Simon Josefsson wrote a message of 33 lines which said: > There are other C APIs for generic DNS lookups, Warning, I was talking about resolution-agnostic APIs like getaddrinfo() (which works as well for LDAP, /etc/hosts, DNS...). > I'm not sure IETF is the best place to standardize any of this > though. Neither am I but: 1) It is an interesting subject, anyway, and worth studying. 2) Some people raised the issue during the IETF Last Call and, unfortunately, it seems to have been seriously considered (instead of being dismissed as out-of-scope). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From bdoman@alphington.com Fri Feb 17 10:29:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA70j-0001ci-5I for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 09:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02627 for ; Fri, 17 Feb 2006 09:03:38 -0500 (EST) Received: from [202.138.139.217] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FA095-0006M6-C7 for dnsext-archive@ietf.org; Fri, 17 Feb 2006 02:35:35 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for dnsext-archive@ietf.org; Sat, 01 Jan 2000 04:36:52 -0800 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for dnsext-archive@ietf.org; Sat, 01 Jan 2000 04:36:52 -0800 Message-ID: <000001c633bc$47e9a300$0100007f@localhost> From: "Miles Thompson" To: Subject: Hey bro, check out the huge sale these guys are offering Date: Sat, 01 Jan 2000 04:36:52 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C633BC.47E9A300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C633BC.47E9A300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.all-love-pillzz.net/pt/?46&dwvenu ------=_NextPart_000_0001_01C633BC.47E9A300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C633BC.47E9A300-- From owner-namedroppers@ops.ietf.org Fri Feb 17 18:07:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAEgm-0006Ef-MH for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 18:07:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22394 for ; Fri, 17 Feb 2006 18:05:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAEcg-000EYl-RG for namedroppers-data@psg.com; Fri, 17 Feb 2006 23:02:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FAEcf-000EYX-NT for namedroppers@ops.ietf.org; Fri, 17 Feb 2006 23:02:45 +0000 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k1HN2jcT024132 for ; Fri, 17 Feb 2006 15:02:45 -0800 (PST) Received: from [17.219.209.205] (unknown [17.219.209.205]) by relay5.apple.com (Apple SCV relay) with SMTP id B77D6324002 for ; Fri, 17 Feb 2006 15:02:44 -0800 (PST) Subject: Re: LLMNR consensus statement Date: Fri, 17 Feb 2006 15:02:44 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <20060217230244.B77D6324002@relay5.apple.com> X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >Is there somewhere IETF guidance about this issue? Basically, you >suggest that Apple's protocol should be approved by IETF, just because >of prior deployment, which may encourage other people to deploy first >(and think later), in the hope of using the same argument. I think you misunderstood me. I was not asking or expecting the IETF to "rubber stamp" anything. My point was that if there are people who sincerely believe that our mDNS protocol is doing harm on the network, then working together to remedy those deficiencies is the path most likely to achieve the desired result. Issuing a competing RFC in the hope that it would displace the established protocol "in the wild" really had about as much chance of succeeding as government- endorsed OSI had of displacing TCP/IP in the 1990s. Too many products today already depend on mDNS. If you have a network printer on your network then you probably already have mDNS on your network, whether you know it or not -- you can check for yourself by downloading Bonjour for Windows from Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From ke_i_ko0011@yahoo.de Fri Feb 17 22:06:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAIQL-0004ql-Dc for dnsext-archive@megatron.ietf.org; Fri, 17 Feb 2006 22:06:17 -0500 Received: from allabout.co.jp ([221.212.57.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14986 for ; Fri, 17 Feb 2006 22:04:23 -0500 (EST) Date: Fri, 17 Feb 2006 22:04:23 -0500 (EST) Message-Id: <200602180304.WAA14986@ietf.org> Received: from zkg6 (unknown [75.109.132.110]) by smtp65 (Coremail) with SMTP id 5iyRwiM81Mx5zyAR.1 for ; Mon, 10 Feb 2003 18:48:52 +0800 (CST) X-Originating-IP: [75.109.132.110] Subject: =?iso-2022-jp?B?GyRCN24bKEI1MBskQiFBJE41VSU1JV0bKEI=?= From: =?shift-jis?B?dGFuYWth?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C2CED1.B447B440" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C2CED1.B447B440 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCOWI1aUlYP00kSCROTDVOQSROPVAycSQkJHJEczYhJDckRiReJDkhIz13QC0kT0VQTz9OQRso QjUbJEJLfDFfISJDS0AtJE9MNU5BJEgkSiRDJEYkXiQ5JE4kRyEiPz83dSRKPXdALSQ3JCskKiRq JF4kOyRzISMkOSRZJEYkTiU7JWwlViQsNGkyaEF8JHJFOiQoJEYlYSVrJSIlSSRiOlwkOyRGJCpC VCRBJEckOSEjJCo2YiRPJCIkayQsMCYkSzdDJF4kbCRKJCQ9d0AtQyMkcj9IQk4kR0x+JDckRiQi JDIkRiQvJEAkNSQkISM3bhsoQjEbJEIhQRsoQjMbJEIycyROJUchPCVIJEc3bhsoQjUwGyRCJE41 VSU1JV0kLDpHRGM4QiROJWklJCVzJEokTiRHISI9d0AtJEskaCRDJEYkTyQ9JGwwSj5lJE41VSU1 JV0kLDR8QlQkRyQtJF4kOSRoISMhISEhISEbKEJodHRwOi8vd3d3LmF3ZzYubmV0Lz8yMDA1GyRC JDUkaSRLISI/Pzd1JEo4cjpdJHI0dUs+JDUkbCRrSn0kTiQ/JGEkSyEiTDVOQSRHNS5KfSROJCo9 OyReJCQkTjZhJC8kTj13QC0lOyVsJVYkckw1TkEkRzghOnckOSRrPzckNyQkJDQ+UjJwJTUhPCVT JTkkckRzNiEkJCQ/JDckXiQ5ISMhISEhGyhCICBodHRwOi8vd3d3LmF3ZzYubmV0Lz8yMDA2GyRC OiMkSiRpMnEwd0hxGyhCPxskQkcvMnFIcUV5MGxAWkw1TkEhKiQ1JGkkSxsoQjEwLDAwMBskQjFf SiwkTkw1TkElXSUkJXMlSCRyJVclbCU8JXMlSCEqJWEhPCVrSVRNVyROSn0kTyQzJEEkaSRLIi0b KEJwcmlvcml0eTdfbmV0QHlhaG9vLmNh ------=_NextPart_000_000F_01C2CED1.B447B440 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj IiBzaXplPTI+PEZPTlQgc2l6ZT0zPjxQUkU+PFRUPjxGT05UIGNsYXNzPWx0YnByZT4bJEI5YjVp SVg/TSRIJE5MNU5BJE49UDJxJCQkckRzNiEkNyRGJF4kOSEjGyhCPEJSPhskQj13QC0kT0VQTz9O QRsoQjUbJEJLfDFfISJDS0AtJE9MNU5BJEgkSiRDJEYkXiQ5JE4kRyEiPz83dSRKPXdALSQ3GyhC PEJSPhskQiQrJCokaiReJDskcyEjGyhCPEJSPhskQiQ5JFkkRiROJTslbCVWJCw0aTJoQXwkckU6 JCgkRiVhJWslIiVJJGI6XCQ7JEYkKkJUJEEkRyQ5ISMkKhsoQjxCUj4bJEI2YiRPJCIkayQsMCYk SzdDJF4kbCRKJCQ9d0AtQyMkcj9IQk4kR0x+JDckRiQiJDIkRiQvJEAkNSQkISMbKEI8QlI+GyRC N24bKEIxGyRCIUEbKEIzGyRCMnMkTiVHITwlSCRHN24bKEI1MBskQiRONVUlNSVdJCw6R0RjOEIk TiVpJSQlcyRKJE4kRyEiPXdALSRLGyhCPEJSPhskQiRoJEMkRiRPJD0kbDBKPmUkTjVVJTUlXSQs NHxCVCRHJC0kXiQ5JGghIxsoQjxCUj4bJEIhISEhISEbKEI8QSBocmVmPSJodHRwOi8vd3d3LmF3 ZzYubmV0Lz8yMDA1Ij5odHRwOi8vd3d3LmF3ZzYubmV0Lz8yMDA1PC9BPjwvRk9OVD48L1RUPjxU VD48Rk9OVCBjbGFzcz1sdGJwcmU+PEJSPhskQiQ1JGkkSyEiPz83dSRKOHI6XSRyNHVLPiQ1JGwk a0p9JE4kPyRhJEshIkw1TkEkRzUuSn0kTiQqPTskXhsoQjxCUj4bJEIkJCRONmEkLyROPXdALSU7 JWwlViRyTDVOQSRHOCE6dyQ5JGs/NyQ3JCQkND5SMnAlNSE8JVMlOSRyRHMbKEI8QlI+GyRCNiEk JCQ/JDckXiQ5ISMbKEI8QlI+GyRCISEhIRsoQiZuYnNwOyA8QSBocmVmPSJodHRwOi8vd3d3LmF3 ZzYubmV0Lz8yMDA2Ij5odHRwOi8vd3d3LmF3ZzYubmV0Lz8yMDA2PC9BPjwvRk9OVD48L1RUPjwv UFJFPjxQUkU+PFRUPjxGT05UIGNsYXNzPWx0YnByZT4bJEI6IyRKJGkycTB3SHEbKEI/GyRCRy8y cUhxRXkwbEBaTDVOQSEqJDUkaSRLGyhCMTAsMDAwGyRCMV9KLCROTDVOQSVdJSQlcxsoQjxCUj4b JEIlSCRyJVclbCU8JXMlSCEqGyhCPC9GT05UPjwvVFQ+PC9QUkU+PFBSRT48VFQ+PEZPTlQgY2xh c3M9bHRicHJlPjwvRk9OVD48L1RUPiZuYnNwOzwvUFJFPjxQUkU+PFRUPjxGT05UIGNsYXNzPWx0 YnByZT48L0ZPTlQ+PC9UVD4mbmJzcDs8L1BSRT48UFJFPjxUVD48Rk9OVCBjbGFzcz1sdGJwcmU+ GyRCJWEhPCVrSVRNVyROSn0kTyQzJEEkaSRLIi0bKEI8QlI+PEEgaHJlZj0ibWFpbHRvOnByaW9y aXR5N19uZXRAeWFob28uY2EiPnByaW9yaXR5N19uZXRAeWFob28uY2E8L0E+PC9GT05UPjwvVFQ+ PC9QUkU+PC9GT05UPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000F_01C2CED1.B447B440-- From owner-namedroppers@ops.ietf.org Sat Feb 18 03:38:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FANbk-0002qy-MK for dnsext-archive@megatron.ietf.org; Sat, 18 Feb 2006 03:38:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29890 for ; Sat, 18 Feb 2006 03:36:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FANWP-000AEO-N0 for namedroppers-data@psg.com; Sat, 18 Feb 2006 08:32:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FANWO-000AE9-Rr for namedroppers@ops.ietf.org; Sat, 18 Feb 2006 08:32:52 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FANWN-0006P0-G1 for namedroppers@ops.ietf.org; Sat, 18 Feb 2006 03:32:51 -0500 Received: by internaut.com (Postfix, from userid 1000) id CBAEB5EAFF; Sat, 18 Feb 2006 00:32:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id A7D8A5EAFE for ; Sat, 18 Feb 2006 00:32:50 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Sat, 18 Feb 2006 00:32:50 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Stuart Cheshire said: "I have great respect for Bernard. We worked well together on RFC 3927, and I was never happy that in this instance we found ourselves on opposite sides of a debate concerning two documents that were very much like two twins separated at birth." My view is that Stuart and I are actually on the same side -- had the IETF not intervened I have little doubt that there would be a single multicast link-local name resolution protocol today, interoperating on all platforms. We worked together on RFC 3927, we just recently worked together on DNAv4, and I look forward to working with Stuart again in the future. "This gives us the chance to improve and enhance the protocol currently being used on tens of millions of deployed devices, rather than architecting a competing document which may well have gone nowhere." Given the past history, I have my doubts as to whether the IETF has anything to contribute here, even in terms of "improving" or "enhancing" mDNS. More likely is that the IETF will not standardize any specifications; it is even possible that no documents will be published as RFCs. That's not a very satisfactory end to a process that began seven years ago at the Networking in the Small (NITS) BOF at IETF 44 in Minneapolis in March 1999. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 20 12:46:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBF7F-00004q-Ob for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 12:46:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBF7A-0006bY-FB for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 12:46:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBF28-000Nwb-4R for namedroppers-data@psg.com; Mon, 20 Feb 2006 17:41:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.91.160.27] (helo=denic.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBF27-000NwQ-70 for namedroppers@ops.ietf.org; Mon, 20 Feb 2006 17:41:11 +0000 Received: by unknown.office.denic.de (Postfix, from userid 501) id C1126265FF3; Mon, 20 Feb 2006 18:41:06 +0100 (CET) Date: Mon, 20 Feb 2006 18:41:06 +0100 From: Peter Koch To: namedroppers@ops.ietf.org Subject: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" Message-ID: <20060220174106.GD994@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Colleagues, during a discussion at a different venue the question arose whether or not the "DNSSEC RRs" should be included in a response to an ANY query with DO=0. pro: section 3 of RFC 4035 (top of page 9) says: A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below. "treat ... as it would any other RRset" would support ANY covering those, which is consistent with RFC 3225 (which explicitly listed ANY). Also, this would be consistent with RFC 3597, not requiring special handling for "unknown" types. con: RFC 4035, 3.2 says: 3.2.1. The DO Bit The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested. The important part is the last full sentence. Also: the DO bit was introduced to protect "innocent" resolvers from DNSSEC RRs they might not expect or understand. Opinions? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 20 13:02:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBFN0-0000xM-Vk for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 13:02:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBFMz-00073X-MT for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 13:02:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBFKf-000PO6-Sq for namedroppers-data@psg.com; Mon, 20 Feb 2006 18:00:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBFKf-000PNs-75 for namedroppers@ops.ietf.org; Mon, 20 Feb 2006 18:00:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C17E611425; Mon, 20 Feb 2006 18:00:20 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Peter Koch cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" In-Reply-To: Your message of "Mon, 20 Feb 2006 18:41:06 +0100." <20060220174106.GD994@unknown.office.denic.de> References: <20060220174106.GD994@unknown.office.denic.de> Date: Mon, 20 Feb 2006 18:00:20 +0000 Message-Id: <20060220180020.C17E611425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 # Also: the DO bit was introduced to protect "innocent" resolvers from # DNSSEC RRs they might not expect or understand. # # Opinions? i think a security aware server should elide dnssec metadata unless DO is set, whereas we already know that a security-nonaware server will not do this and will never do this. we can hope that a security non-aware server will never see dnssec metadata but we know this isn't true either. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 20 14:38:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGrp-0006ni-SC for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 14:38:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGro-0002nx-6y for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 14:38:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBGp1-0005X1-Rc for namedroppers-data@psg.com; Mon, 20 Feb 2006 19:35:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBGp0-0005Wq-T6 for namedroppers@ops.ietf.org; Mon, 20 Feb 2006 19:35:47 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id E972911D531; Mon, 20 Feb 2006 11:35:45 -0800 (PST) From: Wes Hardaker To: Stephane Bortzmeyer Cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Organization: Sparta References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> <20060217133415.GA24796@nic.fr> <20060217144139.GA31819@nic.fr> Date: Mon, 20 Feb 2006 11:35:44 -0800 In-Reply-To: <20060217144139.GA31819@nic.fr> (Stephane Bortzmeyer's message of "Fri, 17 Feb 2006 15:41:39 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >>>>> On Fri, 17 Feb 2006 15:41:39 +0100, Stephane Bortzmeyer said: Stephane> Neither am I but: Stephane> 1) It is an interesting subject, anyway, and worth studying. We're interested heavily in it too and have a -00 ID that should be published by the cutoff date with a bunch of DNSSEC aware API calls that both allow you to match existing APIs as much as possible as well as let you give greater control over the policies the APIs are likely internally going to have to implement. [the dnssec-tools project on sourceforge already has a prototype implementation of the APIs as well] If there is enough people that thinks the work should be done, then I think it should be done. As to when the timing is right, that's certainly a good question. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 20 15:01:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHDc-00089A-7A for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 15:01:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBHDa-0003Ic-TR for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 15:01:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBHBX-00076a-Ik for namedroppers-data@psg.com; Mon, 20 Feb 2006 19:59:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBHBX-00076O-5E for namedroppers@ops.ietf.org; Mon, 20 Feb 2006 19:59:03 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 303BA11D531; Mon, 20 Feb 2006 11:59:01 -0800 (PST) From: Wes Hardaker To: Stephane Bortzmeyer Cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Organization: Sparta References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> <20060217133415.GA24796@nic.fr> <20060217144139.GA31819@nic.fr> Date: Mon, 20 Feb 2006 11:59:01 -0800 In-Reply-To: (Wes Hardaker's message of "Mon, 20 Feb 2006 11:35:44 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >>>>> On Mon, 20 Feb 2006 11:35:44 -0800, Wes Hardaker said: Stephane> Neither am I but: Stephane> 1) It is an interesting subject, anyway, and worth studying. Wes> We're interested heavily in it too and have a -00 ID that should be Wes> published by the cutoff date with a bunch of DNSSEC aware API Wes> calls Whoops... forgot this was in the IDN part of the discussion in my head as I was tracing the thread.... The document I referred to doesn't have any IDN specific stuff in it. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 20 15:59:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBI7y-0001d3-VB for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 15:59:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBI7w-00057n-6G for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 15:59:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBI5P-000B4o-NX for namedroppers-data@psg.com; Mon, 20 Feb 2006 20:56:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.43] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBI5O-000B4Z-JI for namedroppers@ops.ietf.org; Mon, 20 Feb 2006 20:56:46 +0000 Received: from jelte (vhe-410064.sshn.net [195.169.215.155]) by sol.nlnetlabs.nl (Postfix) with ESMTP id D8DE7188028 for ; Mon, 20 Feb 2006 21:56:45 +0100 (CET) Received: from [192.168.8.10] (unknown [192.168.8.10]) by jelte (Postfix) with ESMTP id 5DAAA87F42 for ; Mon, 20 Feb 2006 21:49:51 +0100 (CET) Message-ID: <43FA2D0C.2000801@NLnetLabs.nl> Date: Mon, 20 Feb 2006 21:56:44 +0100 From: Jelte Jansen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051010) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-rsasha256-00.txt References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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 : Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC > > This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG > resource records for use in the Domain Name System Security > Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-00.txt I haven't seen any discussion about this yet, so let me just remind you here. We'd like to get the algorithm assignments and allow time for code to be deployed to use RSA/SHA-256 keys and sigs. Please let me know if there are any comments on this document. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD+i0M4nZCKsdOncURAl1wAKCWi896nD+pnO5D+OngZi+kyxy6UgCcDGP+ QK/xSC3mz8R8UrqTVaz/pKc= =Mtlv -----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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 20 17:31:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBJZ4-00077w-AC for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 17:31:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBJZ2-0008Vr-Qx for dnsext-archive@lists.ietf.org; Mon, 20 Feb 2006 17:31:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBJU3-000HDH-8y for namedroppers-data@psg.com; Mon, 20 Feb 2006 22:26:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBJU2-000HD6-9n for namedroppers@ops.ietf.org; Mon, 20 Feb 2006 22:26:18 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 31E30E601C for ; Mon, 20 Feb 2006 22:26:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k1KMQ1mY016045; Tue, 21 Feb 2006 09:26:03 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200602202226.k1KMQ1mY016045@drugs.dv.isc.org> To: Paul Vixie Cc: Peter Koch , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" In-reply-to: Your message of "Mon, 20 Feb 2006 18:00:20 -0000." <20060220180020.C17E611425@sa.vix.com> Date: Tue, 21 Feb 2006 09:26:01 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > # Also: the DO bit was introduced to protect "innocent" resolvers from > # DNSSEC RRs they might not expect or understand. > # > # Opinions? > > i think a security aware server should elide dnssec metadata unless DO is set > , > whereas we already know that a security-nonaware server will not do this and > will never do this. > > we can hope that a security non-aware server will never see dnssec metadata > but we know this isn't true either. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: I'd expect to see the records in the answer section as a client making a * query is expecting to see records it cannot decode. A RFC 1035 client cannot decode a RP record but no one here would say don't sent the RP. I would not expect to see the DNSSEC records in the additional and authority sections. Asking * to a parent server with a signed parent zone of a signed child zone gets more interesting. DS, NSEC and RRSIG should be in the answer section. There should be a referral containing the NS records. Again there would be not DNSSEC records in the authority or additional sections. Mark ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.2 <<>> dv.isc.org any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37013 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 7 ;; QUESTION SECTION: ;dv.isc.org. IN ANY ;; ANSWER SECTION: dv.isc.org. 3600 IN SOA bsdi.dv.isc.org. marka.isc.org. 2006021500 86400 21600 2419200 86400 dv.isc.org. 60 IN RRSIG DNSKEY 5 3 60 20060316195737 20060214195737 37083 dv.isc.org. WtxeB8M2lAkrXIpdn/X2F0d8Zlx0UOXEyBkdVN6w+mX9KhO2hWf8vZ5C JHPGFoNEXQ7NEBuVJbUcntNKWXQR7QMBTE7LV5vOcbZLoyRR4aI1vwjz mC/9X9ODdZ9UQt/kDOaqKmwtrMtepbRmkw7MXjSNbO4xhJ3AsbPOdNrj UzV0rHfR/XHe9eD+NbDPCGXYF/hSqfjDv8iFx12JLAX3u3ymZ9FYhb5v xAtQBQO1KtiH9i5mPY7AVOxhtppYY70YB5VoBNvCC1uwfmI4d2tFnfcv mzfj1M4f1C3PqscAlsWNCWMfzezX3xW53mkpDiQHE1d3AWrH6R+S8wq/ rtgZ3Q== dv.isc.org. 60 IN RRSIG DNSKEY 5 3 60 20060316195737 20060214195737 52595 dv.isc.org. n2Xn9e300LIJcVhXXi4ZTFEpYDZT6ZSdjQdlWwc5HBbPyRSO7tDIbP78 yayc6dKyX19Bj06k47kbdiXeaCNkEgyNhtpKHeaxCd7lCQGZLaXSAz4m 7XHneELIgylLSGNCM87AHSzRzISsVSpzlcpyDVVUz/TxdxAnHM/lHNYe 9WU= dv.isc.org. 60 IN DNSKEY 257 3 5 AQO/WTD1QT9aOKORz8l7lcWgghCH0E+cxr3cnm7v0oLA0NLMFa1NzZMt PVl6AGWu+jDo0y/y37lWUiNK9FLcmxzTvm2BgWHoZ3/aQcdxkR+SDIxB Ru3HlGGZcrk80lT77OBrYjiJmImQt9cLefG0TxzwYbWEX2AwYCMil/Gf Fia11Cu3HC2JER/Z7INIYiXgX42FWQtqYqSwl20TkH1NLGoWXDQZEcUM BG/dz+o9JTTalQkIcohhxdJ9Bd1Yceq+4hEdN25mMvL2us8nJXa8nqry TEZ2iAce2RxYjhEAuZ4Dg0u0hgCvhOkEyf/M3erv1RkdB1UPMLgh7xiY cw5K87yd dv.isc.org. 60 IN DNSKEY 256 3 5 AQPGP80zt8pQS5xVaaaD054XBet8sCKaYZ9WrnYyuznqNXkS91j6qqHu w7Y9kKAVsFoWfNw0CpahdIJIhUPFM1JRJtXhNy1cg9Ok3kBnN+fwCe2L Y3qOtweFbL9bSjgolQWr42AlFOjZnJVW1cECgVBfinKHBIEIIwIdHGGu LyIQaQ== dv.isc.org. 86400 IN RRSIG NSEC 5 3 86400 20060316195737 20060214195737 52595 dv.isc.org. SICQlRWLkkm246Hd6e1YgU5Qq32zJAtOUjWuw9wmq14Qx9FKdjYS1xHu gYZ0cNj7bgzH0zg5Ke5oJ7g+VTkbIzXVO1wLd3nBKiKmnIIuUM97AAAd DdSrqpg8txEZr3nad8xN48hUllntPjZRM9dRuEulFcTPARUk+t5tTwP5 kbM= dv.isc.org. 86400 IN NSEC _kerberos.dv.isc.org. NS SOA MX RRSIG NSEC DNSKEY dv.isc.org. 86400 IN RRSIG MX 5 3 86400 20060316195737 20060214195737 52595 dv.isc.org. logv6ZVCD/TCjSmu+UIy9Fdg/S4rtZvVtbKpJGLos8RnfONkHYH6bPbe 8u5GzTJlB+MiGw55vl9JdXslNxsOhSyal3pPg+beboWiEo7W6D0BlDgQ VXb48fpHiislIySd/Hu+0fzh9aXWLdOVP9R/XxOiO2cFEdxFUX2jbht+ NGw= dv.isc.org. 86400 IN MX 0 bsdi.dv.isc.org. dv.isc.org. 86400 IN RRSIG NS 5 3 86400 20060316195737 20060214195737 52595 dv.isc.org. qdPqO3dr2oPYD+baCWbJ7oQ8WBQVfeWjPvPy08tllITBz/0q+QS4W6Ec IbrzRV77hJfu6GoAcbiG55SqScmrFJQ46VIP5x2CHOGp4gupjSaCH7e+ RZojBdHPC6OwRnePmx4/z/X2bJkPquGT9sOvIFYesPKgaTklwrxR1tMK 4cA= dv.isc.org. 86400 IN NS drugs.dv.isc.org. dv.isc.org. 86400 IN NS bsdi1.dv.isc.org. dv.isc.org. 3600 IN RRSIG SOA 5 3 3600 20060316195737 20060214195737 52595 dv.isc.org. kyhBxS3oR8LApMHb/G5I7TYbRPqVaJYz2B3qcfUYo6Bpq/RKEvgtsuyJ iUboj0Fwdq7dru0EN0Go5fdrbx9ajBj6qALykH14h9jabjw1RI7nA28I OmLBUsMELWkgUkRLBXiujN912OQYHYRiEQ7E/oC72z3lJyAOa6pPlOs9 Zuk= ;; ADDITIONAL SECTION: bsdi.dv.isc.org. 3600 IN A 192.168.191.233 bsdi.dv.isc.org. 3600 IN A 220.237.98.197 bsdi1.dv.isc.org. 86400 IN A 192.168.191.233 drugs.dv.isc.org. 86400 IN A 192.168.191.236 bsdi.dv.isc.org. 86400 IN AAAA 2001:470:1f00:ffff::5a1 bsdi.dv.isc.org. 86400 IN AAAA 2001:470:1f00:820:2e0:29ff:fe19:c02d drugs.dv.isc.org. 86400 IN AAAA 2001:470:1f00:820:208:74ff:fe9f:eeae ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 21 09:15:29 2006 ;; MSG SIZE rcvd: 1890 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 03:12:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBScw-0005cK-Bv for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 03:12:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBScu-0007yd-Se for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 03:12:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBSZE-000M1x-63 for namedroppers-data@psg.com; Tue, 21 Feb 2006 08:08:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBSZD-000M1m-3B for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 08:08:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4B1A326C10C; Tue, 21 Feb 2006 09:08:13 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 1376626C0F6; Tue, 21 Feb 2006 09:08:12 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 1063958ED2B; Tue, 21 Feb 2006 09:08:12 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 096FD16AA06; Tue, 21 Feb 2006 09:08:12 +0100 (CET) Date: Tue, 21 Feb 2006 09:08:12 +0100 From: Stephane Bortzmeyer To: Wes Hardaker Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Message-ID: <20060221080812.GA13442@nic.fr> References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> <20060217133415.GA24796@nic.fr> <20060217144139.GA31819@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Mon, Feb 20, 2006 at 11:59:01AM -0800, Wes Hardaker wrote a message of 16 lines which said: > forgot this was in the IDN part of the discussion in my head as I > was tracing the thread.... Not at all, Simon mentioned IDN, but the real issue was LLMNR (how to report to the application that the resolution was made with LLMNR or DNS or LDAP because some applications may care). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 03:12:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBScz-0005cb-7k for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 03:12:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBScy-0007yj-Ut for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 03:12:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBSaw-000M6Y-Ga for namedroppers-data@psg.com; Tue, 21 Feb 2006 08:10:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBSav-000M60-SG for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 08:10:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 37C6E26C114; Tue, 21 Feb 2006 09:10:01 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E0E2026C0F6; Tue, 21 Feb 2006 09:09:59 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id DCAD658ED2B; Tue, 21 Feb 2006 09:09:59 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id CCFC016AA06; Tue, 21 Feb 2006 09:09:59 +0100 (CET) Date: Tue, 21 Feb 2006 09:09:59 +0100 From: Stephane Bortzmeyer To: Wes Hardaker Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Message-ID: <20060221080959.GB13442@nic.fr> References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> <20060217133415.GA24796@nic.fr> <20060217144139.GA31819@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Mon, Feb 20, 2006 at 11:35:44AM -0800, Wes Hardaker wrote a message of 20 lines which said: > a bunch of DNSSEC aware API calls that both allow you to match > existing APIs as much as possible as well as let you give greater > control over the policies the APIs are likely internally going to > have to implement. It is DNSSEC-specific? Because I believe that some people would want to have other information as well, such as wether getaddrinfo() was actually done with LLMNR or DNS or /etc/hosts (the starting point of a rather silly flame during the last call). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 05:34:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBUqe-0005tF-Ux for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 05:34:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBUqd-0004dP-09 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 05:34:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBUmw-0004lK-Mz for namedroppers-data@psg.com; Tue, 21 Feb 2006 10:30:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBUmu-0004l6-Qu for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 10:30:32 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id k1LAUITn015565; Tue, 21 Feb 2006 02:30:19 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id k1LAUMZs029625; Tue, 21 Feb 2006 12:30:22 +0200 (EET) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id k1LAUMKR002558; Tue, 21 Feb 2006 12:30:22 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.60350.155682.749025@guava.araneus.fi> Date: Tue, 21 Feb 2006 12:30:22 +0200 To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" In-Reply-To: <20060220174106.GD994@unknown.office.denic.de> References: <20060220174106.GD994@unknown.office.denic.de> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Peter Koch wrote: > during a discussion at a different venue the question arose whether or not > the "DNSSEC RRs" should be included in a response to an ANY query with DO=0. My take is that they should be included. > con: [...] > If the DO bit in an initiating query is not set, the name server side > MUST strip any authenticating DNSSEC RRs from the response but MUST > NOT strip any DNSSEC RR types that the initiating query explicitly > requested. > > The important part is the last full sentence. IMO, an ANY query should be considered "explicitly requesting" all records at the query name. Also, these DNSSEC RRs are not "authenticating" DNSSEC RRs in the sense that they do not authenticate the response, but are simply part of the unauthenticated response data comprising the complete set of records at the query name. > Also: the DO bit was introduced to protect "innocent" resolvers from > DNSSEC RRs they might not expect or understand. As Mark said, a client sending an ANY query must expect to receive records of arbitrary types in the answer section even without DNSSEC. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 10:38:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZae-0004yl-C8 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 10:38:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBZae-0000Le-2M for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 10:38:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBZX9-000PCD-Jz for namedroppers-data@psg.com; Tue, 21 Feb 2006 15:34:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBZX8-000PBx-QX for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 15:34:34 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 21 Feb 2006 10:34:33 -0500 id 002D00DC.43FB3309.00004ED4 In-Reply-To: <20060220174106.GD994@unknown.office.denic.de> References: <20060220174106.GD994@unknown.office.denic.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75974279-C35D-4A65-B26A-E265773E230E@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" Date: Tue, 21 Feb 2006 10:34:31 -0500 To: Peter Koch X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac On Feb 20, 2006, at 12:41 PM, Peter Koch wrote: > Colleagues, > > during a discussion at a different venue the question arose whether > or not > the "DNSSEC RRs" should be included in a response to an ANY query > with DO=0. > > pro: > > section 3 of RFC 4035 (top of page 9) says: > > A security-aware name server that receives a DNS query that > does not > include the EDNS OPT pseudo-RR or that has the DO bit clear MUST > treat the RRSIG, DNSKEY, and NSEC RRs as it would any other > RRset and > MUST NOT perform any of the additional processing described > below. > > "treat ... as it would any other RRset" would support ANY > covering those, > which is consistent with RFC 3225 (which explicitly listed ANY). > > Also, this would be consistent with RFC 3597, not requiring special > handling for "unknown" types. > > con: > > RFC 4035, 3.2 says: > > 3.2.1. The DO Bit > > The resolver side of a security-aware recursive name server > MUST set > the DO bit when sending requests, regardless of the state of > the DO > bit in the initiating request received by the name server > side. If > the DO bit in an initiating query is not set, the name server > side > MUST strip any authenticating DNSSEC RRs from the response but > MUST > NOT strip any DNSSEC RR types that the initiating query > explicitly > requested. > > The important part is the last full sentence. > > Also: the DO bit was introduced to protect "innocent" resolvers from > DNSSEC RRs they might not expect or understand. > > Opinions? My reading is that the DNSSEC types are included in the ANY response. In my reading, section 3.2.1 doesn't conflict with the earlier section. In this case, the DNSSEC types at the qname were "explicitly requested", and thus fall under the "MUST NOT strip" clause in that last full sentence. However, I will readily admit that qtype=ANY and the adverb "explictly" don't go together terribly well. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 10:39:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZbj-00058e-4K for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 10:39:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBZbh-0000R0-RW for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 10:39:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBZa6-000PPZ-8Z for namedroppers-data@psg.com; Tue, 21 Feb 2006 15:37:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBZa5-000PPL-Bn for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 15:37:37 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id A141E11D531; Tue, 21 Feb 2006 07:37:34 -0800 (PST) From: Wes Hardaker To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR consensus statement Organization: Sparta References: <6.2.5.6.2.20060216182017.03b05ef8@ogud.com> <20060217133415.GA24796@nic.fr> <20060217144139.GA31819@nic.fr> <20060221080959.GB13442@nic.fr> Date: Tue, 21 Feb 2006 07:37:34 -0800 In-Reply-To: <20060221080959.GB13442@nic.fr> (Stephane Bortzmeyer's message of "Tue, 21 Feb 2006 09:09:59 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >>>>> On Tue, 21 Feb 2006 09:09:59 +0100, Stephane Bortzmeyer said: >> a bunch of DNSSEC aware API calls that both allow you to match >> existing APIs as much as possible as well as let you give greater >> control over the policies the APIs are likely internally going to >> have to implement. Stephane> It is DNSSEC-specific? Because I believe that some people Stephane> would want to have other information as well, such as wether Stephane> getaddrinfo() was actually done with LLMNR or DNS or Stephane> /etc/hosts (the starting point of a rather silly flame Stephane> during the last call). We (and by "we" I mean my co-workers who did all the work not me) wrote it primarily to solve some of our dnssec specific issues with existing APIs. However, certainly it makes sense to make sure that anything new that is defined can handle all the problems at once! We'd certainly be interested in review for other issues too. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 11:56:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBaos-0002q2-EE for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 11:56:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBaor-0005OH-5A for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 11:56:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBamG-0005Uu-R3 for namedroppers-data@psg.com; Tue, 21 Feb 2006 16:54:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBamG-0005Uh-1q for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 16:54:16 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k1LGreOR016167 for ; Tue, 21 Feb 2006 11:53:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAriaaKF; Tue, 21 Feb 06 11:53:37 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k1LGpxqb015122 for ; Tue, 21 Feb 2006 11:51:59 -0500 (EST) Date: Tue, 21 Feb 2006 11:54:11 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" In-Reply-To: <20060220180020.C17E611425@sa.vix.com> Message-ID: References: <20060220174106.GD994@unknown.office.denic.de> <20060220180020.C17E611425@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Mon, 20 Feb 2006, Paul Vixie wrote: > i think a security aware server should elide dnssec metadata unless > DO is set, whereas we already know that a security-nonaware server > will not do this and will never do this. > > we can hope that a security non-aware server will never see dnssec > metadata but we know this isn't true either. Following the same logic, should modern name servers strip out other new record types, in hopes of protecting innocent (and broken) resolvers? As Mark points out, the general answer is "no" -- we're willing to let a resolver that asks for ANY get unknown RR types and, if it can't cope with the answer, we're willing to let it break. I don't see any need to treat the DNSSEC records differently. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 12:55:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbjZ-0006tw-0M for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 12:55:33 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBbjX-0006oe-Mw for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 12:55:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBbge-0009yr-Tx for namedroppers-data@psg.com; Tue, 21 Feb 2006 17:52:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBbg8-0009x4-QE for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 17:52:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3969511427 for ; Tue, 21 Feb 2006 17:52:00 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" In-Reply-To: Your message of "Tue, 21 Feb 2006 11:54:11 EST." References: <20060220174106.GD994@unknown.office.denic.de> <20060220180020.C17E611425@sa.vix.com> Date: Tue, 21 Feb 2006 17:52:00 +0000 Message-Id: <20060221175200.3969511427@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a # > i think a security aware server should elide dnssec metadata unless DO # > is set, whereas we already know that a security-nonaware server will not # > do this and will never do this. # > # > we can hope that a security non-aware server will never see dnssec # > metadata but we know this isn't true either. # # Following the same logic, should modern name servers strip out other new # record types, in hopes of protecting innocent (and broken) resolvers? no. i was mistaken, but not about that. i thought there was a way to signal dnssec awareness that wasn't DO=1. if there were, then i'd say any requestor who could signal dnssec awareness and also signal that dnssec metadata wasn't wanted, shouldn't get it, even on qtype=ANY. # As Mark points out, the general answer is "no" -- we're willing to let a # resolver that asks for ANY get unknown RR types and, if it can't cope with # the answer, we're willing to let it break. I don't see any need to treat # the DNSSEC records differently. i wasn't worried about seeing something that wasn't understood, i was looking to optimize message size and avoid truncation/fragmentation/tcp. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 13:04:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbs8-0007Jo-Ld for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:04:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBbs7-00070Y-74 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:04:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBbpb-000ArT-FW for namedroppers-data@psg.com; Tue, 21 Feb 2006 18:01:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBbpa-000Ar3-Ek for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:01:46 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 21 Feb 2006 18:01:45 +0000 X-IronPort-AV: i="4.02,135,1139184000"; d="scan'208"; a="2873688:sNHT22539016" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k1LI1iUx009597; Tue, 21 Feb 2006 18:01:44 GMT Date: Tue, 21 Feb 2006 18:01:44 GMT From: Geoffrey Sisson Message-Id: <200602211801.k1LI1iUx009597@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: NSEC3 Issues Cc: nsec3-testing@nsec3.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f We have created an issues list to track NSEC3 issues. The open issues will be sent to namedroppers shortly. Any review by and feedback from the WG participants would be immensely appreciated. The upcoming -04 version of the NSEC3 draft is available at: http://www.nsec3.org/draft-ietf-dnsext-nsec3-04pre1.txt These issues will also be added to the issues tracker at: http://www.nsec3.org/ Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 13:22:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcA5-0000Mn-B8 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:22:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcA4-0007xM-SC for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:22:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBc8E-000Cbf-2w for namedroppers-data@psg.com; Tue, 21 Feb 2006 18:21:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBc8C-000CbO-MU for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:21:00 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 21 Feb 2006 18:20:59 +0000 X-IronPort-AV: i="4.02,135,1139184000"; d="scan'208"; a="2873737:sNHT32313680" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k1LIKwWn009633 for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:20:58 GMT Date: Tue, 21 Feb 2006 18:20:58 GMT From: Geoffrey Sisson Message-Id: <200602211820.k1LIKwWn009633@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: NSEC3 Resolved Issues Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c These are NSEC3 issues that we consider to be resolved. Geoff ----------------------------------------------------------------------- NSEC3 Issue 1: Use of Hashes Creates New Owner Names Issue: A signed zone which uses NSEC3 introduces new owner names which are Base32-encoded hashes of existing owner names in the zone. Resolution: We do not see that, in and of itself, there is any problem with this. It is possible for an NSEC3 RR may have the same owner name as a real owner name; the consequences of this are considered in Issue 12. ----------------------------------------------------------------------- NSEC3 Issue 2: RFC 3548 Base32 Sort Order Issue: RFC 3548 describes a Base32 encoding that is unsuitable for NSEC3 hashes, as the sort order of the encodings differ from binary sort order. This issue was raised in this post to namedroppers: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01423.html Subsequent to this post, the author of RFC 3548 submitted a new draft: http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-00.txt This draft adds a new encoding called "base 32 extended hex alphabet" which preserves the sort order of encoded data, and describes the encoding used in -nsec-03. This is the same encoding used in Section 3.1 of RFC 2938. Resolution: If rfc3548bis is published, the nsec3 draft will be changed to reference this encoding scheme; otherwise the draft will reference the one used in RFC 2938. ----------------------------------------------------------------------- NSEC3 Issue 3: Determination of Correct Zone Parameters Issue: A name server has to be able to look up the NSEC3 RR associated with an owner name. To do this, it must have the correct values for the salt and number of iterations required to produce the hash value which is the owner name of the NSEC3 RR. However, an NSEC3 zone may contain any number of incomplete chains of NSEC3 RRs provided that at least one is complete. Consequently it cannot use the values contained in any arbitrary NSEC3 RR in the zone. So how does a name server determine the correct values for the zone? Discussion: One method for setting the correct values would be to provide them externally, e.g. via the name server's configuration file or out-of-band signaling. However this is not a practical option for secondary servers, which will not have access to information in the primary server's configuration file, and may additionally be running different DNS implementations with no provision for out-of-band signaling. Another method for determining the correct values would be for the name server to examine each NSEC3 RR with a unique combination of values for salt and iterations, and to then enumerate any chains which might be associated with those values to determine whether they form a complete NSEC3 chain. This would of course be impractical for all but the smallest of zones. A third method would be to require that an NSEC3 RR for the host name of the apex exist only if an (otherwise) complete chain of NSEC3 RRs with the same parameters exists. This way, a name server may obtain the correct values from any NSEC3 RRs that has the SOA bit set in the Bit Type field. If more than one NSEC3 RR exists with the SOA bit set, the values of any of them may be used, as each one would indicate the existence of a complete NSEC3 chain. Resolution: The use of the third method will be specified in -04. ----------------------------------------------------------------------- NSEC3 Issue 4: Design Rationale Issue: The draft needs to include more information about rationale underlying various design decisions, for example: - Why use a salt? - Why use iterations? Resolution: An expanded design rationale will be included in -04. ----------------------------------------------------------------------- NSEC3 Issue 5: Hash Function RDATA Too Short Issue: The hash function field of the RDATA section of the NSEC3 RR is seven bits long; however RFC 4034 specifies that DNSSEC security algorithms are identified by 8-bit numbers (Appendix A, Section 1). Resolution: This will be corrected in -04. ----------------------------------------------------------------------- NSEC3 Issue 6: Owner names of hashes are limited to case-folded names Issue: The owner names of NSEC3 RRs are currently restricted to case-folded names as non-case folded names will not be ordered properly in a zone. Base32 has been selected for this encoding. As a consequence, NSEC3 RRs require a 32 octet owner name to represent each hash, 12 more than the binary representation of the hash. If NSEC3 were to be subsequently modified to use SHA-256, then each owner name would require 20 more octets than the binary representation. Some have suggested that NSEC3 could use a new binary label type for owner names rather than Base32-encoded labels; this would marginally reduce the size of DNSSEC responses for zones using NSEC3. It would also marginally increase the total length domain names which could be permitted in an NSEC3 zone. [ Impact on truncation? ] Discussion: This would be a significant departure from previous IETF conservatism, e.g. the selection of ASCII encoding for IDNs. It would also introduce additional complexity to implementors, requiring broad, non-trivial code base changes to existing implementations. Also significantly more middleboxes might fail to properly handle the introduction of a new label type than a new type code. Resolution: Base32-encoded labels will be used. ----------------------------------------------------------------------- NSEC3 Issue 7: Maximum Domain Name Length Issue: The owner name of the apex of an NSEC3 zone is limited to 222 octets, as the NSEC3 hash for the apex (and any other owner names in the zone) is constrained to 255 octets. In practise vanishingly few domain names approach this length. Zones that require such long names will be constrained to using NSEC RRs. Resolution: It's unlikely many domain names will be affected by this limitation. Those that are are probably pathological cases. If DNSSEC is to be used for any domain names of > 222 octets then NSEC rather than NSEC3 will have to be used. (Note that for any zone which uses NSEC3, it may be desirable to limit overall domain length to 202 octets, as longer names could not be used in an NSEC3 zone using SHA-256 hashes.) ----------------------------------------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 13:27:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcEP-0000Y7-GT for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:27:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcEO-0008FB-24 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:27:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcCW-000CzU-A1 for namedroppers-data@psg.com; Tue, 21 Feb 2006 18:25:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcCV-000Cy6-8G for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:25:27 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 21 Feb 2006 18:25:26 +0000 X-IronPort-AV: i="4.02,135,1139184000"; d="scan'208"; a="2873747:sNHT30605648" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k1LIPQuT009658 for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:25:26 GMT Date: Tue, 21 Feb 2006 18:25:26 GMT From: Geoffrey Sisson Message-Id: <200602211825.k1LIPQuT009658@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 8: NSEC3 Signaling Mechanism Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Issue: Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow signal this to NSEC3-unaware DNSSEC applications? Example: if an NSEC3-unaware validating resolver queries for a non-existent RRset in an NSEC3 zone, the response will contain one or more NSEC3 RRs in place of the expected NSEC RR(s). In RFC 4035, omission of NSEC RRs in a No Data/Name Error response is a protocol violation [Section 3.1.3]; consequently, the resolver will mark it bogus. Discussion: Several approaches have been considered for handling this: 1. Use a full type code rollover (a.k.a. `DNSSECter') - Fully independent DNSSEC scheme (third one, if RFC 2535 is considered). - Four new RRs: DNSKEY -> DNSKEY2 RRSIG -> RRSIG2 NSEC -> NSEC3 DS -> DS2 - All RR formats identical except for NSEC vs NSEC3 - NSEC3-unaware validators see only DNSSECbis RRs. In NSEC3 zones only new RRs are used. Either or both validation schemes may be used independently without reference to one another. However: - A validating resolver must have special (non-RFC 4033-35) rules for recognising and processing DS2 RRs in DNSSECbis zones, e.g. when a DNSSECter-only zone has a DNSSSECbis-only parent. Otherwise the DS2 RR will not be identified as part of any validation chain. So while a type-code rollover may at first glance appear to be an elegant solution, it only works if one or another set of type codes is used exclusive DNSSECbis zone. - If the KSK of the NSEC3 is a trust anchor, care must be taken not to use it in the `trusted-keys' store of a non-NSEC3-aware validating resolver. 3. Use a new DS message digest number - Use the DS message digest field for signaling both: a. that NSEC3 is in use in the child zone, and b. which hash algorithm is in use by the NSEC3 RRs in the child zone. - Proposed in this post to namedroppers: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html However: - Only works if all subsequent children are NSEC3. If the chain of trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will appear bogus. 4. Use an unknown algorithm identifier - Described in draft-ietf-dnsext-dnssec-experiments-01.txt - Use algorithm identifiers in RRSIG and DS RRs that would not be recognised by NSEC3-unaware validating resolver, so that No Data/Name Error responses would appear insecure rather than bogus. However: - Would require the use of multiple algorithm identifiers for the same algorithm, at least until NSEC3 was folded into a revised version of DNSSECbis. This would mean SHA-1 (and probably SHA-256) would have two identifiers each. This is mitigated by the fact that: - the algorithm identifier is an 8-bit number out of which only 10 assignments have been made: http://www.iana.org/assignments/dns-sec-alg-numbers - The rate of new assignments is expected to be low. 5. Do nothing No Data/Name Error responses for queries that have NSEC3 somewhere in the validation chain will be marked bogus. - If DNSSEC deployment is sufficiently minimal before NSEC3 (or other NSEC++) is available, this may have a negligible impact. However: - DNS operators considering the deployment of DNSSEC might choose to wait until NSEC3 is available, or, conversely, - DNSSEC deployment might become sufficiently advanced that operators will be unwilling to deploy NSEC3. Proposed Resolution: Approach #4 appears to be the most promising. Thorough testing will be required to determine whether any non-obvious issues exist, though it's been shown to work in previous testing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 13:28:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcFA-0000eb-7s for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:28:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcF9-0008OO-Up for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:28:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcDf-000D5Q-J2 for namedroppers-data@psg.com; Tue, 21 Feb 2006 18:26:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcDe-000D52-NJ for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:26:38 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 21 Feb 2006 18:26:37 +0000 X-IronPort-AV: i="4.02,135,1139184000"; d="scan'208"; a="2873748:sNHT27483276" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k1LIQa8A009663 for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:26:36 GMT Date: Tue, 21 Feb 2006 18:26:36 GMT From: Geoffrey Sisson Message-Id: <200602211826.k1LIQa8A009663@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 9: Potential DoS on Resolvers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 NSEC3 Issue 9: Potential DoS on Resolvers Issue: A potential DoS condition exists in which the operator of a malicious server could select an impractically high number of iterations for the NSEC3 RRs in an signed zone. The NSEC3 RDATA format permits values as high as 2 ^ 23, or 8,388,608 (N.B. this is a change in -04; in -03 it was 2 ^ 24). Consequently, when a resolver receives multiple queries for names (existent or non-existent) in this zone, the resolver must perform the same number of hash iterations for each query. This could result in a significant denial-of-service on the resolver. Discussion: One solution would be to permit resolvers to set an upper limit for the number of iterations that would be permitted in an NSEC3 RR, and to treat NSEC3 RRs with values exceeding this as insecure or bogus. This could be accomplished at the implementation level alone, or it could be governed by a recommendation or standard. One subsidiary issue is that any limit may have to change over time in response to increases in computational speed: a limit which may initially reflect an unjustifiably high number of iterations may later be considered cryptographically weak. Proposed Resolution: We agree that it is desirable for resolvers to set an upper limit. We propose to submit the following two questions for consideration by the IETF Security Area Directorate: 1. Should an upper limit be specified in the standard? 2. If so, should the upper limit be specified in a separate document so that the it may be updated without having to re-publish the entire standard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 13:28:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcFW-0000fw-Gu for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:28:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcFW-0008Qq-80 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:28:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcEH-000D8m-9r for namedroppers-data@psg.com; Tue, 21 Feb 2006 18:27:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcEG-000D8P-On for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:27:16 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 21 Feb 2006 18:27:16 +0000 X-IronPort-AV: i="4.02,135,1139184000"; d="scan'208"; a="2873749:sNHT26412912" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k1LIRFB2009668 for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:27:15 GMT Date: Tue, 21 Feb 2006 18:27:15 GMT From: Geoffrey Sisson Message-Id: <200602211827.k1LIRFB2009668@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 10: Potential DoS on Servers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Issue: Significantly more work is required for a name server to respond to queries which require negative proofs using NSEC3 than is required for a client to compose and send them. For each such query, the name server must repeat the hash function for the number of iterations specified in the NSEC3 RRs. Consequently, name servers with NSEC3 zones are susceptible to asymmetric DoS attacks. Resolution: None at present. If name servers serving NSEC3 zones were to have suitable hardware acceleration for SHA-1, it's possible that the rate of queries required to degrade server function could be made to be higher than that required to saturate the server's network connection(s). Also, while not optimal, implementations could provide a reduced quality of service for queries which require negative proofs, so that resolution and validation of existing names will not be compromised. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 13:31:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcHv-00012m-6C for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:31:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcHu-0000F7-Pn for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 13:31:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcG9-000DLy-Qj for namedroppers-data@psg.com; Tue, 21 Feb 2006 18:29:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,OPTING_OUT_CAPS autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcG9-000DLb-4g for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:29:13 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 21 Feb 2006 18:29:12 +0000 X-IronPort-AV: i="4.02,135,1139184000"; d="scan'208"; a="2873759:sNHT27723344" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k1LITCpJ009672 for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 18:29:12 GMT Date: Tue, 21 Feb 2006 18:29:12 GMT From: Geoffrey Sisson Message-Id: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 13: DDNS and Opt-In Determination Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Issue: When a DDNS client sends an UPDATE transaction containing RRs for a new unsigned delegation to be inserted into an NSEC3 zone, there is no obvious way for the server to determine whether or not the new delegation should be included in the NSEC3 chain. This is because the values of the Opt-In fields of NSEC3 RRs in the zone need not be uniform. In other words, it's permissible to include and exclude unsigned delegations in the NSEC3 chain in any combination. Discussion: Possible approaches: 1. No support for Opt-In in DDNS - All NSEC3 RRs produced as a result an UPDATE will default to Opt-In = 0 - Cannot change value of NSEC RR. 2. Use overloaded NSEC3 RR to signal Opt-In - New unsigned delegations will default to Opt-In = 0, i.e. they will be included in the NSEC3 chain. An unsigned delegation may be removed from the NSEC3 chain by sending an UPDATE containing an NSEC3 RR with the /unhashed/ owner name of the delegation and the Opt-In flag set to 1. If the NSEC3 RR is included in the same atomic update as the RRs of the new unsigned delegation, the new delegation will not be inserted into the NSEC3 chain in the first place. - This method is in effect an overloading of the NSEC3 RR. The owner name of the NSEC3 RR in the UPDATE is be the owner name of the delegation, not the hashed value. Only the value of the Opt-In field is meaningful; the other data in the RDATA section is ignored. - UPDATEs containinr than on RRs exist, the server will return an error. However: - Convoluted use of NSEC3 RR. - NSEC3 RR is larger than required, as only one bit of the 16 octet RDATA section will be meaningful in a DDNS context. - Has unresolved corner cases, e.g. what if an UPDATE removes an unsigned delegation which is at the boundary of two spans, one with Opt-In = 0 and the other with Opt-In = 1? 3. Introduce a new RRTYPE for used with DDNS updates - Similar to previous, but uses a new RRTYPE, e.g. `OPTOUT', rather than overloading the NSEC3 RR. - RR more compact as only one octet will be required for RDATA section. However: - requires use of a dedicated RRTYPE which would be meaningful only in the context of DDNS updates. - Has corner cases such as the one described in Approach 2. 4. Inherited behaviour - If an update containing a new unsigned delegation falls in a span with Opt-In = 1, then it's not added to the NSEC3 chain; if falls on one one which is Opt-In = 0, it is added. However: - Mismatch between granularity of control permitted by - Has corner cases such as the one described in Approach 2. 5. Discourage or prohibit partial Opt-In zones. - Opt-In = 0 or Opt-In = 1 for all NSEC3 RRs in a chain. - Use cases unknown for partial Opt-In zones. However: - Adds unnecessary restrictions to the protocol. Resolution: None. We are still investigating the problem space. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 14:14:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcxc-0003X4-QQ for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 14:14:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcxb-0003Iw-E4 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 14:14:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcuu-000HJi-HK for namedroppers-data@psg.com; Tue, 21 Feb 2006 19:11:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBcut-000HJS-Pn for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 19:11:19 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id F186FC2DA4; Tue, 21 Feb 2006 19:11:20 +0000 (GMT) Date: Tue, 21 Feb 2006 19:11:14 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Geoffrey Sisson , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers Message-ID: In-Reply-To: <200602211826.k1LIQa8A009663@staff.nominet.org.uk> References: <200602211826.k1LIQa8A009663@staff.nominet.org.uk> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 --On 21 February 2006 18:26 +0000 Geoffrey Sisson wrote: > A potential DoS condition exists in which the operator of a malicious > server could select an impractically high number of iterations for the > NSEC3 RRs in an signed zone. The NSEC3 RDATA format permits values as > high as 2 ^ 23, or 8,388,608 (N.B. this is a change in -04; in -03 it > was 2 ^ 24). Consequently, when a resolver receives multiple queries > for names (existent or non-existent) in this zone, the resolver must > perform the same number of hash iterations for each query. This could > result in a significant denial-of-service on the resolver. Hmmm... Off the wall idea for today: Suppose that rather than using just some local resolver config knob, you looked at the parent zones number of hash iterations, and did not allow a number of hash iterations which exceeded both some function of that AND the config knob. Then, when as and when the root goes NSEC3, increasing computation power could be reflected in an increase in the root hash iterations, TLD iterations, etc. etc. You'd still have your local config knob for delegations which went (say) NSEC3->NSEC->NSEC3. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 15:19:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdyq-0006Yz-Fw for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 15:19:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBdyn-0005xl-T2 for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 15:19:28 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBduf-000LxT-LW for namedroppers-data@psg.com; Tue, 21 Feb 2006 20:15:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBdub-000Lwb-5N for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 20:15:07 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E108F4040; Tue, 21 Feb 2006 21:14:59 +0100 (CET) Date: Tue, 21 Feb 2006 21:14:59 +0100 From: bert hubert To: geoff@nominet.org.uk Cc: namedroppers@ops.ietf.org Subject: NSEC3 issue: DNSSEC is too complex by half already Message-ID: <20060221201459.GA22671@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Geoff, Partially in jest, but please consider adding this issue: DNSSEC is too complex by half already ------------------------------------- DNS is not a simple protocol. DNSSEC adds a degree of authentication and integrity to DNS but at a vast cost: attempting to maintain the DNS packet format and benefits of existing infrastructure has made the DNSSEC design a triumph of cleverness and complexity. NSEC3, introduced to add a modicum of privacy to zones, adds a further 42 pages of specifications. NSEC3 might very well break the camel's back - insofar as it was intact up to now. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 15:51:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBeU2-0004AR-RI for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 15:51:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBeU2-00082a-FE for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 15:51:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBeSS-000Ojt-VA for namedroppers-data@psg.com; Tue, 21 Feb 2006 20:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBeSR-000Oih-PL for namedroppers@ops.ietf.org; Tue, 21 Feb 2006 20:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1LKo20e001432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FBeSQ-0000Gw-1i; Tue, 21 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt Message-Id: Date: Tue, 21 Feb 2006 15:50:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 : Requirements related to DNSSEC Trust Anchor Rollover Author(s) : S. Crocker, et al. Filename : draft-ietf-dnsext-rollover-requirements-00.txt Pages : Date : 2006-2-21 Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rollover-requirements-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-rollover-requirements-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: <2006-2-21143639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rollover-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rollover-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-21143639.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 21 21:38:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBju4-0003JS-EZ for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 21:38:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBju2-0002A4-UY for dnsext-archive@lists.ietf.org; Tue, 21 Feb 2006 21:38:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBjq0-000MQl-3n for namedroppers-data@psg.com; Wed, 22 Feb 2006 02:34:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBjpx-000MQV-Qk for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 02:34:41 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id D9745E60AF for ; Wed, 22 Feb 2006 02:34:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k1M2YKq5084275; Wed, 22 Feb 2006 13:34:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200602220234.k1M2YKq5084275@drugs.dv.isc.org> To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: NSEC3 Issue 8: NSEC3 Signaling Mechanism In-reply-to: Your message of "Tue, 21 Feb 2006 18:25:26 GMT." <200602211825.k1LIPQuT009658@staff.nominet.org.uk> Date: Wed, 22 Feb 2006 13:34:20 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 > Issue: > > Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow > signal this to NSEC3-unaware DNSSEC applications? > > Example: if an NSEC3-unaware validating resolver queries for a > non-existent RRset in an NSEC3 zone, the response will contain one or > more NSEC3 RRs in place of the expected NSEC RR(s). In RFC 4035, > omission of NSEC RRs in a No Data/Name Error response is a protocol > violation [Section 3.1.3]; consequently, the resolver will mark it > bogus. > > > Discussion: > > Several approaches have been considered for handling this: [snip] > 3. Use a new DS message digest number > > - Use the DS message digest field for signaling both: > > a. that NSEC3 is in use in the child zone, and > > b. which hash algorithm is in use by the NSEC3 RRs in the > child zone. > > - Proposed in this post to namedroppers: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html > > However: > > - Only works if all subsequent children are NSEC3. If the chain of > trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will > appear bogus. Incorrect. A correctly functioning RFC 4035 validator will treat the child (NSEC3) zone as insecure. Any children of a insecure zone are insecure. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 05:14:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBr1K-0000bY-RJ for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 05:14:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBr1K-0003V3-8C for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 05:14:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBqxP-000N5d-3U for namedroppers-data@psg.com; Wed, 22 Feb 2006 10:10:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBqxM-000N5L-MB for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 10:10:48 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 22 Feb 2006 10:10:47 +0000 X-IronPort-AV: i="4.02,136,1139184000"; d="scan'208"; a="2487691:sNHT26742036" In-Reply-To: <200602220234.k1M2YKq5084275@drugs.dv.isc.org> To: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 8: NSEC3 Signaling Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 22 Feb 2006 10:09:45 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 02/22/2006 10:09:46 AM, Serialize complete at 02/22/2006 10:09:46 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 > > Issue: > > > > Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow > > signal this to NSEC3-unaware DNSSEC applications? > > > > Example: if an NSEC3-unaware validating resolver queries for a > > non-existent RRset in an NSEC3 zone, the response will contain one or > > more NSEC3 RRs in place of the expected NSEC RR(s). In RFC 4035, > > omission of NSEC RRs in a No Data/Name Error response is a protocol > > violation [Section 3.1.3]; consequently, the resolver will mark it > > bogus. > > > > > > Discussion: > > > > Several approaches have been considered for handling this: > > [snip] > > > 3. Use a new DS message digest number > > > > - Use the DS message digest field for signaling both: > > > > a. that NSEC3 is in use in the child zone, and > > > > b. which hash algorithm is in use by the NSEC3 RRs in the > > child zone. > > > > - Proposed in this post to namedroppers: > > > > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html > > > > However: > > > > - Only works if all subsequent children are NSEC3. If the chain of > > trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will > > appear bogus. > > Incorrect. A correctly functioning RFC 4035 validator will > treat the child (NSEC3) zone as insecure. RFC 4035 does handle unknown algorithm but not unknown digest types (though digests could be seen as a subset of algorithms). This is described in bis-updates. So, when a server responsible for an NSEC zone passes a delegation that contains a DS with unknown digest, to indicate the delegated child is NSEC3, a 4035 compliant resolver may fail to handle it as insecure, and might handle it as bogus. > Any children of > a insecure zone are insecure. Yes. Any children of a bogus zone will never be seen, which is a lot worse. Furthermore, if your trust anchor is a sep to a NSEC3 zone, there is no DS to signal that a zone is NSEC3. An rfc4035 compliant validator could be configured as such, hence there is yet another way to shoot oneself in the foot. If the 'signal' is embedded in the signing algorithm (as suggested in (4)), these points are resolved. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 05:38:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBrOZ-0001fw-7K for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 05:38:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBrOY-0004SV-QJ for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 05:38:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBrMr-000P6p-T1 for namedroppers-data@psg.com; Wed, 22 Feb 2006 10:37:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBrMr-000P6c-8S for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 10:37:09 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id D219DE60AE for ; Wed, 22 Feb 2006 10:37:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k1MAanAi096358; Wed, 22 Feb 2006 21:36:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200602221036.k1MAanAi096358@drugs.dv.isc.org> To: Roy Arends Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: NSEC3 Issue 8: NSEC3 Signaling Mechanism In-reply-to: Your message of "Wed, 22 Feb 2006 10:09:45 -0000." Date: Wed, 22 Feb 2006 21:36:49 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 > > > Issue: > > > > > > Should a name server for a DNSSEC zone that uses NSEC3 RRs only > somehow > > > signal this to NSEC3-unaware DNSSEC applications? > > > > > > Example: if an NSEC3-unaware validating resolver queries for a > > > non-existent RRset in an NSEC3 zone, the response will contain one or > > > more NSEC3 RRs in place of the expected NSEC RR(s). In RFC 4035, > > > omission of NSEC RRs in a No Data/Name Error response is a protocol > > > violation [Section 3.1.3]; consequently, the resolver will mark it > > > bogus. > > > > > > > > > Discussion: > > > > > > Several approaches have been considered for handling this: > > > > [snip] > > > > > 3. Use a new DS message digest number > > > > > > - Use the DS message digest field for signaling both: > > > > > > a. that NSEC3 is in use in the child zone, and > > > > > > b. which hash algorithm is in use by the NSEC3 RRs in the > > > child zone. > > > > > > - Proposed in this post to namedroppers: > > > > > > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html > > > > > > However: > > > > > > - Only works if all subsequent children are NSEC3. If the chain > of > > > trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will > > > appear bogus. > > > > Incorrect. A correctly functioning RFC 4035 validator will > > treat the child (NSEC3) zone as insecure. > > RFC 4035 does handle unknown algorithm but not unknown digest types > (though digests could be seen as a subset of algorithms). This is > described in bis-updates. > > So, when a server responsible for an NSEC zone passes a delegation that > contains a DS with unknown digest, to indicate the delegated child is > NSEC3, a 4035 compliant resolver may fail to handle it as insecure, and > might handle it as bogus. In anycase NSEC -> NSEC3 -> NSEC will work with the digest fields as easily as with the algorithm field. The however is incorrect. > > Any children of > > a insecure zone are insecure. > > Yes. Any children of a bogus zone will never be seen, which is a lot > worse. > > Furthermore, if your trust anchor is a sep to a NSEC3 zone, there is no DS > to signal that a zone is NSEC3. An rfc4035 compliant validator could be > configured as such, hence there is yet another way to shoot oneself in the > foot. If the 'signal' is embedded in the signing algorithm (as suggested > in (4)), these points are resolved. > > Roy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 07:08:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBsnH-0006xX-Qn for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 07:08:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBsnG-00070Z-Do for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 07:08:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBsko-00050y-Ey for namedroppers-data@psg.com; Wed, 22 Feb 2006 12:05:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FBskn-00050n-K0 for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 12:05:57 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0012EB; 22 Feb 2006 07:07:23 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 22 Feb 2006 07:07:06 -0500 Received: from connotech.com (209.71.204.101) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0012EA; 22 Feb 2006 07:07:04 -0500 Message-ID: <43FC5C54.7090304@connotech.com> Date: Wed, 22 Feb 2006 07:43:00 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Internet-Drafts@ietf.org wrote: > 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 : Requirements related to DNSSEC Trust Anchor Rollover > > Author(s) : S. Crocker, et al. > Filename : draft-ietf-dnsext-rollover-requirements-00.txt > Pages : > Date : 2006-2-21 > This document essentially says that manual methods of trust anchor key management *are* adequate. In my opinion, the remaining contents can only trigger unproductive discussions. I whish I'm wrong on this! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 17:43:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2i6-0003QR-U8 for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 17:43:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC2i3-0007vd-LZ for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 17:43:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC2e1-000PlX-VD for namedroppers-data@psg.com; Wed, 22 Feb 2006 22:39:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC2e0-000PlJ-Vw for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 22:39:37 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 21D4011D531; Wed, 22 Feb 2006 14:39:35 -0800 (PST) From: Wes Hardaker To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers Organization: Sparta References: <200602211826.k1LIQa8A009663@staff.nominet.org.uk> Date: Wed, 22 Feb 2006 14:39:34 -0800 In-Reply-To: <200602211826.k1LIQa8A009663@staff.nominet.org.uk> (Geoffrey Sisson's message of "Tue, 21 Feb 2006 18:26:36 GMT") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >>>>> On Tue, 21 Feb 2006 18:26:36 GMT, Geoffrey Sisson said: Geoffrey> 1. Should an upper limit be specified in the standard? Geoffrey> 2. If so, should the upper limit be specified in a separate document Geoffrey> so that the it may be updated without having to re-publish Geoffrey> the entire standard. It would make sense (to me) not to specify a particular number as though-shall, but rather as a "at the time of this writing a decent default to choose"... Ideally, resolvers should be configurable with this upper limit and it should be changeable. Specifying a maximum will help interoperability (zone operators that pick a higher iteration factor than the default deployed max will run into issues). However, it also locks you into a time frame where the number either has too be too small for the future (deployment in the future with faster processors may want more iterations) or too large for the present (trying to pick a large enough number for the future will invariably mean that you'll still allow for more of the DoS attack today that you're trying to prevent). -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 17:48:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2mJ-0003x3-V6 for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 17:48:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC2mI-00081B-MS for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 17:48:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC2kt-0000Il-Il for namedroppers-data@psg.com; Wed, 22 Feb 2006 22:46:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC2kt-0000IU-3Q for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 22:46:43 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 39AC011D531; Wed, 22 Feb 2006 14:46:41 -0800 (PST) From: Wes Hardaker To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 10: Potential DoS on Servers Organization: Sparta References: <200602211827.k1LIRFB2009668@staff.nominet.org.uk> Date: Wed, 22 Feb 2006 14:46:40 -0800 In-Reply-To: <200602211827.k1LIRFB2009668@staff.nominet.org.uk> (Geoffrey Sisson's message of "Tue, 21 Feb 2006 18:27:15 GMT") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> On Tue, 21 Feb 2006 18:27:15 GMT, Geoffrey Sisson said: Geoffrey> Significantly more work is required for a name server to Geoffrey> respond to queries which require negative proofs using NSEC3 Geoffrey> than is required for a client to compose and send them. I suspect this has been discussed before and I simply missed it: I assume that the possibility of allowing sites to select between NSEC3 and NSEC has been discussed? The downside, of course, is that you can't drop NSEC and thus a higher complexity. The upside is that zone operators can pick their poison at least. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 18:47:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3hT-0008Jc-Cw for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 18:47:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3hR-00020S-36 for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 18:47:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC3f5-000493-3J for namedroppers-data@psg.com; Wed, 22 Feb 2006 23:44:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC3f4-00048o-37 for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 23:44:46 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 22 Feb 2006 23:44:44 +0000 X-IronPort-AV: i="4.02,138,1139184000"; d="scan'208"; a="2493560:sNHT29484624" In-Reply-To: To: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Geoffrey Sisson Date: Wed, 22 Feb 2006 23:43:39 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 02/22/2006 11:43:42 PM, Serialize complete at 02/22/2006 11:43:42 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Wes Hardaker wrote on 22/02/2006 22:39:34: > >>>>> On Tue, 21 Feb 2006 18:26:36 GMT, Geoffrey Sisson > said: > > Geoffrey> 1. Should an upper limit be specified in the standard? > > Geoffrey> 2. If so, should the upper limit be specified in a separate document > Geoffrey> so that the it may be updated without having to re-publish > Geoffrey> the entire standard. > > It would make sense (to me) not to specify a particular number as > though-shall, but rather as a "at the time of this writing a decent > default to choose"... Ideally, resolvers should be configurable with > this upper limit and it should be changeable. Without an authoritative reference, increases to max iteration may be nearly impossible to coordinate. Even with an authoritative reference we'll have a "root.hints"-type issue where a long tail of resolvers will be slow to update. One thought, though: perhaps max iterations could be registered as an IANA protocol parameter rather than in a formal document. Another consideration: there will presumably have to be distinct max iterations values for each NSEC3 hash function in use. Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 18:55:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3pr-00009C-UY for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 18:55:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3pq-00028l-IX for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 18:55:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC3oT-0004uF-Tu for namedroppers-data@psg.com; Wed, 22 Feb 2006 23:54:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC3oS-0004ty-RW for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 23:54:29 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 22 Feb 2006 23:54:27 +0000 X-IronPort-AV: i="4.02,138,1139184000"; d="scan'208"; a="2887848:sNHT28742516" In-Reply-To: To: Wes Hardaker Cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 10: Potential DoS on Servers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Geoffrey Sisson Date: Wed, 22 Feb 2006 23:53:22 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 02/22/2006 11:53:25 PM, Serialize complete at 02/22/2006 11:53:25 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Wes Hardaker wrote on 22/02/2006 22:46:40: > >>>>> On Tue, 21 Feb 2006 18:27:15 GMT, Geoffrey Sisson > said: > > Geoffrey> Significantly more work is required for a name server to > Geoffrey> respond to queries which require negative proofs using NSEC3 > Geoffrey> than is required for a client to compose and send them. > > I suspect this has been discussed before and I simply missed it: I > assume that the possibility of allowing sites to select between NSEC3 > and NSEC has been discussed? The downside, of course, is that you > can't drop NSEC and thus a higher complexity. The upside is that zone > operators can pick their poison at least. NSEC3 is not intended to replace NSEC, so zone operators may always elect to use NSEC. Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 21:39:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC6Oc-0004D6-Hn for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 21:39:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC6Ob-0000Oi-2W for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 21:39:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC6LX-000G88-Hi for namedroppers-data@psg.com; Thu, 23 Feb 2006 02:36:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DNS_FROM_RFC_WHOIS, SPF_PASS autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC6LW-000G7x-MA for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 02:36:46 +0000 Received: from [10.0.32.167] (72-255-8-118.client.stsn.net [72.255.8.118]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id AD59D56870; Wed, 22 Feb 2006 18:36:45 -0800 (PST) (envelope-from david.conrad@nominum.com) In-Reply-To: <17402.60350.155682.749025@guava.araneus.fi> References: <20060220174106.GD994@unknown.office.denic.de> <17402.60350.155682.749025@guava.araneus.fi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Peter Koch , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" Date: Wed, 22 Feb 2006 18:36:42 -0800 To: Andreas Gustafsson X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi, As someone who was somewhat involved in the DO bit thing (and apologies and all that)... On Feb 21, 2006, at 2:30 AM, Andreas Gustafsson wrote: > Peter Koch wrote: >> during a discussion at a different venue the question arose >> whether or not >> the "DNSSEC RRs" should be included in a response to an ANY query >> with DO=0. > My take is that they should be included. Or, perhaps put differently, there should be no special treatment of DNSSEC RRs in response to an ANY query, regardless of the setting of DO. > IMO, an ANY query should be considered "explicitly requesting" all > records at the query name. Right. > Also, these DNSSEC RRs are not > "authenticating" DNSSEC RRs in the sense that they do not authenticate > the response, but are simply part of the unauthenticated response data > comprising the complete set of records at the query name. It might be argued that in a world in which DNSSEC matters, ANY queries are pretty pointless. >> Also: the DO bit was introduced to protect "innocent" resolvers >> from >> DNSSEC RRs they might not expect or understand. Yes and no. It was also introduced to try to reduce the impact on servers who would otherwise have to respond with data that no one cared about. > As Mark said, a client sending an ANY query must expect to receive > records of arbitrary types in the answer section even without DNSSEC. (Mark and Andreas agreeing? Wow. :-)) Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 23:00:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC7eZ-0001JO-1L for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 23:00:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC7eY-00044v-MU for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 23:00:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC7bJ-000LCB-7D for namedroppers-data@psg.com; Thu, 23 Feb 2006 03:57:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC7bG-000LBz-CD for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 03:57:06 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1N3uuba041550 for ; Wed, 22 Feb 2006 22:56:56 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k1N3uuqk041549 for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 22:56:56 -0500 (EST) (envelope-from namedroppers) Received: from [158.69.80.165] (helo=hobbes.local) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC3rX-0005GZ-48 for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 23:57:39 +0000 Received: from [157.185.80.165] (localhost [127.0.0.1]) by hobbes.local (Postfix) with ESMTP id CC6EF3923E4; Wed, 22 Feb 2006 18:57:37 -0500 (EST) Date: Wed, 22 Feb 2006 18:57:36 -0500 From: Russ Mundy Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt To: Thierry Moreau Cc: namedroppers@ops.ietf.org X-Priority: 3 In-Reply-To: <43FC5C54.7090304@connotech.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On 2/22/06 at 7:43 AM -0500, Thierry Moreau wrote:=20 > > >Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. >> This draft is a work item of the DNS Extensions Working Group of the IET= =46. >>=20 >> Title : Requirements related to DNSSEC Trust Anchor Rollover >>=20 >> Author(s) : S. Crocker, et al. >> Filename : draft-ietf-dnsext-rollover-requirements-00.txt >> Pages :=20 >> Date : 2006-2-21 >> =20 > >This document essentially says that manual methods of trust anchor key=20 >management *are* adequate. The Working Group has said that manual methods are acceptable - the real wo= rld decision as to whether or not manual methods are used belongs to those responsible for operation of each security-aware resolver. > >In my opinion, the remaining contents can only trigger unproductive=20 >discussions. I whish I'm wrong on this! I too hope that the I-D does not trigger unproductive discussions - that is certainly not intent of the document. The intent is to provide a clear set= of requirement statements that have been identified on the mail list, in dnsex= t WG meetings and in email that was sent to the designated editor team (as directed by the co-chairs). Hopefully, we will have useful, positive discussions that result in a set of requirements that have Working Group consensus. > >Regards, > Russ Mundy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 22 23:03:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC7ht-0001QE-6P for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 23:03:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC7hp-00048S-Kp for dnsext-archive@lists.ietf.org; Wed, 22 Feb 2006 23:03:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC7fc-000LV6-JH for namedroppers-data@psg.com; Thu, 23 Feb 2006 04:01:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC7fb-000LUt-CP for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 04:01:35 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1N41KAQ041633 for ; Wed, 22 Feb 2006 23:01:21 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k1N41KBd041632 for namedroppers@ops.ietf.org; Wed, 22 Feb 2006 23:01:20 -0500 (EST) (envelope-from namedroppers) Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC7c0-000LDs-FB for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 03:57:52 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2006 19:57:52 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1N3vpHh025374; Wed, 22 Feb 2006 19:57:51 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 22:57:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Wed, 22 Feb 2006 22:57:49 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210147208B@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcYoQQBSPx16PpQ0EdqhogARJOT6egP6wsbw From: "Bernie Volz \(volz\)" To: , "dhcwg" Cc: X-OriginalArrivalTime: 23 Feb 2006 03:57:50.0956 (UTC) FILETIME=[50F512C0:01C6382D] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Hi: I have just submitted revised versions of the drafts. Copies of what I = submitted are available at: ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-ddns-resolution-11.txt ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-fqdn-option-12.txt ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-dhcpv6-fqdn-04.txt ftp://ftpeng.cisco.com/volz/draft-ietf-dnsext-dhcid-rr-11.txt Ralph had sent a list of 11 issues to the mailing list. And, then = followed up with 19 more raised by Pekka Savola but that list of issues = did not go to the DHC WG. Both emails are below so you can see the full = list of 30 issues. I believe I have addressed all of them. Some key changes are that the DHCID RR now has an additional field to = specify the digest type and we've switched to using SHA-256 instead of = MD5. We need to figure out what the next step is -- do we need another DHC / = DNSEXT WG last-call or do we send these to the IESG directly? If there is strong demand, I can develop diff files but as there were a = lot of minor edits and changes to references, it likely will be rather = large set of differences. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms (rdroms) > Sent: Thursday, February 02, 2006 4:38 PM > To: namedroppers@ops.ietf.org; dhcwg > Cc: Olaf Kolkman; Harald@Alvestrand.no; Stig Venaas; =D3lafur=20 > Gu>mundsson /DNSEXT co-chair > Subject: [dhcwg] Open issues in DHCP FQDN, DHCID and=20 > DDNS-DHCP Related RFCs >=20 > Included below is a summary list of the open issues in this package of > documents: >=20 > draft-ietf-dnsext-dhcid-rr-10.txt > draft-ietf-dhc-ddns-resolution-10.txt > draft-ietf-dhc-dhcpv6-fqdn-03.txt > draft-ietf-dhc-fqdn-option-11.txt >=20 > 1. Which DHCID RR encoding does an IPv4 client/server use (Brian > Carpenter; Bernie has submitted text to resolve the issue) > 2. Editorial comment on resolution doc section 6.3.2 and AAAA records > (Ted Hardie) > 3. s/byte/octet/g (Scott Hollenbeck) > 4. Use example. or example.com. in examples (Scott Hollenbeck) > 5. s/signature/hash value/g (Russ Housley) > 6. In the resolution doc "security considerations" s/where or/whether > or/ (Jon Peterson) > 7. Add an 8-bit algorithm identifier to the DHCID RR to > support algorithm agility (Allison Mankin) > 8. Use of MD5 as opposed to a stronger hash function (Sam Hartman, > Russ Housley) > 9. Hash agility (Sam Hartman, Allison Mankin) > 10. Russ's comment that an attacker that has some knowledge of MAC > addresses does not need to do lot of work. I think this can be > addressed in security considerations by saying this is not privacy > but just obfuscation (Russ Housley) > 11. UTF-8 character set usage (Harald Alvestrand, gen-art) >=20 > Issues 1-6 are strictly editorial and the document editors=20 > will revise the > documents to resolve those issues in the next revision. >=20 > Issues 7-10 are all related to the hash algorithm specified=20 > in the documents > and the requirements for algorithm agility. We will resolve=20 > those issues > through an e-mail discussion to follow. >=20 > Issue 11 needs some clarification; Harald, I hope you'll kick=20 > off a separate > thread to discuss how to resolve this issue. >=20 > - Ralph, for Olafur, Stig and Olaf > -----Original Message----- > From: Ralph Droms (rdroms)=20 > Sent: Wednesday, February 08, 2006 2:28 PM > To: Bernie Volz (volz) > Cc: Stig Venaas; Olaf Kolkman; =D3lafur Gu>mundsson /DNSEXT=20 > co-chair; Harald@Alvestrand.no > Subject: Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP=20 > Related RFCs >=20 > Bernie - it appears there are several issues from Pekka that are not > included in the IESG Discusses (summary below)... >=20 > On 2/8/06 7:57 AM, "Pekka Savola" wrote: >=20 > > On Thu, 2 Feb 2006, Ralph Droms wrote: > >> Included below is a summary list of the open issues in this package > >> of documents: > >>=20 > >> draft-ietf-dnsext-dhcid-rr-10.txt > >> draft-ietf-dhc-ddns-resolution-10.txt > >> draft-ietf-dhc-dhcpv6-fqdn-03.txt > >> draft-ietf-dhc-fqdn-option-11.txt > >=20 > > Just checking, did you also check the following mails: > >=20 > > http://www1.ietf.org/mail-archive/web/ietf/current/msg38995.html > > http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html > > http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05678.html >=20 > Summarizing these issues (starting from 12 after previous=20 > issues 1-11): >=20 > (Substantive) > 12. Interaction between DHCP/DHCID and non-DHCP clients > 13. Server always decides policy on updating existing RRs (section > 6.3.2 of ddns-resolution) > 14. Section 5 of ddns-resolution on DDNS RR TTLs is not=20 > germane to conflict > resolution > 15. Replace "DHCP client" with "node" in section 3 of ddns-resolution > 16. Does section 6.1 of the DHCPv6 FQDN spec work with Rapid Commit? > 17. In section 6 of the DHCPv6 FQDN spec (third bullet in=20 > list), how does > the server know if it has the credentials before it tries=20 > the update? > 18. Security considerations section of DHCPv6 FQDN spec=20 > should include a > pointer to the security considerations section of ddns-resolution > 19. Reword process to define new DHCID RR type codes to use RFC 2434 > process w/o modification >=20 > (Editorial) > 20. Use "example.com" in example FQDNs > 21. In the Intro of ddns-resolution, client and server=20 > negotiate update of > PTR RR as well as A and AAAA RRs > 22. In section 4 of ddns-resolution, "DHCPREQUST" is=20 > DHCPv4-specific; add > ref to corresponding DHCPv6 message > 23. First sentence of section 6.5, ddns-resolution: s/is be/is to be/ > 24. Change refs to RFC 2131 and RFC 3315 to Normative in=20 > ddns-resolution > 25. In DHCPv6 FQDN spec, s/prescence/presence/ > 26. In the Abstract and Intro of the DHCID RR spec, non-DHCP=20 > nodes can be > involved in conflicts as well as DHCP clients > 27. DHCID RR spec shold also include an example of DHCPv6 DHCID RR > generation > 28. Use RFC 3330 documentation prefix instead of 10.0.0.1 (10/8) > 29. Remove citations from abstracts > 30. Refer to both DHCPv4 and DHCPv6 in the Intro of the DHCID RR spec >=20 > Seems like we ought to take a look at these issues and=20 > resolve them as well > as the IESG Discuss issues. >=20 > - RALPH -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 23 08:07:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGBu-0002rN-6R for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 08:07:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCGBs-00006k-R8 for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 08:07:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCG7i-0003Mf-Gr for namedroppers-data@psg.com; Thu, 23 Feb 2006 13:03:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCG7f-0003MQ-SY for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 13:03:08 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k1ND22Mj032015 for ; Thu, 23 Feb 2006 08:02:03 -0500 Received: from gorilla ([129.6.220.3]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id k1ND0xfI004978 for ; Thu, 23 Feb 2006 08:01:01 -0500 (EST) From: "Scott Rose" To: Subject: RE: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt Date: Thu, 23 Feb 2006 08:01:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <43FC5C54.7090304@connotech.com> Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Thierry Moreau > > > > Title : Requirements related to DNSSEC Trust > Anchor Rollover > > > > Author(s) : S. Crocker, et al. > > Filename : draft-ietf-dnsext-rollover-requirements-00.txt > > Pages : > > Date : 2006-2-21 > > > > This document essentially says that manual methods of trust anchor key > management *are* adequate. > I believe that manual methods may be adequate for some zones - it is certainly not adequate for the majority, but depending on security goals, it may be an acceptable design choice. > In my opinion, the remaining contents can only trigger unproductive > discussions. I whish I'm wrong on this! I read both requirements drafts, and I think it may be a good idea to merge some of the ideas in both documents into a unified draft of technical requirements. Scott > > Regards, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.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. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 23 14:16:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLxJ-0002GY-4Y for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 14:16:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLxG-0000kH-Nl for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 14:16:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCLtM-0002aV-4s for namedroppers-data@psg.com; Thu, 23 Feb 2006 19:12:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.91.160.27] (helo=denic.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCLtL-0002a7-15 for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 19:12:43 +0000 Received: by unknown.office.denic.de (Postfix, from userid 501) id 2775426A67F; Thu, 23 Feb 2006 20:12:36 +0100 (CET) Date: Thu, 23 Feb 2006 20:12:36 +0100 From: Peter Koch To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" Message-ID: <20060223191236.GQ2302@unknown.office.denic.de> References: <20060220180020.C17E611425@sa.vix.com> <200602202226.k1KMQ1mY016045@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602202226.k1KMQ1mY016045@drugs.dv.isc.org> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Thanks for all the responses so far. Just in case my question was neutral, i support the "pro" side. The "con" may identify himself :-) On Tue, Feb 21, 2006 at 09:26:01AM +1100, Mark Andrews wrote: > I'd expect to see the records in the answer section as a > client making a * query is expecting to see records it > cannot decode. A RFC 1035 client cannot decode a RP record > but no one here would say don't sent the RP. > > I would not expect to see the DNSSEC records in the additional > and authority sections. Agreed, my question was imprecise. Suggest the follwoing text for the clarifications document: ANY queries When responding to ANY queries without the DO bit set, authoritative or recursive servers MUST include in the answer section any DNSSEC specific RRSets that are present for QNAME, just as they would for any other RR type. Since no DNSSEC processing is requested, DNSSEC specific RRSets MUST NOT appear in the authority or additional section. > Asking * to a parent server with a signed parent zone of a > signed child zone gets more interesting. DS, NSEC and RRSIG Yes, that touches a whole lot of different issues. > should be in the answer section. There should be a referral > containing the NS records. Again there would be not DNSSEC Which NS RRSet in this case? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 23 14:19:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLzV-0003UT-Rh for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 14:19:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLzT-0000m2-E1 for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 14:19:05 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCLx8-00034Q-9C for namedroppers-data@psg.com; Thu, 23 Feb 2006 19:16:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCLx6-000345-Ut for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 19:16:37 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1D9CF33C1C for ; Thu, 23 Feb 2006 19:16:35 +0000 (GMT) Message-ID: <43FE0A1A.5070902@algroup.co.uk> Date: Thu, 23 Feb 2006 19:16:42 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Internet-Drafts@ietf.org wrote: > 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 : Requirements related to DNSSEC Trust Anchor Rollover Comments: Emergency Trust Anchor Rollover: "Any security-aware resolver using those RR(s) as Trust Anchor(s) must quickly remove them from use by the resolver." Surely not - what must happen is they must start using the new keys and stop using the old ones. Normal or Scheduled Trust Anchor Rollover: "Operators of security-aware resolvers using RR(s) from that zone as Trust Anchors need to acquire new and remove revoked Trust Anchors at roughly the same time as the signed zone issues or revokes RR(s)." Actually the requirement is that they don't use revoked ones after they are revoked and do use new ones. Why is this different? Because it allows resolvers that are offline for an extended period to comply. 5.3 - is "SHALL" (as opposed to "shall") a word? 5.9 - "Information about the issuer's view of that state of Resource Records used as Trust Anchors" - should "that" be "the"? also, a metacomment - some of the requirements seem to have ended up hidden in the definitions (such as those I comment on above). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 23 14:39:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCMIp-000744-RX for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 14:39:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCMIo-0001R2-FS for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 14:39:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCMH9-0004QT-Dm for namedroppers-data@psg.com; Thu, 23 Feb 2006 19:37:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCMH7-0004QB-Re for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 19:37:18 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 23 Feb 2006 19:37:16 +0000 X-IronPort-AV: i="4.02,141,1139184000"; d="scan'208"; a="2503171:sNHT27203704" In-Reply-To: <43FE0A1A.5070902@algroup.co.uk> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Geoffrey Sisson Date: Thu, 23 Feb 2006 19:36:09 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 02/23/2006 07:36:13 PM, Serialize complete at 02/23/2006 07:36:13 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Ben Laurie wrote on 23/02/2006 19:16:42: > 5.3 - is "SHALL" (as opposed to "shall") a word? Equivalent to "MUST" (RFC 2119). Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 23 15:52:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCNSH-0006D8-Ap for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 15:52:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCNSH-0004fB-0z for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 15:52:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCNPZ-0008td-6Z for namedroppers-data@psg.com; Thu, 23 Feb 2006 20:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCNPX-0008sw-Nx for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 20:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1NKo20e027338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCNPV-0003DW-V9; Thu, 23 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ds-sha256-05.txt Message-Id: Date: Thu, 23 Feb 2006 15:50:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 : Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) Author(s) : W. Hardaker Filename : draft-ietf-dnsext-ds-sha256-05.txt Pages : 9 Date : 2006-2-23 This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to key signing DNSKEY key(s) in a child zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ds-sha256-05.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-ds-sha256-05.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: <2006-2-23145042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ds-sha256-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ds-sha256-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-23145042.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 23 16:15:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCNnk-0003Dq-T8 for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 16:15:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCNnk-0005eM-JV for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 16:15:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCNlm-000AHl-Q3 for namedroppers-data@psg.com; Thu, 23 Feb 2006 21:13:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCNll-000AHZ-Ok for namedroppers@ops.ietf.org; Thu, 23 Feb 2006 21:13:01 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 23E8F11DACA; Thu, 23 Feb 2006 13:13:00 -0800 (PST) From: Wes Hardaker To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers Organization: Sparta References: Date: Thu, 23 Feb 2006 13:12:59 -0800 In-Reply-To: (Geoffrey Sisson's message of "Wed, 22 Feb 2006 23:43:39 +0000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f >>>>> On Wed, 22 Feb 2006 23:43:39 +0000, Geoffrey Sisson said: Geoffrey> One thought, though: perhaps max iterations could be registered as Geoffrey> an IANA protocol parameter rather than in a formal document. Or... wait for it.... wait for it... A new RRTYPE at the zone (thus should always exist for nsec3 enabled zones) containing the number of iterations (or a range) that the zone uses for it's nsec3 records. Implementations could choose to query for that record if the number advertised in a return nsec3 record was greater than what it wanted to calculate without verifying it has to. I'm about 90% kidding, but it would help. Geoffrey> Another consideration: there will presumably have to be Geoffrey> distinct max iterations values for each NSEC3 hash function Geoffrey> in use. True. Another related attack is actually not for people forging NSEC3 records and returning them to an attacker, but is actually much worse: Consider a registered zone with huge nsec3 iterations in it. Then consider sending mail from that zone to any mail server that performs dns lookups for spam checking or other filtering reasons. Now imagine sending 10000 messages or more. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 23 22:42:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCTqN-0006ye-QE for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 22:42:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCTqM-0001qc-H8 for dnsext-archive@lists.ietf.org; Thu, 23 Feb 2006 22:42:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCTls-0008yO-7Y for namedroppers-data@psg.com; Fri, 24 Feb 2006 03:37:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCTlr-0008y9-67 for namedroppers@ops.ietf.org; Fri, 24 Feb 2006 03:37:31 +0000 Received: from [169.223.252.34] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1O3bD7J049181; Thu, 23 Feb 2006 22:37:16 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060220174106.GD994@unknown.office.denic.de> References: <20060220174106.GD994@unknown.office.denic.de> Date: Fri, 24 Feb 2006 11:37:19 +0800 To: Peter Koch From: Edward Lewis Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 18:41 +0100 2/20/06, Peter Koch wrote: >Colleagues, > >during a discussion at a different venue the question arose whether or not >the "DNSSEC RRs" should be included in a response to an ANY query with DO=0. > >pro: > ... > >con: > > RFC 4035, 3.2 says: > > 3.2.1. The DO Bit > ... > (IF)the DO bit in an initiating query is not set, the name server side > MUST strip any authenticating DNSSEC RRs from the response but MUST > NOT strip any DNSSEC RR types that the initiating query explicitly > requested. > > The important part is the last full sentence. > > Also: the DO bit was introduced to protect "innocent" resolvers from > DNSSEC RRs they might not expect or understand. Don't treat the DNSSEC records that are unknown differently than other unknown records. ;) >Opinions? I think the latter is "pro" as well. DNSSEC records included here explicitly patch the query type, they are not authenticating. (A "QTYPE=any" explicitly matches all type codes.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 24 16:49:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkoh-0001Uu-0B for dnsext-archive@lists.ietf.org; Fri, 24 Feb 2006 16:49:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCkof-0003GP-BU for dnsext-archive@lists.ietf.org; Fri, 24 Feb 2006 16:49:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCklk-0002HJ-9u for namedroppers-data@psg.com; Fri, 24 Feb 2006 21:46:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [158.69.80.165] (helo=hobbes.local) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCklh-0002Gw-9Y for namedroppers@ops.ietf.org; Fri, 24 Feb 2006 21:46:29 +0000 Received: from [157.185.80.165] (localhost [127.0.0.1]) by hobbes.local (Postfix) with ESMTP id DB3D4395AC6; Fri, 24 Feb 2006 16:46:27 -0500 (EST) Date: Fri, 24 Feb 2006 16:46:26 -0500 From: Russ Mundy Subject: RE: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt To: Scott Rose Cc: namedroppers@ops.ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 On 2/23/06 at 8:01 AM -0500, Scott Rose wrote: >> -----Original Message----- >> From: owner-namedroppers@ops.ietf.org >> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Thierry Moreau >> > >> > Title : Requirements related to DNSSEC Trust >> Anchor Rollover >> > >> > Author(s) : S. Crocker, et al. >> > Filename : draft-ietf-dnsext-rollover-requirements-00.txt >> > Pages : >> > Date : 2006-2-21 >> > >> >> This document essentially says that manual methods of trust anchor key >> management *are* adequate. >> > >I believe that manual methods may be adequate for some zones - it is >certainly not adequate for the majority, but depending on security goals, = it >may be an acceptable design choice. > >> In my opinion, the remaining contents can only trigger unproductive >> discussions. I whish I'm wrong on this! > >I read both requirements drafts, and I think it may be a good idea to merg= e >some of the ideas in both documents into a unified draft of technical >requirements. This I-D was finished except for final formatting when Thierry announced hi= s I-D. I reviewed that I-D prior to submitting this one and do think that th= ere might be some things that the Working Group might want to incorporate into this one but (as the final 'clean-up' editor) I did not incorporate any ite= ms into this draft for several reasons - it would have further delayed getting this draft out, items from that draft can be incorporated into subsequent versions of this draft, the requirements in Thierry's draft seemed to be addressing what would be needed for a full-blown pki which I think is more than the WG wants for rollover, and there seemed to be some different usage= of terms from what is defined in rfc-4033. At the risk of repeating, I think that it's certainly possible that there a= re some things from Thierry's draft that should be incorporated into this one = - Working Group participants really need to speak up (or would that be 'mail = up' :*) their views to namedroppers. Russ > >Scott > >> >> Regards, >> >> -- >> >> - Thierry Moreau >> >> CONNOTECH Experts-conseils inc. >> 9130 Place de Montgolfier >> Montreal, Qc >> Canada H2M 2A1 >> >> Tel.: (514)385-5691 >> Fax: (514)385-5900 >> >> web site: http://www.connotech.com >> e-mail: thierry.moreau@connotech.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. >> archive: >> > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 24 19:22:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmlE-0007UN-Ta for dnsext-archive@lists.ietf.org; Fri, 24 Feb 2006 18:54:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCmlB-0007rQ-UQ for dnsext-archive@lists.ietf.org; Fri, 24 Feb 2006 18:54:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCmhN-000FKC-Vz for namedroppers-data@psg.com; Fri, 24 Feb 2006 23:50:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCmhN-000FJs-A5 for namedroppers@ops.ietf.org; Fri, 24 Feb 2006 23:50:09 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1ONo1BX010426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCmhF-0003MT-GI; Fri, 24 Feb 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-11.txt Message-Id: Date: Fri, 24 Feb 2006 18:50:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --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 : A DNS RR for Encoding DHCP Information (DHCID RR) Author(s) : M. Stapp, et al. Filename : draft-ietf-dnsext-dhcid-rr-11.txt Pages : 10 Date : 2006-2-24 It is possible for DHCP clients to attempt to update the same DNS FQDN or attempt to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the "DHCID" RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-dhcid-rr-11.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-dhcid-rr-11.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: <2006-2-24155006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-24155006.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. archive: From owner-namedroppers@ops.ietf.org Sat Feb 25 11:31:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD2KF-0005wH-Gh for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 11:31:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD2KE-0005Aw-3q for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 11:31:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD2Fg-000IoO-O7 for namedroppers-data@psg.com; Sat, 25 Feb 2006 16:26:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD2Ff-000IoB-LY for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 16:26:35 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001433; 25 Feb 2006 11:28:06 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 25 Feb 2006 11:26:46 -0500 Received: from connotech.com (209.71.204.103) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001431; 25 Feb 2006 11:26:40 -0500 Message-ID: <44008D9E.9080604@connotech.com> Date: Sat, 25 Feb 2006 12:02:22 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Mundy CC: Scott Rose , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Russ Mundy wrote: "[...] the requirements in Thierry's draft seemed to be addressing what would be needed for a full-blown pki which I think is more than the WG wants for rollover [...]" This assessment of draft-moreau-dnsext-tak-req-00.txt is unsupported, expeditious, imprecise, and misleading. You may infer that I disagree. The document draft-moreau-dnsext-tak-req-00.txt is an independent I-D submission addressing the automated trust anchor key rollover requirements for DNSSEC. The dnsext wg is chartered to work on this automated rollover. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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. archive: From owner-namedroppers@ops.ietf.org Sat Feb 25 13:23:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD44w-0007H9-Sv for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 13:23:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD44w-0008Qh-If for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 13:23:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD429-000OmR-8C for namedroppers-data@psg.com; Sat, 25 Feb 2006 18:20:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD425-000Om1-KZ for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 18:20:42 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1PIKQ5M058603; Sat, 25 Feb 2006 13:20:26 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060224210949.03b72d20@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 25 Feb 2006 13:20:20 -0500 To: "Bernie Volz \(volz\)" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Cc: , , , Sam Hartman In-Reply-To: <8E296595B6471A4689555D5D725EBB210147208B@xmb-rtp-20a.amer. cisco.com> References: <8E296595B6471A4689555D5D725EBB210147208B@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b At 22:57 22/02/2006, Bernie Volz \(volz\) wrote: >Hi: > >I have just submitted revised versions of the=20 >drafts. Copies of what I submitted are available at: > >Ralph had sent a list of 11 issues to the=20 >mailing list. And, then followed up with 19 more=20 >raised by Pekka Savola but that list of issues=20 >did not go to the DHC WG. Both emails are below=20 >so you can see the full list of 30 issues. > >I believe I have addressed all of them. Bernie, thank you for your diligent work on getting the document set updated. >Some key changes are that the DHCID RR now has=20 >an additional field to specify the digest type=20 >and we've switched to using SHA-256 instead of MD5. To give a little background on this change. During the document revision there was a off-list discussion that involved Ralph Droms, Olafur Gudmundsson, David Harkins, Sam Hartman, Ted Lemon and Bernie Volz. This recollection is mine apologies to anyone that I misrepresent/misunderstood/omitted. This results of discussion need to be documented, and I'm doing that here. 1. Without obfuscation of the client ID, it is trivial to track clients as the move around. 1.5 No protocol change can protect a client that exposes its Client ID over a public network, such as the IETF wireless net. But obfuscation still provides large number of clients with increased privacy. 2. In the overall schema of things he cost difference between using MD5, SHA1 and SHA256 is not that great, thus the=20 strongest one should be used. 3. Changing obfuscation functions over time can either be accomplished by using a new field in DHCID or new RR type. It is better not having to do a type code rollover. The rollover to a new digest function MUST be defined by the NEW definition, by this document. The reason for this is we are not sure if there is ever a need so spending time on that right now is not productive, and by selecting the one of the strongest functions available right now we hope to push this far into the future, i.e. after Ted, Ralph and I retire from the ietf :-). >We need to figure out what the next step is --=20 >do we need another DHC / DNSEXT WG last-call or=20 >do we send these to the IESG directly? Most of the changes are "minor" and I do not see need for a last call, either at the WG level or IETF. Scanning the documents I'm concerned that the examples are TBD, thus I request that at least 3 parties calculate the new digests and post their results. After which the DHCID document is needs to be updated. >If there is strong demand, I can develop diff=20 >files but as there were a lot of minor edits and=20 >changes to references, it likely will be rather large set of differences. Diffs and (partial history are available at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dhcid-rr/ http://tools.ietf.org/wg/dhc/draft-ietf-dhc-ddns-resolution/ http://tools.ietf.org/wg/dhc/draft-ietf-dhc-fqdn-option/ http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dhcpv6-fqdn/ =D3lafur =20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 25 14:34:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD5BJ-00049n-Tz for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 14:34:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD5BI-00029z-Hm for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 14:34:17 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD58X-0002GZ-HQ for namedroppers-data@psg.com; Sat, 25 Feb 2006 19:31:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD58U-0002GF-VU for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 19:31:23 +0000 Received: from [10.20.30.41] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0242BC2DA4; Sat, 25 Feb 2006 19:31:24 +0000 (GMT) Date: Sat, 25 Feb 2006 19:31:16 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Geoffrey Sisson , Wes Hardaker Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers Message-ID: <80869D5AC743B3F3FBC04578@[10.20.30.41]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 --On 24 February 2006 18:11 +0000 Geoffrey Sisson wrote: > The problem with the 10% non-kidding part is that a malicious/ignorant > zone operator could put the value in this RR arbitrarily high, too. That was why I was (again 90% kidding) suggesting it got inherited from its parent. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 25 15:35:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD68Q-0003EL-Rt for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 15:35:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD68P-0003QA-Ch for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 15:35:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD65J-0005Eh-Uj for namedroppers-data@psg.com; Sat, 25 Feb 2006 20:32:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS,SPF_PASS autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD65J-0005EV-5R for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 20:32:09 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 27A135682F; Sat, 25 Feb 2006 12:32:08 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060225152428.039d7a58@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 25 Feb 2006 15:33:26 -0500 To: Russ Mundy From: Mike StJohns Subject: RE: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt Cc: namedroppers@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi Russ - I'm going to have to object to the 12 month period in 5.5 as a requirement. It's a nice to have, but we should consider any box that's been sitting on the shelf for 12 months as the equivalent of a freshly manufactured box for purposes of ANY configuration. If this requirement stands, it eliminates any possibility of doing this in-band with the DNS protocol and will require an external key-management system that can handle being disconnected for 12 months. (And I'm not sure I know of any one). [OK - I know I have to explain this. Basically, DNS is two different protocols - a two-way transport protocol and a one-way data protocol. It's possible to query a server if you get problematic - protocol-wise - answers during a query, but it's currently not possible to do something like ask an authoritative server for all the changes that were made over the last twelve months - e.g. what the database folks call "journaling". To accomplish a recovery from 12 month down time you're going to need to be able to chain all the changes at the appropriate times and even, if your original trust anchor is compromised, I'm not sure you can trust your answer. This would suggest using a set of signatures completely outside of DNSSEC - maybe even something based on 509 certs and messages] Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 25 15:41:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD6EK-0007Gt-PR for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 15:41:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD6EK-0003Xf-G2 for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 15:41:28 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD6Ct-0005dY-E8 for namedroppers-data@psg.com; Sat, 25 Feb 2006 20:39:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS,SPF_PASS autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD6Cs-0005dJ-LG for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 20:39:58 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 6226C5682D; Sat, 25 Feb 2006 12:39:57 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060225153650.039ca9a0@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 25 Feb 2006 15:41:15 -0500 To: Peter Koch ,namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" In-Reply-To: <20060220174106.GD994@unknown.office.denic.de> References: <20060220174106.GD994@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Read all the current responses to this thread - but didn't go back into prehistory. OK - depending on the resolution for NSEC3 and type code rollover - Do you need a specific "DO" bit for each flavor of DNSSEC? Or if an RRSet is signed by DNSSECold (SIG), DNSSECcurrent(RRSIG) and DNSSEC(NSEC3SIG) are all of these returned for "DO"? Mike At 12:41 PM 2/20/2006, Peter Koch wrote: >Colleagues, > >during a discussion at a different venue the question arose whether or not >the "DNSSEC RRs" should be included in a response to an ANY query with DO=0. > >pro: > > section 3 of RFC 4035 (top of page 9) says: > > A security-aware name server that receives a DNS query that does not > include the EDNS OPT pseudo-RR or that has the DO bit clear MUST > treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and > MUST NOT perform any of the additional processing described below. > > "treat ... as it would any other RRset" would support ANY covering those, > which is consistent with RFC 3225 (which explicitly listed ANY). > > Also, this would be consistent with RFC 3597, not requiring special > handling for "unknown" types. > >con: > > RFC 4035, 3.2 says: > > 3.2.1. The DO Bit > > The resolver side of a security-aware recursive name server MUST set > the DO bit when sending requests, regardless of the state of the DO > bit in the initiating request received by the name server side. If > the DO bit in an initiating query is not set, the name server side > MUST strip any authenticating DNSSEC RRs from the response but MUST > NOT strip any DNSSEC RR types that the initiating query explicitly > requested. > > The important part is the last full sentence. > > Also: the DO bit was introduced to protect "innocent" resolvers from > DNSSEC RRs they might not expect or understand. > >Opinions? > >-Peter > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 25 16:40:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD79m-0003ub-K9 for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 16:40:50 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD79m-0005ya-Ij for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 16:40:50 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FD79l-00050a-1H for dnsext-archive@lists.ietf.org; Sat, 25 Feb 2006 16:40:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD77A-0008fy-LB for namedroppers-data@psg.com; Sat, 25 Feb 2006 21:38:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD77A-0008fm-2U for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 21:38:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8EAE811426 for ; Sat, 25 Feb 2006 21:38:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt In-Reply-To: Your message of "Sat, 25 Feb 2006 12:02:22 EST." <44008D9E.9080604@connotech.com> References: <44008D9E.9080604@connotech.com> Date: Sat, 25 Feb 2006 21:38:07 +0000 Message-Id: <20060225213807.8EAE811426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 # "[...] the requirements in Thierry's draft seemed to be addressing what # would be needed for a full-blown pki which I think is more than the WG # wants for rollover [...]" # # This assessment of draft-moreau-dnsext-tak-req-00.txt is unsupported, # expeditious, imprecise, and misleading. You may infer that I disagree. since your work on this is patented, most of us have not reviewed it. # The document draft-moreau-dnsext-tak-req-00.txt is an independent I-D # submission addressing the automated trust anchor key rollover # requirements for DNSSEC. The dnsext wg is chartered to work on this # automated rollover. and what is the IPR status of your requirements document? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 26 09:47:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDNBF-00087r-Rl for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 09:47:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDNBF-00058Z-Gs for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 09:47:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDN6N-00081X-8U for namedroppers-data@psg.com; Sun, 26 Feb 2006 14:42:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDN6L-000816-Kh for namedroppers@ops.ietf.org; Sun, 26 Feb 2006 14:42:22 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2CC0B33C1C; Sun, 26 Feb 2006 14:42:19 +0000 (GMT) Message-ID: <4401BE4B.3080207@algroup.co.uk> Date: Sun, 26 Feb 2006 14:42:19 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Russ Mundy CC: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Russ Mundy wrote: > see in-line: > > On 2/23/06 at 7:16 PM -0000, Ben Laurie wrote: >> Internet-Drafts@ietf.org wrote: >>> 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 : Requirements related to DNSSEC Trust Anchor Rollover >> Comments: >> >> Emergency Trust Anchor Rollover: >> >> "Any security-aware resolver >> using those RR(s) as Trust Anchor(s) must quickly remove them from >> use by the resolver." >> >> Surely not - what must happen is they must start using the new keys >> and stop using the old ones. > > The current wording may need improved but I think that your suggested change > infers that there _will_ (or MUST) be new keys available at the time that the implies, surely. But in any case if there aren't new keys it isn't rollover. > 'old' keys should no longer be used, e.g., 'old' keys have been compromised. > While I agree that having new keys in place when old keys are removed is the > most desireable state but I believe that there is a real possibility that a > zone may not have new keys available so that the zone can no longer be > operated as signed. In that case, the security-aware resolver should stop > using the old key as a TA and treat everything under that hierarchy as _not_ > signed. In other words, the TA should no longer be used even though a new key > is not available. Do you have some wording suggestions? I really would prefer that the definition of rollover and the requirements were separated. Here's what I'd suggest: Emergency Trust Anchor Rollover The operator of a signed zone has issued new DNSKEY RR(s) and/or DS RR(s) as part of an exceptional event. Emergency Trust Anchor Revocation The operator of a signed zone wishes to indicate that the current DNSKEY and/or DS RR(s) are no longer valid as part of an exceptional event. with the requirements moved down to the requirements section. >> Normal or Scheduled Trust Anchor Rollover: >> >> "Operators of security-aware resolvers using RR(s) from that zone as >> Trust Anchors need to acquire new and remove revoked Trust Anchors >> at roughly the same time as the signed zone issues or revokes >> RR(s)." >> >> Actually the requirement is that they don't use revoked ones after >> they are revoked and do use new ones. Why is this different? Because >> it allows resolvers that are offline for an extended period to comply. > > I agree that this definition doesn't mesh particularly well with 5.5 but I > don't think that they conflict either in that when a system is 'returning from > offline' there should be an effective, secure method for it the resolver to > use only valid TAs. Do you have some suggested words here? Again, split the definition from the requirement, and make the requirement: Operators of security-aware resolvers using RR(s) from that zone as Trust Anchors need to acquire new and remove revoked Trust Anchors such that no old key is used for long after revocation." Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 26 21:50:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDYSp-0006L2-El for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 21:50:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDYSn-0007oF-VV for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 21:50:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDYNA-0003Lo-QU for namedroppers-data@psg.com; Mon, 27 Feb 2006 02:44:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDYN9-0003LS-7F for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 02:44:28 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1R2iGRP064718 for ; Sun, 26 Feb 2006 21:44:16 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k1R2iGnE064717 for namedroppers@ops.ietf.org; Sun, 26 Feb 2006 21:44:16 -0500 (EST) (envelope-from namedroppers) Received: from [158.69.80.165] (helo=hobbes.local) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FClLC-0006CN-FT for namedroppers@ops.ietf.org; Fri, 24 Feb 2006 22:23:10 +0000 Received: from [157.185.80.165] (localhost [127.0.0.1]) by hobbes.local (Postfix) with ESMTP id 6E847395B30; Fri, 24 Feb 2006 17:23:09 -0500 (EST) Date: Fri, 24 Feb 2006 17:23:08 -0500 From: Russ Mundy Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt To: Ben Laurie Cc: namedroppers@ops.ietf.org X-Priority: 3 In-Reply-To: <43FE0A1A.5070902@algroup.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] see in-line: On 2/23/06 at 7:16 PM -0000, Ben Laurie wrote:=20 >Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. >> This draft is a work item of the DNS Extensions Working Group of the IET= =46. >>=20 >> Title : Requirements related to DNSSEC Trust Anchor Rollover > >Comments: > >Emergency Trust Anchor Rollover: > > "Any security-aware resolver > using those RR(s) as Trust Anchor(s) must quickly remove them from > use by the resolver." > >Surely not - what must happen is they must start using the new keys >and stop using the old ones. The current wording may need improved but I think that your suggested chang= e infers that there _will_ (or MUST) be new keys available at the time that t= he 'old' keys should no longer be used, e.g., 'old' keys have been compromised= =2E While I agree that having new keys in place when old keys are removed is th= e most desireable state but I believe that there is a real possibility that a zone may not have new keys available so that the zone can no longer be operated as signed. In that case, the security-aware resolver should stop using the old key as a TA and treat everything under that hierarchy as _not= _ signed. In other words, the TA should no longer be used even though a new = key is not available. Do you have some wording suggestions? > >Normal or Scheduled Trust Anchor Rollover: > > "Operators of security-aware resolvers using RR(s) from that zone as > Trust Anchors need to acquire new and remove revoked Trust Anchors > at roughly the same time as the signed zone issues or revokes > RR(s)." > >Actually the requirement is that they don't use revoked ones after >they are revoked and do use new ones. Why is this different? Because >it allows resolvers that are offline for an extended period to comply. I agree that this definition doesn't mesh particularly well with 5.5 but I don't think that they conflict either in that when a system is 'returning f= rom offline' there should be an effective, secure method for it the resolver to use only valid TAs. Do you have some suggested words here? > >5.3 - is "SHALL" (as opposed to "shall") a word? What Geoff said "Equivalent to "MUST" (RFC 2119)." > >5.9 - "Information about the issuer's view of that state of Resource > Records used as Trust Anchors" - should "that" be "the"? Right, got it, thanks. > >also, a metacomment - some of the requirements seem to have ended up >hidden in the definitions (such as those I comment on above). Well there was some discussion among the editor team about things that shou= ld be definitions and things that should be requirements. For the most part, = the requirements section are things the editor team received as directed in the last WG meeting (mail list, direct mail & WG meetings). The definitions we= re written to explain terms that were included in the requirements that did no= t have definitions (or not enough of a definition) in rfc4033. =20 It is certainly possible that some WG members believe (like Ben) that some = (or lots of) things from the definitions section should be revised & moved to t= he requirements section. If you believe this to be the case, please speak up = & provide suggested wording for the 'new' requirement. > >Cheers, > >Ben. Thanks a lot for your review & input, Russ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 26 21:50:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDYSq-0006LI-Dy for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 21:50:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDYSn-0007oE-VQ for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 21:50:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDYP2-0003Wd-EQ for namedroppers-data@psg.com; Mon, 27 Feb 2006 02:46:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDYP1-0003WO-FQ for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 02:46:23 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1R2kE6w064733 for ; Sun, 26 Feb 2006 21:46:14 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k1R2kDSt064732 for namedroppers@ops.ietf.org; Sun, 26 Feb 2006 21:46:14 -0500 (EST) (envelope-from namedroppers) Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD4Tz-0000NE-Lp for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 18:49:31 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 25 Feb 2006 10:49:31 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1PInUVb008312; Sat, 25 Feb 2006 10:49:30 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Feb 2006 13:49:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Date: Sat, 25 Feb 2006 13:49:28 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21014727DC@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Thread-Index: AcY6OCzUQww2L+qtQ5Skm0/ukLrR1gAAhQ7Q From: "Bernie Volz \(volz\)" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= Cc: , , , "Sam Hartman" X-OriginalArrivalTime: 25 Feb 2006 18:49:30.0456 (UTC) FILETIME=[35F86D80:01C63A3C] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > Scanning the documents I'm concerned that the examples are TBD, thus > I request that at least 3 parties calculate the new digests and post > their results. After which the DHCID document is needs to be updated. I figured I'd wait until we settled on whether this was the correct way = to go before supplying the DHCID RR data for the 3 examples. (I also = didn't have a SHA-256 implementation readily at hand to actually write a = quick program but implementations are readily available, such as in the = OpenSSL distribution. I wanted to get the updated draft out figuring = that the examples can be handled during the RFC editing process.) - Bernie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 26 21:58:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDYaG-00005b-NV for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 21:58:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDYaF-0007yW-9Q for dnsext-archive@lists.ietf.org; Sun, 26 Feb 2006 21:58:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDYYW-0005MA-4O for namedroppers-data@psg.com; Mon, 27 Feb 2006 02:56:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDYYU-0005L6-5p for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 02:56:10 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1R2txVs064789 for ; Sun, 26 Feb 2006 21:55:59 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k1R2txG9064788 for namedroppers@ops.ietf.org; Sun, 26 Feb 2006 21:55:59 -0500 (EST) (envelope-from namedroppers) Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FD76Y-0008e3-Kz for namedroppers@ops.ietf.org; Sat, 25 Feb 2006 21:37:30 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2006 13:37:31 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1PLbPHf006599; Sat, 25 Feb 2006 13:37:26 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Feb 2006 16:37:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs Date: Sat, 25 Feb 2006 16:37:24 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21014727EE@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Open issues in DHCP FQDN,DHCID and DDNS-DHCP Related RFCs Thread-Index: AcY6OCzUQww2L+qtQ5Skm0/ukLrR1gAAhQ7QAAXU0nA= From: "Bernie Volz \(volz\)" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= Cc: , , "Sam Hartman" , X-OriginalArrivalTime: 25 Feb 2006 21:37:25.0686 (UTC) FILETIME=[AB468560:01C63A53] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Here's my calculation of the 3 examples in the DHCID RR draft. Example 1: client.example.com. A 10.0.0.1 client.example.com. DHCID = AAABxLmlskllE0MVjd57zHcWmEH3pCQ6VytcKD//7es/deY=3D Example 2: chi.example.com. A 10.0.12.99 chi.example.com. DHCID = AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdWL3b/NaiUDlW2No=3D Example 3: chi6.example.com. AAAA 2000::1234:5678 chi6.example.com. DHCID = AAIBY2/AuCccgoJbsaxcQc9TUapptP69lOjxfNuVAA2kjEA=3D When calculating the SHA-256 hash, the following data patterns were = used: unsigned char example_1_data[] =3D { 0x01, // ethernet type code 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, // mac address 6, 'c', 'l', 'i', 'e', 'n', 't', 7, 'e', 'x', 'a', 'm', 'p', 'l', 'e', 3, 'c', 'o', 'm', 0 }; unsigned char example_2_data[] =3D { 0x01, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, // client identifier 3, 'c', 'h', 'i', 7, 'e', 'x', 'a', 'm', 'p', 'l', 'e', 3, 'c', 'o', 'm', 0 }; unsigned char example_3_data[] =3D { 0x00, 0x01, 0x00, 0x06, 0x41, 0x2d, 0xf1, 0x66, // DUID 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 4, 'c', 'h', 'i', '6', 7, 'e', 'x', 'a', 'm', 'p', 'l', 'e', 3, 'c', 'o', 'm', 0 }; Before base64 encoding, the 2 octet identifier type and 1 octet digest = type (=3D1) were added in front of the resulting SHA-256 hash. - Bernie > -----Original Message----- > From: Bernie Volz (volz)=20 > Sent: Saturday, February 25, 2006 1:49 PM > To: =D3lafur Gu=F0mundsson /DNSEXT co-chair > Cc: margaret@thingmagic.com; namedroppers@ops.ietf.org; Sam=20 > Hartman; dhcwg@ietf.org > Subject: RE: [dhcwg] Open issues in DHCP FQDN,DHCID and=20 > DDNS-DHCP Related RFCs >=20 > > Scanning the documents I'm concerned that the examples are TBD, thus > > I request that at least 3 parties calculate the new digests and post > > their results. After which the DHCID document is needs to=20 > be updated. >=20 > I figured I'd wait until we settled on whether this was the=20 > correct way to go before supplying the DHCID RR data for the=20 > 3 examples. (I also didn't have a SHA-256 implementation=20 > readily at hand to actually write a quick program but=20 > implementations are readily available, such as in the OpenSSL=20 > distribution. I wanted to get the updated draft out figuring=20 > that the examples can be handled during the RFC editing process.) >=20 > - Bernie >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 05:44:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfrH-00012w-G1 for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 05:44:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDfrE-0004wt-0u for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 05:44:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDfnR-0005d3-C6 for namedroppers-data@psg.com; Mon, 27 Feb 2006 10:40:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDfnP-0005c6-3v for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 10:40:03 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k1RAe0KW079712 for ; Mon, 27 Feb 2006 11:40:00 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44008D9E.9080604@connotech.com> References: <44008D9E.9080604@connotech.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-61--479153783" Message-Id: Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt Date: Mon, 27 Feb 2006 11:40:03 +0100 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-61--479153783 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 25, 2006, at 6:02 PM, Thierry Moreau wrote: > The document draft-moreau-dnsext-tak-req-00.txt is an independent I-D > submission addressing the automated trust anchor key rollover > requirements for DNSSEC. The dnsext wg is chartered to work on this > automated rollover. And we do so by keeping focus on the working group requirements document. If anybody would like to see requirements changed or added then, as always, the suggestion is to write a "patch" to the WG requirements document (wording as it should appear in the document) and argue why you would like to have it there. Some participants are already following that strategy. If there is consensus for your position the modification goes in. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-61--479153783 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEAtcDtN/ca3YJIocRAvHwAKDJy5QvhrTPBLF8E9Vv8pZteYmTOACg3e0/ N6C1/KJHsYnb7/dDIKMFS6g= =WeM3 -----END PGP SIGNATURE----- --Apple-Mail-61--479153783-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 06:21:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDgRM-0003rZ-Ix for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 06:21:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDgRL-0006Mu-3R for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 06:21:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgPN-0007Yx-C8 for namedroppers-data@psg.com; Mon, 27 Feb 2006 11:19:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgPL-0007YZ-Em for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 11:19:16 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1RBJ4I1000736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2006 12:19:05 +0100 From: Simon Josefsson To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060227:i-d-announce@ietf.org::YRYSHQQVBxgECmNq:Vrl X-Hashcash: 1:21:060227:namedroppers@ops.ietf.org::wD0ubDfABRUWF9YY:229b X-Hashcash: 1:21:060227:internet-drafts@ietf.org::MygP2JSpo3ZbcQqf:5dVQ Date: Mon, 27 Feb 2006 12:19:03 +0100 In-Reply-To: (Internet-Drafts@ietf.org's message of "Tue, 21 Feb 2006 15:50:02 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Section 5.2 says: The solution SHOULD not have any intellectual property encumbrance on either the technologies used by the solution nor implementations of the solution. The technology used by the solution SHOULD permit implementers to provide complete, running implementations that have Berkley open source type of licensing. I suggest modifying it to: The solution SHOULD not have any intellectual property encumbrance on either the technologies used by the solution nor implementations of the solution. The technology used by the solution SHOULD permit implementers to provide complete, running implementations that have Berkley open source type or GNU Generic Public License free software type of licensing. The reasons is that we expect that implementations of this solution to be released under the GPL (e.g., in glibc), and that the GPL places certain additional restrictions on solutions, that the Berkeley license do not places, which I feel are important to capture here. In general, this section may be poorly phrased. I see no problem in picking a solution that is patented if there is a license that grant everyone sufficient rights to use the solution without any additional problems. What do you think? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 06:38:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDgho-0003wY-9I for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 06:38:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDghl-0006qt-Pt for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 06:38:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgfc-0008Vi-To for namedroppers-data@psg.com; Mon, 27 Feb 2006 11:36:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgfc-0008VF-4N for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 11:36:04 +0000 Received: from [10.20.30.41] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id BB0EEC2DA7; Mon, 27 Feb 2006 11:36:06 +0000 (GMT) Date: Mon, 27 Feb 2006 11:35:56 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Simon Josefsson , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 --On 27 February 2006 12:19 +0100 Simon Josefsson wrote: > The reasons is that we expect that implementations of this solution to > be released under the GPL (e.g., in glibc), and that the GPL places > certain additional restrictions on solutions, that the Berkeley > license do not places, which I feel are important to capture here. I don't think your propose change makes sense. What the original para seeks to do is ensure that the IPR can be released under a BSD-style license. The very fact that it can be released under such a license means that it can also be released under a GPL-style license (as BSD-style licenses allow relicensing). Your proposal suggests that we merely ensure that it can be released under BSD *OR* GPL. This would permit IPR that was /only/ released under GPL, which would prevent a BSD release (as GPL does not permit relicensing under BSD). Your point that the wording is significantly broken is, however, taken. BSD and GPL are both /copyright/ licenses, neither of which make any mention of patents, and neither have any patent grant or patent defence clauses. It's thus perfectly possible to release an implementation of a patent-encumbered algorithm under (say) the GPL, and retain a cause of action against those using it. On that basis I would suggest simply deleting the second sentence (which adds nothing except confusion to the first sentence). But in any case, isn't there an IETF standard which specifies what sort of IPR encumbrances are and are not acceptable, in which case can't we just use that, rather than attempting to repeat that debate in microcosm? If so, the whole paragraph can be replaced with a reference to that, and we can stop trying to be lawyers :-) ... Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 06:47:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDgqy-0008H4-Jg for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 06:47:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDgqy-0007AT-80 for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 06:47:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgoj-00098k-Pp for namedroppers-data@psg.com; Mon, 27 Feb 2006 11:45:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgoi-00098X-RJ for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 11:45:29 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1RBjIom004317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 12:45:19 +0100 From: Simon Josefsson To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060227:alex@alex.org.uk::eZiaTautopiHS61I:DhpE X-Hashcash: 1:21:060227:namedroppers@ops.ietf.org::o1glT/8dB1wfRUSU:BdpM Date: Mon, 27 Feb 2006 12:45:17 +0100 In-Reply-To: (Alex Bligh's message of "Mon, 27 Feb 2006 11:35:56 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Alex Bligh writes: > --On 27 February 2006 12:19 +0100 Simon Josefsson wrote: > >> The reasons is that we expect that implementations of this solution to >> be released under the GPL (e.g., in glibc), and that the GPL places >> certain additional restrictions on solutions, that the Berkeley >> license do not places, which I feel are important to capture here. > > I don't think your propose change makes sense. What the original para > seeks to do is ensure that the IPR can be released under a BSD-style > license. The very fact that it can be released under such a license > means that it can also be released under a GPL-style license (as BSD-style > licenses allow relicensing). > > Your proposal suggests that we merely ensure that it can be released > under BSD *OR* GPL. This would permit IPR that was /only/ released under > GPL, which would prevent a BSD release (as GPL does not permit relicensing > under BSD). No, that was not my point. I strongly believe the solution should be possible to implement with any popular free license. Including both the BSD and the GPL. If you have a better way to capture that, I'm all for it. > Your point that the wording is significantly broken is, however, taken. > BSD and GPL are both /copyright/ licenses, neither of which make any > mention of patents, and neither have any patent grant or patent defence > clauses. It's thus perfectly possible to release an implementation of > a patent-encumbered algorithm under (say) the GPL, and retain a cause > of action against those using it. At the risk of starting an unproductive discussion, that is incorrect, the GPLv3 draft do talk about patents. > On that basis I would suggest simply deleting the second sentence > (which adds nothing except confusion to the first sentence). I disagree. Making it possible to implement this solution with either BSD or GPL license seem required for wider adoption. > But in any case, isn't there an IETF standard which specifies what sort of > IPR encumbrances are and are not acceptable, in which case can't we just > use that, rather than attempting to repeat that debate in microcosm? If so, > the whole paragraph can be replaced with a reference to that, and we > can stop trying to be lawyers :-) ... See RFC 3979. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 07:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDhA0-0002lV-16 for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 07:07:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDh9x-0007e7-Jy for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 07:07:28 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDh7d-000AHY-Ki for namedroppers-data@psg.com; Mon, 27 Feb 2006 12:05:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDh7c-000AGv-PC for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 12:05:00 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FDh7b-0004qk-Di for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 07:04:59 -0500 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id EFE0513744; Mon, 27 Feb 2006 07:04:49 -0500 (EST) Date: Mon, 27 Feb 2006 07:04:49 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 Message-ID: <20060227120449.GB16300@dba3> Reply-To: Andrew Sullivan Mail-Followup-To: namedroppers@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On Mon, Feb 27, 2006 at 11:35:56AM +0000, Alex Bligh wrote: > But in any case, isn't there an IETF standard which specifies what sort of > IPR encumbrances are and are not acceptable, in which case can't we just > use that, rather than attempting to repeat that debate in microcosm? If so, RFC3979 is pretty clear that the IETF won't take a stand on "acceptable or not". But sectoin 6.5 offers three options under which IPR claims are not incompatible with publication as RFC: a) under a royalty-free and otherwise reasonable and non- discriminatory license b) under a license that contains reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment c) without the need to obtain a license from the IPR holder As nearly as I can tell, the point of the reference to the BSD in this draft is to eliminate (b) from the running, and to clarify what "reasonable and non-discriminatory" in (a) means. My suspicion, however, is that (c) is what we'd really like. So perhaps something along the following lines will get us there: The solution MUST be covered by one of options (a) or (c) of section 6.5 of [RFC3979]. If the technology is covered by option (a), the license SHOULD be compatible with standard licensing models of existing resolver libraries. Does that help? A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 09:48:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjgF-00083S-0n for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 09:48:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjgD-0004yL-NO for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 09:48:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjcR-000Iml-An for namedroppers-data@psg.com; Mon, 27 Feb 2006 14:44:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjcP-000ImV-Vo for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 14:44:58 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k1REiqpM082770 for ; Mon, 27 Feb 2006 15:44:53 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-68--464470877" To: Namedroppers From: "Olaf M. Kolkman" Subject: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 27 Feb 2006 15:44:45 +0100 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-68--464470877 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Colleagues, draft-ietf-dnsext-dnssec-experiments-00 has been on our stack for quite some time draft-ietf-dnsext-dnssec-opt-in was updated to reflect the content of the former. In a mail to this group [1] we pointed you to these documents and requested careful review of the methodology to perform these experiments. We would hereby like to issue a working group last call on draft-ietf-dnsext-dnssec-experiments-02 and draft-ietf-dnsext-dnssec-opt-in-08 The chairs think that it would be proper for the dnssec-experiments draft to continue its life as an standards track RFC and for the opt-in draft to continue as an experimental RFC and would like to ask for consent or argued counter-proposals. Please carefully review the methodology described in dnssec-experiments and review if the methodology has been correctly applied to the opt-in draft. Please refrain from rehashing old discussions on the opt-in mechanism; How experiments is applied to opt-in has relevance. This working group last call will terminate March 15. We request at least 5 people to state that they thoroughly read said documents before we forward to the IESG. Our apologies for leaving this shelved for so long. --Olaf Kolkman [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg00252.html ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-68--464470877 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEAxBitN/ca3YJIocRAsg6AKDJKYFQ83OGtyqCgsC7s+kSfn5vIwCaA4fE eoOwhslPp71tkDqxwOjjNj0= =eI9U -----END PGP SIGNATURE----- --Apple-Mail-68--464470877-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:02:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjtr-0007dU-3u for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:02:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjtq-0005Sx-4Y for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:02:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjry-000Jto-DA for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:01:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,INFO_TLD, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjrx-000Jtd-PK for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:01:01 +0000 Received: from [10.20.30.41] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 83305C2DA7; Mon, 27 Feb 2006 15:01:03 +0000 (GMT) Date: Mon, 27 Feb 2006 15:00:49 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 Message-ID: <288304AC0C90E8853991FD04@[10.20.30.41]> In-Reply-To: <20060227120449.GB16300@dba3> References: <20060227120449.GB16300@dba3> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f --On 27 February 2006 07:04 -0500 Andrew Sullivan wrote: > The solution MUST be covered by one of options (a) or (c) of > section 6.5 of [RFC3979]. If the technology is covered by option > (a), the license SHOULD be compatible with standard licensing > models of existing resolver libraries. That would indeed address my point. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:09:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjzq-0001L7-Ax for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:09:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjzp-0005jX-Uh for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:09:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjxn-000KMo-Jt for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:07:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjxm-000KMb-S4 for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:07:03 +0000 Received: from [10.20.30.41] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C5768C2DA7; Mon, 27 Feb 2006 15:07:04 +0000 (GMT) Date: Mon, 27 Feb 2006 15:06:52 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Simon Josefsson Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 Message-ID: <987B0DE1DB2923E12D7B5484@[10.20.30.41]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Simon, >> I don't think your propose change makes sense. What the original para >> seeks to do is ensure that the IPR can be released under a BSD-style >> license. The very fact that it can be released under such a license >> means that it can also be released under a GPL-style license (as >> BSD-style licenses allow relicensing). >> >> Your proposal suggests that we merely ensure that it can be released >> under BSD *OR* GPL. This would permit IPR that was /only/ released under >> GPL, which would prevent a BSD release (as GPL does not permit >> relicensing under BSD). > > No, that was not my point. I strongly believe the solution should be > possible to implement with any popular free license. Including both > the BSD and the GPL. If you have a better way to capture that, I'm > all for it. I agree with what you are seeking to do. However, your wording had could be read to have the opposite effect... > The technology used by the solution SHOULD permit > implementers to provide complete, running implementations that have > Berkley open source type or GNU Generic Public License free > software type of licensing. ... because of the word "or" before GNU. A technology that ONLY allowed GPL would thus satisfy the "SHOULD" condition, if you read the "or" to mean "the solution shall either provide X or Y". My point was that you can delete the GPL bit because ANYTHING that's licensed under a BSD license can ANYWAY be relicensed under the GPL. So if it is a necessary condition that a BSD version of the library can be released, then that alone is sufficient to ensure a GPL version can also be released (at least in terms of copyright grant). >> Your point that the wording is significantly broken is, however, taken. >> BSD and GPL are both /copyright/ licenses, neither of which make any >> mention of patents, and neither have any patent grant or patent defence >> clauses. It's thus perfectly possible to release an implementation of >> a patent-encumbered algorithm under (say) the GPL, and retain a cause >> of action against those using it. > > At the risk of starting an unproductive discussion, that is incorrect, > the GPLv3 draft do talk about patents. That's WIP. GPLv2 is what's here today. >> On that basis I would suggest simply deleting the second sentence >> (which adds nothing except confusion to the first sentence). > > I disagree. Making it possible to implement this solution with either > BSD or GPL license seem required for wider adoption. I agree completely, just that that's not what your proposed amendment does (at least the way I read it). If you wrote "or (at the implementers choice)" then it would not be ambiguous. But... >> But in any case, isn't there an IETF standard which specifies what sort >> of IPR encumbrances are and are not acceptable, in which case can't we >> just use that, rather than attempting to repeat that debate in >> microcosm? If so, the whole paragraph can be replaced with a reference >> to that, and we can stop trying to be lawyers :-) ... > > See RFC 3979. I think this is preferable (if we refer to (a) or (c)). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:09:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDk0S-0001mG-Th for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:09:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDk0S-0005kh-Lo for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:09:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjz1-000KTI-TE for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:08:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjz1-000KT1-FV for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:08:19 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1FE8211425 for ; Mon, 27 Feb 2006 15:08:19 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 In-Reply-To: Your message of "Mon, 27 Feb 2006 15:00:49 GMT." <288304AC0C90E8853991FD04@[10.20.30.41]> References: <20060227120449.GB16300@dba3> <288304AC0C90E8853991FD04@[10.20.30.41]> Date: Mon, 27 Feb 2006 15:08:19 +0000 Message-Id: <20060227150819.1FE8211425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 # > The solution MUST be covered by one of options (a) or (c) of # > section 6.5 of [RFC3979]. If the technology is covered by option # > (a), the license SHOULD be compatible with standard licensing # > models of existing resolver libraries. # # That would indeed address my point. if someone points at GLIBC2 and says "it's compatible with that", no. if someone points at BIND and says "it's compatible with that", yes. therefore i think we need stronger, more explicit wording. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:13:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDk4R-0004lk-I8 for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:13:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDk4R-0005vU-4H for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:13:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDk2B-000Kno-2O for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:11:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDk2A-000KnW-9O for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:11:34 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Feb 2006 10:11:32 -0500 X-IronPort-AV: i="4.02,150,1139202000"; d="scan'208"; a="83183501:sNHT1866862878" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1RFBUjL006036; Mon, 27 Feb 2006 10:11:31 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 10:11:30 -0500 Received: from [161.44.65.148] ([161.44.65.148]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 10:11:30 -0500 Message-ID: <440316A1.7000509@cisco.com> Date: Mon, 27 Feb 2006 10:11:29 -0500 From: Mark Stapp User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= CC: "Bernie Volz (volz)" , margaret@thingmagic.com, namedroppers@ops.ietf.org, Sam Hartman , dhcwg@ietf.org Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs References: <8E296595B6471A4689555D5D725EBB21014727EE@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21014727EE@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Feb 2006 15:11:30.0480 (UTC) FILETIME=[1685FB00:01C63BB0] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Olafur, I computed the sha256 hashes this morning using python 2.4 and the Crypto.SHA256 module, and got the same DHCID data for the three examples. I didn't think it would be necessary to post a transcript of the python command-lines or a script, but I could do that if you think it's helpful. -- Mark Bernie Volz (volz) wrote: > Here's my calculation of the 3 examples in the DHCID RR draft. > > Example 1: > client.example.com. A 10.0.0.1 > client.example.com. DHCID AAABxLmlskllE0MVjd57zHcWmEH3pCQ6VytcKD//7es/deY= > > Example 2: > chi.example.com. A 10.0.12.99 > chi.example.com. DHCID AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdWL3b/NaiUDlW2No= > > Example 3: > chi6.example.com. AAAA 2000::1234:5678 > chi6.example.com. DHCID AAIBY2/AuCccgoJbsaxcQc9TUapptP69lOjxfNuVAA2kjEA= > > When calculating the SHA-256 hash, the following data patterns were used: > > unsigned char example_1_data[] = { > 0x01, // ethernet type code > 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, // mac address > 6, 'c', 'l', 'i', 'e', 'n', 't', > 7, 'e', 'x', 'a', 'm', 'p', 'l', 'e', > 3, 'c', 'o', 'm', > 0 }; > > unsigned char example_2_data[] = { > 0x01, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, // client identifier > 3, 'c', 'h', 'i', > 7, 'e', 'x', 'a', 'm', 'p', 'l', 'e', > 3, 'c', 'o', 'm', > 0 }; > > unsigned char example_3_data[] = { > 0x00, 0x01, 0x00, 0x06, 0x41, 0x2d, 0xf1, 0x66, // DUID > 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, > 4, 'c', 'h', 'i', '6', > 7, 'e', 'x', 'a', 'm', 'p', 'l', 'e', > 3, 'c', 'o', 'm', > 0 }; > > Before base64 encoding, the 2 octet identifier type and 1 octet digest type (=1) were added in front of the resulting SHA-256 hash. > > - Bernie > >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Saturday, February 25, 2006 1:49 PM >> To: Ólafur Guðmundsson /DNSEXT co-chair >> Cc: margaret@thingmagic.com; namedroppers@ops.ietf.org; Sam >> Hartman; dhcwg@ietf.org >> Subject: RE: [dhcwg] Open issues in DHCP FQDN,DHCID and >> DDNS-DHCP Related RFCs >> >>> Scanning the documents I'm concerned that the examples are TBD, thus >>> I request that at least 3 parties calculate the new digests and post >>> their results. After which the DHCID document is needs to >> be updated. >> >> I figured I'd wait until we settled on whether this was the >> correct way to go before supplying the DHCID RR data for the >> 3 examples. (I also didn't have a SHA-256 implementation >> readily at hand to actually write a quick program but >> implementations are readily available, such as in the OpenSSL >> distribution. I wanted to get the updated draft out figuring >> that the examples can be handled during the RFC editing process.) >> >> - Bernie >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:23:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkDM-0000WJ-Nw for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:23:08 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkDM-00067Z-Lw for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:23:08 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FDkDK-0000wT-Ka for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:23:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkBP-000LYw-0O for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:21:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkBN-000LYZ-Lr for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:21:06 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1RFKp6t005264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 16:20:53 +0100 From: Simon Josefsson To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 References: <987B0DE1DB2923E12D7B5484@[10.20.30.41]> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060227:alex@alex.org.uk::BL36KOyTD81ajm+6:4Ys6 X-Hashcash: 1:21:060227:namedroppers@ops.ietf.org::s0LXjhL48b3EMtPW:4k1R Date: Mon, 27 Feb 2006 16:20:50 +0100 In-Reply-To: <987B0DE1DB2923E12D7B5484@[10.20.30.41]> (Alex Bligh's message of "Mon, 27 Feb 2006 15:06:52 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Alex Bligh writes: >>> But in any case, isn't there an IETF standard which specifies what sort >>> of IPR encumbrances are and are not acceptable, in which case can't we >>> just use that, rather than attempting to repeat that debate in >>> microcosm? If so, the whole paragraph can be replaced with a reference >>> to that, and we can stop trying to be lawyers :-) ... >> >> See RFC 3979. > > I think this is preferable (if we refer to (a) or (c)). I agree that this is preferable. I do believe it should be (a) _and_ (c), though. For reference, here they are: a) under a royalty-free and otherwise reasonable and non- discriminatory license, or b) under a license that contains reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without the need to obtain a license from the IPR holder. I don't think b) would be compatible with how several DNS resolvers are distributed today (and thus likely to be distributed tomorrow). a) without c) may cause delays when someone wishes to fork a free implementation, requiring the new distributor to obtain a license. If there are no strong argument that c) has to be permitted, I believe a) AND c) would be the most useful requirement on a solution. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:30:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkKr-0004is-3e for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:30:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkKq-0006Vx-RB for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:30:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkIu-000M9Z-Hh for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:28:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkIt-000M92-LU for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:28:52 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1RFSchl006416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 16:28:39 +0100 From: Simon Josefsson To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 References: <20060227150035.36EA911426@sa.vix.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060227:namedroppers@ops.ietf.org::Nmkqiid+ebao8Sba:7vO X-Hashcash: 1:21:060227:paul@vix.com::bnqNsfO0+dJKtkdS:31Bt Date: Mon, 27 Feb 2006 16:28:37 +0100 In-Reply-To: <20060227150035.36EA911426@sa.vix.com> (Paul Vixie's message of "Mon, 27 Feb 2006 15:00:35 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Paul Vixie writes: > # No, that was not my point. I strongly believe the solution should be > # possible to implement with any popular free license. Including both > # the BSD and the GPL. If you have a better way to capture that, I'm > # all for it. > > BSD code can be forked and rerelased under GPL, but not vice versa. So > if you specify "BSD or GPL" you're allowing for a non-BSD-compatible > license (which TAKREM, for example, has). If you specify "BSD" then you > are effectively allowing "BSD or GPL" implementations. I disagree. GPLv3 discusses patents. It will be possible to create an implementation licensed under the BSD license that is not possible to re-license to GPLv3 because of a patent. I do not think this WG will have a solution to the anchor problem before GPLv3 has been released. Since GLIBC will be available under GPLv3, and may end up containing an implementation of this proposal [1], I believe it is useful to make sure it is possible to implement the solution and release the code under the GPLv3 license. Thanks. [1] Although it will likely be an external add-on in the beginning, similar to how my IDN work was distributed as an add-on to GLIBC in the beginning, but later merged into glibc proper. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:32:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkMS-0005RX-NO for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:32:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkMS-0006XS-Ei for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:32:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkKz-000MLs-Lg for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:31:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkKz-000MLb-0K for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:31:01 +0000 Received: from [10.20.30.41] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id F19A4C2DB0; Mon, 27 Feb 2006 15:31:02 +0000 (GMT) Date: Mon, 27 Feb 2006 15:30:50 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Simon Josefsson Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 Message-ID: In-Reply-To: References: <987B0DE1DB2923E12D7B5484@[10.20.30.41]> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 --On 27 February 2006 16:20 +0100 Simon Josefsson wrote: > I don't think b) would be compatible with how several DNS resolvers > are distributed today (and thus likely to be distributed tomorrow). > > a) without c) may cause delays when someone wishes to fork a free > implementation, requiring the new distributor to obtain a license. > > If there are no strong argument that c) has to be permitted, I believe > a) AND c) would be the most useful requirement on a solution. At risk of spending the whole day arguing about AND vs OR, how can something both be "without the need to obtain a license" AND be "under a royalty-free or otherwise non-discrimatory license". The stronger statement (if we are concerned about minimizing licensing conditions to implementors) would be to require (c). I can't see how requiring "(a) AND (c)" is meaningful. I think it either has to be "(a) or (c)", or "(c)". Only the latter will guarantee it can be released under a BSD license, which is your aim. (a) (which is a possibility in "(a) or (c)" would allow the requirement of a payment of (say) 1 cent per deployed library, which is obviously not compatible with BSD/GPL. Therefore I think we should be going for "(c)". Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 10:38:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkSE-0000VV-Uv for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:38:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkSD-0006pI-Ly for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:38:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkQX-000Mt4-RH for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:36:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkQX-000Mss-6V for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:36:45 +0000 Received: from [10.1.3.233] (helo=roaming3.int.libertyrms.com) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FDkQW-00059Y-4F for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 10:36:44 -0500 Received: by roaming3.int.libertyrms.com (Postfix, from userid 1019) id B67B918B57F; Mon, 27 Feb 2006 10:36:28 -0500 (EST) Date: Mon, 27 Feb 2006 10:36:28 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 Message-ID: <20060227153628.GB21433@afilias.info> Reply-To: Andrew Sullivan References: <20060227120449.GB16300@dba3> <288304AC0C90E8853991FD04@[10.20.30.41]> <20060227150819.1FE8211425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060227150819.1FE8211425@sa.vix.com> User-Agent: Mutt/1.5.11 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Mon, Feb 27, 2006 at 03:08:19PM +0000, Paul Vixie wrote: > # > (a), the license SHOULD be compatible with standard licensing > # > models of existing resolver libraries. > # > # That would indeed address my point. > > if someone points at GLIBC2 and says "it's compatible with that", no. > if someone points at BIND and says "it's compatible with that", yes. That was why I said "models" and not "a model". But the idea is, "It had better be compatible with all the well-known licenses for this sort of stuff." What about ". . .compatible with standard licensing models of existing resolver libraries, including Berkeley- and GNU- style software licenses." (My own preference, FWIW, is to add that technologies that are available under case (c) SHOULD be preferred over other technologies, assuming each meets the other technical requirements. AFAIK this is in keeping with the current BCPs, but I neither am a lawyer nor had a hand in drafting the current BCPs.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 11:13:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDl0R-0006XI-VC for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 11:13:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDl0P-0000Sb-KD for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 11:13:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDky2-000PEX-N5 for namedroppers-data@psg.com; Mon, 27 Feb 2006 16:11:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDky1-000PEL-SP for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 16:11:22 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k1RGBAXV071321 for ; Mon, 27 Feb 2006 11:11:16 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060227105645.03d975f8@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Feb 2006 11:11:07 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: IETF-65 DNSEXT agenda items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Please send to me requests items you want to have on the agenda along with how long a slot you prefer. 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 11:15:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDl1i-00078f-Ml for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 11:15:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDl1i-0000U5-A7 for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 11:15:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDl0P-000PLw-8q for namedroppers-data@psg.com; Mon, 27 Feb 2006 16:13:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDl0O-000PLe-Dv for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 16:13:48 +0000 Received: from [10.20.30.41] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 320C1C2DB0; Mon, 27 Feb 2006 16:13:50 +0000 (GMT) Date: Mon, 27 Feb 2006 16:13:38 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Simon Josefsson , Paul Vixie Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 Message-ID: In-Reply-To: References: <20060227150035.36EA911426@sa.vix.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --On 27 February 2006 16:28 +0100 Simon Josefsson wrote: > I disagree. GPLv3 discusses patents. It will be possible to create > an implementation licensed under the BSD license that is not possible > to re-license to GPLv3 because of a patent. Even if GPLv3 contains a grant, it is STILL possible for a third party to relicense a BSD license under GPLv3. However, the end licensee will not benefit from the grant in GPLv3, as the original IPR holder won't have granted it. The same problem occurs in a much simpler scenario, which is that the license holder grants a BSD license (which has no patent grant). Even if you disambiguate your wording, the "letter of the law" would still be met by an IPR holder who agrees to grant a BSD license to the IPR (which would be ineffective to help enbd users as it didn't contain a patent grant), and a GPLv3 license (which would be effective to end users, but they'd be stuck with a GPLv3 license). That doesn't do what you want, because people can't *USE* it under the BSD license (because they don't have a patent grant). > I do not think this WG will have a solution to the anchor problem > before GPLv3 has been released. Since GLIBC will be available under > GPLv3, and may end up containing an implementation of this proposal > [1], I believe it is useful to make sure it is possible to implement > the solution and release the code under the GPLv3 license. I think trying to reinvent license-discuss here is folly. We should not talk about specific licenses. We should talk about unincumbered IPR. IE we should define the effect we want, not cause. If we really want to talk about software licenses, how about: The technology used by the solution SHOULD permit implementers to provide complete, running implementations under any OSI-approved license that the implementor chooses, without either the implementer or the end user requiring any additional license grant (patent, copyright, or other) to make use of the resultant code. If you like you can add "(including BSD and GPL)" after "OSI-approved license" but I think it's otiose. Can I also pick another hole in this bit: The solution SHOULD not have any intellectual property encumbrance on either the technologies used by the solution nor implementations of the solution. I think it's quite reasonable for a subset of implementations to be subject to IPR "encumbrances", provided you can produce another that isn't. For instance, if someone produces an unpatented method, and provides a closed-source implementation, this should not count against the protocol (the more interoperability the better) PROVIDED that it doesn't make it any harder for anyone else to provide unencumbered implementations. We also have an "either/nor" issue. I think we should have something like. The solution SHOULD not have any intellectual property encumbrance affecting either the technologies used by the solution, or which necessarily affect any implementatoin of the solution. Just to be clear, I fully agree with what you are trying to do here, which is to specify that whatever solution is picked should not create problems for those trying to incorporate the library in to GPL or BSD code, I'm just arguing about the wording; in fact I'd probably go further and make the "SHOULD" a "MUST" given we are talking about every resolver that's out there. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 12:05:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlo1-0007Ma-BE for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 12:05:05 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDk8j-00060T-UX for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:18:21 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FDjtr-0000pP-Gh for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 10:03:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjrY-000Jqr-5b for namedroppers-data@psg.com; Mon, 27 Feb 2006 15:00:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjrX-000Jqf-K9 for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 15:00:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 36EA911426 for ; Mon, 27 Feb 2006 15:00:35 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 In-Reply-To: Your message of "Mon, 27 Feb 2006 12:45:17 +0100." References: Date: Mon, 27 Feb 2006 15:00:35 +0000 Message-Id: <20060227150035.36EA911426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 # No, that was not my point. I strongly believe the solution should be # possible to implement with any popular free license. Including both # the BSD and the GPL. If you have a better way to capture that, I'm # all for it. BSD code can be forked and rerelased under GPL, but not vice versa. So if you specify "BSD or GPL" you're allowing for a non-BSD-compatible license (which TAKREM, for example, has). If you specify "BSD" then you are effectively allowing "BSD or GPL" implementations. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 12:18:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDm15-00056y-94 for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 12:18:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDm13-0002d5-RC for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 12:18:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDlxX-0003B7-7C for namedroppers-data@psg.com; Mon, 27 Feb 2006 17:14:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDlxV-0003Al-Hp for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 17:14:53 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1RHEfFk022178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 18:14:42 +0100 From: Simon Josefsson To: Alex Bligh Cc: namedroppers@ops.ietf.org, Paul Vixie Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 References: <20060227150035.36EA911426@sa.vix.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060227:namedroppers@ops.ietf.org::a/y352i5nKaMLSw6:0p+c X-Hashcash: 1:21:060227:paul@vix.com::CgTxce+nXLwmHM2z:2xHe X-Hashcash: 1:21:060227:alex@alex.org.uk::YQutLN9j9vKxTGxs:Lie3 Date: Mon, 27 Feb 2006 18:14:40 +0100 In-Reply-To: (Alex Bligh's message of "Mon, 27 Feb 2006 16:13:38 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Alex Bligh writes: > --On 27 February 2006 16:28 +0100 Simon Josefsson wrote: > >> I disagree. GPLv3 discusses patents. It will be possible to create >> an implementation licensed under the BSD license that is not possible >> to re-license to GPLv3 because of a patent. > > Even if GPLv3 contains a grant, it is STILL possible for a third party > to relicense a BSD license under GPLv3. However, the end licensee will > not benefit from the grant in GPLv3, as the original IPR holder won't > have granted it. See section 11 of GPLv3. There is an automatic implied patent license right in it, see: http://gplv3.fsf.org/draft http://gplv3.fsf.org/rationale#SECTION003110000000000000000 So it seems it may not be possible to re-license BSD code under the GPLv3, if there is an applicable patent that the IPR holder is not willing to grant a license to. > I think trying to reinvent license-discuss here is folly. We should not > talk about specific licenses. We should talk about unincumbered IPR. > IE we should define the effect we want, not cause. I completely agree here. My issue was prompted up by the current draft discussing licenses. > Just to be clear, I fully agree with what you are trying to do here, > which is to specify that whatever solution is picked should not create > problems for those trying to incorporate the library in to GPL or BSD > code, I'm just arguing about the wording; in fact I'd probably go > further and make the "SHOULD" a "MUST" given we are talking about every > resolver that's out there. I don't think RFC 2119 language is applicable at all here. This is intended to be a guiding document. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 14:31:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDo5z-00041z-CZ for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 14:31:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDo5w-0007OF-PM for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 14:31:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDo1Y-000B1F-42 for namedroppers-data@psg.com; Mon, 27 Feb 2006 19:27:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDo1X-000B12-FD for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 19:27:11 +0000 Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k1RJR1DO019405 for ; Mon, 27 Feb 2006 12:27:01 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k1RJRwCj017964 for ; Mon, 27 Feb 2006 12:27:58 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k1RJRrp1017945; Mon, 27 Feb 2006 12:27:53 -0700 Date: Mon, 27 Feb 2006 12:27:53 -0700 Message-Id: <200602271927.k1RJRrp1017945@localhost.localdomain> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Both requirments documents have good points and severe flaws in presentation. I don't think either one serves as a starting point for modification. Here's my attempt to summarize the requirements from each --- I've tried to preserve the inconsistencies and confusions, possibly introducing new ones: Individual Submission (Moreau) 1. Entity named in whois information for the zone must adopt documented procedures and protocols. 2. Resolver must have trusted configuration store. 3. Resolver may initialize trust at first instantiation of zone keys. 4. Support automated rollover to greatest possible extent. 5. Trustworthiness must be >= previous trustworthiness. 6. Rollover method must have analysis (disclosure) of catastropic failure modes. 7. Resolver must be able to detect key revocation, and resolver must be able to detect key re-use. 8. Management scheme must have analysis of dependency on initial out-of-band distribution of trusted information. 9. Must support two keys at once (incoming and retiring keys). 10. Resolver must be able to detect key revocation. 11. Analysis of how to avoid critical failure modes. ----------------------- Working Group Submission 1. Scalability for Internet-wide usage. 2. No IPR; Berkeley open source licensing recommended. 3,4. Applicable to root zone and all others, including private networks. 5. Reconnection after 12 months should be OK. 6. Manual or automated. 7. Scheduled and non-scheduled rollover. a. Initial Trust Relationship is optional. 8. Timely distribution of TA RRs. 9. Trustworthy distribution of new RRs and retraction of outdated RRs. 10. New RR types are a question to the WG. Requirements derived from the definitions: 1. Resolvers must switch to using new RRs quickly in an emergency rollover. 2. Resolvers must obtain TA RRs in a trustworthy manner. 3. Zone operator issues new keys and optionally revokes old keys; resolvers must switch to using the new keys at "roughly" the same time. 4. Resolvers may have any number of TAs for any number of zones. 5. Resolver operators are responsible for using a trustworthy method of obtaining TAs. The integrity and authenticity must be assured. No TA can be used unless there is an Initial Trust Relationship. 6. Issuer of TA RRs and users of same must know exactly which RRs are revoked. --------------------- The WG submission's main 1, 3, 4, 8, and 9 look good. The WG submission's reqs from definitions 1, 2, and 5 are also good. Moreau's 5, 7 (second clause), and 9 look like good things that aren't in the other draft. Neither document explicitly mentions advertising key lifetimes. The WG submission hints at the issue in saying that a resolver probably won't use more than 20 TA's. Does this mean 20 manually configured lifetimes and ad hoc methods (telephone call?) of update notification? The IPR issue seems to be a point of contention, as is the Initial Trust Relationship (the WG submission seems to contradict itself on this point). Is there really such a thing as an emergency rollover? What happens when a zone switches from being an island of trust to being part of the hierarchy? Should everyone treating it as a TA remove its TA RR's from their resolvers? Hilarie Orman Purple Streak, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 17:46:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr8h-0007lP-2f for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 17:46:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDr8d-0003L2-PZ for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 17:46:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDr4C-000MYg-J8 for namedroppers-data@psg.com; Mon, 27 Feb 2006 22:42:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDr4A-000MYQ-3a for namedroppers@ops.ietf.org; Mon, 27 Feb 2006 22:42:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 57B8611425 for ; Mon, 27 Feb 2006 22:42:05 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-rollover-requirements-00.txt 5.2 In-Reply-To: Your message of "Mon, 27 Feb 2006 16:20:50 +0100." References: <987B0DE1DB2923E12D7B5484@[10.20.30.41]> Date: Mon, 27 Feb 2006 22:42:05 +0000 Message-Id: <20060227224205.57B8611425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c # I agree that this is preferable. I do believe it should be (a) _and_ # (c), though. For reference, here they are: # # a) under a royalty-free and otherwise reasonable and non- # discriminatory license, or # ... # c) without the need to obtain a license from the IPR holder. # agreed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 27 20:19:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDtWu-000439-KH for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 20:19:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDtWt-0006TM-7o for dnsext-archive@lists.ietf.org; Mon, 27 Feb 2006 20:19:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDtSh-0006KG-HQ for namedroppers-data@psg.com; Tue, 28 Feb 2006 01:15:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDtSg-0006Js-EL for namedroppers@ops.ietf.org; Tue, 28 Feb 2006 01:15:34 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0014E5; 27 Feb 2006 20:17:09 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 27 Feb 2006 20:16:32 -0500 Received: from connotech.com (209.71.204.119) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0014E4; 27 Feb 2006 20:16:27 -0500 Message-ID: <4403ACC0.6070607@connotech.com> Date: Mon, 27 Feb 2006 20:52:00 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hilarie Orman CC: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt References: <200602271927.k1RJRrp1017945@localhost.localdomain> In-Reply-To: <200602271927.k1RJRrp1017945@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Dear Hilarie: First, the conventional "Thanks for your interest in our individual sumbission draft." applies to your message. It is thus a pleasure for me to attempt answer the questions you asked. > Neither document explicitly mentions advertising key lifetimes. This is discussed in section 3.3 in the document draft-moreau-dnsext-tak-req-00.txt. Not an explicit formal requirement though. > Is there really such a thing as an emergency rollover? In essence, the document draft-moreau-dnsext-tak-req-00.txt circumvents the definitional issue for "emergency rollover". For resolvers, this is discussed in the 4th to last and 3rd to last paragraphs of section 2.2. On the authoritative nameserver side, please refer to the 2nd requirement in section 2.3: by implication, the presence of a possible "breached state" (in the key life-cycle diagram) mandates support of emergency rollover by nameservers. > What happens when a zone switches from being an island of trust to > being part of the hierarchy? This is discussed in section 3.2. Not an explicit formal requirement though. > Should everyone treating it as a > TA remove its TA RR's from their resolvers? The document draft-moreau-dnsext-tak-req-00.txt des not mandate this behavior. Best regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 28 03:28:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE0Dt-0007Ii-GN for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 03:28:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE0Ds-0002f0-0e for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 03:28:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE08q-0009JV-Br for namedroppers-data@psg.com; Tue, 28 Feb 2006 08:23:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE08o-0009JH-QW for namedroppers@ops.ietf.org; Tue, 28 Feb 2006 08:23:31 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k1S8MqcA005109; Tue, 28 Feb 2006 09:22:53 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <200602271927.k1RJRrp1017945@localhost.localdomain> References: <200602271927.k1RJRrp1017945@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-72--400984198" Message-Id: Cc: Steve Crocker , Russ Mundy , Howard Eland Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt Date: Tue, 28 Feb 2006 09:22:52 +0100 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-72--400984198 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hilarie, Thanks for making this inventory.... You wrote: > I don't think either one serves as a starting point for modification. Personally I think a 3rd document would be overkill and a waist of time. We want to have a rough consensus document on which we can base trade-offs. Once all issues have been identified and we have a rough consensus on what we want we can start making tradeoffs. I propose that the editors extract "Issues" out of this list so that we can discuss them one by one. It will help us to keep focus. Can we count on the editors to do this in the cause of the week? --Olaf > > The WG submission's main 1, 3, 4, 8, and 9 look good. The WG > submission's reqs from definitions 1, 2, and 5 are also good. > Moreau's 5, 7 (second clause), and 9 look like good things that aren't > in the other draft. > > Neither document explicitly mentions advertising key lifetimes. > The WG submission hints at the issue in saying that a resolver > probably > won't use more than 20 TA's. Does this mean 20 manually configured > lifetimes and ad hoc methods (telephone call?) of update notification? > > The IPR issue seems to be a point of contention, as is the Initial > Trust Relationship (the WG submission seems to contradict itself on > this point). > > Is there really such a thing as an emergency rollover? > > What happens when a zone switches from being an island of trust to > being part of the hierarchy? Should everyone treating it as a > TA remove its TA RR's from their resolvers? > > Hilarie Orman > Purple Streak, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-72--400984198 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEBAhdtN/ca3YJIocRApUtAJ95uO6RYEW1DxsNnNiu7gwZJns6GACeLJTc /mRTdHxSo/bp5rNMeZLPu3k= =Cswh -----END PGP SIGNATURE----- --Apple-Mail-72--400984198-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 28 05:30:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE27K-0000L9-OY for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 05:30:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE27J-00060X-AR for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 05:30:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE24O-000GDp-V6 for namedroppers-data@psg.com; Tue, 28 Feb 2006 10:27:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE24N-000GDV-9K for namedroppers@ops.ietf.org; Tue, 28 Feb 2006 10:27:03 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AB3A733C1C; Tue, 28 Feb 2006 10:27:01 +0000 (GMT) Message-ID: <44042578.9030405@algroup.co.uk> Date: Tue, 28 Feb 2006 10:27:04 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hilarie Orman CC: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt References: <200602271927.k1RJRrp1017945@localhost.localdomain> In-Reply-To: <200602271927.k1RJRrp1017945@localhost.localdomain> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Hilarie Orman wrote: > Both requirments documents have good points and severe flaws in > presentation. I don't think either one serves as a starting point for > modification. > > Here's my attempt to summarize the requirements from each --- I've > tried to preserve the inconsistencies and confusions, possibly > introducing new ones: > > Individual Submission (Moreau) > > 1. Entity named in whois information for the zone must > adopt documented procedures and protocols. > 2. Resolver must have trusted configuration store. > 3. Resolver may initialize trust at first instantiation of zone keys. > 4. Support automated rollover to greatest possible extent. > 5. Trustworthiness must be >= previous trustworthiness. > 6. Rollover method must have analysis (disclosure) of catastropic > failure modes. > 7. Resolver must be able to detect key revocation, and > resolver must be able to detect key re-use. > 8. Management scheme must have analysis of dependency on > initial out-of-band distribution of trusted information. > 9. Must support two keys at once (incoming and retiring keys). > 10. Resolver must be able to detect key revocation. > 11. Analysis of how to avoid critical failure modes. > > ----------------------- > > Working Group Submission > > 1. Scalability for Internet-wide usage. > 2. No IPR; Berkeley open source licensing recommended. > 3,4. Applicable to root zone and all others, including private networks. > 5. Reconnection after 12 months should be OK. > 6. Manual or automated. > 7. Scheduled and non-scheduled rollover. > a. Initial Trust Relationship is optional. > 8. Timely distribution of TA RRs. > 9. Trustworthy distribution of new RRs and retraction of outdated RRs. > 10. New RR types are a question to the WG. > > Requirements derived from the definitions: > 1. Resolvers must switch to using new RRs quickly in an emergency rollover. > 2. Resolvers must obtain TA RRs in a trustworthy manner. > 3. Zone operator issues new keys and optionally revokes old keys; > resolvers must switch to using the new keys at "roughly" the same time. > 4. Resolvers may have any number of TAs for any number of zones. > 5. Resolver operators are responsible for using a trustworthy method > of obtaining TAs. The integrity and authenticity must be > assured. No TA can be used unless there is an Initial Trust Relationship. > 6. Issuer of TA RRs and users of same must know exactly which RRs are > revoked. > > --------------------- > > The WG submission's main 1, 3, 4, 8, and 9 look good. The WG > submission's reqs from definitions 1, 2, and 5 are also good. By implication, you are saying that the other clauses are not good. What is wrong with them? > Moreau's 5, 7 (second clause), and 9 look like good things that aren't > in the other draft. > > Neither document explicitly mentions advertising key lifetimes. > The WG submission hints at the issue in saying that a resolver probably > won't use more than 20 TA's. Does this mean 20 manually configured > lifetimes and ad hoc methods (telephone call?) of update notification? > > The IPR issue seems to be a point of contention, as is the Initial > Trust Relationship (the WG submission seems to contradict itself on > this point). Surely a requirements document (at least an initial one) is bound to have contradictory requirements? I'm not sure I agree that IPR is a point of contention - there's some detailed discussion over exactly how to best phrase the requirement to be able to produce free software, but no disagreement over the underlying requirement (apart from Thierry Moreau, who would like us to use his IPR). > Is there really such a thing as an emergency rollover? There's certainly such a thing as a compromised key, and that's what needs to be dealt with. > What happens when a zone switches from being an island of trust to > being part of the hierarchy? Should everyone treating it as a > TA remove its TA RR's from their resolvers? It seems to me the answer is "clearly not" - some people may have a stronger trust relationship with a zone than with its parent. Presumably software is going to end up distinguishing between keys that should be trusted so long as there is no signed path to them, and keys that should be trusted whatever happens. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 28 08:34:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE4zN-0003zj-Bd for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 08:34:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE4zM-0003iP-0Z for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 08:34:05 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE4w3-0000ID-C0 for namedroppers-data@psg.com; Tue, 28 Feb 2006 13:30:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE4w1-0000Hr-4R for namedroppers@ops.ietf.org; Tue, 28 Feb 2006 13:30:37 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k1SDUH0g023317 for ; Tue, 28 Feb 2006 08:30:18 -0500 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id k1SDU1fH014963 for ; Tue, 28 Feb 2006 08:30:01 -0500 (EST) From: "Scott Rose" To: Subject: RE: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt Date: Tue, 28 Feb 2006 08:30:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4403ACC0.6070607@connotech.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Thierry Moreau > > > What happens when a zone switches from being an island of trust to > > being part of the hierarchy? > > This is discussed in section 3.2. Not an explicit formal > requirement though. > Perhaps it should be (in whatever final requirements draft is produced). Or at least the requirement that a zone transitioning from an island of trust to a chain do so gracefully. Especially in the first years of DNSSEC rollout, as more zones move from being islands to part of a chain. "Gracefully" would also mean that a zone continues to publish its own trust anchor in addition to having it as part of a chain. > > Should everyone treating it as a > > TA remove its TA RR's from their resolvers? > > The document draft-moreau-dnsext-tak-req-00.txt des not mandate this > behavior. > Either the validator would remove the TA, or continue to validate/update it when possible through the chain. This would be a policy decision if it was believed the zone would move from chained back to an island for some reason. Scott > Best regards, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.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. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 28 08:52:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5Gk-0000sH-M8 for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 08:52:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5Gj-0003yu-38 for dnsext-archive@lists.ietf.org; Tue, 28 Feb 2006 08:52:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE5F2-0001Z1-V5 for namedroppers-data@psg.com; Tue, 28 Feb 2006 13:50:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE5F2-0001Xo-1x for namedroppers@ops.ietf.org; Tue, 28 Feb 2006 13:50:16 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 28 Feb 2006 13:50:14 +0000 X-IronPort-AV: i="4.02,152,1139184000"; d="scan'208"; a="2951465:sNHT26413536" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k1SDoDqa012079; Tue, 28 Feb 2006 13:50:13 GMT Date: Tue, 28 Feb 2006 13:50:13 GMT From: Geoffrey Sisson Message-Id: <200602281350.k1SDoDqa012079@staff.nominet.org.uk> To: namedroppers@ops.ietf.org, nsec3-testing@nsec3.org Subject: NSEC3 Workshop - 8-10 May Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Nominet and DENIC are organising an NSEC3 workshop to be held at (or near) DENIC's offices in Frankfurt, Germany on 8-10 May 2006. The workshop will focus on: - Functionality and interoperability of NSEC3 tools and implementations - Comprehensive testing of the NSEC3 RR in NSEC3-only and NSEC/NSEC3 environments Participation is open to anyone with a serious interest; however, space is limited, and precedence will be given to people who have a previous involvement with NSEC3 or the development or deployment of DNSSEC. If you are interested in participating, please let me know. There will also be a pre-workshop meeting next week at Nominet's offices in Oxford, United Kingdom. This is also open to anyone with a serious interest, but will have a narrow focus on proof-of-concept and testing of basic functionality of existing code. Reports from both the workshop and pre-workshop will be posted to the namedroppers and nsec3-testing mailing lists. Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: