From root@core3.amsl.com Tue Oct 12 13:45:02 2010 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CC3633A6A55; Tue, 12 Oct 2010 13:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012204502.CC3633A6A55@core3.amsl.com> Date: Tue, 12 Oct 2010 13:45:02 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-22.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 20:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-22.txt Pages : 49 Date : 2010-10-12 This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-enum-enumservices-guide-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12133007.I-D@ietf.org> --NextPart-- From richard@shockey.us Mon Oct 18 13:55:41 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011F53A6BF1 for ; Mon, 18 Oct 2010 13:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIFdR7CRhBiW for ; Mon, 18 Oct 2010 13:55:40 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id E57893A6BCB for ; Mon, 18 Oct 2010 13:55:39 -0700 (PDT) Received: (qmail 2769 invoked by uid 0); 18 Oct 2010 20:57:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 18 Oct 2010 20:57:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=PFB2H+Wnal+ISd8iM0i6OfQgg4xvfQOSePRIZFtnnwzb9eaVGUrTMSVwhKGPNRElkDX/sqoh/1jwbnhH5OqsISt4dC5ji65vQpr7qP44X7aSOmYp1SnF9lDjSUEPdSqW; Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P7wlY-0001fU-Mk for enum@ietf.org; Mon, 18 Oct 2010 14:57:08 -0600 From: "Richard Shockey" To: "'IETF ENUM list'" Date: Mon, 18 Oct 2010 16:57:06 -0400 Message-ID: <02b601cb6f07$06a25ff0$13e71fd0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Actu9NexbAq6/IU4S0uNkhDqA4+L+wAEgXog Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us} Subject: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 20:55:41 -0000 I'm reading this as the "ENUM is considered harmful to the DNS" or don't even think about E2MD -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 18, 2010 2:45 PM To: i-d-announce@ietf.org Cc: iab@iab.org Subject: I-D ACTION:draft-iab-dns-applications-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Architecture Board Working Group of the IETF. Title : Architectural Considerations on Application Features in the DNS Author(s) : O. Kolkman, J. Peterson, H. Tschofenig, B. Aboba Filename : draft-iab-dns-applications-00.txt Pages : 23 Date : 2010-10-18 While the principal purpose of the Domain Name System (DNS) is to translate Internet domain names to IP addresses, over time a number of Internet applications have integrated supplemental features into the DNS to support their operations. Many of these features assist in locating the appropriate service in a domain, or in transforming intermediary identifiers into names that the DNS can process. Proposals to piggyback more sophisticated application behavior on top of the DNS, however, have raised questions about the propriety of instantiating some features in the DNS, especially those with security sensitivities. This document explores the architectural consequences of installing application features in the DNS, and provides guidance for future work in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From lconroy@insensate.co.uk Mon Oct 18 18:19:12 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6B73A6A6A for ; Mon, 18 Oct 2010 18:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nT5-8emzcEn for ; Mon, 18 Oct 2010 18:19:09 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 248B53A6A66 for ; Mon, 18 Oct 2010 18:19:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 587FA6FC6F7; Tue, 19 Oct 2010 02:20:37 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <02b601cb6f07$06a25ff0$13e71fd0$@us> Date: Tue, 19 Oct 2010 02:20:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <805C6AC6-25A8-46CA-9B05-C37D5535066C@insensate.co.uk> References: <02b601cb6f07$06a25ff0$13e71fd0$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1081) Cc: 'IETF ENUM list' Subject: Re: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 01:19:13 -0000 Hi Richard, folks, ... and you're surprised, given the authorship ?)p This is a good document, it is needed, and I don't read it that states = that ENUM is a bad idea. Seriously, this had to be shipped today as it's a -00 draft, so it has = some rough edges. =20 My initial notes on the draft are: - In 3.1, the end of the second sentence on page 8 "needs work". - The second sentence of section 3.3 on page 9 also needs work; 1464 = applied the TXT record that was defined in 1035 for use for arbitrary data. = 1464 did NOT define the TXT record. - The last sentence in 4.1.1 on page 12 has "like" when I'd expect = "likely". - The first sentence of 4.2 uses "surfaced" in a slightly odd way; maybe = "raised" or "exposed"? - in section 4.2 on first paragraph of page 13, void should be replaced = by unused. (draft-ietf-enum-void is ancient; the last one was = draft-ietf-enum-unused-04.txt). - The second sentence of the second paragraph of 4.4 on page 14 starts = with a typo -- should be "In". - being picky, the second "bullet" of section 5 on page 16 could replace = "are only depended on" with "only depend". - missing closing parentheses missing in third sentence of first = paragraph on page 18. ---- I await with interest the IAB's comments on the Google resolver = proposals (perhaps on page 12) and also on the keyassure work (apparently on page 17, if I = decode it correctly) -- after all, Phil *might* (eventually) get carpal if he's the only one = to fight those evil people. There are places where the authors' dry sense of humour made me laugh: - http (or TLS) is the same as DNS -- on page 17, second paragraph, - by implication, CNAME considered a bad sign (there, and earlier on = page 16, second "bullet" of the second set of items on page 16), - the thought that DKIM did NOT chose to use TXT records partially = because it was infeasible at the time to get an RR type while as the DKIM syntax and = semantics was still crystallising (or that they had been through enough pain by = that point :) Send-n as currently written may be in the sights, but it is perfectly = possible to design a "number length" DNS tree that will be very heavily cached and uses the = DNS ability to scale and be information-dense (unlike almost any other protocol, = even TLS -- ha!). Whether that would use NAPTRs or just plain TXT records (like everyone = else) is an entirely different question. It would avoid any need for standardisation = in the IETF, which may be the point. Finally, I really would like to find the bogey man who thought of = putting ringtones in the DNS; I hear much talk of how bad this is, but no-one ever = proposed doing such a perverse thing, AFAICT. all the best, Lawrence On 18 Oct 2010, at 21:57, Richard Shockey wrote: >=20 > I'm reading this as the "ENUM is considered harmful to the DNS" or = don't > even think about E2MD >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 18, 2010 2:45 PM > To: i-d-announce@ietf.org > Cc: iab@iab.org > Subject: I-D ACTION:draft-iab-dns-applications-00.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Internet Architecture Board Working = Group > of the IETF. >=20 > Title : Architectural Considerations on Application > Features in the DNS > Author(s) : O. Kolkman, J. Peterson, H. Tschofenig, B. = Aboba > Filename : draft-iab-dns-applications-00.txt > Pages : 23 > Date : 2010-10-18 > =09 > While the principal purpose of the Domain Name System (DNS) is to > translate Internet domain names to IP addresses, over time a number > of Internet applications have integrated supplemental features into > the DNS to support their operations. Many of these features assist > in locating the appropriate service in a domain, or in transforming > intermediary identifiers into names that the DNS can process. > Proposals to piggyback more sophisticated application behavior on = top > of the DNS, however, have raised questions about the propriety of > instantiating some features in the DNS, especially those with > security sensitivities. This document explores the architectural > consequences of installing application features in the DNS, and > provides guidance for future work in this area. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From bernie@ietf.hoeneisen.ch Wed Oct 20 00:57:49 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF1A3A683F for ; Wed, 20 Oct 2010 00:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytJpg0hkB9FE for ; Wed, 20 Oct 2010 00:57:48 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 768FF3A6849 for ; Wed, 20 Oct 2010 00:57:48 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1P8TZw-0007WL-4f; Wed, 20 Oct 2010 09:59:20 +0200 Date: Wed, 20 Oct 2010 09:59:19 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <02b601cb6f07$06a25ff0$13e71fd0$@us> Message-ID: References: <02b601cb6f07$06a25ff0$13e71fd0$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: 'IETF ENUM list' Subject: Re: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 07:57:49 -0000 Hi Rich et al. Let's look at the bright side of draft-iab-dns-applications-00.txt: Finally we have the concerns expressed in written, and thus a much better basis for future discussions concerning any ENUM extensions (including E2MD). Hopefully, with this document we can finally get rid of an odd form of communication, which was "conveyance of concerns by Grey-Beard-Proxy". cheers, Bernie PS: I'll try to figure out, on which list draft-iab-dns-applications is to be discussed, as the ENUM list is certainly too narrow for this problem space. -- http://ucom.ch/ Tech Consulting for Internet Standardization On Mon, 18 Oct 2010, Richard Shockey wrote: > > I'm reading this as the "ENUM is considered harmful to the DNS" or don't > even think about E2MD > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 18, 2010 2:45 PM > To: i-d-announce@ietf.org > Cc: iab@iab.org > Subject: I-D ACTION:draft-iab-dns-applications-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Internet Architecture Board Working Group > of the IETF. > > Title : Architectural Considerations on Application > Features in the DNS > Author(s) : O. Kolkman, J. Peterson, H. Tschofenig, B. Aboba > Filename : draft-iab-dns-applications-00.txt > Pages : 23 > Date : 2010-10-18 > > While the principal purpose of the Domain Name System (DNS) is to > translate Internet domain names to IP addresses, over time a number > of Internet applications have integrated supplemental features into > the DNS to support their operations. Many of these features assist > in locating the appropriate service in a domain, or in transforming > intermediary identifiers into names that the DNS can process. > Proposals to piggyback more sophisticated application behavior on top > of the DNS, however, have raised questions about the propriety of > instantiating some features in the DNS, especially those with > security sensitivities. This document explores the architectural > consequences of installing application features in the DNS, and > provides guidance for future work in this area. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > From bernie@ietf.hoeneisen.ch Wed Oct 20 01:06:50 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254733A690E for ; Wed, 20 Oct 2010 01:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyRJPIoDtIcO for ; Wed, 20 Oct 2010 01:06:49 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id EF83F3A68E2 for ; Wed, 20 Oct 2010 01:06:48 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1P8Tig-0007ZD-2a; Wed, 20 Oct 2010 10:08:22 +0200 Date: Wed, 20 Oct 2010 10:08:21 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: draft-iab-dns-applications@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM list Subject: [Enum] Which mailing-list for draft-iab-dns-applications-00? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 08:06:50 -0000 Dear authors of draft-iab-dns-applications, draft-iab-dns-applications has raised some interest within the ENUM community. First discussions took place on the ENUM WG mailing list. I believe the ENUM WG mailing list is too narrow for this problem space. May I ask you which mailing list this document is meant to be discussed? Unless we get further instructions from you by the end of this week, we'll assume that the right place for discussing draft-iab-dns-applications is . We are looking forward to your answer. cheers, Bernie, co-chair of the ENUM WG -- http://ucom.ch/ Tech Consulting for Internet Standardization From olaf@NLnetLabs.nl Wed Oct 20 03:21:02 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AF23A6981 for ; Wed, 20 Oct 2010 03:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKBlYEDNbYv4 for ; Wed, 20 Oct 2010 03:17:53 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 7BC7E3A688D for ; Wed, 20 Oct 2010 03:17:49 -0700 (PDT) Received: from dhcp-05.nlnetlabs.nl (dhcp-05.nlnetlabs.nl [213.154.224.71]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o9KAJC6K084464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Oct 2010 12:19:13 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-35-25109395; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: Date: Wed, 20 Oct 2010 12:19:14 +0200 Message-Id: References: To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [213.154.224.1]); Wed, 20 Oct 2010 12:19:13 +0200 (CEST) Cc: draft-iab-dns-applications@tools.ietf.org, IETF ENUM list Subject: Re: [Enum] Which mailing-list for draft-iab-dns-applications-00? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 10:21:02 -0000 --Apple-Mail-35-25109395 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hmmm... good question. I would think that a DNS specific list is to narrow as well. The apps = area list may be a reasonable place but that would miss out on a lot of = DNS folk. Because of the cross area nature it is probably best to stick = to the IETF list (a technical discussion for a change).=20 --Olaf [top-post] On Oct 20, 2010, at 10:08 AM, Bernie Hoeneisen wrote: > Dear authors of draft-iab-dns-applications, >=20 > draft-iab-dns-applications has raised some interest within the ENUM = community. First discussions took place on the ENUM WG mailing list. >=20 > I believe the ENUM WG mailing list is too narrow for this problem = space. May I ask you which mailing list this document is meant to be = discussed? >=20 > Unless we get further instructions from you by the end of this week, = we'll assume that the right place for discussing = draft-iab-dns-applications is . >=20 > We are looking forward to your answer. >=20 > cheers, > Bernie, co-chair of the ENUM WG >=20 > -- >=20 > http://ucom.ch/ > Tech Consulting for Internet Standardization >=20 ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-35-25109395 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMDIwMTAxOTE1WjAj BgkqhkiG9w0BCQQxFgQUDV2DxDDmF+FawWNrFCP/0NACtSkwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAGzHwTsQFRlLzXYDeXM8sSvkPTaziE7FqzXyn6LyIAtxt5vZY00oCYMhUBRdby56 1S8HEPPw9YvFhRYaLopiplAib3zBCSPPl7qxdsE0+mUamf4resco1HGfBOnZVcDsD16T/qUbyT1G iqCEwqldNscvT7xmZBSsPuvMg0qeeGgHJ4Xc/WYMNq1/tdlCcdaMNAnHHgAJ2QCKnauc+zjlEIBL jr8igUGLMT98ZS23T2x0I4JHjBnNZQ6yb9j6nzCQhjfWm0KjT9k/tjHdUzx1TB78IaAANqkvLBqg 2C1y74hppZfhsC41VCbfKh3TAim3ROx82jsQLIpWu69wIqqL/tYAAAAAAAA= --Apple-Mail-35-25109395-- From olaf@NLnetLabs.nl Wed Oct 20 03:22:05 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733303A6407 for ; Wed, 20 Oct 2010 03:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFGyLMw8Ec5H for ; Wed, 20 Oct 2010 03:22:05 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 7BC7E3A688D for ; Wed, 20 Oct 2010 03:17:49 -0700 (PDT) Received: from dhcp-05.nlnetlabs.nl (dhcp-05.nlnetlabs.nl [213.154.224.71]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o9KAJC6K084464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Oct 2010 12:19:13 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-35-25109395; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: Date: Wed, 20 Oct 2010 12:19:14 +0200 Message-Id: References: To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [213.154.224.1]); Wed, 20 Oct 2010 12:19:13 +0200 (CEST) Cc: draft-iab-dns-applications@tools.ietf.org, IETF ENUM list Subject: Re: [Enum] Which mailing-list for draft-iab-dns-applications-00? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 10:22:05 -0000 --Apple-Mail-35-25109395 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hmmm... good question. I would think that a DNS specific list is to narrow as well. The apps = area list may be a reasonable place but that would miss out on a lot of = DNS folk. Because of the cross area nature it is probably best to stick = to the IETF list (a technical discussion for a change).=20 --Olaf [top-post] On Oct 20, 2010, at 10:08 AM, Bernie Hoeneisen wrote: > Dear authors of draft-iab-dns-applications, >=20 > draft-iab-dns-applications has raised some interest within the ENUM = community. First discussions took place on the ENUM WG mailing list. >=20 > I believe the ENUM WG mailing list is too narrow for this problem = space. May I ask you which mailing list this document is meant to be = discussed? >=20 > Unless we get further instructions from you by the end of this week, = we'll assume that the right place for discussing = draft-iab-dns-applications is . >=20 > We are looking forward to your answer. >=20 > cheers, > Bernie, co-chair of the ENUM WG >=20 > -- >=20 > http://ucom.ch/ > Tech Consulting for Internet Standardization >=20 ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-35-25109395 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMDIwMTAxOTE1WjAj BgkqhkiG9w0BCQQxFgQUDV2DxDDmF+FawWNrFCP/0NACtSkwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAGzHwTsQFRlLzXYDeXM8sSvkPTaziE7FqzXyn6LyIAtxt5vZY00oCYMhUBRdby56 1S8HEPPw9YvFhRYaLopiplAib3zBCSPPl7qxdsE0+mUamf4resco1HGfBOnZVcDsD16T/qUbyT1G iqCEwqldNscvT7xmZBSsPuvMg0qeeGgHJ4Xc/WYMNq1/tdlCcdaMNAnHHgAJ2QCKnauc+zjlEIBL jr8igUGLMT98ZS23T2x0I4JHjBnNZQ6yb9j6nzCQhjfWm0KjT9k/tjHdUzx1TB78IaAANqkvLBqg 2C1y74hppZfhsC41VCbfKh3TAim3ROx82jsQLIpWu69wIqqL/tYAAAAAAAA= --Apple-Mail-35-25109395-- From gonzalo.camarillo@ericsson.com Wed Oct 20 04:08:31 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE023A6768 for ; Wed, 20 Oct 2010 04:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P92XwLm3wQPY for ; Wed, 20 Oct 2010 04:08:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 935923A659A for ; Wed, 20 Oct 2010 04:08:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-6d-4cbece0ab5ba Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 87.73.04955.A0ECEBC4; Wed, 20 Oct 2010 13:10:02 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Oct 2010 13:10:02 +0200 Received: from [131.160.126.156] ([131.160.126.156]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Oct 2010 13:10:02 +0200 Message-ID: <4CBECE0A.8040904@ericsson.com> Date: Wed, 20 Oct 2010 14:10:02 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: enum@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2010 11:10:02.0177 (UTC) FILETIME=[576A6310:01CB7047] X-Brightmail-Tracker: AAAAAA== Subject: [Enum] Trilogy and IAX draft X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 11:08:31 -0000 Folks, I have just requested the approval of the last draft of the ENUM trilogy. I would like to thank the authors of the three drafts for their work on the last phases of the process. At this point, the next step for the WG is to revise the following draft so that it is compliant with the ENUM trilogy we have just approved. https://datatracker.ietf.org/doc/draft-ietf-enum-iax/ Thanks, Gonzalo From jon.peterson@neustar.biz Wed Oct 20 07:43:30 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E1F3A69F2 for ; Wed, 20 Oct 2010 07:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.948 X-Spam-Level: X-Spam-Status: No, score=-101.948 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq-S4EDMYAZK for ; Wed, 20 Oct 2010 07:42:52 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 5DD0C3A6912 for ; Wed, 20 Oct 2010 07:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1287585826; x=1602942826; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=4yZ9O6brm6feGqfBvClmM14AeDWVeTIjOjKMIY9lLA0=; b=HRvc+bSHRDt+B54sVHDjcfsJ43CkMqgR3sWwf7zfmPeM0/fSaCWBaTuCQ9pFAW /aNlEx3613gcqSWnk0cmx1VQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.38431407; Wed, 20 Oct 2010 10:43:45 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 20 Oct 2010 10:43:45 -0400 From: "Peterson, Jon" To: Lawrence Conroy , Richard Shockey Date: Wed, 20 Oct 2010 10:43:43 -0400 Thread-Topic: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt Thread-Index: ActvK94foukXcRT7Rd20EzfmrMFdHABOVMbA Message-ID: In-Reply-To: <805C6AC6-25A8-46CA-9B05-C37D5535066C@insensate.co.uk> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 9bJYrrmgwpAoYg/1SDL7IA== Content-Type: multipart/alternative; boundary="_000_C8E4785F46C0Djonpetersonneustarbiz_" MIME-Version: 1.0 Cc: IETF ENUM list Subject: Re: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:43:30 -0000 --_000_C8E4785F46C0Djonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lawrence, Thanks for these notes. Your editorial concerns will be fixed in the next r= evision. I'm not sure that dns-applications would be the right place to address Goog= le's pubic resolver, as the scope of this document is really the interplay = of applications and the DNS, and at least off the top of my head I don't se= e how the Google resolver is salient to that. In much the same way that iab= -dns-applications does not rule out DKIM's use of credentials in the DNS, i= nitially I don't think it should rule out the keyassure work either, which = in my opinion could turn out to be useful, although there are also paths wh= ere it could turn out not to be useful. The draft certainly does not suggest that HTTP and DNS are the same - merel= y that HTTP (or really any query-response protocol) can emulate the query-r= esponse semantics of the DNS. Obviously the two protocols are otherwise ver= y different. I think I do agree that the second bullet in the second set of bullets on p= age sixteen doesn't capture what we meant here, though instinctively there = must be some discouragement of excessive recursion. We'll try to find a mor= e exact way of stating that which doesn't seem to ban CNAME. We do want to = preserve concerns about redirecting between names in the DNS without DNSSEC= , though. While there are alternative technical solutions to many of the practices di= scussed in dns-applications, the issue the draft raises with send-n is its = "predictive" quality, the practice where one node in a tree tells resolvers= about the the state of nodes down the tree and the resulting synchronizati= on issues. Perhaps there are ways to approach send-n in the DNS that don't = exhibit this quality, but perhaps there are ways to do it outside of the DN= S entirely which require a lot less imagination. The draft doesn't attribute the story of ringtones in the DNS to any partic= ular source, and perhaps it is apocryphal, but that doesn't exempt it from = serving as an illustrative example of excessive data in the DNS. Jon Peterson NeuStar, Inc. On 10/18/10 6:20 PM, "Lawrence Conroy" wrote: Hi Richard, folks, ... and you're surprised, given the authorship ?)p This is a good document, it is needed, and I don't read it that states that= ENUM is a bad idea. Seriously, this had to be shipped today as it's a -00 draft, so it has some= rough edges. My initial notes on the draft are: - In 3.1, the end of the second sentence on page 8 "needs work". - The second sentence of section 3.3 on page 9 also needs work; 1464 applie= d the TXT record that was defined in 1035 for use for arbitrary data. 1464 = did NOT define the TXT record. - The last sentence in 4.1.1 on page 12 has "like" when I'd expect "likely"= . - The first sentence of 4.2 uses "surfaced" in a slightly odd way; maybe "r= aised" or "exposed"? - in section 4.2 on first paragraph of page 13, void should be replaced by = unused. (draft-ietf-enum-void is ancient; the last one was draft-ietf-enum-unused= -04.txt). - The second sentence of the second paragraph of 4.4 on page 14 starts with= a typo -- should be "In". - being picky, the second "bullet" of section 5 on page 16 could replace "a= re only depended on" with "only depend". - missing closing parentheses missing in third sentence of first paragraph = on page 18. ---- I await with interest the IAB's comments on the Google resolver proposals (= perhaps on page 12) and also on the keyassure work (apparently on page 17, if I decode= it correctly) -- after all, Phil *might* (eventually) get carpal if he's the only one to = fight those evil people. There are places where the authors' dry sense of humour made me laugh: - http (or TLS) is the same as DNS -- on page 17, second paragraph, - by implication, CNAME considered a bad sign (there, and earlier on page 1= 6, second "bullet" of the second set of items on page 16), - the thought that DKIM did NOT chose to use TXT records partially because = it was infeasible at the time to get an RR type while as the DKIM syntax and sem= antics was still crystallising (or that they had been through enough pain by tha= t point :) Send-n as currently written may be in the sights, but it is perfectly possi= ble to design a "number length" DNS tree that will be very heavily cached and uses the DN= S ability to scale and be information-dense (unlike almost any other protocol, even T= LS -- ha!). Whether that would use NAPTRs or just plain TXT records (like everyone else= ) is an entirely different question. It would avoid any need for standardisation in= the IETF, which may be the point. Finally, I really would like to find the bogey man who thought of putting r= ingtones in the DNS; I hear much talk of how bad this is, but no-one ever proposed d= oing such a perverse thing, AFAICT. all the best, Lawrence On 18 Oct 2010, at 21:57, Richard Shockey wrote: > > I'm reading this as the "ENUM is considered harmful to the DNS" or don't > even think about E2MD > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 18, 2010 2:45 PM > To: i-d-announce@ietf.org > Cc: iab@iab.org > Subject: I-D ACTION:draft-iab-dns-applications-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Internet Architecture Board Working Grou= p > of the IETF. > > Title : Architectural Considerations on Application > Features in the DNS > Author(s) : O. Kolkman, J. Peterson, H. Tschofenig, B. Aboba > Filename : draft-iab-dns-applications-00.txt > Pages : 23 > Date : 2010-10-18 > > While the principal purpose of the Domain Name System (DNS) is to > translate Internet domain names to IP addresses, over time a number > of Internet applications have integrated supplemental features into > the DNS to support their operations. Many of these features assist > in locating the appropriate service in a domain, or in transforming > intermediary identifiers into names that the DNS can process. > Proposals to piggyback more sophisticated application behavior on top > of the DNS, however, have raised questions about the propriety of > instantiating some features in the DNS, especially those with > security sensitivities. This document explores the architectural > consequences of installing application features in the DNS, and > provides guidance for future work in this area. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --_000_C8E4785F46C0Djonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt
Lawrence,

Thanks for these notes. Your editorial concerns will be fixed in the next r= evision.

I’m not sure that dns-applications would be the right place to addres= s Google’s pubic resolver, as the scope of this document is really th= e interplay of applications and the DNS, and at least off the top of my hea= d I don’t see how the Google resolver is salient to that. In much the= same way that iab-dns-applications does not rule out DKIM’s use of c= redentials in the DNS, initially I don’t think it should rule out the= keyassure work either, which in my opinion could turn out to be useful, al= though there are also paths where it could turn out not to be useful.

The draft certainly does not suggest that HTTP and DNS are the same –= merely that HTTP (or really any query-response protocol) can emulate the q= uery-response semantics of the DNS. Obviously the two protocols are otherwi= se very different.

I think I do agree that the second bullet in the second set of bullets on p= age sixteen doesn’t capture what we meant here, though instinctively = there must be some discouragement of excessive recursion. We’ll try t= o find a more exact way of stating that which doesn’t seem to ban CNA= ME. We do want to preserve concerns about redirecting between names in the = DNS without DNSSEC, though.

While there are alternative technical solutions to many of the practices di= scussed in dns-applications, the issue the draft raises with send-n is its = “predictive” quality, the practice where one node in a tree tel= ls resolvers about the the state of nodes down the tree and the resulting s= ynchronization issues. Perhaps there are ways to approach send-n in the DNS= that don’t exhibit this quality, but perhaps there are ways to do it= outside of the DNS entirely which require a lot less imagination.

The draft doesn’t attribute the story of ringtones in the DNS to any = particular source, and perhaps it is apocryphal, but that doesn’t exe= mpt it from serving as an illustrative example of excessive data in the DNS= .

Jon Peterson
NeuStar, Inc.


On 10/18/10 6:20 PM, "Lawrence Conroy" <lconroy@insensate.co.uk> wrote:

Hi Richard, folks,
 ... and you're surprised, given the authorship ?)p

This is a good document, it is needed, and I don't read it that states that= ENUM
is a bad idea.

Seriously, this had to be shipped today as it's a -00 draft, so it has some= rough edges.

My initial notes on the draft are:

- In 3.1, the end of the second sentence on page 8 "needs work".<= BR>
- The second sentence of section 3.3 on page 9 also needs work; 1464 applie= d
  the TXT record that was defined in 1035 for use for arbitrary d= ata. 1464 did
  NOT define the TXT record.

- The last sentence in 4.1.1 on page 12 has "like" when I'd expec= t "likely".

- The first sentence of 4.2 uses "surfaced" in a slightly odd way= ; maybe "raised"
  or "exposed"?

- in section 4.2 on first paragraph of page 13, void should be replaced by = unused.
  (draft-ietf-enum-void is ancient; the last one was draft-ietf-e= num-unused-04.txt).

- The second sentence of the second paragraph of 4.4 on page 14 starts with= a typo
  -- should be "In".

- being picky, the second "bullet" of section 5 on page 16 could = replace "are only
  depended on" with "only depend".

- missing closing parentheses missing in third sentence of first paragraph = on page 18.

----

I await with interest the IAB's comments on the Google resolver proposals (= perhaps on
page 12) and also on the keyassure work (apparently on page 17, if I decode= it correctly)
-- after all, Phil *might* (eventually) get carpal if he's the only one to = fight those
evil people.

There are places where the authors' dry sense of humour made me laugh:

- http (or TLS) is the same as DNS -- on page 17, second paragraph,

- by implication, CNAME considered a bad sign (there, and earlier on page 1= 6, second
  "bullet" of the second set of items on page 16),

- the thought that DKIM did NOT chose to use TXT records partially because = it was
  infeasible at the time to get an RR type while as the DKIM synt= ax and semantics
  was still crystallising (or that they had been through enough p= ain by that point :)

Send-n as currently written may be in the sights, but it is perfectly possi= ble to design
a "number length" DNS tree that will be very heavily cached and u= ses the DNS ability
to scale and be information-dense (unlike almost any other protocol, even T= LS -- ha!).
Whether that would use NAPTRs or just plain TXT records (like everyone else= ) is an
entirely different question. It would avoid any need for standardisation in= the IETF,
which may be the point.

Finally, I really would like to find the bogey man who thought of putting r= ingtones
in the DNS; I hear much talk of how bad this is, but no-one ever proposed d= oing such
a perverse thing, AFAICT.

all the best,
  Lawrence


On 18 Oct 2010, at 21:57, Richard Shockey wrote:

>
> I'm reading this as the "ENUM is considered harmful to the DNS&qu= ot; or don't
> even think about E2MD
>
> -----Original Message-----
> From: i-d-announce-bounces@i= etf.org [mailto:i-d-an= nounce-bounces@ietf.org]
> On Behalf Of Internet-Drafts@ietf= .org
> Sent: Monday, October 18, 2010 2:45 PM
> To: i-d-announce@ietf.org
> Cc: iab@iab.org
> Subject: I-D ACTION:draft-iab-dns-applications-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Internet Architecture Board Working G= roup
> of the IETF.
>
>       Title     &nbs= p;     : Architectural Considerations on Applicati= on
> Features in the DNS
>       Author(s)     =   : O. Kolkman, J. Peterson, H. Tschofenig, B. Aboba
>       Filename     &= nbsp;  : draft-iab-dns-applications-00.txt
>       Pages     &nbs= p;     : 23
>       Date      = ;      : 2010-10-18
>      
> While the principal purpose of the Domain Name System (DNS) is to
>   translate Internet domain names to IP addresses, over time= a number
>   of Internet applications have integrated supplemental feat= ures into
>   the DNS to support their operations.  Many of these f= eatures assist
>   in locating the appropriate service in a domain, or in tra= nsforming
>   intermediary identifiers into names that the DNS can proce= ss.
>   Proposals to piggyback more sophisticated application beha= vior on top
>   of the DNS, however, have raised questions about the propr= iety of
>   instantiating some features in the DNS, especially those w= ith
>   security sensitivities.  This document explores the a= rchitectural
>   consequences of installing application features in the DNS= , and
>   provides guidance for future work in this area.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-iab-dns-applications-= 00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/int= ernet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www.iet= f.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
https://www.ietf.org= /mailman/listinfo/enum

--_000_C8E4785F46C0Djonpetersonneustarbiz_-- From wwwrun@core3.amsl.com Wed Oct 20 08:03:26 2010 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 33F3D3A6827; Wed, 20 Oct 2010 08:03:26 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101020150326.33F3D3A6827@core3.amsl.com> Date: Wed, 20 Oct 2010 08:03:26 -0700 (PDT) Cc: enum mailing list , enum chair , Internet Architecture Board , RFC Editor Subject: [Enum] Protocol Action: 'IANA Registration of Enumservices: Guide, Template and IANA Considerations' to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:03:26 -0000 The IESG has approved the following document: - 'IANA Registration of Enumservices: Guide, Template and IANA Considerations ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-22.txt 1 - Technical Summary E.164 Number Mapping (ENUM) provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers. This document updates RFC 3761 as part of a suite of including rfc3761bis and a transition mechanism for the existing IANA registry. One of the primary concepts of ENUM is the definition of "Enumservices", which allows for providing different URIs for different applications of said mapping mechanism. This document specifies a revision of the IANA Registry for Enumservices, which was originally described in [RFC 3761]. The new registration processes have been specifically designed to be decoupled from the existence of the ENUM working group. 2 - Working Group Summary Was there anything in the discussion in the interested community that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Was the document considered in any WG, and if so, why was it not adopted as a work item there? There was extensive discussion on the alternatives for various processes involved in the Enumservices registration including what would constitute Expert Review in this context. The goal was to have a formal process in place to enable the closure of the ENUM WG. 3 - Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Rfc 3761 is globally deployed in multiple contexts and the existing Enumservice registry has received extensive use. This new procedure should simplify the process considerably. 4 – Personnel Document Shepherd: Richard Shockey Responsible AD: Gonzalo Camarillo From jim@rfc1035.com Wed Oct 20 08:08:53 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3806C3A67EF for ; Wed, 20 Oct 2010 08:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNM05iAOyj1s for ; Wed, 20 Oct 2010 08:08:52 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id F23E63A67D3 for ; Wed, 20 Oct 2010 08:08:51 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id D993E1542053; Wed, 20 Oct 2010 16:10:23 +0100 (BST) Message-Id: <6D8759AF-2F7E-4643-BDFC-7C13E9D5D175@rfc1035.com> From: Jim Reid To: "Peterson, Jon" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 20 Oct 2010 16:10:23 +0100 References: X-Mailer: Apple Mail (2.936) Cc: IETF ENUM list , Lawrence Conroy Subject: [Enum] excessive data in the DNS X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:08:53 -0000 On 20 Oct 2010, at 15:43, Peterson, Jon wrote: > The draft doesn't attribute the story of ringtones in the DNS to any > particular source, and perhaps it is apocryphal, but that doesn't > exempt it from serving as an illustrative example of excessive data > in the DNS. Jon, I simply don't know what you mean here. Please define "excessive", preferably with objective qualitative and quantitative metrics. There are plenty of examples of stupid and/or pointless data in the DNS. [My favourite was a text-based adventure game.] But who gets to decide what's stupid and pointless? Or if those things are excessive? We may well agree that ringtones in the DNS are a possibly apocryphal example of "excessive" data. However the people who put that data there and those who consume those ringtones would presumably disagree with that view. And they'd be right. If whatever they're doing to the DNS works for them and isn't harming others, who are we to judge? For some definition of we... From jon.peterson@neustar.biz Wed Oct 20 10:30:49 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31383A68B8 for ; Wed, 20 Oct 2010 10:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.724 X-Spam-Level: X-Spam-Status: No, score=-99.724 tagged_above=-999 required=5 tests=[AWL=-2.126, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqWDB9Nzd5c5 for ; Wed, 20 Oct 2010 10:30:42 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id D789E3A68F6 for ; Wed, 20 Oct 2010 10:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1287595932; x=1602955320; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=agRiTlyKaKG7nH0k09QXzUBifVZ75KHzlQ7MsxJ2uYc=; b=n5oaPUdMMrQQ1svBxTbzMUd+ptSU1qrW6WYzPtHW652ISEc9tGVIXtN6cOOxhi fUwimAympiRlbMAF3WPFW8Kw== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.32732796; Wed, 20 Oct 2010 13:32:11 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 20 Oct 2010 13:32:10 -0400 From: "Peterson, Jon" To: Jim Reid Date: Wed, 20 Oct 2010 13:32:09 -0400 Thread-Topic: excessive data in the DNS Thread-Index: ActwaO/5aue/qJCuRuqS/iMRNzjBfQAE8jnN Message-ID: In-Reply-To: <6D8759AF-2F7E-4643-BDFC-7C13E9D5D175@rfc1035.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 5sw4iCpwJfXUAujllAbCPg== Content-Type: multipart/alternative; boundary="_000_C8E49FD946C48jonpetersonneustarbiz_" MIME-Version: 1.0 Cc: IETF ENUM list , Lawrence Conroy Subject: Re: [Enum] excessive data in the DNS X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:30:49 -0000 --_000_C8E49FD946C48jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of the challenges of reaching architectural principles for the guidance= on using DNS as a generic database is wrapping measurable parameters aroun= d concepts like "excessive", I agree. We do understand what it means for a = label to be excessive, and give numbers for that in the draft. For the data= part of a resource record, that probably has a variety of caveats and depe= ndencies. I've certainly seen pages of ASCII art in TXT records before that= didn't seem to bring the Internet to its knees. Since a lot of the potenti= al for generic NAPTR data comes from the potential use of data URLs, it is = worth pointing out that the data URL RFC contains the following text: The "data:" URL scheme is only useful for short values. Note that some applications that use URLs may impose a length limit; for example, URLs embedded within anchors in HTML have a length limit determined by the SGML declaration for HTML RFC1866. The LITLEN (1024) limits the number of characters which can appear in a single attribute value literal, the ATTSPLEN (2100) limits the sum of all lengths of all attribute value specifications which appear in a tag, and the TAGLEN (2100) limits the overall length of a tag. Perhaps in later versions of the document we could call out this text speci= fically, although it doesn't define "short values" in a way that will give = you a hard litmus test. We also have to consider what implementations will = realistically accommodate. We need to consider that implementations out the= re use very large data URLs today - for example, I understand some iPhone h= acks encode multi-megabyte .pdf files as data URLs. If one of those ended u= p in the DNS, would your resolver parse it or die? If the resolver survives= , would the application that receives it from the resolver survive? I'm sur= e that some people could put that data in the DNS with particular resolver = implementations in mind that would survive and relay the data properly. Wha= t happens, though, when someone outside of that community tries to access i= t? Jon Peterson NeuStar, Inc. On 10/20/10 11:10 AM, "Jim Reid" wrote: On 20 Oct 2010, at 15:43, Peterson, Jon wrote: > The draft doesn't attribute the story of ringtones in the DNS to any > particular source, and perhaps it is apocryphal, but that doesn't > exempt it from serving as an illustrative example of excessive data > in the DNS. Jon, I simply don't know what you mean here. Please define "excessive", preferably with objective qualitative and quantitative metrics. There are plenty of examples of stupid and/or pointless data in the DNS. [My favourite was a text-based adventure game.] But who gets to decide what's stupid and pointless? Or if those things are excessive? We may well agree that ringtones in the DNS are a possibly apocryphal example of "excessive" data. However the people who put that data there and those who consume those ringtones would presumably disagree with that view. And they'd be right. If whatever they're doing to the DNS works for them and isn't harming others, who are we to judge? For some definition of we... --_000_C8E49FD946C48jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: excessive data in the DNS
One of the challenges of reaching architectural principles for the guidance= on using DNS as a generic database is wrapping measurable parameters aroun= d concepts like “excessive”, I agree. We do understand what it = means for a label to be excessive, and give numbers for that in the draft. = For the data part of a resource record, that probably has a variety of cave= ats and dependencies. I’ve certainly seen pages of ASCII art in TXT r= ecords before that didn’t seem to bring the Internet to its knees. Si= nce a lot of the potential for generic NAPTR data comes from the potential = use of data URLs, it is worth pointing out that the data URL RFC contains t= he following text:

   The "data:" URL scheme is only useful for short= values. Note that
   some applications that use URLs may impose a length limit= ; for
   example, URLs embedded within <A> anchors in HTML h= ave a length limit
   determined by the SGML declaration for HTML RFC1866. The = LITLEN
   (1024) limits the number of characters which can appear i= n a single
   attribute value literal, the ATTSPLEN (2100) limits the s= um of all
   lengths of all attribute value specifications which appea= r in a tag,
   and the TAGLEN (2100) limits the overall length of a tag.=

Perhaps in later versions of the document we could call out this text speci= fically, although it doesn’t define “short values” in a w= ay that will give you a hard litmus test. We also have to consider what imp= lementations will realistically accommodate. We need to consider that imple= mentations out there use very large data URLs today – for example, I = understand some iPhone hacks encode multi-megabyte .pdf files as data URLs.= If one of those ended up in the DNS, would your resolver parse it or die? = If the resolver survives, would the application that receives it from the r= esolver survive? I’m sure that some people could put that data in the= DNS with particular resolver implementations in mind that would survive an= d relay the data properly. What happens, though, when someone outside of th= at community tries to access it?

Jon Peterson
NeuStar, Inc.


On 10/20/10 11:10 AM, "Jim Reid" <= jim@rfc1035.com> wrote:

On 20 Oct 2010, at 15:43, Peterson, Jon wro= te:

> The draft doesn't attribute the story of ringtones in the DNS to any <= BR> > particular source, and perhaps it is apocryphal, but that doesn't
> exempt it from serving as an illustrative example of excessive data > in the DNS.

Jon, I simply don't know what you mean here. Please define
"excessive", preferably with objective qualitative and quantitati= ve
metrics. There are plenty of examples of stupid and/or pointless data
in the DNS. [My favourite was a text-based adventure game.] But who
gets to decide what's stupid and pointless? Or if those things are
excessive?

We may well agree that ringtones in the DNS are a possibly apocryphal
example of "excessive" data. However the people who put that data=
there and those who consume those ringtones would presumably disagree
with that view. And they'd be right. If whatever they're doing to the
DNS works for them and isn't harming others, who are we to judge? For
some definition of we...

--_000_C8E49FD946C48jonpetersonneustarbiz_-- From lconroy@insensate.co.uk Wed Oct 20 10:52:52 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78E43A68FE for ; Wed, 20 Oct 2010 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.749 X-Spam-Level: X-Spam-Status: No, score=0.749 tagged_above=-999 required=5 tests=[AWL=-1.652, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEGw2gqEXk0v for ; Wed, 20 Oct 2010 10:52:51 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 0D8103A68A0 for ; Wed, 20 Oct 2010 10:52:50 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 7159D70AB7E; Wed, 20 Oct 2010 18:54:23 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Wed, 20 Oct 2010 18:54:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1081) Cc: IETF ENUM list , Jim Reid Subject: Re: [Enum] excessive data in the DNS X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:52:52 -0000 Hi Jon, Jim, folks, If we're talking about URLs in NAPTRs, these have to be in the REGEXP = field, and that gives a hard limit of 255 bytes. In practice, with the limits to the = REGEXP field content and the data: URL's syntax, we're really talking about a lot less for = useful binary data. See the x-crypto draft for the gory details. I guess you might string a set of NAPTRs together, each holding a small = chunk of stuff inside a data: URL, and using the ORDER/PREF fields to defined the = sequence in which the payloads were to be stitched together, but that's waaaay beyond = sensible. For a single NAPTR, this is not a realistic problem, IMHO. That's why I = have remained skeptical of concerns over data: URLs inside NAPTRs; the field a data = URL must inhabit is severely restricted. Sure, one can bulk up NAPTRs (e.g. using full = blown 3GPP-compliant SIP URLs) and have a lot of them in a domain (speaking of different = identities a la 3GPP) but for individual NAPTRs, they simply can't be that big. TXT is much "better" for that kind of bulk. With due deference to Jim, I = still think that putting a ringtone in the DNS is perverse; consenting adults or = not, DNS is hardly in the privacy of one's own home. all the best, Lawrence On 20 Oct 2010, at 18:32, Peterson, Jon wrote: > One of the challenges of reaching architectural principles for the = guidance on using DNS as a generic database is wrapping measurable = parameters around concepts like "excessive", I agree. We do understand = what it means for a label to be excessive, and give numbers for that in = the draft. For the data part of a resource record, that probably has a = variety of caveats and dependencies. I've certainly seen pages of ASCII = art in TXT records before that didn't seem to bring the Internet to its = knees. Since a lot of the potential for generic NAPTR data comes from = the potential use of data URLs, it is worth pointing out that the data = URL RFC contains the following text: >=20 > The "data:" URL scheme is only useful for short values. Note that > some applications that use URLs may impose a length limit; for > example, URLs embedded within anchors in HTML have a length = limit > determined by the SGML declaration for HTML RFC1866. The LITLEN > (1024) limits the number of characters which can appear in a single > attribute value literal, the ATTSPLEN (2100) limits the sum of all > lengths of all attribute value specifications which appear in a tag, > and the TAGLEN (2100) limits the overall length of a tag. >=20 > Perhaps in later versions of the document we could call out this text = specifically, although it doesn't define "short values" in a way that = will give you a hard litmus test. We also have to consider what = implementations will realistically accommodate. We need to consider that = implementations out there use very large data URLs today - for example, = I understand some iPhone hacks encode multi-megabyte .pdf files as data = URLs. If one of those ended up in the DNS, would your resolver parse it = or die? If the resolver survives, would the application that receives it = from the resolver survive? I'm sure that some people could put that data = in the DNS with particular resolver implementations in mind that would = survive and relay the data properly. What happens, though, when someone = outside of that community tries to access it? >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > On 10/20/10 11:10 AM, "Jim Reid" wrote: >=20 > On 20 Oct 2010, at 15:43, Peterson, Jon wrote: >=20 >> The draft doesn't attribute the story of ringtones in the DNS to any >> particular source, and perhaps it is apocryphal, but that doesn't >> exempt it from serving as an illustrative example of excessive data >> in the DNS. >=20 > Jon, I simply don't know what you mean here. Please define > "excessive", preferably with objective qualitative and quantitative > metrics. There are plenty of examples of stupid and/or pointless data > in the DNS. [My favourite was a text-based adventure game.] But who > gets to decide what's stupid and pointless? Or if those things are > excessive? >=20 > We may well agree that ringtones in the DNS are a possibly apocryphal > example of "excessive" data. However the people who put that data > there and those who consume those ringtones would presumably disagree > with that view. And they'd be right. If whatever they're doing to the > DNS works for them and isn't harming others, who are we to judge? For > some definition of we... >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed Oct 20 13:47:22 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665EC3A6914 for ; Wed, 20 Oct 2010 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCdyjByB459K for ; Wed, 20 Oct 2010 13:47:21 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 51BB53A67A7 for ; Wed, 20 Oct 2010 13:47:21 -0700 (PDT) Received: (qmail 24365 invoked by uid 0); 20 Oct 2010 20:48:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 20 Oct 2010 20:48:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Uk2iT+kAEQLmE0sigf0/g/w2FnyXjgSbp6C6LzVk37CdL10TmjjJ7q2eWh+nZWmLXEg3h1BglHuMs6eHqpOxrIsJpbQQ9pBV6+xhTNgQEzKvlw+fAZcVzuC82nAA97l/; Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P8fag-000410-Lv for enum@ietf.org; Wed, 20 Oct 2010 14:48:54 -0600 From: "Richard Shockey" To: "'IETF ENUM list'" Date: Wed, 20 Oct 2010 16:48:52 -0400 Message-ID: <010a01cb7098$34a26930$9de73b90$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Actwjxs/D6uXk9TwTpCQNclYIYDrJQAAu+RgAAGENrA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us} Subject: [Enum] FW: draft-iab-dns-applications - clarification re: Send-N X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:47:22 -0000 IN case you folks didn't see this ..the discussion moved over to the full IETF discuss list. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, October 20, 2010 4:47 PM To: 'bill manning' Cc: 'Ray Bellis'; draft-iab-dns-applications@tools.ietf.org; ietf@ietf.org Subject: RE: draft-iab-dns-applications - clarification re: Send-N Well Bill with due respect, the data that most of us would like to use for this class of application is very static and its sources are very authoritative. That which is somewhat volatile is easy to sync such as Local Number Portability data or line status. There is a staggering amount of data in the field that Infrastructure oriented ENUM works and works well in the field. Speed and scale were the keys and the desire NOT to have another protocol stack in mission critical network elements such as the CSCF or SBC at the edge of the SIP/IMS networks. But the larger issue is this. When the ENUM WG was rechartered it was explicit that this class of application was in scope. Now for some inexplicable reason its out of scope. I want to know why. "3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data." As a practical matter the horse has left the barn, mated, now has several foals. This document is a terrible attempt at an ex post facto architectural decision that is significantly damaging to those of us who want to make things in SIP work better. As a practical matter I want to know are all of these proposals for PSTN metadata, trunk group, SPID, source URI etc are now out of scope for IETF standardization. Even as private deployments? If so than the IESG and the IAB should say so explicitly now and not waste our time in Prague on a BOF that will never be chartered. I personally find section 5.1 unusually amusing as if now the IAB wants to say split-DNS "should be considered harmful". Leakage in to the public DNS .. geez really. Like what where are the examples of the harm? So who put ringtones in the DNS :-) -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of bill manning Sent: Wednesday, October 20, 2010 3:43 PM To: Richard Shockey Cc: 'Ray Bellis'; draft-iab-dns-applications@tools.ietf.org; ietf@ietf.org Subject: Re: draft-iab-dns-applications - clarification re: Send-N while I agree that the hierarchical and distributed nature of the DNS is a scintillating, shimmering attractant, it is wise to be aware of the baseline assumption in your arguement, e.g. that a client will -ALWAYS- ask an authoritative source... The DNS is so designed that caching is a huge component of the scalability of the DNS... and its greatest hinderance for such ideas as are laid out in the ENUM dip lookup. You can't be assured that the data is timely. This is a strong reason to consider that the DNS is _NOT_ the droid you are looking for, in spite of its other attractive qualities. just my 0.02 lira. --bill On 20October2010Wednesday, at 12:25, Richard Shockey wrote: > > And finally, regarding: > > "It is unclear why this data is better maintained by the DNS > than in an unrelated application protocol." > > If a device is performing an ENUM dip hoping to find a contactable SIP URI, > it is simply most efficient for the ENUM response to directly include the > Send-N metadata when needed rather than have separate queries using a > different network protocol. Also, the hierarchical and distributed nature > of the DNS protocol makes it an _ideal_ structural fit for this meta data. > > I believe the onus should be on your draft to explicitly identify valid > technical reasons why the DNS protocol should _not_ be used, rather than > make vague hand-waving assertions which appear to have little or no > justification. > > > > RS> Precisely, What is unclear is why the IETF and the IAB is suddenly > trying to block a perfectly legitimate extension of RFC 3761 that is in > various forms of global deployment, proven to work, scale and more > importantly provides a valuable and essential function in the transition > from analog POTS to SIP based communication. > > Just saying no is not a solution to the real issues of number translation in > carrier networks. > > Ok a lot of people hate phone numbers including, it seems, 50% of RAI > directorate but they are not going away anytime soon. > > So just say it .. is this the message? Don't even try to charter E2MD? > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From bernie@ietf.hoeneisen.ch Mon Oct 25 11:01:01 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB3C3A68B0 for ; Mon, 25 Oct 2010 11:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcOklFeq1GUI for ; Mon, 25 Oct 2010 11:01:00 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 0D36E3A67FA for ; Mon, 25 Oct 2010 11:01:00 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1PARN7-0003bl-Dz for enum@ietf.org; Mon, 25 Oct 2010 20:02:44 +0200 Date: Mon, 25 Oct 2010 20:02:13 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF ENUM list Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [Enum] Call for Community Feedback on Willing Nominees (fwd) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 18:01:01 -0000 Hi, The IETF NomCom chair asks the community for feedback on nominees. NomCom selects the management positions of the IETF, i.e. IAB, IESG, IETF chair, and IAOC. Those people who get selected to management positions decide on important questions concerning the IETF. Your feedback to NomCom ensures that the NomCom has all the information they need to select reasonable people to the management positions. The details on how to provide feedback you can find below. Happy feedback:ing! cheers, Bernie (who was a voting member in NomCom 2008/09) -- http://ucom.ch/ Tech Consulting for Internet Standardization ---------- Forwarded message ---------- Date: Mon, 18 Oct 2010 18:01:32 From: NomCom Chair To: IETF Announcement list Subject: Call for Community Feedback on Willing Nominees Call for Community Feedback on Willing Nominees Per RFC 5680, NomCom 2010-2011 is issuing a call to the entire IETF community for feedback on the Willing Nominees for the open IETF positions. Nominations closed on October 8 and the list of willing nominees is now quite stable. What is feedback? ================= Feedback is information you think will help NomCom make a decision on selecting candidates for open IETF positions. Feedback should be based on information you know first hand about an individual nominee. Review the list of willing nominees and open positions ====================================================== Familiarize yourself with the list of IETF open positions at https://wiki.tools.ietf.org/group/nomcom/10/ Then familiarize yourself with the list of willing nominees at at https://wiki.tools.ietf.org/group/nomcom/10/input/ If you need a username/password to see the list of willing nominees it is very easy to obtain at http://tools.ietf.org/ Just select "Get Passwd" from the left margin and follow the instructions. How to Provide feedback to NomCom ================================= Simply use one of the following methods: - The best method is to enter it directly on the NomCom Wiki https://wiki.tools.ietf.org/group/nomcom/10/. Then select ?Provide Comments? making sure you correctly select the nominee and position from the pull down menu. - Or send an email to nomcom10@ietf.org and be sure to identify the nominee and position the feedback pertains to. - Or contact one (or more) of the NomCom members by email or in Beijing. You may also provide anonymous feedback by contacting one of the NomCom members who will anonymize it for the rest of the members. NomCom would like to thank all those who submitted nominations, and all the nominees for their consideration of the various positions to which they have been nominated. Thomas Walsh Chair, NomCom 2010-2011 nomcom-chair@ietf.org twalsh@juniper.net From lconroy@insensate.co.uk Tue Oct 26 11:25:27 2010 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975A73A6877 for ; Tue, 26 Oct 2010 11:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uRkfBhSCU6G for ; Tue, 26 Oct 2010 11:25:26 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 839B03A67F9 for ; Tue, 26 Oct 2010 11:25:26 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id D1D777457E3 for ; Tue, 26 Oct 2010 19:27:12 +0100 (BST) From: Lawrence Conroy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2010 19:27:12 +0100 References: To: IETF ENUM list Message-Id: <8E3A98FF-499F-42CF-BC8E-4663735C0BA3@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Enum] Fwd: draft-iab-dns-applications X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 18:25:27 -0000 Hi Folks, for those of you avoiding the stream of consciousness that is the IETF = general list, here's some apposite info. with apologies to those who now have this twice (or already knew this) all the best Lawrence Begin forwarded message: > From: Bernard Aboba > Date: 26 October 2010 00:44:13 GMT+01:00 > To: > Subject: Re: draft-iab-dns-applications >=20 > BTW, IAB documents are now included in TRAC, so that it is now = possible to > enter a comment or issue from the following link: >=20 > http://trac.tools.ietf.org/group/iab/trac/newticket >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf