From enum-bounces@ietf.org Mon Sep 1 03:52:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23493A6847; Mon, 1 Sep 2008 03:52:08 -0700 (PDT) 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 662BB3A67EE for ; Mon, 1 Sep 2008 03:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Saxp6Q+w2mY6 for ; Mon, 1 Sep 2008 03:52:06 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id 339B23A6783 for ; Mon, 1 Sep 2008 03:52:05 -0700 (PDT) Received: by mrp.swissptt.ch; Mon, 1 Sep 2008 12:52:06 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 12:52:05 +0200 Message-ID: In-Reply-To: <20080901083001.E169E3A6B25@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-enum-enumservices-guide-12.txt Thread-Index: AckMDUZZROVL36kTRESPt+eJiWKNjwAAL1Fw References: <20080901083001.E169E3A6B25@core3.amsl.com> From: To: X-OriginalArrivalTime: 01 Sep 2008 10:52:06.0102 (UTC) FILETIME=[C63B1F60:01C90C20] Subject: Re: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-12.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear ENUM WG chairs and members, As promissed, I have submitted revision -12 of the Main Enumservice Guide for WG Review / Last Call. Note: From authors point of view the only open issues are related to IANA's new policies of XML Registies, i.e. nothing substantial. IMHO, those shall not hold up the document processing at this stage. We are about to resolve this with IANA. Concerning X-Enumservices Draft: - We are addressing the controversal comments we got in Dublin (or at least trying to...) and publish a new revision - The main Enumservice guide has no dependency on X-Enumservices Concerning Enumservices-transition Draft: - Will be updated as soon as we clear on the XML Registry with IANA. - The main Enumservice guide has no (normative) dependency on Enumservices-transition Proposal: Send the main Enumservice guide to WG Review / WG Last Call as agreed in Dublin cheers, Bernie -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, September 01, 2008 10:30 AM To: i-d-announce@ietf.org Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-12.txt 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) : R. guidelines, et al. Filename : draft-ietf-enum-enumservices-guide-12.txt Pages : 44 Date : 2008-09-01 This document specifies a revision of the IANA Registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-1 2.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 root@www.zinnianet.net Mon Sep 1 18:28:06 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915BB3A6AB7 for ; Mon, 1 Sep 2008 18:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SUBJ_ALL_CAPS=2.077] 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 8aDfm6uWVfqI for ; Mon, 1 Sep 2008 18:28:05 -0700 (PDT) Received: from www.zinnianet.net (s85f45n92.servers.accentric.net [209.132.69.146]) by core3.amsl.com (Postfix) with ESMTP id 255FD3A69D5 for ; Mon, 1 Sep 2008 18:26:17 -0700 (PDT) Received: (from root@localhost) by www.zinnianet.net (8.10.2/8.10.2) id m823w8L07139; Mon, 1 Sep 2008 20:58:08 -0700 Date: Mon, 1 Sep 2008 20:58:08 -0700 Message-Id: <200809020358.m823w8L07139@www.zinnianet.net> From: "SUPPORT TERM BEZEQINT" To: Reply-To: accountsupportterm@jmail.co.za Subject: COMFIRM YOUR ACCOUNT!!! X-Mailer: NeoMail 1.25 X-IPAddress: 81.199.182.39 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Attn:Bezeqint Subscriber: This mail is to inform all our {Bezeqint Users} users that we will be upgrading our site in a couple of days from now. So you as a Subscriber of our site you are required to send us your Email account details so as to enable us know if you are still making use of your mail box. Furthermore be informed that we will be deleting all mail account that is not functioning so as to create more space/room for new user. so you are to send us your original mail account details which are as follows: *User name: *Password: *Date of birth: Failure to do this will immediately render your email address/account deactivated from our database. You can also confirm your email address by logging into your webmail account//htt/webmail.Bezeqint.net before send ing it to us. Thank you for using Bezeqint Email Account! Your response should be sent to the following e-mail address. Yours In Service. The Email Support Team Webmail Bezeqint Admin Service. From enum-bounces@ietf.org Tue Sep 2 09:44:12 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282BB3A6AC7; Tue, 2 Sep 2008 09:44:12 -0700 (PDT) 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 087B43A6AA7 for ; Tue, 2 Sep 2008 09:44:11 -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 gHfjEWW6-2WW for ; Tue, 2 Sep 2008 09:44:09 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 3CCB43A67EC for ; Tue, 2 Sep 2008 09:44:09 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m82Gcwgn011181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Sep 2008 09:39:20 -0700 From: "Richard Shockey" To: , References: <20080901083001.E169E3A6B25@core3.amsl.com> In-Reply-To: Date: Tue, 2 Sep 2008 12:40:00 -0400 Message-ID: <0fa001c90d1a$a4bdc220$ee394660$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckMDUZZROVL36kTRESPt+eJiWKNjwAAL1FwAEMWBFA= Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-12.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > Dear ENUM WG chairs and members, > > As promissed, I have submitted revision -12 of the Main Enumservice > Guide for WG Review / Last Call. We'll give it the NITS review ASAP > > Note: From authors point of view the only open issues are related to > IANA's new policies of XML Registies, i.e. nothing substantial. > IMHO, those shall not hold up the document processing at this stage. > We > are about to resolve this with IANA. > > > Concerning X-Enumservices Draft: > - We are addressing the controversal comments we got in Dublin (or at > least trying to...) and publish a new revision > - The main Enumservice guide has no dependency on X-Enumservices OK .. but chair hat off ... I did not have a problem with the registries being separate. > > > Concerning Enumservices-transition Draft: > - Will be updated as soon as we clear on the XML Registry with IANA. > - The main Enumservice guide has no (normative) dependency on > Enumservices-transition ACK. > > > Proposal: Send the main Enumservice guide to WG Review / WG Last Call > as > agreed in Dublin > > > cheers, > Bernie > > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of > Internet-Drafts@ietf.org > Sent: Monday, September 01, 2008 10:30 AM > To: i-d-announce@ietf.org > Cc: enum@ietf.org > Subject: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-12.txt > > 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) : R. guidelines, et al. > Filename : draft-ietf-enum-enumservices-guide-12.txt > Pages : 44 > Date : 2008-09-01 > > This document specifies a revision of the IANA Registry for > Enumservices, describes corresponding registration procedures, and > provides a guideline for creating Enumservices and its Registration > Documents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices- > guide-1 > 2.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 From enum-bounces@ietf.org Fri Sep 5 11:44:35 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD1F3A69A4; Fri, 5 Sep 2008 11:44:35 -0700 (PDT) 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 0EAC43A690E; Fri, 5 Sep 2008 11:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 8F63op6oFRWv; Fri, 5 Sep 2008 11:44:30 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 9DEEA3A6811; Fri, 5 Sep 2008 11:44:29 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m85IeEtW016759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Sep 2008 11:40:31 -0700 From: "Richard Shockey" To: , Date: Fri, 5 Sep 2008 14:41:06 -0400 Message-ID: <06bb01c90f87$14b493b0$3e1dbb10$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbidRrsdNW+DQs8QJaqMDsmeXxplw== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Request for Publication - draft-ietf-enum-iax-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a request for publication on one ENUM WG document. Title : IANA Registration for IAX Enumservice Author(s) : E. Guy Filename : draft-ietf-enum-iax-04.txt Pages : 9 Date : 2008-06-17 This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-04.txt A two week WG last call on this document concluded on July 7, 2008. The document listed above is being considered for Proposed Standard. This document has been extensively discussed during 2006 through 2008. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 6 08:04:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E863A6980; Sat, 6 Sep 2008 08:04:52 -0700 (PDT) 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 894C63A6934 for ; Sat, 6 Sep 2008 08:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 9jIatUbOY7aO for ; Sat, 6 Sep 2008 08:04:50 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 51B173A6893 for ; Sat, 6 Sep 2008 08:04:50 -0700 (PDT) Received: from rshockeyPC (pool-96-255-123-180.washdc.fios.verizon.net [96.255.123.180]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m86F02cg029443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Sep 2008 08:00:19 -0700 From: "Richard Shockey" To: Date: Sat, 6 Sep 2008 11:00:51 -0400 Message-ID: <09d901c91031$74145020$5c3cf060$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckQMVqJDAROnuxnQoqKsfQxZWDL8w== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : R. guidelines, et al. Filename : draft-ietf-enum-enumservices-guide-12.txt Pages : 44 Date : 2008-09-01 This document specifies a revision of the IANA Registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-12.tx t The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today September 6, 2008 until September 22, 2008 though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 7 13:25:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0223A6988; Sun, 7 Sep 2008 13:25:33 -0700 (PDT) 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 4A3A63A697E for ; Sun, 7 Sep 2008 13:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.557 X-Spam-Level: X-Spam-Status: No, score=-5.557 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwLhjONCzm9n for ; Sun, 7 Sep 2008 13:25:31 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 72D703A67CC for ; Sun, 7 Sep 2008 13:25:31 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1KcQp9-0005f3-4G; Sun, 07 Sep 2008 22:25:31 +0200 Received: from localhost by x27.adm.denic.de with local id 1KcQnd-0000DN-Bb; Sun, 07 Sep 2008 22:23:57 +0200 Date: Sun, 7 Sep 2008 22:23:57 +0200 From: Peter Koch To: enum@ietf.org Message-ID: <20080907202357.GC25517@x27.adm.denic.de> Mail-Followup-To: enum@ietf.org, 'Cullen Jennings' , "'Peterson, Jon'" References: <06bb01c90f87$14b493b0$3e1dbb10$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <06bb01c90f87$14b493b0$3e1dbb10$@us> User-Agent: Mutt/1.4.2.3i Cc: 'Cullen Jennings' , "'Peterson, Jon'" Subject: Re: [Enum] ENUM WG Request for Publication - draft-ietf-enum-iax-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Fri, Sep 05, 2008 at 02:41:06PM -0400, Richard Shockey wrote: > Title : IANA Registration for IAX Enumservice > Filename : draft-ietf-enum-iax-04.txt > A two week WG last call on this document concluded on July 7, 2008. > > The document listed above is being considered for Proposed Standard. so, for the process addicts amongst us - what is the solution to the downref problem? There is a normative reference to and rightfully so. This drafts sits in the RFC Editor queue for publication as Informational. RFC 3967, section 2, first bullet item, could be read as a way out of this, but I doubt it could be appropriately invoked: the only reason that draft-ietf-enum-iax-04.txt is aiming at Standards Track is that that has been the only way to get an enum service registered since RRFC 3761. Now, the IANA registration document update for ENUM services is in WGLC now and hopefully can be shipped to the IESG soon. This eliminates the need for draft-ietf-enum-iax-04.txt going to proposed. Instead, I've had hoped - apologies if you heard this a couple of times already - we could have processed draft-ietf-enum-iax-04.txt under the upcoming ENUM services guidelines with an exception granted from the IESG as it was done with RFC2929bis. What's the plan? -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 12 07:53:26 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485023A6B67; Fri, 12 Sep 2008 07:53:26 -0700 (PDT) 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 0515E3A6ABC for ; Fri, 12 Sep 2008 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmEneh0opUXo for ; Fri, 12 Sep 2008 07:53:24 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id E49D13A680C for ; Fri, 12 Sep 2008 07:53:23 -0700 (PDT) Received: by mrp.swissptt.ch; Fri, 12 Sep 2008 16:53:27 +0200 (MEST) From: To: Date: Fri, 12 Sep 2008 16:53:24 +0200 Thread-Topic: [Enum] Working Group Last Call on enumservices guide 12 Thread-Index: AckQMVqJDAROnuxnQoqKsfQxZWDL8wEtOGGg Message-ID: <57582E8F684F0447BEA7762D5F71AFB10E7A22EE99@sg000004.corproot.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH MIME-Version: 1.0 X-OriginalArrivalTime: 12 Sep 2008 14:53:26.0110 (UTC) FILETIME=[4F883FE0:01C914E7] Subject: [Enum] FW: Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi! Does anybody remember who was volonteering to review draft-ietf-enum-enumse= rvices-guide-12? In Dublin there were three people offering to do so, but I do not remember = who. cheers, Bernie PS: I have requested IANA review of -12 (as some IANA related stuff has cha= nged). Furthermore I have sent IANA a proposal for the XML Registry for fee= dback. No reply from IANA to any of these requests so far. -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Saturday, September 06, 2008 5:01 PM To: enum@ietf.org Cc: 'Patrik F=E4ltstr=F6m' Subject: [Enum] Working Group Last Call on enumservices guide 12 Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-12.txt Pages : 44 Date : 2008-09-01 This document specifies a revision of the IANA Registry for Enumservices, d= escribes corresponding registration procedures, and provides a guideline fo= r creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-12.tx t The intent of the last call is to solicit comments before submitting the ID= to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or f= orever hold your peace" in case there are fundamental objections which have= not gotten previous or adequate discussion, or minor errors which need cor= rection. Work group last call will extend for 2 weeks or so from today September 6, 2008 until September 22, 2008 though we can modify that if new issues come = up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PST= N Mobile: +1 703.593.2683 _______________________________________________ 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 From enum-bounces@ietf.org Wed Sep 17 11:16:06 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782783A6A45; Wed, 17 Sep 2008 11:16:06 -0700 (PDT) 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 48C683A6838 for ; Wed, 17 Sep 2008 11:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9j1kPMB1tyB for ; Wed, 17 Sep 2008 11:16:04 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 418183A6A45 for ; Wed, 17 Sep 2008 11:16:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,416,1217808000"; d="scan'208";a="79006230" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 17 Sep 2008 18:16:15 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8HIGENe026524; Wed, 17 Sep 2008 11:16:14 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8HIGD03000040; Wed, 17 Sep 2008 18:16:13 GMT From: Cullen Jennings To: Peter Koch In-Reply-To: <20080907202357.GC25517@x27.adm.denic.de> Impp: xmpp:cullenfluffyjennings@jabber.org References: <06bb01c90f87$14b493b0$3e1dbb10$@us> <20080907202357.GC25517@x27.adm.denic.de> Message-Id: <0C6D6161-61DF-4888-9F63-6C0B518694FA@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 17 Sep 2008 12:16:07 -0600 X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1776; t=1221675374; x=1222539374; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Enum]=20ENUM=20WG=20Request=20for=20Pu blication=20-=20draft-ietf-enum-iax-04.txt |Sender:=20; bh=aFO0fQuDYCRHzNjej2KjKx93+4tbbp/6ZBka49S2qWc=; b=gUttY7FeeXT9fwc+p3fBXt7EN/vLQctUykk0u8xb0iTsHnXHXFUqfPCBy6 OSmq1ht+Tdmoy0hwxd6pelxrerHIHWyJxBYlVkuZuJH0oUj5iIWFC1rzQmXq WNMiewhijx; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: enum@ietf.org, "'Peterson, Jon'" Subject: Re: [Enum] ENUM WG Request for Publication - draft-ietf-enum-iax-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org My suggestion of the easiest way to solve this would be to IETF Last Call draft-ietf-enum-iax calling out a 3967 downref to draft-guy-iax-04. On Sep 7, 2008, at 2:23 PM, Peter Koch wrote: > On Fri, Sep 05, 2008 at 02:41:06PM -0400, Richard Shockey wrote: > >> Title : IANA Registration for IAX Enumservice >> Filename : draft-ietf-enum-iax-04.txt > >> A two week WG last call on this document concluded on July 7, 2008. >> >> The document listed above is being considered for Proposed Standard. > > so, for the process addicts amongst us - what is the solution to the > downref problem? > There is a normative reference to and > rightfully so. > This drafts sits in the RFC Editor queue for publication as > Informational. > RFC 3967, section 2, first bullet item, could be read as a way out > of this, > but I doubt it could be appropriately invoked: the only reason that > draft-ietf-enum-iax-04.txt is aiming at Standards Track is that that > has been > the only way to get an enum service registered since RRFC 3761. > Now, the IANA registration document update for ENUM services is in > WGLC > now and hopefully can be shipped to the IESG soon. This eliminates > the > need for draft-ietf-enum-iax-04.txt going to proposed. Instead, > I've had > hoped - apologies if you heard this a couple of times already - we > could > have processed draft-ietf-enum-iax-04.txt under the upcoming ENUM > services > guidelines with an exception granted from the IESG as it was done with > RFC2929bis. > > What's the plan? > > -Peter > _______________________________________________ > 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 From ahmed4life001@yahoo.ca Thu Sep 18 00:08:25 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0733A69A3 for ; Thu, 18 Sep 2008 00:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.101 X-Spam-Level: **** X-Spam-Status: No, score=4.101 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myUkH1QEVXNQ for ; Thu, 18 Sep 2008 00:08:24 -0700 (PDT) Received: from n9.bullet.mail.ac4.yahoo.com (n9.bullet.mail.ac4.yahoo.com [76.13.13.237]) by core3.amsl.com (Postfix) with SMTP id A06B63A6833 for ; Thu, 18 Sep 2008 00:08:24 -0700 (PDT) Received: from [76.13.13.25] by n9.bullet.mail.ac4.yahoo.com with NNFMP; 18 Sep 2008 07:08:38 -0000 Received: from [76.13.10.173] by t4.bullet.mail.ac4.yahoo.com with NNFMP; 18 Sep 2008 07:08:38 -0000 Received: from [127.0.0.1] by omp114.mail.ac4.yahoo.com with NNFMP; 18 Sep 2008 07:08:38 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 52936.7838.bm@omp114.mail.ac4.yahoo.com Received: (qmail 15574 invoked by uid 60001); 18 Sep 2008 07:08:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ymail_nen1; d=yahoo.ca; h=Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=J2GF+soeLRQnU0IEy5b3ELUze9oO0d5JWbMhdntpPtDutov1iSkkHAk1sk9UXaWllfnvrdPWO5yKPsBDyaoPPPJxVcfvMcnV3K5roZcs9QL++My3+tgctf3Ckn8dOE/1OZ6fsXBw6vOTrdEhrB7zgjynTbMhu/y2Hy+DwBnbPzE=; Received: from [41.203.227.192] by web59803.mail.ac4.yahoo.com via HTTP; Thu, 18 Sep 2008 00:08:37 PDT Date: Thu, 18 Sep 2008 00:08:37 -0700 (PDT) From: Ahmed Diallo Reply-To: ahmedd4life@yahoo.fr Subject: Can i Trust You? Call me if yes +226 78 03 96 12 To: enum-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1173110046-1221721717=:14012" Content-Transfer-Encoding: 8bit Message-ID: <859051.14012.qm@web59803.mail.ac4.yahoo.com> --0-1173110046-1221721717=:14012 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I have a new email address!You can now email me at: ahmed4life001@yahoo.ca I am Ahmed DIALLO, a staf of Bank Of Africa I want to transfer US$14 Million to your account. - Ahmed Diallo --0-1173110046-1221721717=:14012 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I have a new email address!
You can now email me at: ahmed4life001@yahoo.ca

I am Ahmed DIALLO, a staf of Bank Of Africa I want to transfer US$14 Million to your account.



- Ahmed Diallo
--0-1173110046-1221721717=:14012-- From enum-bounces@ietf.org Thu Sep 18 01:48:12 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2671F3A6AF8; Thu, 18 Sep 2008 01:48:12 -0700 (PDT) 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 D6F203A6AEA for ; Thu, 18 Sep 2008 01:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KExYLn7X1BPc for ; Thu, 18 Sep 2008 01:48:05 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id 0633A3A69E2 for ; Thu, 18 Sep 2008 01:48:04 -0700 (PDT) Received: by mrp.swissptt.ch; Thu, 18 Sep 2008 10:47:20 +0200 (MEST) From: To: , Date: Thu, 18 Sep 2008 10:46:59 +0200 Thread-Topic: [Enum] ENUM WG Request for Publication - draft-ietf-enum-iax-04.txt Thread-Index: AckY8YQ8o7WqyXsCT6eyLXjIIQ6XyAAeDuUQ Message-ID: <57582E8F684F0447BEA7762D5F71AFB10E7A4D7F3F@sg000004.corproot.net> References: <06bb01c90f87$14b493b0$3e1dbb10$@us> <20080907202357.GC25517@x27.adm.denic.de> <0C6D6161-61DF-4888-9F63-6C0B518694FA@cisco.com> In-Reply-To: <0C6D6161-61DF-4888-9F63-6C0B518694FA@cisco.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH MIME-Version: 1.0 X-OriginalArrivalTime: 18 Sep 2008 08:47:02.0615 (UTC) FILETIME=[1ED39E70:01C9196B] Cc: enum@ietf.org, jon.peterson@neustar.biz Subject: Re: [Enum] ENUM WG Request for Publication - draft-ietf-enum-iax-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Cullen Peter has suggested to test-run the new Enumservice registration process. The document defining this process (draft-ietf-enum-enumservices-guide-12) is currently in WG LC. Is the IESG interested in such a test-run of the new Enum Registration process as it has been done with 2929bis? The IAX Enumservice registration (draft-ietf-enum-iax-04) is a perfect sample for this. cheers, Bernie -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, September 17, 2008 8:16 PM To: Peter Koch Cc: enum@ietf.org; 'Peterson, Jon' Subject: Re: [Enum] ENUM WG Request for Publication - draft-ietf-enum-iax-04.txt My suggestion of the easiest way to solve this would be to IETF Last Call draft-ietf-enum-iax calling out a 3967 downref to draft-guy-iax-04. On Sep 7, 2008, at 2:23 PM, Peter Koch wrote: > On Fri, Sep 05, 2008 at 02:41:06PM -0400, Richard Shockey wrote: > >> Title : IANA Registration for IAX Enumservice >> Filename : draft-ietf-enum-iax-04.txt > >> A two week WG last call on this document concluded on July 7, 2008. >> >> The document listed above is being considered for Proposed Standard. > > so, for the process addicts amongst us - what is the solution to the > downref problem? > There is a normative reference to and > rightfully so. > This drafts sits in the RFC Editor queue for publication as > Informational. > RFC 3967, section 2, first bullet item, could be read as a way out of > this, but I doubt it could be appropriately invoked: the only reason > that draft-ietf-enum-iax-04.txt is aiming at Standards Track is that > that has been the only way to get an enum service registered since > RRFC 3761. > Now, the IANA registration document update for ENUM services is in > WGLC now and hopefully can be shipped to the IESG soon. This > eliminates the need for draft-ietf-enum-iax-04.txt going to proposed. > Instead, I've had hoped - apologies if you heard this a couple of > times already - we could have processed draft-ietf-enum-iax-04.txt > under the upcoming ENUM services guidelines with an exception granted > from the IESG as it was done with RFC2929bis. > > What's the plan? > > -Peter > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 18 08:23:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A273A6B61; Thu, 18 Sep 2008 08:23:48 -0700 (PDT) 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 820F328C114 for ; Thu, 18 Sep 2008 08:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s40xOWhMsV7Q for ; Thu, 18 Sep 2008 08:23:46 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9D4FE3A69B4 for ; Thu, 18 Sep 2008 08:23:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,422,1217808000"; d="scan'208";a="21845774" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 18 Sep 2008 15:24:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m8IFO12M012773; Thu, 18 Sep 2008 08:24:01 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m8IFNxrh004909; Thu, 18 Sep 2008 15:24:00 GMT From: Cullen Jennings To: "" In-Reply-To: <57582E8F684F0447BEA7762D5F71AFB10E7A4D7F3F@sg000004.corproot.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <06bb01c90f87$14b493b0$3e1dbb10$@us> <20080907202357.GC25517@x27.adm.denic.de> <0C6D6161-61DF-4888-9F63-6C0B518694FA@cisco.com> <57582E8F684F0447BEA7762D5F71AFB10E7A4D7F3F@sg000004.corproot.net> Message-Id: <4004FF00-33B9-4EEC-A7C6-704A5E46CEA9@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 18 Sep 2008 09:23:54 -0600 X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3131; t=1221751441; x=1222615441; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Enum]=20ENUM=20WG=20Request=20for=20Pu blication=20-=20draft-ietf-enum-iax-04.txt |Sender:=20; bh=xOmWZs6J14qZC8pL4XXFXgNqn9fk7xJjWZkM7WGQm1A=; b=F/HVODV8wBB5xhZ9ti5BKgXQwi8XVuBwoBkl6j3ndflmdY0xv+u9q27Ztc 4da9wWjndowVluhF05h/EkYEkYsvB/EtIzftpQ4xVajZAvhsncLUSsVNjX2H LeNYiz3Men; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: enum@ietf.org, pk@DENIC.DE, jon.peterson@neustar.biz Subject: Re: [Enum] ENUM WG Request for Publication - draft-ietf-enum-iax-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org That would be up to Jon but I'd be sort of surprised to see the IESG user the process in 2929bis that before 2929bis was approved (not an RFC but past the IESG approval step). However if 2929bis is in WGLC now, that might be relatively soon so perhaps one should just wait and then do enum-iax. On Sep 18, 2008, at 2:46 AM, wrote: > Hi Cullen > > Peter has suggested to test-run the new Enumservice registration > process. > The document defining this process (draft-ietf-enum-enumservices- > guide-12) > is currently in WG LC. > > Is the IESG interested in such a test-run of the new Enum > Registration process > as it has been done with 2929bis? The IAX Enumservice registration > (draft-ietf-enum-iax-04) is a perfect sample for this. > > > cheers, > Bernie > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Wednesday, September 17, 2008 8:16 PM > To: Peter Koch > Cc: enum@ietf.org; 'Peterson, Jon' > Subject: Re: [Enum] ENUM WG Request for Publication - draft-ietf- > enum-iax-04.txt > > > My suggestion of the easiest way to solve this would be to IETF Last > Call draft-ietf-enum-iax calling out a 3967 downref to draft-guy- > iax-04. > > > On Sep 7, 2008, at 2:23 PM, Peter Koch wrote: > >> On Fri, Sep 05, 2008 at 02:41:06PM -0400, Richard Shockey wrote: >> >>> Title : IANA Registration for IAX Enumservice >>> Filename : draft-ietf-enum-iax-04.txt >> >>> A two week WG last call on this document concluded on July 7, 2008. >>> >>> The document listed above is being considered for Proposed Standard. >> >> so, for the process addicts amongst us - what is the solution to the >> downref problem? >> There is a normative reference to and >> rightfully so. >> This drafts sits in the RFC Editor queue for publication as >> Informational. >> RFC 3967, section 2, first bullet item, could be read as a way out of >> this, but I doubt it could be appropriately invoked: the only reason >> that draft-ietf-enum-iax-04.txt is aiming at Standards Track is that >> that has been the only way to get an enum service registered since >> RRFC 3761. >> Now, the IANA registration document update for ENUM services is in >> WGLC now and hopefully can be shipped to the IESG soon. This >> eliminates the need for draft-ietf-enum-iax-04.txt going to proposed. >> Instead, I've had hoped - apologies if you heard this a couple of >> times already - we could have processed draft-ietf-enum-iax-04.txt >> under the upcoming ENUM services guidelines with an exception granted >> from the IESG as it was done with RFC2929bis. >> >> What's the plan? >> >> -Peter >> _______________________________________________ >> 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From aonori@infomaniak.ch Thu Sep 18 15:28:27 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBC93A6B65 for ; Thu, 18 Sep 2008 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_20=-0.74] 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 XlWkxq3Z--Me for ; Thu, 18 Sep 2008 15:28:27 -0700 (PDT) Received: from smtp1.infomaniak.ch (smtp1.infomaniak.ch [84.16.68.89]) by core3.amsl.com (Postfix) with ESMTP id C83F13A6AEB for ; Thu, 18 Sep 2008 15:28:26 -0700 (PDT) Received: from webmail.infomaniak.ch (mta-web8.infomaniak.ch [84.16.68.41]) by smtp1.infomaniak.ch (8.14.2/8.14.2) with ESMTP id m8IMFLTg026174; Fri, 19 Sep 2008 00:15:21 +0200 Date: Fri, 19 Sep 2008 00:15:22 +0200 From: IT WEBMAIL SERVICE Subject: Account Expire in 4 Day(s) Message-ID: <1221776122-6805185785c66eb6925850b3ddace0f4@infomaniak.ch> X-Mailer: Infomaniak Webmail X-Origin-IP: 196.207.0.227 MIME-Version: 1.0 X-Priority: 3 (Normal) Reply-To: upgreadteam001@live.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Antivirus: Dr.Web (R) for Mail Servers on smtp1 host X-Antivirus-Code: 100000 To: undisclosed-recipients:; Dear Webmail acount Subscriber, To complete your Webmail account, you must reply to this email immediately and enter your password here (*********) if you are the rightfull owner of this account, and help us to fight sparm mails. Failure to do this will immediately render your email address in-active from our database. You can also confirm your email address by enter your address here (*********) and also help us to fight sparm mails. NOTE: You are advice to change your password in the next 7 working days after undergoing this process for sercurity reasons. Thank you for using Webmail ! From a4diallo01@yahoo.com.au Sat Sep 20 02:20:55 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D64C3A6800 for ; Sat, 20 Sep 2008 02:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.101 X-Spam-Level: **** X-Spam-Status: No, score=4.101 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L0MZJQOYjEJ for ; Sat, 20 Sep 2008 02:20:54 -0700 (PDT) Received: from n4d.bullet.mail.ac4.yahoo.com (n4d.bullet.mail.ac4.yahoo.com [76.13.13.88]) by core3.amsl.com (Postfix) with SMTP id 8D6533A67FC for ; Sat, 20 Sep 2008 02:20:54 -0700 (PDT) Received: from [76.13.13.25] by n4.bullet.mail.ac4.yahoo.com with NNFMP; 20 Sep 2008 09:21:10 -0000 Received: from [76.13.10.171] by t4.bullet.mail.ac4.yahoo.com with NNFMP; 20 Sep 2008 09:21:10 -0000 Received: from [127.0.0.1] by omp112.mail.ac4.yahoo.com with NNFMP; 20 Sep 2008 09:21:10 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 108909.53204.bm@omp112.mail.ac4.yahoo.com Received: (qmail 53507 invoked by uid 60001); 20 Sep 2008 09:21:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ymail_nen1; d=yahoo.com.au; h=Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rJ0inQM8nmbb/25z0S+Mul7exTrWU9UGRZ+fvkCTjk0aQ7szy1RyufGO7cq/hSxYPe+e7jApWDwndkqELSL2y6iTXzereIePBw5CbJ8iLM+U8pdEGsF0HHl6jVJY6iL70Uwofq8R2/IfmoFjqYKCa5iJohhc1vPq/IVN9VlVLsI=; Received: from [41.203.227.235] by web59606.mail.ac4.yahoo.com via HTTP; Sat, 20 Sep 2008 02:21:09 PDT Date: Sat, 20 Sep 2008 02:21:09 -0700 (PDT) From: =?iso-8859-1?q?Ahmed=20Diallo?= Reply-To: ahmedd4life@yahoo.fr Subject: Can i Trust You? Call me if yes +226 78 03 96 12 To: enum-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1281395243-1221902469=:51682" Content-Transfer-Encoding: 8bit Message-ID: <861336.51682.qm@web59606.mail.ac4.yahoo.com> --0-1281395243-1221902469=:51682 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I have a new email address!You can now email me at: a4diallo01@yahoo.com.au I am Ahmed DIALLO, a staf of Bank Of Africa I want to transfer US$14 Million to your account. - Ahmed Diallo --0-1281395243-1221902469=:51682 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I have a new email address!
You can now email me at: a4diallo01@yahoo.com.au

I am Ahmed DIALLO, a staf of Bank Of Africa I want to transfer US$14 Million to your account.



- Ahmed Diallo
--0-1281395243-1221902469=:51682-- From enum-bounces@ietf.org Sun Sep 21 10:47:15 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B98D28C0FE; Sun, 21 Sep 2008 10:47:15 -0700 (PDT) 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 88F633A6BE9 for ; Sun, 21 Sep 2008 10:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK7XTy6EawlB for ; Sun, 21 Sep 2008 10:47:10 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id A6A863A6BE7 for ; Sun, 21 Sep 2008 10:47:09 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1KhT1Z-0000fh-0G; Sun, 21 Sep 2008 19:47:09 +0200 Received: from localhost by x27.adm.denic.de with local id 1KhSzw-0003YJ-HP; Sun, 21 Sep 2008 19:45:28 +0200 Date: Sun, 21 Sep 2008 19:45:28 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080921174528.GA12658@x27.adm.denic.de> Mail-Followup-To: IETF ENUM WG References: <09d901c91031$74145020$5c3cf060$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <09d901c91031$74145020$5c3cf060$@us> User-Agent: Mutt/1.4.2.3i Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sat, Sep 06, 2008 at 11:00:51AM -0400, Richard Shockey wrote: > http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-12.tx > t > > The intent of the last call is to solicit comments before submitting the ID > to the IESG as a Proposed Standard. I have reviewed version 12 of the Enumservice Guidelines draft. I support the general change of the registration policy from Experimental or Standards Track to Expert Review, as proposed in this document. I support publication as BCP. However, there are several editorial and terminology issues that IMHO warrant another update before sending this to the IESG. Regarding Terminology, the draft mixes "Registration", "Registration Template" and "Registration Document", where I'd suggest the following distinctions to be consistently applied: "Registration" is what is entered into the Registry after an application has been approved. "Registration Template" is the multiline template given in section 11. "Enumservice Specification" is what the applicant uses to specify the actual data. In fact, the Registration Template should be copied into the specification document, as it is today. I'd suggest to completely drop the term "Registration Document". The XML template in the appendix could be dropped without harm, in my opinion. If it is going to stay, the maintenance obligations need to be specified. During this review I might have stumbled across issues that have already been dealt with and have been declared closed. In this case, I'd appreciate a hint; there's no attempt to consciously rehash old discussions. -Peter > ENUM -- Telephone Number Mapping B. Hoeneisen > Working Group Swisscom > Internet-Draft A. Mayrhofer > Obsoletes: 3761 (if approved) enum.at > Intended status: Standards Track J. Livingood > Expires: March 5, 2009 Comcast IANA Registry Descriptions usually are BCP documents, and this draft obsoletes only part of RFC 3761, so "Updates: 3761" is probably more appropriate. > IANA Registration of Enumservices: Guide, Template and IANA > Considerations > draft-ietf-enum-enumservices-guide-12 > Abstract > > This document specifies a revision of the IANA Registry for NIT: s/revision of the IANA Registry/revision of the IANA Registration Guidelines/ > Enumservices, describes corresponding registration procedures, and > provides a guideline for creating Enumservices and its Registration NIT: s/its/their/ > 3.1. Functionality Requirements > > A registered Enumservice must be able to function as a selection > mechanism when choosing one NAPTR resource record from another. That > means that the Registration MUST specify what is expected when using > that very NAPTR record, and the URI which is the outcome of the use > of it. Here and in the rest of the document, "NAPTR" is always used in its singular form, where an ENUM service cannot expect to be covered by a single RR only. Also, a reference to DDDS and an introduction of the NAPTR RR [RFC3403] would be helpful. > Specifically, a registered Enumservice MUST specify the URI Scheme(s) > that may be used for the Enumservice, and, when needed, other The wording, active voice with "Enumservice" in the first person irritates me. -> "An Enumservice Specification MUST specify all URI Schemes ..." > 3.2. Naming Requirements > > An Enumservice MUST be unique in order to be useful as a selection > criteria: NIT: criterion > o The Type MUST be unique. > > o The Subtype (being dependent on the Type) MUST be unique within a > given Type. > > Types and Subtypes MUST conform to the ABNF specified in > [I-D.ietf-enum-3761bis]. Since that is only clarified in the -bis draft, it should be noted (non- normatively) here that type and subtype strings will be matched case insensitively (2.4.4 and 3.4 in -bis). > The ABNF specified in [I-D.ietf-enum-3761bis] allows the "-" (dash) > character for Types and Subtypes . To avoid confusion with possible > future prefixes, a "-" MUST NOT be used as the first nor as the > second character of a Type nor a Subtype. Strange enough, the current draft would allow "-" also as a last character. This should be changed in the -bis document, not in the registration guidelines. > To avoid confusion with Enumservice fields using an obsolete syntax, > any identifying tag of any Enumservice MUST NOT be set to nor start > with "E2U". > > The Subtype for one Type MAY be the same as a Subtype for a different > registered Type but it is not sufficient to simply reference another > Type's Subtype. The functionality of each Subtype MUST be specified > in the context of the Type being registered. This basicly says that the subtypes aren't equal, so I'd suggest to reword: "The Subtype for one Type MAY have the same identifier as a Subtype ..." > Section 4 contains further naming requirements. This is a bit hard to follow for applicants, experts and right now for me. Can we have a summary of the requirements right here? The following section ("cookbook") should contain recommendations only, not requirements. > 3.3. Security Requirements > > An analysis of security issues is REQUIRED for all registered > Enumservices. (This is in accordance with the basic requirements for > all IETF protocols.) > > All descriptions of security issues MUST be as accurate and extensive > as feasible. In particular, a statement that there are "no security > issues associated with this Enumservice" must not be confused with > "the security issues associated with this Enumservice have not been > assessed". > > There is no requirement that an Enumservice must be completely free > of security risks. Nevertheless, all known security risks MUST be > identified in the Registration of an Enumservice. The draft isn't completely consistent in its use of the term "Registration". Isn't it the registration template that should contain the risk assessment? [see introduction] > The security considerations section of all Registrations is subject > to continuing evaluation and modification. How would that work and whose obligation is it? > Some of the issues that SHOULD be looked at in a security analysis of > an Enumservice are: Not sure this SHOULD is justified or helpful. For the expert evaluation, some consideration by the applicant has to be shown anyway. "SHOULD be looked at" is rather fuzzy. > 2. Complex Enumservices may include provisions for directives that > institute actions which, while not directly harmful, may result > in disclosure of information that either facilitates a subsequent > attack or else violates the users privacy in some way. NIT: user's or users' > 3.4. Publication Requirements > > Enumservices Registrations MUST be published according to the See previous remark about terminology. In my reading, the "Registrations" would be published by incorporation into the IANA registry after the application has been granted, while the _Specification_ is what is dealt with here. > requirements for 'Specification Required' set in "Guidelines for > Writing an IANA Considerations Section in RFCs" [RFC5226]. RFCs > fulfill these requirements. Therefore, it is strongly RECOMMENDED > Registration Documents be published as RFCs. This emphasis isn't necessary IMHO, but I can live with it. My discomfort lies with the interaction of ISR and "Designated Expert". > 4. Enumservice Creation Cookbook > > 4.1. General Enumservice Considerations > > ENUM is an extremely flexible identifier mapping mechanism, using > E.164 (phone) numbers as input identifiers, and returning URIs as > output identifiers. Because of this flexibility, almost every use > case for ENUM could be implemented in several ways. > > Section 2 of "Guidelines for Writing an IANA Considerations Section > in RFCs" [RFC5226] provides motivation why management of a name space > might be necessary. Since the name space for Enumservice > registrations is among the largest namespaces that IANA manages (even > when ignoring Subtypes, its 32 alphanumeric characters make it much NIT: s/32/up to 32/; otherwise the 32 could be read as the number of characters rather than string length. > larger than the entire IPv6 addressing space), exhaustion is not a > problem. However, the following motivation for management taken from > Section 2 of [RFC5226] applies to Enumservices: I'd rephrase the whole paragraph to avoid the confusing (to me) comparison and duplication of reference: Even though the namespace for Enumservice Types [NIT: Too Many Capitals] is rather large (up to 32 alphanumerical characters), there are reasons suggesting a guided management. These reasons are given following the structure in section 2 of [RFC5226]: > o Prevent hoarding / wasting of values: Enumservice Types are not an > opaque identifier to prevent collisions in the namespace, but > rather identify the use of a certain technology in the context of > ENUM. Service Types might also be displayed to end users in > implementations, so meaningful Type strings having a clear > relation to the protocols / applications used are strongly > preferred (and RECOMMENDED). Therefore, preventing hoarding / > wasting / "hijacking" of Enumservice Type names is important. NIT: translate the "/" style into plain English NIT: s/strongly preferred (and RECOMMENDED)/RECOMMENDED/ > o Sanity check to ensure sensible / necessary requests: This applies > to Enumservices, since especially various Enumservices for the > same purpose would reduce the chance of successful > interoperability, and unnecessarily increase the confusion among > implementers. > > o Delegation of namespace portions: Theoretically, the Type / > Subtype structure of Enumservices would allow for delegations of > Type values, and self-supporting management of Subtype values by a > delegate within the Type value. Such delegates could for example > be other standardization bodies. However, this would require > clear policies regarding publication and use of such Subtypes. > Delegation of Enumservice namespace portions is therefore > currently not supported. I'd approach this less defensively, since 5226 only suggests delegation, but doesn't RECOMMEND it: Since the main motivations formanagement are sanity checks and space preservation in NAPTR responses, a unique policy has to be applied to all registrations and therefore delegation wouldn't gain anything. > o Interoperability: Since the benefit of an Enumservice rises with > the number of supporting clients, the registration of several > services for a similar or identical purpose clearly reduces > interoperability. Also, space within the protocol on which ENUM > is based (DNS packets) is rather scarce compared to the huge > identifier space that Enumservice typing provides. Registering > nearly identical services would clutter that space. Strictly speaking, the registration alone wouldn't do any harm, competing use would. Operational circumstances suggest to keep the space occupied by all services published in the NAPTR RRSet at any owner in the e164.arpa domain bounded. Registration of nearly identical services and subsequent competing or parallel use could easily increase the DNS operational complexity. > Generally, before commencing work on a new Enumservice registration, > the following should be considered: > > o Is there an existing Enumservice that could fulfill the desired > functionality without overloading it? Check the IANA Enumservice > Registry at . > > o Is there work in progress, or previous work, on a similar > Enumservice? Check the mailing list archives at > , and search > the Internet-Drafts Archive at . As some > Internet-Drafts may have expired and no longer be available in the > Internet-Drafts Archive, it is important to search the > mailing list archives and to perform a web search. While the advice is fine pragmatically, I'd suggest the IETF not make a statement in an RFC suggesting that the policy of six month lifetime for internet drafts wasn't meant seriously. > 4.2.1. General Type / Subtype Considerations > > To avoid confusion, the name of an URI Scheme MUST NOT be used as a > Type name for an Enumservice which is not specifically about the > respective protocol / URI Scheme - for example, the Type name 'imap' NIT: s/ - for/. For/ > would be inadequate for use in an Enumservice about "Internet > mapping" services, because it corresponds to an existing URI Scheme / > protocol for something different. > > If Subtypes are defined, the minimum number SHOULD be two (including > the empty subtype, if defined). The choice of just one possible > Subtype for a given Type does not add any information when selecting > a ENUM record, and hence can be left out completely. However, > potential future expansion of a Type towards several Subtypes MAY > justify the use of Subtypes, even in the case just one is currently > defined. "may justify" doesn't justify 2119 language. Add a forward reference to Section 9 to explain "future expansion" of existing Enumservice Registrations. > It is perfectly legal under a certain Type to mix the Enumservice > without a Subtype ("empty Subtype") with Enumservices containing a > Subtype. In that case, however, the Enumservice with an empty > Subtype SHOULD be used to reflect the base service, while the other > Enumservices SHOULD be used to reflect variants. The use of "SHOULD be used" in this paragraph confuses me. Would that refer to the way the service has to be specified or the actual operational use in NAPTR RRSets and queries? > 4.2.2. Protocol-based Enumservices Class > > Such an Enumservice indicates that an interaction using the named > protocol will result for use of this NAPTR. The expected behavior of See above: NAPTR in singular only. > a system using this Enumservice MUST be clear from the protocol. > > A good indication that an Enumservice belongs to this Class is the > fact that a client does not need to understand the actual application > to make use of an instance of this Enumservice. > > Examples of such Enumservices include XMPP [RFC4979] and SIP > [RFC3764]. > > 4.2.2.1. Protocol-based Enumservice "Type" Strings > > A protocol-based Enumservice SHOULD use the lowercased name of the > protocol as its Type name. Language: For a protocol-based Enumservice the Type SHOULD be specified as the lowercased name of the base protocol. Why lowercased when the field is case insensitive? > 4.2.2.2. Protocol-based Enumservice "Subtype" Strings > > Where there is a single URI Scheme associated with this protocol, > then the Enumservice SHOULD NOT use a Subtype. > > Where there are a number of different URI Schemes associated with > this protocol, the Registration MAY use the empty Subtype for all URI > Schemes that it specifies as mandatory to implement. For each URI > Scheme that is not mandatory to implement a distinct Subtype string > MUST be used. Language: Enumservice/Registration "use" Subtypes Where there is a single URI Scheme associated with this protocol, a Subtype SHOULD NOT be specified for the Enumservice. > 4.2.3. Application-based Enumservice Classes [...] > Another example is sms, where the presence of such an Enumservice > indicates that the publishing entity is capable of engaging in Clarification needed: what's meant by "presence of such an Enumservice"? > 4.2.3.2. Application-based Enumservice "Subtype" Strings > > It is RECOMMENDED to use the URI Scheme(s) which the application > uses, as Subtype name(s). Subtype names SHOULD be shared only > between URI Schemes that the Registration specifies as mandatory to > implement for a given Subtype. NIT: "SHOULD be shared only" better expressed by "MAY be shared", therwise it's inconsistent with the previous sharing requirement. > 4.2.4.2. Data- / Format-based Enumservice "Subtype" Strings > > It is RECOMMENDED to use the URI Schemes used to access the service > as Subtype name. Subtype names SHOULD be shared only between URI SHOULD ... only: see above > 5. Required Sections and Information > > In addition to the sections required for an RFC as outlined in > [RFC2223] and [instructions2authors] "Instructions to RFC Authors", > there are several sections that MUST appear in an Enumservice > Registration Document. These sections are as follows, and SHOULD be > in the given order. Given that non-RFC sepcifications are allowed, as well, it should be clarified how far the references above should be applied normatively to those specificatins. > 5.2. IANA Registration (MANDATORY) > > This section MUST be included in an Enumservice Registration. Where > a given Enumservice Type has multiple Subtypes, there MUST be a > separate 'IANA Registration' section for each Subtype. The following > lists the fields and order of an 'IANA Registration' section. > > > > o Enumservice Class: > > This field contains the Class of the Enumservice as defined in > Section 4.2. It's value MUST be one of (without quotes): > > * "Protocol-based": The Enumservice belongs to the Protocol-based > class as described in Section 4.2.2. > > * "Application-based, Common": The Enumservice is a "common" case > of the Application-based class as described in Section 4.2.3. > > * "Application-based, Subset": The Enumservice belongs to the > "subset" case of the Application-based class as described in > Section 4.2.3. > > * "Application-based, Ancillary": The Enumservice is an > "ancillary" case of the Application-based class, as described > in Section 4.2.3. > > * "Data- / Format-based": The Enumservice belongs to the Data- / > Format-based class as described in Section 4.2.4. > > * "Other": The majority of the functionality of the Enumservice > does not fall into one of the classes defined. > > e.g. > Protocol-based I've never understood why this information needs to be recorded, but so be it. When the tag is yo be used verbatimly, "Data- / Format-based" should be condensed to a single token. The example comes as a surprise a bit. In fact, the step-by-step walk-through might deserve a subsubsection number per field and some complete examples at the end of section 5.2. > o Enumservice Type: > > The Type of the Enumservice. All Types SHOULD be listed in lower- > case. The choice of Type depends on the Enumservice Class. > Please find further instructions in Section 4. > > e.g. > "foo" > > Note: Put the Type string between double quotes. Why? And does "Note" imply "MUST"? > o Enumservice Subtype: > > The Subtype of the Enumservice. All Subtypes SHOULD be listed in > lower-case. The choice of Subtype depends on the Enumservice > Class. Please find further instructions in Section 4. > > e.g. > "bar" > > e.g. > N/A > > Note: Put the Subtype string between double quotes. > > Note: Many Enumservices do not require a Subtype; use "N/A" in > this case. What if the empty subtype is registered in addition to others? Also, see questions for "Type". > o URI Scheme(s): > > The URI Schemes that are used with the Enumservice. The selection > of URI Schemes often depends on the Enumservice Class, Type, > and/or Subtype. Please find further instructions in Section 4. > > e.g. > 'bar', 'sbar' > > Note: Do not put a colon after a URI Scheme and put each URI > Scheme between single quotes. If there is more than one URI > Scheme, use a comma as separator. > > Note: A client cannot choose a specific ENUM record in a record > set based on the URI Scheme - the selection is only based on Type > and Subtype. Maybe add a reference to DDDS [RFC 3402] here. > * "COMMON": Indicates that the Enumservice is intended for > widespread use on the public Internet, and that it's scope is NIT: its > o Registration Document(s): > > A *unique* reference to the Enumservice Registration Document. > > e.g. > [RFC 9999] > > e.g. > [RFC 7777] (Obsoleted by RFC 8888) > [RFC 8888] (Updated by RFC 9999) > [RFC 9999] Now, is the intention here to list the history of the underlying protocol or the enumservice registration? How is who supposed to track and update this field? > 5.3. Examples (MANDATORY) > > This section MUST show at least one example of the Enumservice being > registered, for illustrative purposes. The example(s) shall in no > way limit the various forms that a given Enumservice may take, and > this should be noted at the beginning of this section of the > document. The example(s) MUST show the specific formatting of the > intended NAPTRs (according to [RFC3403] and [I-D.ietf-enum-3761bis]), > including one or more NAPTR example(s), AND a brief textual > description, consisting of one or more sentences written in plain > English, explaining the various parts or attributes of the record(s). > > The example(s) SHOULD contain a brief description how a client > supporting this Enumservice could behave, if that description was not > already given in e.g. the Introduction or the Functional > Specification. > > e.g. > $ORIGIN 9.7.8.0.9.7.8.9.0.9.4.4.e164.arpa. > @ IN NAPTR 100 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" . With reference to good practice and the pending IESG statement on examples, some hint for reserved or "drama" numbers should be given here, at least to the extent not to use numbers in example that could have any meaning in real life. > 5.5. Security Considerations (MANDATORY) [...] > However, this section is not intended as a general security Best > Current Practices (BCP) document and therefore it should not include > general and obvious security recommendations, such as securing > servers with strong password authentication. Remove reference to "BCP", since a section never makes a BCP. > [RFC3552] provides guidance to write a good Security Considerations > section, Section 10.2 of this document contains guidance specific to > Enumservice registration. That's perfectly sufficient! > 5.8. Other Sections (OPTIONAL) > > Other sections, beyond those required by the IETF and/or IANA, which > are cited or otherwise referenced herein, MAY be included in an Other sections beyond those required above may be included in an Enumservice Specification. > 6. The Process of Registering New Enumservices > > This section describes the process by which a new Enumservice is > submitted for review and comment, how such proposed Enumservices are > reviewed, and how they are published. Is this an illustration of the process or a normative description? What is the difference to BCP26/RFC 5226? > R-D: Registration Document I'd rather use the term "Enumservice specification" here to avoid confusion. > 6.2. Step 2: Write and Submit Registration Document > > An Internet-Draft (or another specification as appropriate) MUST be > written and made publicly available (submitted). The Registration > Document MUST follow the guidelines according to Section 4 and > Section 5 of this document. It is RECOMMENDED to use the XML2RFC > template contained in Appendix A of this document. This makes implicit assumptions about the IPR of the "Enumservice specification". > 6.3. Step 3: Request Comments from the IETF Community > > The authors MUST send an email to , in which comments > on the Registration Document are requested. A proper public > reference (a URL is RECOMMENDED) to the Registration Document MUST be > included in this email. > > The authors SHOULD allow a reasonable period of time to elapse, such > as two to four weeks, in order to collect any feedback. The authors > then consider whether or not to take any of those comments into > account, by making changes to the Registration Document and > submitting a revision, or otherwise proceeding. The following > outcomes are open to the authors. The choice of path is left to the > authors' judgement. As an informal consultation this is fine, but at some point in time someone else but the author needs to step in and actually steer the process and to actually judge the outcome. That happens as soon as the registration is requested and an Expert assigned. However, as an informal prelude this (i.e., 6.3) might be a bit overspecified. Other than that, I don't think it does any real harm as long as it's clear that, say, an Expert isn't bound by a "no objections" in this phase. > 6.5.1. Outcome 1: Experts Approve the Registation > > No (more) changes to the Registration Document are made. IANA will > inform the authors, who then will proceed to Step 6 below. Now, for transparency, shouldn't the - now official - application go to the list under the supervision of IANA or the Expert? > 6.6. Step 6: Publication of the Registration Document > > The authors are responsible that the Registration Document is > published according to 'Specification Required' as defined in > [RFC5226]. > > Typically Enumservice Registrations will be published as > Informational RFC via the Independent Submission process (see also > [instructions2authors]). s/Typically/Non-IETF/ > 6.7. Step 7: Adding Enumservice to IANA Registry > > In case the specification is published as an RFC, the RFC publication > process ensures that IANA will add the Enumservice to the Registry. > > If the specification will not be published as an RFC, the authors > MUST inform IANA, as soon as the Registration Document has been > published according to 'Specification Required' as defined in > [RFC5226]. The 'Registration Document(s)' field in the IANA Template > MUST contain a unambiguous reference to the Registration Document > (see also Section 5.2). In addition, the authors SHOULD provide IANA > with a stable URL to the Registration Document. IANA will then add > the Enumservice to the Registry. Why is the last SHOULD not a MUST,, except that noone can guarantee stability? > 7. Expert Review > > 7.1. Expert Selection Process > > According to Section 3.2 of [RFC5226], experts are appointed by the > IESG upon recommendation by the RAI Area Directors. The RAI area > directors are responsible for ensuring that there is always a > sufficient pool of experts available. > > 7.2. Review Guidelines > > Generally, the Expert Review Process of an Enumservice MUST follow > the guidelines documented in Section 3.3 of "Guidelines for Writing > an IANA Considerations Section in RFCs" [RFC5226]. > > The experts SHOULD evaluate the criteria as set out in [RFC5226], as > well as consider the following: Why not MUST? > o Verify conformance with the ENUM specification > [I-D.ietf-enum-3761bis]. > > o Verify that the requirements set in this document (Section 5) are > met. This includes check for completeness and whether all the > aspects described in Section 5 are sufficiently addressed. Add reference to this draft, Section 3. > 7.3. Appeals > > Appeals against Expert Review decisions follow the normal IETF appeal > process as described in section 7 of [RFC5226] and section 6.5 of > [RFC2026]. s/as described/as currently described/; Indeed, it might be better to only refer to RFC 5226 here. > 9. Extension of Existing Enumservice Registrations > > There are cases where it is more sensible to extend an existing > Enumservice registration rather than proposing a new one. Such cases > include adding a new Subtype to an existing Type. Depending on the > nature of the extension, the original Registration Document needs to > be extended (Updates) or replaced (Obsoletes) [RFC2223]. This is too RFC centric. > 11. IANA Considerations > 11.1.5. Change Control > > Change control of any Enumservices Registrations is done by "Expert > Review" and "Specification Required" according to [RFC5226]. Updates > of Enumservices Registrations MUST comply with the guidelines > described in this document. Updates are handled the same way as > initial Enumservice Registrations. > > Authorized Change Controllers are the experts and the IESG. > > Enumservice registrations MUST NOT be deleted. An Enumservice that > is believed no longer appropriate for use, can be declared obsolete > by publication of a new Enumservices Registrations document changing > its "Intended Usage" field to "OBSOLETE"; such Enumservices will be > clearly marked in the lists published by IANA. Obsoletion of an Enumservice should be subject to the same procedure as registration. > 11.1.6. Restrictions > > As stated in Section 3.2, a "-" (dash) MUST NOT be used as the first > nor as the second character of a Type nor a Subtype. Furthermore, > any identifying tag of any Enumservice MUST NOT be set to nor start > with "E2U". Any Enumservice registration requests covered by these > restrictions MUST be rejected by IANA, and the 'Expert Review > Process' SHOULD NOT be initiated. > > Appendix A contains examples for Enumservice registrations. > Therefore, IANA MUST NOT register an Enumservice with Type or Subtype > set to "foo", "bar", or "sbar", unless the experts explicitly confirm > an exception. Shouldn't the ENUM WG take the opportunity to designate "example" schemes which will be added to the Registry and thus no longer be available for registration? > 11.2. XML2RFC Template > > Before publication of this document IANA shall make the XML2RFC > template in Appendix A publicly available so that authors of new > Enumservice Registrations can easily download it. Given all the implications from boilerplate text, I doubt the template is really helpful. Also, it would introduce maintenance burden for whoever is tasked (hint!) with keeping this template in sync with xml2rfc and the IETF's requirements. While I'd assume taht IANA can take care of the Registration Template, I doubt it's the right place to provide for specification templates. > Appendix A. XML2RFC Template for Enumservice Registration Admittedly, I skipped this. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 29 10:00:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B53728C13F; Mon, 29 Sep 2008 10:00:04 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A07D28C126; Mon, 29 Sep 2008 10:00:00 -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: <20080929170001.4A07D28C126@core3.amsl.com> Date: Mon, 29 Sep 2008 10:00:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-cnam-08.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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --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 for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata' Author(s) : R. Shockey Filename : draft-ietf-enum-cnam-08.txt Pages : 18 Date : 2008-9-29 This document registers the Enumservice 'pstndata' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new URI type 'pstndata:'. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). The pstndata URI is created to facilitate this transfer, however this URI may be used to transport other PSTN data in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-08.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-cnam-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-9-29094727.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Sep 30 10:21:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3CC3A6BBE; Tue, 30 Sep 2008 10:21:32 -0700 (PDT) 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 5F20F3A6B32 for ; Tue, 30 Sep 2008 10:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSURpp7Sm-z3 for ; Tue, 30 Sep 2008 10:21:28 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 1263628C178 for ; Tue, 30 Sep 2008 10:21:16 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m8UHCwCw030202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Sep 2008 10:13:14 -0700 From: "Richard Shockey" To: "'Peter Koch'" , "'IETF ENUM WG'" References: <09d901c91031$74145020$5c3cf060$@us> <20080921174528.GA12658@x27.adm.denic.de> In-Reply-To: <20080921174528.GA12658@x27.adm.denic.de> Date: Tue, 30 Sep 2008 13:13:49 -0400 Message-ID: <0e6a01c92320$00675f30$01361d90$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckcEgSpQoF6wwV7Rs2i3lBTpgGldwHDWpsw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter ... why the change to BCP vs Proposed Standard. I think this is exactly the kind of draft that requires PS. In any event WGLC is now over. I'm wondering if the authors want to incorporate any of Peter's suggestions into a 13 version before the chairs request publication. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Peter Koch > Sent: Sunday, September 21, 2008 1:45 PM > To: IETF ENUM WG > Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 > > On Sat, Sep 06, 2008 at 11:00:51AM -0400, Richard Shockey wrote: > > > http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices- > guide-12.tx > > t > > > > The intent of the last call is to solicit comments before submitting > the ID > > to the IESG as a Proposed Standard. > > I have reviewed version 12 of the Enumservice Guidelines draft. > I support the general change of the registration policy from > Experimental or > Standards Track to Expert Review, as proposed in this document. > I support publication as BCP. > > However, there are several editorial and terminology issues that IMHO > warrant > another update before sending this to the IESG. > > Regarding Terminology, the draft mixes "Registration", "Registration > Template" > and "Registration Document", where I'd suggest the following > distinctions to > be consistently applied: > > "Registration" is what is entered into the Registry after an > application has > been approved. > "Registration Template" is the multiline template given in section > 11. > "Enumservice Specification" is what the applicant uses to specify > the > actual data. In fact, the Registration Template should be > copied into > the specification document, as it is today. > I'd suggest to completely drop the term "Registration > Document". > > The XML template in the appendix could be dropped without harm, in my > opinion. > If it is going to stay, the maintenance obligations need to be > specified. > > During this review I might have stumbled across issues that have > already been > dealt with and have been declared closed. In this case, I'd appreciate > a hint; > there's no attempt to consciously rehash old discussions. > > -Peter > > > ENUM -- Telephone Number Mapping B. > Hoeneisen > > Working Group > Swisscom > > Internet-Draft A. > Mayrhofer > > Obsoletes: 3761 (if approved) > enum.at > > Intended status: Standards Track J. > Livingood > > Expires: March 5, 2009 > Comcast > > IANA Registry Descriptions usually are BCP documents, and this draft > obsoletes only part of RFC 3761, so "Updates: 3761" is probably more > appropriate. > > > IANA Registration of Enumservices: Guide, Template and IANA > > Considerations > > draft-ietf-enum-enumservices-guide-12 > > > Abstract > > > > This document specifies a revision of the IANA Registry for > > NIT: s/revision of the IANA Registry/revision of the IANA Registration > Guidelines/ > > > Enumservices, describes corresponding registration procedures, > and > > provides a guideline for creating Enumservices and its > Registration > NIT: s/its/their/ > > > 3.1. Functionality Requirements > > > > A registered Enumservice must be able to function as a selection > > mechanism when choosing one NAPTR resource record from another. > That > > means that the Registration MUST specify what is expected when > using > > that very NAPTR record, and the URI which is the outcome of the > use > > of it. > > Here and in the rest of the document, "NAPTR" is always used in its > singular form, where an ENUM service cannot expect to be covered by a > single RR only. > Also, a reference to DDDS and an introduction of the NAPTR RR > [RFC3403] > would be helpful. > > > Specifically, a registered Enumservice MUST specify the URI > Scheme(s) > > that may be used for the Enumservice, and, when needed, other > > The wording, active voice with "Enumservice" in the first person > irritates me. > -> "An Enumservice Specification MUST specify all URI Schemes ..." > > > 3.2. Naming Requirements > > > > An Enumservice MUST be unique in order to be useful as a > selection > > criteria: > NIT: criterion > > > o The Type MUST be unique. > > > > o The Subtype (being dependent on the Type) MUST be unique > within a > > given Type. > > > > Types and Subtypes MUST conform to the ABNF specified in > > [I-D.ietf-enum-3761bis]. > > Since that is only clarified in the -bis draft, it should be noted > (non- > normatively) here that type and subtype strings will be matched > case insensitively (2.4.4 and 3.4 in -bis). > > > The ABNF specified in [I-D.ietf-enum-3761bis] allows the "-" > (dash) > > character for Types and Subtypes . To avoid confusion with > possible > > future prefixes, a "-" MUST NOT be used as the first nor as the > > second character of a Type nor a Subtype. > > Strange enough, the current draft would allow "-" also as a last > character. > This should be changed in the -bis document, not in the registration > guidelines. > > > To avoid confusion with Enumservice fields using an obsolete > syntax, > > any identifying tag of any Enumservice MUST NOT be set to nor > start > > with "E2U". > > > > The Subtype for one Type MAY be the same as a Subtype for a > different > > registered Type but it is not sufficient to simply reference > another > > Type's Subtype. The functionality of each Subtype MUST be > specified > > in the context of the Type being registered. > > This basicly says that the subtypes aren't equal, so I'd suggest to > reword: > "The Subtype for one Type MAY have the same identifier as a Subtype > ..." > > > Section 4 contains further naming requirements. > > This is a bit hard to follow for applicants, experts and right now for > me. > Can we have a summary of the requirements right here? The following > section ("cookbook") should contain recommendations only, not > requirements. > > > 3.3. Security Requirements > > > > An analysis of security issues is REQUIRED for all registered > > Enumservices. (This is in accordance with the basic requirements > for > > all IETF protocols.) > > > > All descriptions of security issues MUST be as accurate and > extensive > > as feasible. In particular, a statement that there are "no > security > > issues associated with this Enumservice" must not be confused > with > > "the security issues associated with this Enumservice have not > been > > assessed". > > > > There is no requirement that an Enumservice must be completely > free > > of security risks. Nevertheless, all known security risks MUST > be > > identified in the Registration of an Enumservice. > > The draft isn't completely consistent in its use of the term > "Registration". > Isn't it the registration template that should contain the risk > assessment? > [see introduction] > > > The security considerations section of all Registrations is > subject > > to continuing evaluation and modification. > > How would that work and whose obligation is it? > > > Some of the issues that SHOULD be looked at in a security > analysis of > > an Enumservice are: > > Not sure this SHOULD is justified or helpful. For the expert > evaluation, > some consideration by the applicant has to be shown anyway. "SHOULD be > looked > at" is rather fuzzy. > > > 2. Complex Enumservices may include provisions for directives > that > > institute actions which, while not directly harmful, may > result > > in disclosure of information that either facilitates a > subsequent > > attack or else violates the users privacy in some way. > NIT: user's or users' > > > 3.4. Publication Requirements > > > > Enumservices Registrations MUST be published according to the > > See previous remark about terminology. In my reading, the > "Registrations" would > be published by incorporation into the IANA registry after the > application has > been granted, while the _Specification_ is what is dealt with here. > > > requirements for 'Specification Required' set in "Guidelines for > > Writing an IANA Considerations Section in RFCs" [RFC5226]. RFCs > > fulfill these requirements. Therefore, it is strongly > RECOMMENDED > > Registration Documents be published as RFCs. > > This emphasis isn't necessary IMHO, but I can live with it. My > discomfort > lies with the interaction of ISR and "Designated Expert". > > > 4. Enumservice Creation Cookbook > > > > 4.1. General Enumservice Considerations > > > > ENUM is an extremely flexible identifier mapping mechanism, using > > E.164 (phone) numbers as input identifiers, and returning URIs as > > output identifiers. Because of this flexibility, almost every > use > > case for ENUM could be implemented in several ways. > > > > Section 2 of "Guidelines for Writing an IANA Considerations > Section > > in RFCs" [RFC5226] provides motivation why management of a name > space > > might be necessary. Since the name space for Enumservice > > registrations is among the largest namespaces that IANA manages > (even > > when ignoring Subtypes, its 32 alphanumeric characters make it > much > > NIT: s/32/up to 32/; otherwise the 32 could be read as the number of > characters rather than string length. > > > larger than the entire IPv6 addressing space), exhaustion is not > a > > problem. However, the following motivation for management taken > from > > Section 2 of [RFC5226] applies to Enumservices: > > I'd rephrase the whole paragraph to avoid the confusing (to me) > comparison and > duplication of reference: > > Even though the namespace for Enumservice Types [NIT: Too Many > Capitals] > is rather large (up to 32 alphanumerical characters), there are > reasons > suggesting a guided management. These reasons are given > following the > structure in section 2 of [RFC5226]: > > > o Prevent hoarding / wasting of values: Enumservice Types are > not an > > opaque identifier to prevent collisions in the namespace, but > > rather identify the use of a certain technology in the context > of > > ENUM. Service Types might also be displayed to end users in > > implementations, so meaningful Type strings having a clear > > relation to the protocols / applications used are strongly > > preferred (and RECOMMENDED). Therefore, preventing hoarding / > > wasting / "hijacking" of Enumservice Type names is important. > > NIT: translate the "/" style into plain English > NIT: s/strongly preferred (and RECOMMENDED)/RECOMMENDED/ > > > o Sanity check to ensure sensible / necessary requests: This > applies > > to Enumservices, since especially various Enumservices for the > > same purpose would reduce the chance of successful > > interoperability, and unnecessarily increase the confusion > among > > implementers. > > > > o Delegation of namespace portions: Theoretically, the Type / > > Subtype structure of Enumservices would allow for delegations > of > > Type values, and self-supporting management of Subtype values > by a > > delegate within the Type value. Such delegates could for > example > > be other standardization bodies. However, this would require > > clear policies regarding publication and use of such Subtypes. > > Delegation of Enumservice namespace portions is therefore > > currently not supported. > > I'd approach this less defensively, since 5226 only suggests > delegation, but > doesn't RECOMMEND it: Since the main motivations formanagement are > sanity > checks and space preservation in NAPTR responses, a unique policy has > to > be applied to all registrations and therefore delegation wouldn't gain > anything. > > > o Interoperability: Since the benefit of an Enumservice rises > with > > the number of supporting clients, the registration of several > > services for a similar or identical purpose clearly reduces > > interoperability. Also, space within the protocol on which > ENUM > > is based (DNS packets) is rather scarce compared to the huge > > identifier space that Enumservice typing provides. > Registering > > nearly identical services would clutter that space. > > Strictly speaking, the registration alone wouldn't do any harm, > competing > use would. > > Operational circumstances suggest to keep the space occupied by all > services published in the NAPTR RRSet at any owner in the e164.arpa > domain bounded. Registration of nearly identical services and > subsequent > competing or parallel use could easily increase the DNS operational > complexity. > > > Generally, before commencing work on a new Enumservice > registration, > > the following should be considered: > > > > o Is there an existing Enumservice that could fulfill the > desired > > functionality without overloading it? Check the IANA > Enumservice > > Registry at . > > > > o Is there work in progress, or previous work, on a similar > > Enumservice? Check the mailing list archives > at > > , and > search > > the Internet-Drafts Archive at . As > some > > Internet-Drafts may have expired and no longer be available in > the > > Internet-Drafts Archive, it is important to search the > > mailing list archives and to perform a web > search. > > While the advice is fine pragmatically, I'd suggest the IETF not make > a > statement in an RFC suggesting that the policy of six month lifetime > for internet drafts wasn't meant seriously. > > > 4.2.1. General Type / Subtype Considerations > > > > To avoid confusion, the name of an URI Scheme MUST NOT be used as > a > > Type name for an Enumservice which is not specifically about the > > respective protocol / URI Scheme - for example, the Type name > 'imap' > NIT: s/ - for/. For/ > > > would be inadequate for use in an Enumservice about "Internet > > mapping" services, because it corresponds to an existing URI > Scheme / > > protocol for something different. > > > > If Subtypes are defined, the minimum number SHOULD be two > (including > > the empty subtype, if defined). The choice of just one possible > > Subtype for a given Type does not add any information when > selecting > > a ENUM record, and hence can be left out completely. However, > > potential future expansion of a Type towards several Subtypes MAY > > justify the use of Subtypes, even in the case just one is > currently > > defined. > > "may justify" doesn't justify 2119 language. > > Add a forward reference to Section 9 to explain "future expansion" of > existing Enumservice Registrations. > > > It is perfectly legal under a certain Type to mix the Enumservice > > without a Subtype ("empty Subtype") with Enumservices containing > a > > Subtype. In that case, however, the Enumservice with an empty > > Subtype SHOULD be used to reflect the base service, while the > other > > Enumservices SHOULD be used to reflect variants. > > The use of "SHOULD be used" in this paragraph confuses me. Would that > refer to the way the service has to be specified or the actual > operational > use in NAPTR RRSets and queries? > > > 4.2.2. Protocol-based Enumservices Class > > > > Such an Enumservice indicates that an interaction using the named > > protocol will result for use of this NAPTR. The expected > behavior of > > See above: NAPTR in singular only. > > > a system using this Enumservice MUST be clear from the protocol. > > > > A good indication that an Enumservice belongs to this Class is > the > > fact that a client does not need to understand the actual > application > > to make use of an instance of this Enumservice. > > > > Examples of such Enumservices include XMPP [RFC4979] and SIP > > [RFC3764]. > > > > 4.2.2.1. Protocol-based Enumservice "Type" Strings > > > > A protocol-based Enumservice SHOULD use the lowercased name of > the > > protocol as its Type name. > > Language: For a protocol-based Enumservice the Type SHOULD be > specified as > the lowercased name of the base protocol. > > Why lowercased when the field is case insensitive? > > > 4.2.2.2. Protocol-based Enumservice "Subtype" Strings > > > > Where there is a single URI Scheme associated with this protocol, > > then the Enumservice SHOULD NOT use a Subtype. > > > > Where there are a number of different URI Schemes associated with > > this protocol, the Registration MAY use the empty Subtype for all > URI > > Schemes that it specifies as mandatory to implement. For each > URI > > Scheme that is not mandatory to implement a distinct Subtype > string > > MUST be used. > > Language: Enumservice/Registration "use" Subtypes > > Where there is a single URI Scheme associated with this protocol, > a Subtype SHOULD NOT be specified for the Enumservice. > > > 4.2.3. Application-based Enumservice Classes > > [...] > > > Another example is sms, where the presence of such an > Enumservice > > indicates that the publishing entity is capable of engaging in > > Clarification needed: what's meant by "presence of such an > Enumservice"? > > > 4.2.3.2. Application-based Enumservice "Subtype" Strings > > > > It is RECOMMENDED to use the URI Scheme(s) which the application > > uses, as Subtype name(s). Subtype names SHOULD be shared only > > between URI Schemes that the Registration specifies as mandatory > to > > implement for a given Subtype. > > NIT: "SHOULD be shared only" better expressed by "MAY be shared", > therwise > it's inconsistent with the previous sharing requirement. > > > 4.2.4.2. Data- / Format-based Enumservice "Subtype" Strings > > > > It is RECOMMENDED to use the URI Schemes used to access the > service > > as Subtype name. Subtype names SHOULD be shared only between URI > > SHOULD ... only: see above > > > 5. Required Sections and Information > > > > In addition to the sections required for an RFC as outlined in > > [RFC2223] and [instructions2authors] "Instructions to RFC > Authors", > > there are several sections that MUST appear in an Enumservice > > Registration Document. These sections are as follows, and SHOULD > be > > in the given order. > > Given that non-RFC sepcifications are allowed, as well, it should be > clarified how far the references above should be applied normatively > to those specificatins. > > > 5.2. IANA Registration (MANDATORY) > > > > This section MUST be included in an Enumservice Registration. > Where > > a given Enumservice Type has multiple Subtypes, there MUST be a > > separate 'IANA Registration' section for each Subtype. The > following > > lists the fields and order of an 'IANA Registration' section. > > > > > > > > o Enumservice Class: > > > > This field contains the Class of the Enumservice as defined in > > Section 4.2. It's value MUST be one of (without quotes): > > > > * "Protocol-based": The Enumservice belongs to the Protocol- > based > > class as described in Section 4.2.2. > > > > * "Application-based, Common": The Enumservice is a "common" > case > > of the Application-based class as described in Section > 4.2.3. > > > > * "Application-based, Subset": The Enumservice belongs to the > > "subset" case of the Application-based class as described > in > > Section 4.2.3. > > > > * "Application-based, Ancillary": The Enumservice is an > > "ancillary" case of the Application-based class, as > described > > in Section 4.2.3. > > > > * "Data- / Format-based": The Enumservice belongs to the > Data- / > > Format-based class as described in Section 4.2.4. > > > > * "Other": The majority of the functionality of the > Enumservice > > does not fall into one of the classes defined. > > > > e.g. > > Protocol-based > > I've never understood why this information needs to be recorded, but > so be it. > When the tag is yo be used verbatimly, "Data- / Format-based" should > be > condensed to a single token. > > The example comes as a surprise a bit. In fact, the step-by-step > walk-through > might deserve a subsubsection number per field and some complete > examples > at the end of section 5.2. > > > o Enumservice Type: > > > > The Type of the Enumservice. All Types SHOULD be listed in > lower- > > case. The choice of Type depends on the Enumservice Class. > > Please find further instructions in Section 4. > > > > e.g. > > "foo" > > > > Note: Put the Type string between double quotes. > > Why? And does "Note" imply "MUST"? > > > o Enumservice Subtype: > > > > The Subtype of the Enumservice. All Subtypes SHOULD be listed > in > > lower-case. The choice of Subtype depends on the Enumservice > > Class. Please find further instructions in Section 4. > > > > e.g. > > "bar" > > > > e.g. > > N/A > > > > Note: Put the Subtype string between double quotes. > > > > Note: Many Enumservices do not require a Subtype; use "N/A" in > > this case. > > What if the empty subtype is registered in addition to others? > Also, see questions for "Type". > > > o URI Scheme(s): > > > > The URI Schemes that are used with the Enumservice. The > selection > > of URI Schemes often depends on the Enumservice Class, Type, > > and/or Subtype. Please find further instructions in Section > 4. > > > > e.g. > > 'bar', 'sbar' > > > > Note: Do not put a colon after a URI Scheme and put each URI > > Scheme between single quotes. If there is more than one URI > > Scheme, use a comma as separator. > > > > Note: A client cannot choose a specific ENUM record in a > record > > set based on the URI Scheme - the selection is only based on > Type > > and Subtype. > > Maybe add a reference to DDDS [RFC 3402] here. > > > * "COMMON": Indicates that the Enumservice is intended for > > widespread use on the public Internet, and that it's scope > is > > NIT: its > > > o Registration Document(s): > > > > A *unique* reference to the Enumservice Registration Document. > > > > e.g. > > [RFC 9999] > > > > e.g. > > [RFC 7777] (Obsoleted by RFC 8888) > > [RFC 8888] (Updated by RFC 9999) > > [RFC 9999] > > Now, is the intention here to list the history of the underlying > protocol > or the enumservice registration? How is who supposed to track and > update > this field? > > > 5.3. Examples (MANDATORY) > > > > This section MUST show at least one example of the Enumservice > being > > registered, for illustrative purposes. The example(s) shall in > no > > way limit the various forms that a given Enumservice may take, > and > > this should be noted at the beginning of this section of the > > document. The example(s) MUST show the specific formatting of > the > > intended NAPTRs (according to [RFC3403] and [I-D.ietf-enum- > 3761bis]), > > including one or more NAPTR example(s), AND a brief textual > > description, consisting of one or more sentences written in plain > > English, explaining the various parts or attributes of the > record(s). > > > > The example(s) SHOULD contain a brief description how a client > > supporting this Enumservice could behave, if that description was > not > > already given in e.g. the Introduction or the Functional > > Specification. > > > > e.g. > > $ORIGIN 9.7.8.0.9.7.8.9.0.9.4.4.e164.arpa. > > @ IN NAPTR 100 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" . > > With reference to good practice and the pending IESG statement on > examples, > some hint for reserved or "drama" numbers should be given here, at > least > to the extent not to use numbers in example that could have any > meaning > in real life. > > > 5.5. Security Considerations (MANDATORY) > > [...] > > However, this section is not intended as a general security Best > > Current Practices (BCP) document and therefore it should not > include > > general and obvious security recommendations, such as securing > > servers with strong password authentication. > > Remove reference to "BCP", since a section never makes a BCP. > > > [RFC3552] provides guidance to write a good Security > Considerations > > section, Section 10.2 of this document contains guidance specific > to > > Enumservice registration. > > That's perfectly sufficient! > > > 5.8. Other Sections (OPTIONAL) > > > > Other sections, beyond those required by the IETF and/or IANA, > which > > are cited or otherwise referenced herein, MAY be included in an > > Other sections beyond those required above may be included in an > Enumservice Specification. > > > 6. The Process of Registering New Enumservices > > > > This section describes the process by which a new Enumservice is > > submitted for review and comment, how such proposed Enumservices > are > > reviewed, and how they are published. > > Is this an illustration of the process or a normative description? > What > is the difference to BCP26/RFC 5226? > > > R-D: Registration Document > > I'd rather use the term "Enumservice specification" here to avoid > confusion. > > > 6.2. Step 2: Write and Submit Registration Document > > > > An Internet-Draft (or another specification as appropriate) MUST > be > > written and made publicly available (submitted). The > Registration > > Document MUST follow the guidelines according to Section 4 and > > Section 5 of this document. It is RECOMMENDED to use the XML2RFC > > template contained in Appendix A of this document. > > This makes implicit assumptions about the IPR of the "Enumservice > specification". > > > 6.3. Step 3: Request Comments from the IETF Community > > > > The authors MUST send an email to , in which > comments > > on the Registration Document are requested. A proper public > > reference (a URL is RECOMMENDED) to the Registration Document > MUST be > > included in this email. > > > > The authors SHOULD allow a reasonable period of time to elapse, > such > > as two to four weeks, in order to collect any feedback. The > authors > > then consider whether or not to take any of those comments into > > account, by making changes to the Registration Document and > > submitting a revision, or otherwise proceeding. The following > > outcomes are open to the authors. The choice of path is left to > the > > authors' judgement. > > As an informal consultation this is fine, but at some point in time > someone > else but the author needs to step in and actually steer the process > and > to actually judge the outcome. That happens as soon as the > registration > is requested and an Expert assigned. However, as an informal prelude > this (i.e., 6.3) might be a bit overspecified. Other than that, I > don't think > it does any real harm as long as it's clear that, say, an Expert isn't > bound by a "no objections" in this phase. > > > 6.5.1. Outcome 1: Experts Approve the Registation > > > > No (more) changes to the Registration Document are made. IANA > will > > inform the authors, who then will proceed to Step 6 below. > > Now, for transparency, shouldn't the - now official - application go > to > the list under the supervision of IANA or the Expert? > > > 6.6. Step 6: Publication of the Registration Document > > > > The authors are responsible that the Registration Document is > > published according to 'Specification Required' as defined in > > [RFC5226]. > > > > Typically Enumservice Registrations will be published as > > Informational RFC via the Independent Submission process (see > also > > [instructions2authors]). > > s/Typically/Non-IETF/ > > > 6.7. Step 7: Adding Enumservice to IANA Registry > > > > In case the specification is published as an RFC, the RFC > publication > > process ensures that IANA will add the Enumservice to the > Registry. > > > > If the specification will not be published as an RFC, the authors > > MUST inform IANA, as soon as the Registration Document has been > > published according to 'Specification Required' as defined in > > [RFC5226]. The 'Registration Document(s)' field in the IANA > Template > > MUST contain a unambiguous reference to the Registration Document > > (see also Section 5.2). In addition, the authors SHOULD provide > IANA > > with a stable URL to the Registration Document. IANA will then > add > > the Enumservice to the Registry. > > Why is the last SHOULD not a MUST,, except that noone can guarantee > stability? > > > 7. Expert Review > > > > 7.1. Expert Selection Process > > > > According to Section 3.2 of [RFC5226], experts are appointed by > the > > IESG upon recommendation by the RAI Area Directors. The RAI area > > directors are responsible for ensuring that there is always a > > sufficient pool of experts available. > > > > 7.2. Review Guidelines > > > > Generally, the Expert Review Process of an Enumservice MUST > follow > > the guidelines documented in Section 3.3 of "Guidelines for > Writing > > an IANA Considerations Section in RFCs" [RFC5226]. > > > > The experts SHOULD evaluate the criteria as set out in [RFC5226], > as > > well as consider the following: > > Why not MUST? > > > o Verify conformance with the ENUM specification > > [I-D.ietf-enum-3761bis]. > > > > o Verify that the requirements set in this document (Section 5) > are > > met. This includes check for completeness and whether all the > > aspects described in Section 5 are sufficiently addressed. > > Add reference to this draft, Section 3. > > > 7.3. Appeals > > > > Appeals against Expert Review decisions follow the normal IETF > appeal > > process as described in section 7 of [RFC5226] and section 6.5 of > > [RFC2026]. > > s/as described/as currently described/; Indeed, it might be better to > only > refer to RFC 5226 here. > > > 9. Extension of Existing Enumservice Registrations > > > > There are cases where it is more sensible to extend an existing > > Enumservice registration rather than proposing a new one. Such > cases > > include adding a new Subtype to an existing Type. Depending on > the > > nature of the extension, the original Registration Document needs > to > > be extended (Updates) or replaced (Obsoletes) [RFC2223]. > > This is too RFC centric. > > > 11. IANA Considerations > > > 11.1.5. Change Control > > > > Change control of any Enumservices Registrations is done by > "Expert > > Review" and "Specification Required" according to [RFC5226]. > Updates > > of Enumservices Registrations MUST comply with the guidelines > > described in this document. Updates are handled the same way as > > initial Enumservice Registrations. > > > > Authorized Change Controllers are the experts and the IESG. > > > > Enumservice registrations MUST NOT be deleted. An Enumservice > that > > is believed no longer appropriate for use, can be declared > obsolete > > by publication of a new Enumservices Registrations document > changing > > its "Intended Usage" field to "OBSOLETE"; such Enumservices will > be > > clearly marked in the lists published by IANA. > > Obsoletion of an Enumservice should be subject to the same procedure > as > registration. > > > 11.1.6. Restrictions > > > > As stated in Section 3.2, a "-" (dash) MUST NOT be used as the > first > > nor as the second character of a Type nor a Subtype. > Furthermore, > > any identifying tag of any Enumservice MUST NOT be set to nor > start > > with "E2U". Any Enumservice registration requests covered by > these > > restrictions MUST be rejected by IANA, and the 'Expert Review > > Process' SHOULD NOT be initiated. > > > > Appendix A contains examples for Enumservice registrations. > > Therefore, IANA MUST NOT register an Enumservice with Type or > Subtype > > set to "foo", "bar", or "sbar", unless the experts explicitly > confirm > > an exception. > > Shouldn't the ENUM WG take the opportunity to designate "example" > schemes > which will be added to the Registry and thus no longer be available > for > registration? > > > 11.2. XML2RFC Template > > > > Before publication of this document IANA shall make the XML2RFC > > template in Appendix A publicly available so that authors of new > > Enumservice Registrations can easily download it. > > Given all the implications from boilerplate text, I doubt the template > is really helpful. Also, it would introduce maintenance burden for > whoever > is tasked (hint!) with keeping this template in sync with xml2rfc and > the IETF's requirements. While I'd assume taht IANA can take care of > the Registration Template, I doubt it's the right place to provide for > specification templates. > > > Appendix A. XML2RFC Template for Enumservice Registration > > Admittedly, I skipped this. > > -Peter > _______________________________________________ > 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 From enum-bounces@ietf.org Tue Sep 30 11:05:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FBC3A689C; Tue, 30 Sep 2008 11:05:08 -0700 (PDT) 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 8066F3A6A11 for ; Tue, 30 Sep 2008 11:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3l6kvdkljdT for ; Tue, 30 Sep 2008 11:05:06 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 8B11B28C186 for ; Tue, 30 Sep 2008 11:04:57 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KkjaR-00055J-BM; Tue, 30 Sep 2008 20:04:39 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 35E3B825246; Tue, 30 Sep 2008 20:04:39 +0200 (CEST) Date: Tue, 30 Sep 2008 20:04:38 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080930180438.GH13332@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <09d901c91031$74145020$5c3cf060$@us> <20080921174528.GA12658@x27.adm.denic.de> <0e6a01c92320$00675f30$01361d90$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <0e6a01c92320$00675f30$01361d90$@us> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, > Peter ... why the change to BCP vs Proposed Standard. I think this is > exactly the kind of draft that requires PS. the draft "IANA Registration of Enumservices: Guide, Template and IANA Considerations" doesn't specify a protocol but a process. Both RFC 2026, section 5, and section 4.3 of RFC 5226 suggest that process documents, and IANA Guidelines in particular, usually are published as BCP RFCs. Also, there's little to implement independently in this draft that could help advance it on the Standards Track. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 30 11:53:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE093A6951; Tue, 30 Sep 2008 11:53:25 -0700 (PDT) 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 9DA383A6951 for ; Tue, 30 Sep 2008 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwyGbJKhizoG for ; Tue, 30 Sep 2008 11:53:22 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id 03A5E3A689C for ; Tue, 30 Sep 2008 11:53:21 -0700 (PDT) Received: by mrp.swissptt.ch; Tue, 30 Sep 2008 20:53:39 +0200 (MEST) From: To: , Date: Tue, 30 Sep 2008 20:53:36 +0200 Thread-Topic: [Enum] Working Group Last Call on enumservices guide 12 Thread-Index: AckcEgSpQoF6wwV7Rs2i3lBTpgGldwHDWpswAAMfS7A= Message-ID: <57582E8F684F0447BEA7762D5F71AFB10E7C0908D2@sg000004.corproot.net> References: <09d901c91031$74145020$5c3cf060$@us> <20080921174528.GA12658@x27.adm.denic.de> <0e6a01c92320$00675f30$01361d90$@us> In-Reply-To: <0e6a01c92320$00675f30$01361d90$@us> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2008 18:53:39.0382 (UTC) FILETIME=[D9F28560:01C9232D] Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Rich We'll certainly consider Peter's feedback and issue a revision -13. As I expressed in Dublin, Swisscom is not supporting me for this work any longer, so I'll have to do it all in my freetime. (And freetime is precious at the moment as there is also all my NomCom work to be done in my freetime.) Therefore it might take a while. I hope we can issue -13 soon, but unfortunately these are my boundary conditions... cheers, Bernie -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, September 30, 2008 7:14 PM To: 'Peter Koch'; 'IETF ENUM WG' Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 [...] In any event WGLC is now over. I'm wondering if the authors want to incorporate any of Peter's suggestions into a 13 version before the chairs request publication. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 30 12:08:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9FF3A67EF; Tue, 30 Sep 2008 12:08:30 -0700 (PDT) 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 E2A473A67B0 for ; Tue, 30 Sep 2008 12:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 iPtZCORbuxfa for ; Tue, 30 Sep 2008 12:08:28 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 9C3503A6A00 for ; Tue, 30 Sep 2008 12:08:27 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m8UJ53js010621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Sep 2008 12:05:32 -0700 From: "Richard Shockey" To: "'Peter Koch'" , "'IETF ENUM WG'" References: <09d901c91031$74145020$5c3cf060$@us> <20080921174528.GA12658@x27.adm.denic.de> <0e6a01c92320$00675f30$01361d90$@us> <20080930180438.GH13332@unknown.office.denic.de> In-Reply-To: <20080930180438.GH13332@unknown.office.denic.de> Date: Tue, 30 Sep 2008 15:06:48 -0400 Message-ID: <0fae01c9232f$b9934000$2cb9c000$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckjJwh+u6lojTKgRV2SUOETooFLFAACJpYQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I stand corrected ..thanks for point that out > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Peter Koch > Sent: Tuesday, September 30, 2008 2:05 PM > To: IETF ENUM WG > Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 > > Richard, > > > Peter ... why the change to BCP vs Proposed Standard. I think this > is > > exactly the kind of draft that requires PS. > > the draft "IANA Registration of Enumservices: Guide, Template and IANA > Considerations" doesn't specify a protocol but a process. > > Both RFC 2026, section 5, and section 4.3 of RFC 5226 suggest that > process > documents, and IANA Guidelines in particular, usually are published as > BCP > RFCs. Also, there's little to implement independently in this draft > that > could help advance it on the Standards Track. > > -Peter > _______________________________________________ > 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 From enum-bounces@ietf.org Tue Sep 30 12:42:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335593A6B4B; Tue, 30 Sep 2008 12:42:53 -0700 (PDT) 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 4797D3A6B4B for ; Tue, 30 Sep 2008 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 hnwguQ+RxGBv for ; Tue, 30 Sep 2008 12:42:51 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 020873A683A for ; Tue, 30 Sep 2008 12:42:50 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m8UJdgnj002981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Sep 2008 12:40:03 -0700 From: "Richard Shockey" To: , References: <09d901c91031$74145020$5c3cf060$@us> <20080921174528.GA12658@x27.adm.denic.de> <0e6a01c92320$00675f30$01361d90$@us> <57582E8F684F0447BEA7762D5F71AFB10E7C0908D2@sg000004.corproot.net> In-Reply-To: <57582E8F684F0447BEA7762D5F71AFB10E7C0908D2@sg000004.corproot.net> Date: Tue, 30 Sep 2008 15:40:48 -0400 Message-ID: <0fff01c92334$8925d7c0$9b718740$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckcEgSpQoF6wwV7Rs2i3lBTpgGldwHDWpswAAMfS7AAAhuMsA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Understood Bernie ... do what you can. We all deeply appreciate what you have done so far. > -----Original Message----- > From: Bernhard.Hoeneisen@swisscom.com > [mailto:Bernhard.Hoeneisen@swisscom.com] > Sent: Tuesday, September 30, 2008 2:54 PM > To: richard@shockey.us; enum@ietf.org > Subject: RE: [Enum] Working Group Last Call on enumservices guide 12 > > Hi Rich > > We'll certainly consider Peter's feedback and issue a revision -13. > > As I expressed in Dublin, Swisscom is not supporting me for this work > any longer, > so I'll have to do it all in my freetime. (And freetime is precious at > the moment > as there is also all my NomCom work to be done in my freetime.) > Therefore it might take a while. > > I hope we can issue -13 soon, but unfortunately these are my boundary > conditions... > > cheers, > Bernie > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Richard Shockey > Sent: Tuesday, September 30, 2008 7:14 PM > To: 'Peter Koch'; 'IETF ENUM WG' > Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 > > [...] > > In any event WGLC is now over. I'm wondering if the authors want to > incorporate any of Peter's suggestions into a 13 version before the > chairs request publication. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 30 13:32:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA36B28C10C; Tue, 30 Sep 2008 13:32:48 -0700 (PDT) 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 D489A28C10C for ; Tue, 30 Sep 2008 13:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIOiCGXqVSVW for ; Tue, 30 Sep 2008 13:32:47 -0700 (PDT) Received: from mail.swisscom.com (outmail20.swisscom.com [138.190.32.10]) by core3.amsl.com (Postfix) with ESMTP id C0D6A3A6B2B for ; Tue, 30 Sep 2008 13:32:46 -0700 (PDT) Received: by mrz.swissptt.ch; Tue, 30 Sep 2008 22:31:13 +0200 (MEST) From: To: Date: Tue, 30 Sep 2008 22:31:19 +0200 Thread-Topic: No IANA feedback for draft-ietf-enum-enumservices-guide-12 received Thread-Index: AckjO37SU/V/O8MjS7y+9l5w6EGflw== Message-ID: <57582E8F684F0447BEA7762D5F71AFB10E7C0908DC@sg000004.corproot.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2008 20:31:13.0485 (UTC) FILETIME=[7B43BFD0:01C9233B] Cc: iana-issues@icann.org, iana@iana.org Subject: [Enum] No IANA feedback for draft-ietf-enum-enumservices-guide-12 received 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: , Content-Type: multipart/mixed; boundary="===============0988569680==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0988569680== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_57582E8F684F0447BEA7762D5F71AFB10E7C0908DCsg000004corpr_" --_000_57582E8F684F0447BEA7762D5F71AFB10E7C0908DCsg000004corpr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ENUM WG In Dublin we have been asked to use the new XMLized policy for IANA registr= ations of Enumservices. According to my knowledge, there is neither documen= tation nor an example on how this is done. I have sent IANA a draft proposal containing an XML schema and asked for gu= idance on how a specification for an XML Registry should look like. I also = stressed out the fact that the document was in WG LC. Result: So far, no answer at all :-( Does anybody have direct connections to IANA and could remind them to resol= v the issues collected in ticket [IANA #171390] ASAP? I there is no answer from IANA by the end of this week, we'll go on with th= e old-style IANA Registry for Enumservices (i.e. forget about XML Registry)= . Does anybody have an issue with this approach? Any better proposals on how = to get out of this lock? cheers, Bernie --_000_57582E8F684F0447BEA7762D5F71AFB10E7C0908DCsg000004corpr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear ENUM WG
 
In Dublin we have been asked to use the new XMLized policy for IANA re= gistrations of Enumservices. According to my knowledge, there is neither do= cumentation nor an example on how this is done.
 
I have sent IANA a draft proposal containing an XML schema and asked f= or guidance on how a specification for an XML Registry should look like. I = also stressed out the fact that the document was in WG LC.
 
Result: So far, no answer at all :-(
 
Does anybody have direct connections to IANA and could remind them to = resolv the issues collected in ticket [IANA #171390] ASAP?
 
I there is no answer from IANA by the end of this week, we'll go on wi= th the old-style IANA Registry for Enumservices (i.e. forget about XML Regi= stry).
Does anybody have an issue with this approach? Any better proposals on= how to get out of this lock?
 
cheers,
Bernie
 
 
 --_000_57582E8F684F0447BEA7762D5F71AFB10E7C0908DCsg000004corpr_-- --===============0988569680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --===============0988569680==-- From enum-bounces@ietf.org Wed Oct 1 00:09:45 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A76D3A6BF4; Wed, 1 Oct 2008 00:09:45 -0700 (PDT) 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 9DBB13A6BFC for ; Wed, 1 Oct 2008 00:09:43 -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 MBlJxS-vU0e1 for ; Wed, 1 Oct 2008 00:09:42 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id A5EEF3A6BDA for ; Wed, 1 Oct 2008 00:09:42 -0700 (PDT) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.2) with ESMTP id m9177rYH061182; Wed, 1 Oct 2008 09:07:53 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200810010707.m9177rYH061182@bartok.nlnetlabs.nl> To: Bernhard.Hoeneisen@swisscom.com In-reply-to: Your message of Tue, 30 Sep 2008 22:31:19 +0200. <57582E8F684F0447BEA7762D5F71AFB10E7C0908DC@sg000004.corproot.net> Date: Wed, 01 Oct 2008 09:07:53 +0200 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (bartok.nlnetlabs.nl [127.0.0.1]); Wed, 01 Oct 2008 09:07:53 +0200 (CEST) Cc: enum@ietf.org, iana-issues@icann.org, iana@iana.org Subject: Re: [Enum] No IANA feedback for draft-ietf-enum-enumservices-guide-12 received 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In Dublin we have been asked to use the new XMLized policy for IANA registrations of Enumservices. According to my knowledge, there is neither documentation nor an example on how this is done. Maybe it got lost in the transition to the new web site. There are now templates for registrations at the next URL: http://www.iana.org/protocols/apply/. Did you use that? jaap _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum