From exim@www1.ietf.org Mon Nov 3 14:46:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17065 for ; Mon, 3 Nov 2003 14:46:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkeo-0001xN-2E for enum-archive@odin.ietf.org; Mon, 03 Nov 2003 14:46:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3JkYkU007517 for enum-archive@odin.ietf.org; Mon, 3 Nov 2003 14:46:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkeI-0001wW-Mq; Mon, 03 Nov 2003 14:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkdl-0001vD-Pc for enum@optimus.ietf.org; Mon, 03 Nov 2003 14:45:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17009; Mon, 3 Nov 2003 14:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGkdi-0003LP-00; Mon, 03 Nov 2003 14:45:26 -0500 Received: from p154.n-nypop03.stsn.com ([199.106.90.154] helo=S-UTL01-NYNOC.stsn.com) by ietf-mx with smtp (Exim 4.12) id 1AGkdi-0003LB-00; Mon, 03 Nov 2003 14:45:26 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us ([10.6.59.95]) by S-UTL01-NYNOC.stsn.com (NAVGW 2.5.2.9) with SMTP id M2003110314460726947 ; Mon, 03 Nov 2003 14:46:09 -0500 Message-Id: <6.0.0.22.2.20031028161320.0355de90@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 03 Nov 2003 14:42:35 -0500 To: enum@ietf.org From: Richard Shockey Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FINAL Agenda for ENUM WG IETF 58 Minneapolis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , TUESDAY, November 11, 2003 0800-1800 IETF Registration - Ballroom Foyer, 3rd Floor 0800-0900 Continental Breakfast - Ballroom Foyer, 3rd Floor 1130-1300 Break 1300-1400 Afternoon Sessions I APP ldapbis LDAP (v3) Revsion WG INT send Securing Neighbor Discovery WG OPS dnsop Domain Name System Operations WG OPS ipcdn IP over Cable Data Network WG RTG pim Protocol Independent Multicast WG SEC enroll Credential and Provisioning BOF TSV enum Telephone Number Mapping WG IETF 58 Minneapolis Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Nominations for ENUM WG Secretary. The chairs would like the ENUM WG to participate in an IETF experiment to consider another position in the ENUM WG management structure that of WG Secretary which would have the responsibility for things like the minutes and document tracking etc. 1. Applicability Statement of CRISP work to ENUM - 15 Min Title : IRIS - An ENUM Registry (ereg) Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-01.txt Pages : 33 Date : 2003-10-24 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-01.txt 2. Potential Informational Document 15 min Title : Numbering for VoIP and other IP Communications > Author(s) : R. Stastny > Filename : draft-stastny-enum-numbering-voip-00.txt > Pages : 43 > Date : 2003-10-20 > >This document gives advice in setting up E.164 compatible numbering >and dialing plans in administrative domains set up for IP >Communications in general and VoIP applications in detail. After >explaining numbering and dialing plans in principle, it discusses >which types of E.164 numbers should be used for IP based terminals, >to achieve proper routing of calls and other communications on the >PSTN/ISDN and also on the Internet, using ENUM technology. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-stastny-enum-numbering-voip-00.txt 4. Implementation issues L. Conroy 10-15 Problem Statement : "This summarizes our experiences of what's "out there" in ENUM, and some implementation choices that need to be made. It is intended as a guide to what we found when querying different ENUM domains (and what we misunderstood at first reading of the standards). Note that this covers implementation issues only, NOT protocol issues. However, if different implementations share common choices, then behavior can be better predicted". 5. Trial Updates Korea 5 min +... Poland - Use of EPP in provisioning. 10+ http://www.ietf.org/internet-drafts/draft-bartosiewicz-enum-48tld-00.txt 6. WG next steps 7. General Discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 06:08:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09060 for ; Tue, 4 Nov 2003 06:08:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGz2k-0004JE-Px for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 06:08:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4B8E6h016512 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 06:08:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGz2X-0004G6-R3; Tue, 04 Nov 2003 06:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGz1v-000467-Nw for enum@optimus.ietf.org; Tue, 04 Nov 2003 06:07:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08990 for ; Tue, 4 Nov 2003 06:07:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGz1r-0003Jh-00 for enum@ietf.org; Tue, 04 Nov 2003 06:07:19 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AGz1r-0003In-00 for enum@ietf.org; Tue, 04 Nov 2003 06:07:19 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 11:06:48 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPKMR; Tue, 4 Nov 2003 11:06:43 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 11:06:36 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 1 - Case Sensitivity Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, here's an issue we've come across when looking at ENUM domain content "out there". Some NAPTRs use lower case for the flag field value; some use upper case - (e.g. 'U' or 'u') Some NAPTRs use lower case for the ENUMservice tokens; some use upper case - (e.g. 'SIP' or 'sip') In our clients we treat both of these strings as case-insensitive (i.e. we do a tolower before comparing them). This is also done in a couple of the Clients where I've scanned their source. Thus... Q: It looks like most clients are designed to treat the flags and service fields as case-insensitive. Does anyone object to this (i.e. does anyone have a burning desire to have the flag and services field entries treated as case-sensitive)? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 06:20:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09288 for ; Tue, 4 Nov 2003 06:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzEE-0004tA-Sv for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 06:20:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4BK4eS018734 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 06:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzEA-0004ra-Kt; Tue, 04 Nov 2003 06:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzDL-0004pt-Ts for enum@optimus.ietf.org; Tue, 04 Nov 2003 06:19:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09263 for ; Tue, 4 Nov 2003 06:18:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzDH-0003TJ-00 for enum@ietf.org; Tue, 04 Nov 2003 06:19:07 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AGzDH-0003TD-00 for enum@ietf.org; Tue, 04 Nov 2003 06:19:07 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 11:18:38 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPKNB; Tue, 4 Nov 2003 11:18:34 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 11:18:26 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 2 - Reservation of E2U Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, here's an issue we've come across when looking at ENUM domain content "out there". Some NAPTRs use the soon-to-be obsolescent (2916) syntax, whilst others use the syntax defined in 2916bis - (i.e. the E2U is at the rightmost or leftmost end of hte services field). As one should be 'liberal in what one accepts' (and both forms are "out there"), it is appropriate to process both forms. However, I think that this does mean that there should NOT be a valid ENUMservice with the token 'E2U' (or 'e2u' or 'e2U' or 'E2u'). [For those old enough, this is a shade of the JANET vs. 822 domain ordering issue] Does anyone have a burning desire to allow such an ENUMservice token, or instead can we ask IESG and/or IANA to reserve this token (or these tokens, if case sensitivity is required)? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 06:34:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09766 for ; Tue, 4 Nov 2003 06:34:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzRj-0005iF-7D for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 06:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4BY3Yh021927 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 06:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzRh-0005gf-74; Tue, 04 Nov 2003 06:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzQq-0005fE-5I for enum@optimus.ietf.org; Tue, 04 Nov 2003 06:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09707 for ; Tue, 4 Nov 2003 06:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzQm-0003gB-00 for enum@ietf.org; Tue, 04 Nov 2003 06:33:04 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AGzQl-0003ei-00 for enum@ietf.org; Tue, 04 Nov 2003 06:33:03 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 11:32:34 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPKN5; Tue, 4 Nov 2003 11:32:28 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 11:32:23 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 3 - service field in Non-final NAPTRs Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi folks, there don't seem to be any non-final NAPTRs "out there" yet and I'm not sure what should be the solution, so this is a pair of straight questions: Q: MUST a Client ignore the content of the service field in a non-final NAPTR (i.e. one with an empty flags field)? Q: MUST a Registrant NOT populate a non-final NAPTR with a non-empty services field? Background: We were unclear over whether or not a non-final NAPTR acted regardless of DDDS application, or instead it could include a non-empty services field, including E2U and, potentially, ENUMservice token(s). In the latter case, one could treat the non-final NAPTR as being DDDS Application specific and possibly even have more than one non-final NAPTR with each one being tied to a different application (e.g. one for E2U, one for D2U, one for ...). Furthermore, one could traverse the non-final if and only if the specified ENUMservice was supported by the Client. In effect, the intent of the Registrant would be "for contact info for the h323 ENUMservice within ENUM, look here" or "for contacts for the sip ENUMservice, look there". Against that, the Registrant might have decided to leave the services field of a non-final NAPTR blank, or the Client may choose to ignore the service field content in this case, so the Client has to be able to handle the other case (I guess as a "catch-all"). At present, we ignore the services field in our Clients, but I'm interested in the group's opinions. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 06:48:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10193 for ; Tue, 4 Nov 2003 06:48:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzfH-0006eo-7q for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 06:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Bm3h7025559 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 06:48:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzfF-0006dp-Hn; Tue, 04 Nov 2003 06:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzeO-0006c9-4l for enum@optimus.ietf.org; Tue, 04 Nov 2003 06:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10118 for ; Tue, 4 Nov 2003 06:46:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzeJ-0003rW-00 for enum@ietf.org; Tue, 04 Nov 2003 06:47:03 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AGzeJ-0003rE-00 for enum@ietf.org; Tue, 04 Nov 2003 06:47:03 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 11:46:34 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPK3S; Tue, 4 Nov 2003 11:46:28 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 11:46:23 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 4 - treatment of ORDER in NAPTRs with non-supported ENUMservices Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi folks, this one's pretty obscure, but it's tied to the way that Clients select from several possible contact choices. We have seen a few domains within which NAPTRs with different ORDER field values exist, and it's not always completely clear how to react (i.e there are corner cases like this). The ENUM Client can select which of a set of NAPTRs that share the same ("winning") ORDER field value based on its capabilities; thus, if it doesn't handle the ENUMservice h323, then even though this appears in a NAPTR with the best priority/preference, the Client can discard it and go on to the next best, and so on. However... Q: If the Client discards a NAPTR as it specifies an un-supported ENUMservice, then should the Client re-evaluate the "winning" ORDER field value after discarding the NAPTR containing the un-supported ENUMservice? Background: This came up as a corner case when we were testing non-final NAPTR processing - the "referred" domain had NAPTRs with a new "winning" Order field value, but none of the NAPTRs in that domain were supported, so should a Client "return" to try with lower preference/priority NAPTRs, or just give up, as it had hit one with a new "winning" Order value? Opinions gratefully received - at present, our client only considers the Order field value within a single RRset, so if no NAPTRs give useful results in a "recursive" call, it returns and continues with any unprocessed NAPTRs in the "referring" domain (i.e. the one with the non-final NAPTR). all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 07:08:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11047 for ; Tue, 4 Nov 2003 07:08:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzyh-0007xw-2n for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 07:08:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4C86Rt030582 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 07:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzyc-0007vT-25; Tue, 04 Nov 2003 07:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzxr-0007kB-NJ for enum@optimus.ietf.org; Tue, 04 Nov 2003 07:07:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11009 for ; Tue, 4 Nov 2003 07:07:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzxn-00049t-00 for enum@ietf.org; Tue, 04 Nov 2003 07:07:11 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AGzxk-00049k-00 for enum@ietf.org; Tue, 04 Nov 2003 07:07:09 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 12:06:39 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPKPR; Tue, 4 Nov 2003 12:06:32 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 12:06:25 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 5 - Treatment of Non-final loop in ENUM query Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi folks, (if you thought that issue 4 was obscure, this one's worse :). Another (pure implementation) issue with non-final NAPTR processing came up when (due to misconfiguration) we had a referential loop in a pair of non-final NAPTRs. A Client may detect a loop in an ENUM querie (e.g. there's a non-final NAPTR within 5.4.3.2.1.e164.arpa that points to domain a.example.com., and within a.example.com there's a non-final NAPTR that points "back" to 5.4.3.2.1.e164.arpa.). Q: If 5.4.3.2.1.e164.arpa contains some NAPTRs that are as-yet unprocessed when the initial "reference" is followed, then should the Client "return" to the "referencing" domain to process the remaining NAPTRs, or should it abort and give up on the whole query? Background: This one can get a bit more involved. The client may continue in the domain a.example.com looking for as-yet unprocessed NAPTRs, or might instead discard all remaining NAPTRs in that domain and "return" to the 5.4.3.2.1.e164.arpa. domain and look there. Where there are three non-finals in different domains, the Client has the choice to abort the whole non-final "recursion" and return to the original domain, or just go "one domain up" and continue with processing the domain that included the non-final that had the "bad" non-final. In our Client, we choose to continue with the domain that includes the "bad" non-final rather than either aborting the whole query or returning to the initial "top of the stack" domain. Although we (obviously) think that this is the way to go, I'd appreciate any opinions on whether or not this is the best approach. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 08:49:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14670 for ; Tue, 4 Nov 2003 08:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1YR-00072i-9D for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 08:49:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Dn750027049 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 08:49:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1YL-00071f-37; Tue, 04 Nov 2003 08:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1Xj-00070s-Nf for enum@optimus.ietf.org; Tue, 04 Nov 2003 08:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14622 for ; Tue, 4 Nov 2003 08:48:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH1Xi-0005m7-00 for enum@ietf.org; Tue, 04 Nov 2003 08:48:22 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AH1Xh-0005lF-00 for enum@ietf.org; Tue, 04 Nov 2003 08:48:22 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 13:47:49 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPK4W; Tue, 4 Nov 2003 13:47:47 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 13:47:47 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 6 - detection of Non-final loop in ENUM query Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi folks, here's another choice that Clients have to make when dealing with non-finals. Q: Is is necessary to keep a full "domain traversed" list for each ENUM query, or is it sufficient to just keep a "recursion count", detecting a loop by the count expiring? Q: If the latter is OK, then how many non-final domain traversals is reasonable for a query? Our Client currently sets a recurstion limit of 5, so that, if non-final references are encountered within an ENUM query, when the references are more than 4 deep it classifies this as a loop and continues where it left off (see issue 5 for the related question :). Can anyone think of a case where one might reasonably expect any deeper nesting, or where immediate loop detection is required? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 09:48:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16247 for ; Tue, 4 Nov 2003 09:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2TV-0001Tg-QJ for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 09:48:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Em5nT005665 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 09:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2TR-0001Ss-Aa; Tue, 04 Nov 2003 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2So-0001SU-92 for enum@optimus.ietf.org; Tue, 04 Nov 2003 09:47:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16227 for ; Tue, 4 Nov 2003 09:47:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH2Sm-0006Tp-00 for enum@ietf.org; Tue, 04 Nov 2003 09:47:20 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AH2Sl-0006TG-00 for enum@ietf.org; Tue, 04 Nov 2003 09:47:19 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 14:46:49 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPKWZ; Tue, 4 Nov 2003 14:46:43 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 14:46:43 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 7 - Order of evaluation of NAPTRs with equal preference/priority Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi folks, We have seen domains with more than one NAPTR with the same priority/preference field value "out there"; this shouldn't happen, but as we prefer to be liberal, how should a Client react? Again, this is a pure implementation issue; there doesn't seem to be anywhere in 2916bis or in 340x where this is explicitly barred, even though the WG discussions have suggested that it's a bad idea. Some of the affected domains are "published" via DNS servers that return responses in a fixed RRset pattern; examining the NAPTRs themselves, it looks like some folk assume that an "in order" processing is expected. Now...of course this is risky activity, as there's no guarantee of ordering, and a simple change of DNS server (or version) can remove the option of fixed delivery order, causing some strange results (i.e. Clients calling what were assumed to be lower contacts). In short, the simple answer is: "don't do it", but whilst there are some out there that do... We chose to treat NAPTRs with identical order and preference/priority field values in the order they were delivered. I can't see any harm in doing this, and if anyone can see a reason for random evaluation, please holler. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 10:48:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19432 for ; Tue, 4 Nov 2003 10:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3Pg-0004fO-Tk for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 10:48:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4FmCfJ017886 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 10:48:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3PV-0004da-SL; Tue, 04 Nov 2003 10:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3PI-0004Xw-4J for enum@optimus.ietf.org; Tue, 04 Nov 2003 10:47:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19391 for ; Tue, 4 Nov 2003 10:47:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3PF-0007I0-00 for enum@ietf.org; Tue, 04 Nov 2003 10:47:45 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AH3PF-0007H8-00 for enum@ietf.org; Tue, 04 Nov 2003 10:47:45 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 15:01:15 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPKXM; Tue, 4 Nov 2003 15:01:09 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 4 Nov 2003 15:00:59 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Impl.Issues: 8 - Evaluation order for NAPTR with multiple ENUservices Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi folks, one more issue; the only NAPTRs we've seen with more than one ENUMservice in them are ones tied to mobile phones, but it's a general implementation issue, so... Q: If a NAPTR contains more than one ENUMservice, should these ENUMservices be evaluated from left to right, or from right to left? Background: This matters, as the Registrant may populate NAPTRs in which they intend to specify that they prefer to receive an SMS, and only if this can't be done to receive a voice call. If these two ENUMservices are tied to the same URL (and have adjacent preferences) then a single NAPTR may be "published" holding both ENUMservices. However, should this be: 'E2U+sms:tel+voice:tel' '!^.*$!tel:44-767-123-4567' or instead: 'E2U+voice:tel+sms:tel' '!^.*$!tel:44-767-123-4567' Our Client chooses left-to-right evaluation order for NAPTRs with multiple ENUMservices. If anyone can think of a good reason to process right to left, please holler. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 10:58:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20078 for ; Tue, 4 Nov 2003 10:58:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3ZE-0005GU-Tx for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 10:58:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Fw4q0020221 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 10:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3ZB-0005Fb-Pz; Tue, 04 Nov 2003 10:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3YO-0005CC-QF for enum@optimus.ietf.org; Tue, 04 Nov 2003 10:57:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20042 for ; Tue, 4 Nov 2003 10:56:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3YM-0007Wh-00 for enum@ietf.org; Tue, 04 Nov 2003 10:57:10 -0500 Received: from gromit.rfc1035.com ([62.6.242.6]) by ietf-mx with esmtp (Exim 4.12) id 1AH3YK-0007WE-00 for enum@ietf.org; Tue, 04 Nov 2003 10:57:09 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [62.6.242.9]) by gromit.rfc1035.com (8.10.1/8.9.0) with ESMTP id hA4Fuph12639; Tue, 4 Nov 2003 15:56:51 GMT To: "Conroy, Lawrence (SMTP)" cc: enum@ietf.org Subject: Re: [Enum] Impl.Issues: 7 - Order of evaluation of NAPTRs with equal preference/priority In-reply-to: Your message of "Tue, 04 Nov 2003 14:46:43 GMT." Date: Tue, 04 Nov 2003 15:56:50 +0000 Message-ID: <12637.1067961410@gromit.rfc1035.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "lwc" == Conroy, Lawrence (SMTP) writes: lwc> Hi folks, We have seen domains with more than one NAPTR with lwc> the same priority/preference field value "out there"; this lwc> shouldn't happen, but as we prefer to be liberal, how should lwc> a Client react? Well there doesn't seem to be anything which prohibits NAPTRs for some name having identical priority/preference values and it wouldn't be reasonable to do so IMO. So in these cases, the client should figuratively toss a coin to make the decision, just like when mail software finds there's 2 or more equal preference MX records for some domain. lwc> Now...of course this is risky activity, as there's no lwc> guarantee of ordering, and a simple change of DNS server (or lwc> version) can remove the option of fixed delivery order, lwc> causing some strange results (i.e. Clients calling what were lwc> assumed to be lower contacts). In short, the simple answer is: lwc> "don't do it", but whilst there are some out there that do... I must be missing something. If the NAPTRs are equal, whoever is publishing them doesn't care which URI clients go to after they do a lookup. Therefore the client shouldn't need to be given rules to make it behave deterministically for these cases. A rule which says "select equal NAPTRs in the order they appear in the DNS response" is meaningless. [Though in practice this is what mail software tends to do when MX records are equal.] The reason for that is there could be a resolving name server between the client and the authoritative name server. So even if the authoritative server sends out responses with equal NAPTRs in some order, it can't be assumed that will be the order seen by an end client. A resolving server in between would almost certainly be doing round-robin on the stuff it hands out from its cache. There's also the distinct possibility that authoritative name servers for some ENUM zone could be sending out responses with equal NAPTRs in a different order, say because they use different DNS implementations. Even in the case where the ordering in responses is always the same, I don't think it's necessary for 2916bis or whatever to tell the client which one to choose. The publisher of the NAPTR records could/should have done that by explictly giving them different priority and/or preference fields. Presumably that publisher had a reason for making the NAPTRs equal and therefore left it up to the client to choose based on whatever criteria it felt like applying. It would worthwhile documenting this: "when NAPTRs are equal, a client is free to choose any one of the RRs according to its own criteria which may or may not be random." _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 11:16:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20932 for ; Tue, 4 Nov 2003 11:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3qg-0006em-9P for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 11:16:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4GG6ps025564 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 11:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3qc-0006dX-P4; Tue, 04 Nov 2003 11:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3pt-0006cI-36 for enum@optimus.ietf.org; Tue, 04 Nov 2003 11:15:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20885 for ; Tue, 4 Nov 2003 11:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3ps-00002H-00 for enum@ietf.org; Tue, 04 Nov 2003 11:15:16 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AH3pr-0007nl-00 for enum@ietf.org; Tue, 04 Nov 2003 11:15:15 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 16:14:45 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPK65; Tue, 4 Nov 2003 16:14:41 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: Jim Reid Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <12637.1067961410@gromit.rfc1035.com> References: <12637.1067961410@gromit.rfc1035.com> Date: Tue, 4 Nov 2003 16:14:41 +0000 Subject: Re: [Enum] Impl.Issues: 7 - Order of evaluation of NAPTRs with equal preference/priority Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Jim, folks, Thanks Jim for the detailed comments. I report only what I've seen. I didn't say it was sensible. I did say that this is just a pure implementation issue - I'd share your unhappiness if any such admonition were to be added to a standards track doc. I stated what ours did, and I asked if there were any good reasons for randomising evaluation - I didn't see a "don't do this" in your comments, which I take to mean we aren't doing anything badly dodgy (or the mail software is as well, which would explain some things). A Result. all the best, Lawrence At 3:56 pm +0000 4/11/03, Jim Reid wrote: > >>>>> "lwc" == Conroy, Lawrence (SMTP) writes: > > lwc> Hi folks, We have seen domains with more than one NAPTR with > lwc> the same priority/preference field value "out there"; this > lwc> shouldn't happen, but as we prefer to be liberal, how should > lwc> a Client react? > >Well there doesn't seem to be anything which prohibits NAPTRs for some >name having identical priority/preference values and it wouldn't be >reasonable to do so IMO. So in these cases, the client should >figuratively toss a coin to make the decision, just like when mail >software finds there's 2 or more equal preference MX records for some >domain. > > lwc> Now...of course this is risky activity, as there's no > lwc> guarantee of ordering, and a simple change of DNS server (or > lwc> version) can remove the option of fixed delivery order, > lwc> causing some strange results (i.e. Clients calling what were > lwc> assumed to be lower contacts). In short, the simple answer is: > lwc> "don't do it", but whilst there are some out there that do... > >I must be missing something. If the NAPTRs are equal, whoever is >publishing them doesn't care which URI clients go to after they do a >lookup. Therefore the client shouldn't need to be given rules to make >it behave deterministically for these cases. > >A rule which says "select equal NAPTRs in the order they appear in the >DNS response" is meaningless. [Though in practice this is what mail >software tends to do when MX records are equal.] The reason for that >is there could be a resolving name server between the client and the >authoritative name server. So even if the authoritative server sends >out responses with equal NAPTRs in some order, it can't be assumed >that will be the order seen by an end client. A resolving server in >between would almost certainly be doing round-robin on the stuff it >hands out from its cache. There's also the distinct possibility that >authoritative name servers for some ENUM zone could be sending out >responses with equal NAPTRs in a different order, say because they use >different DNS implementations. > >Even in the case where the ordering in responses is always the same, I >don't think it's necessary for 2916bis or whatever to tell the client >which one to choose. The publisher of the NAPTR records could/should >have done that by explictly giving them different priority and/or >preference fields. Presumably that publisher had a reason for making >the NAPTRs equal and therefore left it up to the client to choose >based on whatever criteria it felt like applying. It would worthwhile >documenting this: "when NAPTRs are equal, a client is free to choose >any one of the RRs according to its own criteria which may or may not >be random." > -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 11:40:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21773 for ; Tue, 4 Nov 2003 11:40:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Dt-00083i-VX for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 11:40:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Ge53o030898 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 11:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Dq-00081s-Cd; Tue, 04 Nov 2003 11:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Ct-000813-RF for enum@optimus.ietf.org; Tue, 04 Nov 2003 11:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21693 for ; Tue, 4 Nov 2003 11:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4Cs-0000OP-00 for enum@ietf.org; Tue, 04 Nov 2003 11:39:02 -0500 Received: from sip.mah.priv.at ([81.223.16.194] helo=www.mah.priv.at) by ietf-mx with esmtp (Exim 4.12) id 1AH4Cs-0000Nz-00 for enum@ietf.org; Tue, 04 Nov 2003 11:39:02 -0500 Received: from localhost ([127.0.0.1] helo=mah9.eunet.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1AH4CF-0007Sa-00 for ; Tue, 04 Nov 2003 17:38:23 +0100 Message-Id: <5.2.0.9.2.20031104173523.051439f8@localhost> X-Sender: mah#inode.at@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Nov 2003 17:38:20 +0100 To: enum@ietf.org From: Michael Haberler Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-781F6BA4; boundary="=======73C6C9F=======" Subject: [Enum] Prototype of ENUM validation system online Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --=======73C6C9F======= Content-Type: text/plain; x-avg-checked=avg-ok-781F6BA4; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit over summer we developed a distributed authentication architecture for ENUM validation based on the RADIUS protocol, which was described in http://enum.nic.at/documents/AETP/Permanent_Documents/Drafts/0030-ENUM_validation_architecture_v04.doc . Otmar Lendl has just finished a prototype as proof-of-concept of this design and this prototype is now online. The presentation is available at http://enum.nic.at/documents/AETP/Presentations/Austria/0026-2003-11_ENUM-Validation-demo.ppt The demo system is online for your perusal at http://samuel.ops.at43.at/ . The documentation for this demo software is at http://samuel.ops.at43.at/docs/ we're very interested in comments & feedback. One aspect which I should underline - the method is intended to work also in the face of telcos which just ignore ENUM, in which case another validation entities take their role; this will not be necessarily more efficient but is important for consumer choice. The point is that there might be more than one "TSP" validating a given number. -Michael Haberler --=======73C6C9F=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Nov 4 12:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22879 for ; Tue, 4 Nov 2003 12:04:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4b7-0002LK-D3 for enum-archive@odin.ietf.org; Tue, 04 Nov 2003 12:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4H45u9009000 for enum-archive@odin.ietf.org; Tue, 4 Nov 2003 12:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4b3-0002IY-04; Tue, 04 Nov 2003 12:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4as-0002IE-7N for enum@optimus.ietf.org; Tue, 04 Nov 2003 12:03:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22841 for ; Tue, 4 Nov 2003 12:03:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4ao-0000nZ-00 for enum@ietf.org; Tue, 04 Nov 2003 12:03:46 -0500 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AH4ad-0000mX-00 for enum@ietf.org; Tue, 04 Nov 2003 12:03:46 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hA4Gj0ob013650 for ; Tue, 4 Nov 2003 12:03:01 -0500 Received: from acclust02evs1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 3FA53961000A4A9C; Tue, 4 Nov 2003 12:00:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Prototype of ENUM validation system online Date: Tue, 4 Nov 2003 12:03:00 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A055D0237@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] Prototype of ENUM validation system online Thread-Index: AcOi8n7HSi0GfsnkSbeQR4sckusq3AAAhklA From: "Pfautz, Penn L, ALABS" To: "Michael Haberler" , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Michael: Thanks for this interesting document. Validation is a problem we = grappled with some in the US ENUM Forum. The trick of course is to get = the TSP to cooperate in the process. In the US it is not even possible = to determine from publicly available information who is the TSP. Then = there is the issue of how much the TSP will charge for assisting in the = verification process. So we'll be watching experience with great = interest. Penn Pfautz AT&T -----Original Message----- From: Michael Haberler [mailto:mah@eunet.at] Sent: Tuesday, November 04, 2003 11:38 AM To: enum@ietf.org Subject: [Enum] Prototype of ENUM validation system online over summer we developed a distributed authentication architecture for = ENUM=20 validation based on the RADIUS protocol, which was described in=20 http://enum.nic.at/documents/AETP/Permanent_Documents/Drafts/0030-ENUM_va= lidation_architecture_v04.doc=20 . Otmar Lendl has just finished a prototype as proof-of-concept of this=20 design and this prototype is now online. The presentation is available at=20 http://enum.nic.at/documents/AETP/Presentations/Austria/0026-2003-11_ENUM= -Validation-demo.ppt The demo system is online for your perusal at http://samuel.ops.at43.at/ = . The documentation for this demo software is at = http://samuel.ops.at43.at/docs/ we're very interested in comments & feedback. One aspect which I should underline - the method is intended to work = also=20 in the face of telcos which just ignore ENUM, in which case another=20 validation entities take their role; this will not be necessarily more=20 efficient but is important for consumer choice. The point is that there=20 might be more than one "TSP" validating a given number. -Michael Haberler _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Nov 5 10:39:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10473 for ; Wed, 5 Nov 2003 10:39:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPke-0000Ih-VI for enum-archive@odin.ietf.org; Wed, 05 Nov 2003 10:39:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5FdKE6001149 for enum-archive@odin.ietf.org; Wed, 5 Nov 2003 10:39:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPkL-0000HK-56; Wed, 05 Nov 2003 10:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPk5-0000H1-6F for enum@optimus.ietf.org; Wed, 05 Nov 2003 10:38:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10458 for ; Wed, 5 Nov 2003 10:38:31 -0500 (EST) From: Olivier.Girard@bakom.admin.ch Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPk2-0005to-00 for enum@ietf.org; Wed, 05 Nov 2003 10:38:42 -0500 Received: from fwigk1.admin.ch ([193.5.216.70] helo=mag06.bb.admin.ch) by ietf-mx with esmtp (Exim 4.12) id 1AHPk2-0005th-00 for enum@ietf.org; Wed, 05 Nov 2003 10:38:42 -0500 Received: from mar01.bb.admin.ch (mar01.bb.admin.ch [193.5.222.71]) by mag06.bb.admin.ch (8.12.10/8.12.10) with ESMTP id hA5FcWQn028604; Wed, 5 Nov 2003 16:38:32 +0100 (MET) Received: from mas21.bb.admin.ch (mas21.bb.admin.ch [193.5.222.82]) by mar01.bb.admin.ch (8.12.10/8.12.10) with SMTP id hA5FcSUj008708; Wed, 5 Nov 2003 16:38:32 +0100 (MET) Received: by ad01007exc.ad.admin.ch with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Nov 2003 16:38:28 +0100 Message-ID: To: ppfautz@att.com, mah@eunet.at, enum@ietf.org Subject: RE : [Enum] Prototype of ENUM validation system online Date: Wed, 5 Nov 2003 16:38:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Colleagues,=20 The best thing would be to have a validation process totally = independent from the TSP... This is not possible as long as the TSP will be = responsible for the allocation of individual E.164 numbers to customers.=20 What about a direct allocation of E.164 numbers to the customers based = on the model used for Internet domain names ? This could be done directly by the Authority managing the E.164 = ressources in a country... In this scenario, the Authority would also have the = control of information related to the numbers like e.g. directory data and = could give anyone access to those data at a fair price...! :o) And as this solution require a centralized database, some information (like who is = the TSP for a given number) could also be made available to any service or application provider...=20 I know, I'm dreaming... :o)=20 Best,=20 olivier -----Message d'origine----- De : Pfautz, Penn L, ALABS [mailto:ppfautz@att.com]=20 Envoy=E9 : mardi, 4. novembre 2003 18:03 =C0 : Michael Haberler; enum@ietf.org Objet : RE: [Enum] Prototype of ENUM validation system online Michael: Thanks for this interesting document. Validation is a problem we = grappled with some in the US ENUM Forum. The trick of course is to get the TSP = to cooperate in the process. In the US it is not even possible to = determine from publicly available information who is the TSP. Then there is the = issue of how much the TSP will charge for assisting in the verification = process. So we'll be watching experience with great interest. Penn Pfautz AT&T -----Original Message----- From: Michael Haberler [mailto:mah@eunet.at] Sent: Tuesday, November 04, 2003 11:38 AM To: enum@ietf.org Subject: [Enum] Prototype of ENUM validation system online over summer we developed a distributed authentication architecture for = ENUM=20 validation based on the RADIUS protocol, which was described in=20 http://enum.nic.at/documents/AETP/Permanent_Documents/Drafts/0030-ENUM_v= alid ation_architecture_v04.doc=20 . Otmar Lendl has just finished a prototype as proof-of-concept of this=20 design and this prototype is now online. The presentation is available at=20 http://enum.nic.at/documents/AETP/Presentations/Austria/0026-2003-11_ENU= M-Va lidation-demo.ppt The demo system is online for your perusal at = http://samuel.ops.at43.at/ . The documentation for this demo software is at http://samuel.ops.at43.at/docs/ we're very interested in comments & feedback. One aspect which I should underline - the method is intended to work = also=20 in the face of telcos which just ignore ENUM, in which case another=20 validation entities take their role; this will not be necessarily more=20 efficient but is important for consumer choice. The point is that there = might be more than one "TSP" validating a given number. -Michael Haberler _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Nov 5 10:52:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10950 for ; Wed, 5 Nov 2003 10:52:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPwx-0001BS-St for enum-archive@odin.ietf.org; Wed, 05 Nov 2003 10:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Fq3Fk004533 for enum-archive@odin.ietf.org; Wed, 5 Nov 2003 10:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPwv-0001Aa-VB; Wed, 05 Nov 2003 10:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPwh-00018m-5I for enum@optimus.ietf.org; Wed, 05 Nov 2003 10:51:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10910 for ; Wed, 5 Nov 2003 10:51:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPwe-00063c-00 for enum@ietf.org; Wed, 05 Nov 2003 10:51:44 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1AHPwd-00063K-00 for enum@ietf.org; Wed, 05 Nov 2003 10:51:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Subject: RE : [Enum] Prototype of ENUM validation system online MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Nov 2003 16:56:24 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233967@oefeg-s02.oefeg.loc> Thread-Topic: RE : [Enum] Prototype of ENUM validation system online Thread-Index: AcOjs8peggl7HYtOSwWj42Vdu/fdyQAAJxtw From: "Stastny Richard" To: , , , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Oliver, you are running in open doors. That was exactly the proposal we made to = our regulator, considering that all numbers are portable now anyway, so the assigee = could the end-user itself, and he is then selecting his provider, as it is alredy done with service = numbers. This would not imply much changes in practice, because normally the TSP = would also be the 'registrar', but we could use the existing DNS Registry = technology to handle the transactions, as you proposed. Our regulator did not reject the proposal immediately, but pointed out = some legal and=20 procedural problems to be solved (currently every number assigned not in = bulk yoi need a single legal paper (Bescheid). At least we are discussing to try this model with the number range for = ENUM. I will bring forward some more information on the current level of = discussion to the ECC meeting in Biel on NNA. best regards Richard > -----Original Message----- > From: Olivier.Girard@bakom.admin.ch=20 > [mailto:Olivier.Girard@bakom.admin.ch]=20 > Sent: Wednesday, November 05, 2003 4:38 PM > To: ppfautz@att.com; mah@eunet.at; enum@ietf.org > Subject: RE : [Enum] Prototype of ENUM validation system online >=20 >=20 > Dear Colleagues,=20 >=20 > The best thing would be to have a validation process totally=20 > independent from the TSP... This is not possible as long as=20 > the TSP will be responsible for the allocation of individual=20 > E.164 numbers to customers.=20 >=20 > What about a direct allocation of E.164 numbers to the=20 > customers based on the model used for Internet domain names ? >=20 > This could be done directly by the Authority managing the=20 > E.164 ressources in a country... In this scenario, the=20 > Authority would also have the control of information related=20 > to the numbers like e.g. directory data and could give anyone=20 > access to those data at a fair price...! :o) And as this=20 > solution require a centralized database, some information=20 > (like who is the TSP for a given number) could also be made=20 > available to any service or application provider...=20 >=20 > I know, I'm dreaming... :o)=20 >=20 > Best,=20 >=20 > olivier >=20 >=20 > -----Message d'origine----- > De : Pfautz, Penn L, ALABS [mailto:ppfautz@att.com]=20 > Envoy=E9 : mardi, 4. novembre 2003 18:03 > =C0 : Michael Haberler; enum@ietf.org > Objet : RE: [Enum] Prototype of ENUM validation system online >=20 >=20 > Michael: > Thanks for this interesting document. Validation is a problem=20 > we grappled with some in the US ENUM Forum. The trick of=20 > course is to get the TSP to cooperate in the process. In the=20 > US it is not even possible to determine from publicly=20 > available information who is the TSP. Then there is the issue=20 > of how much the TSP will charge for assisting in the=20 > verification process. So we'll be watching experience with=20 > great interest. >=20 > Penn Pfautz > AT&T >=20 > -----Original Message----- > From: Michael Haberler [mailto:mah@eunet.at] > Sent: Tuesday, November 04, 2003 11:38 AM > To: enum@ietf.org > Subject: [Enum] Prototype of ENUM validation system online >=20 >=20 > over summer we developed a distributed authentication=20 > architecture for ENUM=20 > validation based on the RADIUS protocol, which was described in=20 > http://enum.nic.at/documents/AETP/Permanent_Documents/Drafts/0 030-ENUM_valid ation_architecture_v04.doc=20 . Otmar Lendl has just finished a prototype as proof-of-concept of this=20 design and this prototype is now online. The presentation is available at=20 http://enum.nic.at/documents/AETP/Presentations/Austria/0026-2003-11_ENUM= -Va lidation-demo.ppt The demo system is online for your perusal at http://samuel.ops.at43.at/ = . The documentation for this demo software is at = http://samuel.ops.at43.at/docs/ we're very interested in comments & feedback. One aspect which I should underline - the method is intended to work = also=20 in the face of telcos which just ignore ENUM, in which case another=20 validation entities take their role; this will not be necessarily more=20 efficient but is important for consumer choice. The point is that there=20 might be more than one "TSP" validating a given number. -Michael Haberler _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Nov 5 13:48:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16695 for ; Wed, 5 Nov 2003 13:48:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHShU-0003XX-1u for enum-archive@odin.ietf.org; Wed, 05 Nov 2003 13:48:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5ImFAq013556 for enum-archive@odin.ietf.org; Wed, 5 Nov 2003 13:48:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHShG-0003Sg-GK; Wed, 05 Nov 2003 13:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSgj-0003Rx-Th for enum@optimus.ietf.org; Wed, 05 Nov 2003 13:47:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16586 for ; Wed, 5 Nov 2003 13:47:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSgh-0000av-00 for enum@ietf.org; Wed, 05 Nov 2003 13:47:27 -0500 Received: from gromit.rfc1035.com ([62.6.242.6]) by ietf-mx with esmtp (Exim 4.12) id 1AHSgg-0000as-00 for enum@ietf.org; Wed, 05 Nov 2003 13:47:27 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [62.6.242.6]) by gromit.rfc1035.com (8.10.1/8.9.0) with ESMTP id hA5Il2h01043; Wed, 5 Nov 2003 18:47:02 GMT To: Olivier.Girard@bakom.admin.ch cc: ppfautz@att.com, mah@eunet.at, enum@ietf.org Subject: Re: RE : [Enum] Prototype of ENUM validation system online In-reply-to: Your message of "Wed, 05 Nov 2003 16:38:21 +0100." Date: Wed, 05 Nov 2003 18:47:00 +0000 Message-ID: <1040.1068058020@gromit.rfc1035.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Olivier" == Olivier Girard writes: Olivier> What about a direct allocation of E.164 numbers to the Olivier> customers based on the model used for Internet domain Olivier> names ? What model is that? On the internet, anyone can pretty much register any domain name they want with little or no authentication beyond a credit card number for payment. Is this what you're suggesting for the registration of E.164 numbers? Now it might be nice for the regulator to administer ENUM delegations but this is likely to be impractical for a number of reasons. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Nov 6 03:09:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27979 for ; Thu, 6 Nov 2003 03:09:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfCk-00040S-3v for enum-archive@odin.ietf.org; Thu, 06 Nov 2003 03:09:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA689MvD015342 for enum-archive@odin.ietf.org; Thu, 6 Nov 2003 03:09:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfCP-0003uV-Kd; Thu, 06 Nov 2003 03:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfBP-0003es-0O for enum@optimus.ietf.org; Thu, 06 Nov 2003 03:07:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27901 for ; Thu, 6 Nov 2003 03:07:46 -0500 (EST) From: Olivier.Girard@bakom.admin.ch Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHfBK-0004TE-00 for enum@ietf.org; Thu, 06 Nov 2003 03:07:54 -0500 Received: from fwigk1.admin.ch ([193.5.216.70] helo=mag06.bb.admin.ch) by ietf-mx with esmtp (Exim 4.12) id 1AHfBK-0004TB-00 for enum@ietf.org; Thu, 06 Nov 2003 03:07:54 -0500 Received: from mar01.bb.admin.ch (mar01.bb.admin.ch [193.5.222.71]) by mag06.bb.admin.ch (8.12.10/8.12.10) with ESMTP id hA687oQn013817; Thu, 6 Nov 2003 09:07:50 +0100 (MET) Received: from mas22.bb.admin.ch (mas22.bb.admin.ch [193.5.222.83]) by mar01.bb.admin.ch (8.12.10/8.12.10) with SMTP id hA687kUj003802; Thu, 6 Nov 2003 09:07:50 +0100 (MET) Received: by ad01008exc.ad.admin.ch with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Nov 2003 09:07:45 +0100 Message-ID: To: jim@rfc1035.com Cc: ppfautz@att.com, mah@eunet.at, enum@ietf.org Subject: RE : RE : [Enum] Prototype of ENUM validation system online Date: Thu, 6 Nov 2003 09:07:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jim,=20 No. What I suggest is that the individual E.164 numbers be allocated directly to the end users. Once done, the customer may contact one (or = more) operator or service provider in order to implement his number for the service(s) he wants to have. The regulator does not intend to administer ENUM delegations. Best regards,=20 olivier =20 -----Message d'origine----- De : Jim Reid [mailto:jim@rfc1035.com]=20 Envoy=E9 : mercredi, 5. novembre 2003 19:47 =C0 : Olivier.Girard@bakom.admin.ch Cc : ppfautz@att.com; mah@eunet.at; enum@ietf.org Objet : Re: RE : [Enum] Prototype of ENUM validation system online=20 >>>>> "Olivier" =3D=3D Olivier Girard =20 >>>>> writes: Olivier> What about a direct allocation of E.164 numbers to the Olivier> customers based on the model used for Internet domain Olivier> names ? What model is that? On the internet, anyone can pretty much register = any domain name they want with little or no authentication beyond a credit = card number for payment. Is this what you're suggesting for the registration = of E.164 numbers? Now it might be nice for the regulator to administer ENUM delegations = but this is likely to be impractical for a number of reasons. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Nov 6 04:24:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00350 for ; Thu, 6 Nov 2003 04:24:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgNY-0007wG-4f for enum-archive@odin.ietf.org; Thu, 06 Nov 2003 04:24:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69OZo3030462 for enum-archive@odin.ietf.org; Thu, 6 Nov 2003 04:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgNK-0007mp-N7; Thu, 06 Nov 2003 04:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfVl-0004pn-SR for enum@optimus.ietf.org; Thu, 06 Nov 2003 03:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28513 for ; Thu, 6 Nov 2003 03:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHfVj-0004jI-00 for enum@ietf.org; Thu, 06 Nov 2003 03:28:59 -0500 Received: from internal.mail.demon.net ([193.195.224.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHfVi-0004im-00 for enum@ietf.org; Thu, 06 Nov 2003 03:28:59 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id hA68U6q15300; Thu, 6 Nov 2003 08:30:06 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1AHfVB-0007M8-00; Thu, 06 Nov 2003 08:28:25 +0000 Date: Thu, 6 Nov 2003 08:28:25 +0000 From: "Clive D.W. Feather" To: Olivier.Girard@bakom.admin.ch Cc: ppfautz@att.com, mah@eunet.at, enum@ietf.org Subject: Re: RE : [Enum] Prototype of ENUM validation system online Message-ID: <20031106082825.GL69447@finch-staff-1.thus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Olivier.Girard@bakom.admin.ch said: > The best thing would be to have a validation process totally independent > from the TSP... This is not possible as long as the TSP will be responsible > for the allocation of individual E.164 numbers to customers. > > What about a direct allocation of E.164 numbers to the customers based on > the model used for Internet domain names ? > > This could be done directly by the Authority managing the E.164 ressources > in a country... Can you say "political minefield"? I don't have time to write a full explanation of the history and issues, but a proposal like that would simply result in Enum being seen, by UK telcos, as "a stupid idea from a bunch of complete idiots". -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Nov 6 06:00:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04033 for ; Thu, 6 Nov 2003 06:00:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhsA-0007cE-5l for enum-archive@odin.ietf.org; Thu, 06 Nov 2003 06:00:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6B0HBW029208 for enum-archive@odin.ietf.org; Thu, 6 Nov 2003 06:00:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhrw-0007Xw-Na; Thu, 06 Nov 2003 06:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhrb-0007Vx-JS for enum@optimus.ietf.org; Thu, 06 Nov 2003 05:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03995 for ; Thu, 6 Nov 2003 05:59:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHhrX-00071s-00 for enum@ietf.org; Thu, 06 Nov 2003 05:59:39 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AHhrX-00070t-00 for enum@ietf.org; Thu, 06 Nov 2003 05:59:39 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Nov 2003 10:59:09 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPMPS; Thu, 6 Nov 2003 10:59:04 -0000 From: "Conroy, Lawrence (SMTP)" To: Stastny Richard , "Clive D.W. Feather" , Olivier.Girard@bakom.admin.ch Cc: ppfautz@att.com, mah@eunet.at, enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <06CF906FE3998C4E944213062009F16223396E@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F16223396E@oefeg-s02.oefeg.loc> Date: Thu, 6 Nov 2003 10:58:56 +0000 Subject: RE: RE : [Enum] Prototype of ENUM validation system online Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 10:51 am +0100 6/11/03, Richard wrote: >See inline: > > > -----Original Message----- > > From: Clive D.W. Feather [mailto:clive@demon.net] > > I don't have time to write a full explanation of the history >> and issues, but a proposal like that would simply result in >> Enum being seen, by UK telcos, as "a stupid idea from a bunch >> of complete idiots". > >Hold on, currently service numbers are already given to the end-users >directly. What is proposed here >by Oliver is to do the same for portable geo and mobile numbers also. >This has nothing to do with ENUM. Hi Folks, two comments - to all in this thread - Richard's comment is well put - how does this fit into the IETF ENUM WG? to Clive - how would the proposal change the the level of activity (or views) of the players in the UK? I'm puzzled here... I think that there is still the embedded assumption that an individual has a right to use a phone number, so I can't select 'Whitehall 1212' as a number I can register. We still need proof that the number is assigned to a person, and that the person making the registration request IS that person to whom a number is assigned. The difference lies only in the place from where we get the proof of assignment. I think that there is still the embedded assumption that the registration is valid only if the number is active (i.e. it has Telephony Service from a provider), so we also need proof that there is an active Telephony Service associated with the number. I'd be very interested if folk don't have those assumptions, but I would have thought that such a change would be a topic for the ITU (or ETSI, or the EU/FCC/...) and the IAB rather that the IETF. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Nov 6 06:18:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04302 for ; Thu, 6 Nov 2003 06:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHi9L-0008V1-Ty for enum-archive@odin.ietf.org; Thu, 06 Nov 2003 06:18:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6BI3PW032632 for enum-archive@odin.ietf.org; Thu, 6 Nov 2003 06:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHi9J-0008Ty-UG; Thu, 06 Nov 2003 06:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHi8j-0008TZ-Fs for enum@optimus.ietf.org; Thu, 06 Nov 2003 06:17:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04291 for ; Thu, 6 Nov 2003 06:17:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHi8f-0007Ct-00 for enum@ietf.org; Thu, 06 Nov 2003 06:17:21 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1AHi8e-0007Cb-00 for enum@ietf.org; Thu, 06 Nov 2003 06:17:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Subject: RE: RE : [Enum] Prototype of ENUM validation system online MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Nov 2003 12:22:04 +0100 Message-ID: <06CF906FE3998C4E944213062009F16223396F@oefeg-s02.oefeg.loc> Thread-Topic: RE : [Enum] Prototype of ENUM validation system online Thread-Index: AcOkVchxY6aDd3OyQiei+cRH7049zwAABY4g From: "Stastny Richard" To: "Conroy, Lawrence (SMTP)" , "Clive D.W. Feather" , Cc: , , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Lawrence wrote: > I'm puzzled here... > I think that there is still the embedded assumption that an=20 > individual has a right > to use a phone number, so I can't select 'Whitehall 1212' as a number=20 > I can register. > We still need proof that the number is assigned to a person, and that=20 > the person > making the registration request IS that person to whom a number is=20 > assigned. The > difference lies only in the place from where we get the proof=20 > of assignment. This is still valid for opt-in numbers >=20 > I think that there is still the embedded assumption that the=20 > registration is valid > only if the number is active (i.e. it has Telephony Service from a=20 > provider), so > we also need proof that there is an active Telephony Service=20 > associated with the number. Again for opt-in numbers >=20 > I'd be very interested if folk don't have those assumptions, but I=20 > would have thought > that such a change would be a topic for the ITU (or ETSI, or the=20 > EU/FCC/...) and the IAB > rather that the IETF. >=20 But if you consider numbers for VoIP and ENUM where ENUM IS the service, the whole thing is turning around. You have the service only if there is an entry in ENUM. So getting the ENUM domain AND the E.164 number is one step, so there is no need for valtdation and re-validation. Once again: with the entry in e164.arpa you get the telephony service and the number and this is linked 1:1. If you give back the domain, the service ceases to exist. The above mentioned prove of identitty is the same if you subscribe to a telephony service not more and not less (You fill out a form and fax it or submit it). Has anybody checked when you subscribed your phone if you are the person you pretend to be? Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Nov 6 16:05:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00901 for ; Thu, 6 Nov 2003 16:05:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrJS-0003lx-QB for enum-archive@odin.ietf.org; Thu, 06 Nov 2003 16:05:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6L56Ed014451 for enum-archive@odin.ietf.org; Thu, 6 Nov 2003 16:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrIP-0003hq-MS; Thu, 06 Nov 2003 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrI9-0003hK-WB for enum@optimus.ietf.org; Thu, 06 Nov 2003 16:03:46 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00855 for ; Thu, 6 Nov 2003 16:03:33 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AHrAO-0002Vo-F3; Thu, 06 Nov 2003 15:55:44 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: enum@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 06 Nov 2003 15:55:44 -0500 Subject: [Enum] Last Call: 'enumservice registration for SIP Addresses-of-Record' to Proposed Standard Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'enumservice registration for SIP Addresses-of-Record ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-00.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Nov 6 16:11:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01109 for ; Thu, 6 Nov 2003 16:11:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrPG-0004Fp-Gu for enum-archive@odin.ietf.org; Thu, 06 Nov 2003 16:11:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6LB6CX016302 for enum-archive@odin.ietf.org; Thu, 6 Nov 2003 16:11:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrPB-0004DC-Px; Thu, 06 Nov 2003 16:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrOQ-0004Bh-G1 for enum@optimus.ietf.org; Thu, 06 Nov 2003 16:10:14 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01001 for ; Thu, 6 Nov 2003 16:10:02 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AHrEy-0003CH-3y; Thu, 06 Nov 2003 16:00:28 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: enum@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 06 Nov 2003 16:00:28 -0500 Subject: [Enum] Last Call: 'ENUM Service Registration for H.323 URL' to Proposed Standard Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'ENUM Service Registration for H.323 URL ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-01.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Nov 14 09:52:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12157 for ; Fri, 14 Nov 2003 09:52:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfJP-0003LB-Cg for enum-archive@odin.ietf.org; Fri, 14 Nov 2003 09:52:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEEqdiN012790 for enum-archive@odin.ietf.org; Fri, 14 Nov 2003 09:52:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfIm-0003HR-HI; Fri, 14 Nov 2003 09:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfHz-0003Ek-DC for enum@optimus.ietf.org; Fri, 14 Nov 2003 09:51:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12085 for ; Fri, 14 Nov 2003 09:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfHx-00069s-00 for enum@ietf.org; Fri, 14 Nov 2003 09:51:09 -0500 Received: from sip.mah.priv.at ([81.223.16.194] helo=www.mah.priv.at) by ietf-mx with esmtp (Exim 4.12) id 1AKfHw-00069T-00 for enum@ietf.org; Fri, 14 Nov 2003 09:51:09 -0500 Received: from localhost ([127.0.0.1] helo=mah9.eunet.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1AKfHL-0001BA-00; Fri, 14 Nov 2003 15:50:31 +0100 Message-Id: <5.2.0.9.2.20031114154814.0419c260@localhost> X-Sender: mah#inode.at@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Nov 2003 15:50:32 +0100 To: enum@ietf.org, enum-trials@ripe.net, enum-trial@lists.nic.at, jeff Pulver From: Michael Haberler Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-292D5D63; boundary="=======64C96F26=======" Subject: [Enum] paper on the at43 IP communications platform Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --=======64C96F26======= Content-Type: text/plain; x-avg-checked=avg-ok-292D5D63; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit an English paper describing our at43 ENUM-enabled IP communications platform operated with the University of Vienna is now online at http://enum.nic.at/documents/AETP/Presentations/Other/0020-The_at43_broadband_IP_communications_platform.pdf -Micahel Haberler --=======64C96F26=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Nov 14 10:25:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15544 for ; Fri, 14 Nov 2003 10:25:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfp0-0006CR-Lk for enum-archive@odin.ietf.org; Fri, 14 Nov 2003 10:25:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFPI3G023786 for enum-archive@odin.ietf.org; Fri, 14 Nov 2003 10:25:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfnk-00063F-Qr; Fri, 14 Nov 2003 10:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfnT-00062m-Ji for enum@optimus.ietf.org; Fri, 14 Nov 2003 10:23:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15459 for ; Fri, 14 Nov 2003 10:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfnR-0006yG-00 for enum@ietf.org; Fri, 14 Nov 2003 10:23:41 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1AKfnQ-0006xq-00 for enum@ietf.org; Fri, 14 Nov 2003 10:23:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 14 Nov 2003 16:28:19 +0100 Message-ID: <06CF906FE3998C4E944213062009F1622339A6@oefeg-s02.oefeg.loc> Thread-Topic: IETF58 ENUM WG slides for enum-voip-numbering Thread-Index: AcOqw+7MQ0GYy4yzS1yXwIX3kp2blA== From: "Stastny Richard" To: Content-Transfer-Encoding: base64 Subject: [Enum] IETF58 ENUM WG slides for enum-voip-numbering Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNCnRoZSBwcmVzZW50YXRpb24gaGVsZCBhdCB0aGUgSUVURjU4IEVOVU0gV0cg b24gdGhlIEktRA0KIGh0dHA6Ly9lbnVtLm5pYy5hdC9kb2N1bWVudHMvSUVURi9JbnRlcm5ldF9E cmFmdHMvZHJhZnQtc3Rhc3RueS1lbnVtLW51bWJlcmluZy12b2lwLTAwLnR4dCA8aHR0cDovL2Vu dW0ubmljLmF0L2RvY3VtZW50cy9JRVRGL0ludGVybmV0X0RyYWZ0cy9kcmFmdC1zdGFzdG55LWVu dW0tbnVtYmVyaW5nLXZvaXAtMDAudHh0PiANCiAgICAgICANCmlzIGF2YWlsYWJsZSBhdA0KaHR0 cDovL2VudW0ubmljLmF0L2RvY3VtZW50cy9BRVRQL1ByZXNlbnRhdGlvbnMvQXVzdHJpYS8wMDI3 LTIwMDMtMTFfSUVURjU4X1N0YXN0bnkucHB0DQoNCnJlZ2FyZHMNClJpY2hhcmQNCiANCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Nov 19 21:47:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00148 for ; Wed, 19 Nov 2003 21:47:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMeqw-0006h1-UC for enum-archive@odin.ietf.org; Wed, 19 Nov 2003 21:47:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK2lUB7025675 for enum-archive@odin.ietf.org; Wed, 19 Nov 2003 21:47:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMeqS-0006fP-Rr; Wed, 19 Nov 2003 21:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMepU-0006eV-56 for enum@optimus.ietf.org; Wed, 19 Nov 2003 21:46:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00090 for ; Wed, 19 Nov 2003 21:45:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMepR-0001ca-00 for enum@ietf.org; Wed, 19 Nov 2003 21:45:57 -0500 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 1AMepQ-0001c4-00 for enum@ietf.org; Wed, 19 Nov 2003 21:45:56 -0500 Received: (qmail 86495 invoked from network); 20 Nov 2003 03:04:37 -0000 Received: from unknown (HELO pobox.org.sg) (203.208.233.159) by sentosa.post1.com with SMTP; 20 Nov 2003 03:04:37 -0000 Message-ID: <3FBC2AA8.4090607@pobox.org.sg> Date: Thu, 20 Nov 2003 10:44:56 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Stastny Richard CC: enum@ietf.org Subject: Re: [Enum] IETF58 ENUM WG slides for enum-voip-numbering References: <06CF906FE3998C4E944213062009F1622339A6@oefeg-s02.oefeg.loc> In-Reply-To: <06CF906FE3998C4E944213062009F1622339A6@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA00091 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Has anyone taken minutes of the meeting? -James Seng Stastny Richard wrote: > Hi folks, >=20 > the presentation held at the IETF58 ENUM WG on the I-D > http://enum.nic.at/documents/IETF/Internet_Drafts/draft-stastny-enum-n= umbering-voip-00.txt =20 > =20 > is available at > http://enum.nic.at/documents/AETP/Presentations/Austria/0027-2003-11_IE= TF58_Stastny.ppt >=20 > regards > Richard > =20 > ???????????????????????????????????=DE=9E?j)b? b?=D7=A7?o?z????!??l???? > ???_????f??f??X??)=DF=A3? >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Nov 20 07:31:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01436 for ; Thu, 20 Nov 2003 07:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnxr-0004e8-GA for enum-archive@odin.ietf.org; Thu, 20 Nov 2003 07:31:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKCVFm2017808 for enum-archive@odin.ietf.org; Thu, 20 Nov 2003 07:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnxd-0004ch-F0; Thu, 20 Nov 2003 07:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnxN-0004bl-7z for enum@optimus.ietf.org; Thu, 20 Nov 2003 07:30:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01405 for ; Thu, 20 Nov 2003 07:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnxM-0001sV-00 for enum@ietf.org; Thu, 20 Nov 2003 07:30:44 -0500 Received: from heron.verisign.com ([216.168.237.102]) by ietf-mx with esmtp (Exim 4.12) id 1AMnxM-0001sS-00 for enum@ietf.org; Thu, 20 Nov 2003 07:30:44 -0500 Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hAKCUcha018391; Thu, 20 Nov 2003 07:30:38 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 07:30:37 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01E81046@vsvapostal8.vasrv.verisign.com> From: "Hollenbeck, Scott" To: "'James Seng'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] IETF58 ENUM WG slides for enum-voip-numbering Date: Thu, 20 Nov 2003 07:30:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I took the minutes and sent them to both Rich and Patrik after the meeting concluded. -Scott- > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org] On > Behalf Of James Seng > Sent: Wednesday, November 19, 2003 9:45 PM > To: Stastny Richard > Cc: enum@ietf.org > Subject: Re: [Enum] IETF58 ENUM WG slides for enum-voip-numbering > > > Has anyone taken minutes of the meeting? > > -James Seng _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Nov 21 00:22:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17941 for ; Fri, 21 Nov 2003 00:22:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN3kJ-0000ap-Aj for enum-archive@odin.ietf.org; Fri, 21 Nov 2003 00:22:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL5MJI7002228 for enum-archive@odin.ietf.org; Fri, 21 Nov 2003 00:22:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN3k0-0000VQ-NI; Fri, 21 Nov 2003 00:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN3ji-0000V5-Fr for enum@optimus.ietf.org; Fri, 21 Nov 2003 00:21:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17897 for ; Fri, 21 Nov 2003 00:21:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN3jf-0003kv-00 for enum@ietf.org; Fri, 21 Nov 2003 00:21:40 -0500 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 1AN3je-0003kk-00 for enum@ietf.org; Fri, 21 Nov 2003 00:21:39 -0500 Received: (qmail 3000 invoked from network); 21 Nov 2003 05:40:20 -0000 Received: from icsf.ida.gov.sg (HELO pobox.org.sg) (210.24.193.10) by sentosa.post1.com with SMTP; 21 Nov 2003 05:40:20 -0000 Message-ID: <3FBDA0A9.80606@pobox.org.sg> Date: Fri, 21 Nov 2003 13:20:41 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Richard Shockey CC: "'enum@ietf.org'" Subject: Re: [Enum] IETF58 ENUM WG slides for enum-voip-numbering References: <5BEA6CDB196A4241B8BE129D309AA4AF01E81046@vsvapostal8.vasrv.verisign.com> <6.0.1.1.2.20031120103555.036dbec0@joy.songbird.com> In-Reply-To: <6.0.1.1.2.20031120103555.036dbec0@joy.songbird.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks. I am just wondering what happened to 2916bis since it expires few days ago. -James Seng Richard Shockey wrote: > At 07:30 AM 11/20/2003, Hollenbeck, Scott wrote: > >> I took the minutes and sent them to both Rich and Patrik after the >> meeting >> concluded. > > > I'll have the draft notes up either today or tommrrow at the latest > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Nov 28 13:16:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05870 for ; Fri, 28 Nov 2003 13:16:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APnAU-00006y-7M for enum-archive@odin.ietf.org; Fri, 28 Nov 2003 13:16:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASIGcda000376 for enum-archive@odin.ietf.org; Fri, 28 Nov 2003 13:16:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APn9t-0008Vq-7F; Fri, 28 Nov 2003 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APn9Q-0008V7-OW for enum@optimus.ietf.org; Fri, 28 Nov 2003 13:15:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05806; Fri, 28 Nov 2003 13:15:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APn9O-0006ST-00; Fri, 28 Nov 2003 13:15:30 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx with esmtp (Exim 4.12) id 1APn9N-0006RP-00; Fri, 28 Nov 2003 13:15:30 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1APn8t-0002jS-00; Fri, 28 Nov 2003 19:14:59 +0100 Date: Fri, 28 Nov 2003 19:14:59 +0100 (CET) From: Bernie Hoeneisen To: iesg@ietf.org cc: enum@ietf.org Subject: Re: [Enum] Last Call: 'ENUM Service Registration for H.323 URL' to Proposed Standard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi! Concerning the H.323 ENUM Service Registration draft: I am missing an example section, where the reader can get a picture on how a H.323 NAPTR Record could look like. Especially for discovering the "standard H.323 URL" one has to dig into ITU specs, which might be quite some challenge... I'd propose to add a brief description aobut the "standard H.323 URL" and some examples for H.323 NAPTR records to improve the understandability of this document. cheers, Bernie On Thu, 6 Nov 2003, The IESG wrote: > The IESG has received a request from the Telephone Number Mapping WG to > consider the following document: > > - 'ENUM Service Registration for H.323 URL ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-28. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-01.txt > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum