From enum-bounces@ietf.org Thu Nov 02 10:18:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeIU-0003Wm-TQ; Thu, 02 Nov 2006 10:16:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeIT-0003V2-Qq for enum@ietf.org; Thu, 02 Nov 2006 10:16:01 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfeIP-0003RK-Cj for enum@ietf.org; Thu, 02 Nov 2006 10:16:01 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kA2FFqdp008488 for ; Thu, 2 Nov 2006 07:15:58 -0800 From: "Richard Shockey" To: Date: Thu, 2 Nov 2006 10:15:34 -0500 Message-ID: <027601c6fe91$c000aaa0$98201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb+kb2J7WSPzWdWRnaRJ3JAsvhQvw== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Enum] Final ENUM WG Agenda X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org http://www3.ietf.org/proceedings/06nov/agenda/enum.txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 02 16:05:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfjj5-0001rV-GQ; Thu, 02 Nov 2006 16:03:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfjj3-0001qe-JC for enum@ietf.org; Thu, 02 Nov 2006 16:03:49 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfjiz-0004qL-2h for enum@ietf.org; Thu, 02 Nov 2006 16:03:49 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kA2L3eE3023152 for ; Thu, 2 Nov 2006 13:03:48 -0800 From: "Richard Shockey" To: Date: Thu, 2 Nov 2006 16:03:11 -0500 Message-ID: <046601c6fec2$55f24890$98201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb+wkyIv1+MAfAISQeKh7l0x0Ihng== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Enum] PLease get your presentations for MON ready ASAP X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Send them to Alex or myself so they can be ready BEFORE the meeting starts. Please! Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 06:17:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh2RL-0004Ra-SG; Mon, 06 Nov 2006 06:14:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh2RK-0004RQ-NQ for enum@ietf.org; Mon, 06 Nov 2006 06:14:54 -0500 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh2RG-0001uI-SM for enum@ietf.org; Mon, 06 Nov 2006 06:14:54 -0500 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Mon, 06 Nov 2006 13:14:42 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Nov 2006 13:14:42 +0200 Message-ID: <07BC6C0D40216E44A34BE6701694FE8603BE2869@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reference to E.164 Thread-Index: AcamjzwfCz1CDf2+TOCZ0/3GlcplrwC+7iewFgHoxr0= References: <07BC6C0D40216E44A34BE6701694FE86038B46DD@POSTI.laru.local> From: "Nieminen Klaus" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Enum] Reference to E.164 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2044813385==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============2044813385== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70194.C22B5FF9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70194.C22B5FF9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 Just want to repeat my earlier comment, because nearly every reference = in the IDs in our agenda point to a old version of E.164 Recommendation. = Please use 02/05: http://www.itu.int/rec/T-REC-E.164/en =20 List of IDs that should be corrected in the next version: =20 - draft-ietf-enum-3761bis-00.txt - draft-ietf-enum-uri-00.txt - draft-chenh-enum-app-auth-00.txt - draft-reichinger-enum-foaf-01.txt - draft-ietf-enum-iax-01.txt - draft-ietf-enum-combined-01.txt =20 - Klaus ________________________________ L=E4hett=E4j=E4: Nieminen Klaus [mailto:Klaus.Nieminen@ficora.fi] L=E4hetetty: ma 17.7.2006 13:30 Vastaanottaja: enum@ietf.org Aihe: RE: [Enum] ENUM Working Group last call = fordocumentdraft-ietf-enum-validation-token-01.txt Hi all, I have one minor issue that I believe to be valid for most current ENUM = IDs. The old E.164 Recommendation has been replaced by a new one E.164 = (02/05. For more details see: http://www.itu.int/rec/T-REC-E.164/en It's not critical, but I think we should start using the latest version. regards, - Klaus - ------_=_NextPart_001_01C70194.C22B5FF9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] ENUM Working Group last call = fordocumentdraft-ietf-enum-validation-token-01.txt=0A= =0A= =0A= =0A=
=0A=
Hi = all,
=0A=
 
=0A=
Just want to repeat my = earlier comment, because nearly every reference in the IDs in our agenda = point to a old version of E.164 Recommendation. Please use 02/05: =  http://www.itu.int/rec/T-R= EC-E.164/en
=0A=
 
=0A=
List of IDs that should be = corrected in the next version:
=0A=
 
=0A=
- draft-ietf-enum-3761bis-00.txt
- = draft-ietf-enum-uri-00.txt
- draft-chenh-enum-app-auth-00.txt
=0A=
- draft-reichinger-enum-foaf-01.txt
=0A=
- draft-ietf-enum-iax-01.txt
- = draft-ietf-enum-combined-01.txt
=0A=
 
=0A=
- Klaus
=0A=

=0A=
=0A= L=E4hett=E4j=E4: Nieminen Klaus = [mailto:Klaus.Nieminen@ficora.fi]
L=E4hetetty: ma 17.7.2006 = 13:30
Vastaanottaja: enum@ietf.org
Aihe: RE: [Enum] = ENUM Working Group last call = fordocumentdraft-ietf-enum-validation-token-01.txt

=0A=
=0A=

Hi all,

I have one minor issue that I believe = to be valid for most current ENUM IDs.

The old E.164 = Recommendation has been replaced by a new one E.164 (02/05.

For = more details see:
http://www.itu.int/rec/T-R= EC-E.164/en

It's not critical, but I think we should start = using the latest version.

regards,

- Klaus = -

------_=_NextPart_001_01C70194.C22B5FF9-- --===============2044813385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2044813385==-- From enum-bounces@ietf.org Mon Nov 06 13:10:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8uS-0008A7-AA; Mon, 06 Nov 2006 13:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8uQ-0008A0-L6 for enum@ietf.org; Mon, 06 Nov 2006 13:09:22 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8uI-00042x-At for enum@ietf.org; Mon, 06 Nov 2006 13:09:22 -0500 Received: from [130.129.70.160] ([::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 06 Nov 2006 19:08:54 +0100 id 0007C3A5.454F7A37.00006345 Message-ID: <454F79A1.30500@enum.at> Date: Mon, 06 Nov 2006 19:06:25 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Enum] presentations... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org If you haven't sent me your slide decks, please do so ASAP. Remote participants (but not just those!) appreciate to have the slides available before the presentation.. thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 14:48:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAQf-0002r0-GC; Mon, 06 Nov 2006 14:46:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAQe-0002qv-EQ for enum@ietf.org; Mon, 06 Nov 2006 14:46:44 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhAQc-0006rg-5W for enum@ietf.org; Mon, 06 Nov 2006 14:46:44 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id ED4634D431; Mon, 6 Nov 2006 20:46:30 +0100 (CET) Date: Mon, 6 Nov 2006 20:46:30 +0100 From: Otmar Lendl To: enum@ietf.org Message-ID: <20061106194630.GA2186@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Enum] Re: draft-chenh-enum-app-auth-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Regarding draft-chenh-enum-app-auth-00.txt: | 2.3. Application | [...] | In order to improve the security and privacy of ENUM service, | authentication function can be introduced into ENUM applications. | When the originer initiates a service, the initiation message carries | both originer's un-encrypted ENUM number and encrypted ENUM number | field with sender's public key. Shouldn't that be the private key? Two other questions: * Do you propose to store the public key directly in the ENUM dns, or just a refernce (URI) to a key-server which keeps the public keys? * How to you protect the scheme against replay attacks? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 15:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhBCr-0000gu-Bc; Mon, 06 Nov 2006 15:36:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhBCp-0000dH-6U for enum@ietf.org; Mon, 06 Nov 2006 15:36:31 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhBCo-0004JN-8M for enum@ietf.org; Mon, 06 Nov 2006 15:36:31 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6E2554D434; Mon, 6 Nov 2006 21:36:27 +0100 (CET) Date: Mon, 6 Nov 2006 21:36:27 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] draft-ietf-enum-uri-00.txt Message-ID: <20061106203627.GB2186@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/10/05 16:10, Otmar Lendl wrote: >=20 > [There seems to be a problem with enum@ietf.org, an earlier mail > from me didn't make it back to my mailbox.] Both authors of the ENUM bis / URI RR drafts don't recall receiving this message. There _were_ problems with the mailing list, thus yet another try to get this list of questions through to everybody. I'll pose these in the WG session later today as well. /ol >=20 > On 2006/09/28 11:09, Patrik F=E4ltstr=F6m wrote: > > This document was requested to be published the other day, but =20 > > publication seems to take some time. >=20 > Thanks for the document, here are some question: >=20 > >=20 > > 1. =20 > > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Applicability =20 > > Statement . . . . . . . . . . . . . . . . . . . 3 >=20 > The formatting is a bit off (not only here, but also in the=20 > rfc-editor repository), could you please submit a version > without unwanted line-breaks, and with page breaks? >=20 >=20 > Concerning this example: >=20 > > 6.2. Different providers for services for the same E.164 > >=20 > > An organisation have the E.164 +442079460148, but different > > organisations handle routing of calls for the number on the Intern= et > > (with the help of SIP) and traditional PSTN. More specifically, t= he > > two providers want to run DNS for the record(s) that refer to the > > services they provide. >=20 > I think I understand the pure DNS mechanics you propose. >=20 > What I can't see right now is how this proposal fits into the > Tier0/Tier1/ITSP/end-user scheme of actors. Where are the=20 > zone cuts and who is operating which zone? >=20 > > The ENUM provider for the +44 country code in this case not only d= o > > delegations on the full E.164 number, but delegations on the servi= ce > > parameter values, as can be seen below: > >=20 > > In this example we also include the NAPTR records that with the he= lp > > of the 'D' flag refer to the URI records. We also include NAPTR > > records according to RFC 3761 [RFC3761] that give backward > > compatibility. > >=20 > > In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.: >=20 > Who do you propose should run that zone? >=20 > > $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > >=20 > > ;; NAPTR records that refer to URI records > > IN NAPTR 1 1 "D" "E2U:sip" ( ; service > > "" ; regexp > > _sip._e2u ; replacement > > ) > >=20 > > IN NAPTR 1 1 "D" "E2U:tel" ( ;service > > "" ;regexp > > _tel._e2u ;replacement > > ) >=20 > This record is *important* to the telco running the phone > service for this number. They won't want to live with the > possibility that users can mess up the telco internal routing. >=20 > >=20 > > ;; NAPTR records for RFC 3761 compatibility > > IN NAPTR 1 1 "U" "E2U:sip" ( ;service > > "!.*!sip:+442079460148@sipprovider.net!" ; regexp > > . ; replacement > > ) >=20 > In the current model, this record is supposed to be hosted > on a user-controlled server. >=20 > This puts us into a bind:=20 >=20 > > IN NAPTR 1 1 "U" "E2U:tel" ( ;service > > "!.*!sip:+442079460148@sipprovider.net!" ; regexp > > . ; replacement > > ) > >=20 > > ;; Delegations to child zones > > _sip._e2u IN NS ns1.example.net. > > _tel._e2u IN NS ns1.example.com. >=20 > Once again, the I-ENUM records are dependent on the management of > the pure ENUM zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. >=20 > > In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: > >=20 > >=20 > > $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > > _sip._e2u IN URI "sip:+442079460148@example.net" >=20 > Shouldn't that be=20 >=20 > $ORIGIN _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > @ IN URI "sip:+442079460148@example.net" >=20 > to indicate where the zone-cut is? >=20 > ----------------------------- >=20 > To summarize: >=20 > If I were to start an ENUM deployment from scratch, this proposal fine > (except, see below). In this case, I'd put the IN NAPTR 1 1 "D" > records in the Tier1 zone (autocreated based on *._e2u entries) and > just delegate (optionally) the _sip._e2u subdomains to subscribers or > ITSPs. That way, the DNS infrastructure of one application can be kept > independent from the one of another application. >=20 > The problem is the legacy 3761 support: For all the delegated domains > out there, it is not acceptable for the carriers to go to their > subscribers and asks them for a delegation of _tel._e2u. That ain't > going to fly. In order to make the transition, current ENUM users need > to provision their existing NAPTRs into the registry. That's going to > be a headache for everybody who managed to get a 3761-based system up > and running. >=20 > ----------------------------- >=20 > The showstopper: >=20 > And then there is the issue of open numbering plans. I can't see how th= is > scheme is supposed to work in a country where PBX operators are free to > define their own variable-length dialplan behind their pilot number. >=20 > Consider the example of enum.at's Vienna office: >=20 > Our pilot number is +43 1 5056416. That's a normal (i.e. not shortened)= Vienna > number. We use 2-digit extension, e.g. -33 is my phone. A common scheme > is to use prefixes for FAX to Email services. In our case -933 is > supposed to deliver an incoming FAX to my mailbox. Our carrier (Telekom > Austria) doesn't know or even care about these arrangements. >=20 > In ENUM terms, right now we have a delegation for > 6.1.4.5.0.5.1.3.4.e164.arpa and simply add new extensions to our zone > file and be done with it. >=20 > In I-ENUM, Telekom Austria (were they to take part in our trial) would > use wildcards to direct calls to their ingress point, e.g. by >=20 > 6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1@sip.telekom.at! > *.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1@sip.telekom.at! >=20 > Which records should Telekom Austria provision under your scheme? >=20 > /ol > --=20 > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 16:53:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCOP-0001eM-J9; Mon, 06 Nov 2006 16:52:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCON-0001dd-Qm for enum@ietf.org; Mon, 06 Nov 2006 16:52:31 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCOL-0000P2-Un for enum@ietf.org; Mon, 06 Nov 2006 16:52:31 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id F24368696E for ; Mon, 6 Nov 2006 21:52:28 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <45D5BE42-EBCE-4618-B840-5C0EC4B6A140@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: enum@ietf.org From: lconroy Date: Mon, 6 Nov 2006 21:52:27 +0000 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Enum] Experiences work X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, a quick clarification - (for information only, not modifying any standard ;). It looks like there will be another version of the Experiences draft. The current version still has the contentious EDNS0 text that has been forked out to another doc, so the new version of Experiences will excise this duplicate data and merely refer to that EDNS0 document. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 16:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCUU-0004RS-1k; Mon, 06 Nov 2006 16:58:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCUR-0004RM-Qr for enum@ietf.org; Mon, 06 Nov 2006 16:58:47 -0500 Received: from klara.frobbit.se ([85.30.129.37] helo=frobbit.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCUQ-0001Ph-0H for enum@ietf.org; Mon, 06 Nov 2006 16:58:47 -0500 Received: from [130.129.68.79] (account paf [130.129.68.79] verified) by frobbit.se (CommuniGate Pro SMTP 5.0.10) with ESMTPA id 3988258; Mon, 06 Nov 2006 22:58:26 +0100 In-Reply-To: <20061006070656.GJ15701@nic.at> References: <20061006070656.GJ15701@nic.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt Date: Mon, 6 Nov 2006 13:58:21 -0800 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: IETF ENUM WG , enum-wg@ripe.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 6 okt 2006, at 00.06, Otmar Lendl wrote: > The IETF enum list seems to be broken, but as Paf explained > his proposal at the RIPE meeting in A'dam this week, here is > a copy of my reply: And here is my response... > On 2006/09/28 11:09, Patrik F=E4ltstr=F6m wrote: >> This document was requested to be published the other day, but >> publication seems to take some time. > > Thanks for the document, here are some question: > >> >> 1. >> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. Applicability >> Statement . . . . . . . . . . . . . . . . . . . 3 > > The formatting is a bit off (not only here, but also in the > rfc-editor repository), could you please submit a version > without unwanted line-breaks, and with page breaks? Yes, because I sent the draft inline instead of as an attachment... > Concerning this example: > >> 6.2. Different providers for services for the same E.164 >> >> An organisation have the E.164 +442079460148, but different >> organisations handle routing of calls for the number on the =20 >> Internet >> (with the help of SIP) and traditional PSTN. More =20 >> specifically, the >> two providers want to run DNS for the record(s) that refer to the >> services they provide. > > I think I understand the pure DNS mechanics you propose. > > What I can't see right now is how this proposal fits into the > Tier0/Tier1/ITSP/end-user scheme of actors. Where are the > zone cuts and who is operating which zone? This is the key question of course. >> The ENUM provider for the +44 country code in this case not =20 >> only do >> delegations on the full E.164 number, but delegations on the =20 >> service >> parameter values, as can be seen below: >> >> In this example we also include the NAPTR records that with the =20= >> help >> of the 'D' flag refer to the URI records. We also include NAPTR >> records according to RFC 3761 [RFC3761] that give backward >> compatibility. >> >> In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.: > > Who do you propose should run that zone? A neutral party. Wherever we do the zone cut to "the user", "some service provider" or =20= whoever, the delegation have to be made from a neutral party. Just =20 like the management of the number portability database. >> $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. >> >> ;; NAPTR records that refer to URI records >> IN NAPTR 1 1 "D" "E2U:sip" ( ; service >> "" ; regexp >> _sip._e2u ; replacement >> ) >> >> IN NAPTR 1 1 "D" "E2U:tel" ( ;service >> "" ;regexp >> _tel._e2u ;replacement >> ) > > This record is *important* to the telco running the phone > service for this number. They won't want to live with the > possibility that users can mess up the telco internal routing. Yes, and they will unless under very specific circumstances accept =20 the delegation FROM anyone else than a neutral party. I personally see similar issues with *ALL* services. This is why the ie164.arpa, or i.6.4.e164.arpa ideas from my point of =20= view can not be the ONLY special delegations as "the telco" is only =20 one of the service providers that think their service is special. I.e. I think we have one statement and a few questions to answer: Statement: Delegation must at some location in the tree be from a =20 neutral party. Question 1: Where in the tree are we breaking out from neutral party =20 delegation to special delegation? Question 2: When should "non-User ENUM" in reality NOT be in the =20 e164.arpa tree? >> ;; NAPTR records for RFC 3761 compatibility >> IN NAPTR 1 1 "U" "E2U:sip" ( ;service >> "!.*!sip:+442079460148@sipprovider.net!" ; regexp >> . ; replacement >> ) > > In the current model, this record is supposed to be hosted > on a user-controlled server. Yes. > > This puts us into a bind: > >> IN NAPTR 1 1 "U" "E2U:tel" ( ;service >> "!.*!sip:+442079460148@sipprovider.net!" ; regexp >> . ; replacement >> ) >> >> ;; Delegations to child zones >> _sip._e2u IN NS ns1.example.net. >> _tel._e2u IN NS ns1.example.com. > > Once again, the I-ENUM records are dependent on the management of > the pure ENUM zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. You have pointed out a very good thing. We can not mix these things. =20 That the user is responsible for the zone from which delegations are =20 made. >> In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: >> >> >> $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. >> _sip._e2u IN URI "sip:+442079460148@example.net" > > Shouldn't that be > > $ORIGIN _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > @ IN URI "sip:+442079460148@example.net" > > to indicate where the zone-cut is? Maybe that is a better example? It is still "just" a syntax to make =20 the zone content easier to read. It in reality have nothing to do =20 with where the cut is. BUT, you suggest this is made clearer. I =20 should say "In the zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. =20 we have the following data". > ----------------------------- > > To summarize: > > If I were to start an ENUM deployment from scratch, this proposal =20 > is fine > (except, see below). In this case, I'd put the IN NAPTR 1 1 "D" > records in the Tier1 zone (autocreated based on *._e2u entries) and > just delegate (optionally) the _sip._e2u subdomains to subscribers or > ITSPs. That way, the DNS infrastructure of one application can be kept > independent from the one of another application. > > The problem is the legacy 3761 support: For all the delegated domains > out there, it is not acceptable for the carriers to go to their > subscribers and asks them for a delegation of _tel._e2u. That ain't > going to fly. In order to make the transition, current ENUM users need > to provision their existing NAPTRs into the registry. That's going to > be a headache for everybody who managed to get a 3761-based system up > and running. I agree. > ----------------------------- > > The showstopper: > > And then there is the issue of open numbering plans. I can't see =20 > how this > scheme is supposed to work in a country where PBX operators are =20 > free to > define their own variable-length dialplan behind their pilot number. > > Consider the example of enum.at's Vienna office: > > Our pilot number is +43 1 5056416. That's a normal (i.e. not =20 > shortened) Vienna > number. We use 2-digit extension, e.g. -33 is my phone. A common =20 > scheme > is to use prefixes for FAX to Email services. In our case -933 is > supposed to deliver an incoming FAX to my mailbox. Our carrier =20 > (Telekom > Austria) doesn't know or even care about these arrangements. > > In ENUM terms, right now we have a delegation for > 6.1.4.5.0.5.1.3.4.e164.arpa and simply add new extensions to our zone > file and be done with it. > > In I-ENUM, Telekom Austria (were they to take part in our trial) would > use wildcards to direct calls to their ingress point, e.g. by > > 6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1@sip.telekom.at! > *.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1@sip.telekom.at! > > Which records should Telekom Austria provision under your scheme? If I understand you correctly, Telekom Austria is running telephony =20 for the number +43 1 5056416, but then you as a user of that number =20 can add whatever digits you want as "extensions" as the routing is =20 prefix based. I presume as long as the number of digits totally is =20 fewer than 15 :-) Can you "port" that prefix from Telekom Austria to someone else? Today, as you point out, there should be a zone =20 6.1.4.5.0.5.1.3.4.e164.arpa in which you instead of "just" having =20 NAPTR records for the name of the zone, you have NAPTR for the =20 extensions you have. Example (not open numbering plan): 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... With open numbering plan: 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... 3.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... 4.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... 5.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... How do you handle number portability for these numbers (that end with =20= 33, 34 and 35)? Can they be ported one at a time, or just the whole =20 block at the same time? On the other hand, I see problems when the email provider want to run =20= the DNS for the NAPTR that refer to the email services they run, and =20 further, that the delegation should be from a neutral party? I do not have an answer to your question. I think the solution will =20 violate many of the requirements we have. Regardless of what the =20 solution is. Good discussion, lets continue. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 17:12:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCh3-0006k7-IQ; Mon, 06 Nov 2006 17:11:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCh2-0006jF-Tj for enum@ietf.org; Mon, 06 Nov 2006 17:11:48 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCgx-0003FB-Lf for enum@ietf.org; Mon, 06 Nov 2006 17:11:48 -0500 Received: from ([10.20.9.174]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27184083; Mon, 06 Nov 2006 17:11:19 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 17:11:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 17:11:16 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602453E36@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lim-kim-enum-based-softswitch-00 Thread-Index: AccB8Hp8Wk1vplM6Q7W6IfxP7BRfBQ== From: "Livingood, Jason" To: , , X-OriginalArrivalTime: 06 Nov 2006 22:11:17.0144 (UTC) FILETIME=[7B0AE980:01C701F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Enum] draft-lim-kim-enum-based-softswitch-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Continuing discussion from the WG meeting on this I-D -> seems like we should resolve the problem we're trying to solve with this, or what the objective of the I-D is. >From reading the draft a couple of times now, it seems like the authors are trying to (1) specify a requirement that could be referenced by softswitch vendors so that such vendors actually support ENUM, which may simply mean that the switch must have an ENUM client with specific requirements around the root to be queried and how call routing should progress after the failure of an ENUM lookup. Then, another is to (2) specify the progression of the call routing logic in the switch itself with first a lookup to infrastructure ENUM and then progression to other internal tables or other methods. As a service provider, we've worked on both of these things with our vendors so I can understand the desire to solve this by implementers. As the co-authors are from a national agency in Korea though, perhaps the objective is to specify how implementation should work for vendors and service providers in Korea? If so, perhaps this is more a BCP for Korean implementation / Korean numbering space? If not, and #1 and #2 are objectives, then maybe a BCP or Informational document is more appropriate? Not sure either way - throwing out some discussion points... Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 17:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCmq-0002tl-0r; Mon, 06 Nov 2006 17:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCmo-0002pb-Ah for enum@ietf.org; Mon, 06 Nov 2006 17:17:46 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCmm-0004AR-T5 for enum@ietf.org; Mon, 06 Nov 2006 17:17:46 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id E055C4D436; Mon, 6 Nov 2006 23:17:35 +0100 (CET) Date: Mon, 6 Nov 2006 23:17:35 +0100 From: Otmar Lendl To: Patrik =?iso-8859-15?B?RuRsdHN0cvZt?= Subject: Re: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt Message-ID: <20061106221735.GL20763@nic.at> Mail-Followup-To: Otmar Lendl , Patrik =?iso-8859-15?B?RuRsdHN0cvZt?= , enum-wg@ripe.net, IETF ENUM WG References: <20061006070656.GJ15701@nic.at> <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> User-Agent: Mutt/1.5.13 (2006-08-11) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IETF ENUM WG , enum-wg@ripe.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org [quick reply to just answer some question on open numbering plans.] On 2006/11/06 22:11, Patrik F=E4ltstr=F6m wrote: > On 6 okt 2006, at 00.06, Otmar Lendl wrote: >=20 > >In I-ENUM, Telekom Austria (were they to take part in our trial) would > >use wildcards to direct calls to their ingress point, e.g. by > > > >6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1@sip.telekom.at! > >*.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1@sip.telekom.at! > > > >Which records should Telekom Austria provision under your scheme? >=20 > If I understand you correctly, Telekom Austria is running telephony =20 > for the number +43 1 5056416, but then you as a user of that number =20 > can add whatever digits you want as "extensions" as the routing is =20 > prefix based. I presume as long as the number of digits totally is =20 > fewer than 15 :-) Correct.=20 > Can you "port" that prefix from Telekom Austria to someone else? Yes. > Today, as you point out, there should be a zone =20 > 6.1.4.5.0.5.1.3.4.e164.arpa in which you instead of "just" having =20 > NAPTR records for the name of the zone, you have NAPTR for the =20 > extensions you have. >=20 > Example (not open numbering plan): >=20 > 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... > 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... > 6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... >=20 > With open numbering plan: > 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... > 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... > 3.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... > 4.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... > 5.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... Correct. This actually quite efficient as you just have to maintain a single zone for the full PBX and not one per extension. (On the other hand, this s*cks for us as the ENUM registry as=20 we can only sell a single delegation to big corporate PBXs.) > How do you handle number portability for these numbers (that end with =20 > 33, 34 and 35)? Can they be ported one at a time, or just the whole =20 > block at the same time? Porting is only possible at the number level, not on the extension level. For that example, we can take +43 1 5056416 plus all existing extensions to a different operator, but we can't port out individual extensions like +43 1 5056416 33. (This is similar to the email/domain porting question that came up here at the ietf meeting just now: Domains can be "ported", and take all email addresses with them.) > Good discussion, lets continue. Indeed. /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 17:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQI-0003Vz-P3; Mon, 06 Nov 2006 17:58:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQH-0003Vm-L6 for enum@ietf.org; Mon, 06 Nov 2006 17:58:33 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDMI-0000wj-UY for enum@ietf.org; Mon, 06 Nov 2006 17:54:28 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5BCF0869E4 for ; Mon, 6 Nov 2006 22:54:26 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: enum@ietf.org From: lconroy Date: Mon, 6 Nov 2006 22:54:25 +0000 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Enum] Guide comments X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi folks, I for one want non-terminals and experimental services. I use both, and these should be in the guide. [want some text ?] As for extensibility, this is specifically not permitted in the 3761 template. The type WAS intended to be controlling, describing the kind of teleservice. That was the big change from 2916. Sub-types should avoid confusion by doing similar things, but with different methods. Good idea to add text to spell out extensibility, and what the limits are on it. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 17:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQG-0003VH-OB; Mon, 06 Nov 2006 17:58:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQF-0003UQ-3K for enum@ietf.org; Mon, 06 Nov 2006 17:58:31 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDMx-00010A-8T for enum@ietf.org; Mon, 06 Nov 2006 17:55:16 -0500 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27193101; Mon, 06 Nov 2006 17:54:50 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 17:54:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 17:54:49 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602453E42@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement? Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIw== From: "Livingood, Jason" To: X-OriginalArrivalTime: 06 Nov 2006 22:54:50.0026 (UTC) FILETIME=[907110A0:01C701F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence:From enum-bounces@ietf.org Mon Nov 06 17:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQI-0003Vz-P3; Mon, 06 Nov 2006 17:58:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQH-0003Vm-L6 for enum@ietf.org; Mon, 06 Nov 2006 17:58:33 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDMI-0000wj-UY for enum@ietf.org; Mon, 06 Nov 2006 17:54:28 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5BCF0869E4 for ; Mon, 6 Nov 2006 22:54:26 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: enum@ietf.org From: lconroy Date: Mon, 6 Nov 2006 22:54:25 +0000 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Enum] Guide comments X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi folks, I for one want non-terminals and experimental services. I use both, and these should be in the guide. [want some text ?] As for extensibility, this is specifically not permitted in the 3761 template. The type WAS intended to be controlling, describing the kind of teleservice. That was the big change from 2916. Sub-types should avoid confusion by doing similar things, but with different methods. Good idea to add text to spell out extensibility, and what the limits are on it. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 17:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQG-0003VH-OB; Mon, 06 Nov 2006 17:58:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQF-0003UQ-3K for enum@ietf.org; Mon, 06 Nov 2006 17:58:31 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDMx-00010A-8T for enum@ietf.org; Mon, 06 Nov 2006 17:55:16 -0500 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27193101; Mon, 06 Nov 2006 17:54:50 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 17:54:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 17:54:49 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602453E42@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement? Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIw== From: "Livingood, Jason" To: X-OriginalArrivalTime: 06 Nov 2006 22:54:50.0026 (UTC) FILETIME=[907110A0:01C701F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Follow-up on discussion of this I-D at the WG session today. It seems like the chairs and AD are asking whether or not people feel strongly about this particular service and will actually use it, as it will take time & energy to overcome concerns raised through the I-D review process (concerns which will surely be raised again in later reviews in the process). So perhaps I can propose we step back for a moment, considering the need for void or not as an enumservice type? Here I think the best starting point is for everyone to re-read section 3 of the draft, called "The Problem" and decide whether or not there is agreement on that problem. If so, we can *then* decide if void solves that problem or not, but we have to first at least agree on the problem. Here is that text, FYI: 3. The Problem At present, from the ENUM client's perspective, two possibilities exist: there is an ENUM domain that potentially holds alternative contacts, or there is no ENUM domain, in which case a query on ENUM will return a DNS response showing 'no such domain' (NXDOMAIN, code 3)[4]. This latter response is ambiguous. There are two potential reasons for the lack of an ENUM domain holding alternative contacts; either the assignee has chosen not to register the domain, or the E.164 number is not assigned for communications service at present. If the number is assigned, then the caller can use the E.164 number to place the call via a network that uses such identifiers as global addresses (i.e. the CSN). If however, there is no domain because the associated E.164 number is not assigned for communications service, then any attempt to place the call via the CSN will fail. What would be useful is a mechanism "between" a registration holding NAPTRs with URIs and the lack of a domain registration. In this way, an entity who is responsible for E.164 numbers in a range can indicate that a particular number has not been assigned to anyone for communications service. For example, if a communications service provider has been allocated responsibility for delivering calls to endpoints identified with E.164 numbers in a block, then they may have some numbers in that block that are currently unused. These E.164 numbers are not used to terminate calls to end users. An originating user agent cannot differentiate this state from the one in which there is an end user as a number assignee, but that end user has have chosen not to "publish" other contacts. In effect, it would be more useful if the originating end user could receive a response that states "there is no service via this number", as opposed to "there may be service via this number, but there are no alternative contacts available". In short, the issue is distinguishing between E.164 numbers that do not have corresponding ENUM entries but are supported via the PSTN and those E.164 numbers that are not terminated on the PSTN. In this latter case lack of a NAPTR holding a destination URI really implies that there is no service at all for this telephone number. For example, some number ranges have been allocated for service that is provided only via reference to an ENUM domain, and terminate on the Internet (i.e. these calls will terminate only at a VoIP end point). The fundamental problem is that there may be inconsistencies between the E.164 name space as it is understood by the National Regulatory Authority (NRA) and how that name space is represented in ENUM, as service moves towards being provided in some cases only via non-PSTN access. In effect, the PSTN may list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Follow-up on discussion of this I-D at the WG session today. It seems like the chairs and AD are asking whether or not people feel strongly about this particular service and will actually use it, as it will take time & energy to overcome concerns raised through the I-D review process (concerns which will surely be raised again in later reviews in the process). So perhaps I can propose we step back for a moment, considering the need for void or not as an enumservice type? Here I think the best starting point is for everyone to re-read section 3 of the draft, called "The Problem" and decide whether or not there is agreement on that problem. If so, we can *then* decide if void solves that problem or not, but we have to first at least agree on the problem. Here is that text, FYI: 3. The Problem At present, from the ENUM client's perspective, two possibilities exist: there is an ENUM domain that potentially holds alternative contacts, or there is no ENUM domain, in which case a query on ENUM will return a DNS response showing 'no such domain' (NXDOMAIN, code 3)[4]. This latter response is ambiguous. There are two potential reasons for the lack of an ENUM domain holding alternative contacts; either the assignee has chosen not to register the domain, or the E.164 number is not assigned for communications service at present. If the number is assigned, then the caller can use the E.164 number to place the call via a network that uses such identifiers as global addresses (i.e. the CSN). If however, there is no domain because the associated E.164 number is not assigned for communications service, then any attempt to place the call via the CSN will fail. What would be useful is a mechanism "between" a registration holding NAPTRs with URIs and the lack of a domain registration. In this way, an entity who is responsible for E.164 numbers in a range can indicate that a particular number has not been assigned to anyone for communications service. For example, if a communications service provider has been allocated responsibility for delivering calls to endpoints identified with E.164 numbers in a block, then they may have some numbers in that block that are currently unused. These E.164 numbers are not used to terminate calls to end users. An originating user agent cannot differentiate this state from the one in which there is an end user as a number assignee, but that end user has have chosen not to "publish" other contacts. In effect, it would be more useful if the originating end user could receive a response that states "there is no service via this number", as opposed to "there may be service via this number, but there are no alternative contacts available". In short, the issue is distinguishing between E.164 numbers that do not have corresponding ENUM entries but are supported via the PSTN and those E.164 numbers that are not terminated on the PSTN. In this latter case lack of a NAPTR holding a destination URI really implies that there is no service at all for this telephone number. For example, some number ranges have been allocated for service that is provided only via reference to an ENUM domain, and terminate on the Internet (i.e. these calls will terminate only at a VoIP end point). The fundamental problem is that there may be inconsistencies between the E.164 name space as it is understood by the National Regulatory Authority (NRA) and how that name space is represented in ENUM, as service moves towards being provided in some cases only via non-PSTN access. In effect, the PSTN may not have complete information and ENUM may be required to deliver a call, but the data stored in ENUM at present may be ambiguous. For applications such as an ENUM-aware VoIP/PSTN gateway, this presents a problem. These would use ENUM to decide how to route or terminate a call. A simple default configuration rule for such a gateway would probably be: "if the number called is not in ENUM or has no NAPTR records, dump the call to the PSTN". Such a rule is likely to be the norm while most telephony traffic uses the public telephone network. In other words, if the response from the DNS is that the number does not exist in ENUM, the gateway would try to terminate the call on the PSTN. This will not always work. The number that was attempted may be in some range that cannot be terminated on the PSTN: a block assigned for VoIP and ENUM exclusively, and for which there is no PSTN termination, for example. If a number in such a range had not been entered into ENUM, the DNS would return the expected NXDOMAIN or NOHOST response, causing the gateway to take its default action which would have undefined results. Where a "not in service" number is within such a special number block, the typical action of a PSTN element will be to pass this on to a VoIP/PSTN gateway, where as just described another ENUM query may be used to determine call treatment: the result could be a processing "loop". Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum not have complete information and ENUM may be required to deliver a call, but the data stored in ENUM at present may be ambiguous. For applications such as an ENUM-aware VoIP/PSTN gateway, this presents a problem. These would use ENUM to decide how to route or terminate a call. A simple default configuration rule for such a gateway would probably be: "if the number called is not in ENUM or has no NAPTR records, dump the call to the PSTN". Such a rule is likely to be the norm while most telephony traffic uses the public telephone network. In other words, if the response from the DNS is that the number does not exist in ENUM, the gateway would try to terminate the call on the PSTN. This will not always work. The number that was attempted may be in some range that cannot be terminated on the PSTN: a block assigned for VoIP and ENUM exclusively, and for which there is no PSTN termination, for example. If a number in such a range had not been entered into ENUM, the DNS would return the expected NXDOMAIN or NOHOST response, causing the gateway to take its default action which would have undefined results. Where a "not in service" number is within such a special number block, the typical action of a PSTN element will be to pass this on to a VoIP/PSTN gateway, where as just described another ENUM query may be used to determine call treatment: the result could be a processing "loop". Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 18:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEEF-0001eY-MI; Mon, 06 Nov 2006 18:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEE6-0001Bu-FA; Mon, 06 Nov 2006 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEE5-0000PB-QM; Mon, 06 Nov 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BF4FA328A1; Mon, 6 Nov 2006 23:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GhEE5-0004KZ-Jy; Mon, 06 Nov 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Nov 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-01.txt Pages : 6 Date : 2006-11-6 This document defines a parallel namespace “ie164.arpa” to “e164.arpa” as defined in RFC3761 to be used for Infrastructure ENUM purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-infrastructure-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-infrastructure-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-6162329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-infrastructure-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-infrastructure-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-6162329.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Nov 06 19:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEz9-00015w-Ht; Mon, 06 Nov 2006 19:38:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEz8-00015N-3V for enum@ietf.org; Mon, 06 Nov 2006 19:38:38 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEz6-0003l6-Ri for enum@ietf.org; Mon, 06 Nov 2006 19:38:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on SOLUTION Void? Date: Mon, 6 Nov 2006 19:36:48 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602453E74@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on SOLUTION Void? Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7A= From: "Livingood, Jason" To: X-OriginalArrivalTime: 07 Nov 2006 00:36:49.0959 (UTC) FILETIME=[D034BB70:01C70204] X-Spam-Score: 0.6 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org So if we have agreement / consensus on the problem statement, then the next obvious step is to determine if the solution recommended by the void service is the right one. My question is, if not void, then what? A SP could register their inactive TNs with SIP URIs that go to a special URI that plays back an announcement that the number is inactive, such as sip:inactive@example.foo or sip:12159811234@example.foo (where that URI is used for ALL inactive numbers). In both cases, communication is initiated from the caller to this URI, and the terminating side would then have to trigger and play an announcement (but it would otherwise look like a normally completed call).=20 I think the use of void potentially gives the call originator at the network edge access to this information more directly, potentially obviating the need to even attempt a call. In general, I kind of like being able to figure that sort of stuff out at the egde / point of origination. So I like that about the void proposal. Are there other methods that people think could solve for this problem? I am a bit more ambivalent about the contact address (email addr or http URL), but this may be useful for some clients and applications that I don't yet see a use case for yet. Perhaps another concern is the name of the service being VOID. Perhaps some take that to mean that the query was invalid in some manner? If so, perhaps it could be called INACTIVE or something like that instead... Also, I'd suggest the authors consider removal of this text in section 7, as I'd suggest that I am not sure SPs would actually do this and I think regular SIP mechanisms can handle these scenarios: "This could be done for a variety of reasons. The number could have been delegated to an end user who has chosen to insert this record: for instance it's in an ENUM or VoIP only number block and the end user's SIP gateway is out of service." In general, I also find the rest of section 7 confusing and that may also explain some of the issues raised on the I-D. Jason =20 > A service provider has a number block of, for example,=20 > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has=20 > issued 50% of these numbers to individual subscribers and the=20 > other 50% have not been. These are not neatly distributed=20 > within the block, as subscribers choose their numbers so the=20 > active numbers end up being randomly distributed in the block.=20 >=20 > If the SP registers SIP URIs for all of the active TNs then=20 > those calls will work and terminate just fine. If a TN is=20 > not registered then, since it is inactive, then if a person=20 > dials one of the unregistered TNs then you have to wait for=20 > NXDOMAIN response. In that case, most softswitches / proxies=20 > will then do legacy lookups (LNP, LERG, etc.). The downside=20 > is two-fold: greater post-dial delay than is necessary, and=20 > having to rely on legacy call lookup tools (which may have=20 > associated costs). There should be a way instead to stop the=20 > call routing progression immediately if you know that the TN=20 > is inactive, thus triggering back the code for a number not=20 > in service network announcement to a caller. >=20 > Is this a correct understanding of one of the issues the=20 > authors are trying to identify in the problem statement? >=20 > Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 19:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhF4n-0004tf-Iq; Mon, 06 Nov 2006 19:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEgu-0002Jv-2Z for enum@ietf.org; Mon, 06 Nov 2006 19:19:48 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEcY-0006Hx-EK for enum@ietf.org; Mon, 06 Nov 2006 19:15:24 -0500 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27209510; Mon, 06 Nov 2006 19:14:56 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:14:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement? Date: Mon, 6 Nov 2006 19:14:55 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602453E6E@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement? Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIg From: "Livingood, Jason" To: X-OriginalArrivalTime: 07 Nov 2006 00:14:56.0889 (UTC) FILETIME=[C18E2690:01C70201] X-Spam-Score: 0.6 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > What would be useful is a mechanism "between" a=20 > registration holding > NAPTRs with URIs and the lack of a domain registration. =20 > In this way, > an entity who is responsible for E.164 numbers in a range can > indicate that a particular number has not been assigned to=20 > anyone for > communications service. For example, if a communications service > provider has been allocated responsibility for delivering calls to > endpoints identified with E.164 numbers in a block, then they may > have some numbers in that block that are currently unused. These > E.164 numbers are not used to terminate calls to end users. So from this, I would understand the problem as such - A service provider has a number block of, for example, +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has issued 50% of these numbers to individual subscribers and the other 50% have not been. These are not neatly distributed within the block, as subscribers choose their numbers so the active numbers end up being randomly distributed in the block.=20 If the SP registers SIP URIs for all of the active TNs then those calls will work and terminate just fine. If a TN is not registered then, since it is inactive, then if a person dials one of the unregistered TNs then you have to wait for NXDOMAIN response. In that case, most softswitches / proxies will then do legacy lookups (LNP, LERG, etc.). The downside is two-fold: greater post-dial delay than is necessary, and having to rely on legacy call lookup tools (which may have associated costs). There should be a way instead to stop the call routing progression immediately if you know that the TN is inactive, thus triggering back the code for a number not in service network announcement to a caller. Is this a correct understanding of one of the issues the authors are trying to identify in the problem statement? Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 06 19:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFFz-0003yv-Mp; Mon, 06 Nov 2006 19:56:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFFx-0003x7-MQ for enum@ietf.org; Mon, 06 Nov 2006 19:56:01 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhFFw-0005qH-2M for enum@ietf.org; Mon, 06 Nov 2006 19:56:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement? Date: Tue, 7 Nov 2006 01:54:16 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BC0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement? thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAAG6HgE= References: <45AEC6EF95942140888406588E1A6602453E6E@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , X-Spam-Score: 0.6 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >Is this a correct understanding of one of the issues the authors are >trying to identify in the problem statement? One of the issues, yes Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Di 07.11.2006 01:14 An: enum@ietf.org Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = Agreement onProblem Statement? > What would be useful is a mechanism "between" a > registration holding > NAPTRs with URIs and the lack of a domain registration.=20 > In this way, > an entity who is responsible for E.164 numbers in a range can > indicate that a particular number has not been assigned to > anyone for > communications service. For example, if a communications service > provider has been allocated responsibility for delivering calls to > endpoints identified with E.164 numbers in a block, then they may > have some numbers in that block that are currently unused. These > E.164 numbers are not used to terminate calls to end users. So from this, I would understand the problem as such - A service provider has a number block of, for example, +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has issued 50% of these numbers to individual subscribers and the other 50% have not been. These are not neatly distributed within the block, as subscribers choose their numbers so the active numbers end up being randomly distributed in the block. If the SP registers SIP URIs for all of the active TNs then those calls will work and terminate just fine. If a TN is not registered then, since it is inactive, then if a person dials one of the unregistered TNs then you have to wait for NXDOMAIN response. In that case, most softswitches / proxies will then do legacy lookups (LNP, LERG, etc.). The downside is two-fold: greater post-dial delay than is necessary, and having to rely on legacy call lookup tools (which may have associated costs). There should be a way instead to stop the call routing progression immediately if you know that the TN is inactive, thus triggering back the code for a number not in service network announcement to a caller. Is this a correct understanding of one of the issues the authors are trying to identify in the problem statement? Jason _______________________________________________ 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 enum-bounces@ietf.org Mon Nov 06 20:32:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFoR-0006YK-Be; Mon, 06 Nov 2006 20:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFoP-0006YE-EM for enum@ietf.org; Mon, 06 Nov 2006 20:31:37 -0500 Received: from mailgw.nic.or.kr ([202.30.50.169] helo=nida.or.kr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhFoM-0001r4-MG for enum@ietf.org; Mon, 06 Nov 2006 20:31:37 -0500 X-HELO: ehlo mail.nic.or.kr X-RECEIVED-IP: 202.30.50.51 Received: from 202.30.50.51(202.30.50.51) at Tue, 07 Nov 2006 10:33:36 +0900 by nida.or.kr with ESMTP CrediShield X-MAIL-FROM: jhlim@nida.or.kr Received: from sr71 (localhost [127.0.0.1]) by mail.nic.or.kr (v3smtp 8.11.6.9/8.11.0) with ESMTP id kA71Uvi06322; Tue, 7 Nov 2006 10:30:57 +0900 (KST) From: "JoonHyung Lim" To: "'Livingood, Jason'" , , Subject: RE: [Enum] draft-lim-kim-enum-based-softswitch-00 Date: Mon, 6 Nov 2006 17:30:56 -0800 Message-ID: <018c01c7020c$607a4f40$d632a8c0@sr71> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB8Hp8Wk1vplM6Q7W6IfxP7BRfBQAErLfA In-Reply-To: <45AEC6EF95942140888406588E1A6602453E36@PACDCEXCMB04.cable.comcast.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Right, Primary intended objective is definately '(1)'. I hope this draft will progress with this objective. Never intended on Korea-only thing. As you said, we also had to decide how softswitch works with ENUM during the implementation period. And, I think '(2)' might be good objective for this draft in another aspect of view, but I couldn't find a pure progression about the call routing logic at this time. It will be another future work we can talking about. Thanks for your comments. ======================================== JoonHyung Lim National Internet Development Agency of Korea(NIDA) ======================================== > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 2:11 PM > To: jhlim@nida.or.kr; wkim@nida.or.kr; enum@ietf.org > Subject: [Enum] draft-lim-kim-enum-based-softswitch-00 > > Continuing discussion from the WG meeting on this I-D -> > seems like we should resolve the problem we're trying to > solve with this, or what the objective of the I-D is. > > >From reading the draft a couple of times now, it seems like > the authors > are trying to (1) specify a requirement that could be > referenced by softswitch vendors so that such vendors > actually support ENUM, which may simply mean that the switch > must have an ENUM client with specific requirements around > the root to be queried and how call routing should progress > after the failure of an ENUM lookup. Then, another is to (2) > specify the progression of the call routing logic in the > switch itself with first a lookup to infrastructure ENUM and > then progression to other internal tables or other methods. > > As a service provider, we've worked on both of these things > with our vendors so I can understand the desire to solve this > by implementers. > As the co-authors are from a national agency in Korea though, > perhaps the objective is to specify how implementation should > work for vendors and service providers in Korea? If so, > perhaps this is more a BCP for Korean implementation / Korean > numbering space? If not, and #1 and #2 are objectives, then > maybe a BCP or Informational document is more appropriate? > > Not sure either way - throwing out some discussion points... > > Jason > > _______________________________________________ > 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 enum-bounces@ietf.org Mon Nov 06 22:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHPt-0007gZ-Mq; Mon, 06 Nov 2006 22:14:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHPs-0007gQ-V4 for enum@ietf.org; Mon, 06 Nov 2006 22:14:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHPr-0007qB-JF for enum@ietf.org; Mon, 06 Nov 2006 22:14:24 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2006 19:14:22 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="340159473:sNHT49943012" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73ENHC002520 for ; Mon, 6 Nov 2006 19:14:23 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA73EMbF005267 for ; Mon, 6 Nov 2006 19:14:22 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:14:22 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:14:22 -0800 Message-ID: <454FFA0D.5060406@cisco.com> Date: Mon, 06 Nov 2006 22:14:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 03:14:22.0613 (UTC) FILETIME=[D26D4450:01C7021A] DKIM-Signature: a=rsa-sha1; q=dns; l=1900; t=1162869263; x=1163733263; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=3A=20Lunch=20logistics=20update=20[DO=20NOT=20REPLY]; X=v=3Dcisco.com=3B=20h=3Dwvzj+J9U4bGAuwmnCCs9T7HKQa8=3D; b=FXmp1uUJtqDQJxJfM6khyXYpXSfie7NcbWeSRETN6MNHxAJNXycjifqQ0qpCe1RNgw4al1LY slRIImPAFPHlNtz3H8Z54tOzd34+iuXAsbTVXsc8hS8y4bVAj3FBRM9P; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Enum] ICE tutorial: Lunch logistics update [DO NOT REPLY] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt) WHEN: Tuesday, November 7 1130-1300 Lunch will be provided at a nominal fee of $10 Sandwiches, salad and chips Bring-your-own beverage Please get me your $10 prior to the end of the IETF meeting. Only 90 lunches have been ordered, its first-come-first-served I am covering this out of my own pocket, so please do get me your $10 if you partake of the food. I'm not tracking who eats or pays - we're on the honor system here! WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice). !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 03:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhMmZ-0000Sl-Dw; Tue, 07 Nov 2006 03:58:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhMmX-0000Sf-TI for enum@ietf.org; Tue, 07 Nov 2006 03:58:09 -0500 Received: from open.nlnetlabs.nl ([2001:7b8:206:1:211:2fff:fed7:7378]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhMmW-0002fr-Gj for enum@ietf.org; Tue, 07 Nov 2006 03:58:09 -0500 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.8/8.13.4) with ESMTP id kA78vqHi081358; Tue, 7 Nov 2006 09:57:53 +0100 (CET) (envelope-from jaap@open.nlnetlabs.nl) Message-Id: <200611070857.kA78vqHi081358@open.nlnetlabs.nl> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt In-reply-to: Your message of Mon, 06 Nov 2006 13:58:21 -0800. <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> Date: Tue, 07 Nov 2006 09:57:52 +0100 From: Jaap Akkerhuis X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on open.nlnetlabs.nl X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF ENUM WG , enum-wg@ripe.net, Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 6 okt 2006, at 00.06, Otmar Lendl wrote: > The IETF enum list seems to be broken, This is not the first time I've seen this claim. However, how this list seems to be broken is never specified. Did you checked the archives whether it really didn't make the list? What was the response of the list software when you send something that didn't make the list? When did "the list" broke? Your list maintainers want to know what is going on so they can correct this. Just repeating that the list is broken is unproductive. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 08:29:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhQzZ-0006c9-7s; Tue, 07 Nov 2006 08:27:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCFa-0007cb-62 for enum@ietf.org; Mon, 06 Nov 2006 16:43:26 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhC1Q-00051M-5y for enum@ietf.org; Mon, 06 Nov 2006 16:28:52 -0500 Received: (eyou send program); Tue, 07 Nov 2006 05:28:35 +0800 Message-ID: <362848515.31311@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [130.129.66.172]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 07 Nov 2006 05:28:35 +0800 Message-ID: <454FA904.1010300@cnnic.cn> Date: Tue, 07 Nov 2006 05:28:36 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Otmar Lendl Subject: Re: [Enum] Re: draft-chenh-enum-app-auth-00.txt References: <362842578.26962@cnnic.cn> In-Reply-To: <362842578.26962@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Tue, 07 Nov 2006 08:27:51 -0500 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org 1)public key will be stored into the ENUM DNS. 2)Exact, replay attack is good question, some mechanism, e.g. timestamp, should be used to against that. BUT, this has not been covered in this draft up to now. -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn Otmar Lendl wrote: > Regarding draft-chenh-enum-app-auth-00.txt: > > | 2.3. Application > | > > [...] > > | In order to improve the security and privacy of ENUM service, > | authentication function can be introduced into ENUM applications. > | When the originer initiates a service, the initiation message carries > | both originer's un-encrypted ENUM number and encrypted ENUM number > | field with sender's public key. > > Shouldn't that be the private key? > > Two other questions: > > * Do you propose to store the public key directly in the ENUM dns, > or just a refernce (URI) to a key-server which keeps the public > keys? > > * How to you protect the scheme against replay attacks? > > /ol > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 11:35:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTtU-0000No-IA; Tue, 07 Nov 2006 11:33:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTtS-0000Mk-W2 for enum@ietf.org; Tue, 07 Nov 2006 11:33:46 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTtQ-00070W-KY for enum@ietf.org; Tue, 07 Nov 2006 11:33:46 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Nov 2006 11:33:44 -0500 X-IronPort-AV: i="4.09,397,1157342400"; d="scan'208"; a="109007288:sNHT53774464" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7GXirx031373; Tue, 7 Nov 2006 11:33:44 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA7GXiDM020509; Tue, 7 Nov 2006 11:33:44 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 11:33:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement? Date: Tue, 7 Nov 2006 11:33:40 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DA886@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement? Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgACJxYnA= From: "Michael Hammer \(mhammer\)" To: "Livingood, Jason" , X-OriginalArrivalTime: 07 Nov 2006 16:33:44.0250 (UTC) FILETIME=[7DCA49A0:01C7028A] DKIM-Signature: a=rsa-sha1; q=dns; l=2933; t=1162917224; x=1163781224; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Enum]=20draft-ietf-enum-void-02=20-->=20First=20Question=20-=20 Agreement=20onProblem=20Statement? |To:=22Livingood, =20Jason=22=20, =20; X=v=3Dcisco.com=3B=20h=3DDzWbSoKpI1mZk6AHQZQa02lreYU=3D; b=0r5r6hFacVgY0yeT/DEa/F0xZHSnZLtBkPREtxPJhI+9AneFsIZAmoKfgIp3kxRYycDe+UYF lUfQRX/ZFh+ZKFO7XnHDNadFuMuCSZ9W85xf42UVeQsA3qiKWgDCdyeb; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org It's a question of pay me now or pay me later. Do SP's want to pay the cost in an ENUM response, or a failed PSTN GW call? I would argue that handling in ENUM would be much, much more efficient, since it won't involve setting up media to a PSTN GW, the added gateway control signaling, and possibly occupation of otherwise useful trunk capacity, just to find out the number is not assigned. Mike > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Monday, November 06, 2006 7:15 PM > To: enum@ietf.org > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First=20 > Question - Agreement onProblem Statement? >=20 > > What would be useful is a mechanism "between" a registration=20 > > holding > > NAPTRs with URIs and the lack of a domain registration. =20 > > In this way, > > an entity who is responsible for E.164 numbers in a range can > > indicate that a particular number has not been assigned=20 > to anyone=20 > > for > > communications service. For example, if a communications service > > provider has been allocated responsibility for=20 > delivering calls to > > endpoints identified with E.164 numbers in a block, then they may > > have some numbers in that block that are currently unused. These > > E.164 numbers are not used to terminate calls to end users. >=20 > So from this, I would understand the problem as such - >=20 > A service provider has a number block of, for example,=20 > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has=20 > issued 50% of these numbers to individual subscribers and the=20 > other 50% have not been. These are not neatly distributed=20 > within the block, as subscribers choose their numbers so the=20 > active numbers end up being randomly distributed in the block.=20 >=20 > If the SP registers SIP URIs for all of the active TNs then=20 > those calls will work and terminate just fine. If a TN is=20 > not registered then, since it is inactive, then if a person=20 > dials one of the unregistered TNs then you have to wait for=20 > NXDOMAIN response. In that case, most softswitches / proxies=20 > will then do legacy lookups (LNP, LERG, etc.). > The downside is two-fold: greater post-dial delay than is=20 > necessary, and having to rely on legacy call lookup tools=20 > (which may have associated costs). There should be a way=20 > instead to stop the call routing progression immediately if=20 > you know that the TN is inactive, thus triggering back the=20 > code for a number not in service network announcement to a caller. >=20 > Is this a correct understanding of one of the issues the=20 > authors are trying to identify in the problem statement? >=20 > Jason >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 13:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVLV-0002NS-H1; Tue, 07 Nov 2006 13:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVLT-0002N4-FQ for enum@ietf.org; Tue, 07 Nov 2006 13:06:47 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVL4-0007VK-VS for enum@ietf.org; Tue, 07 Nov 2006 13:06:47 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 173B256892 for ; Tue, 7 Nov 2006 10:06:12 -0800 (PST) (envelope-from spouliotte@nominum.com) X-Spam-Status: No, hits=0.0 required=7.0 tests=AWL: -0.718,BAYES_99: 4.07,FORGED_RCVD_HELO: 0.135, HOT_NASTY: 0.157,HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.5, SUBJECT_ENCODED_TWICE: 1.723, SUBJECT_EXCESS_QP: 0, CUSTOM_RULE_FROM: ALLOW, TOTAL_SCORE: 6.868 X-Spam-Level: Received: from 67.111.99.2 ([67.111.99.2]) by mail.nominum.com for enum@ietf.org; Tue, 7 Nov 2006 10:06:10 -0800 To: enum@ietf.org From: "Shawn Pouliotte" Subject: =?iso-8859-1?Q?RE=3A_=5BEnum=5D_draft-ietf-enum-void-02_--=3E_Firs?= =?iso-8859-1?Q?t_Question_-_Agreement_onProblem_Statement=3F?= In-Reply-To: 072C5B76F7CEAB488172C6F64B30B5E3022DA886@xmb-rtp-20b.amer.cisco.com Message-ID: <20061107180610.da6ba7ea@mail.nominum.com> Date: Tue, 07 Nov 2006 10:06:10 -0800 X-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 MIME-Version: 1.0 X-Spam-Score: 2.7 (++) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0332714852==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0332714852== Content-Type: multipart/alternative; boundary="-----------0fabcf1c74086628243fc2035024bd05" This is a multi-part message in MIME format. -------------0fabcf1c74086628243fc2035024bd05 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem statement at least in my mind is clear and pretty much every= carrier I discuss the concept with see the value. Its important to be a= ble to distinguish between un-issued addresses and non-existant for all = the reasons already mentioned.=20 Just my 2 cents =5F=5F=5F=5F=5F =20 From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] To: Livingood, Jason [mailto:Jason=5FLivingood@cable.comcast.com], enum@= ietf.org Sent: Tue, 07 Nov 2006 08:33:40 -0800 Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreeme= nt onProblem Statement=3F It's a question of pay me now or pay me later. =20 Do SP's want to pay the cost in an ENUM response, or a failed PSTN GW call=3F =20 I would argue that handling in ENUM would be much, much more efficient= , since it won't involve setting up media to a PSTN GW, the added gatewa= y control signaling, and possibly occupation of otherwise useful trunk capacity, just to find out the number is not assigned. =20 Mike =20 =20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason=5FLivingood@cable.comcast.com]= =20 > Sent: Monday, November 06, 2006 7:15 PM > To: enum@ietf.org > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First=20 > Question - Agreement onProblem Statement=3F >=20 > > What would be useful is a mechanism "between" a registration=20 > > holding > > NAPTRs with URIs and the lack of a domain registration. =20 > > In this way, > > an entity who is responsible for E.164 numbers in a range can > > indicate that a particular number has not been assigned=20 > to anyone=20 > > for > > communications service. For example, if a communications servi= ce > > provider has been allocated responsibility for=20 > delivering calls to > > endpoints identified with E.164 numbers in a block, then they m= ay > > have some numbers in that block that are currently unused. The= se > > E.164 numbers are not used to terminate calls to end users. >=20 > So from this, I would understand the problem as such - >=20 > A service provider has a number block of, for example,=20 > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has=20 > issued 50% of these numbers to individual subscribers and the=20 > other 50% have not been. These are not neatly distributed=20 > within the block, as subscribers choose their numbers so the=20 > active numbers end up being randomly distributed in the block.=20 >=20 > If the SP registers SIP URIs for all of the active TNs then=20 > those calls will work and terminate just fine. If a TN is=20 > not registered then, since it is inactive, then if a person=20 > dials one of the unregistered TNs then you have to wait for=20 > NXDOMAIN response. In that case, most softswitches / proxies=20 > will then do legacy lookups (LNP, LERG, etc.). > The downside is two-fold: greater post-dial delay than is=20 > necessary, and having to rely on legacy call lookup tools=20 > (which may have associated costs). There should be a way=20 > instead to stop the call routing progression immediately if=20 > you know that the TN is inactive, thus triggering back the=20 > code for a number not in service network announcement to a caller. >=20 > Is this a correct understanding of one of the issues the=20 > authors are trying to identify in the problem statement=3F >=20 > Jason >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =20 -------------0fabcf1c74086628243fc2035024bd05 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem statement at least in my mind is clear and pretty much every= carrier I discuss the concept with see the value. Its important to be a= ble to distinguish between un-issued addresses and non-existant for all = the reasons already mentioned.

Just my 2 cents
From: Michael Hammer (mhammer)= [mailto:mhammer@cisco.com]
To: Livingood, Jason [mailto:Jason= =5FLivingood@cable.comcast.com], enum@ietf.org
Sent: Tue, 07 N= ov 2006 08:33:40 -0800
Subject: RE: [Enum] draft-ietf-enum-voi= d-02 --> First Question - Agreement onProblem Statement=3F

It'= s a question of pay me now or pay me later.

Do SP's want to pay the cost in an ENUM response, or a failed PSTN GW call=3F

I would argue that handling in ENUM would be much, much more efficient,<= br> since it won't involve setting up media to a PSTN GW, the added gateway<= br> control signaling, and possibly occupation of otherwise useful trunk
capacity, just to find out the number is not assigned.

Mike


> -----Original Message-----
> From: Livingood, Jason [mailto:Jason=5FLivingood@cable.comcast.com]
> Sent: Monday, November 06, 2006 7:15 PM
> To: enum@ietf.org
> Subject: RE: [Enum] draft-ietf-enum-void-02 --> First
> Question - Agreement onProblem Statement=3F
>
> > What would be useful is a mechanism "between" a registratio= n
> > holding
> > NAPTRs with URIs and the lack of a domain registration. > > In this way,
> > an entity who is responsible for E.164 numbers in a range c= an
> > indicate that a particular number has not been assigned > to anyone
> > for
> > communications service. For example, if a communications s= ervice
> > provider has been allocated responsibility for
> delivering calls to
> > endpoints identified with E.164 numbers in a block, then th= ey may
> > have some numbers in that block that are currently unused. = These
> > E.164 numbers are not used to terminate calls to end users.=
>
> So from this, I would understand the problem as such -
>
> A service provider has a number block of, for example,
> +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has
> issued 50% of these numbers to individual subscribers and the
> other 50% have not been. These are not neatly distributed
> within the block, as subscribers choose their numbers so the
> active numbers end up being randomly distributed in the block.
>
> If the SP registers SIP URIs for all of the active TNs then
> those calls will work and terminate just fine. If a TN is
> not registered then, since it is inactive, then if a person
> dials one of the unregistered TNs then you have to wait for
> NXDOMAIN response. In that case, most softswitches / proxies
> will then do legacy lookups (LNP, LERG, etc.).
> The downside is two-fold: greater post-dial delay than is
> necessary, and having to rely on legacy call lookup tools
> (which may have associated costs). There should be a way
> instead to stop the call routing progression immediately if
> you know that the TN is inactive, thus triggering back the
> code for a number not in service network announcement to a caller.<= br> >
> Is this a correct understanding of one of the issues the
> authors are trying to identify in the problem statement=3F
>
> Jason
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum
-------------0fabcf1c74086628243fc2035024bd05-- --===============0332714852== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0332714852==-- From enum-bounces@ietf.org Tue Nov 07 13:40:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVrs-0006ZC-Fu; Tue, 07 Nov 2006 13:40:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVrr-0006XG-Jw for enum@ietf.org; Tue, 07 Nov 2006 13:40:15 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhVro-0004RX-CQ for enum@ietf.org; Tue, 07 Nov 2006 13:40:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 19:39:24 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BC5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: void-02 new version thread-index: AccCl4socHc73M5BSkWSnjO3fH+GWgAAcyVy References: <20061107180610.da6ba7ea@mail.nominum.com> From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Enum] void-02 new version X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think there is a rough consensus that it is useful to have an = indication=20 of unallocated number blocks and unassigned numbers in ENUM. =20 To update the draft I have some questions: =20 Q1: is it useful to distinguish between unallocated numbers and = unassigned numbers from an originating users point-of-view? =20 Q2: Some people seem to have a problem with the naming of the ENUMservice (void). We choose the name because it was short I am open for proposals for something else (also dependant of Q1) Proposals that where mentioned already: status sit If there is a distinction required between unassigned and unallocated: unas unal =20 Q3: There where also some discussions on the URI (note: we need an URI because of the syntax of the NAPTR) I do not see any need for a change here, but there was also a=20 proposal to use a txt URI =20 Note: there was also a proposal to simply use a sip URI pointing=20 to an (sit) announcement. This is not possible because ENUM may be used also by non-voice clients. It is the decision of the originating client how to react to the user if it encounters (void). =20 Q4: The problem of section 7 (enclosing zone) If one reads the text, the whole issue is optional and it is recommended to enter (void) for each potential number. =20 Nevertheless, in countries with variable length numbers (including = direct- dial-in) THIS DOES NOT WORK. =20 So we optionally came up with this approach, because we need it.=20 It is e.g not required in countries with fixed number lenght such as the NANP. Maybe we should state this more clearly =20 regards Richard =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 14:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWWX-0000yE-Rq; Tue, 07 Nov 2006 14:22:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWWW-0000tP-G3 for enum@ietf.org; Tue, 07 Nov 2006 14:22:16 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWWV-0001Lx-2s for enum@ietf.org; Tue, 07 Nov 2006 14:22:16 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 44B634CC9D; Tue, 7 Nov 2006 20:22:10 +0100 (CET) Date: Tue, 7 Nov 2006 20:22:10 +0100 From: Otmar Lendl To: Stastny Richard Subject: Re: [Enum] void-02 new version Message-ID: <20061107192210.GA1386@nic.at> References: <20061107180610.da6ba7ea@mail.nominum.com> <32755D354E6B65498C3BD9FD496C7D462C4BC5@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BC5@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/07 19:11, Stastny Richard wrote: > I think there is a rough consensus that it is useful to have an indication > of unallocated number blocks and unassigned numbers in ENUM. > > To update the draft I have some questions: > > Q1: is it useful to distinguish between unallocated numbers and unassigned > numbers from an originating users point-of-view? Not that much. IMHO. Does the PSTN offer different error codes to the end-user (i.e. SIT cadence vs. ???) ? > Q2: Some people seem to have a problem with the naming of the > ENUMservice (void). We choose the name because it was short > I am open for proposals for something else > (also dependant of Q1) > Proposals that where mentioned already: > status > sit > If there is a distinction required between unassigned and unallocated: > unas > unal "status" may be the better choice as it keeps the path open to indicate other conditions which we have not considered right now. > Q3: There where also some discussions on the URI > (note: we need an URI because of the syntax of the NAPTR) > I do not see any need for a change here, but there was also a > proposal to use a txt URI What about we change the service-type to a generic status and use a URI to indicate the status? e.g. "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . or perhaps do something similar to the ECRIT service URNs: "E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.unassigned!" . or "E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.unallocated!" . "E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.invalid!" . this opens to "E2U+status" "u" 0 0 "!.*!urn:pstn-status:active.ported!" . > Note: there was also a proposal to simply use a sip URI pointing > to an (sit) announcement. This is not possible because ENUM may > be used also by non-voice clients. It is the decision of the originating > client how to react to the user if it encounters (void). agreed. > Q4: The problem of section 7 (enclosing zone) > If one reads the text, the whole issue is optional and it is recommended > to enter (void) for each potential number. AFAIK this is exactly the point where Peter's concerns are. > Nevertheless, in countries with variable length numbers (including direct- > dial-in) THIS DOES NOT WORK. Well, it's either that or DNS wildcards. The URI might contain some information regarding the range of numbers which are not valid on the PSTN. > So we optionally came up with this approach, because we need it. > It is e.g not required in countries with fixed number lenght such as > the NANP. > Maybe we should state this more clearly That may be a good idea in any case. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 14:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWlR-0008W8-Ce; Tue, 07 Nov 2006 14:37:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWlQ-0008W0-Hz for enum@ietf.org; Tue, 07 Nov 2006 14:37:40 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWlO-0002pg-6f for enum@ietf.org; Tue, 07 Nov 2006 14:37:40 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7JbUAJ006186; Tue, 7 Nov 2006 19:37:37 GMT From: "Richard Shockey" To: "'Livingood, Jason'" , Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement? Date: Tue, 7 Nov 2006 14:37:22 -0500 Organization: NeuStar, Inc, Message-ID: <004b01c702a4$2a322550$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45AEC6EF95942140888406588E1A6602453E42@PACDCEXCMB04.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwAmw0Yg X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I certainly got the sense from the room that there is a problem here. There is a strong desire for ENUM systems to have the ability to distinguish between active and non allocated numbers or number blocks. The problem statement being that CUA or other entities do not want to initiate a session if it is clear that the number is inactive. There are clear reasons to distinguish between non active vs non existent numbers. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 5:55 PM > To: enum@ietf.org > Subject: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement > onProblem Statement? > > Follow-up on discussion of this I-D at the WG session today. It seems > like the chairs and AD are asking whether or not people feel strongly > about this particular service and will actually use it, as it will take > time & energy to overcome concerns raised through the I-D review process > (concerns which will surely be raised again in later reviews in the > process). > > So perhaps I can propose we step back for a moment, considering the need > for void or not as an enumservice type? Here I think the best starting > point is for everyone to re-read section 3 of the draft, called "The > Problem" and decide whether or not there is agreement on that problem. > If so, we can *then* decide if void solves that problem or not, but we > have to first at least agree on the problem. Here is that text, FYI: > > 3. The Problem > > At present, from the ENUM client's perspective, two possibilities > exist: there is an ENUM domain that potentially holds alternative > contacts, or there is no ENUM domain, in which case a query on ENUM > will return a DNS response showing 'no such domain' (NXDOMAIN, code > 3)[4]. > > This latter response is ambiguous. There are two potential reasons > for the lack of an ENUM domain holding alternative contacts; either > the assignee has chosen not to register the domain, or the E.164 > number is not assigned for communications service at present. > > If the number is assigned, then the caller can use the E.164 number > to place the call via a network that uses such identifiers as global > addresses (i.e. the CSN). If however, there is no domain because the > associated E.164 number is not assigned for communications service, > then any attempt to place the call via the CSN will fail. > > What would be useful is a mechanism "between" a registration holding > NAPTRs with URIs and the lack of a domain registration. In this way, > an entity who is responsible for E.164 numbers in a range can > indicate that a particular number has not been assigned to anyone for > communications service. For example, if a communications service > provider has been allocated responsibility for delivering calls to > endpoints identified with E.164 numbers in a block, then they may > have some numbers in that block that are currently unused. These > E.164 numbers are not used to terminate calls to end users. > > An originating user agent cannot differentiate this state from the > one in which there is an end user as a number assignee, but that end > user has have chosen not to "publish" other contacts. In effect, it > would be more useful if the originating end user could receive a > response that states "there is no service via this number", as > opposed to "there may be service via this number, but there are no > alternative contacts available". > > In short, the issue is distinguishing between E.164 numbers that do > not have corresponding ENUM entries but are supported via the PSTN > and those E.164 numbers that are not terminated on the PSTN. In this > latter case lack of a NAPTR holding a destination URI really implies > that there is no service at all for this telephone number. For > example, some number ranges have been allocated for service that is > provided only via reference to an ENUM domain, and terminate on the > Internet (i.e. these calls will terminate only at a VoIP end point). > The fundamental problem is that there may be inconsistencies between > the E.164 name space as it is understood by the National Regulatory > Authority (NRA) and how that name space is represented in ENUM, as > service moves towards being provided in some cases only via non-PSTN > access. In effect, the PSTN may not have complete information and > ENUM may be required to deliver a call, but the data stored in ENUM > at present may be ambiguous. > > For applications such as an ENUM-aware VoIP/PSTN gateway, this > presents a problem. These would use ENUM to decide how to route or > terminate a call. A simple default configuration rule for such a > gateway would probably be: "if the number called is not in ENUM or > has no NAPTR records, dump the call to the PSTN". Such a rule is > likely to be the norm while most telephony traffic uses the public > telephone network. In other words, if the response from the DNS is > that the number does not exist in ENUM, the gateway would try to > terminate the call on the PSTN. > > This will not always work. The number that was attempted may be in > some range that cannot be terminated on the PSTN: a block assigned > for VoIP and ENUM exclusively, and for which there is no PSTN > termination, for example. If a number in such a range had not been > entered into ENUM, the DNS would return the expected NXDOMAIN or > NOHOST response, causing the gateway to take its default action which > would have undefined results. Where a "not in service" number is > within such a special number block, the typical action of a PSTN > element will be to pass this on to a VoIP/PSTN gateway, where as just > described another ENUM query may be used to determine call treatment: > the result could be a processing "loop". > > > Jason > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 14:38:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWls-0001VH-VK; Tue, 07 Nov 2006 14:38:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWlr-0001K9-3U for enum@ietf.org; Tue, 07 Nov 2006 14:38:07 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWlp-0002sM-LO for enum@ietf.org; Tue, 07 Nov 2006 14:38:07 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7JbwAJ006193; Tue, 7 Nov 2006 19:38:04 GMT From: "Richard Shockey" To: "'Livingood, Jason'" , Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? Date: Tue, 7 Nov 2006 14:37:57 -0500 Organization: NeuStar, Inc, Message-ID: <004c01c702a4$3b139660$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45AEC6EF95942140888406588E1A6602453E74@PACDCEXCMB04.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In line.. Chair hat off.. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 7:37 PM > To: enum@ietf.org > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement > onSOLUTION Void? > > So if we have agreement / consensus on the problem statement, then the > next obvious step is to determine if the solution recommended by the > void service is the right one. My question is, if not void, then what? > > A SP could register their inactive TNs with SIP URIs that go to a > special URI that plays back an announcement that the number is inactive, > such as sip:inactive@example.foo or sip:12159811234@example.foo (where > that URI is used for ALL inactive numbers). In both cases, > communication is initiated from the caller to this URI, and the > terminating side would then have to trigger and play an announcement > (but it would otherwise look like a normally completed call). > > I think the use of void potentially gives the call originator at the > network edge access to this information more directly, potentially > obviating the need to even attempt a call. In general, I kind of like > being able to figure that sort of stuff out at the egde / point of > origination. So I like that about the void proposal. Yes.. > > Are there other methods that people think could solve for this problem? > > I am a bit more ambivalent about the contact address (email addr or http > URL), but this may be useful for some clients and applications that I > don't yet see a use case for yet. I'd certainly like to understand this use case better. > > Perhaps another concern is the name of the service being VOID. Perhaps > some take that to mean that the query was invalid in some manner? If > so, perhaps it could be called INACTIVE or something like that > instead... The general use case to me seems to revolve around what is the status of a particular TN within the network at a particular point in time. Now that begs the question of how do you express status with the caveat that the DNS is not very good at expressing highly dynamic data. I agree the term void may have been a contributing factor to the confusion in the IESG on what this draft was trying to accomplish. My own personal thinking of what the appropriate enumservice for this problem should be is something along the lines of E2U+status:text where the URI is a text URI text:inactive We could define as text a limited number of status condition potentially including compound status with semicolon separators. Just a thought but it has simplicity easy to parse and is extensible if someone thinks of something else like text:inactive;SPID=6666 > > Also, I'd suggest the authors consider removal of this text in section > 7, as I'd suggest that I am not sure SPs would actually do this and I > think regular SIP mechanisms can handle these scenarios: > "This could be done for a variety of reasons. The number could have > been delegated to an end user who has chosen to insert this record: for > instance it's in an ENUM or VoIP only number block and the end user's > SIP gateway is out of service." > > In general, I also find the rest of section 7 confusing and that may > also explain some of the issues raised on the I-D. > > > Jason > > > > A service provider has a number block of, for example, > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > issued 50% of these numbers to individual subscribers and the > > other 50% have not been. These are not neatly distributed > > within the block, as subscribers choose their numbers so the > > active numbers end up being randomly distributed in the block. > > > > If the SP registers SIP URIs for all of the active TNs then > > those calls will work and terminate just fine. If a TN is > > not registered then, since it is inactive, then if a person > > dials one of the unregistered TNs then you have to wait for > > NXDOMAIN response. In that case, most softswitches / proxies > > will then do legacy lookups (LNP, LERG, etc.). The downside > > is two-fold: greater post-dial delay than is necessary, and > > having to rely on legacy call lookup tools (which may have > > associated costs). There should be a way instead to stop the > > call routing progression immediately if you know that the TN > > is inactive, thus triggering back the code for a number not > > in service network announcement to a caller. > > > > Is this a correct understanding of one of the issues the > > authors are trying to identify in the problem statement? > > > > Jason > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 15:08:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXEO-0004n5-7q; Tue, 07 Nov 2006 15:07:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXEM-0004m5-Ut for enum@ietf.org; Tue, 07 Nov 2006 15:07:34 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhXEK-0005ra-6R for enum@ietf.org; Tue, 07 Nov 2006 15:07:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonProblem Statement? Date: Tue, 7 Nov 2006 21:03:45 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BC6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonProblem Statement? thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwAmw0YgAAWN4GQ= References: <004b01c702a4$2a322550$78218182@cis.neustar.com> From: "Stastny Richard" To: , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org numbers. Could you please elaborate what this clear reasons are? =20 BTW: we have three values now: =20 unallocated (not existent) unassigned (not existent) inactive (inactive -=3D out-of-service- barred - etc) =20 Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Di 07.11.2006 20:37 An: 'Livingood, Jason'; enum@ietf.org Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonProblem Statement? I certainly got the sense from the room that there is a problem here. = There is a strong desire for ENUM systems to have the ability to distinguish between active and non allocated numbers or number blocks. The problem statement being that CUA or other entities do not want to initiate a session if it is clear that the number is inactive. There are clear reasons to distinguish between non active vs non = existent numbers. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 5:55 PM > To: enum@ietf.org > Subject: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement > onProblem Statement? > > Follow-up on discussion of this I-D at the WG session today. It seems > like the chairs and AD are asking whether or not people feel strongly > about this particular service and will actually use it, as it will = take > time & energy to overcome concerns raised through the I-D review = process > (concerns which will surely be raised again in later reviews in the > process). > > So perhaps I can propose we step back for a moment, considering the = need > for void or not as an enumservice type? Here I think the best = starting > point is for everyone to re-read section 3 of the draft, called "The > Problem" and decide whether or not there is agreement on that problem. > If so, we can *then* decide if void solves that problem or not, but we > have to first at least agree on the problem. Here is that text, FYI: > > 3. The Problem > > At present, from the ENUM client's perspective, two possibilities > exist: there is an ENUM domain that potentially holds alternative > contacts, or there is no ENUM domain, in which case a query on ENUM > will return a DNS response showing 'no such domain' (NXDOMAIN, code > 3)[4]. > > This latter response is ambiguous. There are two potential reasons > for the lack of an ENUM domain holding alternative contacts; either > the assignee has chosen not to register the domain, or the E.164 > number is not assigned for communications service at present. > > If the number is assigned, then the caller can use the E.164 number > to place the call via a network that uses such identifiers as = global > addresses (i.e. the CSN). If however, there is no domain because = the > associated E.164 number is not assigned for communications service, > then any attempt to place the call via the CSN will fail. > > What would be useful is a mechanism "between" a registration = holding > NAPTRs with URIs and the lack of a domain registration. In this = way, > an entity who is responsible for E.164 numbers in a range can > indicate that a particular number has not been assigned to anyone = for > communications service. For example, if a communications service > provider has been allocated responsibility for delivering calls to > endpoints identified with E.164 numbers in a block, then they may > have some numbers in that block that are currently unused. These > E.164 numbers are not used to terminate calls to end users. > > An originating user agent cannot differentiate this state from the > one in which there is an end user as a number assignee, but that = end > user has have chosen not to "publish" other contacts. In effect, = it > would be more useful if the originating end user could receive a > response that states "there is no service via this number", as > opposed to "there may be service via this number, but there are no > alternative contacts available". > > In short, the issue is distinguishing between E.164 numbers that do > not have corresponding ENUM entries but are supported via the PSTN > and those E.164 numbers that are not terminated on the PSTN. In = this > latter case lack of a NAPTR holding a destination URI really = implies > that there is no service at all for this telephone number. For > example, some number ranges have been allocated for service that is > provided only via reference to an ENUM domain, and terminate on the > Internet (i.e. these calls will terminate only at a VoIP end = point). > The fundamental problem is that there may be inconsistencies = between > the E.164 name space as it is understood by the National Regulatory > Authority (NRA) and how that name space is represented in ENUM, as > service moves towards being provided in some cases only via = non-PSTN > access. In effect, the PSTN may not have complete information and > ENUM may be required to deliver a call, but the data stored in ENUM > at present may be ambiguous. > > For applications such as an ENUM-aware VoIP/PSTN gateway, this > presents a problem. These would use ENUM to decide how to route or > terminate a call. A simple default configuration rule for such a > gateway would probably be: "if the number called is not in ENUM or > has no NAPTR records, dump the call to the PSTN". Such a rule is > likely to be the norm while most telephony traffic uses the public > telephone network. In other words, if the response from the DNS is > that the number does not exist in ENUM, the gateway would try to > terminate the call on the PSTN. > > This will not always work. The number that was attempted may be in > some range that cannot be terminated on the PSTN: a block assigned > for VoIP and ENUM exclusively, and for which there is no PSTN > termination, for example. If a number in such a range had not been > entered into ENUM, the DNS would return the expected NXDOMAIN or > NOHOST response, causing the gateway to take its default action = which > would have undefined results. Where a "not in service" number is > within such a special number block, the typical action of a PSTN > element will be to pass this on to a VoIP/PSTN gateway, where as = just > described another ENUM query may be used to determine call = treatment: > the result could be a processing "loop". > > > Jason > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 15:13:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXIs-0000po-MU; Tue, 07 Nov 2006 15:12:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXIr-0000pj-40 for enum@ietf.org; Tue, 07 Nov 2006 15:12:13 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhXIo-0006JJ-Co for enum@ietf.org; Tue, 07 Nov 2006 15:12:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 21:10:15 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BC7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFduZR References: <004c01c702a4$3b139660$78218182@cis.neustar.com> From: "Stastny Richard" To: , "Livingood, Jason" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >E2U+status:text where the URI is a text URI text:inactive =20 What about an URN as Otmar proposed? =20 Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Di 07.11.2006 20:37 An: 'Livingood, Jason'; enum@ietf.org Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? In line.. Chair hat off.. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 7:37 PM > To: enum@ietf.org > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = Agreement > onSOLUTION Void? > > So if we have agreement / consensus on the problem statement, then the > next obvious step is to determine if the solution recommended by the > void service is the right one. My question is, if not void, then = what? > > A SP could register their inactive TNs with SIP URIs that go to a > special URI that plays back an announcement that the number is = inactive, > such as sip:inactive@example.foo or sip:12159811234@example.foo (where > that URI is used for ALL inactive numbers). In both cases, > communication is initiated from the caller to this URI, and the > terminating side would then have to trigger and play an announcement > (but it would otherwise look like a normally completed call). > > I think the use of void potentially gives the call originator at the > network edge access to this information more directly, potentially > obviating the need to even attempt a call. In general, I kind of like > being able to figure that sort of stuff out at the egde / point of > origination. So I like that about the void proposal. Yes.. > > Are there other methods that people think could solve for this = problem? > > I am a bit more ambivalent about the contact address (email addr or = http > URL), but this may be useful for some clients and applications that I > don't yet see a use case for yet. I'd certainly like to understand this use case better. > > Perhaps another concern is the name of the service being VOID. = Perhaps > some take that to mean that the query was invalid in some manner? If > so, perhaps it could be called INACTIVE or something like that > instead... The general use case to me seems to revolve around what is the status of = a particular TN within the network at a particular point in time. Now that begs the question of how do you express status with the caveat = that the DNS is not very good at expressing highly dynamic data. I agree the term void may have been a contributing factor to the = confusion in the IESG on what this draft was trying to accomplish. My own personal thinking of what the appropriate enumservice for this problem should be is something along the lines of E2U+status:text where the URI is a text URI text:inactive We could define as text a limited number of status condition potentially including compound status with semicolon separators. Just a thought but it has simplicity easy to parse and is extensible if someone thinks of something else like text:inactive;SPID=3D6666 > > Also, I'd suggest the authors consider removal of this text in section > 7, as I'd suggest that I am not sure SPs would actually do this and I > think regular SIP mechanisms can handle these scenarios: > "This could be done for a variety of reasons. The number could have > been delegated to an end user who has chosen to insert this record: = for > instance it's in an ENUM or VoIP only number block and the end user's > SIP gateway is out of service." > > In general, I also find the rest of section 7 confusing and that may > also explain some of the issues raised on the I-D. > > > Jason > > > > A service provider has a number block of, for example, > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > issued 50% of these numbers to individual subscribers and the > > other 50% have not been. These are not neatly distributed > > within the block, as subscribers choose their numbers so the > > active numbers end up being randomly distributed in the block. > > > > If the SP registers SIP URIs for all of the active TNs then > > those calls will work and terminate just fine. If a TN is > > not registered then, since it is inactive, then if a person > > dials one of the unregistered TNs then you have to wait for > > NXDOMAIN response. In that case, most softswitches / proxies > > will then do legacy lookups (LNP, LERG, etc.). The downside > > is two-fold: greater post-dial delay than is necessary, and > > having to rely on legacy call lookup tools (which may have > > associated costs). There should be a way instead to stop the > > call routing progression immediately if you know that the TN > > is inactive, thus triggering back the code for a number not > > in service network announcement to a caller. > > > > Is this a correct understanding of one of the issues the > > authors are trying to identify in the problem statement? > > > > Jason > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 15:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXNv-0002RC-8C; Tue, 07 Nov 2006 15:17:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXNu-0002R2-0l for enum@ietf.org; Tue, 07 Nov 2006 15:17:26 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhXNs-000730-8A for enum@ietf.org; Tue, 07 Nov 2006 15:17:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 21:14:31 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BC8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVL References: <004c01c702a4$3b139660$78218182@cis.neustar.com> From: "Stastny Richard" To: , "Livingood, Jason" , X-Spam-Score: 0.6 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >Just a thought but it has simplicity easy to parse and is extensible if >someone thinks of something else like text:inactive;SPID=3D6666 Could you please start thinking global There is currently no global SPIDs =20 So who is defining them? =20 If the SPID is needed at all, the pointer to a webpage or an email = address works as well =20 Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Di 07.11.2006 20:37 An: 'Livingood, Jason'; enum@ietf.org Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? In line.. Chair hat off.. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 7:37 PM > To: enum@ietf.org > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = Agreement > onSOLUTION Void? > > So if we have agreement / consensus on the problem statement, then the > next obvious step is to determine if the solution recommended by the > void service is the right one. My question is, if not void, then = what? > > A SP could register their inactive TNs with SIP URIs that go to a > special URI that plays back an announcement that the number is = inactive, > such as sip:inactive@example.foo or sip:12159811234@example.foo (where > that URI is used for ALL inactive numbers). In both cases, > communication is initiated from the caller to this URI, and the > terminating side would then have to trigger and play an announcement > (but it would otherwise look like a normally completed call). > > I think the use of void potentially gives the call originator at the > network edge access to this information more directly, potentially > obviating the need to even attempt a call. In general, I kind of like > being able to figure that sort of stuff out at the egde / point of > origination. So I like that about the void proposal. Yes.. > > Are there other methods that people think could solve for this = problem? > > I am a bit more ambivalent about the contact address (email addr or = http > URL), but this may be useful for some clients and applications that I > don't yet see a use case for yet. I'd certainly like to understand this use case better. > > Perhaps another concern is the name of the service being VOID. = Perhaps > some take that to mean that the query was invalid in some manner? If > so, perhaps it could be called INACTIVE or something like that > instead... The general use case to me seems to revolve around what is the status of = a particular TN within the network at a particular point in time. Now that begs the question of how do you express status with the caveat = that the DNS is not very good at expressing highly dynamic data. I agree the term void may have been a contributing factor to the = confusion in the IESG on what this draft was trying to accomplish. My own personal thinking of what the appropriate enumservice for this problem should be is something along the lines of E2U+status:text where the URI is a text URI text:inactive We could define as text a limited number of status condition potentially including compound status with semicolon separators. Just a thought but it has simplicity easy to parse and is extensible if someone thinks of something else like text:inactive;SPID=3D6666 > > Also, I'd suggest the authors consider removal of this text in section > 7, as I'd suggest that I am not sure SPs would actually do this and I > think regular SIP mechanisms can handle these scenarios: > "This could be done for a variety of reasons. The number could have > been delegated to an end user who has chosen to insert this record: = for > instance it's in an ENUM or VoIP only number block and the end user's > SIP gateway is out of service." > > In general, I also find the rest of section 7 confusing and that may > also explain some of the issues raised on the I-D. > > > Jason > > > > A service provider has a number block of, for example, > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > issued 50% of these numbers to individual subscribers and the > > other 50% have not been. These are not neatly distributed > > within the block, as subscribers choose their numbers so the > > active numbers end up being randomly distributed in the block. > > > > If the SP registers SIP URIs for all of the active TNs then > > those calls will work and terminate just fine. If a TN is > > not registered then, since it is inactive, then if a person > > dials one of the unregistered TNs then you have to wait for > > NXDOMAIN response. In that case, most softswitches / proxies > > will then do legacy lookups (LNP, LERG, etc.). The downside > > is two-fold: greater post-dial delay than is necessary, and > > having to rely on legacy call lookup tools (which may have > > associated costs). There should be a way instead to stop the > > call routing progression immediately if you know that the TN > > is inactive, thus triggering back the code for a number not > > in service network announcement to a caller. > > > > Is this a correct understanding of one of the issues the > > authors are trying to identify in the problem statement? > > > > Jason > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 15:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXaL-00026m-Fm; Tue, 07 Nov 2006 15:30:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXaK-00023N-5c for enum@ietf.org; Tue, 07 Nov 2006 15:30:16 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXaI-00007x-RH for enum@ietf.org; Tue, 07 Nov 2006 15:30:16 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7KU6AJ006825; Tue, 7 Nov 2006 20:30:12 GMT From: "Richard Shockey" To: "'Stastny Richard'" , "'Livingood, Jason'" , Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question -AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 15:30:01 -0500 Organization: NeuStar, Inc, Message-ID: <008501c702ab$832c7320$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BC7@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFduZRAAA1QxA= X-Spam-Score: 0.6 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org NO. NO URN's NAPTR Records are URI's 3761 is The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 3:10 PM > To: richard@shockey.us; Livingood, Jason; enum@ietf.org > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > >E2U+status:text where the URI is a text URI text:inactive > > What about an URN as Otmar proposed? > > Richard > > ________________________________ > > Von: Richard Shockey [mailto:richard@shockey.us] > Gesendet: Di 07.11.2006 20:37 > An: 'Livingood, Jason'; enum@ietf.org > Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > > > In line.. Chair hat off.. > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, November 06, 2006 7:37 PM > > To: enum@ietf.org > > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - > Agreement > > onSOLUTION Void? > > > > So if we have agreement / consensus on the problem statement, then the > > next obvious step is to determine if the solution recommended by the > > void service is the right one. My question is, if not void, then what? > > > > A SP could register their inactive TNs with SIP URIs that go to a > > special URI that plays back an announcement that the number is inactive, > > such as sip:inactive@example.foo or sip:12159811234@example.foo (where > > that URI is used for ALL inactive numbers). In both cases, > > communication is initiated from the caller to this URI, and the > > terminating side would then have to trigger and play an announcement > > (but it would otherwise look like a normally completed call). > > > > I think the use of void potentially gives the call originator at the > > network edge access to this information more directly, potentially > > obviating the need to even attempt a call. In general, I kind of like > > being able to figure that sort of stuff out at the egde / point of > > origination. So I like that about the void proposal. > > Yes.. > > > > > Are there other methods that people think could solve for this problem? > > > > I am a bit more ambivalent about the contact address (email addr or http > > URL), but this may be useful for some clients and applications that I > > don't yet see a use case for yet. > > I'd certainly like to understand this use case better. > > > > > Perhaps another concern is the name of the service being VOID. Perhaps > > some take that to mean that the query was invalid in some manner? If > > so, perhaps it could be called INACTIVE or something like that > > instead... > > The general use case to me seems to revolve around what is the status of a > particular TN within the network at a particular point in time. > > Now that begs the question of how do you express status with the caveat > that > the DNS is not very good at expressing highly dynamic data. > > I agree the term void may have been a contributing factor to the confusion > in the IESG on what this draft was trying to accomplish. > > My own personal thinking of what the appropriate enumservice for this > problem should be is something along the lines of > > E2U+status:text where the URI is a text URI text:inactive > > We could define as text a limited number of status condition potentially > including compound status with semicolon separators. > > Just a thought but it has simplicity easy to parse and is extensible if > someone thinks of something else like text:inactive;SPID=6666 > > > > > Also, I'd suggest the authors consider removal of this text in section > > 7, as I'd suggest that I am not sure SPs would actually do this and I > > think regular SIP mechanisms can handle these scenarios: > > "This could be done for a variety of reasons. The number could have > > been delegated to an end user who has chosen to insert this record: for > > instance it's in an ENUM or VoIP only number block and the end user's > > SIP gateway is out of service." > > > > In general, I also find the rest of section 7 confusing and that may > > also explain some of the issues raised on the I-D. > > > > > > Jason > > > > > > > A service provider has a number block of, for example, > > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > > issued 50% of these numbers to individual subscribers and the > > > other 50% have not been. These are not neatly distributed > > > within the block, as subscribers choose their numbers so the > > > active numbers end up being randomly distributed in the block. > > > > > > If the SP registers SIP URIs for all of the active TNs then > > > those calls will work and terminate just fine. If a TN is > > > not registered then, since it is inactive, then if a person > > > dials one of the unregistered TNs then you have to wait for > > > NXDOMAIN response. In that case, most softswitches / proxies > > > will then do legacy lookups (LNP, LERG, etc.). The downside > > > is two-fold: greater post-dial delay than is necessary, and > > > having to rely on legacy call lookup tools (which may have > > > associated costs). There should be a way instead to stop the > > > call routing progression immediately if you know that the TN > > > is inactive, thus triggering back the code for a number not > > > in service network announcement to a caller. > > > > > > Is this a correct understanding of one of the issues the > > > authors are trying to identify in the problem statement? > > > > > > Jason > > > > _______________________________________________ > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 15:31:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXbp-00043C-HN; Tue, 07 Nov 2006 15:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXbn-00040u-VF for enum@ietf.org; Tue, 07 Nov 2006 15:31:47 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXbm-0000HY-HD for enum@ietf.org; Tue, 07 Nov 2006 15:31:47 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7KVZAJ006833; Tue, 7 Nov 2006 20:31:42 GMT From: "Richard Shockey" To: "'Stastny Richard'" , "'Livingood, Jason'" , Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 15:31:33 -0500 Organization: NeuStar, Inc, Message-ID: <008601c702ab$b8557560$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0087_01C70281.CF7F6D60" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BC8@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAAA1GQA= X-MS-TNEF-Correlator: 00000000D782A326514E234E9AEF378ABB1DFA3DC4678100 X-Spam-Score: 0.6 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C70281.CF7F6D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please ..I was only using that as example of something some one MIGHT want to try. I know there are no global SIPD's. For the purposes of this draft I think limiting the response to unallocated (not existent) unassigned (not existent) inactive (inactive -= out-of-service- barred - etc) is sufficient. I just want the URI syntax for status conditions to _eventually_ be extensible. Which is why something like E2U+status:[uri] makes sense but I'm not totally sold on this. The more I think about it what you are proposing with the http and email address is something entirely different than what is actually needed. What you are discussing is essentially TN ownership which is not line (number) status. That I increasingly think that this point to carrier of record via http or smtp should be its own URI scheme. We know what the problem is lets keep the solution very very simple, even if that means starting over from scratch. _____ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, November 07, 2006 3:15 PM To: richard@shockey.us; Livingood, Jason; enum@ietf.org Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? >Just a thought but it has simplicity easy to parse and is extensible if >someone thinks of something else like text:inactive;SPID=6666 Could you please start thinking global There is currently no global SPIDs So who is defining them? If the SPID is needed at all, the pointer to a webpage or an email address works as well Richard _____ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Di 07.11.2006 20:37 An: 'Livingood, Jason'; enum@ietf.org Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? In line.. Chair hat off.. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 7:37 PM > To: enum@ietf.org > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement > onSOLUTION Void? > > So if we have agreement / consensus on the problem statement, then the > next obvious step is to determine if the solution recommended by the > void service is the right one. My question is, if not void, then what? > > A SP could register their inactive TNs with SIP URIs that go to a > special URI that plays back an announcement that the number is inactive, > such as sip:inactive@example.foo or sip:12159811234@example.foo (where > that URI is used for ALL inactive numbers). In both cases, > communication is initiated from the caller to this URI, and the > terminating side would then have to trigger and play an announcement > (but it would otherwise look like a normally completed call). > > I think the use of void potentially gives the call originator at the > network edge access to this information more directly, potentially > obviating the need to even attempt a call. In general, I kind of like > being able to figure that sort of stuff out at the egde / point of > origination. So I like that about the void proposal. Yes.. > > Are there other methods that people think could solve for this problem? > > I am a bit more ambivalent about the contact address (email addr or http > URL), but this may be useful for some clients and applications that I > don't yet see a use case for yet. I'd certainly like to understand this use case better. > > Perhaps another concern is the name of the service being VOID. Perhaps > some take that to mean that the query was invalid in some manner? If > so, perhaps it could be called INACTIVE or something like that > instead... The general use case to me seems to revolve around what is the status of a particular TN within the network at a particular point in time. Now that begs the question of how do you express status with the caveat that the DNS is not very good at expressing highly dynamic data. I agree the term void may have been a contributing factor to the confusion in the IESG on what this draft was trying to accomplish. My own personal thinking of what the appropriate enumservice for this problem should be is something along the lines of E2U+status:text where the URI is a text URI text:inactive We could define as text a limited number of status condition potentially including compound status with semicolon separators. Just a thought but it has simplicity easy to parse and is extensible if someone thinks of something else like text:inactive;SPID=6666 > > Also, I'd suggest the authors consider removal of this text in section > 7, as I'd suggest that I am not sure SPs would actually do this and I > think regular SIP mechanisms can handle these scenarios: > "This could be done for a variety of reasons. The number could have > been delegated to an end user who has chosen to insert this record: for > instance it's in an ENUM or VoIP only number block and the end user's > SIP gateway is out of service." > > In general, I also find the rest of section 7 confusing and that may > also explain some of the issues raised on the I-D. > > > Jason > > > > A service provider has a number block of, for example, > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > issued 50% of these numbers to individual subscribers and the > > other 50% have not been. These are not neatly distributed > > within the block, as subscribers choose their numbers so the > > active numbers end up being randomly distributed in the block. > > > > If the SP registers SIP URIs for all of the active TNs then > > those calls will work and terminate just fine. If a TN is > > not registered then, since it is inactive, then if a person > > dials one of the unregistered TNs then you have to wait for > > NXDOMAIN response. In that case, most softswitches / proxies > > will then do legacy lookups (LNP, LERG, etc.). The downside > > is two-fold: greater post-dial delay than is necessary, and > > having to rely on legacy call lookup tools (which may have > > associated costs). There should be a way instead to stop the > > call routing progression immediately if you know that the TN > > is inactive, thus triggering back the code for a number not > > in service network announcement to a caller. > > > > Is this a correct understanding of one of the issues the > > authors are trying to identify in the problem statement? > > > > Jason > > _______________________________________________ > 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 ------=_NextPart_000_0087_01C70281.CF7F6D60 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IiMUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgDkMAAAJAAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMA LgAAAAAAHgBwAAEAAABOAAAAW0VudW1dIGRyYWZ0LWlldGYtZW51bS12b2lkLTAyIC0tPiBGaXJz dCBRdWVzdGlvbiAtIEFncmVlbWVudG9uU09MVVRJT04gVm9pZD8AAAACAXEAAQAAAC8AAAABxwH2 kAAuk6w8wn1M1r6yecbv6I0jAAJx8iAAAJBbsAAkEhWwAAWdFUsAADUZAAALAAEOAAAAAAIBCg4B AAAAGAAAAAAAAADXgqMmUU4jTprvN4q7Hfo9woAAAAMAFA4BAAAAHgAoDgEAAAAyAAAAMDAwMDAw MDQBUmljaC5TaG9ja2V5QE5ldVN0YXIuYml6AW9hay5uZXVzdGFyLmNvbQAAAB4AKQ4BAAAAMgAA ADAwMDAwMDA0AVJpY2guU2hvY2tleUBOZXVTdGFyLmJpegFvYWsubmV1c3Rhci5jb20AAAADAN4/ n04AAAMAAlkAABYAAwAJWQIAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AI IAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAAA AAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPYAIIAYAAAAAAMAAAAAAAABGAAAA ABiFAAAAAAAACwBSgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAFOACCAGAAAAAADAAAAA AAAARgAAAAABhQAAAAAAAEAAVYAIIAYAAAAAAMAAAAAAAABGAAAAAGCFAAAACNboKQAAAAsAHw4B AAAAAgH4DwEAAAAQAAAA14KjJlFOI06a7zeKux36PQIB+g8BAAAAEAAAANeCoyZRTiNOmu83irsd +j0DAP4PBQAAAAIBCRABAAAAAy0AAP8sAABxuAAATFpGdSPeiDUDAAoAcmNwZzEyNYIyA0NodG1s MQMw/wEDAfcKgAKkA+QHEwKAEAP/AFAEVghVB7IRNQ5RAwECAIRjaArAc2V0MgYA2wbDETUzBEYT xzASPwIA7jQDxRXZEOo1F78WfwIAWjYZryAHbRE1NwPGVHxhaANxAoARQwjvCfc7qyBfDjA1IX9l DiA4Is93IVERQQxgYwBQCwkBZDMmNhqgC6U0IBACKlxHDrIBkA4QOSA8DrIghngO0ACAOnY9Ighw JG46BPBoZQDAcy2mbQ3gA2BzbwGALQWg1m0pYA7QIikFbymPKpm1KsBmDeBlLbUrdncsDxctHy8A BbBkK3ZzdDG/Ly8wPzKQAMAAIChRcyt1AzJADrB0cDovL3chNgAudzMuBbBnL4BUUi9SRUMtDrLw NDAiPhFDJ/cUUAqjMzevOL9nMyeQKLBlYb5kN50O8ToPPI8oNDYO8EY8B4ABkCBuYQeAPeZHCfAE kGF0BbEFoAIwlQnwdDJATSp2IFcxYfQgMQ7wKC3gKEAEkAmAgiAHgGRpdW0pN44LPe85kzQ/USEt LVuRBpAgIW0qsF0+CqMiPDIQeWxlRuR2XIhcOioDMHtiZRPwFHZpBbA6CHBsKCMJAQFhdShAI1ZN TOopJBB9CqNvSB9JL0o1TndKv0vPSjUucxPwcG5lTZ9Or0cSL0dZRhBb8wnwQzBmXUYwQ59Eryhh xDc3KKB0aXRHgUT/gQfwRTogW0VuQ1B4XSBkQGAq0QiQADAtAwnwQ1Atdm9pZC0GMBRQRjAmZ3Q7 IOxGaRQQBUBRClAyEFDA9QOgLQqjQQnCB4ACMAIgAFNPTFVUSU9OlCBWWeE/VC04NVKBx1avVN9F am86UzSCHwDYZ1R5UCE/0nMKsC4APwhxMk8zXzRpCqM/xCJQkwSQKrBuTj/hIi9fP/9gT0W/Rs8K wTIRTVJQX1Fl5QiQbwhgaSkDMFI/U0//aA9pHz9RR1Rx/3GUakJmRMovTYBGAiEgRAEQC4CnXvBb cQQgKi9mREACEv4tUXAuAAqkAZFQQXdlKmC4bHk6HwV3+AqwbiqgMGUtMToUUEJBNiB5J5AzIF6g J5AnkBRQNDtKJnWCU0didg9mYnAuGk0qsE4FsADAbCwg7GxpfspDMHZ+yHf6NIFyZwuAOjALgHnZ gfQtpwbgAkArES4whDAxBTD3edl3YwCQei4QDiCEIIR/lXj2IgdtIkomYTp/gKxua39gYvFufsJI YnHvURCJcXf6H9M6CjJ52UDw/ngq4AWDQHBbcVDwcCCKc9+MIYjmbQAAkEDwZImviYD1dcBsH/B3 CYCK34vvjP99jg1wgTsqsCpQg1RAgHByLQdAdDpRgECAgp8t/QUQZw6wgl6WOIO0lw+DGP9HgAGA gl2FT4Zfh2+Ie4+j/kUAwAMQfRNegJVuR1OWwL1icTqKYWcxB0CYoGULUH55nu95FBDkd/iR9D/Q dmulcUpEQAqwZ1AwBmBjj1tiJbN4Np4zOC41C4C/QjGEIIJ/gjGrc0IwLg4w/60TrQhKJoBiqX9Q QakiYdD/r0VKJnBxca9p4iiRbyVwr++yD7S/KDNqEi87bzm/uI+VJ+g1GqA8BuBkeX9wgQBwZz1F Ti1VBfD9iWI9CjJH8LzHt/AoAwAh4wMwvBIxMDN7oL4mGqBfJ7snAbpvwL8oMzl7YDzvgGFAsAtg BBA9rza+CQAAr79vwc/Gbye7NjsxcMPVz37XxM/F3w4QNDgooAIS22wgnkE9FFAf0z2oUp3QvWMR PQcTyusL4gMwYxNQ7wMxJ5DLrygkODsxj6JsIflHcT0nnegKo78AnqOmP9o7p/gnyu/Rc1BHgGQg cVAwLi5JTTBkIEqQbvl5QCB1AJC8MJMwE/AFQO/Y4ZNQP+ALUGW2nMhVviff0RkqwGwgA3AUMGjZ gt1yg9kBUDBNSUdIVNjBx3XhQICTMHJ5LiesJ4D7OzFhwHC3/g5AbwHg/8NQX+Iyj6K+Cb4XzC41 w3Ev/wIS5C/lM74mCqLk2AqBvjf/CrHpuMYNAcBvAeEeyE/tT//JH8ov1x/MT81fzm/Pf9CP/9Gf 0q/Tv9TP1d/xn8X+4K9x+McmbmJi8AKAvign/mELwP4v4c/i3+PvAn/mD/8GD+gv6T/qT+tf7G/u zw7//++f8K/9n/LP89/07/X/9w//FF/5L/o/+0/8XxNPGdLYsP5reqCIQNnAQsGJMCEReqA0IGeQ 4GKBEKlgSVDiRAAvIzgyVlABewVQ+Rl4cy7+v//PA78EzwXf/xm/B/8qHwofCy8MPw1PDl//EL8z DxGPEp8TrxS/Fc8W3/8X7xj/Gg8bHxwvHT8eTzdf//6vJn8AzwHfAu8n3yjvLM//Kw8sHy0vLj8v TzBfMW8zz/8zj1UPNa82v0OvON857zr//zwPPR8+Lz8/QE9BX0JvWVzfkLCRYCDhenBtUHB6sdjx 92qg3bHaIGST0JzQIGHdsv5r2r/bz19Ff4B5ILDw2ZP/ISClMGDAdpEhIN9RRF9Fb/9JX0pvS39f X02fcT9Pv1DP/1HfUu9T/1Zfei9XL1g4YQb/k0ObUmDBXOCoQN5hZK93z0da716wXMMiQ29moGnb pLCgsiJdb17BNV8PYB3/oZRhLmJ/oDGDmn/vhf9tT/9GH0cvjA9ur2+/cM+QX3Lv/5PvdQ92H3cv eD95T3uvnN//fH99j36ff6+aT4HPgt+D7/+E/6PPhx+IL4k/ik+i/9lQFVxwbCHAY9ngZWQgfigg oGfg2kBncKFwW3Ap/4x/jY+Rf5KPk5+ov5W/tX//l9+Y75n/mw+cH55/vm+fT/+gX6Fvon+736Sf pa+mv6fP/8Vfqe+q/6wPrR/Ej68xWBD8aWfecK/fsO+zf7MPtB//t//KT7dPuF+5b7p/u4+8n/++ /8AP3+/A38Hvwv/ED91f/8Yvxz/IT8lfym/Lf8yPzZ9fzq/mDmtQXNBrQHYhICj58ictPWh/aY/r lfAA71AnZyDuUPBAdmlc4C0gHSHgcmvQ0UD24GV0Y//SP9NP1F/Vb9Z/65/Yn/xv/9q/28/c393v 3v/hXwVf4i//4z/kT+VfAs/nf+iP6Z/qr/8MT+zP7d/u7+//C38Rj47v/4//+B/5L/o/+0//L/1v /n///48AnwGvAr8DzwYvBe8ob/8ID1h/Fw8M/1uvXL9dz17ffxHPYP9iD2MfZC/xTWcAc7h1Zmb2 sA8QLtAuZ/HkanU0cCB3NEBn4GZSJFVSaABzeS7QYXj/MBBmIPN/9I8ypTRwr6A6kLkvYW5kazFs EWxSXzMfemkwy2kybzN/E0oTQjrfazA3MPawOA9ChGXygC7Q+nWvUXkdjx6fQk9ISUFK70npQCw9 H0I5YmZwCgHSAC0T8GITYDpAV2gwY2jZOWJ3aDAACPBt95BoMQtrcGsAa2ZwRTJVK8k+1DpbDvFd IAlAUkB3OYFQIWZwYgpQZ/AXvyNwODIxNxkLSKBJ+G3/TT9OT0ol0XIKYEVxFUBRce5s0UAK8GdD LhqfG68cv/9IH0kvSj8g/2BfIx8kLyU//yZPJ18pv2lPKo8rnyyvLb//Ls8v3zDvMf9C30PvNS82 P/83T22fGo9cvxhfGW+Qr14f/18vYw9hT2JfY29kf2WPZp//Z69qD2nPi09r72z/ee9vH/9wL3E/ ck9zX3RvdX92j3ef63ivj5xUOzFtmnDykDpg4VHCayBhYvYB8hA6sfJor6AgeRWQnVD3MFefw1iv lYVwcm9wCnBR4t53P4BQ8DsioBB0jgCXIJ3RQGUJQBUwnVBkZPcw745QOWNRl9IBafcwWrE/cP85 wBXQ0gFbUZcgnr+fz5WF353zOXHyQUeDWhBl0TDRMOdQkp4YpTFzYz8QoZM5caejoaSyWpNUTlsg dwsA/HJzUMCOAFFAUNGmL6c/nzkI0XJFkAsA0VF1bU/A/HIpPsU6QJxQnhE6YPIg/mP3MAigUeFa sZ0EpeE7An85caFw8iBaQq3fru+VhWO39xEPEvZAIPcwmkBy0UDd9qBhomSacJdAbaKRrTD/FZBb AU/BP4BTwKzhO1RQ4P+jAFCAep97r3+fgK+Bv5Wf/4PfwC+F/4cPiB+JL4o/jJ//yR+Nb45/j4+Q n5Gvkr+Tz/+U35Xvlv+YD5kfmi/Nb3qP/7yPfK99v37Pve++/8LfwR//wi/DP8RPxV/Gb8d/yd/J n//rH8u/zM/Zv87vz//RD9Iff9Mv1D/VT9Zf12/Yf+9sV/WxAGsK4Hed5DsioUFQYd5tOWITYLph UkBl7dA7If+0/7YPPmb6IApQP6G4kBXQp/KwAdMT8G1wE2AsRyP/spDdsLPTUaD28FPB7BDmEH1R 4m8B0fLAoVD9kKswcv8+8FDgu3/bb99f4G/hf/Vf/+OfCm/lv+bP59/o7+n/7F//E1/tL+4/70/w X/Fv8n/zj//0n/Wv9r/3z/jf+e8Xr9pP/wbP3G/dfySPCC8JPw0fGK//DG8Nfw6PD58QrxG/FB8T 3+81XysiLjE/cHYfpp1wuHCnBNAi8D+wZTs41C0f4OhmdDpa4Wm6AQFgsQB4MS41IVE2wKNwUeE6 6jCyoCA75jQhMiNPMs//Nn8+3zdPPQ8+H0B/RC83X8cWjZ1QOnBnbj0bgBoQrwTRH7VQEFAALUiT Okj0+Tz8cWMdqRV7Ql9DbxmtZjNF4xtjIlQCgFOxTtpl/IBSpCAfgCIcDh2RnmYuME4fHs8f3TEy PL//U5//LFh//8svbyxsM0v/97sw2kZPaLlBGlSh4GSdAGNRECEQMCUiSIxFkGJDsqCp8Hg9LTEc DDFTS7FLsGpcueFiU4B+7CBfZZJlUVyw0jCTMm//RU9nj2ieJYAZwSuVah8uVvVOvDAloS9CHCyf aS9wH98VPxZPF19vj1TVYhwLZUHPdY9PPxpjG2NUYbnAdID7HA8dYTd4H1SfVa8hJFCEZyGZevQh dHdlSLAAEDqvnXC58FcPfPRGBRE6Ko//K598vy2/he+G/4VDdyqJX/95LxpEUIh6/3wPjF9+L38+ zYCPYYK/kQQgU3HgksDabqyQUq2hMkBkWc//z62Q9VujErTQOpdlLpblREBvOhBlZy6x0F3ljI0x iCFico9pZhNmv/9Yz3Yvdz+fD5H/H/aCD5XP/lOsIYRvhX+L74pvqb8AgMJUOtBzZGF5AtB0UDcD ALFSPBA3AtAc8DA2F5+PmO+qZTNWkDUgUP5NnI+dn56vr0+gz6HftH/vo/+lD6YfuHhUKjCq36kv H7h/q0+/PySvugF0MTpmUATQdDBuTiHgOuB3fTpAdFEQGgBSISJQl4NACnOVIGP+MHkudXPvKQ++ gcQbByA7tR+wL7/fG8OPxJ9MR2AEcW9vZP0C0Epz4BoAxs/H38jgAuAgbnVtQGn98GYu/SLQZ7If sy+0P8k/tl+3bx/U37mPup+7r6cpdWJq/GVjp/++f7+PwJ/fz5ax1lIgoJpQRdGxXdV/yh+t4IVk BXA6IC3R8i3Rokgtdm86gC0wKfAtWi0mL2chYOV4PpY5RjZpzRADoFGtgQGDLSB4QWdy/kADwBoQ GgBTAE9MVVRJT04g+lbn0T/g/99P4F+Hr+8f//AvJY8pfzAfMS8yPzNPNF//1m/7P22v8f9vz/y/ AI9y//90D3UfjK9P2VDPUd9S7wXP/9pPID1WvwVf85/obyc/KE//9P8qb+6f/y/wv/HPL7/23//3 7xgv+g8Bzx/vRl9HYTqAoj06gE9XQeOQcJTQglRJ4TgxMzc4Dn//Hf8hrybPQU8k/yYPKG8sH98C 3wPvKn8GD3nbY9wQOaDWPTqwjsBrjqRBxaAwLfmQNGNmB8BkcNZBMR8Lz9cM3w3hk+86NJM7M4Pb 8N8z8g5vNt/pH+orSsagehAWYWLwlSB128EgYnW9ehBpehCXkAiADWBtJCC7l3BBYHnkP+VPPTVl L3Brl0CasCAt0XPNgDhgZH8jcAiASeFJAA1gM+DNgGn+ZtJ/04/Un0KvET8+r0mmvy/A7GB58M2A YZBjMGsIgK5v6iBOAk6CZ9GQbEWxf2JAxmBLfxJfE2pi8CRhOg9jMI7A66CuIDtTUEn4RD02VHEV rxa/SY8Y3/9WL1c/EK8Unxs/HE8dXx5v/x9/Sx9iT/2fWQ8rX2PPZ5//ZJ9lr2a/aR9s7yk/PG9s L/9uj3I/Lo8vn3CfMb8yzzPf/zTvNf89fzgfOS86PztPdm/ffQ9H/0kPSh9z40NAwNwg/CB5QMBF cH7QdYDNgH6gr19gjeBOg0+CZ4GwYnYwj4O/hM+F34bvfVRozQDjRuEIgGN1cuwwB0CU0PwgbkVg igSW0FQxxr1bL/8Ur1TPVd+M31f/lU8bD14f/18vYD9hT3Ovnj9p32rvnA//n7+jj28vgl+iz6Uv qN90f/91j6c/d694v3nPet97764v/34Pfx+AL4E/gk+zr1EPUh//Wj+R35Lvk/+VD7zvly/B7/+Z T5pfm2+cf52Pqo/K36C//8SPyK/MX9Avpg+5P89v0c//1X+rX6xv09+uj6+fsK+xv/+yz7pPtO+1 /7cPuB/Zr+BCGlOP8HdAsEYSZGVm/4xwT4JAoOxQ7Zy+L78/wE//wV/f78N/7N/Fn8avx7/Iz//J 39bf9c/ND84f85/3T/sf/9Jf02/6X/y/AG/Xr9i//s//2t/b79z/3g/fHwW/4T/iT//jX+Rv5X8L P7sfvC+9P+lv/+p/64/snxR/7r8Zf/Df8e//8v/0D/UfAh8ib/hPHB8gP/8j7ye//Z8Qzyb/KV8t DwLv/wP/K28GHwcvCD8JTwpfMl+/DH8Njw6fD68xPzfTSU0wb+ghkHNGEoyAZeeQRgBhk4lQMRBs LD6zcG+McL9TQB+xjY9DrzfTRVFh5xD0ZWIuwGdFwDDgRdFPsOcxADvQP+BkZI7gMHCKb+eLf4yP QV99dzDgTsEwYP9D8UAwFP8WDxcfGC8ZP0hf/xtfT38dfx6PH58gryG/Lr//WG8k71IfLE9Z712/ Kj89b/9c/19fYw8vjzCfYW8yvzPP/zTfNe82/zgPOR86Lzs/PE//Zz9t3xL/FA9K/02PTR9OL/9b z3cfUV9Sb1N/VI9Vn1av/2OvZL+FD1rvfr9iT4aPil//YD9zb4rvi/+Pr2WPZp+OD/9ov2nPat9r 72z/bg9vH3AvB3E/ck+T3yBSaWNo/YIAZHdfeG95f3qPe5+aL/99v6YPf9+A74H/gw+EH5Ef/67/ h0+or46vsH+0T4yfn8//s4+177mfke+S/7f/lR+WL/+XP5hPmV+ab5t/nI+dn56v/73Pdy+iT3T/ dg/Kz6OvpL//sl/PH6fvqP+qD6sfrC+tP/+6P7tP25+xf9VPuN/dH+Dv/7bPyf/hf+KP5j+8H70v 5J8Pv0/AVcOQwaMiVGltoUWAIE5ld6Dgb+nw7G4iwk5B8WbUgOrvxQ/7xh/HIjLHcsmf8G/Lv8zP /83f9O/P/9EP0h/5P9Q//M//1l/Xb9h/2Y/an+efBb/jLMPpLkARaWduPcHAQOLb8hZA8HjH8AoD Ogpk8+z8cWPwGegr9A8Dj+xeB1P/7W/uf++P8J/xr8aG848Pb/9BfhnvQjsAD/0MA+tCZwF6jQe/ aAqxwIR3aWQ+wGMSgMdQMCUiCfwHAGKESW4/sHg9LTHCTAYxDSENIGpcdWxk4mIU8H4gXycCJsFH o/8BMwMPBr8o/yoO9iC/8fw1/yuP/vbdb95/KE8qrzGf5/9P6Q9FIBcF6fByZ0fALehib3RDsG0Y DxkfFet+YsJLJrE4zxCvwJPBo1TcYWgTUcJPw6E3O18WDf8zoxcPx1/IYD40x7RKkAogt/hAyTDI 8GQ370A0VsfQ/jr7L/w/P//+X0kPSh9IY/86akx/PG5B5D2PPp8/r0C//xbfQx9EKUXvVCSg7xvP +IINU9lTUkDBcGV5IFs/6fDIQDdAR4z2I1XgMTqmUAqg6aBuTsggZSLAfjpV4BKAx9ATkciQWiNA 4nNdFC51c/mvSJFfO5WisF1PvDFLQWJyUon/J4MoLxo/OW86f2avVR/yZvtFP1jvRxLQCnAkwG2Q TS8PSK9qj02fca8gRGkgqDA3LmTwLsMwMEtA8cMwOjM3ZC9lP2ZPZ19/aG9pf3jva59sr22/fOhB v0d/cO9x/3MPg49Z0SdeDxtfH2AoTOPgJ6Bnb298ZCx5j1uPhE+LYzPgSg/pUMfQYe9i/30nOyAh CnB1bUBpb8BmLv3p0Gd2j3efeK+K/3rPe99flE99/38PgB+YSEJvwHL4ZWZmge+C/4QPhR+fT+lZ 4UU6XXBFkSFkHIufYZg5ZHJhZsfwkWItkZESLXZvIuAtMPqQtC0t9s9nx6D4KD5ZWUxGaYjgwFBR dRLQdK5px9CnoIGwZ51QZRLAA8fgx9BTT0xVVEnsT05HQSLgP6Bvnr+fz/9Kz66Pr5/2L/ofAL8B zwLf/wPvBP+V37qvLx+xbzE/vC//v//jL5v/vz/Bn8VPNHo2P/83T8OfT889LxKfUo8Uv5kPv0HP VovKH9Bv93/4jyAkoMIgJ5IuLiBDWjCqgPYgWjA9UG+dcNiQke+S//+UD6PfvI3an9uv3L/dz6iv d6m6p7Dk8U9gwMkBCdFN9c3wc7NQZeTz3g/fH+Av7+E/4k/jX6nocsmBsp+Ib/uJf4qCII5vj39j tF1w0M9+YeqDIjCdYM2gXZXxU1+ZiidAYySAmnAuY8mAf/cw0mD3gs69kWCbkLLCZgebkCeg0mB7 SFlQRcBSTElOSyD1v/bPeffWfX1TMZuQ72CzMFz+YyXxJoDQGfrv+//35L4f/x2f6T+txVJxZB/n n+iv6b+36s/r31loUyQRoyBNV3BYZGF58TA1wHarwGIvJEF2APEwdeM3dlEgUP5NBa8GvwfPCN8J 7wr/WXf+VLPAkQ8PPxBPEV8SbxN/gxSPDDV1YmplYwzB/6MIpi+nPxvPHN+qbxoPpL//gVarlhcP GB8ZLySvG08h3/9Zd6wfJ68ovynPKt8r7yz/fzIfMC8xPzYvM180bxz/b7wgadcgmwDZEQ2QILNQ caulIC8g+BD58Kvgc6NhwC5xIHRoX/Bw7ZD991Ft0lHZMKvD8TA/wT+j/zZvN384jzmfOq87v1l3 Q9BqeNlBYopAbz9h0mBl/chAac4AyXAfIG/A71BX0M9D0D1yP8LxcGx1qxOdUMf4EavRb7BkIGJd YEGP/0KfQ69Ev0XPRt8iuiAy0lD/71CKQM2ASbM/0eVR1sAucb/YgFE/1l/XauXAXWBxqub3ScDx MD2BbslQU8NBFE/v+yWPT3V32SEvf03vTv9a3/9RH1IvYA9eH18vZB9hT2Jf92NvgbA9QFA+4f5w TGBLwP/JAElxxbA/wdjx5YEeQMMQye/QVE7OAHdpP8A9QOJJa5BVUklUstkxinD9SeJhZH9lj2af Z69ov2nPdwwHVuAeMGnloW5hbqRw1mwNMM4AYs1waz4gmiDzmhBZ0HVuzYA+g26zP8L/FkENwknB bQaKvHBPcV9yb+dzf3SPdZx1Y24A99DM4fRwOm0GQEiw77B3cNiAP9LQPWAW0IJDybCwoDk40Xuw MjM0gxsoXUDvUP9M33vvfP9+D38fgC8L+G6zP3biScE/YExR0tDFsEFM5kxs+Hm0cylVr1a/V8z/ 2CHJQW4A98HN8Hrfhz+IT/+JX4pvi38L+EvieJBUYNkw/1kkbPFt4HagQLCOEe2RP7PdALBsyJBs gW8RaEnBbmH/DiDOkExgTL+Uj5Wflq+Xv/+Yz4xrSlObEfDgzOFKIO/g/2vDQTM9451CVRHmIMWw nhL/d3J4Hp6Pn5+gr6G/os+j3/kMByhiS2A9cI1QpoSTAX/vUG3QPyDYQPEAeACrsGv/PhFZwUpg nOFYsPgRg2GcAv+c0o+9qo+rn6yvrb+uz2O//7TPtd+6z7f/uQ+6H5KDnWK+bngAP8KN4dlRU8Rw yVD/DKF2obNByQBtYFS0nNKD0f/lY28wqBF5U7tfvG+9f76P17+fwK9IGXSmgHJ4AExQ++YgPiBj qVDl8J03bQCOMXv/QJsjbRbQ79D50EvBdP+zQA4gw8nGj8efyK/Jv8rP/8vfLfhJAaXUeXMnMJ4x PWDWZW1gqNF0QLFwjVCywH+c0o/PkN+R7+Yg07AfQGzbDiB3AGttALFhZtSfW8//1CWyctGf0q/T v9+f1d/W7z8MBw3ApfL8Ykni+SBndT/QEW6z8XDc4MMyI6B1Zv/kALEw2pF5VGwgplE+0MPA/20A 6vLiP+NP5F/lb+Z/54//LfjFhZsx2x/cL1fMPVF3AP+yc26z/GDroj/Cw3RAEMPA/nN2sLRv7k/v X/Bv8X37L9f8P/1P/lNZxLAu+k//r/8AvwHP/o8EPwVPBl/xb/J//wn/CA8JHw4PCz8MTw1fa0Ef 6kOGAbF0z+BKMGhvZP9ulXZw+eDposJza7RLMW1h/44ynXNABV2PD38QjxGfEq//E78cTxpfG28g Xx2PHp8fr/fewYUwsrFisPHP84UwKBD+dnawPpL42D7xIVBtMD4gLGRkS8DOgSipYGFpz3bAKnKD 0vZwdHAgvyHPPyLfI+8k/yYP91eNcEwpf53wsLKdc7MQWLB54I3SZv+xQI4jSzBMED7gLiDREZ2g uagyYXB3cJr1bpVJLC+/LT8uTy9fMG8xf/dXZFVw+ieNUHlKMFQRsqLDApNC/44jPrEDPzhvOX86 jwd/QV/nQm9DfzuBSSez8VQwRVD/bQCzQfg0g8B4kOxwj5BFUN+eI420P4R54NpBckBfRb//Rs9H 30SfTV9Ob09/O488n/9TH1EvUj9XL1RfVW9Wf/fA9lCxsHcwcDXSFgQp8UlBv5tTeXOFMMMjwsKx 8HLYoMOpUOkVVk9JRPTv9f//9wtan+B/ZNVehVefWK9Zv/9lf1vfXO912DUyaOD4VtmxZ6lweCF5 J3F1sbCooHf/giGOsCjhw5GOsDUUsxB4YO+xsBnMYz/230ntP2lPal//a29sf22PbprQwV6VKCEY BAc0QZzTs/BJTkFDVPhJVkWD0zUxwmLpYPg3/3Zfd294f3mPep97r/dXjrD760BwYGQDIExfgi+D P4RP31Cfia+Kv4vPhUFUwtHeRfc/SHAjPuJtzpPQYMNwGIL3jMCpIbPwd+qCYAVKsetQe52gw0Fh jQ+OH48vkD99m4yxz6BjsUCMwVROsRD/KCDCcdkVzZT4ohlAmljsxP2bYmmpcIivlv+YD5kfjO+P ny+gP6FPhUFOb3cW1P1L8GfExHEx60DPssNBFpDfpvA+UD6gsTDN4HgZUM5y/5VFmyLE1RiQcMOB D6N/pI/HpZ+FQcLCRE5TX/JfEfPDYHFSZ28WoMYSqWXY4snO8GdoxFFkeWBxNnD70DDqkGGeL6yf ra+uv6Jv37SPtZ+2r0jSJ7Bn0GAVg/9vcHFQJ9DDczQC6oAYkUvw39oCKeP0QDNx2OJmKjEY0v/O winTNKCyAM/At++4/7oPhbsffZtlSUVTRyugz9oQlIPO4yqQYWbakHGSfb7AedjjzsDOQTUwNlFz /mizj8Hfwu/D/7fPyZ/Kr/vLv4VBTTQgpuDaEH2BGGD/YHArQBej2OLrEcYVKIE2QM/50fRA6pDs MW51kzBhRf8Yxsz/zg/PH9AvmjAZZBhQ/xaQflUz0X/43pCoUMehr/H/15KVktWf1q/Xv9jPzO/d /4ffD+AfhVBFMlUrlUT6OkwgeKuMdB9kT+af56//9yqUgBXC+TIzEPgQM9En8P/mQuzi6W/qf+iv 7l/vb/B/92XvZvzmQjrjUCoxKNDjcf/hb+J/44/gT/c/+E/5X/pv7lcp0hgiSoBm/YEnsDbh/+2S J/D9cLMATCBJINRhS/DvK5H9QJVFX4FkfgCoQp1Q70wgvrDUAH7geft//I/9n/f+r8URNXB1AyDH kcgSlDP/qeqScLMBGHCoUZJw+yGrIP2cEHPInwVPBl8Hb/tfDM93Dd8O74VBSj9QnGIWgXX/snCn QSmBfgHTEKnBnfA2Uvd+ADQgcGBzNCCSoQ/RknH/StIz0eZRKRCyANoRiADc7/8RLxI/E0+FUDUi qFBvstJh85WTf/hlbJJxgJLw7/H/I+uL9ls7U1BiMD02/yOhGO8Z/xsPHB8QHyTvJf//Jw+FX4Zv Kq8ovynPLr8r73Ms/y4PIEEfAH1RSQJz/xUQkZAUkdNTvwAU8EqgvoLnsgBKgZOBbW9x8WC0YAL7 7ZJyUmX20cC/MA8xHzIv9zM/NE+HaTd9YHGhNmyrIf+8Mb0gsJI2oOyBI1CqMX5D/b9xdQQCqOJL E0rS7fw7P388Tz1fPm8/f1270kOTgWdRmqNTSVBwQWPTEG7fsGCTMX7AX+BN4WQYkV8x3ZJxc1+w 9rC+0G/mIEWv/0a/R89I30nvSv+Hh1RvcTD7XyAg2SJSeJFQsGF+N6jw/wCR1RK+cHHwvtCb4NFR UeD/vHCSYDfxYl8gj+t8kVIB5f9+M1Mf9N9Spb3SUB9RL1I/f2CfVF9Vb4eHviMAUH7wZ//UEQAw x8KoYAPAADCSEQIw/5SAqQAV0k3QT+C+QZKhiBGPcVDGRbxwAvByZDrVAv9jP2RPZV9mb2d/aI+H i0VQO9ThfgAnfeG+UahgRU7kVU1/slZvTYGoULKR8wHlGIBvY5wxlFGv4mt2/3Ywbp9vr3C/cc9y 33Pvh4f/TXJqsscQsqCwYQlwnGACUv/UpFxvWA98P3pPe1+E731//36Pf5+FT4Zfh2+If4mPip+9 IdhJqGBCII5QC2BsNkH/28EdMNUAjkB41KmRgdU6E/9BQMA226J4w6shvZGMP41P/45fj2+Qf5GP IeeUA6lhTTD/OcIdQTjk2uI2oNyhC2CwYOcBsahRxVMtRAvPmG+Zf/+aj5ufnK+j76H/ow+n/6Uv /6Y/p0+oX6lvqn+rj6yfra/9IedKXBKvP7BPsV+yb7N//7SPuP+3D7gfvQ+6P7tPvF//vW++f7+P wJ/Br8K/Vo/JH/81D4IWA4DZ8NTAODJsQgFAf3fr3NA2QNUS5lBC4J7AZf4sxD/FT8Zfx2/If8wv yp8D1f/XDysxLTIxNegtOTjawFjbYTZA7FTz22LtIi0w3LEXAtsQ3UH/gp9df16OlwEjUBXC0S/S P//TT9Rf1W/ZH9eP5g/nH5/j8QAwNTAln2UfEXfkANG/bQII4M6RRHE2kd6wY1tg/+wzeLXhP+JP 41/kb+V/6S//55/zb/R/g9Db0esjYvJDA/9qIt2P3p9ejxdyQ3FDEvCw92rARKKBgHTtsRVwAbDu n//vr/C/8c/y3/aP9P8DbwR//woyOcGg8nhTQWPtamyBbKH9eOJpOFDsBpQh7m//fwCP/wGfAq8G XwTPEI8Rn54iIvP76/drc3BqEZZik5DswB1A//28dlIIl6FvDO8N/w8PEB//E88SPx4fHy8ZXxpv G38cj98dnyFPH78nryi/SZ+E4NGPTPH98exCgMJVUklOQM9a40SQn2YVdVROOVGhAP+2byPfJO8l /ycPKr8pLzTfvzXvQmEKYk5gRJBDwWkugW1D4HJ4lfhQbTIgasEg/mprsEKglFGCj/qf+60sYf/P MC+QgXEwHzEvMj8zTzRf/zgPNn9E70X/+RItBmriL+H/CSCWUXXjgXI7gRWDCSAv0vt2UD+CcOxB tl9BD0IfQy//RD9H70ZfUg9TH2Iw/eCeUTN3gZ9XdW5J6S+WIHn/gbD4tGsRgUBLUW5vTj9PT39Q X1FvVR9Tj18/YE85cU7AWERPTUFJP9CU4f5woMCVYDx/PY8+naDS4KF3OgCVYAkgbTnA4LBNIGZc dHMIIQowoCEvzlJ4/mmgIFqfW69cv13PXt9ij79g/2+fcK86Y0xTF2Ag0PDNgQBjgWB4YG9rFqAK EBAoTE5QCSBMRVLKRwkgZWnQLillP2ZP+/u/dOF3ZQDOoWrPa99s739t/28Pcr9xL3+/gM9LgXTF OrAtLjBsZDqTQJTgbzuhfwBk4P4ALVbiVtBl/57QdXCW4UyBChB9AEsgn/D9fvB5CSHswHrve/99 D34f/38vgt+BT4z/jg/4wZZi7IH/lOD9saDBdSU6AnWF3PGE8Pd18dvAziBolyL4s4gviT//ik+L X4xvkB+Oj5ovmz8JQK1NIGNW8BhCY2khc3cf13gveT/b4nMKQHWFAPlB388hWhB1cJdgWFFhOyHs kP3+AG+T4QvPlk+XX5hvmX//nS+bn6o/q08VUJNDznD+UC8W8s5hhUHq0GmSoWltvm1KYJ8y/bFM oVlSa/kQ/ndoVFeyP8Clj6afp6+ov/+pz61/q++3r7i/S4078KVA2e2wZ2f4UBbyYhVw0AD/V7Kf kM6wLiTPRvkRst+z7/+0/7YPtx+6z7k/xO/F/whh/83mwjCEoTrT+RBX8EsgsMD+brJR7JDPMDoC +FAZT8Ef/8Ivwz/ET8f/xm/RL9I/zG//zX/Oj8+f0K/UX9LP2r/bz+8uAQhB7gGfgXJYgC8wV+H/ esAWMNaA7MEXAS6xV0nqw/8vs9Xv1v/YD9kf2i/d39xP++fP6N9h/lAKQO3y/QH+EP55keV6sctw TKCkMlejalHfCNDLQKTxO6HLUj/i/+QP/+Uf5i/nP+rv6V/039Tv8B//8S/yP/NP9v/4D/Z//m84 rv5KCUBNP/p/+4/8n/2vAV//Bc8D3wTvCd8HDwgfCS8VUP5fET8STxMaCk8LXwxvDX//Do8PnzkX L/C/gJTBOnDtcv8WIJ+wFC8VPxZPF18Ybxl/rRqLQGqQodAuWnBnHC9/HT8eTx9fIG8hf//vKLY8 Rb9QaFiAZj0ioYB0IXXgOi8vdyzgMS7NI2YvG2KU0G4vG+Il8PVaYC8bEiIlKSQAPDCGcBpkJAJm hQCkUntIWcpQdoBMZIBLICxfLW95Lnl9fS/RhQBNECdwXPBjZjFco4AlwCZXMb9/Ms8uhymHoWcm wDj/Ch458jIk4C9hJSAj7yT/Jg//Jx88vz3PPt8/70D/Qg9DH/9ELygBEx9KvxNfRa9Gv0fP/0SM Gx9Mr02/Ts9P31DjI1//Uo9Tn1SvRM8rTzGvN08uf/8vjzCfXP9eDzPPNN8172MP/zgPOl86L1nv PE9sp6Ew4QDXWGlrb1eGNVgRL78Qy3Ajbs9v32cyNFxRbzrycDytMjVs8nQTKYZbEt9qKFloWwNZ b1p2N2zydD6varFbL3sPV6QwXFEvhhD+dnGfeK98X4AvfS9+P39P/4GvhX+Cf4OPhJ+G/4rPV0nU NThtAWK+0Hl0Toyfu48vc1Y3bQGhgjytM5C1An2UAAADAA00/T8DAAMADzT9PwMAAgEUNAEAAAAQ AAAATklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwRDc4MkEzMjY1MTRFMjM0RTlB RUYzNzhBQkIxREZBM0RDNDY3ODEwMAAAAAADAAYQ/MjPxAMABxACFAAAAwAQEAAAAAADABEQAAAA AB4ACBABAAAAZQAAAFBMRUFTRUlXQVNPTkxZVVNJTkdUSEFUQVNFWEFNUExFT0ZTT01FVEhJTkdT T01FT05FTUlHSFRXQU5UVE9UUllJS05PV1RIRVJFQVJFTk9HTE9CQUxTSVBEU0ZPUlRIRVBVUlAA AAAAhDQ= ------=_NextPart_000_0087_01C70281.CF7F6D60 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_0087_01C70281.CF7F6D60-- From enum-bounces@ietf.org Tue Nov 07 15:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXec-00063b-MG; Tue, 07 Nov 2006 15:34:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXeb-00062D-Be for enum@ietf.org; Tue, 07 Nov 2006 15:34:41 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhXea-0000iT-3X for enum@ietf.org; Tue, 07 Nov 2006 15:34:41 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1162931678!4616466!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23752 invoked from network); 7 Nov 2006 20:34:38 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-11.tower-146.messagelabs.com with SMTP; 7 Nov 2006 20:34:38 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA7KYboL024139; Tue, 7 Nov 2006 15:34:38 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA7KYWrv024096; Tue, 7 Nov 2006 15:34:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 15:34:30 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E0E3FC0@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BC8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:draft-ietf-enum-void-02 --> my problem Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAACBMbA= From: "Pfautz, Penn L, GBLAM" To: "Stastny Richard" , , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Enum] RE:draft-ietf-enum-void-02 --> my problem X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I'm not fundamentally against the void concept and I do recognize it addresses a problem I too would like to solve. But I think there needs to be some discussion in the draft of whether there might be some limitations in use. For example, I think American regulators would be concerned that, if carriers of record habitually populated such records in open DNS, they would be data-mined for unlisted numbers. I agree the info is available via war dialing but that's still harder than just being able to use DNS queries.=20 So, while something like void would be appropriate in some environments (no issues in a secured carrier access only root) it might raise issues in others. Penn _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 15:38:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXhr-000785-Qf; Tue, 07 Nov 2006 15:38:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXhq-000780-5y for enum@ietf.org; Tue, 07 Nov 2006 15:38:02 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXho-00018F-Ux for enum@ietf.org; Tue, 07 Nov 2006 15:38:02 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7KbgAJ006875; Tue, 7 Nov 2006 20:37:48 GMT From: "Richard Shockey" To: "'Otmar Lendl'" , "'Stastny Richard'" Subject: RE: [Enum] void-02 new version Date: Tue, 7 Nov 2006 15:37:40 -0500 Organization: NeuStar, Inc, Message-ID: <009601c702ac$92e6faf0$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20061107192210.GA1386@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCohOXavykb06JR1+JP2kprdXEEQACc1Sw X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > > Not that much. IMHO. Does the PSTN offer different error codes to > the end-user (i.e. SIT cadence vs. ???) ? YEP they are standard TCAP responses but many of them are not useful here. > > > Q2: Some people seem to have a problem with the naming of the > > ENUMservice (void). We choose the name because it was short > > I am open for proposals for something else > > (also dependant of Q1) > > Proposals that where mentioned already: > > status > > sit > > If there is a distinction required between unassigned and unallocated: > > unas > > unal > > "status" may be the better choice as it keeps the path open to > indicate other conditions which we have not considered right now. > > > Q3: There where also some discussions on the URI > > (note: we need an URI because of the syntax of the NAPTR) > > I do not see any need for a change here, but there was also a > > proposal to use a txt URI > > What about we change the service-type to a generic status and > use a URI to indicate the status? e.g. > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . EXACTLY ... or as I was thinking text is itself a URI..but this would work very well IMHO. The data field could be more useful and its what Jason and I used for CNAM etc. > > or perhaps do something similar to the ECRIT service URNs: > > "E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.unassigned!" . > or > "E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.unallocated!" . > "E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.invalid!" . > > this opens to > > "E2U+status" "u" 0 0 "!.*!urn:pstn-status:active.ported!" . Out of scope ... see RFC 3761 > > > Note: there was also a proposal to simply use a sip URI pointing > > to an (sit) announcement. This is not possible because ENUM may > > be used also by non-voice clients. It is the decision of the originating > > client how to react to the user if it encounters (void). > > agreed. > > > Q4: The problem of section 7 (enclosing zone) > > If one reads the text, the whole issue is optional and it is recommended > > to enter (void) for each potential number. > > AFAIK this is exactly the point where Peter's concerns are. > > > Nevertheless, in countries with variable length numbers (including > direct- > > dial-in) THIS DOES NOT WORK. > > Well, it's either that or DNS wildcards. Reminder that there are lots of RFC indicating wildcards in the DNS etc are harmful. > > The URI might contain some information regarding the range of > numbers which are not valid on the PSTN. Interesting how could you express this in a data: URI? > > > So we optionally came up with this approach, because we need it. > > It is e.g not required in countries with fixed number lenght such as > > the NANP. > > Maybe we should state this more clearly > > That may be a good idea in any case.= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 15:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXkb-0000Uw-7c; Tue, 07 Nov 2006 15:40:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXka-0000Ur-EG for enum@ietf.org; Tue, 07 Nov 2006 15:40:52 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhXkY-0001QB-Ns for enum@ietf.org; Tue, 07 Nov 2006 15:40:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question -AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 21:38:03 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BC9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question -AgreementonSOLUTION Void? thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFduZRAAA1QxAAAMM7Ww== References: <008501c702ab$832c7320$78218182@cis.neustar.com> From: "Stastny Richard" To: , "Livingood, Jason" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >NO. NO URN's >NAPTR Records are URI's Is this chair cap off or on ? >3761 is The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 3:10 PM > To: richard@shockey.us; Livingood, Jason; enum@ietf.org > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > >E2U+status:text where the URI is a text URI text:inactive > > What about an URN as Otmar proposed? > > Richard > > ________________________________ > > Von: Richard Shockey [mailto:richard@shockey.us] > Gesendet: Di 07.11.2006 20:37 > An: 'Livingood, Jason'; enum@ietf.org > Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > > > In line.. Chair hat off.. > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, November 06, 2006 7:37 PM > > To: enum@ietf.org > > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - > Agreement > > onSOLUTION Void? > > > > So if we have agreement / consensus on the problem statement, then = the > > next obvious step is to determine if the solution recommended by the > > void service is the right one. My question is, if not void, then = what? > > > > A SP could register their inactive TNs with SIP URIs that go to a > > special URI that plays back an announcement that the number is = inactive, > > such as sip:inactive@example.foo or sip:12159811234@example.foo = (where > > that URI is used for ALL inactive numbers). In both cases, > > communication is initiated from the caller to this URI, and the > > terminating side would then have to trigger and play an announcement > > (but it would otherwise look like a normally completed call). > > > > I think the use of void potentially gives the call originator at the > > network edge access to this information more directly, potentially > > obviating the need to even attempt a call. In general, I kind of = like > > being able to figure that sort of stuff out at the egde / point of > > origination. So I like that about the void proposal. > > Yes.. > > > > > Are there other methods that people think could solve for this = problem? > > > > I am a bit more ambivalent about the contact address (email addr or = http > > URL), but this may be useful for some clients and applications that = I > > don't yet see a use case for yet. > > I'd certainly like to understand this use case better. > > > > > Perhaps another concern is the name of the service being VOID. = Perhaps > > some take that to mean that the query was invalid in some manner? = If > > so, perhaps it could be called INACTIVE or something like that > > instead... > > The general use case to me seems to revolve around what is the status = of a > particular TN within the network at a particular point in time. > > Now that begs the question of how do you express status with the = caveat > that > the DNS is not very good at expressing highly dynamic data. > > I agree the term void may have been a contributing factor to the = confusion > in the IESG on what this draft was trying to accomplish. > > My own personal thinking of what the appropriate enumservice for this > problem should be is something along the lines of > > E2U+status:text where the URI is a text URI text:inactive > > We could define as text a limited number of status condition = potentially > including compound status with semicolon separators. > > Just a thought but it has simplicity easy to parse and is extensible = if > someone thinks of something else like text:inactive;SPID=3D6666 > > > > > Also, I'd suggest the authors consider removal of this text in = section > > 7, as I'd suggest that I am not sure SPs would actually do this and = I > > think regular SIP mechanisms can handle these scenarios: > > "This could be done for a variety of reasons. The number could have > > been delegated to an end user who has chosen to insert this record: = for > > instance it's in an ENUM or VoIP only number block and the end = user's > > SIP gateway is out of service." > > > > In general, I also find the rest of section 7 confusing and that may > > also explain some of the issues raised on the I-D. > > > > > > Jason > > > > > > > A service provider has a number block of, for example, > > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > > issued 50% of these numbers to individual subscribers and the > > > other 50% have not been. These are not neatly distributed > > > within the block, as subscribers choose their numbers so the > > > active numbers end up being randomly distributed in the block. > > > > > > If the SP registers SIP URIs for all of the active TNs then > > > those calls will work and terminate just fine. If a TN is > > > not registered then, since it is inactive, then if a person > > > dials one of the unregistered TNs then you have to wait for > > > NXDOMAIN response. In that case, most softswitches / proxies > > > will then do legacy lookups (LNP, LERG, etc.). The downside > > > is two-fold: greater post-dial delay than is necessary, and > > > having to rely on legacy call lookup tools (which may have > > > associated costs). There should be a way instead to stop the > > > call routing progression immediately if you know that the TN > > > is inactive, thus triggering back the code for a number not > > > in service network announcement to a caller. > > > > > > Is this a correct understanding of one of the issues the > > > authors are trying to identify in the problem statement? > > > > > > Jason > > > > _______________________________________________ > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 15:45:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXot-0003KF-J2; Tue, 07 Nov 2006 15:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXot-0003KA-4F for enum@ietf.org; Tue, 07 Nov 2006 15:45:19 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXor-0001uK-R2 for enum@ietf.org; Tue, 07 Nov 2006 15:45:19 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 087744CC9C; Tue, 7 Nov 2006 21:45:07 +0100 (CET) Date: Tue, 7 Nov 2006 21:45:07 +0100 From: Otmar Lendl To: Richard Shockey Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question -AgreementonSOLUTION Void? Message-ID: <20061107204507.GB1386@nic.at> References: <32755D354E6B65498C3BD9FD496C7D462C4BC7@oefeg-s04.oefeg.loc> <008501c702ab$832c7320$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008501c702ab$832c7320$78218182@cis.neustar.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: enum@ietf.org, 'Stastny Richard' , "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/07 21:11, Richard Shockey wrote: > > NO. NO URN's > > NAPTR Records are URI's > http://www.ietf.org/rfc/rfc2396.txt ---- 1.2. URI, URL, and URN A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute(s) of that resource. The term "Uniform Resource Name" (URN) refers to the subset of URI that are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable. ---- Thus any URN is also a URI. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 15:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXrH-0005qe-4p; Tue, 07 Nov 2006 15:47:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXrF-0005lM-FI for enum@ietf.org; Tue, 07 Nov 2006 15:47:45 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXrD-0002Bs-PV for enum@ietf.org; Tue, 07 Nov 2006 15:47:45 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7KlWAJ006977; Tue, 7 Nov 2006 20:47:38 GMT From: "Richard Shockey" To: "'Pfautz, Penn L, GBLAM'" , "'Stastny Richard'" , "'Livingood, Jason'" , Subject: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Tue, 7 Nov 2006 15:47:27 -0500 Organization: NeuStar, Inc, Message-ID: <009d01c702ad$f2cbaaa0$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0E0E3FC0@ACCLUST02EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAACBMbAAAGuCEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Tuesday, November 07, 2006 3:35 PM > To: Stastny Richard; richard@shockey.us; Livingood, Jason; enum@ietf.org > Subject: [Enum] RE:draft-ietf-enum-void-02 --> my problem > > I'm not fundamentally against the void concept and I do recognize it > addresses a problem I too would like to solve. But I think there needs > to be some discussion in the draft of whether there might be some > limitations in use. For example, I think American regulators would be > concerned that, if carriers of record habitually populated such records > in open DNS, they would be data-mined for unlisted numbers. I agree the > info is available via war dialing but that's still harder than just > being able to use DNS queries. > So, while something like void would be appropriate in some environments > (no issues in a secured carrier access only root) it might raise issues > in others. Penn this is an excellent point. I completely agree this is a requirement for a rewritten draft. This would certainly help the IESG understand where the requirement would come from. It has been my experience that the operators who want to use such a void our status URI are essentially building private ENUM infrastructure systems where the data exposed between consenting service providers is exchanged through a trusted registry operation or other our of band mechanism and fully cached in their local ENUM DNS server infrastructure aka the IP-SCP. This permits the originating carrier the opportunity to avoid unnecessary INVITES to the terminating peering partner etc. > > Penn > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 15:48:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXry-0006Mw-VS; Tue, 07 Nov 2006 15:48:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXrx-0006Hc-2G for enum@ietf.org; Tue, 07 Nov 2006 15:48:29 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXrs-0002Fn-21 for enum@ietf.org; Tue, 07 Nov 2006 15:48:29 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7KmDAJ006983; Tue, 7 Nov 2006 20:48:19 GMT From: "Richard Shockey" To: "'Stastny Richard'" , , "'Livingood, Jason'" , Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question-AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 15:48:12 -0500 Organization: NeuStar, Inc, Message-ID: <009e01c702ae$0b637160$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BC9@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFduZRAAA1QxAAAMM7WwAAVcxQ X-Spam-Score: 1.1 (+) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org ON ..see RFC 3761 that says URI not URN's. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 3:38 PM > To: rich.shockey@NeuStar.biz; Livingood, Jason; enum@ietf.org > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question- > AgreementonSOLUTION Void? > > >NO. NO URN's > > >NAPTR Records are URI's > > Is this chair cap off or on ? > > >3761 is The E.164 to Uniform Resource Identifiers (URI) > Dynamic Delegation Discovery System (DDDS) Application (ENUM) > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, November 07, 2006 3:10 PM > > To: richard@shockey.us; Livingood, Jason; enum@ietf.org > > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > > AgreementonSOLUTION Void? > > > > >E2U+status:text where the URI is a text URI text:inactive > > > > What about an URN as Otmar proposed? > > > > Richard > > > > ________________________________ > > > > Von: Richard Shockey [mailto:richard@shockey.us] > > Gesendet: Di 07.11.2006 20:37 > > An: 'Livingood, Jason'; enum@ietf.org > > Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - > > AgreementonSOLUTION Void? > > > > > > > > In line.. Chair hat off.. > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, November 06, 2006 7:37 PM > > > To: enum@ietf.org > > > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - > > Agreement > > > onSOLUTION Void? > > > > > > So if we have agreement / consensus on the problem statement, then the > > > next obvious step is to determine if the solution recommended by the > > > void service is the right one. My question is, if not void, then > what? > > > > > > A SP could register their inactive TNs with SIP URIs that go to a > > > special URI that plays back an announcement that the number is > inactive, > > > such as sip:inactive@example.foo or sip:12159811234@example.foo (where > > > that URI is used for ALL inactive numbers). In both cases, > > > communication is initiated from the caller to this URI, and the > > > terminating side would then have to trigger and play an announcement > > > (but it would otherwise look like a normally completed call). > > > > > > I think the use of void potentially gives the call originator at the > > > network edge access to this information more directly, potentially > > > obviating the need to even attempt a call. In general, I kind of like > > > being able to figure that sort of stuff out at the egde / point of > > > origination. So I like that about the void proposal. > > > > Yes.. > > > > > > > > Are there other methods that people think could solve for this > problem? > > > > > > I am a bit more ambivalent about the contact address (email addr or > http > > > URL), but this may be useful for some clients and applications that I > > > don't yet see a use case for yet. > > > > I'd certainly like to understand this use case better. > > > > > > > > Perhaps another concern is the name of the service being VOID. > Perhaps > > > some take that to mean that the query was invalid in some manner? If > > > so, perhaps it could be called INACTIVE or something like that > > > instead... > > > > The general use case to me seems to revolve around what is the status of > a > > particular TN within the network at a particular point in time. > > > > Now that begs the question of how do you express status with the caveat > > that > > the DNS is not very good at expressing highly dynamic data. > > > > I agree the term void may have been a contributing factor to the > confusion > > in the IESG on what this draft was trying to accomplish. > > > > My own personal thinking of what the appropriate enumservice for this > > problem should be is something along the lines of > > > > E2U+status:text where the URI is a text URI text:inactive > > > > We could define as text a limited number of status condition potentially > > including compound status with semicolon separators. > > > > Just a thought but it has simplicity easy to parse and is extensible if > > someone thinks of something else like text:inactive;SPID=6666 > > > > > > > > Also, I'd suggest the authors consider removal of this text in section > > > 7, as I'd suggest that I am not sure SPs would actually do this and I > > > think regular SIP mechanisms can handle these scenarios: > > > "This could be done for a variety of reasons. The number could have > > > been delegated to an end user who has chosen to insert this record: > for > > > instance it's in an ENUM or VoIP only number block and the end user's > > > SIP gateway is out of service." > > > > > > In general, I also find the rest of section 7 confusing and that may > > > also explain some of the issues raised on the I-D. > > > > > > > > > Jason > > > > > > > > > > A service provider has a number block of, for example, > > > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > > > issued 50% of these numbers to individual subscribers and the > > > > other 50% have not been. These are not neatly distributed > > > > within the block, as subscribers choose their numbers so the > > > > active numbers end up being randomly distributed in the block. > > > > > > > > If the SP registers SIP URIs for all of the active TNs then > > > > those calls will work and terminate just fine. If a TN is > > > > not registered then, since it is inactive, then if a person > > > > dials one of the unregistered TNs then you have to wait for > > > > NXDOMAIN response. In that case, most softswitches / proxies > > > > will then do legacy lookups (LNP, LERG, etc.). The downside > > > > is two-fold: greater post-dial delay than is necessary, and > > > > having to rely on legacy call lookup tools (which may have > > > > associated costs). There should be a way instead to stop the > > > > call routing progression immediately if you know that the TN > > > > is inactive, thus triggering back the code for a number not > > > > in service network announcement to a caller. > > > > > > > > Is this a correct understanding of one of the issues the > > > > authors are trying to identify in the problem statement? > > > > > > > > Jason > > > > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 16:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY30-000164-Vd; Tue, 07 Nov 2006 15:59:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY2z-00015t-V3 for enum@ietf.org; Tue, 07 Nov 2006 15:59:53 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhY2X-0003uC-Vm for enum@ietf.org; Tue, 07 Nov 2006 15:59:53 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id F324E4CC9C; Tue, 7 Nov 2006 21:59:24 +0100 (CET) Date: Tue, 7 Nov 2006 21:59:24 +0100 From: Otmar Lendl To: Richard Shockey Subject: Re: [Enum] void-02 new version Message-ID: <20061107205924.GS20763@nic.at> References: <20061107192210.GA1386@nic.at> <009601c702ac$92e6faf0$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009601c702ac$92e6faf0$78218182@cis.neustar.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: enum@ietf.org, 'Stastny Richard' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/07 21:11, Richard Shockey wrote: > > > > What about we change the service-type to a generic status and > > use a URI to indicate the status? e.g. > > > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . > > EXACTLY ... or as I was thinking text is itself a URI..but this would work > very well IMHO. Agreed. I really think we should keep the ENUM-service type simple and generic stating "the URI in the regex will define the status of the number". > The data field could be more useful and its what Jason and I used for CNAM > etc. The question of what URI scheme to use (and yes, urn: is just yet another URI-scheme) is open to discussion. I think there are a few possible solutions. data:, text: or urn:. If we want to find out what is best choice, we should first fomulate a quick requirements list. What information should be encodable in that URI? Quick list: * status as a set of pre-defined values. Perhaps hierarchically structured. * Carrier identification? * Number block information (e.g. "this status applies to all of +43780") * Porting indicator? > > > > > Nevertheless, in countries with variable length numbers (including > > direct- > > > dial-in) THIS DOES NOT WORK. > > > > Well, it's either that or DNS wildcards. > > Reminder that there are lots of RFC indicating wildcards in the DNS etc are > harmful. I'm very much open to suggestion on how to solve the problem without resorting to wildcards. > > > > > The URI might contain some information regarding the range of > > numbers which are not valid on the PSTN. > > > Interesting how could you express this in a data: URI? > ...;apliesto=+43780 /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY51-0001Wm-7j; Tue, 07 Nov 2006 16:01:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY50-0001Wc-1t for enum@ietf.org; Tue, 07 Nov 2006 16:01:58 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhY4l-0004Il-91 for enum@ietf.org; Tue, 07 Nov 2006 16:01:58 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7L1TAJ007173; Tue, 7 Nov 2006 21:01:34 GMT From: "Richard Shockey" To: "'Otmar Lendl'" Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question -AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 16:01:27 -0500 Organization: NeuStar, Inc, Message-ID: <010501c702af$e58bb860$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20061107204507.GB1386@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCrax/tybGU9B9RbquGj9Zo4YaXAAAQPZA X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: enum@ietf.org, 'Stastny Richard' , "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Ok but I not convinced this is the application to start down the road changing what is expected from the rewrite. No other registered Enumservices uses URN's and frankly this application does not IMHO justify starting down that road any more than I really want to see documents about non-terminal NAPTR records until some one comes up with a specific use case and enumservice registration that justifies it. I think we had consensus that this rewrite needs to be simple fast and quick. If you want to complicate the rewrite of void-03 with an issue like incorporating URN's this then we're probably headed back to square one. > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, November 07, 2006 3:45 PM > To: Richard Shockey > Cc: 'Stastny Richard'; 'Livingood, Jason'; enum@ietf.org > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > On 2006/11/07 21:11, Richard Shockey wrote: > > > > NO. NO URN's > > > > NAPTR Records are URI's > > > > http://www.ietf.org/rfc/rfc2396.txt > > ---- > 1.2. URI, URL, and URN > > A URI can be further classified as a locator, a name, or both. The > term "Uniform Resource Locator" (URL) refers to the subset of URI > that identify resources via a representation of their primary access > mechanism (e.g., their network "location"), rather than identifying > the resource by name or by some other attribute(s) of that resource. > The term "Uniform Resource Name" (URN) refers to the subset of URI > that are required to remain globally unique and persistent even when > the resource ceases to exist or becomes unavailable. > ---- > > Thus any URN is also a URI. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY5H-0001f2-Le; Tue, 07 Nov 2006 16:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY5G-0001cY-8N for enum@ietf.org; Tue, 07 Nov 2006 16:02:14 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhY58-0004MH-Ji for enum@ietf.org; Tue, 07 Nov 2006 16:02:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 21:59:07 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BCA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAAA1GQAAAVmdIw== References: <008601c702ab$b8557560$78218182@cis.neustar.com> From: "Stastny Richard" To: , "Livingood, Jason" , X-Spam-Score: 1.1 (+) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org So why do you need SPID. This is also line ownership =20 and what about unallocated blocks? you need a SPID for the FCC too =20 And I do not know if line status is what you want line active or inactive may change quite rapidly =20 Richard ________________________________ Von: Richard Shockey [mailto:Rich.Shockey@NeuStar.biz] Gesendet: Di 07.11.2006 21:31 An: Stastny Richard; 'Livingood, Jason'; enum@ietf.org Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? Please ..I was only using that as example of something some one MIGHT = want to try.=20 =20 I know there are no global SIPD's. =20 For the purposes of this draft I think limiting the response to=20 =20 unallocated (not existent) unassigned (not existent) inactive (inactive -=3D out-of-service- barred - etc) =20 is sufficient. I just want the URI syntax for status conditions to = _eventually_ be extensible. Which is why something like E2U+status:[uri] = makes sense but I'm not totally sold on this. =20 The more I think about it what you are proposing with the http and email = address is something entirely different than what is actually needed. = What you are discussing is essentially TN ownership which is not line = (number) status. That I increasingly think that this point to carrier of = record via http or smtp should be its own URI scheme. =20 We know what the problem is lets keep the solution very very simple, = even if that means starting over from scratch. =20 ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, November 07, 2006 3:15 PM To: richard@shockey.us; Livingood, Jason; enum@ietf.org Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? =20 >Just a thought but it has simplicity easy to parse and is extensible if >someone thinks of something else like text:inactive;SPID=3D6666 Could you please start thinking global There is currently no global SPIDs =20 So who is defining them? =20 If the SPID is needed at all, the pointer to a webpage or an email = address works as well =20 Richard =20 =20 ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Di 07.11.2006 20:37 An: 'Livingood, Jason'; enum@ietf.org Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? In line.. Chair hat off.. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 06, 2006 7:37 PM > To: enum@ietf.org > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - = Agreement > onSOLUTION Void? > > So if we have agreement / consensus on the problem statement, then the > next obvious step is to determine if the solution recommended by the > void service is the right one. My question is, if not void, then = what? > > A SP could register their inactive TNs with SIP URIs that go to a > special URI that plays back an announcement that the number is = inactive, > such as sip:inactive@example.foo or sip:12159811234@example.foo (where > that URI is used for ALL inactive numbers). In both cases, > communication is initiated from the caller to this URI, and the > terminating side would then have to trigger and play an announcement > (but it would otherwise look like a normally completed call). > > I think the use of void potentially gives the call originator at the > network edge access to this information more directly, potentially > obviating the need to even attempt a call. In general, I kind of like > being able to figure that sort of stuff out at the egde / point of > origination. So I like that about the void proposal. Yes.. > > Are there other methods that people think could solve for this = problem? > > I am a bit more ambivalent about the contact address (email addr or = http > URL), but this may be useful for some clients and applications that I > don't yet see a use case for yet. I'd certainly like to understand this use case better. > > Perhaps another concern is the name of the service being VOID. = Perhaps > some take that to mean that the query was invalid in some manner? If > so, perhaps it could be called INACTIVE or something like that > instead... The general use case to me seems to revolve around what is the status of = a particular TN within the network at a particular point in time. Now that begs the question of how do you express status with the caveat = that the DNS is not very good at expressing highly dynamic data. I agree the term void may have been a contributing factor to the = confusion in the IESG on what this draft was trying to accomplish. My own personal thinking of what the appropriate enumservice for this problem should be is something along the lines of E2U+status:text where the URI is a text URI text:inactive We could define as text a limited number of status condition potentially including compound status with semicolon separators. Just a thought but it has simplicity easy to parse and is extensible if someone thinks of something else like text:inactive;SPID=3D6666 > > Also, I'd suggest the authors consider removal of this text in section > 7, as I'd suggest that I am not sure SPs would actually do this and I > think regular SIP mechanisms can handle these scenarios: > "This could be done for a variety of reasons. The number could have > been delegated to an end user who has chosen to insert this record: = for > instance it's in an ENUM or VoIP only number block and the end user's > SIP gateway is out of service." > > In general, I also find the rest of section 7 confusing and that may > also explain some of the issues raised on the I-D. > > > Jason > > > > A service provider has a number block of, for example, > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > issued 50% of these numbers to individual subscribers and the > > other 50% have not been. These are not neatly distributed > > within the block, as subscribers choose their numbers so the > > active numbers end up being randomly distributed in the block. > > > > If the SP registers SIP URIs for all of the active TNs then > > those calls will work and terminate just fine. If a TN is > > not registered then, since it is inactive, then if a person > > dials one of the unregistered TNs then you have to wait for > > NXDOMAIN response. In that case, most softswitches / proxies > > will then do legacy lookups (LNP, LERG, etc.). The downside > > is two-fold: greater post-dial delay than is necessary, and > > having to rely on legacy call lookup tools (which may have > > associated costs). There should be a way instead to stop the > > call routing progression immediately if you know that the TN > > is inactive, thus triggering back the code for a number not > > in service network announcement to a caller. > > > > Is this a correct understanding of one of the issues the > > authors are trying to identify in the problem statement? > > > > Jason > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 16:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY7V-0003Jl-CZ; Tue, 07 Nov 2006 16:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY7U-0003Ja-AU for enum@ietf.org; Tue, 07 Nov 2006 16:04:32 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhY7S-0004iV-VF for enum@ietf.org; Tue, 07 Nov 2006 16:04:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 22:03:01 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BCC@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-enum-void-02 --> my problem thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAACBMbAAATB4Vg== References: <34DA635B184A644DA4588E260EC0A25A0E0E3FC0@ACCLUST02EVS1.ugd.att.com> From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Enum] Re: draft-ietf-enum-void-02 --> my problem X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org You should not forget=20 1. void is optional 2.it may be very useful also in private ENUMs =20 Richard ________________________________ Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Gesendet: Di 07.11.2006 21:34 An: Stastny Richard; richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: RE:draft-ietf-enum-void-02 --> my problem I'm not fundamentally against the void concept and I do recognize it addresses a problem I too would like to solve. But I think there needs to be some discussion in the draft of whether there might be some limitations in use. For example, I think American regulators would be concerned that, if carriers of record habitually populated such records in open DNS, they would be data-mined for unlisted numbers. I agree the info is available via war dialing but that's still harder than just being able to use DNS queries. So, while something like void would be appropriate in some environments (no issues in a secured carrier access only root) it might raise issues in others. Penn _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY9P-0003mo-3j; Tue, 07 Nov 2006 16:06:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY9N-0003mI-4p for enum@ietf.org; Tue, 07 Nov 2006 16:06:29 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhY9L-0004wF-ST for enum@ietf.org; Tue, 07 Nov 2006 16:06:29 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2006 13:06:27 -0800 X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208"; a="48162072:sNHT709395598" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7L6RIt029263; Tue, 7 Nov 2006 16:06:27 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7L6QYJ008301; Tue, 7 Nov 2006 16:06:26 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 16:06:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Tue, 7 Nov 2006 16:06:22 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DA9FB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAACBMbAAAUIVgA== From: "Michael Hammer \(mhammer\)" To: "Pfautz, Penn L, GBLAM" , "Stastny Richard" , , "Livingood, Jason" , X-OriginalArrivalTime: 07 Nov 2006 21:06:26.0251 (UTC) FILETIME=[964D81B0:01C702B0] DKIM-Signature: a=rsa-sha1; q=dns; l=1331; t=1162933587; x=1163797587; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Enum]=20RE=3Adraft-ietf-enum-void-02=20-->=20my=20problem |To:=22Pfautz, =20Penn=20L, =20GBLAM=22=20, =0A=20=20=20=20=20 =20=20=20=22Stastny=20Richard=22=20, =20, =0A=20=20=20=20=20=20=20=20=22Livingood, =20Jason=22=20,=0A=20=20=20=20=20=20=20=20; X=v=3Dcisco.com=3B=20h=3DAgqHekijQcbCr6KBZcaApCGw4Jw=3D; b=t0aZnNVsGUMvNf7IcWlkHiB0HBPG7KnFXCf2CLK+aGV0EpvvGEzArZyL1SqZppAhrxCQFoGu YtEelShipD1EsesNfVDjA1UVrlGMZZS3BTzGxG0j1otnnd/9A+CadmyE; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Huh??? The only difference is in the method used to discern the end result. It would be harder on the network than the user. Mike=20 > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 > Sent: Tuesday, November 07, 2006 3:35 PM > To: Stastny Richard; richard@shockey.us; Livingood, Jason;=20 > enum@ietf.org > Subject: [Enum] RE:draft-ietf-enum-void-02 --> my problem >=20 > I'm not fundamentally against the void concept and I do=20 > recognize it addresses a problem I too would like to solve.=20 > But I think there needs to be some discussion in the draft of=20 > whether there might be some limitations in use. For example,=20 > I think American regulators would be concerned that, if=20 > carriers of record habitually populated such records in open=20 > DNS, they would be data-mined for unlisted numbers. I agree=20 > the info is available via war dialing but that's still harder=20 > than just being able to use DNS queries.=20 > So, while something like void would be appropriate in some=20 > environments (no issues in a secured carrier access only=20 > root) it might raise issues in others. >=20 > Penn >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYF1-0005Fo-1B; Tue, 07 Nov 2006 16:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYEz-0005Fd-Qk for enum@ietf.org; Tue, 07 Nov 2006 16:12:17 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYEy-0005gD-JQ for enum@ietf.org; Tue, 07 Nov 2006 16:12:17 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7LC4AJ007263; Tue, 7 Nov 2006 21:12:09 GMT From: "Richard Shockey" To: "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Enum] void-02 new version Date: Tue, 7 Nov 2006 16:12:03 -0500 Organization: NeuStar, Inc, Message-ID: <012501c702b1$60298830$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20061107205924.GS20763@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQ X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: enum@ietf.org, 'Stastny Richard' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > > On 2006/11/07 21:11, Richard Shockey wrote: > > > > > > What about we change the service-type to a generic status and > > > use a URI to indicate the status? e.g. > > > > > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . > > > > EXACTLY ... or as I was thinking text is itself a URI..but this would > work > > very well IMHO. > > Agreed. I really think we should keep the ENUM-service type simple > and generic stating "the URI in the regex will define the status of the > number". > > > The data field could be more useful and its what Jason and I used for > CNAM > > etc. > > The question of what URI scheme to use (and yes, urn: is just yet > another URI-scheme) is open to discussion. I think there are a > few possible solutions. data:, text: or urn:. IMHO data or text. I don't want to go down the URN rat hole for reasons earlier noted. If we want to > find out what is best choice, we should first fomulate a quick > requirements list. What information should be encodable in that URI? > > Quick list: > > * status as a set of pre-defined values. Perhaps hierarchically > structured. > * Carrier identification? > * Number block information (e.g. "this status applies to all of +43780") > * Porting indicator? PLEASE PLEASE... I think we had consensus here. The initial use case for this ID surrounds 3 conditions as Richard noted. unallocated (not existent) unassigned (not existent) inactive (inactive -= out-of-service- barred - etc) Can we stick with this and finish up? Please!! This is an issue that people want to use NOW. If the URI scheme is extensible enough people can write separate drafts on those other items. Add the rest of that stuff into the draft and we might have to totally respin the document. As it was 'void' was in the IESG queue I'd like to justify a note to the AD's that this revision is in the context of the original, answers their concerns, and as such does not necessarily need additional WG LAST Call. OK? > > > > > > > > Nevertheless, in countries with variable length numbers (including > > > direct- > > > > dial-in) THIS DOES NOT WORK. > > > > > > Well, it's either that or DNS wildcards. > > > > Reminder that there are lots of RFC indicating wildcards in the DNS etc > are > > harmful. > > I'm very much open to suggestion on how to solve the problem without > resorting to wildcards. > > > > > > > > > > The URI might contain some information regarding the range of > > > numbers which are not valid on the PSTN. > > > > > > Interesting how could you express this in a data: URI? > > > > ...;apliesto=+43780 > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYFS-0005M1-TB; Tue, 07 Nov 2006 16:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYFR-0005Lr-G8 for enum@ietf.org; Tue, 07 Nov 2006 16:12:45 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhYFQ-0005jX-5d for enum@ietf.org; Tue, 07 Nov 2006 16:12:45 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1162933962!13864556!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23380 invoked from network); 7 Nov 2006 21:12:42 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 7 Nov 2006 21:12:42 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA7LCgSt015531; Tue, 7 Nov 2006 16:12:42 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA7LCTOh015410; Tue, 7 Nov 2006 16:12:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 16:12:27 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E0E4079@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BCC@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-enum-void-02 --> my problem Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAACBMbAAATB4VgAANXBQ From: "Pfautz, Penn L, GBLAM" To: "Stastny Richard" , , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Enum] RE: draft-ietf-enum-void-02 --> my problem X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard: I agree with both points but would feel better if the draft addressed the issue and pointed to potentially limits on The environments in which it might be used as was done, for example in the cnam drafts. Penn=20 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, November 07, 2006 4:03 PM To: Pfautz, Penn L, GBLAM; richard@shockey.us; Livingood, Jason; enum@ietf.org Subject: Re: draft-ietf-enum-void-02 --> my problem You should not forget=20 1. void is optional 2.it may be very useful also in private ENUMs =20 Richard ________________________________ Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Gesendet: Di 07.11.2006 21:34 An: Stastny Richard; richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: RE:draft-ietf-enum-void-02 --> my problem I'm not fundamentally against the void concept and I do recognize it addresses a problem I too would like to solve. But I think there needs to be some discussion in the draft of whether there might be some limitations in use. For example, I think American regulators would be concerned that, if carriers of record habitually populated such records in open DNS, they would be data-mined for unlisted numbers. I agree the info is available via war dialing but that's still harder than just being able to use DNS queries. So, while something like void would be appropriate in some environments (no issues in a secured carrier access only root) it might raise issues in others. Penn _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:15:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYI0-0000xV-25; Tue, 07 Nov 2006 16:15:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYHy-0000m4-C2 for enum@ietf.org; Tue, 07 Nov 2006 16:15:22 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhYHw-00069K-0z for enum@ietf.org; Tue, 07 Nov 2006 16:15:22 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1162934119!9052384!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1044 invoked from network); 7 Nov 2006 21:15:19 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-6.tower-121.messagelabs.com with SMTP; 7 Nov 2006 21:15:19 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA7LFImW017144; Tue, 7 Nov 2006 16:15:18 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA7LFFNI017098; Tue, 7 Nov 2006 16:15:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Tue, 7 Nov 2006 16:15:11 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E0E4085@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3022DA9FB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thread-Index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAACBMbAAAUIVgAAARa3w From: "Pfautz, Penn L, GBLAM" To: "Michael Hammer \(mhammer\)" , "Stastny Richard" , , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org But ease (and cost) may make the difference between whether a approach to mining is viable or not. If it's not harder to send an INVITE than to do a DNS query one of the motivations for this draft would be gone. And just so, war dialing is more work than a DNS query. Penn -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, November 07, 2006 4:06 PM To: Pfautz, Penn L, GBLAM; Stastny Richard; richard@shockey.us; Livingood, Jason; enum@ietf.org Subject: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem Huh??? The only difference is in the method used to discern the end result. It would be harder on the network than the user. Mike=20 > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 > Sent: Tuesday, November 07, 2006 3:35 PM > To: Stastny Richard; richard@shockey.us; Livingood, Jason;=20 > enum@ietf.org > Subject: [Enum] RE:draft-ietf-enum-void-02 --> my problem >=20 > I'm not fundamentally against the void concept and I do=20 > recognize it addresses a problem I too would like to solve.=20 > But I think there needs to be some discussion in the draft of=20 > whether there might be some limitations in use. For example,=20 > I think American regulators would be concerned that, if=20 > carriers of record habitually populated such records in open=20 > DNS, they would be data-mined for unlisted numbers. I agree=20 > the info is available via war dialing but that's still harder=20 > than just being able to use DNS queries.=20 > So, while something like void would be appropriate in some=20 > environments (no issues in a secured carrier access only=20 > root) it might raise issues in others. >=20 > Penn >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYQI-0008BL-Tx; Tue, 07 Nov 2006 16:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYQI-0008BG-8B for enum@ietf.org; Tue, 07 Nov 2006 16:23:58 -0500 Received: from dakota.ucd.ie ([193.1.169.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYQG-0007Rz-WD for enum@ietf.org; Tue, 07 Nov 2006 16:23:58 -0500 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) id <0J8D00G01Q0KI600@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for enum@ietf.org; Tue, 07 Nov 2006 21:23:46 +0000 (GMT) Received: from [10.0.1.189] ([83.141.81.52]) by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPSA id <0J8D00MYXQ3LCWB0@dakota.ucd.ie>; Tue, 07 Nov 2006 21:23:45 +0000 (GMT) Date: Tue, 07 Nov 2006 21:23:53 +0000 From: Niall O'Reilly Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem In-reply-to: <34DA635B184A644DA4588E260EC0A25A0E0E4085@ACCLUST02EVS1.ugd.att.com> To: "Pfautz, Penn L, GBLAM" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Gpgmail-State: !signed References: <34DA635B184A644DA4588E260EC0A25A0E0E4085@ACCLUST02EVS1.ugd.att.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: enum@ietf.org, "Michael Hammer \(mhammer\)" , Niall O'Reilly , richard@shockey.us, Stastny Richard , "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 7 Nov 2006, at 21:15, Pfautz, Penn L, GBLAM wrote: > If it's not harder to send an INVITE than to > do a DNS query one of the motivations for this draft would be gone. There would still be the residual motivation of preventing looping due to hot-potato call-routing configuration, which is mentioned at the end of Section 3 of the draft. Or this isn't significant? /Niall _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYRz-0000VP-Oq; Tue, 07 Nov 2006 16:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYRy-0000RW-Ov for enum@ietf.org; Tue, 07 Nov 2006 16:25:42 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhYRx-0007jR-89 for enum@ietf.org; Tue, 07 Nov 2006 16:25:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Tue, 7 Nov 2006 22:24:53 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BCD@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQ= References: <012501c702b1$60298830$78218182@cis.neustar.com> From: "Stastny Richard" To: , "Otmar Lendl" , "Richard Shockey" X-Spam-Score: 0.5 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >unallocated (not existent) >unassigned (not existent) >inactive (inactive -=3D out-of-service- barred - etc) I think we have at least consensus here I see some decisions still to make: E2U+status:unass with mailto and http pointing to owner E2U+status:unall E2U+status:inact E2U+status with text:unassigned or text::unallocated or text:inactive or E2U+unass:http E2U+unass:mailto etc all schemes are extensible >Can we stick with this and finish up? Please!! This is an issue that = people >want to use NOW. If the URI scheme is extensible enough people can = write >separate drafts on those other items. >Add the rest of that stuff into the draft and we might have to totally >respin the document. As it was 'void' was in the IESG queue I'd like to >justify a note to the AD's that this revision is in the context of the >original, answers their concerns, and as such does not necessarily need >additional WG LAST Call. for a complete rewrite count me out Richard ________________________________ Von: Richard Shockey [mailto:Rich.Shockey@NeuStar.biz] Gesendet: Di 07.11.2006 22:12 An: 'Otmar Lendl'; 'Richard Shockey' Cc: Stastny Richard; enum@ietf.org Betreff: RE: [Enum] void-02 new version > > On 2006/11/07 21:11, Richard Shockey wrote: > > > > > > What about we change the service-type to a generic status and > > > use a URI to indicate the status? e.g. > > > > > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . > > > > EXACTLY ... or as I was thinking text is itself a URI..but this = would > work > > very well IMHO. > > Agreed. I really think we should keep the ENUM-service type simple > and generic stating "the URI in the regex will define the status of = the > number". > > > The data field could be more useful and its what Jason and I used = for > CNAM > > etc. > > The question of what URI scheme to use (and yes, urn: is just yet > another URI-scheme) is open to discussion. I think there are a > few possible solutions. data:, text: or urn:. IMHO data or text. I don't want to go down the URN rat hole for reasons earlier noted. If we want to > find out what is best choice, we should first fomulate a quick > requirements list. What information should be encodable in that URI? > > Quick list: > > * status as a set of pre-defined values. Perhaps hierarchically > structured. > * Carrier identification? > * Number block information (e.g. "this status applies to all of = +43780") > * Porting indicator? PLEASE PLEASE... I think we had consensus here. The initial use case for this ID surrounds 3 conditions as Richard noted. unallocated (not existent) unassigned (not existent) inactive (inactive -=3D out-of-service- barred - etc) Can we stick with this and finish up? Please!! This is an issue that = people want to use NOW. If the URI scheme is extensible enough people can write separate drafts on those other items. Add the rest of that stuff into the draft and we might have to totally respin the document. As it was 'void' was in the IESG queue I'd like to justify a note to the AD's that this revision is in the context of the original, answers their concerns, and as such does not necessarily need additional WG LAST Call. OK? > > > > > > > > Nevertheless, in countries with variable length numbers = (including > > > direct- > > > > dial-in) THIS DOES NOT WORK. > > > > > > Well, it's either that or DNS wildcards. > > > > Reminder that there are lots of RFC indicating wildcards in the DNS = etc > are > > harmful. > > I'm very much open to suggestion on how to solve the problem without > resorting to wildcards. > > > > > > > > > > The URI might contain some information regarding the range of > > > numbers which are not valid on the PSTN. > > > > > > Interesting how could you express this in a data: URI? > > > > ...;apliesto=3D+43780 > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYSw-0003y3-9P; Tue, 07 Nov 2006 16:26:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYSv-0003uh-D6 for enum@ietf.org; Tue, 07 Nov 2006 16:26:41 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhYSu-0007s6-08 for enum@ietf.org; Tue, 07 Nov 2006 16:26:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 22:25:23 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BCE@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-enum-void-02 --> my problem thread-index: AccB9pAALpOsPMJ9TNa+snnG7+iNIwACcfIgAACQW7AAJBIVsAAFnRVLAACBMbAAATB4VgAANXBQAACSb9Y= References: <34DA635B184A644DA4588E260EC0A25A0E0E4079@ACCLUST02EVS1.ugd.att.com> From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Enum] Re: draft-ietf-enum-void-02 --> my problem X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org ok, we add something in the security section =20 Richard ________________________________ Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Gesendet: Di 07.11.2006 22:12 An: Stastny Richard; richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: RE: draft-ietf-enum-void-02 --> my problem Richard: I agree with both points but would feel better if the draft addressed the issue and pointed to potentially limits on The environments in which it might be used as was done, for example in the cnam drafts. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, November 07, 2006 4:03 PM To: Pfautz, Penn L, GBLAM; richard@shockey.us; Livingood, Jason; enum@ietf.org Subject: Re: draft-ietf-enum-void-02 --> my problem You should not forget 1. void is optional 2.it may be very useful also in private ENUMs Richard ________________________________ Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Gesendet: Di 07.11.2006 21:34 An: Stastny Richard; richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: RE:draft-ietf-enum-void-02 --> my problem I'm not fundamentally against the void concept and I do recognize it addresses a problem I too would like to solve. But I think there needs to be some discussion in the draft of whether there might be some limitations in use. For example, I think American regulators would be concerned that, if carriers of record habitually populated such records in open DNS, they would be data-mined for unlisted numbers. I agree the info is available via war dialing but that's still harder than just being able to use DNS queries. So, while something like void would be appropriate in some environments (no issues in a secured carrier access only root) it might raise issues in others. Penn _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYWD-0005Q8-TO; Tue, 07 Nov 2006 16:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYWC-0005Q3-Ui for enum@ietf.org; Tue, 07 Nov 2006 16:30:04 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhYWB-0008L3-J8 for enum@ietf.org; Tue, 07 Nov 2006 16:30:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Tue, 7 Nov 2006 22:27:13 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BCF@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem thread-index: AccCsul/6rrnmPEkSVCBLGAgA0VkbgAAJQkT References: <34DA635B184A644DA4588E260EC0A25A0E0E4085@ACCLUST02EVS1.ugd.att.com> From: "Stastny Richard" To: "Niall O'Reilly" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thank you for coming back to this =20 Void is optional exept for ENUM only numbers, where it is required =20 Richard ________________________________ Von: Niall O'Reilly [mailto:Niall.oReilly@ucd.ie] Gesendet: Di 07.11.2006 22:23 An: Pfautz, Penn L, GBLAM Cc: Niall O'Reilly; Michael Hammer (mhammer); Stastny Richard; = richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem On 7 Nov 2006, at 21:15, Pfautz, Penn L, GBLAM wrote: > If it's not harder to send an INVITE than to > do a DNS query one of the motivations for this draft would be gone. There would still be the residual motivation of preventing looping due to hot-potato call-routing configuration, which is mentioned at the end of Section 3 of the draft. Or this isn't significant? /Niall _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYda-00075I-EB; Tue, 07 Nov 2006 16:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYdZ-00074f-8K for enum@ietf.org; Tue, 07 Nov 2006 16:37:41 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYdW-0000sK-VN for enum@ietf.org; Tue, 07 Nov 2006 16:37:41 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7LbPAJ007444; Tue, 7 Nov 2006 21:37:32 GMT From: "Richard Shockey" To: "'Stastny Richard'" , , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Enum] void-02 new version Date: Tue, 7 Nov 2006 16:37:22 -0500 Organization: NeuStar, Inc, Message-ID: <001d01c702b4$eae2a800$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQAAK51IA== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BCD@oefeg-s04.oefeg.loc> X-Spam-Score: 0.5 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org OK its just me but I'm not going to the IESG with a "UNASS" parameter in an ID. :-) Cant you just spell it out.. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 4:25 PM > To: rich.shockey@NeuStar.biz; Otmar Lendl; Richard Shockey > Cc: enum@ietf.org > Subject: Re: [Enum] void-02 new version > > >unallocated (not existent) > > >unassigned (not existent) > > >inactive (inactive -= out-of-service- barred - etc) > > I think we have at least consensus here > > I see some decisions still to make: > > E2U+status:unass with mailto and http pointing to owner > E2U+status:unall > E2U+status:inact > > E2U+status with text:unassigned or text::unallocated or text:inactive > > or > > E2U+unass:http > E2U+unass:mailto > etc > > all schemes are extensible > > >Can we stick with this and finish up? Please!! This is an issue that > people > >want to use NOW. If the URI scheme is extensible enough people can write > >separate drafts on those other items. > > >Add the rest of that stuff into the draft and we might have to totally > >respin the document. As it was 'void' was in the IESG queue I'd like to > >justify a note to the AD's that this revision is in the context of the > >original, answers their concerns, and as such does not necessarily need > >additional WG LAST Call. > > for a complete rewrite count me out > > Richard > > > > ________________________________ > > Von: Richard Shockey [mailto:Rich.Shockey@NeuStar.biz] > Gesendet: Di 07.11.2006 22:12 > An: 'Otmar Lendl'; 'Richard Shockey' > Cc: Stastny Richard; enum@ietf.org > Betreff: RE: [Enum] void-02 new version > > > > > > > > On 2006/11/07 21:11, Richard Shockey wrote: > > > > > > > > What about we change the service-type to a generic status and > > > > use a URI to indicate the status? e.g. > > > > > > > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . > > > > > > EXACTLY ... or as I was thinking text is itself a URI..but this would > > work > > > very well IMHO. > > > > Agreed. I really think we should keep the ENUM-service type simple > > and generic stating "the URI in the regex will define the status of the > > number". > > > > > The data field could be more useful and its what Jason and I used for > > CNAM > > > etc. > > > > The question of what URI scheme to use (and yes, urn: is just yet > > another URI-scheme) is open to discussion. I think there are a > > few possible solutions. data:, text: or urn:. > > > IMHO data or text. I don't want to go down the URN rat hole for reasons > earlier noted. > > > If we want to > > find out what is best choice, we should first fomulate a quick > > requirements list. What information should be encodable in that URI? > > > > Quick list: > > > > * status as a set of pre-defined values. Perhaps hierarchically > > structured. > > * Carrier identification? > > * Number block information (e.g. "this status applies to all of > +43780") > > * Porting indicator? > > > PLEASE PLEASE... I think we had consensus here. The initial use case for > this ID surrounds 3 conditions as Richard noted. > > unallocated (not existent) > > unassigned (not existent) > > inactive (inactive -= out-of-service- barred - etc) > > Can we stick with this and finish up? Please!! This is an issue that > people > want to use NOW. If the URI scheme is extensible enough people can write > separate drafts on those other items. > > Add the rest of that stuff into the draft and we might have to totally > respin the document. As it was 'void' was in the IESG queue I'd like to > justify a note to the AD's that this revision is in the context of the > original, answers their concerns, and as such does not necessarily need > additional WG LAST Call. > > OK? > > > > > > > > > > > > > > > > > > Nevertheless, in countries with variable length numbers (including > > > > direct- > > > > > dial-in) THIS DOES NOT WORK. > > > > > > > > Well, it's either that or DNS wildcards. > > > > > > Reminder that there are lots of RFC indicating wildcards in the DNS > etc > > are > > > harmful. > > > > I'm very much open to suggestion on how to solve the problem without > > resorting to wildcards. > > > > > > > > > > > > > > > The URI might contain some information regarding the range of > > > > numbers which are not valid on the PSTN. > > > > > > > > > Interesting how could you express this in a data: URI? > > > > > > > ...;apliesto=+43780 > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:40:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYfo-00013B-6x; Tue, 07 Nov 2006 16:40:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYfn-00011Y-1R for enum@ietf.org; Tue, 07 Nov 2006 16:39:59 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhYfl-0001Ay-2w for enum@ietf.org; Tue, 07 Nov 2006 16:39:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Tue, 7 Nov 2006 22:38:35 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BD0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQAAK51IAAAHstC References: <001d01c702b4$eae2a800$78218182@cis.neustar.com> From: "Stastny Richard" To: , , "Otmar Lendl" , "Richard Shockey" X-Spam-Score: 0.5 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Ok, at least I tried ;-) ________________________________ Von: Richard Shockey [mailto:Rich.Shockey@NeuStar.biz] Gesendet: Di 07.11.2006 22:37 An: Stastny Richard; rich.shockey@NeuStar.biz; 'Otmar Lendl'; 'Richard = Shockey' Cc: enum@ietf.org Betreff: RE: [Enum] void-02 new version OK its just me but I'm not going to the IESG with a "UNASS" parameter in = an ID. :-) Cant you just spell it out.. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 4:25 PM > To: rich.shockey@NeuStar.biz; Otmar Lendl; Richard Shockey > Cc: enum@ietf.org > Subject: Re: [Enum] void-02 new version > > >unallocated (not existent) > > >unassigned (not existent) > > >inactive (inactive -=3D out-of-service- barred - etc) > > I think we have at least consensus here > > I see some decisions still to make: > > E2U+status:unass with mailto and http pointing to owner > E2U+status:unall > E2U+status:inact > > E2U+status with text:unassigned or text::unallocated or text:inactive > > or > > E2U+unass:http > E2U+unass:mailto > etc > > all schemes are extensible > > >Can we stick with this and finish up? Please!! This is an issue that > people > >want to use NOW. If the URI scheme is extensible enough people can = write > >separate drafts on those other items. > > >Add the rest of that stuff into the draft and we might have to = totally > >respin the document. As it was 'void' was in the IESG queue I'd like = to > >justify a note to the AD's that this revision is in the context of = the > >original, answers their concerns, and as such does not necessarily = need > >additional WG LAST Call. > > for a complete rewrite count me out > > Richard > > > > ________________________________ > > Von: Richard Shockey [mailto:Rich.Shockey@NeuStar.biz] > Gesendet: Di 07.11.2006 22:12 > An: 'Otmar Lendl'; 'Richard Shockey' > Cc: Stastny Richard; enum@ietf.org > Betreff: RE: [Enum] void-02 new version > > > > > > > > On 2006/11/07 21:11, Richard Shockey = wrote: > > > > > > > > What about we change the service-type to a generic status and > > > > use a URI to indicate the status? e.g. > > > > > > > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . > > > > > > EXACTLY ... or as I was thinking text is itself a URI..but this = would > > work > > > very well IMHO. > > > > Agreed. I really think we should keep the ENUM-service type simple > > and generic stating "the URI in the regex will define the status of = the > > number". > > > > > The data field could be more useful and its what Jason and I used = for > > CNAM > > > etc. > > > > The question of what URI scheme to use (and yes, urn: is just yet > > another URI-scheme) is open to discussion. I think there are a > > few possible solutions. data:, text: or urn:. > > > IMHO data or text. I don't want to go down the URN rat hole for = reasons > earlier noted. > > > If we want to > > find out what is best choice, we should first fomulate a quick > > requirements list. What information should be encodable in that URI? > > > > Quick list: > > > > * status as a set of pre-defined values. Perhaps hierarchically > > structured. > > * Carrier identification? > > * Number block information (e.g. "this status applies to all of > +43780") > > * Porting indicator? > > > PLEASE PLEASE... I think we had consensus here. The initial use case = for > this ID surrounds 3 conditions as Richard noted. > > unallocated (not existent) > > unassigned (not existent) > > inactive (inactive -=3D out-of-service- barred - etc) > > Can we stick with this and finish up? Please!! This is an issue that > people > want to use NOW. If the URI scheme is extensible enough people can = write > separate drafts on those other items. > > Add the rest of that stuff into the draft and we might have to totally > respin the document. As it was 'void' was in the IESG queue I'd like = to > justify a note to the AD's that this revision is in the context of the > original, answers their concerns, and as such does not necessarily = need > additional WG LAST Call. > > OK? > > > > > > > > > > > > > > > > > > Nevertheless, in countries with variable length numbers = (including > > > > direct- > > > > > dial-in) THIS DOES NOT WORK. > > > > > > > > Well, it's either that or DNS wildcards. > > > > > > Reminder that there are lots of RFC indicating wildcards in the = DNS > etc > > are > > > harmful. > > > > I'm very much open to suggestion on how to solve the problem without > > resorting to wildcards. > > > > > > > > > > > > > > > The URI might contain some information regarding the range of > > > > numbers which are not valid on the PSTN. > > > > > > > > > Interesting how could you express this in a data: URI? > > > > > > > ...;apliesto=3D+43780 > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 16:41:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYh5-0002qA-NZ; Tue, 07 Nov 2006 16:41:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYh4-0002pz-Se for enum@ietf.org; Tue, 07 Nov 2006 16:41:18 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYh1-0001Ls-IN for enum@ietf.org; Tue, 07 Nov 2006 16:41:18 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B76A14CC9D; Tue, 7 Nov 2006 22:41:12 +0100 (CET) Date: Tue, 7 Nov 2006 22:41:12 +0100 From: Otmar Lendl To: Richard Shockey Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? Message-ID: <20061107214112.GC1386@nic.at> References: <45AEC6EF95942140888406588E1A6602453E74@PACDCEXCMB04.cable.comcast.com> <004c01c702a4$3b139660$78218182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01c702a4$3b139660$78218182@cis.neustar.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: enum@ietf.org, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/07 20:11, Richard Shockey wrote: [...] > My own personal thinking of what the appropriate enumservice for this > problem should be is something along the lines of > > E2U+status:text where the URI is a text URI text:inactive > > We could define as text a limited number of status condition potentially > including compound status with semicolon separators. > > Just a thought but it has simplicity easy to parse and is extensible if > someone thinks of something else like text:inactive;SPID=6666 As mentioned before, the basic idea seems fine. I'm just a bit confused about the text: URI. I can't find that URI scheme at http://www.iana.org/assignments/uri-schemes.html Did you mean data:? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 17:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZgz-0000hD-4n; Tue, 07 Nov 2006 17:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZgx-0000fT-D5 for enum@ietf.org; Tue, 07 Nov 2006 17:45:15 -0500 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZgv-0001IY-UZ for enum@ietf.org; Tue, 07 Nov 2006 17:45:15 -0500 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Wed, 08 Nov 2006 00:45:08 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: VS: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Wed, 8 Nov 2006 00:45:08 +0200 Message-ID: <07BC6C0D40216E44A34BE6701694FE8603BE2878@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thread-Index: AccCsul/6rrnmPEkSVCBLGAgA0VkbgAAJQkTAAJlG0U= References: <34DA635B184A644DA4588E260EC0A25A0E0E4085@ACCLUST02EVS1.ugd.att.com> <32755D354E6B65498C3BD9FD496C7D462C4BCF@oefeg-s04.oefeg.loc> From: "Nieminen Klaus" To: "Stastny Richard" X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0862191132==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0862191132== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C702BE.60573967" This is a multi-part message in MIME format. ------_=_NextPart_001_01C702BE.60573967 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I understand very well the motivation why you want void mandatory for = unassigned ENUM only numbers, but I don't think you should try to = specify void mandatory even for that number range in this ID (RFC)... I = think this is a good point to mention, but I would suggest that you use = SHOULD strenght... =20 - Klaus ________________________________ L=E4hett=E4j=E4: Stastny Richard [mailto:Richard.Stastny@oefeg.at] L=E4hetetty: ti 7.11.2006 23:27 Vastaanottaja: Niall O'Reilly Kopio: enum@ietf.org; Livingood, Jason Aihe: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thank you for coming back to this Void is optional exept for ENUM only numbers, where it is required Richard ------_=_NextPart_001_01C702BE.60573967 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Enum] RE:draft-ietf-enum-void-02 --> = my problem=0A= =0A= =0A= =0A=
=0A=
I understand = very well the motivation why you want void mandatory for unassigned ENUM = only numbers, but I don't think you should try = to specify void mandatory even for that number range = in this ID (RFC)... I think this is a good point to mention, = but I would suggest that you use SHOULD strenght...
=0A=
 
=0A=
- Klaus
=0A=

=0A=
=0A= L=E4hett=E4j=E4: Stastny Richard = [mailto:Richard.Stastny@oefeg.at]
L=E4hetetty: ti 7.11.2006 = 23:27
Vastaanottaja: Niall O'Reilly
Kopio: = enum@ietf.org; Livingood, Jason
Aihe: Re: [Enum] = RE:draft-ietf-enum-void-02 --> my problem

=0A=
=0A=

Thank you for coming back to this

Void is = optional exept for ENUM only numbers, where it is = required

Richard

------_=_NextPart_001_01C702BE.60573967-- --===============0862191132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0862191132==-- From enum-bounces@ietf.org Tue Nov 07 18:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZvb-0002ny-4B; Tue, 07 Nov 2006 18:00:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZvZ-0002no-9M for enum@ietf.org; Tue, 07 Nov 2006 18:00:21 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZvY-0003Us-1C for enum@ietf.org; Tue, 07 Nov 2006 18:00:21 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 3CED54CC9F; Wed, 8 Nov 2006 00:00:13 +0100 (CET) Date: Wed, 8 Nov 2006 00:00:13 +0100 From: Otmar Lendl To: Jaap Akkerhuis Subject: Re: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt Message-ID: <20061107230013.GA6337@nic.at> Mail-Followup-To: Otmar Lendl , Jaap Akkerhuis , Patrik =?iso-8859-15?B?RuRsdHN0cvZt?= , IETF ENUM WG , enum-wg@ripe.net References: <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> <200611070857.kA78vqHi081358@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611070857.kA78vqHi081358@open.nlnetlabs.nl> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF ENUM WG , Patrik =?iso-8859-15?B?RuRsdHN0cvZt?= , enum-wg@ripe.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/07 09:11, Jaap Akkerhuis wrote: > > On 6 okt 2006, at 00.06, Otmar Lendl wrote: > > The IETF enum list seems to be broken, > > Just repeating that the list is broken is unproductive. Just for the record here: This was an issue about one month ago. There was enough off-list diagnosing and communication which got the problem to be resolved. I mentioned the issue on the list only to explain why I resent mails (some people might have received some mails multiple times). /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 18:37:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhaUD-000375-3q; Tue, 07 Nov 2006 18:36:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhaUB-00031Q-Nq for enum@ietf.org; Tue, 07 Nov 2006 18:36:07 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhaUA-0008TI-F0 for enum@ietf.org; Tue, 07 Nov 2006 18:36:07 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Nov 2006 00:35:53 +0100 id 0007C3AA.45511859.000014DC Message-ID: <455117BD.7080101@enum.at> Date: Wed, 08 Nov 2006 00:33:17 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: richard@shockey.us Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? References: <004c01c702a4$3b139660$78218182@cis.neustar.com> In-Reply-To: <004c01c702a4$3b139660$78218182@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: enum@ietf.org, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > E2U+status:text where the URI is a text URI text:inactive just a short note: That could aid to the confusion, because one could get the impression that if this is a mobile number for which the "text" (SMS) service is disabled... However, that could actually be a feature (collides with eg. SIP's negotiation capabilites)... Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 18:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhabD-0007dd-UU; Tue, 07 Nov 2006 18:43:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhabC-0007dP-P2 for enum@ietf.org; Tue, 07 Nov 2006 18:43:22 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghab8-0000p8-HW for enum@ietf.org; Tue, 07 Nov 2006 18:43:22 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA7Nh5AJ008838; Tue, 7 Nov 2006 23:43:11 GMT From: "Richard Shockey" To: "'Otmar Lendl'" Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? Date: Tue, 7 Nov 2006 18:43:02 -0500 Organization: NeuStar, Inc, Message-ID: <009001c702c6$78d3b8f0$68418182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCtXzUd09XwK6WTEqtU8zOGde5bQAENZog In-Reply-To: <20061107214112.GC1386@nic.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: enum@ietf.org, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org HUMMM You're right, there is only the data URI... I could have sworn I saw text some where .. but the default mode of data is ASCII text > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, November 07, 2006 4:41 PM > To: Richard Shockey > Cc: 'Livingood, Jason'; enum@ietf.org > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement > onSOLUTION Void? > > On 2006/11/07 20:11, Richard Shockey wrote: > [...] > > > My own personal thinking of what the appropriate enumservice for this > > problem should be is something along the lines of > > > > E2U+status:text where the URI is a text URI text:inactive > > > > We could define as text a limited number of status condition potentially > > including compound status with semicolon separators. > > > > Just a thought but it has simplicity easy to parse and is extensible if > > someone thinks of something else like text:inactive;SPID=6666 > > As mentioned before, the basic idea seems fine. I'm just a bit confused > about the text: URI. I can't find that URI scheme at > http://www.iana.org/assignments/uri-schemes.html > > Did you mean data:? > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 18:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhaeC-000876-0w; Tue, 07 Nov 2006 18:46:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhaeA-00086f-Vw for enum@ietf.org; Tue, 07 Nov 2006 18:46:26 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghae8-0001D8-Gd for enum@ietf.org; Tue, 07 Nov 2006 18:46:26 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 92EEE86CE2; Tue, 7 Nov 2006 23:46:23 +0000 (GMT) In-Reply-To: <20061107214112.GC1386@nic.at> References: <45AEC6EF95942140888406588E1A6602453E74@PACDCEXCMB04.cable.comcast.com> <004c01c702a4$3b139660$78218182@cis.neustar.com> <20061107214112.GC1386@nic.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? Date: Tue, 7 Nov 2006 23:46:23 +0000 To: Otmar Lendl , Richard Shockey X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: enum@ietf.org, Jason Livingood X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, OK - you have filled up my mailbox, now it's your turn. (i) I checked - 3761 does not say anything about URNs, so they are not banned. (ii) what text: URI? Otmar's data: is the nearest legal option, but it sure is ugly. Getting rid of the http: or mailto: seems unwise, as they are valid URIs. I hope you all at least agree that there should be some URI in a NAPTR, right? (iii) For unassigned/unallocated numbers, who exactly gets to populate the (user) ENUM zone? It must be the election fever over there... all the best, Lawrence On 7 Nov 2006, at 21:41, Otmar Lendl wrote: > On 2006/11/07 20:11, Richard Shockey wrote: > [...] > >> My own personal thinking of what the appropriate enumservice for this >> problem should be is something along the lines of >> >> E2U+status:text where the URI is a text URI text:inactive >> >> We could define as text a limited number of status condition >> potentially >> including compound status with semicolon separators. >> >> Just a thought but it has simplicity easy to parse and is >> extensible if >> someone thinks of something else like text:inactive;SPID=6666 > > As mentioned before, the basic idea seems fine. I'm just a bit > confused > about the text: URI. I can't find that URI scheme at > http://www.iana.org/assignments/uri-schemes.html > > Did you mean data:? > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 18:51:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghaif-0003on-Rg; Tue, 07 Nov 2006 18:51:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghaie-0003oi-Kv for enum@ietf.org; Tue, 07 Nov 2006 18:51:04 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghaid-0001lt-B7 for enum@ietf.org; Tue, 07 Nov 2006 18:51:04 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Nov 2006 00:51:00 +0100 id 0007C3A7.45511BE5.000017BD Message-ID: <45511B4D.9010500@enum.at> Date: Wed, 08 Nov 2006 00:48:29 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Enum] requesting feedback on XMPP specific issues... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi, as mentioned in the session, i've discovered two "special" issues with XMPP URIs/IRIs when being used in ENUM. I'd appreciate feedback on this, as i'm currently preparing the next draft revision. 1) Authentication component: XMPP URIs may contain an authentication component, which instructs the client to authenticate as the user id given in the URI, and then contact a differen user id, eg. xmpp://alex@enum.at/office@enum.at would instruct the client to authenticate as "alex@enum.at", and then contact "office@enum.at". I have now text in the draft that the output URI of this Enumservice SHOULD NOT contain such an authentication component - there might be corner cases where it could be useful, so i refrained from using MUST. 2) IRIs: XMPP supports IRIs (non-ASCII characters in the URI). However, non-ASCII characters are always "percent-encoded", so the replacement part of the regex string in the NAPTR should always contain ASCII only. However, the regex algorithm _could_ be affected... I have currently no text about this issue in the draft. I have a strong opinion against disallowing IRIs in this Enumservice, because if XMPP itself supports them, a restriction here would limit the applicability of the Enumservice to a subset of the potential users. (And, the XMPP clients which support this Enumservice will need to support IRIs anyway to be compliant to the XMPP URI spec). However, do we need some text about special considerations with regards to that? I'd appreciate comments (or even text!) about those issues. thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 18:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghap9-0002m4-Vw; Tue, 07 Nov 2006 18:57:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghap8-0002gG-M0 for enum@ietf.org; Tue, 07 Nov 2006 18:57:46 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghaon-0002d4-On for enum@ietf.org; Tue, 07 Nov 2006 18:57:46 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Nov 2006 00:57:22 +0100 id 0007C3A7.45511D62.000018BA Message-ID: <45511CC6.2070605@enum.at> Date: Wed, 08 Nov 2006 00:54:46 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? References: <45AEC6EF95942140888406588E1A6602453E74@PACDCEXCMB04.cable.comcast.com> <004c01c702a4$3b139660$78218182@cis.neustar.com> <20061107214112.GC1386@nic.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: enum@ietf.org, Jason Livingood , Otmar Lendl , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: > (iii) For unassigned/unallocated numbers, who exactly gets to populate > the (user) ENUM zone? it cannot be delegated. An upright assignment is one of the requirements for ENUM validation and hence delegation. So, this service would mainly apply to "infrastructure" and "private" use, HOWEVER, a registry might decide (or be instructed by the local NRA) to also add such records into the tier 1 zone itself to cover "black holes" in the numbering plan ... would eg. work perfectly for unassigned area codes in the NANP... cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 19:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb4d-0005w6-UB; Tue, 07 Nov 2006 19:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb4c-0005uv-Gb for enum@ietf.org; Tue, 07 Nov 2006 19:13:46 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ghb4a-0004zI-4D for enum@ietf.org; Tue, 07 Nov 2006 19:13:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Wed, 8 Nov 2006 01:12:44 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? thread-index: AccCxZzCBmtL0IxmQF2m4sDVEYA65QABQAt+ References: <004c01c702a4$3b139660$78218182@cis.neustar.com> <455117BD.7080101@enum.at> From: "Stastny Richard" To: "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: enum@ietf.org, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think this is not a text URI it is data URI =20 E2U+status:data "!^.*$!data:,unassigned!" =20 Richard ________________________________ Von: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] Gesendet: Mi 08.11.2006 00:33 An: richard@shockey.us Cc: enum@ietf.org; 'Livingood, Jason' Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? Richard Shockey wrote: > E2U+status:text where the URI is a text URI text:inactive just a short note: That could aid to the confusion, because one could = get the impression that if this is a mobile number for which the "text" = (SMS) service is disabled... However, that could actually be a feature (collides with eg. SIP's negotiation capabilites)... Alex _______________________________________________ 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 enum-bounces@ietf.org Tue Nov 07 19:16:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb7X-00088i-HN; Tue, 07 Nov 2006 19:16:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb7W-00088c-40 for enum@ietf.org; Tue, 07 Nov 2006 19:16:46 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghb7T-0005Lf-IS for enum@ietf.org; Tue, 07 Nov 2006 19:16:45 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA80GPAJ009234; Wed, 8 Nov 2006 00:16:33 GMT From: "Richard Shockey" To: "'lconroy'" , "'Otmar Lendl'" Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? Date: Tue, 7 Nov 2006 19:16:23 -0500 Organization: NeuStar, Inc, Message-ID: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCxvkjaFjQprsXSzW4KwOIAyBfYAAA76+A In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: enum@ietf.org, 'Jason Livingood' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Tuesday, November 07, 2006 6:46 PM > To: Otmar Lendl; Richard Shockey > Cc: enum@ietf.org; Jason Livingood > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement > onSOLUTION Void? > > Hi Folks, > OK - you have filled up my mailbox, now it's your turn. > (i) I checked - 3761 does not say anything about URNs, so they are > not banned. > (ii) what text: URI? Otmar's data: is the nearest legal option, but > it sure is ugly. It's the best we can get right now and Jason and I are using it in the CNAM draft. If you do URI I's suspect a pushback from the IESG to respin the document ..the consensus is to finish this project. > Getting rid of the http: or mailto: seems unwise, as they are > valid URIs. > I hope you all at least agree that there should be some URI in > a NAPTR, right? > > (iii) For unassigned/unallocated numbers, who exactly gets to > populate the (user) ENUM zone? We put text in there suggested by Penn Pfautz that this data is generally restricted ..yada yada similar to what Jason and I did in the PSTN LNP draft. This data is not expected to be used in the public ENUM tree. > > It must be the election fever over there... > > all the best, > Lawrence > > > On 7 Nov 2006, at 21:41, Otmar Lendl wrote: > > > On 2006/11/07 20:11, Richard Shockey wrote: > > [...] > > > >> My own personal thinking of what the appropriate enumservice for this > >> problem should be is something along the lines of > >> > >> E2U+status:text where the URI is a text URI text:inactive > >> > >> We could define as text a limited number of status condition > >> potentially > >> including compound status with semicolon separators. > >> > >> Just a thought but it has simplicity easy to parse and is > >> extensible if > >> someone thinks of something else like text:inactive;SPID=6666 > > > > As mentioned before, the basic idea seems fine. I'm just a bit > > confused > > about the text: URI. I can't find that URI scheme at > > http://www.iana.org/assignments/uri-schemes.html > > > > Did you mean data:? > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > 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 enum-bounces@ietf.org Tue Nov 07 19:18:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb8Z-0001G7-5P; Tue, 07 Nov 2006 19:17:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb8Y-0001G1-35 for enum@ietf.org; Tue, 07 Nov 2006 19:17:50 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghb8W-0005Tr-Ql for enum@ietf.org; Tue, 07 Nov 2006 19:17:50 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Nov 2006 01:17:45 +0100 id 0007C3A7.45512229.00001E64 Message-ID: <45512191.5010006@enum.at> Date: Wed, 08 Nov 2006 01:15:13 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? References: <004c01c702a4$3b139660$78218182@cis.neustar.com> <455117BD.7080101@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: enum@ietf.org, "Livingood, Jason" , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > I think this is not a text URI it is data URI > > E2U+status:data "!^.*$!data:,unassigned!" Fine with me. However, in that case i'd leave out the subtype of the Enumservice. It does not add any value. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 19:18:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb8q-0001br-GE; Tue, 07 Nov 2006 19:18:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb8p-0001WE-0M for enum@ietf.org; Tue, 07 Nov 2006 19:18:07 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghb8n-0005W2-OD for enum@ietf.org; Tue, 07 Nov 2006 19:18:06 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA80HoAJ009247; Wed, 8 Nov 2006 00:18:00 GMT From: "Richard Shockey" To: "'Stastny Richard'" , "'Alexander Mayrhofer'" Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question -AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 19:17:49 -0500 Organization: NeuStar, Inc, Message-ID: <00ee01c702cb$539b45d0$68418182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCxZzCBmtL0IxmQF2m4sDVEYA65QABQAt+AAAnX+A= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: enum@ietf.org, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Looks right to me .. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 7:13 PM > To: Alexander Mayrhofer; richard@shockey.us > Cc: enum@ietf.org; Livingood, Jason > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > I think this is not a text URI it is data URI > > E2U+status:data "!^.*$!data:,unassigned!" > > Richard > > ________________________________ > > Von: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Gesendet: Mi 08.11.2006 00:33 > An: richard@shockey.us > Cc: enum@ietf.org; 'Livingood, Jason' > Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > > > Richard Shockey wrote: > > E2U+status:text where the URI is a text URI text:inactive > > just a short note: That could aid to the confusion, because one could get > the impression that if this is a mobile number for which the "text" (SMS) > service is disabled... > > However, that could actually be a feature (collides with eg. SIP's > negotiation capabilites)... > > Alex > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 19:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLI-0002Wo-41; Tue, 07 Nov 2006 19:31:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLH-0002Wj-4q for enum@ietf.org; Tue, 07 Nov 2006 19:30:59 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbLE-0006nC-PV for enum@ietf.org; Tue, 07 Nov 2006 19:30:59 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 11E0786D3F; Wed, 8 Nov 2006 00:30:56 +0000 (GMT) In-Reply-To: <45512191.5010006@enum.at> References: <004c01c702a4$3b139660$78218182@cis.neustar.com> <455117BD.7080101@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> <45512191.5010006@enum.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Wed, 8 Nov 2006 00:30:54 +0000 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: enum@ietf.org, Stastny Richard , "Livingood, Jason" , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Alex, folks, Actually, yes it does add something. data: need not be the only possible URI scheme ever associated with a "status" Enumservice, and from the mangled audio someone said in the ENUM meeting that extensibility should be considered. all the best, Lawrence On 8 Nov 2006, at 00:15, Alexander Mayrhofer wrote: > Stastny Richard wrote: >> I think this is not a text URI it is data URI >> >> E2U+status:data "!^.*$!data:,unassigned!" > > Fine with me. However, in that case i'd leave out the subtype of the > Enumservice. It does not add any value. > > Alex > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 19:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLT-0002YJ-Pg; Tue, 07 Nov 2006 19:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLS-0002Y3-B3 for enum@ietf.org; Tue, 07 Nov 2006 19:31:10 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbLQ-0006p0-Ry for enum@ietf.org; Tue, 07 Nov 2006 19:31:10 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA80UrAJ009347; Wed, 8 Nov 2006 00:31:04 GMT From: "Richard Shockey" To: "'Stastny Richard'" , "'Alexander Mayrhofer'" Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 19:30:50 -0500 Organization: NeuStar, Inc, Message-ID: <00f201c702cd$26a7a260$68418182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-asciFrom enum-bounces@ietf.org Tue Nov 07 19:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLI-0002Wo-41; Tue, 07 Nov 2006 19:31:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLH-0002Wj-4q for enum@ietf.org; Tue, 07 Nov 2006 19:30:59 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbLE-0006nC-PV for enum@ietf.org; Tue, 07 Nov 2006 19:30:59 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 11E0786D3F; Wed, 8 Nov 2006 00:30:56 +0000 (GMT) In-Reply-To: <45512191.5010006@enum.at> References: <004c01c702a4$3b139660$78218182@cis.neustar.com> <455117BD.7080101@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> <45512191.5010006@enum.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Wed, 8 Nov 2006 00:30:54 +0000 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: enum@ietf.org, Stastny Richard , "Livingood, Jason" , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Alex, folks, Actually, yes it does add something. data: need not be the only possible URI scheme ever associated with a "status" Enumservice, and from the mangled audio someone said in the ENUM meeting that extensibility should be considered. all the best, Lawrence On 8 Nov 2006, at 00:15, Alexander Mayrhofer wrote: > Stastny Richard wrote: >> I think this is not a text URI it is data URI >> >> E2U+status:data "!^.*$!data:,unassigned!" > > Fine with me. However, in that case i'd leave out the subtype of the > Enumservice. It does not add any value. > > Alex > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 19:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLT-0002YJ-Pg; Tue, 07 Nov 2006 19:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbLS-0002Y3-B3 for enum@ietf.org; Tue, 07 Nov 2006 19:31:10 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbLQ-0006p0-Ry for enum@ietf.org; Tue, 07 Nov 2006 19:31:10 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA80UrAJ009347; Wed, 8 Nov 2006 00:31:04 GMT From: "Richard Shockey" To: "'Stastny Richard'" , "'Alexander Mayrhofer'" Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 19:30:50 -0500 Organization: NeuStar, Inc, Message-ID: <00f201c702cd$26a7a260$68418182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCyzkCj5gIADTfSu2X/6jC4J3FPwAAHN8oAABZCmA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BDB@oefeg-s04.oefeg.loc> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: enum@ietf.org, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I agree it does no harm. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 7:20 PM > To: Alexander Mayrhofer > Cc: richard@shockey.us; enum@ietf.org; Livingood, Jason > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > I like to have the URI in the ENUMservice > you never know what comes next, it is extensible > > Richard > > ________________________________ > > Von: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Gesendet: Mi 08.11.2006 01:15 > An: Stastny Richard > Cc: richard@shockey.us; enum@ietf.org; Livingood, Jason > Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > > > Stastny Richard wrote: > > I think this is not a text URI it is data URI > > > > E2U+status:data "!^.*$!data:,unassigned!" > > Fine with me. However, in that case i'd leave out the subtype of the > Enumservice. It does not add any value. > > Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum i" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCyzkCj5gIADTfSu2X/6jC4J3FPwAAHN8oAABZCmA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BDB@oefeg-s04.oefeg.loc> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: enum@ietf.org, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I agree it does no harm. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 07, 2006 7:20 PM > To: Alexander Mayrhofer > Cc: richard@shockey.us; enum@ietf.org; Livingood, Jason > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > I like to have the URI in the ENUMservice > you never know what comes next, it is extensible > > Richard > > ________________________________ > > Von: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Gesendet: Mi 08.11.2006 01:15 > An: Stastny Richard > Cc: richard@shockey.us; enum@ietf.org; Livingood, Jason > Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > > > Stastny Richard wrote: > > I think this is not a text URI it is data URI > > > > E2U+status:data "!^.*$!data:,unassigned!" > > Fine with me. However, in that case i'd leave out the subtype of the > Enumservice. It does not add any value. > > Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 19:34:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbOs-00045D-Ew; Tue, 07 Nov 2006 19:34:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbOq-000457-OB for enum@ietf.org; Tue, 07 Nov 2006 19:34:40 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbOo-0007GS-WA for enum@ietf.org; Tue, 07 Nov 2006 19:34:40 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Nov 2006 01:34:35 +0100 id 0007C3AA.4551261B.0000236B Message-ID: <45512583.8010002@enum.at> Date: Wed, 08 Nov 2006 01:32:03 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? References: <004c01c702a4$3b139660$78218182@cis.neustar.com> <455117BD.7080101@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> <45512191.5010006@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDB@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BDB@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org, "Livingood, Jason" , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > I like to have the URI in the ENUMservice > you never know what comes next, it is extensible We could still extend it, even if we start first without an subtype. afaik it is perfectly legal to mix subtypes with non-existing subtype in a single type definition. The "empty" subtype is not special among them, it's not a "fallback" (correct my guys if i'm wrong). eg. if we would extend the "status" later we'd probably have: E2U+status data: E2U+status:pstn (whatever) E2U+status:ngn (whatever) ... ... or whatever. I'm just hesitating to "burn" one of the Enumservice distinguishing options by putting redundant information into it in the first place. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 19:41:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbV1-0001HH-1E; Tue, 07 Nov 2006 19:41:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbV0-0001H7-61 for enum@ietf.org; Tue, 07 Nov 2006 19:41:02 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbUx-00084Y-7N for enum@ietf.org; Tue, 07 Nov 2006 19:41:02 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9D34386D57; Wed, 8 Nov 2006 00:40:58 +0000 (GMT) In-Reply-To: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? Date: Wed, 8 Nov 2006 00:40:58 +0000 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: enum@ietf.org, 'Jason Livingood' , 'Otmar Lendl' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, folks, Scanning the list, I'm not sure that it's easy to make that consensus call. From this side of the World, it looks more there's a proposal for a different Enumservice called "status", with (a) different URI scheme. This new Enumservice would focus on one of the use cases covered in VOID, would have different restrictions on use, and would be designed to avoid any "pushback" that VOID received. It would apparently not have the equivalent of section 7 of VOID, and so would be not exactly useful in an open numbering plan environment. If it looks like a duck, it quacks like a duck, it probably isn't VOID. all the best Lawrence On 8 Nov 2006, at 00:16, Richard Shockey wrote: > If you do URI I's suspect a pushback from the IESG to respin the > document > ..the consensus is to finish this project. > We put text in there suggested by Penn Pfautz that this data is > generally > restricted ..yada yada similar to what Jason and I did in the PSTN LNP > draft. > > This data is not expected to be used in the public ENUM tree. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 19:53:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbfp-0007yx-Ou; Tue, 07 Nov 2006 19:52:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbfn-0007yr-De for enum@ietf.org; Tue, 07 Nov 2006 19:52:11 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghbfm-0001AP-6T for enum@ietf.org; Tue, 07 Nov 2006 19:52:11 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA80phAJ009544; Wed, 8 Nov 2006 00:51:50 GMT From: "Richard Shockey" To: "'lconroy'" , Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Tue, 7 Nov 2006 19:51:42 -0500 Organization: NeuStar, Inc, Message-ID: <010901c702d0$0fb19d60$68418182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCzpr6d8CiwmByQu6Z34jUYZpiIAAAGaZQ In-Reply-To: X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: enum@ietf.org, 'Otmar Lendl' , 'Jason Livingood' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org OK ..well if that's what you want I'm sure Jason or I or someone can whip up a substitute draft dealing with the specific issues of number "status" in about 2 hours. Since the subject matter is within already approved WG document scope [I'll check with the AD's] but IMHO it could instantly be made a WG item and go to last call probably within a week. Is that what you want? Split status issues from void? It really doesn't matter to me one way or another ..I'm trying to facilitate fixing a problem. > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Tuesday, November 07, 2006 7:41 PM > To: rich.shockey@NeuStar.biz > Cc: enum@ietf.org; 'Jason Livingood'; 'Otmar Lendl' > Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - > AgreementonSOLUTION Void? > > > Hi Richard, folks, > Scanning the list, I'm not sure that it's easy to make that > consensus call. > > From this side of the World, it looks more there's a proposal for a > different > Enumservice called "status", with (a) different URI scheme. > > This new Enumservice would focus on one of the use cases covered in > VOID, > would have different restrictions on use, and would be designed to avoid > any "pushback" that VOID received. > > It would apparently not have the equivalent of section 7 of VOID, and so > would be not exactly useful in an open numbering plan environment. > > If it looks like a duck, it quacks like a duck, it probably isn't VOID. > > all the best > Lawrence > > On 8 Nov 2006, at 00:16, Richard Shockey wrote: > > If you do URI I's suspect a pushback from the IESG to respin the > > document > > ..the consensus is to finish this project. > > > We put text in there suggested by Penn Pfautz that this data is > > generally > > restricted ..yada yada similar to what Jason and I did in the PSTN LNP > > draft. > > > > This data is not expected to be used in the public ENUM tree. > > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 07 19:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbj1-00023F-8V; Tue, 07 Nov 2006 19:55:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbj0-000239-6R for enum@ietf.org; Tue, 07 Nov 2006 19:55:30 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ghbiy-0001fP-OF for enum@ietf.org; Tue, 07 Nov 2006 19:55:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Wed, 8 Nov 2006 01:54:44 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BDD@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? thread-index: AccCzohgzWfwpayfTvm7mx5iRh8MfAAAMtde References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> From: "Stastny Richard" To: "lconroy" , X-Spam-Score: 0.5 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: enum@ietf.org, Otmar Lendl , Jason Livingood X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org No I do not thinks so =20 It is the same Enumservice with a different name It does not is provide the ownership (which may also provided in data, but you may not need to retrieve this infomation via ENUM, you may also get it via the NRAs webpage) It provides a possibiltiy to distingish between unallocated, unassigned = and inactive (I have no idea who needs this, but who cares) =20 The issue with the "enclosing zone" is still there: this should stay in the document as not recommended possibility for fixed lentgh numbering plans, but as useful in varialble numbering plans =20 Richard ________________________________ Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: Mi 08.11.2006 01:40 An: rich.shockey@NeuStar.biz Cc: enum@ietf.org; 'Jason Livingood'; 'Otmar Lendl' Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? Hi Richard, folks, Scanning the list, I'm not sure that it's easy to make that=20 consensus call. From this side of the World, it looks more there's a proposal for a=20 different Enumservice called "status", with (a) different URI scheme. This new Enumservice would focus on one of the use cases covered in=20 VOID, would have different restrictions on use, and would be designed to avoid any "pushback" that VOID received. It would apparently not have the equivalent of section 7 of VOID, and so would be not exactly useful in an open numbering plan environment. If it looks like a duck, it quacks like a duck, it probably isn't VOID. all the best Lawrence On 8 Nov 2006, at 00:16, Richard Shockey wrote: > If you do URI I's suspect a pushback from the IESG to respin the=20 > document > ..the consensus is to finish this project. > We put text in there suggested by Penn Pfautz that this data is=20 > generally > restricted ..yada yada similar to what Jason and I did in the PSTN LNP > draft. > > This data is not expected to be used in the public ENUM tree. _______________________________________________ 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 enum-bounces@ietf.org Tue Nov 07 19:56:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbjj-0003as-0e; Tue, 07 Nov 2006 19:56:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbji-0003ab-Jm for enum@ietf.org; Tue, 07 Nov 2006 19:56:14 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghbjh-0001jx-B7 for enum@ietf.org; Tue, 07 Nov 2006 19:56:14 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Nov 2006 01:56:04 +0100 id 0007C3A7.45512B24.000027EC Message-ID: <45512A8D.6030500@enum.at> Date: Wed, 08 Nov 2006 01:53:33 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onSOLUTION Void? References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: enum@ietf.org, 'Otmar Lendl' , 'Jason Livingood' , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: > It would apparently not have the equivalent of section 7 of VOID, and so > would be not exactly useful in an open numbering plan environment. alex whispers: *wildcard* ducks, and runs away. :) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 20:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbqj-0007vw-Fg; Tue, 07 Nov 2006 20:03:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbqh-0007la-0y for enum@ietf.org; Tue, 07 Nov 2006 20:03:27 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ghbqf-0002j0-E7 for enum@ietf.org; Tue, 07 Nov 2006 20:03:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Wed, 8 Nov 2006 01:59:31 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BDE@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? thread-index: AccC0JlCETYmjX+aTIe1DmITX7EzrwAAI0z2 References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> <45512A8D.6030500@enum.at> From: "Stastny Richard" To: "Alexander Mayrhofer" , "lconroy" X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: enum@ietf.org, Jason Livingood , Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Do not run away ;-) =20 wildcard only works in Infrastructure ENUM having only a tier 1 =20 If we want to have an ENUMservice ONLY for Infrastructure ENUM - fine =20 But IMO it should also work in User ENUM =20 So we could add text saying that the "enclosing zone" is only required = in User ENUM in Infrastructure ENUM this could also be done with wildcards =20 Richard ________________________________ Von: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] Gesendet: Mi 08.11.2006 01:53 An: lconroy Cc: enum@ietf.org; 'Otmar Lendl'; 'Jason Livingood'; = rich.shockey@NeuStar.biz Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? lconroy wrote: > It would apparently not have the equivalent of section 7 of VOID, and = so > would be not exactly useful in an open numbering plan environment. alex whispers: *wildcard* ducks, and runs away. :) _______________________________________________ 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 enum-bounces@ietf.org Tue Nov 07 20:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbx7-0005d8-Md; Tue, 07 Nov 2006 20:10:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbx5-0005cf-VR for enum@ietf.org; Tue, 07 Nov 2006 20:10:03 -0500 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghbx0-0003hD-JL for enum@ietf.org; Tue, 07 Nov 2006 20:10:03 -0500 Received: from [212.158.216.75] (account jim HELO [10.59.1.78]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 110387; Wed, 08 Nov 2006 01:09:57 +0000 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BDD@oefeg-s04.oefeg.loc> References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> <32755D354E6B65498C3BD9FD496C7D462C4BDD@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79F72716-EF4C-4C69-8BE2-6E9D8226790A@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Date: Wed, 8 Nov 2006 01:09:55 +0000 To: "Stastny Richard" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: enum@ietf.org, Jason Livingood , lconroy , Otmar Lendl , rich.shockey@NeuStar.biz Subject: [Enum] finding the closest enclosing zone X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Nov 8, 2006, at 00:54, Stastny Richard wrote: > The issue with the "enclosing zone" is still there: > this should stay in the document as not recommended possibility > for fixed lentgh numbering plans, but as useful in varialble > numbering plans Even with a fixed numbering plan, the problem of finding the closest encloser remains: eg delegations on an "area code" basis or to a DDI block. When there are a fixed number of labels (digits in this case) in some domain name this tells you nothing about the number of delegations that could exist within that domain name or where those delegations occur. BTW people, I've changed the subject header to make it more appropriate to this thread. Please try to do this for all the other threads that have exploded off "draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement?" :-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 07 20:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhcEx-0000c4-28; Tue, 07 Nov 2006 20:28:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhcEw-0000bz-Bh for enum@ietf.org; Tue, 07 Nov 2006 20:28:30 -0500 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhcEt-0005eg-VK for enum@ietf.org; Tue, 07 Nov 2006 20:28:30 -0500 Received: from [212.158.216.75] (account jim HELO [10.59.1.78]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 110394; Wed, 08 Nov 2006 01:28:26 +0000 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BDE@oefeg-s04.oefeg.loc> References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> <45512A8D.6030500@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDE@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Date: Wed, 8 Nov 2006 01:28:23 +0000 To: "Stastny Richard" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: enum@ietf.org, Otmar Lendl , Alexander Mayrhofer , lconroy , rich.shockey@NeuStar.biz, Jason Livingood Subject: [Enum] wildcards X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Nov 8, 2006, at 00:59, Stastny Richard wrote: > So we could add text saying that the "enclosing zone" is only > required in User ENUM > in Infrastructure ENUM this could also be done with wildcards I would not support this. It is far from clear whether the need to find the enclosing zone is only a problem for User ENUM. My gut feel is it isn't. Current thinking for Infrastructure ENUM or Enterprise ENUM might focus around monolithic centralised systems. That may change later. So tossing the closest encloser issue away at this stage may well return to haunt the WG. A generalised solution that isn't specific to one flavour of ENUM is the way forward IMO. My views about DNS wildcarding are well known and don't need to be repeated here. Putting text in the draft that says "you can do this with wildcards" is just bad. Should the draft enumerate all the other silly and ill-advised ways of solving this problem as well? Where should the line be drawn? More importantly if the draft contains this sort of text, clueless bozos will interpret that as meaning "the IETF says it's perfectly OK to use wildcarding to handle this problem" and deploy that approach. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 00:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghfag-0000yk-Pe; Wed, 08 Nov 2006 00:03:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghfaf-0000yY-Jz for enum@ietf.org; Wed, 08 Nov 2006 00:03:09 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghfab-0008O3-Ks for enum@ietf.org; Wed, 08 Nov 2006 00:03:09 -0500 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.27329526; Wed, 08 Nov 2006 00:02:37 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 00:02:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Wed, 8 Nov 2006 00:02:36 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020D52BF@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQAD0RqUA== From: "Livingood, Jason" To: "Stastny Richard" , , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 08 Nov 2006 05:02:36.0747 (UTC) FILETIME=[1BA539B0:01C702F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > >unallocated (not existent) >=20 > >unassigned (not existent) >=20 > >inactive (inactive -=3D out-of-service- barred - etc) I still don't understand how the inactive use case differs... J _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 00:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfaQ-0000xi-EK; Wed, 08 Nov 2006 00:02:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfaP-0000xd-DH for enum@ietf.org; Wed, 08 Nov 2006 00:02:53 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhfaK-0008M8-5U for enum@ietf.org; Wed, 08 Nov 2006 00:02:53 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27402354; Wed, 08 Nov 2006 00:02:22 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 00:02:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Wed, 8 Nov 2006 00:02:21 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAA+E8JA= From: "Livingood, Jason" To: , "Otmar Lendl" X-OriginalArrivalTime: 08 Nov 2006From enum-bounces@ietf.org Wed Nov 08 00:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghfag-0000yk-Pe; Wed, 08 Nov 2006 00:03:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghfaf-0000yY-Jz for enum@ietf.org; Wed, 08 Nov 2006 00:03:09 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghfab-0008O3-Ks for enum@ietf.org; Wed, 08 Nov 2006 00:03:09 -0500 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.27329526; Wed, 08 Nov 2006 00:02:37 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 00:02:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Wed, 8 Nov 2006 00:02:36 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020D52BF@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQAD0RqUA== From: "Livingood, Jason" To: "Stastny Richard" , , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 08 Nov 2006 05:02:36.0747 (UTC) FILETIME=[1BA539B0:01C702F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > >unallocated (not existent) >=20 > >unassigned (not existent) >=20 > >inactive (inactive -=3D out-of-service- barred - etc) I still don't understand how the inactive use case differs... J _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 00:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfaQ-0000xi-EK; Wed, 08 Nov 2006 00:02:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfaP-0000xd-DH for enum@ietf.org; Wed, 08 Nov 2006 00:02:53 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhfaK-0008M8-5U for enum@ietf.org; Wed, 08 Nov 2006 00:02:53 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27402354; Wed, 08 Nov 2006 00:02:22 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 00:02:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Wed, 8 Nov 2006 00:02:21 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAA+E8JA= From: "Livingood, Jason" To: , "Otmar Lendl" X-OriginalArrivalTime: 08 Nov 2006 05:02:21.0839 (UTC) FILETIME=[12C271F0:01C702F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > > Quick list: > >=20 > > * status as a set of pre-defined values. Perhaps hierarchically > > structured. Sounds complicated. Maybe we should keep it more simple, easier to implement and understand. > > * Carrier identification? > > * Number block information (e.g. "this status applies to all of=20 > > +43780") > > * Porting indicator? On those 3, IMHO, no, let's not lose focus. If we want carrier ID or some of the other stuff, then do it in a different enumservice... > PLEASE PLEASE... I think we had consensus here. The initial=20 > use case for this ID surrounds 3 conditions as Richard noted. >=20 > unallocated (not existent) >=20 > unassigned (not existent) >=20 > inactive (inactive -=3D out-of-service- barred - etc) Well, hold on just a second. I thought we had consensus on the first two use cases. Where did the 3rd one above come from? Can someone please describe the specific use case and how that is noticeably different from the first two? In the first the NRA has not put a TN in service, and in the second the SP has not done so. So in the third, what party are we talking about? Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum 05:02:21.0839 (UTC) FILETIME=[12C271F0:01C702F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > > Quick list: > >=20 > > * status as a set of pre-defined values. Perhaps hierarchically > > structured. Sounds complicated. Maybe we should keep it more simple, easier to implement and understand. > > * Carrier identification? > > * Number block information (e.g. "this status applies to all of=20 > > +43780") > > * Porting indicator? On those 3, IMHO, no, let's not lose focus. If we want carrier ID or some of the other stuff, then do it in a different enumservice... > PLEASE PLEASE... I think we had consensus here. The initial=20 > use case for this ID surrounds 3 conditions as Richard noted. >=20 > unallocated (not existent) >=20 > unassigned (not existent) >=20 > inactive (inactive -=3D out-of-service- barred - etc) Well, hold on just a second. I thought we had consensus on the first two use cases. Where did the 3rd one above come from? Can someone please describe the specific use case and how that is noticeably different from the first two? In the first the NRA has not put a TN in service, and in the second the SP has not done so. So in the third, what party are we talking about? Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 00:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfaG-0000wx-55; Wed, 08 Nov 2006 00:02:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhfaF-0000ws-KY for enum@ietf.org; Wed, 08 Nov 2006 00:02:43 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhfaA-0008LZ-Dz for enum@ietf.org; Wed, 08 Nov 2006 00:02:43 -0500 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27402353; Wed, 08 Nov 2006 00:02:19 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 00:02:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Wed, 8 Nov 2006 00:02:19 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020D52BC@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccCohOXavykb06JR1+JP2kprdXEEQACc1SwABBnbzA= From: "Livingood, Jason" To: , "Otmar Lendl" , "Stastny Richard" X-OriginalArrivalTime: 08 Nov 2006 05:02:19.0029 (UTC) FILETIME=[1115AC50:01C702F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > > What about we change the service-type to a generic status and use a=20 > > URI to indicate the status? e.g. > >=20 > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . >=20 > EXACTLY ... or as I was thinking text is itself a URI..but=20 > this would work very well IMHO. This looks useful Otmar... So we'd have these two types, right? "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!"=20 "E2U+status" "u" 0 0 "!.*!data:text/plain,unallocated!" My only question is back to whether "status" is right or not. Thinking of an implementer a few years from now... They may wonder why there's not a status record for any number. Perhaps we can pick something that gives a better hint that a number is in fact not in service in some manner? I will concede that this may reduce the extesibility of the "status" notion, but that may not be a bad thing. Jason=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 01:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhhNU-0004T8-HN; Wed, 08 Nov 2006 01:57:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhhMW-00046a-Hl for enum@ietf.org; Wed, 08 Nov 2006 01:56:40 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhhIM-00010C-VE for enum@ietf.org; Wed, 08 Nov 2006 01:52:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Wed, 8 Nov 2006 07:50:36 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQAD0RqUAAE0EtT References: <45AEC6EF95942140888406588E1A66020D52BF@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , , "Otmar Lendl" , "Richard Shockey" X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The inactive status came from the discussion, but I also think this = status is too dynamc and should not be put into DNS =20 Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Mi 08.11.2006 06:02 An: Stastny Richard; rich.shockey@NeuStar.biz; Otmar Lendl; Richard = Shockey Cc: enum@ietf.org Betreff: RE: [Enum] void-02 new version > >unallocated (not existent) > > >unassigned (not existent) > > >inactive (inactive -=3D out-of-service- barred - etc) I still don't understand how the inactive use case differs... J _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 02:07:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhhMl-0004NC-Gt; Wed, 08 Nov 2006 01:56:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhhMc-0004KH-Fg for enum@ietf.org; Wed, 08 Nov 2006 01:56:46 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhhFl-0000Nh-1f for enum@ietf.org; Wed, 08 Nov 2006 01:49:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Wed, 8 Nov 2006 07:48:12 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccCohOXavykb06JR1+JP2kprdXEEQACc1SwABBnbzAABRdXug== References: <45AEC6EF95942140888406588E1A66020D52BC@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , , "Otmar Lendl" X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org the other option was "vacant", but this is also not perfect =20 Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Mi 08.11.2006 06:02 An: rich.shockey@NeuStar.biz; Otmar Lendl; Stastny Richard Cc: enum@ietf.org Betreff: RE: [Enum] void-02 new version > > What about we change the service-type to a generic status and use a > > URI to indicate the status? e.g. > > > > "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" . > > EXACTLY ... or as I was thinking text is itself a URI..but > this would work very well IMHO. This looks useful Otmar... So we'd have these two types, right? "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" "E2U+status" "u" 0 0 "!.*!data:text/plain,unallocated!" My only question is back to whether "status" is right or not. Thinking of an implementer a few years from now... They may wonder why there's not a status record for any number. Perhaps we can pick something that gives a better hint that a number is in fact not in service in some manner? I will concede that this may reduce the extesibility of the "status" notion, but that may not be a bad thing. Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 03:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj0D-0005qS-JK; Wed, 08 Nov 2006 03:41:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj0C-0005cn-Ku for enum@ietf.org; Wed, 08 Nov 2006 03:41:44 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghimt-0001KY-JV for enum@ietf.org; Wed, 08 Nov 2006 03:28:00 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id CD9BA86E22; Wed, 8 Nov 2006 08:27:58 +0000 (GMT) In-Reply-To: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] void-02 new version Date: Wed, 8 Nov 2006 08:27:58 +0000 To: "Livingood, Jason" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: enum@ietf.org, Stastny Richard , Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Jason, folks, This is exactly one of my issues. As Jason says below, these first two cases seem to differ in who is controlling the zone. "Unallocated" means the NRA still controls the zone (as then have not put a TN in service). In the "Unassigned" case, the SP controls the zone (as the SP has not put a TN into service). This last "Inactive" case seems to imply this as well, but only makes sense if it takes a long time to make a TN active. Otherwise why bother provisioning this status? Who/What controls the zone may be important information. all the best, Lawrence On 8 Nov 2006, at 05:02, Livingood, Jason wrote: >> PLEASE PLEASE... I think we had consensus here. The initial >> use case for this ID surrounds 3 conditions as Richard noted. >> >> unallocated (not existent) >> >> unassigned (not existent) >> >> inactive (inactive -= out-of-service- barred - etc) > > Well, hold on just a second. I thought we had consensus on the first > two use cases. Where did the 3rd one above come from? Can someone > please describe the specific use case and how that is noticeably > different from the first two? In the first the NRA has not put a > TN in > service, and in the second the SP has not done so. So in the third, > what party are we talking about? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 08:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhnP1-00056s-6S; Wed, 08 Nov 2006 08:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhnP0-00056n-03 for enum@ietf.org; Wed, 08 Nov 2006 08:23:38 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbO4-000789-Kg for enum@ietf.org; Tue, 07 Nov 2006 19:33:52 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GhbCg-0006eV-IQ for enum@ietf.org; Tue, 07 Nov 2006 19:22:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? Date: Wed, 8 Nov 2006 01:20:19 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BDB@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void? thread-index: AccCyzkCj5gIADTfSu2X/6jC4J3FPwAAHN8o References: <004c01c702a4$3b139660$78218182@cis.neustar.com> <455117BD.7080101@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDA@oefeg-s04.oefeg.loc> <45512191.5010006@enum.at> From: "Stastny Richard" To: "Alexander Mayrhofer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: enum@ietf.org, "Livingood, Jason" , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I like to have the URI in the ENUMservice you never know what comes next, it is extensible =20 Richard ________________________________ Von: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] Gesendet: Mi 08.11.2006 01:15 An: Stastny Richard Cc: richard@shockey.us; enum@ietf.org; Livingood, Jason Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - = AgreementonSOLUTION Void? Stastny Richard wrote: > I think this is not a text URI it is data URI >=20 > E2U+status:data "!^.*$!data:,unassigned!" Fine with me. However, in that case i'd leave out the subtype of the Enumservice. It does not add any value. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 09:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhnzW-00067H-4j; Wed, 08 Nov 2006 09:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWMo-0002RE-6C for enum@ietf.org; Tue, 07 Nov 2006 14:12:14 -0500 Received: from rockstar.seiri.com ([204.130.216.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWMm-0000Bq-E0 for enum@ietf.org; Tue, 07 Nov 2006 14:12:14 -0500 Received: from localhost (bownes@localhost) by rockstar.seiri.com (8.11.6/8.11.6) with ESMTP id kA7JBr019789; Tue, 7 Nov 2006 14:11:53 -0500 Date: Tue, 7 Nov 2006 14:09:20 -0500 (EST) From: Bob Bownes To: "Michael Hammer (mhammer)" Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement? In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3022DA886@xmb-rtp-20b.amer.cisco.com> Message-ID: References: <072C5B76F7CEAB488172C6F64B30B5E3022DA886@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.6 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Wed, 08 Nov 2006 09:01:20 -0500 Cc: enum@ietf.org, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org While fundamentally I agree returning something now rather than nothing later and avoiding PDD is a Good Thing, I wonder if this means we either have to make the DNS server ENUM aware (I see a NULL URI, so return NXDOMAIN right now) or the *all* applications NULL URI aware (I see a NULL URI and know what to do with it). On Tue, 7 Nov 2006, Michael Hammer (mhammer) wrote: > It's a question of pay me now or pay me later. > > Do SP's want to pay the cost in an ENUM response, or a failed PSTN GW > call? > > I would argue that handling in ENUM would be much, much more efficient, > since it won't involve setting up media to a PSTN GW, the added gateway > control signaling, and possibly occupation of otherwise useful trunk > capacity, just to find out the number is not assigned. > > Mike > > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, November 06, 2006 7:15 PM > > To: enum@ietf.org > > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First > > Question - Agreement onProblem Statement? > > > > > What would be useful is a mechanism "between" a registration > > > holding > > > NAPTRs with URIs and the lack of a domain registration. > > > In this way, > > > an entity who is responsible for E.164 numbers in a range can > > > indicate that a particular number has not been assigned > > to anyone > > > for > > > communications service. For example, if a communications service > > > provider has been allocated responsibility for > > delivering calls to > > > endpoints identified with E.164 numbers in a block, then they may > > > have some numbers in that block that are currently unused. These > > > E.164 numbers are not used to terminate calls to end users. > > > > So from this, I would understand the problem as such - > > > > A service provider has a number block of, for example, > > +1-215-981-XXXX, where XXXX is -0000 to -9999. That SP has > > issued 50% of these numbers to individual subscribers and the > > other 50% have not been. These are not neatly distributed > > within the block, as subscribers choose their numbers so the > > active numbers end up being randomly distributed in the block. > > > > If the SP registers SIP URIs for all of the active TNs then > > those calls will work and terminate just fine. If a TN is > > not registered then, since it is inactive, then if a person > > dials one of the unregistered TNs then you have to wait for > > NXDOMAIN response. In that case, most softswitches / proxies > > will then do legacy lookups (LNP, LERG, etc.). > > The downside is two-fold: greater post-dial delay than is > > necessary, and having to rely on legacy call lookup tools > > (which may have associated costs). There should be a way > > instead to stop the call routing progression immediately if > > you know that the TN is inactive, thus triggering back the > > code for a number not in service network announcement to a caller. > > > > Is this a correct understanding of one of the issues the > > authors are trying to identify in the problem statement? > > > > Jason > > > > _______________________________________________ > > 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 enum-bounces@ietf.org Wed Nov 08 10:01:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghou9-0007hg-2v; Wed, 08 Nov 2006 09:59:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghou7-0007ha-MN for enum@ietf.org; Wed, 08 Nov 2006 09:59:51 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ghou6-0000R8-9T for enum@ietf.org; Wed, 08 Nov 2006 09:59:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Wed, 8 Nov 2006 15:57:37 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccDD7O2BlUd+d44QryrIu6qK9AF+wANoeH0 References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "lconroy" , "Livingood, Jason" X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: enum@ietf.org, Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >Who/What controls the zone may be important information. maybe, but not for the originator during the call =20 Richard ________________________________ Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: Mi 08.11.2006 09:27 An: Livingood, Jason Cc: rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org; Stastny = Richard Betreff: Re: [Enum] void-02 new version Hi Jason, folks, This is exactly one of my issues. As Jason says below, these first two cases seem to differ in who is controlling the zone. "Unallocated" means the NRA still controls the zone (as then have not put a TN in service). In the "Unassigned" case, the SP controls the zone (as the SP has not put a TN into service). This last "Inactive" case seems to imply this as well, but only makes sense if it takes a long time to make a TN active. Otherwise why bother provisioning this status? Who/What controls the zone may be important information. all the best, Lawrence On 8 Nov 2006, at 05:02, Livingood, Jason wrote: >> PLEASE PLEASE... I think we had consensus here. The initial >> use case for this ID surrounds 3 conditions as Richard noted. >> >> unallocated (not existent) >> >> unassigned (not existent) >> >> inactive (inactive -=3D out-of-service- barred - etc) > > Well, hold on just a second. I thought we had consensus on the first > two use cases. Where did the 3rd one above come from? Can someone > please describe the specific use case and how that is noticeably > different from the first two? In the first the NRA has not put a=20 > TN in > service, and in the second the SP has not done so. So in the third, > what party are we talking about? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 10:14:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghp6l-0006a9-5I; Wed, 08 Nov 2006 10:12:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghp6k-0006a3-HV for enum@ietf.org; Wed, 08 Nov 2006 10:12:54 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghp6j-0002Bn-2t for enum@ietf.org; Wed, 08 Nov 2006 10:12:54 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id CE44686FF5; Wed, 8 Nov 2006 15:12:51 +0000 (GMT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc> References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] void-02 new version Date: Wed, 8 Nov 2006 15:12:50 +0000 To: "Stastny Richard" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: enum@ietf.org, Otmar Lendl , "Livingood, Jason" , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, folks, Absolutely agree that it doesn't matter to the originator. But if the real difference between these two cases is whether the NRA or the SP controls the zone and provisions the Vacant/Void/Status/... NAPTR, then why do we need both Unallocated and Unassigned? How does this make a difference to the originating ENUM client? all the best, Lawrence On 8 Nov 2006, at 14:57, Stastny Richard wrote: >> Who/What controls the zone may be important information. > > maybe, but not for the originator during the call > > Richard > > ________________________________ > > Von: lconroy [mailto:lconroy@insensate.co.uk] > Gesendet: Mi 08.11.2006 09:27 > An: Livingood, Jason > Cc: rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org; Stastny > Richard > Betreff: Re: [Enum] void-02 new version > > > > Hi Jason, folks, > This is exactly one of my issues. As Jason says below, these first > two cases seem to differ in who is controlling the zone. > > "Unallocated" means the NRA still controls the zone (as then have not > put a TN in service). > > In the "Unassigned" case, the SP controls the zone (as the SP has not > put a TN into service). > > This last "Inactive" case seems to imply this as well, but only makes > sense if it takes a long time to make a TN active. Otherwise why > bother > provisioning this status? > > Who/What controls the zone may be important information. > > all the best, > Lawrence > > On 8 Nov 2006, at 05:02, Livingood, Jason wrote: >>> PLEASE PLEASE... I think we had consensus here. The initial >>> use case for this ID surrounds 3 conditions as Richard noted. >>> >>> unallocated (not existent) >>> >>> unassigned (not existent) >>> >>> inactive (inactive -= out-of-service- barred - etc) >> >> Well, hold on just a second. I thought we had consensus on the first >> two use cases. Where did the 3rd one above come from? Can someone >> please describe the specific use case and how that is noticeably >> different from the first two? In the first the NRA has not put a >> TN in >> service, and in the second the SP has not done so. So in the third, >> what party are we talking about? > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 10:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpKF-0004Tt-3d; Wed, 08 Nov 2006 10:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpKD-0004Tf-M2 for enum@ietf.org; Wed, 08 Nov 2006 10:26:49 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhpKB-0003yz-31 for enum@ietf.org; Wed, 08 Nov 2006 10:26:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Wed, 8 Nov 2006 16:22:55 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE3@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccDSEOvdUA/UXspRK6aKNldjnJKvwAAYAXf References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc> From: "Stastny Richard" To: "lconroy" X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: enum@ietf.org, Otmar Lendl , "Livingood, Jason" , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org that why I proposed to use vacant/void/status as ENUMservice and put the rest in the text/data The originator does not need to look in the URI during call setup (as it was with void), he simple stops the call Richard ________________________________ Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: Mi 08.11.2006 16:12 An: Stastny Richard Cc: Livingood, Jason; rich.shockey@NeuStar.biz; Otmar Lendl; = enum@ietf.org Betreff: Re: [Enum] void-02 new version Hi Richard, folks, Absolutely agree that it doesn't matter to the originator. But if the real difference between these two cases is whether the NRA=20 or the SP controls the zone and provisions the Vacant/Void/Status/... NAPTR,=20 then why do we need both Unallocated and Unassigned? How does this make a difference to the originating ENUM client? all the best, Lawrence On 8 Nov 2006, at 14:57, Stastny Richard wrote: >> Who/What controls the zone may be important information. > > maybe, but not for the originator during the call > > Richard > > ________________________________ > > Von: lconroy [mailto:lconroy@insensate.co.uk] > Gesendet: Mi 08.11.2006 09:27 > An: Livingood, Jason > Cc: rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org; Stastny=20 > Richard > Betreff: Re: [Enum] void-02 new version > > > > Hi Jason, folks, > This is exactly one of my issues. As Jason says below, these first > two cases seem to differ in who is controlling the zone. > > "Unallocated" means the NRA still controls the zone (as then have not > put a TN in service). > > In the "Unassigned" case, the SP controls the zone (as the SP has not > put a TN into service). > > This last "Inactive" case seems to imply this as well, but only makes > sense if it takes a long time to make a TN active. Otherwise why=20 > bother > provisioning this status? > > Who/What controls the zone may be important information. > > all the best, > Lawrence > > On 8 Nov 2006, at 05:02, Livingood, Jason wrote: >>> PLEASE PLEASE... I think we had consensus here. The initial >>> use case for this ID surrounds 3 conditions as Richard noted. >>> >>> unallocated (not existent) >>> >>> unassigned (not existent) >>> >>> inactive (inactive -=3D out-of-service- barred - etc) >> >> Well, hold on just a second. I thought we had consensus on the first >> two use cases. Where did the 3rd one above come from? Can someone >> please describe the specific use case and how that is noticeably >> different from the first two? In the first the NRA has not put a >> TN in >> service, and in the second the SP has not done so. So in the third, >> what party are we talking about? > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 13:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrtM-0004iG-K7; Wed, 08 Nov 2006 13:11:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrtL-0004hI-5o for enum@ietf.org; Wed, 08 Nov 2006 13:11:15 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrqN-0002O5-SP for enum@ietf.org; Wed, 08 Nov 2006 13:08:14 -0500 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id kA8I7sAJ019965; Wed, 8 Nov 2006 18:08:00 GMT From: "Richard Shockey" To: "'Livingood, Jason'" , "'Stastny Richard'" , , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Enum] void-02 new version Date: Wed, 8 Nov 2006 13:07:52 -0500 Organization: NeuStar, Inc, Message-ID: <02d201c70360$d040f450$68418182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45AEC6EF95942140888406588E1A66020D52BF@PACDCEXCMB04.cable.comcast.com> Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQAD0RqUAAcSoZQ X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Well inactive is useful but to your point I'm not sure its realistically possible to express since it involves highly dynamic data that is inappropriate for the DNS infrastructure to deal with. So yes ..in the interest of simplicity the relevant use cases for THIS DRAFT should be limited to unallocated as well as unassigned. The chairs interest here is to respond to comments of the IESG on the void-03. There is always an opportunity to do additional drafts that define elements of number status. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Wednesday, November 08, 2006 12:03 AM > To: Stastny Richard; rich.shockey@NeuStar.biz; Otmar Lendl; Richard > Shockey > Cc: enum@ietf.org > Subject: RE: [Enum] void-02 new version > > > >unallocated (not existent) > > > > >unassigned (not existent) > > > > >inactive (inactive -= out-of-service- barred - etc) > > I still don't understand how the inactive use case differs... > > J > > _______________________________________________ > 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 enum-bounces@ietf.org Wed Nov 08 14:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhseO-00062s-8I; Wed, 08 Nov 2006 13:59:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhseM-00062I-Jb for enum@ietf.org; Wed, 08 Nov 2006 13:59:50 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhseK-0001R3-VR for enum@ietf.org; Wed, 08 Nov 2006 13:59:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version - new name: unused Date: Wed, 8 Nov 2006 19:59:05 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version - new name: unused thread-index: AccDZi55IfT8jrF0RiGbTMrHfyAaaQAAOrhZ References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com><32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc><32755D354E6B65498C3BD9FD496C7D462C4BE3@oefeg-s04.oefeg.loc> <1163011412.30540.26.camel@localhost> From: "Stastny Richard" To: "Ed Guy" X-Spam-Score: 0.5 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: enum@ietf.org, "Livingood, Jason" , lconroy , Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >What happens when a number is changed? On the PSTN,=20 >the Caller would be given an intercept message like >"The number have have dialled has been changed. =20 >The new number is ". =20 >personally, I'd like to have this scenario result in an origination >feature that updates my address book. >Should this be in scope for the status indication? we should not overload void/status/etc with this issues - they may be handled with normal enumservices (such as announcement) =20 I am starting to get problems with the new name status, because it seems to open up another can-of-worms of interpretations =20 what about "unused" for both unallocated and unassigned that narrows the used better than status =20 Richard ________________________________ Von: Ed Guy [mailto:edguy@emcsw.com] Gesendet: Mi 08.11.2006 19:43 An: Stastny Richard Cc: lconroy; enum@ietf.org; Otmar Lendl; Livingood, Jason; = rich.shockey@NeuStar.biz Betreff: Re: [Enum] void-02 new version On the void/status indications, the originator needs to stop the call in all of these cases, but the issue is=20 "what indication to they give to the calling party?" On unassigned vs unallocated: If a well-formed number has not yet been allocated by the NRA or=20 assigned by one of its delegates, the handling might be the same. =20 Why is the national regulator special? any domain may be delegated. (so, two designations are not needed)=20 on Out of service: If the services associated with a number is out of order, there is an=20 opportunity to push this status to the originating side, foregoing=20 SIP timeouts. the TTL would need to be very short.=20 We should consider what happens in open dialing plans=20 where a dialled number may be too short.=20 (it's possible I missed this discussion in this email chain). and also,=20 What happens when a number is changed? On the PSTN,=20 the Caller would be given an intercept message like "The number have have dialled has been changed. =20 The new number is ". =20 personally, I'd like to have this scenario result in an origination feature that updates my address book. Should this be in scope for the status indication? /ed On Wed, 2006-11-08 at 16:22 +0100, Stastny Richard wrote:=20 that why I proposed to use vacant/void/status as ENUMservice and put the rest in the text/data =09 The originator does not need to look in the URI during call setup (as it was with void), he simple stops the call =09 Richard =09 ________________________________ =09 Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: Mi 08.11.2006 16:12 An: Stastny Richard Cc: Livingood, Jason; rich.shockey@NeuStar.biz; Otmar Lendl; = enum@ietf.org Betreff: Re: [Enum] void-02 new version =09 =09 =09 Hi Richard, folks, Absolutely agree that it doesn't matter to the originator. But if the real difference between these two cases is whether the NRA=20 or the SP controls the zone and provisions the Vacant/Void/Status/... NAPTR,=20 then why do we need both Unallocated and Unassigned? How does this make a difference to the originating ENUM client? =09 all the best, Lawrence =09 On 8 Nov 2006, at 14:57, Stastny Richard wrote: >> Who/What controls the zone may be important information. > > maybe, but not for the originator during the call > > Richard > > ________________________________ > > Von: lconroy [mailto:lconroy@insensate.co.uk] > Gesendet: Mi 08.11.2006 09:27 > An: Livingood, Jason > Cc: rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org; Stastny=20 > Richard > Betreff: Re: [Enum] void-02 new version > > > > Hi Jason, folks, > This is exactly one of my issues. As Jason says below, these first > two cases seem to differ in who is controlling the zone. > > "Unallocated" means the NRA still controls the zone (as then have not > put a TN in service). > > In the "Unassigned" case, the SP controls the zone (as the SP has not > put a TN into service). > > This last "Inactive" case seems to imply this as well, but only makes > sense if it takes a long time to make a TN active. Otherwise why=20 > bother > provisioning this status? > > Who/What controls the zone may be important information. > > all the best, > Lawrence > > On 8 Nov 2006, at 05:02, Livingood, Jason wrote: >>> PLEASE PLEASE... I think we had consensus here. The initial >>> use case for this ID surrounds 3 conditions as Richard noted. >>> >>> unallocated (not existent) >>> >>> unassigned (not existent) >>> >>> inactive (inactive -=3D out-of-service- barred - etc) >> >> Well, hold on just a second. I thought we had consensus on the = first >> two use cases. Where did the 3rd one above come from? Can someone >> please describe the specific use case and how that is noticeably >> different from the first two? In the first the NRA has not put a >> TN in >> service, and in the second the SP has not done so. So in the third, >> what party are we talking about? > > > =09 =09 =09 =09 _______________________________________________ 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 enum-bounces@ietf.org Wed Nov 08 14:08:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghsmb-00012h-GU; Wed, 08 Nov 2006 14:08:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghsma-00012a-K3 for enum@ietf.org; Wed, 08 Nov 2006 14:08:20 -0500 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsmX-0002SX-Mv for enum@ietf.org; Wed, 08 Nov 2006 14:08:20 -0500 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Wed, 08 Nov 2006 21:08:14 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: VS: [Enum] void-02 new version - new name: unused Date: Wed, 8 Nov 2006 21:04:18 +0200 Message-ID: <07BC6C0D40216E44A34BE6701694FE8603BE2888@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version - new name: unused Thread-Index: AccDZi55IfT8jrF0RiGbTMrHfyAaaQAAOrhZAABl6fQ= References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com><32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc><32755D354E6B65498C3BD9FD496C7D462C4BE3@oefeg-s04.oefeg.loc><1163011412.30540.26.camel@localhost> <32755D354E6B65498C3BD9FD496C7D462C4BE4@oefeg-s04.oefeg.loc> From: "Nieminen Klaus" To: "Stastny Richard" X-Spam-Score: 0.6 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465991768==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1465991768== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70369.3D8944E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70369.3D8944E7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I like the idea of narrowing the scope and name of the enumservice. Name = unused is much better than status (don't want this to be a presence = service :). =20 - klaus ________________________________ L=E4hett=E4j=E4: Stastny Richard [mailto:Richard.Stastny@oefeg.at] L=E4hetetty: ke 8.11.2006 20:59 Vastaanottaja: Ed Guy Kopio: enum@ietf.org; Livingood, Jason; lconroy; Otmar Lendl; = rich.shockey@NeuStar.biz Aihe: Re: [Enum] void-02 new version - new name: unused >What happens when a number is changed? On the PSTN, >the Caller would be given an intercept message like >"The number have have dialled has been changed.=20 >The new number is ".=20 >personally, I'd like to have this scenario result in an origination >feature that updates my address book. >Should this be in scope for the status indication? we should not overload void/status/etc with this issues - they may be handled with normal enumservices (such as announcement) I am starting to get problems with the new name status, because it seems to open up another can-of-worms of interpretations what about "unused" for both unallocated and unassigned that narrows the used better than status Richard ------_=_NextPart_001_01C70369.3D8944E7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Enum] void-02 new version - new name: = unused=0A= =0A= =0A= =0A=
=0A=
I like the = idea of narrowing the scope and name of the enumservice. Name unused is = much better than status (don't want this to be a presence service = :).
=0A=
 
=0A=
- klaus
=0A=

=0A=
=0A= L=E4hett=E4j=E4: Stastny Richard = [mailto:Richard.Stastny@oefeg.at]
L=E4hetetty: ke 8.11.2006 = 20:59
Vastaanottaja: Ed Guy
Kopio: enum@ietf.org; = Livingood, Jason; lconroy; Otmar Lendl; = rich.shockey@NeuStar.biz
Aihe: Re: [Enum] void-02 new version = - new name: unused

=0A=
=0A=

>What happens when a number is changed?  On = the PSTN,
>the Caller would be given an intercept message = like
>"The number have have dialled <X> has been = changed. 
>The new number is = <y>". 
>personally, I'd like to have this scenario = result in an origination
>feature that updates my address = book.
>Should this be in scope for the status = indication?

we should not overload void/status/etc
with this = issues - they may be handled with normal enumservices
(such as = announcement)

I am starting to get problems with the new name = status, because
it seems to open up another can-of-worms of = interpretations

what about "unused" for both unallocated and = unassigned
that narrows the used better than = status

Richard

------_=_NextPart_001_01C70369.3D8944E7-- --===============1465991768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1465991768==-- From enum-bounces@ietf.org Wed Nov 08 17:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvaS-0004Bo-Lk; Wed, 08 Nov 2006 17:08:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvaR-00049O-7Q for enum@ietf.org; Wed, 08 Nov 2006 17:07:59 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvaP-0006am-QO for enum@ietf.org; Wed, 08 Nov 2006 17:07:59 -0500 Received: from [130.129.64.175] (dhcp64-175.ietf67.org [130.129.64.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 12F054D458; Wed, 8 Nov 2006 23:07:43 +0100 (CET) Message-ID: <45525529.6050005@nic.at> Date: Wed, 08 Nov 2006 14:07:37 -0800 From: Otmar Lendl User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Alexander Mayrhofer Subject: Re: [Enum] requesting feedback on XMPP specific issues... References: <45511B4D.9010500@enum.at> In-Reply-To: <45511B4D.9010500@enum.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Alexander Mayrhofer wrote: > > 1) Authentication component: > > XMPP URIs may contain an authentication component, which instructs the > client to authenticate as the user id given in the URI, and then contact a > differen user id, eg. > > xmpp://alex@enum.at/office@enum.at > > would instruct the client to authenticate as "alex@enum.at", and then > contact "office@enum.at". > > I have now text in the draft that the output URI of this Enumservice SHOULD > NOT contain such an authentication component - there might be corner cases > where it could be useful, so i refrained from using MUST. What about just mentioning that issue in the Security Considerations section? I don't think we're in a position to issue SHOULD NOTs or MUST NOTs for this subject: I think it's good enough to make the reader aware that URIs can contain authentication data. After all, the same issue applies to http: and ftp: URIs as well. RFC4002 does not touch upon this at all. > 2) IRIs: > > XMPP supports IRIs (non-ASCII characters in the URI). However, non-ASCII > characters are always "percent-encoded", so the replacement part of the > regex string in the NAPTR should always contain ASCII only. However, the > regex algorithm _could_ be affected... > > I have currently no text about this issue in the draft. I have a strong > opinion against disallowing IRIs in this Enumservice, because if XMPP itself > supports them, a restriction here would limit the applicability of the > Enumservice to a subset of the potential users. (And, the XMPP clients which > support this Enumservice will need to support IRIs anyway to be compliant to > the XMPP URI spec). > > However, do we need some text about special considerations with regards to that? My approach here is that we need to clarify that the DDDS algorithm with its regexp evaluation happens before any IRI unescaping. In other words, the output of the ENUM algorithm is always an ASCII-encoded string. Whether that string is in fact an encoded IRI should not concern us. The ENUM client code (especially the regexp parts) need not be UTF-8 aware. /ol _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 17:12:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghve6-0000LM-E1; Wed, 08 Nov 2006 17:11:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghve4-0000HJ-PS for enum@ietf.org; Wed, 08 Nov 2006 17:11:44 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghvdz-0007MS-GS for enum@ietf.org; Wed, 08 Nov 2006 17:11:44 -0500 Received: from ([10.20.9.174]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27433756; Wed, 08 Nov 2006 17:11:21 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 17:11:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Wed, 8 Nov 2006 17:10:52 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020D52C9@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccCr6cjZCXsodXiR1GINR4Tk74X2wAAFcZQAAB4PNQAD0RqUAAE0EtTACAigOA= From: "Livingood, Jason" To: "Stastny Richard" , , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 08 Nov 2006 22:11:20.0630 (UTC) FILETIME=[D1F25560:01C70382] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I agree... :-) Jason=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, November 08, 2006 1:51 AM > To: Livingood, Jason; rich.shockey@NeuStar.biz; Otmar Lendl;=20 > Richard Shockey > Cc: enum@ietf.org > Subject: Re: [Enum] void-02 new version >=20 > The inactive status came from the discussion, but I also=20 > think this status is too dynamc and should not be put into DNS > =20 > Richard >=20 > ________________________________ >=20 > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Gesendet: Mi 08.11.2006 06:02 > An: Stastny Richard; rich.shockey@NeuStar.biz; Otmar Lendl;=20 > Richard Shockey > Cc: enum@ietf.org > Betreff: RE: [Enum] void-02 new version >=20 >=20 >=20 > > >unallocated (not existent) > > > > >unassigned (not existent) > > > > >inactive (inactive -=3D out-of-service- barred - etc) >=20 > I still don't understand how the inactive use case differs... >=20 > J >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 08 19:02:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxKd-0008TX-Nb; Wed, 08 Nov 2006 18:59:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxKb-0008IS-SF for enum@ietf.org; Wed, 08 Nov 2006 18:59:45 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhxKa-0001er-Et for enum@ietf.org; Wed, 08 Nov 2006 18:59:45 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id EC40E871DF; Wed, 8 Nov 2006 23:59:32 +0000 (GMT) In-Reply-To: <45AEC6EF95942140888406588E1A66020D52C9@PACDCEXCMB04.cable.comcast.com> References: <45AEC6EF95942140888406588E1A66020D52C9@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0BA8CB20-75A3-40E2-936D-977EA4360A88@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] void-02 new version Date: Wed, 8 Nov 2006 23:59:30 +0000 To: "Livingood, Jason" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: enum@ietf.org, Stastny Richard , Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, Unused is OK-ish, but I think I can see a reason to have an "unused" as well as other NAPTRs, in the same zone. Thus "unused" is not quite right. For example, in a zone there could be a SIP NAPTR, and H323 NAPTR, and an "unused" NAPTR. The Client can't talk H323, so it ignores that one. It can talk SIP so it tries that one, but if the negotiation within SIP fails, then the presence of the "unused" NAPTR indicates that the client should not bother trying to call via the PSTN as it won't work. Maybe "PSTN-unused" might avoid confusion - this doesn't say that the number has NO potential communication contacts, but that it doesn't have a "via PSTN" communications path. all the best, Lawrence On 8 Nov 2006, at 22:10, Livingood, Jason wrote: > I agree... :-) > > Jason > >> -----Original Message----- >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >> Sent: Wednesday, November 08, 2006 1:51 AM >> To: Livingood, Jason; rich.shockey@NeuStar.biz; Otmar Lendl; >> Richard Shockey >> Cc: enum@ietf.org >> Subject: Re: [Enum] void-02 new version >> >> The inactive status came from the discussion, but I also >> think this status is too dynamc and should not be put into DNS >> >> Richard >> >> ________________________________ >> >> Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >> Gesendet: Mi 08.11.2006 06:02 >> An: Stastny Richard; rich.shockey@NeuStar.biz; Otmar Lendl; >> Richard Shockey >> Cc: enum@ietf.org >> Betreff: RE: [Enum] void-02 new version >> >> >> >>>> unallocated (not existent) >>> >>>> unassigned (not existent) >>> >>>> inactive (inactive -= out-of-service- barred - etc) >> >> I still don't understand how the inactive use case differs... >> >> J >> >> >> > > _______________________________________________ > 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 enum-bounces@ietf.org Wed Nov 08 21:58:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi06o-0001DC-Vm; Wed, 08 Nov 2006 21:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi06n-0001D4-Og for enum@ietf.org; Wed, 08 Nov 2006 21:57:41 -0500 Received: from gw1.domain-registry.nl ([193.176.144.139] helo=gw.nic.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi06j-00087A-BU for enum@ietf.org; Wed, 08 Nov 2006 21:57:41 -0500 Received: (from root@localhost) by gw.nic.nl (8.9.3c/8.6.12) id DAA92159 for ; Thu, 9 Nov 2006 03:57:23 +0100 (CET) Received: by gw1.domain-registry.nl (TUNIX/Firewall SMTP Server) for id sma091967; Thu, 9 Nov 06 03:56:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Thu, 9 Nov 2006 03:56:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccDksq5TXfKdC2SSASM1rX9vw6CigAF3ufA From: "Antoin Verschuren" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: >=20 > Maybe "PSTN-unused" might avoid confusion - this doesn't say that the > number has NO potential communication contacts, but that it doesn't > have a "via PSTN" communications path. How about "NPT" (No PSTN Termination) Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 00:47:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2jb-0000dR-Vr; Thu, 09 Nov 2006 00:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2ja-0000dK-NQ for enum@ietf.org; Thu, 09 Nov 2006 00:45:54 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gi2jW-0004Jm-B8 for enum@ietf.org; Thu, 09 Nov 2006 00:45:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Thu, 9 Nov 2006 06:43:33 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccDksq5TXfKdC2SSASM1rX9vw6CigAF3ufAAAXt+Bo= References: From: "Stastny Richard" To: "Antoin Verschuren" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Void was not intended to talk only about PSTN terminations =20 It talks about that no number is allocated or assigned, regardless of technology =20 Richard ________________________________ Von: Antoin Verschuren [mailto:Antoin.Verschuren@sidn.nl] Gesendet: Do 09.11.2006 03:56 An: enum@ietf.org Betreff: RE: [Enum] void-02 new version lconroy wrote: > > Maybe "PSTN-unused" might avoid confusion - this doesn't say that the > number has NO potential communication contacts, but that it doesn't > have a "via PSTN" communications path. How about "NPT" (No PSTN Termination) Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/ _______________________________________________ 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 enum-bounces@ietf.org Thu Nov 09 05:42:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7LH-0002fV-Ku; Thu, 09 Nov 2006 05:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7LH-0002fP-28 for enum@ietf.org; Thu, 09 Nov 2006 05:41:07 -0500 Received: from ns1.nic.or.kr ([202.30.50.51] helo=mail.nic.or.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi7LE-0001Dm-C4 for enum@ietf.org; Thu, 09 Nov 2006 05:41:07 -0500 Received: from sr71 (localhost [127.0.0.1]) by mail.nic.or.kr (v3smtp 8.11.6.9/8.11.0) with ESMTP id kA9AeZB26830; Thu, 9 Nov 2006 19:40:36 +0900 (KST) From: "JoonHyung Lim" To: "'Otmar Lendl'" , "'Alexander Mayrhofer'" Subject: RE: [Enum] requesting feedback on XMPP specific issues... Date: Thu, 9 Nov 2006 02:40:34 -0800 Message-ID: <009f01c703eb$7f55b630$db32a8c0@sr71> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45525529.6050005@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccDgrfwcKbNQdftT32/9b4tV9Oj1QADDjwQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Basically, I also agree with this feedback now. I'm not compleletly sure that authentication component is not needed in XMPP enumservice in any case, and intended status of this document is "informational". For IRIs matter, I have similar case in Korea during the User ENUM trial. To use the Korean characters describing geographical location information in ENUM, we encoded the Korean character with base64 encoding method, and put it into the NAPTR RR. but, ENUM-aware client doesn't have to care about a any encoded data when it try to find a data, because ENUM-aware client just brings the data to another application that can decode the data to use. Even if there is "percent-encoding", I think disallowing the IRIs is unnecessary. JoonHyung Lim > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Wednesday, November 08, 2006 2:08 PM > To: Alexander Mayrhofer > Cc: enum@ietf.org > Subject: Re: [Enum] requesting feedback on XMPP specific issues... > > Alexander Mayrhofer wrote: > > > > 1) Authentication component: > > > > XMPP URIs may contain an authentication component, which > instructs the > > client to authenticate as the user id given in the URI, and then > > contact a differen user id, eg. > > > > xmpp://alex@enum.at/office@enum.at > > > > would instruct the client to authenticate as > "alex@enum.at", and then > > contact "office@enum.at". > > > > I have now text in the draft that the output URI of this > Enumservice > > SHOULD NOT contain such an authentication component - there > might be > > corner cases where it could be useful, so i refrained from > using MUST. > > What about just mentioning that issue in the Security > Considerations section? I don't think we're in a position to > issue SHOULD NOTs or MUST NOTs for this subject: I think it's > good enough to make the reader aware that URIs can contain > authentication data. After all, the same issue applies to > http: and ftp: URIs as well. RFC4002 does not touch upon this at all. > > > 2) IRIs: > > > > XMPP supports IRIs (non-ASCII characters in the URI). However, > > non-ASCII characters are always "percent-encoded", so the > replacement > > part of the regex string in the NAPTR should always contain ASCII > > only. However, the regex algorithm _could_ be affected... > > > > I have currently no text about this issue in the draft. I have a > > strong opinion against disallowing IRIs in this > Enumservice, because > > if XMPP itself supports them, a restriction here would limit the > > applicability of the Enumservice to a subset of the > potential users. > > (And, the XMPP clients which support this Enumservice will need to > > support IRIs anyway to be compliant to the XMPP URI spec). > > > > However, do we need some text about special considerations > with regards to that? > > My approach here is that we need to clarify that the DDDS > algorithm with its regexp evaluation happens before any IRI > unescaping. In other words, the output of the ENUM algorithm > is always an ASCII-encoded string. > > Whether that string is in fact an encoded IRI should not concern us. > The ENUM client code (especially the regexp parts) need not > be UTF-8 aware. > > /ol > > _______________________________________________ > 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 enum-bounces@ietf.org Thu Nov 09 06:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi83U-0007ex-M3; Thu, 09 Nov 2006 06:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi83U-0007ej-47 for enum@ietf.org; Thu, 09 Nov 2006 06:26:48 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi83R-0007Im-Et for enum@ietf.org; Thu, 09 Nov 2006 06:26:48 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id ADA3E8732E; Thu, 9 Nov 2006 11:26:44 +0000 (GMT) In-Reply-To: <009f01c703eb$7f55b630$db32a8c0@sr71> References: <009f01c703eb$7f55b630$db32a8c0@sr71> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <877F856C-5E8F-4B4A-BD92-2FB10B126DA1@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] requesting feedback on XMPP specific issues... Date: Thu, 9 Nov 2006 11:26:43 +0000 To: "JoonHyung Lim" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: enum@ietf.org, 'Alexander Mayrhofer' , 'Otmar Lendl' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi there folks, Did I miss something on the XMPP Enumservice specification? An Enumservice registration can't be Informational (I know - I argued that this clause was not needed when 3761 was being written). From RFC 3761: 3.1.4. Publication Requirements Proposals for Enumservices registrations MUST be published as one of the following documents; RFC on the Standards Track, Experimental RFC, or as a BCP. Informational is notably missing from this list. all the best, Lawrence On 9 Nov 2006, at 10:40, JoonHyung Lim wrote: > Basically, I also agree with this feedback now. > > I'm not compleletly sure that authentication component is not > needed in XMPP > enumservice in any case, and intended status of this document is > "informational". > > For IRIs matter, I have similar case in Korea during the User ENUM > trial. > > To use the Korean characters describing geographical location > information in > ENUM, we encoded the Korean character with base64 encoding method, > and put > it into the NAPTR RR. but, ENUM-aware client doesn't have to care > about a > any encoded data when it try to find a data, because ENUM-aware > client just > brings the data to another application that can decode the data to > use. Even > if there is "percent-encoding", I think disallowing the IRIs is > unnecessary. > > JoonHyung Lim > > >> -----Original Message----- >> From: Otmar Lendl [mailto:lendl@nic.at] >> Sent: Wednesday, November 08, 2006 2:08 PM >> To: Alexander Mayrhofer >> Cc: enum@ietf.org >> Subject: Re: [Enum] requesting feedback on XMPP specific issues... >> >> Alexander Mayrhofer wrote: >>> >>> 1) Authentication component: >>> >>> XMPP URIs may contain an authentication component, which >> instructs the >>> client to authenticate as the user id given in the URI, and then >>> contact a differen user id, eg. >>> >>> xmpp://alex@enum.at/office@enum.at >>> >>> would instruct the client to authenticate as >> "alex@enum.at", and then >>> contact "office@enum.at". >>> >>> I have now text in the draft that the output URI of this >> Enumservice >>> SHOULD NOT contain such an authentication component - there >> might be >>> corner cases where it could be useful, so i refrained from >> using MUST. >> >> What about just mentioning that issue in the Security >> Considerations section? I don't think we're in a position to >> issue SHOULD NOTs or MUST NOTs for this subject: I think it's >> good enough to make the reader aware that URIs can contain >> authentication data. After all, the same issue applies to >> http: and ftp: URIs as well. RFC4002 does not touch upon this at all. >> >>> 2) IRIs: >>> >>> XMPP supports IRIs (non-ASCII characters in the URI). However, >>> non-ASCII characters are always "percent-encoded", so the >> replacement >>> part of the regex string in the NAPTR should always contain ASCII >>> only. However, the regex algorithm _could_ be affected... >>> >>> I have currently no text about this issue in the draft. I have a >>> strong opinion against disallowing IRIs in this >> Enumservice, because >>> if XMPP itself supports them, a restriction here would limit the >>> applicability of the Enumservice to a subset of the >> potential users. >>> (And, the XMPP clients which support this Enumservice will need to >>> support IRIs anyway to be compliant to the XMPP URI spec). >>> >>> However, do we need some text about special considerations >> with regards to that? >> >> My approach here is that we need to clarify that the DDDS >> algorithm with its regexp evaluation happens before any IRI >> unescaping. In other words, the output of the ENUM algorithm >> is always an ASCII-encoded string. >> >> Whether that string is in fact an encoded IRI should not concern us. >> The ENUM client code (especially the regexp parts) need not >> be UTF-8 aware. >> >> /ol >> >> _______________________________________________ >> 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 enum-bounces@ietf.org Thu Nov 09 08:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9ew-00063G-8H; Thu, 09 Nov 2006 08:09:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsS0-0006Gb-SA for enum@ietf.org; Wed, 08 Nov 2006 13:47:04 -0500 Received: from emcsw.com ([69.28.242.167] helo=www.eguy.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsRy-0008NY-Po for enum@ietf.org; Wed, 08 Nov 2006 13:47:04 -0500 Received: from dhcp66-182.ietf67.org ([130.129.66.182]:54520) by www.eguy.org with esmtpsa (SSL 3.0:RSA_ARCFOUR_MD5:16) (Exim 4.50) id 1GhsPR-0003vf-0S; Wed, 08 Nov 2006 13:44:26 -0500 Subject: Re: [Enum] void-02 new version From: Ed Guy To: Stastny Richard In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BE3@oefeg-s04.oefeg.loc> References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc> <32755D354E6B65498C3BD9FD496C7D462C4BE3@oefeg-s04.oefeg.loc> Date: Wed, 08 Nov 2006 13:43:32 -0500 Message-Id: <1163011412.30540.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Spam-Score: 0.7 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 X-Mailman-Approved-At: Thu, 09 Nov 2006 08:09:32 -0500 Cc: enum@ietf.org, "Livingood, Jason" , lconroy , Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2128683872==" Errors-To: enum-bounces@ietf.org --===============2128683872== Content-Type: multipart/alternative; boundary="=-JrQ++Xg4QpT8mM+hdPbZ" --=-JrQ++Xg4QpT8mM+hdPbZ Content-Type: text/plain Content-Transfer-Encoding: 7bit On the void/status indications, the originator needs to stop the call in all of these cases, but the issue is "what indication to they give to the calling party?" On unassigned vs unallocated: If a well-formed number has not yet been allocated by the NRA or assigned by one of its delegates, the handling might be the same. Why is the national regulator special? any domain may be delegated. (so, two designations are not needed) on Out of service: If the services associated with a number is out of order, there is an opportunity to push this status to the originating side, foregoing SIP timeouts. the TTL would need to be very short. We should consider what happens in open dialing plans where a dialled number may be too short. (it's possible I missed this discussion in this email chain). and also, What happens when a number is changed? On the PSTN, the Caller would be given an intercept message like "The number have have dialled has been changed. The new number is ". personally, I'd like to have this scenario result in an origination feature that updates my address book. Should this be in scope for the status indication? /ed On Wed, 2006-11-08 at 16:22 +0100, Stastny Richard wrote: > that why I proposed to use vacant/void/status as ENUMservice > and put the rest in the text/data > > The originator does not need to look in the URI during call setup > (as it was with void), he simple stops the call > > Richard > > ________________________________ > > Von: lconroy [mailto:lconroy@insensate.co.uk] > Gesendet: Mi 08.11.2006 16:12 > An: Stastny Richard > Cc: Livingood, Jason; rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org > Betreff: Re: [Enum] void-02 new version > > > > Hi Richard, folks, > Absolutely agree that it doesn't matter to the originator. > But if the real difference between these two cases is whether the NRA > or the SP > controls the zone and provisions the Vacant/Void/Status/... NAPTR, > then why do > we need both Unallocated and Unassigned? > How does this make a difference to the originating ENUM client? > > all the best, > Lawrence > > On 8 Nov 2006, at 14:57, Stastny Richard wrote: > >> Who/What controls the zone may be important information. > > > > maybe, but not for the originator during the call > > > > Richard > > > > ________________________________ > > > > Von: lconroy [mailto:lconroy@insensate.co.uk] > > Gesendet: Mi 08.11.2006 09:27 > > An: Livingood, Jason > > Cc: rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org; Stastny > > Richard > > Betreff: Re: [Enum] void-02 new version > > > > > > > > Hi Jason, folks, > > This is exactly one of my issues. As Jason says below, these first > > two cases seem to differ in who is controlling the zone. > > > > "Unallocated" means the NRA still controls the zone (as then have not > > put a TN in service). > > > > In the "Unassigned" case, the SP controls the zone (as the SP has not > > put a TN into service). > > > > This last "Inactive" case seems to imply this as well, but only makes > > sense if it takes a long time to make a TN active. Otherwise why > > bother > > provisioning this status? > > > > Who/What controls the zone may be important information. > > > > all the best, > > Lawrence > > > > On 8 Nov 2006, at 05:02, Livingood, Jason wrote: > >>> PLEASE PLEASE... I think we had consensus here. The initial > >>> use case for this ID surrounds 3 conditions as Richard noted. > >>> > >>> unallocated (not existent) > >>> > >>> unassigned (not existent) > >>> > >>> inactive (inactive -= out-of-service- barred - etc) > >> > >> Well, hold on just a second. I thought we had consensus on the first > >> two use cases. Where did the 3rd one above come from? Can someone > >> please describe the specific use case and how that is noticeably > >> different from the first two? In the first the NRA has not put a > >> TN in > >> service, and in the second the SP has not done so. So in the third, > >> what party are we talking about? > > > > > > > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum --=-JrQ++Xg4QpT8mM+hdPbZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On the void/status indications, the originator needs to stop
the call in all of these cases, but the issue is
"what indication to they give to the calling party?"

On unassigned vs unallocated:
If a well-formed number has not yet been allocated by the NRA or
assigned by one of its delegates,  the handling might be the same.  
Why is the national regulator special?  any domain may be delegated.
(so, two designations are not needed)

on Out of service:
If the services associated with a number is out of order, there is an
opportunity to push this status to the originating side, foregoing
SIP timeouts. the  TTL would need to be very short.


We should consider what happens in open dialing plans
where a dialled number may be too short.
(it's possible I missed this discussion in this email chain).

and also,

What happens when a number is changed?  On the PSTN,
the Caller would be given an intercept message like
"The number have have dialled <X> has been changed. 
The new number is <y>". 
personally, I'd like to have this scenario result in an origination
feature that updates my address book.
Should this be in scope for the status indication?


/ed





On Wed, 2006-11-08 at 16:22 +0100, Stastny Richard wrote: 
that why I proposed to use vacant/void/status as ENUMservice
and put the rest in the text/data

The originator does not need to look in the URI during call setup
(as it was with void), he simple stops the call

Richard

________________________________

Von: lconroy [mailto:lconroy@insensate.co.uk]
Gesendet: Mi 08.11.2006 16:12
An: Stastny Richard
Cc: Livingood, Jason; rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org
Betreff: Re: [Enum] void-02 new version



Hi Richard, folks,
  Absolutely agree that it doesn't matter to the originator.
But if the real difference between these two cases is whether the NRA 
or the SP
controls the zone and provisions the Vacant/Void/Status/... NAPTR, 
then why do
we need both Unallocated and Unassigned?
How does this make a difference to the originating ENUM client?

all the best,
   Lawrence

On 8 Nov 2006, at 14:57, Stastny Richard wrote:
>> Who/What controls the zone may be important information.
>
> maybe, but not for the originator during the call
>
> Richard
>
> ________________________________
>
> Von: lconroy [mailto:lconroy@insensate.co.uk]
> Gesendet: Mi 08.11.2006 09:27
> An: Livingood, Jason
> Cc: rich.shockey@NeuStar.biz; Otmar Lendl; enum@ietf.org; Stastny 
> Richard
> Betreff: Re: [Enum] void-02 new version
>
>
>
> Hi Jason, folks,
>   This is exactly one of my issues. As Jason says below, these first
> two cases seem to differ in who is controlling the zone.
>
> "Unallocated" means the NRA still controls the zone (as then have not
> put a TN in service).
>
> In the "Unassigned" case, the SP controls the zone (as the SP has not
> put a TN into service).
>
> This last "Inactive" case seems to imply this as well, but only makes
> sense if it takes a long time to make a TN active. Otherwise why 
> bother
> provisioning this status?
>
> Who/What controls the zone may be important information.
>
> all the best,
>    Lawrence
>
> On 8 Nov 2006, at 05:02, Livingood, Jason wrote:
>>> PLEASE PLEASE... I think we had consensus here. The initial
>>> use case for this ID surrounds 3 conditions as Richard noted.
>>>
>>> unallocated (not existent)
>>>
>>> unassigned (not existent)
>>>
>>> inactive (inactive -= out-of-service- barred - etc)
>>
>> Well, hold on just a second.  I thought we had consensus on the first
>> two use cases.  Where did the 3rd one above come from?  Can someone
>> please describe the specific use case and how that is noticeably
>> different from the first two?  In the first the NRA has not put a
>> TN in
>> service, and in the second the SP has not done so.  So in the third,
>> what party are we talking about?
>
>
>




_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum
--=-JrQ++Xg4QpT8mM+hdPbZ-- --===============2128683872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2128683872==-- From enum-bounces@ietf.org Thu Nov 09 08:12:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9hm-00081x-Mr; Thu, 09 Nov 2006 08:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9BC-0007hK-Rh; Thu, 09 Nov 2006 07:38:50 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi9BC-0001VM-87; Thu, 09 Nov 2006 07:38:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kA9CccNr005971; Thu, 9 Nov 2006 14:38:38 +0200 Date: Thu, 9 Nov 2006 14:38:38 +0200 (EET) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2178/Thu Nov 9 02:08:09 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-Mailman-Approved-At: Thu, 09 Nov 2006 08:12:29 -0500 Cc: enum@ietf.org, enum-chairs@tools.ietf.org Subject: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' to Informational RFC (draft-ietf-enum-infrastructure-enum-reqs) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Tue, 31 Oct 2006, The IESG wrote: > - 'Infrastrucure ENUM Requirements ' > as an Informational > RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-30. I'm a bit wary of using upper-case keywords in requirements documents such as this, but I personally don't have a major issue with it because it hopefully doesn't cause much confusion between "protocol requirements" and "operational requirements". Some detailed comments below, substantial ----------- 2. Queries of infrastructure ENUM fully qualified domain names MUST return a result, even if the result is a Name Error (RCODE = 3). Queries must not be rejected, e.g., based on access control lists. ==> the example with RCODE=3 is maybe not the best one. Rather or at the very least, you should also mention RCODE=5 (Refused, e.g., for policy reasons) which might be much more applicable than Name Error. Actually, maybe this could call for another requirement such as: 'Queries for existing names MUST NOT be responded with Name Error (RCODE=3)'.. because this would balkanize the name space, where from one point in the Internet the authoritative answer would be "name does not exist" and from another, "name exists". Or is there already consensus that it's OK to create a split-view DNS for information that's supposed to be publicly available? 5. Implementation of Infrastructure ENUM MUST NOT restrict the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM registrations. ==> you mention 'Tier 2 name server provider' but it isn't clear what this means. Would adding a reference help? Or are you already assuming certain kind of name server architecture? ==> it wasn't 100% clear what 'end-user ENUM registrations' means, also because this is pretty close to 'user ENUM ...'. The ability to select who's controlling selected parts of its ENUM mapping ("selecting the provider of the ENUM registration")? The ability of the user to register records of its own liking to its number ("ability to control the contents of the ENUM registration")? I think you meant the former; should the latter also be a requirement? 6. Infrastructure ENUM SHALL be implemented under a top level domain that can support reliability and performance suitable for PSTN/ PLMN applications. ==> this seems like a NOP requirement, given that you don't describe or give reference what those reliability or performance requirements are. What are the real requirements? Is it believed that some top level domains could not satisfy these? If not, this requirement doesn't seem to be useful. 8. Proposed implementations of Infrastructure ENUM SHOULD: C. Restrict the need for any additional resolver functionality to service provider resolvers. ==> you say this about service provider resolvers, but nothing about resolvers at large. Maybe make these explicit: - Service provider resolvers should not be required to have additional functionality - Resolvers at large must not be required to have additional functionality E. Minimize the client knowledge of the numbering plan required. ==> I'd go farther than saying 'minimize' as the clients who use this information should be expected to have zero knowledge of numbering plans. This seems like a big NO-NO. Or are you referring to service provider resolvers with 'client' here? While that might be acceptable as a performance optimization, I dislike even that. 4. Security Considerations ==> you mention user privacy concerns, but I'd also briefly mention (1-2 sentences) the requirement for the user to prevent or restrict number->username mapping information as you already mentioned in requirement 7. editorial --------- 2.1. Definition Infrastructure ENUM is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to map a telephone number into a URI [4] that identifies a specific point of interconnection to that service provider's network that could enable the originating party to establish communication with the associated terminating party. ==> that's a relatively long and complex sentence to start with. Could it be possible to rephrase it a bit? Also it might be useful to s/carrier-of-record/carrier-of-record (as defined below)/; it wasn't first obvious to me where "carrier-of-record" is described. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 08:53:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiAJH-0001is-1v; Thu, 09 Nov 2006 08:51:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiAJF-0001if-Ml; Thu, 09 Nov 2006 08:51:13 -0500 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiAJD-0002D7-Az; Thu, 09 Nov 2006 08:51:13 -0500 Received: from [195.54.244.2] (account jim HELO [172.16.1.100]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 110570; Thu, 09 Nov 2006 13:50:59 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16D8F43F-C721-4733-B553-3E694532D56C@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' to Informational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Thu, 9 Nov 2006 13:50:59 +0000 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Nov 9, 2006, at 12:38, Pekka Savola wrote: > 6. Infrastructure ENUM SHALL be implemented under a top level > domain > that can support reliability and performance suitable for > PSTN/PLMN > applications. > > ==> this seems like a NOP requirement, given that you don't describe > or give reference what those reliability or performance requirements > are. What are the real requirements? Is it believed that some top > level domains could not satisfy these? If not, this requirement > doesn't seem to be useful. Indeed. I wonder why "top level domain" gets mentioned at all. There's nothing magical or special about Infrastructure ENUM that requires or justifies the creation of a TLD. It would be best to avoid opening up that layer-9 rat-hole in the ICANN/IANA/DoC world. Besides, didn't RFC3172 decree infrastructure domains live under .arpa? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 09:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiApN-0002bw-6h; Thu, 09 Nov 2006 09:24:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiApM-0002br-1t for enum@ietf.org; Thu, 09 Nov 2006 09:24:24 -0500 Received: from dakota.ucd.ie ([193.1.169.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiApI-0007Gj-LR for enum@ietf.org; Thu, 09 Nov 2006 09:24:24 -0500 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) id <0J8G00601VHQE600@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for enum@ietf.org; Thu, 09 Nov 2006 14:18:29 +0000 (GMT) Received: from [89.127.166.214] by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPSA id <0J8G0022JVQS2Z90@dakota.ucd.ie>; Thu, 09 Nov 2006 14:18:29 +0000 (GMT) Date: Thu, 09 Nov 2006 14:18:41 +0000 From: Niall O'Reilly Subject: Re: [Enum] void-02 new version In-reply-to: <1163011412.30540.26.camel@localhost> To: Ed Guy Message-id: <135EC3EE-E440-4D9E-8712-3767A7467CA2@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Gpgmail-State: !signed References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc> <32755D354E6B65498C3BD9FD496C7D462C4BE3@oefeg-s04.oefeg.loc> <1163011412.30540.26.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: enum@ietf.org, Otmar Lendl , Niall O'Reilly , lconroy , rich.shockey@NeuStar.biz, Stastny Richard , "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 8 Nov 2006, at 18:43, Ed Guy wrote: > on Out of service: > If the services associated with a number is out of order, there is an > opportunity to push this status to the originating side, foregoing > SIP timeouts. the TTL would need to be very short. AFAICS, this would be a per-service (rather than per-number) situation. Wouldn't that be beyond the scope of void/status/unused? /Niall _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 09:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBIl-0000O2-Q4; Thu, 09 Nov 2006 09:54:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBIk-0000Nh-Ms for enum@ietf.org; Thu, 09 Nov 2006 09:54:46 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiBIj-00033w-C0 for enum@ietf.org; Thu, 09 Nov 2006 09:54:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Thu, 9 Nov 2006 15:53:29 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccECqVmQILGX+yvSZ2yOuRR73bDSQABCxlp References: <45AEC6EF95942140888406588E1A66020D52BD@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4BE2@oefeg-s04.oefeg.loc> <32755D354E6B65498C3BD9FD496C7D462C4BE3@oefeg-s04.oefeg.loc> <1163011412.30540.26.camel@localhost> <135EC3EE-E440-4D9E-8712-3767A7467CA2@ucd.ie> From: "Stastny Richard" To: "Niall O'Reilly" , "Ed Guy" X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: enum@ietf.org, Otmar Lendl , lconroy , "Livingood, Jason" , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Exactly =20 Richard ________________________________ Von: Niall O'Reilly [mailto:Niall.oReilly@ucd.ie] Gesendet: Do 09.11.2006 15:18 An: Ed Guy Cc: Niall O'Reilly; Stastny Richard; enum@ietf.org; Livingood, Jason; = lconroy; Otmar Lendl; rich.shockey@NeuStar.biz Betreff: Re: [Enum] void-02 new version On 8 Nov 2006, at 18:43, Ed Guy wrote: > on Out of service: > If the services associated with a number is out of order, there is an > opportunity to push this status to the originating side, foregoing > SIP timeouts. the TTL would need to be very short. AFAICS, this would be a per-service (rather than per-number) situation. Wouldn't that be beyond the scope of void/status/unused? /Niall _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 12:30:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDik-0003G1-Uq; Thu, 09 Nov 2006 12:29:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDij-0003DV-Ej; Thu, 09 Nov 2006 12:29:45 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiDii-0002eb-6J; Thu, 09 Nov 2006 12:29:45 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1163093374!10224581!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 32045 invoked from network); 9 Nov 2006 17:29:34 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-12.tower-121.messagelabs.com with SMTP; 9 Nov 2006 17:29:34 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9HTYdj017795; Thu, 9 Nov 2006 12:29:34 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9HTJnV017686; Thu, 9 Nov 2006 12:29:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Thu, 9 Nov 2006 12:29:14 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E114538@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <16D8F43F-C721-4733-B553-3E694532D56C@rfc1035.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Thread-Index: AccEBosL3hbReq29TeK0dD3+36a7dQAHU3Lw From: "Pfautz, Penn L, GBLAM" To: "Jim Reid" , "Pekka Savola" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Jim: Just to be clear - we were not looking for a new TLD for infrastructure ENUM. The authors of this draft would be happy to see the infrastructure ENUM apex under .arpa. However, there may be other parties involved (note that the ITU-T has yet to accept e164.arpa for user ENUM beyond interim status.) We'd be happy with an apex domain that meets the necessary performance requirements.=20 Penn Pfautz -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com]=20 Sent: Thursday, November 09, 2006 8:51 AM To: Pekka Savola Cc: enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs)=20 On Nov 9, 2006, at 12:38, Pekka Savola wrote: > 6. Infrastructure ENUM SHALL be implemented under a top level =20 > domain > that can support reliability and performance suitable for =20 > PSTN/PLMN > applications. > > =3D=3D> this seems like a NOP requirement, given that you don't = describe > or give reference what those reliability or performance requirements > are. What are the real requirements? Is it believed that some top > level domains could not satisfy these? If not, this requirement > doesn't seem to be useful. Indeed. I wonder why "top level domain" gets mentioned at all. =20 There's nothing magical or special about Infrastructure ENUM that =20 requires or justifies the creation of a TLD. It would be best to =20 avoid opening up that layer-9 rat-hole in the ICANN/IANA/DoC world. =20 Besides, didn't RFC3172 decree infrastructure domains live under .arpa? _______________________________________________ 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 enum-bounces@ietf.org Thu Nov 09 16:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHQI-00060T-EY; Thu, 09 Nov 2006 16:26:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHQG-00060B-Jp for enum@ietf.org; Thu, 09 Nov 2006 16:26:56 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHQF-00066S-Aj for enum@ietf.org; Thu, 09 Nov 2006 16:26:56 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 09 Nov 2006 22:26:50 +0100 id 0000001E.45539D1A.00004A4E Message-ID: <45539C80.5000706@enum.at> Date: Thu, 09 Nov 2006 22:24:16 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] requesting feedback on XMPP specific issues... References: <009f01c703eb$7f55b630$db32a8c0@sr71> <877F856C-5E8F-4B4A-BD92-2FB10B126DA1@insensate.co.uk> In-Reply-To: <877F856C-5E8F-4B4A-BD92-2FB10B126DA1@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: enum@ietf.org, 'Otmar Lendl' , JoonHyung Lim X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi there folks, > Did I miss something on the XMPP Enumservice specification? > > An Enumservice registration can't be Informational (I know - I argued > that this clause was not needed when 3761 was being written). That is an error in the document, of course. Sorry for the confusion. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 16:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHUT-00013g-PC; Thu, 09 Nov 2006 16:31:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHUS-00012v-6K for enum@ietf.org; Thu, 09 Nov 2006 16:31:16 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHUQ-0006zD-T2 for enum@ietf.org; Thu, 09 Nov 2006 16:31:16 -0500 Received: from [130.129.70.160] (dhcp70-160.ietf67.org [::ffff:130.129.70.160]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 09 Nov 2006 22:31:09 +0100 id 0000001E.45539E1E.00004B83 Message-ID: <45539D80.10906@enum.at> Date: Thu, 09 Nov 2006 22:28:32 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JoonHyung Lim Subject: Re: [Enum] requesting feedback on XMPP specific issues... References: <009f01c703eb$7f55b630$db32a8c0@sr71> In-Reply-To: <009f01c703eb$7f55b630$db32a8c0@sr71> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: enum@ietf.org, 'Otmar Lendl' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org JoonHyung Lim wrote: > Basically, I also agree with this feedback now. > > I'm not compleletly sure that authentication component is not needed in XMPP > enumservice in any case, and intended status of this document is > "informational". > > For IRIs matter, I have similar case in Korea during the User ENUM trial. > > To use the Korean characters describing geographical location information in > ENUM, we encoded the Korean character with base64 encoding method, and put > it into the NAPTR RR. but, ENUM-aware client doesn't have to care about a > any encoded data when it try to find a data, because ENUM-aware client just > brings the data to another application that can decode the data to use. Even > if there is "percent-encoding", I think disallowing the IRIs is unnecessary. Well, at least for IRIs, there is a standardized procedure to map them to URIs. It is outlined in Section 3.1 of RFC 3987. I will have text in the next revision of the draft that this procedure should be followed when using IRIs with ENUM. But: It seems to be rather "hacky" to use base64 for encoding of URIs in ENUM, unless the URI is a "data" URI, which actually supports base64 encoding afaik. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 17:59:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIqW-00087V-BA; Thu, 09 Nov 2006 17:58:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIqU-00087N-7q; Thu, 09 Nov 2006 17:58:06 -0500 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIqS-0001lM-Sl; Thu, 09 Nov 2006 17:58:06 -0500 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 110651; Thu, 09 Nov 2006 22:58:03 +0000 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0E114538@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A0E114538@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Thu, 9 Nov 2006 22:58:02 +0000 To: "Pfautz, Penn L, GBLAM" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, Pekka Savola , iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Nov 9, 2006, at 17:29, Pfautz, Penn L, GBLAM wrote: > Just to be clear - we were not looking for a new TLD for > infrastructure > ENUM. The authors of this draft would be happy to see the > infrastructure > ENUM apex under .arpa. However, there may be other parties involved > (note that the ITU-T has yet to accept e164.arpa for user ENUM beyond > interim status.) We'd be happy with an apex domain that meets the > necessary performance requirements. I am sure that's the case. However the text in the draft doesn't say so. At least not clearly enough IMO. The current wording can (and will in some circles) be interpreted as meaning Infrastructure ENUM needs its own TLD. Just delete the words "top level" from the text and we're done. ie: 6. Infrastructure ENUM SHALL be implemented under a domain that can support reliability and performance suitable for PSTN/PLMN applications. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 09 19:44:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKUl-0007hC-M4; Thu, 09 Nov 2006 19:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKUk-0007f8-I4 for enum@ietf.org; Thu, 09 Nov 2006 19:43:46 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKUj-0007Ih-3w for enum@ietf.org; Thu, 09 Nov 2006 19:43:46 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 21013876AC; Fri, 10 Nov 2006 00:43:34 +0000 (GMT) In-Reply-To: <45539D80.10906@enum.at> References: <009f01c703eb$7f55b630$db32a8c0@sr71> <45539D80.10906@enum.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58DD5B40-DDB8-4CFF-AE0C-0C99521596AE@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] requesting feedback on XMPP specific issues... Date: Fri, 10 Nov 2006 00:43:33 +0000 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: enum@ietf.org, 'Otmar Lendl' , JoonHyung Lim X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, See section 3.1 of draft-ietf-experiences-04.txt. Bottom of page 7 et.seq. (Been there, seen it, done it :). Using the IRI to URI conversion rules is a MUST, not a SHOULD, or you will break perfectly valid conforming client programs. Agree - If this is in a NAPTR, then it generates a URI, No? The only legal choice if you MUST use an E2U NAPTR is to put the "stuff" inside a data: URI. Why not use a TXT record? That takes multiple strings, each of which can contain up to 255 octets of binary data - TXT looks like it will work fine for your needs. Note - IRIs are *not* permitted in 3761 as specified - only URIs. Just a block of Base64 encoded data instead of a URI is certainly not permitted. Bad things may happen to a valid conforming ENUM client if it hits this "NAPTR". (At least use an experimental Enumservice (X-xxxx) to tell foreign clients to ignore these NAPTRs). all the best, Lawrence On 9 Nov 2006, at 21:28, Alexander Mayrhofer wrote: > JoonHyung Lim wrote: >> Basically, I also agree with this feedback now. >> >> I'm not compleletly sure that authentication component is not >> needed in XMPP >> enumservice in any case, and intended status of this document is >> "informational". >> >> For IRIs matter, I have similar case in Korea during the User ENUM >> trial. >> >> To use the Korean characters describing geographical location >> information in >> ENUM, we encoded the Korean character with base64 encoding method, >> and put >> it into the NAPTR RR. but, ENUM-aware client doesn't have to care >> about a >> any encoded data when it try to find a data, because ENUM-aware >> client just >> brings the data to another application that can decode the data to >> use. Even >> if there is "percent-encoding", I think disallowing the IRIs is >> unnecessary. > > Well, at least for IRIs, there is a standardized procedure to map > them to > URIs. It is outlined in Section 3.1 of RFC 3987. I will have text > in the > next revision of the draft that this procedure should be followed > when using > IRIs with ENUM. > > But: It seems to be rather "hacky" to use base64 for encoding of > URIs in > ENUM, unless the URI is a "data" URI, which actually supports base64 > encoding afaik. > > Alex > > _______________________________________________ > 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 enum-bounces@ietf.org Fri Nov 10 11:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYsT-0002rH-KH; Fri, 10 Nov 2006 11:05:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLNt-0002Jm-RO; Thu, 09 Nov 2006 20:40:45 -0500 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLNs-0005iW-Gd; Thu, 09 Nov 2006 20:40:45 -0500 Received: from [10.0.1.3] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id kAA1gEpP018270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Nov 2006 17:42:14 -0800 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0E114538@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A0E114538@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D8C403F-6CA3-45AD-8CCB-42304BE10B6B@icann.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Thu, 9 Nov 2006 17:40:18 -0800 To: "Pfautz, Penn L, GBLAM" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Fri, 10 Nov 2006 11:05:12 -0500 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, Jim Reid , Pekka Savola , iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Penn, > However, there may be other parties involved > (note that the ITU-T has yet to accept e164.arpa for user ENUM beyond > interim status.) We'd be happy with an apex domain that meets the > necessary performance requirements. What performance requirements beyond those defined in RFC 3172 (which basically just applies 2870 to .ARPA) are necessary? Thanks, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 11:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZiR-0000am-Ks; Fri, 10 Nov 2006 11:58:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZiQ-0000aY-57 for enum@ietf.org; Fri, 10 Nov 2006 11:58:54 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiZiO-0007Ti-Jp for enum@ietf.org; Fri, 10 Nov 2006 11:58:54 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20061110165846m1100nasl4e>; Fri, 10 Nov 2006 16:58:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAAGwjQg011671 for ; Fri, 10 Nov 2006 11:58:45 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAAGwjOT011667; Fri, 10 Nov 2006 11:58:45 -0500 Date: Fri, 10 Nov 2006 11:58:45 -0500 Message-Id: <200611101658.kAAGwjOT011667@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: (jim@rfc1035.com) Subject: Re: [Enum] wildcards References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> <45512A8D.6030500@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDE@oefeg-s04.oefeg.loc> X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: Jim Reid My views about DNS wildcarding are well known and don't need to be repeated here. Putting text in the draft that says "you can do this with wildcards" is just bad. I'm starting to notice that DNS wildcards seem to almost solve some interesting problems, except they don't. One that we've been looking into is for an organization to set up its own internal ENUM tree containing only record that forward ENUM lookups to appropriate external ENUM trees. This allows the organization to, say, by default route everything to a service provider's private ENUM tree, extract subtrees to be routed via the internal network, extract other subtrees to be routed to a different service provider, etc. It would seem that the way to do this is to set up DNS wildcard NAPTRs at the root of each subtree which is treated differently from its containing subtree. As another case, there is a proposal at this IETF to insert special DNS records at the root of each national ENUM subtree. It would be wonderful if a query for that record type, directed to an ENUM domain name, would return the nearest record going up the tree, and wildcards would seem to be the way to do this. Except that DNS wildcards don't work this way -- the effect of a wildcard on a domain name "under" it is canceled if there is any DNS record for any of the intermediate domains. What I'm hoping is that there's a known solution for this problem, of getting "the FOO record for this domain or the nearest ancestor record that has a FOO record". Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 11:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZid-0000lv-Uv; Fri, 10 Nov 2006 11:59:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org From enum-bounces@ietf.org Fri Nov 10 11:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZiR-0000am-Ks; Fri, 10 Nov 2006 11:58:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZiQ-0000aY-57 for enum@ietf.org; Fri, 10 Nov 2006 11:58:54 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiZiO-0007Ti-Jp for enum@ietf.org; Fri, 10 Nov 2006 11:58:54 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20061110165846m1100nasl4e>; Fri, 10 Nov 2006 16:58:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAAGwjQg011671 for ; Fri, 10 Nov 2006 11:58:45 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAAGwjOT011667; Fri, 10 Nov 2006 11:58:45 -0500 Date: Fri, 10 Nov 2006 11:58:45 -0500 Message-Id: <200611101658.kAAGwjOT011667@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: (jim@rfc1035.com) Subject: Re: [Enum] wildcards References: <00ed01c702cb$210dfd10$68418182@cis.neustar.com> <45512A8D.6030500@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDE@oefeg-s04.oefeg.loc> X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: Jim Reid My views about DNS wildcarding are well known and don't need to be repeated here. Putting text in the draft that says "you can do this with wildcards" is just bad. I'm starting to notice that DNS wildcards seem to almost solve some interesting problems, except they don't. One that we've been looking into is for an organization to set up its own internal ENUM tree containing only record that forward ENUM lookups to appropriate external ENUM trees. This allows the organization to, say, by default route everything to a service provider's private ENUM tree, extract subtrees to be routed via the internal network, extract other subtrees to be routed to a different service provider, etc. It would seem that the way to do this is to set up DNS wildcard NAPTRs at the root of each subtree which is treated differently from its containing subtree. As another case, there is a proposal at this IETF to insert special DNS records at the root of each national ENUM subtree. It would be wonderful if a query for that record type, directed to an ENUM domain name, would return the nearest record going up the tree, and wildcards would seem to be the way to do this. Except that DNS wildcards don't work this way -- the effect of a wildcard on a domain name "under" it is canceled if there is any DNS record for any of the intermediate domains. What I'm hoping is that there's a known solution for this problem, of getting "the FOO record for this domain or the nearest ancestor record that has a FOO record". Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 11:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZid-0000lv-Uv; Fri, 10 Nov 2006 11:59:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZic-0000k4-IR; Fri, 10 Nov 2006 11:59:06 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiZia-0007VN-Aa; Fri, 10 Nov 2006 11:59:06 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-146.messagelabs.com!1163177941!8841918!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28869 invoked from network); 10 Nov 2006 16:59:01 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-9.tower-146.messagelabs.com with SMTP; 10 Nov 2006 16:59:01 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAAGx0Im001355; Fri, 10 Nov 2006 11:59:01 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAAGwr95001286; Fri, 10 Nov 2006 11:58:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Fri, 10 Nov 2006 11:58:51 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E14A400@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Thread-Index: AccEUoou8ydxR4CIQj+1kHe95rcY0wAlunIg From: "Pfautz, Penn L, GBLAM" To: "Jim Reid" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, Pekka Savola , iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Will do. Thanks for helping my clarify. Penn=20 -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com]=20 Sent: Thursday, November 09, 2006 5:58 PM To: Pfautz, Penn L, GBLAM Cc: Pekka Savola; enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs)=20 On Nov 9, 2006, at 17:29, Pfautz, Penn L, GBLAM wrote: > Just to be clear - we were not looking for a new TLD for =20 > infrastructure > ENUM. The authors of this draft would be happy to see the =20 > infrastructure > ENUM apex under .arpa. However, there may be other parties involved > (note that the ITU-T has yet to accept e164.arpa for user ENUM beyond > interim status.) We'd be happy with an apex domain that meets the > necessary performance requirements. I am sure that's the case. However the text in the draft doesn't say =20 so. At least not clearly enough IMO. The current wording can (and =20 will in some circles) be interpreted as meaning Infrastructure ENUM =20 needs its own TLD. Just delete the words "top level" from the text =20 and we're done. ie: 6. Infrastructure ENUM SHALL be implemented under a domain that can =20 support reliability and performance suitable for PSTN/PLMN =20 applications. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum with esmtp (Exim 4.43) id 1GiZic-0000k4-IR; Fri, 10 Nov 2006 11:59:06 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiZia-0007VN-Aa; Fri, 10 Nov 2006 11:59:06 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-146.messagelabs.com!1163177941!8841918!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28869 invoked from network); 10 Nov 2006 16:59:01 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-9.tower-146.messagelabs.com with SMTP; 10 Nov 2006 16:59:01 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAAGx0Im001355; Fri, 10 Nov 2006 11:59:01 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAAGwr95001286; Fri, 10 Nov 2006 11:58:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Fri, 10 Nov 2006 11:58:51 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E14A400@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Thread-Index: AccEUoou8ydxR4CIQj+1kHe95rcY0wAlunIg From: "Pfautz, Penn L, GBLAM" To: "Jim Reid" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, Pekka Savola , iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Will do. Thanks for helping my clarify. Penn=20 -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com]=20 Sent: Thursday, November 09, 2006 5:58 PM To: Pfautz, Penn L, GBLAM Cc: Pekka Savola; enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs)=20 On Nov 9, 2006, at 17:29, Pfautz, Penn L, GBLAM wrote: > Just to be clear - we were not looking for a new TLD for =20 > infrastructure > ENUM. The authors of this draft would be happy to see the =20 > infrastructure > ENUM apex under .arpa. However, there may be other parties involved > (note that the ITU-T has yet to accept e164.arpa for user ENUM beyond > interim status.) We'd be happy with an apex domain that meets the > necessary performance requirements. I am sure that's the case. However the text in the draft doesn't say =20 so. At least not clearly enough IMO. The current wording can (and =20 will in some circles) be interpreted as meaning Infrastructure ENUM =20 needs its own TLD. Just delete the words "top level" from the text =20 and we're done. ie: 6. Infrastructure ENUM SHALL be implemented under a domain that can =20 support reliability and performance suitable for PSTN/PLMN =20 applications. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiagR-00054P-Jo; Fri, 10 Nov 2006 13:00:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiagQ-00053R-C9 for enum@ietf.org; Fri, 10 Nov 2006 13:00:54 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiagK-0008Bc-VU for enum@ietf.org; Fri, 10 Nov 2006 13:00:54 -0500 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.27425611; Fri, 10 Nov 2006 13:00:22 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 13:00:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Fri, 10 Nov 2006 13:00:21 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602520A73@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccDZoCS/RIuSDa6SJW+ihHHT3LKrQBi2L4Q From: "Livingood, Jason" To: "Ed Guy" , "Stastny Richard" X-OriginalArrivalTime: 10 Nov 2006 18:00:22.0070 (UTC) FILETIME=[172BED60:01C704F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: enum@ietf.org, lconroy , Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Ed Wrote: What happens when a number is changed? On the PSTN,=20 the Caller would be given an intercept message like "The number have have dialled has been changed. =20 The new number is ". =20 personally, I'd like to have this scenario result in an origination feature that updates my address book. Should this be in scope for the status indication? Jason: IMHO that is out of scope for this draft. What you describe is when a subscriber changes TNs within a given service provider. As such, that SP must provide such a user experience and this should not be within the purview of ENUM. JL _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giah1-0005VH-5K; Fri, 10 Nov 2006 13:01:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giah0-0005VC-Hp for enum@ietf.org; Fri, 10 Nov 2006 13:01:30 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giagz-0008Ge-2t for enum@ietf.org; Fri, 10 Nov 2006 13:01:30 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 171A44D46F; Fri, 10 Nov 2006 19:01:14 +0100 (CET) Date: Fri, 10 Nov 2006 19:01:14 +0100 From: Otmar Lendl To: Dale.Worley@comcast.net Subject: Re: [Enum] wildcards Message-ID: <20061110180114.GA23256@nic.at> References: <45512A8D.6030500@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDE@oefeg-s04.oefeg.loc> <200611101658.kAAGwjOT011667@dragon.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611101658.kAAGwjOT011667@dragon.ariadne.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/10 17:11, Dale.Worley@comcast.net wrote: > From: Jim Reid > > My views about DNS wildcarding are well known and don't need to be > repeated here. Putting text in the draft that says "you can do this > with wildcards" is just bad. > > I'm starting to notice that DNS wildcards seem to almost solve some > interesting problems, except they don't. They solve *some* problems, and while doing that give you enough rope to hang yourself trying to extend a working solution to other problems. > One that we've been looking into is for an organization to set up its > own internal ENUM tree containing only record that forward ENUM > lookups to appropriate external ENUM trees. This allows the > organization to, say, by default route everything to a service > provider's private ENUM tree, extract subtrees to be routed via the > internal network, extract other subtrees to be routed to a different > service provider, etc. > > It would seem that the way to do this is to set up DNS wildcard NAPTRs > at the root of each subtree which is treated differently from its > containing subtree. Non-terminal NAPTR are tempting for that, e.g. *.1.2.3.4.5.e164.arpa. "" "" 0 0 "" some.other.domain. In that case, we don't loose the Application Unique String, but we do loose the information what labels the wildcard subsumed. If some.other.domain uses simple NAPTR records, than all numbers under +54321 will map to the same URI. That's likely not to be what you want to happen. (Besides, almost no one has implemented NTNs yet.) Thus this is not a valid option. > As another case, there is a proposal at this IETF to insert special > DNS records at the root of each national ENUM subtree. It would be > wonderful if a query for that record type, directed to an ENUM domain > name, would return the nearest record going up the tree, and wildcards > would seem to be the way to do this. Yes, the EBL record sounds fine for your application. > Except that DNS wildcards don't work this way -- the effect of a > wildcard on a domain name "under" it is canceled if there is any DNS > record for any of the intermediate domains. > > What I'm hoping is that there's a known solution for this problem, of > getting "the FOO record for this domain or the nearest ancestor record > that has a FOO record". As mentioned before, wildcards do work for very specific problems. Deploying them into generic tree which can contain other records is asking for ugly surprises. So, in your case, if you create your own private tree where you control the full tree (which is best put into one zone, thus no NS-style delegation) and if you only put wildcarded EBL records in there, then IMHO you're quite safe. The only issue you have to worry about then is the effect of "empty non-terminals" on wildcards (see RFC 4592). Example: If you have these two wildcards in your zone: *.6.7.8.9.e164.example *.1.2.3.4.5.6.7.8.9.e164.example then e.g. 0.0.0.0.4.5.6.7.8.9.e164.example will not be match the *.6.7.8.9.e164.example wildcard. The Austrian I-ENUM trial encountered this issue as well. We solved it by auto-generating appropriate records. That's a rather short perl- script with loads the DNS tree, walks the tree to generate the needed entries and spits out a fixed version of the zonefile. Please send email if you want to have a copy. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:03:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaiT-0007KY-Fa; Fri, 10 Nov 2006 13:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaiR-0007KQ-Qt for enum@ietf.org; Fri, 10 Nov 2006 13:02:59 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiaiM-0008Th-EF for enum@ietf.org; Fri, 10 Nov 2006 13:02:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Fri, 10 Nov 2006 13:02:18 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602520A76@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccDksq5TXfKdC2SSASM1rX9vw6CigAF3ufAAFH+vVA= From: "Livingood, Jason" To: "Antoin Verschuren" , X-OriginalArrivalTime: 10 Nov 2006 18:02:18.0579 (UTC) FILETIME=[5C9DCA30:01C704F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yes, but this should not be PSTN specific. We are talking about URIs here, which means we are talking over IP networks. A variation --> NOSVC (No Service)? Jason=20 > -----Original Message----- > From: Antoin Verschuren [mailto:Antoin.Verschuren@sidn.nl]=20 > Sent: Wednesday, November 08, 2006 9:56 PM > To: enum@ietf.org > Subject: RE: [Enum] void-02 new version >=20 > lconroy wrote: > >=20 > > Maybe "PSTN-unused" might avoid confusion - this doesn't=20 > say that the=20 > > number has NO potential communication contacts, but that it doesn't=20 > > have a "via PSTN" communications path. >=20 > How about "NPT" (No PSTN Termination) >=20 > Antoin Verschuren >=20 > Technical Advisor > Policy & Business Development > SIDN > Utrechtseweg 310 > PO Box 5022 > 6802 EA Arnhem > The Netherlands >=20 > T +31 26 3525510 > F +31 26 3525505 > M +31 6 23368970 > E antoin.verschuren@sidn.nl > W http://www.sidn.nl/ >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GianT-0002Qr-Sf; Fri, 10 Nov 2006 13:08:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GianS-0002Qd-JJ; Fri, 10 Nov 2006 13:08:10 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GianP-0001Dz-K6; Fri, 10 Nov 2006 13:08:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Fri, 10 Nov 2006 13:07:04 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602520A7C@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Thread-Index: AccEBosL3hbReq29TeK0dD3+36a7dQAHU3LwADPAsHA= From: "Livingood, Jason" To: "Pfautz, Penn L, GBLAM" , "Jim Reid" , "Pekka Savola" X-OriginalArrivalTime: 10 Nov 2006 18:07:05.0023 (UTC) FILETIME=[0759ACF0:01C704F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org To second Penn's point... A new version of the I-D draft-ietf-enum-infrastructure-02 is to go out soon, which addresses this as follows: =20 3. IANA Considerations=20 =20 IANA has created a registry for Enumservices as originally specified=20 in RFC 2916 and revised in RFC 3761. Enumservices registered with=20 IANA are valid for Infrastructure ENUM as well as end-user ENUM.=20 =20 4. DNS Root for Infrastructure ENUM=20 =20 The top level DNS zone for infrastructure ENUM must support a level=20 of performance similar to that required for root servers (RFC 2870)=20 and must be independent of e164.arpa. =20 Jason > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 > Sent: Thursday, November 09, 2006 12:29 PM > To: Jim Reid; Pekka Savola > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org > Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM=20 > Requirements'toInformational RFC=20 > (draft-ietf-enum-infrastructure-enum-reqs)=20 >=20 > Jim: > Just to be clear - we were not looking for a new TLD for=20 > infrastructure ENUM. The authors of this draft would be happy=20 > to see the infrastructure ENUM apex under .arpa. However,=20 > there may be other parties involved (note that the ITU-T has=20 > yet to accept e164.arpa for user ENUM beyond interim status.)=20 > We'd be happy with an apex domain that meets the necessary=20 > performance requirements.=20 >=20 > Penn Pfautz >=20 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Thursday, November 09, 2006 8:51 AM > To: Pekka Savola > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' > toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs)=20 >=20 >=20 > On Nov 9, 2006, at 12:38, Pekka Savola wrote: >=20 > > 6. Infrastructure ENUM SHALL be implemented under a top level =20 > > domain > > that can support reliability and performance suitable for =20 > > PSTN/PLMN > > applications. > > > > =3D=3D> this seems like a NOP requirement, given that you don't = describe > > or give reference what those reliability or performance requirements > > are. What are the real requirements? Is it believed that some top > > level domains could not satisfy these? If not, this requirement > > doesn't seem to be useful. >=20 > Indeed. I wonder why "top level domain" gets mentioned at all. =20 > There's nothing magical or special about Infrastructure ENUM that =20 > requires or justifies the creation of a TLD. It would be best to =20 > avoid opening up that layer-9 rat-hole in the ICANN/IANA/DoC world. =20 > Besides, didn't RFC3172 decree infrastructure domains live=20 > under .arpa? >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gib3w-0004rG-RZ; Fri, 10 Nov 2006 13:25:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gib3v-0004pp-6t for enum@ietf.org; Fri, 10 Nov 2006 13:25:11 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gib3t-0003wZ-TG for enum@ietf.org; Fri, 10 Nov 2006 13:25:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version - new name: unused Date: Fri, 10 Nov 2006 19:24:24 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BFD@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version - new name: unused thread-index: AccDZi55IfT8jrF0RiGbTMrHfyAaaQAAOrhZAGLCSQAAAFYtFg== References: <45AEC6EF95942140888406588E1A6602520A75@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Status of discussion: =20 Can we agree on the following? =20 Instead of void we use the EnumService UNUSED =20 And we also use the data URI for additional text =20 example=20 =20 IN NAPTR 100 100 "u" "E2U+unused:data" = "!^.*$!data:text/plain,unassigned! . =20 =20 Richard =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:42:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibJZ-0006vr-48; Fri, 10 Nov 2006 13:41:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibJY-0006vG-0i for enum@ietf.org; Fri, 10 Nov 2006 13:41:20 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GibJW-0006m2-Lc for enum@ietf.org; Fri, 10 Nov 2006 13:41:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version - new name: unused Date: Fri, 10 Nov 2006 19:38:29 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BFF@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version - new name: unused thread-index: AccDZi55IfT8jrF0RiGbTMrHfyAaaQAAOrhZAGLCSQAAAFYtFgAA4rYAAAAZFqw= References: <45AEC6EF95942140888406588E1A6602520A8B@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I have a problem with NOSVC, because it includes also the case that the line is currently out of service, and in addition it may be service = specific such mailto may be inservice and sip noservice =20 Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Fr 10.11.2006 19:36 An: Stastny Richard; enum@ietf.org Betreff: RE: [Enum] void-02 new version - new name: unused Looks good to me at least. If folks have a problem with UNUSED, you are welcome to use my suggestion of NOSVC for No Service. ;-) Jason > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, November 10, 2006 1:24 PM > To: Livingood, Jason; enum@ietf.org > Subject: Re: [Enum] void-02 new version - new name: unused > > Status of discussion: >=20 > Can we agree on the following? >=20 > Instead of void we use the EnumService UNUSED >=20 > And we also use the data URI for additional text >=20 > example >=20 > IN NAPTR 100 100 "u" "E2U+unused:data" > "!^.*$!data:text/plain,unassigned! . >=20 >=20 > Richard >=20 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibJH-0006lA-NX; Fri, 10 Nov 2006 13:41:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibIo-0006Ry-HD for enum@ietf.org; Fri, 10 Nov 2006 13:40:34 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibFA-0005Au-Dv for enum@ietf.org; Fri, 10 Nov 2006 13:36:53 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27504365; Fri, 10 Nov 2006 13:36:30 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 13:36:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version - new name: unused Date: Fri, 10 Nov 2006 13:36:28 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602520A8B@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version - new name: unused Thread-Index: AccDZi55IfT8jrF0RiGbTMrHfyAaaQAAOrhZAGLCSQAAAFYtFgAA4rYA From: "Livingood, Jason" To: "Stastny Richard" , X-OriginalArrivalTime: 10 Nov 2006 18:36:30.0060 (UTC) FILETIME=[2364F2C0:01C704F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Looks good to me at least. If folks have a problem with UNUSED, you are welcome to use my suggestion of NOSVC for No Service. ;-) Jason=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Friday, November 10, 2006 1:24 PM > To: Livingood, Jason; enum@ietf.org > Subject: Re: [Enum] void-02 new version - new name: unused >=20 > Status of discussion: > =20 > Can we agree on the following? > =20 > Instead of void we use the EnumService UNUSED > =20 > And we also use the data URI for additional text > =20 > example=20 > =20 > IN NAPTR 100 100 "u" "E2U+unused:data"=20 > "!^.*$!data:text/plain,unassigned! . > =20 > =20 > Richard > =20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 13:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibUL-00062W-LG; Fri, 10 Nov 2006 13:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibUK-00060q-FY; Fri, 10 Nov 2006 13:52:28 -0500 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibUJ-00004t-30; Fri, 10 Nov 2006 13:52:28 -0500 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 110744; Fri, 10 Nov 2006 18:52:25 +0000 In-Reply-To: <45AEC6EF95942140888406588E1A6602520A7C@PACDCEXCMB04.cable.comcast.com> References: <45AEC6EF95942140888406588E1A6602520A7C@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75F6D21E-6F8A-4C01-8E1C-D0647C8A035E@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Fri, 10 Nov 2006 18:52:24 +0000 To: "Livingood, Jason" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, iesg@ietf.org, "Pfautz, Penn L, GBLAM" , Pekka Savola X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Nov 10, 2006, at 18:07, Livingood, Jason wrote: > To second Penn's point... A new version of the I-D > draft-ietf-enum-infrastructure-02 is to go out soon, which addresses > this as follows: > 4. DNS Root for Infrastructure ENUM > > The top level DNS zone for infrastructure ENUM must support a level > of performance similar to that required for root servers (RFC 2870) > and must be independent of e164.arpa. Sorry, I cannot accept this text at all. Specific technical terms are being misused: like "DNS Root" and "top level DNS zone" for example. RFC 2870 concentrates on name server configuration and operation. It says *practically nothing* about performance. The RFC has no meaningful data points about query rates, response times, bandwidth requirements, service levels, etc, etc. I am also not convinced there's any reason why this document needs to mention domain names that can or can't be used for Infrastructure ENUM. How about: 4. Zone Apex for Infrastructure ENUM The domain name chosen for Infrastructure ENUM and any parent domains must be hosted on name servers that have performance characteristics and supporting infrastructure comparable to those deployed for the Internet root name servers. Those name servers for Infrastructure ENUM should be configured and operated according to the guidelines described in RFC2870. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 14:27:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic1T-0003L3-CK; Fri, 10 Nov 2006 14:26:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic0z-0003B3-Jq; Fri, 10 Nov 2006 14:26:13 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gibpq-0003LT-4q; Fri, 10 Nov 2006 14:14:43 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1163186081!9333734!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2147 invoked from network); 10 Nov 2006 19:14:41 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-6.tower-121.messagelabs.com with SMTP; 10 Nov 2006 19:14:41 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAAJEe6e028437; Fri, 10 Nov 2006 14:14:40 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAAJEOur028301; Fri, 10 Nov 2006 14:14:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Fri, 10 Nov 2006 14:14:30 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E14A5D9@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <75F6D21E-6F8A-4C01-8E1C-D0647C8A035E@rfc1035.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Thread-Index: AccE+WKuh5CuWr4WSFiQeoQOrshoWgAAvZDw From: "Pfautz, Penn L, GBLAM" To: "Jim Reid" , "Livingood, Jason" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, Pekka Savola , iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This language works for me. Jason? Richard? Penn=20 -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com]=20 Sent: Friday, November 10, 2006 1:52 PM To: Livingood, Jason Cc: Pfautz, Penn L, GBLAM; Pekka Savola; enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs)=20 On Nov 10, 2006, at 18:07, Livingood, Jason wrote: > To second Penn's point... A new version of the I-D > draft-ietf-enum-infrastructure-02 is to go out soon, which addresses > this as follows: > 4. DNS Root for Infrastructure ENUM > > The top level DNS zone for infrastructure ENUM must support a level > of performance similar to that required for root servers (RFC 2870) > and must be independent of e164.arpa. Sorry, I cannot accept this text at all. Specific technical terms are =20 being misused: like "DNS Root" and "top level DNS zone" for example. =20 RFC 2870 concentrates on name server configuration and operation. It =20 says *practically nothing* about performance. The RFC has no =20 meaningful data points about query rates, response times, bandwidth =20 requirements, service levels, etc, etc. I am also not convinced =20 there's any reason why this document needs to mention domain names =20 that can or can't be used for Infrastructure ENUM. How about: 4. Zone Apex for Infrastructure ENUM The domain name chosen for Infrastructure ENUM and any parent domains =20 must be hosted on name servers that have performance characteristics =20 and supporting infrastructure comparable to those deployed for the =20 Internet root name servers. Those name servers for Infrastructure =20 ENUM should be configured and operated according to the guidelines =20 described in RFC2870. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 14:35:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicA9-00044b-7r; Fri, 10 Nov 2006 14:35:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicA6-00043a-2B; Fri, 10 Nov 2006 14:35:39 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GicA4-0007mW-Jb; Fri, 10 Nov 2006 14:35:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUMRequirements'toInformational RFC(draft-ietf-enum-infrastructure-enum-reqs) Date: Fri, 10 Nov 2006 20:34:23 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C00@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'Infrastrucure ENUMRequirements'toInformational RFC(draft-ietf-enum-infrastructure-enum-reqs) thread-index: AccE+WKuh5CuWr4WSFiQeoQOrshoWgAAvZDwAAC4NuI= References: <34DA635B184A644DA4588E260EC0A25A0E14A5D9@ACCLUST02EVS1.ugd.att.com> From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , "Jim Reid" , "Livingood, Jason" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: enum@ietf.org, enum-chairs@tools.ietf.org, Pekka Savola , iesg@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Ok with me too =20 Richard ________________________________ Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Gesendet: Fr 10.11.2006 20:14 An: Jim Reid; Livingood, Jason Cc: enum@ietf.org; enum-chairs@tools.ietf.org; Pekka Savola; = iesg@ietf.org Betreff: RE: [Enum] Re: Last Call: 'Infrastrucure = ENUMRequirements'toInformational = RFC(draft-ietf-enum-infrastructure-enum-reqs)=20 This language works for me. Jason? Richard? Penn -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com] Sent: Friday, November 10, 2006 1:52 PM To: Livingood, Jason Cc: Pfautz, Penn L, GBLAM; Pekka Savola; enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) On Nov 10, 2006, at 18:07, Livingood, Jason wrote: > To second Penn's point... A new version of the I-D > draft-ietf-enum-infrastructure-02 is to go out soon, which addresses > this as follows: > 4. DNS Root for Infrastructure ENUM > > The top level DNS zone for infrastructure ENUM must support a level > of performance similar to that required for root servers (RFC 2870) > and must be independent of e164.arpa. Sorry, I cannot accept this text at all. Specific technical terms are=20 being misused: like "DNS Root" and "top level DNS zone" for example.=20 RFC 2870 concentrates on name server configuration and operation. It=20 says *practically nothing* about performance. The RFC has no=20 meaningful data points about query rates, response times, bandwidth=20 requirements, service levels, etc, etc. I am also not convinced=20 there's any reason why this document needs to mention domain names=20 that can or can't be used for Infrastructure ENUM. How about: 4. Zone Apex for Infrastructure ENUM The domain name chosen for Infrastructure ENUM and any parent domains=20 must be hosted on name servers that have performance characteristics=20 and supporting infrastructure comparable to those deployed for the=20 Internet root name servers. Those name servers for Infrastructure=20 ENUM should be configured and operated according to the guidelines=20 described in RFC2870. _______________________________________________ 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 enum-bounces@ietf.org Fri Nov 10 15:17:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicnA-0005uF-EN; Fri, 10 Nov 2006 15:16:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gicn8-0005s8-45 for enum@ietf.org; Fri, 10 Nov 2006 15:15:58 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gicn6-0005DT-Pu for enum@ietf.org; Fri, 10 Nov 2006 15:15:58 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 12:15:55 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="747326:sNHT51878574" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAAKFt7Y025789; Fri, 10 Nov 2006 15:15:55 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAAKFpYJ018690; Fri, 10 Nov 2006 15:15:51 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:15:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] void-02 new version Date: Fri, 10 Nov 2006 15:15:50 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DB33B@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version Thread-Index: AccDZoCS/RIuSDa6SJW+ihHHT3LKrQBi2L4QAATFQIA= From: "Michael Hammer \(mhammer\)" To: "Livingood, Jason" , "Ed Guy" , "Stastny Richard" X-OriginalArrivalTime: 10 Nov 2006 20:15:51.0412 (UTC) FILETIME=[04A31340:01C70505] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1169; t=1163189755; x=1164053755; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Enum]=20void-02=20new=20version |Sender:=20 |To:=20=22Livingood, =20Jason=22=20, =0A =20=20=20=20=20=20=20=20=22Ed=20Guy=22=20, =0A=20=20=20=20 =20=20=20=20=22Stastny=20Richard=22=20; bh=WyfuR5/3vfJQKxB6oRvT8t1Vr4sKi3VDvBAjpUKgen8=; b=VmQGH58qB03Jll+eif2tJ1j9SXVKFVO4/IIRtbFkSY2XwgE9/xjAoXgpt1hrNTO5/EM4noBS Je+8PAnwuEzcy7csPUxUI8m2FIhqXooZpeZ1uEq4yOEO5Iw6O/eu63+9; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: enum@ietf.org, lconroy , Otmar Lendl , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Agree, that is a SIP (or whatever) question. Mike=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Friday, November 10, 2006 1:00 PM > To: Ed Guy; Stastny Richard > Cc: enum@ietf.org; lconroy; Otmar Lendl; rich.shockey@NeuStar.biz > Subject: RE: [Enum] void-02 new version >=20 > Ed Wrote: > What happens when a number is changed? On the PSTN, the=20 > Caller would be given an intercept message like "The number=20 > have have dialled has been changed. =20 > The new number is ". =20 > personally, I'd like to have this scenario result in an=20 > origination feature that updates my address book. > Should this be in scope for the status indication? >=20 > Jason: IMHO that is out of scope for this draft. What you=20 > describe is when a subscriber changes TNs within a given=20 > service provider. As such, that SP must provide such a user=20 > experience and this should not be within the purview of ENUM. >=20 > JL >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 15:51:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GidKk-0004l3-4l; Fri, 10 Nov 2006 15:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GidKb-0004ic-7e; Fri, 10 Nov 2006 15:50:33 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GidKb-0004zR-5U; Fri, 10 Nov 2006 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GidKa-0007dv-Ry; Fri, 10 Nov 2006 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6E4D0175BA; Fri, 10 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GidK5-0006aR-Uu; Fri, 10 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 10 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-02.txt Pages : 6 Date : 2006-11-10 This document defines a use case as well as a proposal for a parallel namespace to “e164.arpa” as defined in RFC3761, to be used for Infrastructure ENUM purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-infrastructure-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-infrastructure-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-10134438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-infrastructure-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-infrastructure-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-10134438.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Nov 10 17:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GieTN-00031U-Ie; Fri, 10 Nov 2006 17:03:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GieTE-0002t3-R8 for enum@ietf.org; Fri, 10 Nov 2006 17:03:32 -0500 Received: from relay4.san2.attens.net ([192.215.81.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GieJ6-000323-Dy for enum@ietf.org; Fri, 10 Nov 2006 16:53:05 -0500 Received: from 127host36.starwoodbroadband.com (127host36.starwoodbroadband.com [12.105.242.36]) by relay4.san2.attens.net (8.13.6/8.13.6) with ESMTP id kAALq8XY014278; Fri, 10 Nov 2006 21:52:09 GMT Subject: RE: [Enum] void-02 new version From: Ed Guy To: "Michael Hammer (mhammer)" In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3022DB33B@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3022DB33B@xmb-rtp-20b.amer.cisco.com> Date: Fri, 10 Nov 2006 16:52:06 -0500 Message-Id: <1163195526.10649.52.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Spam-Score: 0.6 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: enum@ietf.org, Otmar Lendl , lconroy , rich.shockey@NeuStar.biz, Stastny Richard , "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1046506515==" Errors-To: enum-bounces@ietf.org --===============1046506515== Content-Type: multipart/alternative; boundary="=-pwwdOaPIaHAB06Wwg4o3" --=-pwwdOaPIaHAB06Wwg4o3 Content-Type: text/plain Content-Transfer-Encoding: 7bit OK. This enumservice works well if it is is kept very simple. >IN NAPTR 100 100 "u" "E2U+unused:data" "!^.*$! data:text/plain,unassigned! . Is the data content unconstrained? And, does void or 'unused' provide an authoritative indication that 1) there is no other valid NAPTR information available for this number, 2) the number is not serviced on the Internet, and 3) the number is not serviced on the PSTN. ?? /ed On Fri, 2006-11-10 at 15:15 -0500, Michael Hammer (mhammer) wrote: > Agree, that is a SIP (or whatever) question. > Mike > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Friday, November 10, 2006 1:00 PM > > To: Ed Guy; Stastny Richard > > Cc: enum@ietf.org; lconroy; Otmar Lendl; rich.shockey@NeuStar.biz > > Subject: RE: [Enum] void-02 new version > > > > Ed Wrote: > > What happens when a number is changed? On the PSTN, the > > Caller would be given an intercept message like "The number > > have have dialled has been changed. > > The new number is ". > > personally, I'd like to have this scenario result in an > > origination feature that updates my address book. > > Should this be in scope for the status indication? > > > > Jason: IMHO that is out of scope for this draft. What you > > describe is when a subscriber changes TNs within a given > > service provider. As such, that SP must provide such a user > > experience and this should not be within the purview of ENUM. > > > > JL > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > --=-pwwdOaPIaHAB06Wwg4o3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit OK.   This enumservice works well if it is is kept very simple. 

>IN NAPTR 100 100 "u" "E2U+unused:data" "!^.*$!data:text/plain,unassigned!  .
Is the data content unconstrained?

And, does void or 'unused'  provide an authoritative indication that
1) there is no other valid NAPTR information available for this number,
2) the number is not serviced on the Internet, and   
3) the number is not serviced on the PSTN.   
??

/ed





On Fri, 2006-11-10 at 15:15 -0500, Michael Hammer (mhammer) wrote: 
Agree, that is a SIP (or whatever) question.
Mike 

> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] 
> Sent: Friday, November 10, 2006 1:00 PM
> To: Ed Guy; Stastny Richard
> Cc: enum@ietf.org; lconroy; Otmar Lendl; rich.shockey@NeuStar.biz
> Subject: RE: [Enum] void-02 new version
> 
> Ed Wrote:
> What happens when a number is changed?  On the PSTN, the 
> Caller would be given an intercept message like "The number 
> have have dialled <X> has been changed.  
> The new number is <y>".  
> personally, I'd like to have this scenario result in an 
> origination feature that updates my address book.
> Should this be in scope for the status indication?
> 
> Jason:  IMHO that is out of scope for this draft.  What you 
> describe is when a subscriber changes TNs within a given 
> service provider.  As such, that SP must provide such a user 
> experience and this should not be within the purview of ENUM.
> 
> JL
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>
--=-pwwdOaPIaHAB06Wwg4o3-- --===============1046506515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1046506515==-- From enum-bounces@ietf.org Fri Nov 10 20:17:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GihTN-0002C6-62; Fri, 10 Nov 2006 20:15:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GihTL-0002Bz-DA for enum@ietf.org; Fri, 10 Nov 2006 20:15:51 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GihTJ-0001e7-Vj for enum@ietf.org; Fri, 10 Nov 2006 20:15:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] void-02 new version Date: Sat, 11 Nov 2006 02:12:35 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C01@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] void-02 new version thread-index: AccFEpQFI3Hjgk3iQgyi9rsJ/Fn3BgAG+SFZ References: <072C5B76F7CEAB488172C6F64B30B5E3022DB33B@xmb-rtp-20b.amer.cisco.com> <1163195526.10649.52.camel@localhost> From: "Stastny Richard" To: "Ed Guy" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: enum@ietf.org, Otmar Lendl , lconroy , "Livingood, Jason" , rich.shockey@NeuStar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >OK. This enumservice works well if it is is kept very simple. =20 >>IN NAPTR 100 100 "u" "E2U+unused:data" = "!^.*$!data:text/plain,unassigned! . >Is the data content unconstrained? =20 IMO yes, you may put in what you like >And, does void or 'unused' provide an authoritative indication that=20 >1) there is no other valid NAPTR information available for this number, = >2) the number is not serviced on the Internet, and =20 >3) the number is not serviced on the PSTN. =20 =20 Yes, it is independant of techology Richard /ed On Fri, 2006-11-10 at 15:15 -0500, Michael Hammer (mhammer) wrote:=20 Agree, that is a SIP (or whatever) question. Mike=20 =09 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Friday, November 10, 2006 1:00 PM > To: Ed Guy; Stastny Richard > Cc: enum@ietf.org; lconroy; Otmar Lendl; rich.shockey@NeuStar.biz > Subject: RE: [Enum] void-02 new version >=20 > Ed Wrote: > What happens when a number is changed? On the PSTN, the=20 > Caller would be given an intercept message like "The number=20 > have have dialled has been changed. =20 > The new number is ". =20 > personally, I'd like to have this scenario result in an=20 > origination feature that updates my address book. > Should this be in scope for the status indication? >=20 > Jason: IMHO that is out of scope for this draft. What you=20 > describe is when a subscriber changes TNs within a given=20 > service provider. As such, that SP must provide such a user=20 > experience and this should not be within the purview of ENUM. >=20 > JL >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 10 23:44:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gikgz-000459-RE; Fri, 10 Nov 2006 23:42:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gikgy-000454-RQ for enum@ietf.org; Fri, 10 Nov 2006 23:42:08 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gikgx-0007kf-J7 for enum@ietf.org; Fri, 10 Nov 2006 23:42:08 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20061111044206m13004o31ee>; Sat, 11 Nov 2006 04:42:06 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAB4g5Qg027794 for ; Fri, 10 Nov 2006 23:42:05 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAB4g5xW027790; Fri, 10 Nov 2006 23:42:05 -0500 Date: Fri, 10 Nov 2006 23:42:05 -0500 Message-Id: <200611110442.kAB4g5xW027790@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <20061110180114.GA23256@nic.at> (lendl@nic.at) Subject: Re: [Enum] wildcards References: <45512A8D.6030500@enum.at> <32755D354E6B65498C3BD9FD496C7D462C4BDE@oefeg-s04.oefeg.loc> <200611101658.kAAGwjOT011667@dragon.ariadne.com> <20061110180114.GA23256@nic.at> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: Otmar Lendl If you have these two wildcards in your zone: *.6.7.8.9.e164.example *.1.2.3.4.5.6.7.8.9.e164.example then e.g. 0.0.0.0.4.5.6.7.8.9.e164.example will not be match the *.6.7.8.9.e164.example wildcard. The Austrian I-ENUM trial encountered this issue as well. We solved it by auto-generating appropriate records. That's a rather short perl- script with loads the DNS tree, walks the tree to generate the needed entries and spits out a fixed version of the zonefile. Yes, but this requires being able to predict what the E.164 numbers are in advance, or at least, a close approximation of the numbering plan. And it generates as many DNS records as there are E.164 numbers in the subtree, which is likely to be millions, rather than the number of subtrees with different treatments, which is likely to be around 10. I suppose in an I-ENUM situation, the carriers are already fully informed about the numbering plan, and may expect to have a separate NAPTR record for every number in-use, but if it's just to route ENUM lookups to one of a set of external service providers, it's not efficient. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 12 10:04:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGqe-0007Xj-8U; Sun, 12 Nov 2006 10:02:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGqc-0007Wv-L7 for enum@ietf.org; Sun, 12 Nov 2006 10:02:14 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjGqa-0006FJ-7t for enum@ietf.org; Sun, 12 Nov 2006 10:02:14 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kACExIqF020037; Sun, 12 Nov 2006 06:59:24 -0800 From: "Richard Shockey" To: "'Stastny Richard'" , "'Livingood, Jason'" , Subject: RE: [Enum] void-02 new version - new name: unused Date: Sun, 12 Nov 2006 09:59:04 -0500 Message-ID: <01b901c7066b$197f02d0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccDZi55IfT8jrF0RiGbTMrHfyAaaQAAOrhZAGLCSQAAAFYtFgBd5gXQ In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BFD@oefeg-s04.oefeg.loc> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Works for me .. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, November 10, 2006 1:24 PM > To: Livingood, Jason; enum@ietf.org > Subject: Re: [Enum] void-02 new version - new name: unused > > Status of discussion: > > Can we agree on the following? > > Instead of void we use the EnumService UNUSED > > And we also use the data URI for additional text > > example > > IN NAPTR 100 100 "u" "E2U+unused:data" "!^.*$!data:text/plain,unassigned! > . > > > Richard > > > _______________________________________________ > 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 enum-bounces@ietf.org Sun Nov 12 10:04:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGr4-0007m5-Lt; Sun, 12 Nov 2006 10:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGr4-0007lw-1m for enum@ietf.org; Sun, 12 Nov 2006 10:02:42 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjGr2-0006Ie-2A for enum@ietf.org; Sun, 12 Nov 2006 10:02:42 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kACEwRGK019476; Sun, 12 Nov 2006 06:58:33 -0800 From: "Richard Shockey" To: "'Pfautz, Penn L, GBLAM'" , "'Jim Reid'" , "'Livingood, Jason'" Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Sun, 12 Nov 2006 09:58:08 -0500 Message-ID: <01b801c7066a$fb29d030$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccE+WKuh5CuWr4WSFiQeoQOrshoWgAAvZDwAFueqnA= In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0E14A5D9@ACCLUST02EVS1.ugd.att.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: enum@ietf.org, 'Pekka Savola' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Seems reasonable but I think you can remove IESG from this discussion from now on. > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Friday, November 10, 2006 2:15 PM > To: Jim Reid; Livingood, Jason > Cc: Pekka Savola; enum@ietf.org; enum-chairs@tools.ietf.org; iesg@ietf.org > Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM > Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum- > reqs) > > This language works for me. Jason? Richard? > > Penn > > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Friday, November 10, 2006 1:52 PM > To: Livingood, Jason > Cc: Pfautz, Penn L, GBLAM; Pekka Savola; enum@ietf.org; > enum-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM > Requirements'toInformational RFC > (draft-ietf-enum-infrastructure-enum-reqs) > > On Nov 10, 2006, at 18:07, Livingood, Jason wrote: > > > To second Penn's point... A new version of the I-D > > draft-ietf-enum-infrastructure-02 is to go out soon, which addresses > > this as follows: > > > 4. DNS Root for Infrastructure ENUM > > > > The top level DNS zone for infrastructure ENUM must support a level > > of performance similar to that required for root servers (RFC 2870) > > and must be independent of e164.arpa. > > Sorry, I cannot accept this text at all. Specific technical terms are > being misused: like "DNS Root" and "top level DNS zone" for example. > RFC 2870 concentrates on name server configuration and operation. It > says *practically nothing* about performance. The RFC has no > meaningful data points about query rates, response times, bandwidth > requirements, service levels, etc, etc. I am also not convinced > there's any reason why this document needs to mention domain names > that can or can't be used for Infrastructure ENUM. > > How about: > > 4. Zone Apex for Infrastructure ENUM > > The domain name chosen for Infrastructure ENUM and any parent domains > must be hosted on name servers that have performance characteristics > and supporting infrastructure comparable to those deployed for the > Internet root name servers. Those name servers for Infrastructure > ENUM should be configured and operated according to the guidelines > described in RFC2870. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 13 12:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfBS-0007Eu-UQ; Mon, 13 Nov 2006 12:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfBR-0007Dy-JD for enum@ietf.org; Mon, 13 Nov 2006 12:01:21 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfBJ-0006v4-8p for enum@ietf.org; Mon, 13 Nov 2006 12:01:21 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27564471; Mon, 13 Nov 2006 12:00:55 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:00:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUMRequirements'toInformational RFC(draft-ietf-enum-infrastructure-enum-reqs) Date: Mon, 13 Nov 2006 12:00:54 -0500 Message-ID: <45AEC6EF95942140888406588E1A66025ABCDD@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'Infrastrucure ENUMRequirements'toInformational RFC(draft-ietf-enum-infrastructure-enum-reqs) Thread-Index: AccE+WKuh5CuWr4WSFiQeoQOrshoWgAAvZDwAAC4NuIAkWRNAA== From: "Livingood, Jason" To: X-OriginalArrivalTime: 13 Nov 2006 17:00:55.0437 (UTC) FILETIME=[48882BD0:01C70745] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Jim Reid X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Changes made. This is pretty similar to feedback that Otmar Lendl sent as well. Jason=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Friday, November 10, 2006 2:34 PM > To: Pfautz, Penn L, GBLAM; Jim Reid; Livingood, Jason > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; Pekka Savola;=20 > iesg@ietf.org > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure=20 > ENUMRequirements'toInformational=20 > RFC(draft-ietf-enum-infrastructure-enum-reqs)=20 >=20 > Ok with me too > =20 > Richard >=20 > ________________________________ >=20 > Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Gesendet: Fr 10.11.2006 20:14 > An: Jim Reid; Livingood, Jason > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; Pekka Savola;=20 > iesg@ietf.org > Betreff: RE: [Enum] Re: Last Call: 'Infrastrucure=20 > ENUMRequirements'toInformational=20 > RFC(draft-ietf-enum-infrastructure-enum-reqs)=20 >=20 >=20 >=20 > This language works for me. Jason? Richard? >=20 > Penn >=20 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Friday, November 10, 2006 1:52 PM > To: Livingood, Jason > Cc: Pfautz, Penn L, GBLAM; Pekka Savola; enum@ietf.org;=20 > enum-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM=20 > Requirements'toInformational RFC > (draft-ietf-enum-infrastructure-enum-reqs) >=20 > On Nov 10, 2006, at 18:07, Livingood, Jason wrote: >=20 > > To second Penn's point... A new version of the I-D > > draft-ietf-enum-infrastructure-02 is to go out soon, which=20 > addresses=20 > > this as follows: >=20 > > 4. DNS Root for Infrastructure ENUM > > > > The top level DNS zone for infrastructure ENUM must=20 > support a level > > of performance similar to that required for root servers=20 > (RFC 2870) > > and must be independent of e164.arpa. >=20 > Sorry, I cannot accept this text at all. Specific technical=20 > terms are being misused: like "DNS Root" and "top level DNS=20 > zone" for example.=20 > RFC 2870 concentrates on name server configuration and=20 > operation. It says *practically nothing* about performance.=20 > The RFC has no meaningful data points about query rates,=20 > response times, bandwidth requirements, service levels, etc,=20 > etc. I am also not convinced there's any reason why this=20 > document needs to mention domain names that can or can't be=20 > used for Infrastructure ENUM. >=20 > How about: >=20 > 4. Zone Apex for Infrastructure ENUM >=20 > The domain name chosen for Infrastructure ENUM and any parent=20 > domains must be hosted on name servers that have performance=20 > characteristics and supporting infrastructure comparable to=20 > those deployed for the Internet root name servers. Those name=20 > servers for Infrastructure ENUM should be configured and=20 > operated according to the guidelines described in RFC2870. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 13 12:11:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfKS-0005n0-AD; Mon, 13 Nov 2006 12:10:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfKQ-0005lu-HK for enum@ietf.org; Mon, 13 Nov 2006 12:10:38 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfKO-0008Dz-11 for enum@ietf.org; Mon, 13 Nov 2006 12:10:37 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kADHA5j24081; Mon, 13 Nov 2006 12:10:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Mon, 13 Nov 2006 12:10:01 -0500 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BCF@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thread-Index: AccCsul/6rrnmPEkSVCBLGAgA0VkbgAAJQkTAQKGv7A= From: "James McEachern" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I hesitate to ask, but... will ENUM only numbers be restricted to fixed = length numbering plans, or will they allow variable length numbering = plans? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, November 07, 2006 4:27 PM To: Niall O'Reilly Cc: enum@ietf.org; Livingood, Jason Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thank you for coming back to this =20 Void is optional exept for ENUM only numbers, where it is required =20 Richard ________________________________ Von: Niall O'Reilly [mailto:Niall.oReilly@ucd.ie] Gesendet: Di 07.11.2006 22:23 An: Pfautz, Penn L, GBLAM Cc: Niall O'Reilly; Michael Hammer (mhammer); Stastny Richard; = richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem On 7 Nov 2006, at 21:15, Pfautz, Penn L, GBLAM wrote: > If it's not harder to send an INVITE than to > do a DNS query one of the motivations for this draft would be gone. There would still be the residual motivation of preventing looping due to hot-potato call-routing configuration, which is mentioned at the end of Section 3 of the draft. Or this isn't significant? /Niall _______________________________________________ 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 enum-bounces@ietf.org Mon Nov 13 12:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfQy-0002Io-5j; Mon, 13 Nov 2006 12:17:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfQw-0002Ie-Cb for enum@ietf.org; Mon, 13 Nov 2006 12:17:22 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfQv-0000Xa-1t for enum@ietf.org; Mon, 13 Nov 2006 12:17:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Last Call: 'InfrastrucureENUMRequirements'toInformationalRFC(draft-ietf-enum-infrastructure-enum-reqs) Date: Mon, 13 Nov 2006 12:16:52 -0500 Message-ID: <45AEC6EF95942140888406588E1A66025ABCE2@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call: 'InfrastrucureENUMRequirements'toInformationalRFC(draft-ietf-enum-infrastructure-enum-reqs) Thread-Index: AccE+WKuh5CuWr4WSFiQeoQOrshoWgAAvZDwAAC4NuIAkWRNAAAAp7Ag From: "Livingood, Jason" To: X-OriginalArrivalTime: 13 Nov 2006 17:16:53.0028 (UTC) FILETIME=[834CF640:01C70747] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Jim Reid X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Here is the specific text below. Any issues? If not I will post a new draft with this change tomorrow. 4. Zone Apex for Infrastructure ENUM The domain name chosed for infrastructure ENUM and any parent domains must be hosted on name servers that have performance characteristics and supporting infrastructure which is comparable to those deployed for the Internet root name servers. Those name servers for Infrastructure ENUM should be configured and operated according to the guidelines described in RFC 2870. =20 Regards Jason > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Monday, November 13, 2006 12:01 PM > To: enum@ietf.org > Cc: Jim Reid > Subject: RE: [Enum] Re: Last Call:=20 > 'InfrastrucureENUMRequirements'toInformationalRFC(draft-ietf-e > num-infrastructure-enum-reqs)=20 >=20 > Changes made. This is pretty similar to feedback that Otmar=20 > Lendl sent as well. >=20 > Jason=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, November 10, 2006 2:34 PM > > To: Pfautz, Penn L, GBLAM; Jim Reid; Livingood, Jason > > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; Pekka Savola;=20 > > iesg@ietf.org > > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure=20 > > ENUMRequirements'toInformational > > RFC(draft-ietf-enum-infrastructure-enum-reqs) > >=20 > > Ok with me too > > =20 > > Richard > >=20 > > ________________________________ > >=20 > > Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Gesendet: Fr 10.11.2006 20:14 > > An: Jim Reid; Livingood, Jason > > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; Pekka Savola;=20 > > iesg@ietf.org > > Betreff: RE: [Enum] Re: Last Call: 'Infrastrucure=20 > > ENUMRequirements'toInformational > > RFC(draft-ietf-enum-infrastructure-enum-reqs) > >=20 > >=20 > >=20 > > This language works for me. Jason? Richard? > >=20 > > Penn > >=20 > > -----Original Message----- > > From: Jim Reid [mailto:jim@rfc1035.com] > > Sent: Friday, November 10, 2006 1:52 PM > > To: Livingood, Jason > > Cc: Pfautz, Penn L, GBLAM; Pekka Savola; enum@ietf.org;=20 > > enum-chairs@tools.ietf.org; iesg@ietf.org > > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM=20 > > Requirements'toInformational RFC > > (draft-ietf-enum-infrastructure-enum-reqs) > >=20 > > On Nov 10, 2006, at 18:07, Livingood, Jason wrote: > >=20 > > > To second Penn's point... A new version of the I-D > > > draft-ietf-enum-infrastructure-02 is to go out soon, which > > addresses > > > this as follows: > >=20 > > > 4. DNS Root for Infrastructure ENUM > > > > > > The top level DNS zone for infrastructure ENUM must > > support a level > > > of performance similar to that required for root servers > > (RFC 2870) > > > and must be independent of e164.arpa. > >=20 > > Sorry, I cannot accept this text at all. Specific technical=20 > terms are=20 > > being misused: like "DNS Root" and "top level DNS zone" for example. > > RFC 2870 concentrates on name server configuration and=20 > operation. It=20 > > says *practically nothing* about performance. > > The RFC has no meaningful data points about query rates, response=20 > > times, bandwidth requirements, service levels, etc, etc. I=20 > am also not=20 > > convinced there's any reason why this document needs to=20 > mention domain=20 > > names that can or can't be used for Infrastructure ENUM. > >=20 > > How about: > >=20 > > 4. Zone Apex for Infrastructure ENUM > >=20 > > The domain name chosen for Infrastructure ENUM and any=20 > parent domains=20 > > must be hosted on name servers that have performance=20 > characteristics=20 > > and supporting infrastructure comparable to those deployed for the=20 > > Internet root name servers. Those name servers for=20 > Infrastructure ENUM=20 > > should be configured and operated according to the guidelines=20 > > described in RFC2870. > >=20 > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 13 15:41:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjiaW-0003Jp-Oy; Mon, 13 Nov 2006 15:39:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjiYM-00027d-Ac for enum@ietf.org; Mon, 13 Nov 2006 15:37:14 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjiOK-0002Ot-H6 for enum@ietf.org; Mon, 13 Nov 2006 15:26:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: Last Call:'InfrastrucureENUMRequirements'toInformationalRFC(draft-ietf-enum-infrastructure-enum-reqs) Date: Mon, 13 Nov 2006 21:25:08 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C0F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: Last Call:'InfrastrucureENUMRequirements'toInformationalRFC(draft-ietf-enum-infrastructure-enum-reqs) thread-index: AccE+WKuh5CuWr4WSFiQeoQOrshoWgAAvZDwAAC4NuIAkWRNAAAAp7AgAAaZevk= References: <45AEC6EF95942140888406588E1A66025ABCE2@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Jim Reid X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Fine with me =20 Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Mo 13.11.2006 18:16 An: enum@ietf.org Cc: Jim Reid Betreff: RE: [Enum] Re: Last = Call:'InfrastrucureENUMRequirements'toInformationalRFC(draft-ietf-enum-in= frastructure-enum-reqs) Here is the specific text below. Any issues? If not I will post a new draft with this change tomorrow. 4. Zone Apex for Infrastructure ENUM The domain name chosed for infrastructure ENUM and any parent domains must be hosted on name servers that have performance characteristics and supporting infrastructure which is comparable to those deployed for the Internet root name servers. Those name servers for Infrastructure ENUM should be configured and operated according to the guidelines described in RFC 2870.=20 Regards Jason > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, November 13, 2006 12:01 PM > To: enum@ietf.org > Cc: Jim Reid > Subject: RE: [Enum] Re: Last Call: > 'InfrastrucureENUMRequirements'toInformationalRFC(draft-ietf-e > num-infrastructure-enum-reqs) > > Changes made. This is pretty similar to feedback that Otmar > Lendl sent as well. > > Jason > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, November 10, 2006 2:34 PM > > To: Pfautz, Penn L, GBLAM; Jim Reid; Livingood, Jason > > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; Pekka Savola; > > iesg@ietf.org > > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure > > ENUMRequirements'toInformational > > RFC(draft-ietf-enum-infrastructure-enum-reqs) > > > > Ok with me too > >=20 > > Richard > > > > ________________________________ > > > > Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Gesendet: Fr 10.11.2006 20:14 > > An: Jim Reid; Livingood, Jason > > Cc: enum@ietf.org; enum-chairs@tools.ietf.org; Pekka Savola; > > iesg@ietf.org > > Betreff: RE: [Enum] Re: Last Call: 'Infrastrucure > > ENUMRequirements'toInformational > > RFC(draft-ietf-enum-infrastructure-enum-reqs) > > > > > > > > This language works for me. Jason? Richard? > > > > Penn > > > > -----Original Message----- > > From: Jim Reid [mailto:jim@rfc1035.com] > > Sent: Friday, November 10, 2006 1:52 PM > > To: Livingood, Jason > > Cc: Pfautz, Penn L, GBLAM; Pekka Savola; enum@ietf.org; > > enum-chairs@tools.ietf.org; iesg@ietf.org > > Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM > > Requirements'toInformational RFC > > (draft-ietf-enum-infrastructure-enum-reqs) > > > > On Nov 10, 2006, at 18:07, Livingood, Jason wrote: > > > > > To second Penn's point... A new version of the I-D > > > draft-ietf-enum-infrastructure-02 is to go out soon, which > > addresses > > > this as follows: > > > > > 4. DNS Root for Infrastructure ENUM > > > > > > The top level DNS zone for infrastructure ENUM must > > support a level > > > of performance similar to that required for root servers > > (RFC 2870) > > > and must be independent of e164.arpa. > > > > Sorry, I cannot accept this text at all. Specific technical > terms are > > being misused: like "DNS Root" and "top level DNS zone" for example. > > RFC 2870 concentrates on name server configuration and > operation. It > > says *practically nothing* about performance. > > The RFC has no meaningful data points about query rates, response > > times, bandwidth requirements, service levels, etc, etc. I > am also not > > convinced there's any reason why this document needs to > mention domain > > names that can or can't be used for Infrastructure ENUM. > > > > How about: > > > > 4. Zone Apex for Infrastructure ENUM > > > > The domain name chosen for Infrastructure ENUM and any > parent domains > > must be hosted on name servers that have performance > characteristics > > and supporting infrastructure comparable to those deployed for the > > Internet root name servers. Those name servers for > Infrastructure ENUM > > should be configured and operated according to the guidelines > > described in RFC2870. > > > > _______________________________________________ > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 13 16:18:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjBQ-0006wN-8b; Mon, 13 Nov 2006 16:17:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjBO-0006wD-Gg for enum@ietf.org; Mon, 13 Nov 2006 16:17:34 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjjBN-00022J-7O for enum@ietf.org; Mon, 13 Nov 2006 16:17:34 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kADLHQX16928; Mon, 13 Nov 2006 16:17:26 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Mon, 13 Nov 2006 16:17:22 -0500 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C0E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thread-Index: AccCsul/6rrnmPEkSVCBLGAgA0VkbgAAJQkTAQKGv7AAKOzgGQAB25lw From: "James McEachern" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I understand that some countries have variable length numbering plans = for the PSTN. However it isn't clear to me why you would want to = perpetuate a "PSTN legacy" characteristic like this into the "SIP = optimized" world of ENUM only numbers. Just wondering... (perhaps this is where I should duck and run as = well;) Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, November 13, 2006 3:21 PM To: McEachern, James (CAR:AR00); enum@ietf.org Cc: Livingood, Jason Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Both =20 Richard ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Mo 13.11.2006 18:10 An: Stastny Richard; enum@ietf.org Cc: Livingood, Jason Betreff: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem I hesitate to ask, but... will ENUM only numbers be restricted to fixed = length numbering plans, or will they allow variable length numbering = plans? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, November 07, 2006 4:27 PM To: Niall O'Reilly Cc: enum@ietf.org; Livingood, Jason Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thank you for coming back to this Void is optional exept for ENUM only numbers, where it is required Richard ________________________________ Von: Niall O'Reilly [mailto:Niall.oReilly@ucd.ie] Gesendet: Di 07.11.2006 22:23 An: Pfautz, Penn L, GBLAM Cc: Niall O'Reilly; Michael Hammer (mhammer); Stastny Richard; = richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem On 7 Nov 2006, at 21:15, Pfautz, Penn L, GBLAM wrote: > If it's not harder to send an INVITE than to > do a DNS query one of the motivations for this draft would be gone. There would still be the residual motivation of preventing looping due to hot-potato call-routing configuration, which is mentioned at the end of Section 3 of the draft. Or this isn't significant? /Niall _______________________________________________ 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 enum-bounces@ietf.org Mon Nov 13 16:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjeX-0008AY-7h; Mon, 13 Nov 2006 16:47:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjeW-0008AQ-Pa for enum@ietf.org; Mon, 13 Nov 2006 16:47:40 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjjeV-0005yr-AZ for enum@ietf.org; Mon, 13 Nov 2006 16:47:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Mon, 13 Nov 2006 22:45:30 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C10@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem thread-index: AccCsul/6rrnmPEkSVCBLGAgA0VkbgAAJQkTAQKGv7AAKOzgGQAB25lwAAET6iU= References: From: "Stastny Richard" To: "James McEachern" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org You may be right, but people are used to it here to have the possibility to use extensions (DDI) =20 Richard ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Mo 13.11.2006 22:17 An: Stastny Richard; enum@ietf.org Cc: Livingood, Jason Betreff: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem I understand that some countries have variable length numbering plans = for the PSTN. However it isn't clear to me why you would want to = perpetuate a "PSTN legacy" characteristic like this into the "SIP = optimized" world of ENUM only numbers. Just wondering... (perhaps this is where I should duck and run as = well;) Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Monday, November 13, 2006 3:21 PM To: McEachern, James (CAR:AR00); enum@ietf.org Cc: Livingood, Jason Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Both Richard ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Mo 13.11.2006 18:10 An: Stastny Richard; enum@ietf.org Cc: Livingood, Jason Betreff: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem I hesitate to ask, but... will ENUM only numbers be restricted to fixed = length numbering plans, or will they allow variable length numbering = plans? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, November 07, 2006 4:27 PM To: Niall O'Reilly Cc: enum@ietf.org; Livingood, Jason Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thank you for coming back to this Void is optional exept for ENUM only numbers, where it is required Richard ________________________________ Von: Niall O'Reilly [mailto:Niall.oReilly@ucd.ie] Gesendet: Di 07.11.2006 22:23 An: Pfautz, Penn L, GBLAM Cc: Niall O'Reilly; Michael Hammer (mhammer); Stastny Richard; = richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem On 7 Nov 2006, at 21:15, Pfautz, Penn L, GBLAM wrote: > If it's not harder to send an INVITE than to > do a DNS query one of the motivations for this draft would be gone. There would still be the residual motivation of preventing looping due to hot-potato call-routing configuration, which is mentioned at the end of Section 3 of the draft. Or this isn't significant? /Niall _______________________________________________ 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 enum-bounces@ietf.org Tue Nov 14 16:49:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk67e-0002W6-7K; Tue, 14 Nov 2006 16:47:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk67d-0002W1-F5 for enum@ietf.org; Tue, 14 Nov 2006 16:47:13 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjiKH-0001vF-Nk for enum@ietf.org; Mon, 13 Nov 2006 15:22:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Date: Mon, 13 Nov 2006 21:21:27 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C0E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE:draft-ietf-enum-void-02 --> my problem thread-index: AccCsul/6rrnmPEkSVCBLGAgA0VkbgAAJQkTAQKGv7AAKOzgGQ== References: From: "Stastny Richard" To: "James McEachern" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Both =20 Richard ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Mo 13.11.2006 18:10 An: Stastny Richard; enum@ietf.org Cc: Livingood, Jason Betreff: RE: [Enum] RE:draft-ietf-enum-void-02 --> my problem I hesitate to ask, but... will ENUM only numbers be restricted to fixed = length numbering plans, or will they allow variable length numbering = plans? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, November 07, 2006 4:27 PM To: Niall O'Reilly Cc: enum@ietf.org; Livingood, Jason Subject: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem Thank you for coming back to this Void is optional exept for ENUM only numbers, where it is required Richard ________________________________ Von: Niall O'Reilly [mailto:Niall.oReilly@ucd.ie] Gesendet: Di 07.11.2006 22:23 An: Pfautz, Penn L, GBLAM Cc: Niall O'Reilly; Michael Hammer (mhammer); Stastny Richard; = richard@shockey.us; Livingood, Jason; enum@ietf.org Betreff: Re: [Enum] RE:draft-ietf-enum-void-02 --> my problem On 7 Nov 2006, at 21:15, Pfautz, Penn L, GBLAM wrote: > If it's not harder to send an INVITE than to > do a DNS query one of the motivations for this draft would be gone. There would still be the residual motivation of preventing looping due to hot-potato call-routing configuration, which is mentioned at the end of Section 3 of the draft. Or this isn't significant? /Niall _______________________________________________ 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 enum-bounces@ietf.org Wed Nov 15 15:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRiB-0004f0-Jn; Wed, 15 Nov 2006 15:50:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRhr-0004b6-9t; Wed, 15 Nov 2006 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRhr-0001yJ-1S; Wed, 15 Nov 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B32EC26E48; Wed, 15 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GkRhq-0008GD-2F; Wed, 15 Nov 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Nov 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vcard-05.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-05.txt Pages : 10 Date : 2006-11-15 This memo registers the Enumservice "vCard" with three subtypes (empty subtype, "xml", "rdf") using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-vcard-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-vcard-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-15125249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vcard-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vcard-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-15125249.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Nov 15 15:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRiu-0005AR-Sn; Wed, 15 Nov 2006 15:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRio-000531-V1; Wed, 15 Nov 2006 15:51:02 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRio-0002Aa-TS; Wed, 15 Nov 2006 15:51:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GkRio-0006LO-Je; Wed, 15 Nov 2006 15:51:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 841162AC6A; Wed, 15 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GkRhq-0008Gb-89; Wed, 15 Nov 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Nov 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-03.txt Pages : 6 Date : 2006-11-15 This document defines a use case as well as a proposal for a parallel namespace to “e164.arpa” as defined in RFC3761, to be used for Infrastructure ENUM purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-infrastructure-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-infrastructure-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-15134230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-infrastructure-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-infrastructure-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-15134230.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Nov 16 05:21:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkeLa-0005Ay-54; Thu, 16 Nov 2006 05:19:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkeLY-000579-8S for enum@ietf.org; Thu, 16 Nov 2006 05:19:52 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkeLW-0001Wv-Ve for enum@ietf.org; Thu, 16 Nov 2006 05:19:52 -0500 Received: from [10.10.0.134] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 16 Nov 2006 11:19:34 +0100 id 00000019.455C3B36.00003A20 Message-ID: <455C3B2D.50109@enum.at> Date: Thu, 16 Nov 2006 11:19:25 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Enum] Re: I-D ACTION:draft-ietf-enum-vcard-05.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Telephone Number Mapping Working Group of the IETF. > > Title : IANA Registration for vCard Enumservice > Author(s) : A. Mayrhofer > Filename : draft-ietf-enum-vcard-05.txt > Pages : 10 > Date : 2006-11-15 FYI - this version addresses comments received from AD review. Most important changes are: - renamed "plain" subtype to empty (n/a) subtype (also in accordance with "wild adoptions" of such services) - clarified security considerations, added examples there - added more text how to do access controls. alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 16 12:52:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklNN-00034S-Te; Thu, 16 Nov 2006 12:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklNM-00032V-E0 for enum@ietf.org; Thu, 16 Nov 2006 12:50:12 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklNH-0005Xl-8q for enum@ietf.org; Thu, 16 Nov 2006 12:50:12 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 16 Nov 2006 12:49:37 -0500 id 015880B2.455CA4B1.00004A85 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: enum@ietf.org From: Andrew Newton Date: Thu, 16 Nov 2006 12:49:46 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Enum] patent on ENUM X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org As anybody run across US Pat. 6,347,085? I looked on the IETF IPR page and there are no disclosures. The claims in this patent certainly seem to illustrate how ENUM works. Should a third party disclosure be filed? -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 17 05:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl0fs-0005wb-JK; Fri, 17 Nov 2006 05:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl0fs-0005wW-3M for enum@ietf.org; Fri, 17 Nov 2006 05:10:20 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl0fo-0004Pq-Ga for enum@ietf.org; Fri, 17 Nov 2006 05:10:20 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id kAHAA8ck012251Fri, 17 Nov 2006 10:10:08 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Gl0ff-0008Yo-00; Fri, 17 Nov 2006 10:10:07 +0000 Date: Fri, 17 Nov 2006 10:10:07 +0000 From: "Clive D.W. Feather" To: Andrew Newton Subject: Re: [Enum] patent on ENUM Message-ID: <20061117101007.GH21779@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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Andrew Newton said: > As anybody run across US Pat. 6,347,085? I looked on the IETF IPR > page and there are no disclosures. > > The claims in this patent certainly seem to illustrate how ENUM works. > > Should a third party disclosure be filed? I don't think it's needed. The only important thing in the patent is the actual claims, starting on column 18, page 17. There are 17 claims, but the important ones are claims 1 and 11 - the remainder are variations on these and so subsidiary to them. Claim 1 has two key elements that we need to consider: (1) Connecting a computer on a packet-switched network to the PSTN using a gateway device. Thus it does not apply to any system that doesn't work through a gateway device. That immediately rules out many uses of ENUM, and makes it clear that it's the gateway device manufacturers/operators that need to worry about the patent. (2) "generating a telephone number domain name [...] by reversing the order in which the segments of the telephone number were received without modifying the sequence of numbers within each segment" This second element is not the way in which ENUM works. Even discounting the question of which root domain is used, let's look at my telephone number: ENUM: 8.3.1.6.5.9.4.8.0.2.4.4.root-domain Patent: 6138.8495.20.44.root-domain or [1]: 84956138.20.44.root-domain or [2]: 6138.495.208.44.root-domain This is different enough (even if there isn't a prior art issue) that it can be (IMHO) ignored. Claim 11 is for a complete software product to carry out the steps including connecting to the gateway. Thus the same differences apply and again don't concern us. He has *NOT* claimed a patent on converting telephone numbers to domain names. [1] The patent is unclear whether 8-digit numbers should be split into two fours. It talks about "exchange data" in column 12, but London telephone numbers aren't split into exchanges like that. [2] A lot of people wrongly believe that my area code is 0208. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 17 06:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1UF-0001ql-MR; Fri, 17 Nov 2006 06:02:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1UE-0001oa-AO for enum@ietf.org; Fri, 17 Nov 2006 06:02:22 -0500 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl1U5-0005Pl-Pn for enum@ietf.org; Fri, 17 Nov 2006 06:02:22 -0500 Received: from [195.54.244.2] (account jim HELO [172.16.1.100]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 111554; Fri, 17 Nov 2006 11:02:01 +0000 In-Reply-To: References: <01b801c7066a$fb29d030$22f0a544@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F07E581-F0A7-47F2-A1BC-6235A9CF2F9A@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Fri, 17 Nov 2006 11:02:03 +0000 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: enum@ietf.org, "'Livingood, Jason'" , "'Pfautz, Penn L, GBLAM'" , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Nov 16, 2006, at 21:05, Pekka Savola wrote: > It is not obvious to me what 'performance characteristics and > supporting infrastructure comparable to those deployed for the > Internet root name servers.' really means, whether this is the real > requirement, and what are even the figures for root name servers. This vagueness was deliberate. :-) The capacity that the root servers have is not usually published for the obvious reason that it tells the bad guys just what the limits are. [Some do publish statistics on the query rates they get.] And that capacity is forever changing anyway: systems get beefed up, more anycast nodes come on-line, extra bandwidth is added, peering arrangements at IXes change, etc, etc. The point of the original text was to say that whatever zone apex is chosen for Infrastructure ENUM, it better have infrastructure at least as good as that for the root servers. Which seems a reasonable heuristic. > There are in the order of O(100) root name server instances at the > moment [http://www.root-servers.org]. Are you referring to the > aggregate performance of all these instances? That would likely be > overengineering, so I suspect the real performance required is > somewhat lower.. It depends on what you mean by "real" performance. In a perfect world, there would be no broken DNS software or misconfigured name servers saturating the root servers with crap. Look at the CAIDA paper from a few years ago about root server traffic. 95% of the queries they get are bogus. Now are those queries "real" or not? In one sense they are because the packets arrive at the servers and need to be answered. In another sense they're not because they cannot be extrapolated from any analysis of how "normal" (well behaved and properly configured) DNS clients do lookups. Oh and lets not overlook the impact of DDoS attacks. Even if everyone in Infrastructure ENUM is well behaved, what if there's a rogue operator or a script kiddie gets into an operator's core network? [Flooding DNS servers with traffic to bring down the world's phone system would be a really juicy target.] Or what if someone's DNS software goes berserk and generates far more traffic than it should? > Having more specific data -- if anyone has sat down and done > calculations on what's really needed -- would be useful. I agree this would be a good exercise. But the upper bounds on what's really needed should be at least one or two orders of magnitude greater than the results of those calculations. Again, this is where guidance from the root server operators could be valuable. After all they have years of real world experience running critical DNS infrastructure in a hostile environment. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 17 10:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5e6-0002gr-VC; Fri, 17 Nov 2006 10:28:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5e6-0002gg-Ed for enum@ietf.org; Fri, 17 Nov 2006 10:28:50 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl5e0-0002EE-81 for enum@ietf.org; Fri, 17 Nov 2006 10:28:50 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 17 Nov 2006 10:28:19 -0500 id 015880B9.455DD513.00001CCF In-Reply-To: <20061117101007.GH21779@finch-staff-1.thus.net> References: <20061117101007.GH21779@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Enum] patent on ENUM Date: Fri, 17 Nov 2006 10:19:36 -0500 To: "Clive D.W. Feather" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Clive, Thanks for your response. Comments in-line: On Nov 17, 2006, at 5:10 AM, Clive D.W. Feather wrote: > Claim 1 has two key elements that we need to consider: > (1) Connecting a computer on a packet-switched network to the PSTN > using > a gateway device. > > Thus it does not apply to any system that doesn't work through a > gateway > device. That immediately rules out many uses of ENUM, and makes it > clear > that it's the gateway device manufacturers/operators that need to > worry > about the patent. Using ENUM to get a SIP URI which is a gateway seems to me that it might be a common use of ENUM, though I have actually not seen setups that do it. > (2) "generating a telephone number domain name [...] by reversing > the order > in which the segments of the telephone number were received > without > modifying the sequence of numbers within each segment" > > This second element is not the way in which ENUM works. Even > discounting > the question of which root domain is used, let's look at my telephone > number: > > ENUM: 8.3.1.6.5.9.4.8.0.2.4.4.root-domain > Patent: 6138.8495.20.44.root-domain > or [1]: 84956138.20.44.root-domain > or [2]: 6138.495.208.44.root-domain > > This is different enough (even if there isn't a prior art issue) > that it > can be (IMHO) ignored. Thanks for pointing this out. I, for some reason, was thinking each segment was only one digit long. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 17 10:40:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5oT-0007xl-3s; Fri, 17 Nov 2006 10:39:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5oR-0007xR-5W for enum@ietf.org; Fri, 17 Nov 2006 10:39:31 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl5oQ-0003jF-0B for enum@ietf.org; Fri, 17 Nov 2006 10:39:31 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 5F9D2980E5E; Fri, 17 Nov 2006 10:39:29 -0500 (EST) To: andy@hxr.us, clive@demon.net Subject: Re: [Enum] patent on ENUM In-Reply-To: Message-Id: <20061117153929.5F9D2980E5E@newdev.harvard.edu> Date: Fri, 17 Nov 2006 10:39:29 -0500 (EST) From: sob@harvard.edu (Scott Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > Thanks for pointing this out. I, for some reason, was thinking each > segment was only one digit long. even if that were the case RFC 1486 is rather good prior art (which should have been cited to the patent office since someone (patent exanminer or inventor) cited another RFC (RFC 1789) Scott _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 19 11:24:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpPU-0003Yo-CY; Sun, 19 Nov 2006 11:20:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpPT-0003Yc-0Z for enum@ietf.org; Sun, 19 Nov 2006 11:20:47 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlpPR-00031o-JS for enum@ietf.org; Sun, 19 Nov 2006 11:20:46 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kAJGKgN7000825 for ; Sun, 19 Nov 2006 08:20:50 -0800 From: "Richard Shockey" To: Date: Sun, 19 Nov 2006 11:20:23 -0500 Message-ID: <017601c70bf6$a35ab680$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Thread-Index: AccI99ZhS4v7Ix9ZSviT8dlJzfgURgC/q76g X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Is the WG satisified that this document is finished and we can go to = last call? > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, November 15, 2006 3:50 PM > To: i-d-announce@ietf.org > Cc: enum@ietf.org > Subject: I-D ACTION:draft-ietf-enum-infrastructure-03.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Telephone Number Mapping Working = Group of > the IETF. >=20 > Title : The E.164 to Uniform Resource Identifiers > (URI) Dynamic Delegation Discovery System > (DDDS) Application for Infrastructure ENUM > Author(s) : J. Livingood, et al. > Filename : draft-ietf-enum-infrastructure-03.txt > Pages : 6 > Date : 2006-11-15 >=20 > This document defines a use case as well as a proposal for a parallel > namespace to =13e164.arpa=14 as defined in RFC3761, to be used for > Infrastructure ENUM purposes. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-03.txt= >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-enum-infrastructure-03.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-infrastructure-03.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 19 14:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlsPo-0004rc-Ng; Sun, 19 Nov 2006 14:33:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoSU-0001e4-0X for enum@ietf.org; Thu, 16 Nov 2006 16:07:42 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkoSQ-0006gy-Hh for enum@ietf.org; Thu, 16 Nov 2006 16:07:41 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kAGL5TvU025367; Thu, 16 Nov 2006 23:05:30 +0200 Date: Thu, 16 Nov 2006 23:05:29 +0200 (EET) From: Pekka Savola To: Richard Shockey Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) In-Reply-To: <01b801c7066a$fb29d030$22f0a544@cis.neustar.com> Message-ID: References: <01b801c7066a$fb29d030$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2198/Thu Nov 16 01:19:47 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Sun, 19 Nov 2006 14:33:19 -0500 Cc: enum@ietf.org, 'Jim Reid' , "'Livingood, Jason'" , "'Pfautz, Penn L, GBLAM'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org By the way, hopefully the rest of the review wasn't forgotten, as all discussion has been about this one topic.. On Sun, 12 Nov 2006, Richard Shockey wrote: > > How about: > > > > 4. Zone Apex for Infrastructure ENUM > > > > The domain name chosen for Infrastructure ENUM and any parent domains > > must be hosted on name servers that have performance characteristics > > and supporting infrastructure comparable to those deployed for the > > Internet root name servers. Those name servers for Infrastructure > > ENUM should be configured and operated according to the guidelines > > described in RFC2870. It is not obvious to me what 'performance characteristics and supporting infrastructure comparable to those deployed for the Internet root name servers.' really means, whether this is the real requirement, and what are even the figures for root name servers. There are in the order of O(100) root name server instances at the moment [http://www.root-servers.org]. Are you referring to the aggregate performance of all these instances? That would likely be overengineering, so I suspect the real performance required is somewhat lower.. Having more specific data -- if anyone has sat down and done calculations on what's really needed -- would be useful. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 19 15:38:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltPq-0001BB-Fr; Sun, 19 Nov 2006 15:37:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltPo-0001B3-Km for enum@ietf.org; Sun, 19 Nov 2006 15:37:24 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GltPh-0005uW-EY for enum@ietf.org; Sun, 19 Nov 2006 15:37:24 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 206218B006; Sun, 19 Nov 2006 20:37:06 +0000 (GMT) In-Reply-To: References: <01b801c7066a$fb29d030$22f0a544@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B71DB70-61FD-4823-93AD-BF1CACCB80FF@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) Date: Sun, 19 Nov 2006 20:37:05 +0000 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: enum@ietf.org, 'Jim Reid' , "'Livingood, Jason'" , "'Pfautz, Penn L, GBLAM'" , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Pekka, folks, One would hope this refers to the service provided by the cloud. However, the setup delay budget for PSTN calls (and one assumes for the VoIP provided calls as well, Jason?) is tight. Having to retransmit an ENUM query prior to placing a call because a DNS instance/cluster is down would be bad - not disastrous, but bad. Given the current performance and reliability of PSTN infrastructure I don't believe that Section 4's proposal would be overkill - it is readily achievable, and not out of keeping with existing infrastructure or service providers' expectations. What it means in the real world is up to the providers - they are the ones who pay for the system, and are very used to specifying service availability and performance. IMHO, it would not really be appropriate for an IETF document to delve too far into PSTN operational and performance requirements - (that's their job :). I of course ignore mobile/cell phone set up - one could do that with a bit of wet string and a pair of PCs. This really has to do better. You simply can't expect a service provider (or its customers) to be happy with a system that can go out of service randomly and is not properly funded and maintained. Advice to infrastructure maintainers in every Country in the World is worthwhile, IMHO. The reference to 2870 is exactly what is needed from an IETF document. Less would be unfair to those whose expertise lies in other areas, more would require that the IETF first has to gain their PSTN infrastructure operational expertise. As is, this document might come out before the authors retire. all the best, Lawrence On 16 Nov 2006, at 21:05, Pekka Savola wrote: > By the way, hopefully the rest of the review wasn't forgotten, as all > discussion has been about this one topic.. > > On Sun, 12 Nov 2006, Richard Shockey wrote: >>> How about: >>> >>> 4. Zone Apex for Infrastructure ENUM >>> >>> The domain name chosen for Infrastructure ENUM and any parent >>> domains >>> must be hosted on name servers that have performance characteristics >>> and supporting infrastructure comparable to those deployed for the >>> Internet root name servers. Those name servers for Infrastructure >>> ENUM should be configured and operated according to the guidelines >>> described in RFC2870. > > It is not obvious to me what 'performance characteristics and > supporting infrastructure comparable to those deployed for the > Internet root name servers.' really means, whether this is the real > requirement, and what are even the figures for root name servers. > > There are in the order of O(100) root name server instances at the > moment [http://www.root-servers.org]. Are you referring to the > aggregate performance of all these instances? That would likely be > overengineering, so I suspect the real performance required is > somewhat lower.. > > Having more specific data -- if anyone has sat down and done > calculations on what's really needed -- would be useful. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 19 15:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltZH-0004YE-Gi; Sun, 19 Nov 2006 15:47:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltZG-0004Y9-Ti for enum@ietf.org; Sun, 19 Nov 2006 15:47:10 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GltZF-0007WT-IH for enum@ietf.org; Sun, 19 Nov 2006 15:47:10 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 1A7BE8B018; Sun, 19 Nov 2006 20:47:09 +0000 (GMT) In-Reply-To: <017601c70bf6$a35ab680$22f0a544@cis.neustar.com> References: <017601c70bf6$a35ab680$22f0a544@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32A272DE-CF3F-446D-A77F-1BD7310D4BE4@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt Date: Sun, 19 Nov 2006 20:47:08 +0000 To: richard@shockey.us X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, folks, I'm happy with this draft as it is - it's short, covers the bases, and is readable. For completeness, some Regulators have suggested that the identity of the service provider should not be readily discernible from data published to all, as this might allow someone to "walk the tree" and find out who is the "carrier of record" for a given number. However, this is unlikely to be an issue globally, as it might only affect a very small number of regimes. [If you want to keep even the lame happy, replace "provider" with "AS1234" or its equivalent in the examples of section 5]. IMHO, it's not important. all the best, Lawrence On 19 Nov 2006, at 16:20, Richard Shockey wrote: > Is the WG satisified that this document is finished and we can go > to last > call? >> http://www.ietf.org/internet-drafts/draft-ietf-enum- >> infrastructure-03.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 19 21:56:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlzIA-0005ip-Ut; Sun, 19 Nov 2006 21:53:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlzI9-0005ih-OT for enum@ietf.org; Sun, 19 Nov 2006 21:53:53 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlzI7-0003uw-Hj for enum@ietf.org; Sun, 19 Nov 2006 21:53:53 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20061120025350b1100sn15ee>; Mon, 20 Nov 2006 02:53:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAK2rnFL024698 for ; Sun, 19 Nov 2006 21:53:49 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAK2rnD8024694; Sun, 19 Nov 2006 21:53:49 -0500 Date: Sun, 19 Nov 2006 21:53:49 -0500 Message-Id: <200611200253.kAK2rnD8024694@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <017601c70bf6$a35ab680$22f0a544@cis.neustar.com> (richard@shockey.us) Subject: Re: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt References: <017601c70bf6$a35ab680$22f0a544@cis.neustar.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: "Richard Shockey" Is the WG satisified that this document is finished and we can go to last call? Take the non-ASCII characters out: \223 and \224 appear in the Abstract. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 20 09:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAYJ-0000Qt-5Q; Mon, 20 Nov 2006 09:55:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAYH-0000OY-72 for enum@ietf.org; Mon, 20 Nov 2006 09:55:17 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAYE-0005Dh-Ux for enum@ietf.org; Mon, 20 Nov 2006 09:55:17 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kAKEp37w006037; Mon, 20 Nov 2006 06:51:09 -0800 From: "Richard Shockey" To: Subject: RE: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt Date: Mon, 20 Nov 2006 09:50:26 -0500 Message-ID: <025401c70cb3$3877c0c0$78201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccMTyjPgXln2K5OQrOfysn1NMpnygAY9L9g In-Reply-To: <200611200253.kAK2rnD8024694@dragon.ariadne.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Alexander Mayrhofer' , "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Plus it seems it needs an introduction as well. All drafts are required to have an "Introduction" Section per the document below: http://www.ietf.org/ID-Checklist.html#anchor4 It looks like it needs a 04 ... and then a NIT Check from Alexander > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Sunday, November 19, 2006 9:54 PM > To: enum@ietf.org > Subject: Re: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt > > From: "Richard Shockey" > > Is the WG satisified that this document is finished and we can go to > last > call? > > Take the non-ASCII characters out: \223 and \224 appear in the Abstract. > > Dale > > _______________________________________________ > 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 enum-bounces@ietf.org Mon Nov 20 09:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAbd-0003hJ-Bo; Mon, 20 Nov 2006 09:58:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAba-0003b3-Tq for enum@ietf.org; Mon, 20 Nov 2006 09:58:43 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAbY-0005PX-Jv for enum@ietf.org; Mon, 20 Nov 2006 09:58:42 -0500 Received: from [10.10.0.218] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 20 Nov 2006 15:58:12 +0100 id 00000019.4561C284.00006ECF Message-ID: <4561C277.20507@enum.at> Date: Mon, 20 Nov 2006 15:57:59 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: richard@shockey.us Subject: Re: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt References: <025401c70cb3$3877c0c0$78201f0a@cis.neustar.com> In-Reply-To: <025401c70cb3$3877c0c0$78201f0a@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: enum@ietf.org, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > Plus it seems it needs an introduction as well. > > > All drafts are required to have an "Introduction" Section per the document > below: > > > http://www.ietf.org/ID-Checklist.html#anchor4 > > It looks like it needs a 04 ... and then a NIT Check from Alexander i will do another NIT check on 03 - please expect feedback later today. alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 20 10:07:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAip-0000AB-QG; Mon, 20 Nov 2006 10:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAip-0000A1-8a for enum@ietf.org; Mon, 20 Nov 2006 10:06:11 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmAim-0005vc-Qr for enum@ietf.org; Mon, 20 Nov 2006 10:06:11 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 20 Nov 2006 16:05:19 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C526C@oefeg-s04.oefeg.loc> In-Reply-To: <025401c70cb3$3877c0c0$78201f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt Thread-Index: AccMTyjPgXln2K5OQrOfysn1NMpnygAY9L9gAACA34A= From: "Stastny Richard" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Livingood, Jason" , Alexander Mayrhofer X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > Plus it seems it needs an introduction as well. Is the section 2. Introduction not enough or am I missing here something? What I could imagine is to swap section 3. and 4 Richard > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, November 20, 2006 3:50 PM > To: enum@ietf.org > Cc: 'Alexander Mayrhofer'; 'Livingood, Jason' > Subject: RE: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt >=20 >=20 > Plus it seems it needs an introduction as well. >=20 >=20 > All drafts are required to have an "Introduction" Section per the document > below: >=20 >=20 > http://www.ietf.org/ID-Checklist.html#anchor4 >=20 > It looks like it needs a 04 ... and then a NIT Check from Alexander >=20 >=20 >=20 > > -----Original Message----- > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > Sent: Sunday, November 19, 2006 9:54 PM > > To: enum@ietf.org > > Subject: Re: [Enum] RE: I-D ACTION:draft-ietf-enum-infrastructure-03.txt > > > > From: "Richard Shockey" > > > > Is the WG satisified that this document is finished and we can go to > > last > > call? > > > > Take the non-ASCII characters out: \223 and \224 appear in the > Abstract. > > > > Dale > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 > _______________________________________________ > 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 enum-bounces@ietf.org Mon Nov 20 10:40:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBEf-000153-2O; Mon, 20 Nov 2006 10:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBEd-000149-DK for enum@ietf.org; Mon, 20 Nov 2006 10:39:03 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBEc-0000SH-3g for enum@ietf.org; Mon, 20 Nov 2006 10:39:03 -0500 Received: from [10.10.0.218] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 20 Nov 2006 16:38:43 +0100 id 00000019.4561CC03.000077D5 Message-ID: <4561CBF0.1060600@enum.at> Date: Mon, 20 Nov 2006 16:38:24 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "'enum@ietf.org'" , Stastny Richard , "Livingood, Jason" , "Pfautz, Penn L, NEO" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Enum] NITS review of draft-ietf-enum-infrastructure-03 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I've found the following issues with the current draft: - Boilerplate: I believe that rsn, the I-D-Team will only accept drafts with the new boilerplate (recognizing the IETF Trust). Please update accordingly. - Abstract: There are non-ASCII-Characters around e164.arpa - most probably "fancy" apostrophes... Please remove them. - ToC: The title of section 4 in the ToC differs from the title of the section itself. Please fix. - Terminology: The draft does not contain a single instanct of RFC2119-style key words. Hence, either remove that section, or add such key words where they should apply. In that case it is being kept, please add a proper reference to RFC 2119 (currently, the reference does not point to the list of references). - Section 4, Section 3: I'd rather swap them. - (current) Section 4: Please add a reference (informative, probably) to RFC 2870. - Section 5: Please use only "example.com/.net/.org" (or subdomains off there) in the examples. Simply appending one of the TLDs to the example URIs will do.. - References: Some of them are never used in the document (like [5], [6], [7], [8], [9] (btw, that doesn't seem to have it's place here anyway)). If you really want to refer to obsoleted RFC 2916, please put it into the "informative" section. hope that helps. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 20 11:41:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCB2-0005O6-B3; Mon, 20 Nov 2006 11:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCB1-0005MU-9i for enum@ietf.org; Mon, 20 Nov 2006 11:39:23 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCAy-0005Mh-So for enum@ietf.org; Mon, 20 Nov 2006 11:39:23 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kAKGdBlx029773; Mon, 20 Nov 2006 08:39:18 -0800 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , , "'Stastny Richard'" , "'Livingood, Jason'" , "'Pfautz, Penn L, NEO'" Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03 Date: Mon, 20 Nov 2006 11:38:58 -0500 Message-ID: <004e01c70cc2$61cde260$78201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4561CBF0.1060600@enum.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccMuguEcalGFy9BQ4eRbNxVW9iHagACD04g X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > I've found the following issues with the current draft: > > - Boilerplate: I believe that rsn, the I-D-Team will only accept drafts > with > the new boilerplate (recognizing the IETF Trust). Please update > accordingly. > > - Abstract: There are non-ASCII-Characters around e164.arpa - most > probably > "fancy" apostrophes... Please remove them. > > - ToC: The title of section 4 in the ToC differs from the title of the > section itself. Please fix. > > - Terminology: The draft does not contain a single instanct of RFC2119- > style > key words. Hence, either remove that section, or add such key words where > they should apply. In that case it is being kept, please add a proper > reference to RFC 2119 (currently, the reference does not point to the list > of references). > > - Section 4, Section 3: I'd rather swap them. Sound right to me as well. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 20 11:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCS8-0007hv-55; Mon, 20 Nov 2006 11:57:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCS6-0007hq-L4 for enum@ietf.org; Mon, 20 Nov 2006 11:57:02 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCS5-0006Ub-7M for enum@ietf.org; Mon, 20 Nov 2006 11:57:02 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 3A0238B292; Mon, 20 Nov 2006 16:57:00 +0000 (GMT) In-Reply-To: <4561CBF0.1060600@enum.at> References: <4561CBF0.1060600@enum.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03 Date: Mon, 20 Nov 2006 16:56:58 +0000 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "'enum@ietf.org'" , Stastny Richard , "Livingood, Jason" , "Pfautz, Penn L, NEO" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, OK, whilst we're at the level of boilerplate changes, I believe that I-Ds are supposed to indicate their intended status (i.e. what track they're on). Most all of the other drafts in the WG don't, but at the top of the document you could put in "Intended Status: Informational". Look at as an example of a draft aimed at BCP status. (It's VERY easy to do if the draft is XML-based and uses XML2RFC). Also, the citation of the requirements document needs to be updated. all the best, Lawrence On 20 Nov 2006, at 15:38, Alexander Mayrhofer wrote: > I've found the following issues with the current draft: > > - Boilerplate: I believe that rsn, the I-D-Team will only accept > drafts with > the new boilerplate (recognizing the IETF Trust). Please update > accordingly. > > - Abstract: There are non-ASCII-Characters around e164.arpa - most > probably > "fancy" apostrophes... Please remove them. > > - ToC: The title of section 4 in the ToC differs from the title of the > section itself. Please fix. > > - Terminology: The draft does not contain a single instanct of > RFC2119-style > key words. Hence, either remove that section, or add such key words > where > they should apply. In that case it is being kept, please add a proper > reference to RFC 2119 (currently, the reference does not point to > the list > of references). > > - Section 4, Section 3: I'd rather swap them. > > - (current) Section 4: Please add a reference (informative, > probably) to RFC > 2870. > > - Section 5: Please use only "example.com/.net/.org" (or subdomains > off > there) in the examples. Simply appending one of the TLDs to the > example URIs > will do.. > > - References: Some of them are never used in the document (like > [5], [6], > [7], [8], [9] (btw, that doesn't seem to have it's place here > anyway)). If > you really want to refer to obsoleted RFC 2916, please put it into the > "informative" section. > > > hope that helps. > > Alex > > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 21 10:21:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXQM-0004UK-LE; Tue, 21 Nov 2006 10:20:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXQK-0004U0-SU for enum@ietf.org; Tue, 21 Nov 2006 10:20:36 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXQJ-0005Ck-JE for enum@ietf.org; Tue, 21 Nov 2006 10:20:36 -0500 Received: from [10.10.0.218] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 21 Nov 2006 16:20:22 +0100 id 0000002C.45631936.000005F0 Message-ID: <45631923.8030802@enum.at> Date: Tue, 21 Nov 2006 16:20:03 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03 References: <4561CBF0.1060600@enum.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'enum@ietf.org'" , Stastny Richard , "Livingood, Jason" , "Pfautz, Penn L, NEO" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi Folks, > OK, whilst we're at the level of boilerplate changes, I believe that I-Ds > are supposed to indicate their intended status (i.e. what track they're > on). > Most all of the other drafts in the WG don't, but at the top of the > document > you could put in "Intended Status: Informational". yep. Afaik leaving that out means "standards track". > Look at as an example of a draft aimed at > BCP status. (It's VERY easy to do if the draft is XML-based and uses > XML2RFC). > > Also, the citation of the requirements document needs to be updated. thanks for catching that, Lawrence. cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 22 00:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmkUc-0007xJ-Tl; Wed, 22 Nov 2006 00:17:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmkUb-0007xE-GU for enum@ietf.org; Wed, 22 Nov 2006 00:17:53 -0500 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmkUa-0002EN-5w for enum@ietf.org; Wed, 22 Nov 2006 00:17:53 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20061122051751m1500aphuse>; Wed, 22 Nov 2006 05:17:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAM5Ho5K015401 for ; Wed, 22 Nov 2006 00:17:50 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAM5HovP015397; Wed, 22 Nov 2006 00:17:50 -0500 Date: Wed, 22 Nov 2006 00:17:50 -0500 Message-Id: <200611220517.kAM5HovP015397@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I hope this isn't too late for the Last Call... In regard to draft-ietf-enum-infrastructure-enum-reqs-03.txt: * Section 2.1. Definition It would make reading easier, IMO, if the first uses of the phrases "infrastructure ENUM" and "user ENUM" were quoted (as I just did) -- the terms really have meaning only as phrases, and it is helpful to the naive reader to use quotes to point that out. (A lot of math books will italicize any phrase the first time it is defined, which makes it clear the exact extent of the term being defined.) The first sentence is also rather complex, and is structured in a way that is a bit unnatural -- it uses the construction "use of the technology in RFC 3761 to map a telephone number", but the action isn't the mapping itself, the action is the *publishing* of a mapping. A clearer phrasing would be: "Infrastructure ENUM" is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to publish the mappping of the E.164 number into a URI [4] that identifies a specific point of interconnection to that carrier's network that could enable an originating party to establish communication with the [a?] terminating party identified by the E.164 number. Infrastructure ENUM is separate from any URIs that the end-user of the E.164 number may wish to associate with that number. Infrastructure ENUM is distinguished from "user ENUM", defined in ... From a domain registration perspective, in user ENUM, the end user number assignee is the registrant; in infrastructure ENUM, the carrier-of-record is the registrant. ... There is also a lot of test discussing what is a "carrier-of-record". But it seems to me that this is not a good idea -- if "infrastructure ENUM" is to mean anything, the concept of the "carrier-of-record of an E.164 number" must *already* be defined by some mechanism outside of ENUM. It might be useful to elucidate what the various possibilities are, but the text must make clear that carrier-of-record is externally defined. Moving the discussion to section 2.2 seems to be a good idea. * Section 2.2. Background This sentence reads better without the reference to the DNS tree apex. If there are real statements to be made about the apex, they should be in the requirements: Infrastructure ENUM allows service providers to link Internet based resources such as URIs to E.164 numbers. These sentences should be joined with a dash or semicolon: There is also no guarantee that the originating service provider querying infrastructure ENUM is able to access the ingress network element of the destination provider's network; additional peering and accounting agreements requiring authentication may be necessary. * Section 3, item 1 Add a hyphen: in a single common publicly-accessible namespace. * Section 3, item 2 2. Queries of infrastructure ENUM fully qualified domain names MUST return a result, even if the result is a Name Error (RCODE = 3). Queries must not be rejected, e.g., based on access control lists. This seems to narrow the issue to a specific detail. Better would be a general statement: 2. Queries of infrastructure ENUM fully qualified domain names MUST return the same result regardless of the source of the query. Returning an empty response based on access control is no more helpful than returning an NXDOMAIN based on access control. * Section 3, item 8D It seems like this could be better phrased: D. Minimize the DNS efford required to obtain the complete set of infrastructure ENUM DNS records. Or perhaps "... of infrastructure and user ENUM DNS records". * Section 3, items 5 and 8F The term "end-user ENUM" is used in these items, but that term is not defined. "User ENUM" is probably meant. * Section 3, item 8G Add spaces in "private ENUM trees. (In this context". * Section 3, additional item This section needs a requirement statement about the interaction of infrastructure ENUM with E.164 number portability. And given that the number portability policies in various E.164 subdomains are likely to change over time, number portability requirements seem to be particularly important to specify well. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 22 10:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmu8Q-0006V5-T3; Wed, 22 Nov 2006 10:35:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmu8P-0006Uk-M9 for enum@ietf.org; Wed, 22 Nov 2006 10:35:37 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gmu8N-0007Kt-9U for enum@ietf.org; Wed, 22 Nov 2006 10:35:37 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1164209733!18217159!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25211 invoked from network); 22 Nov 2006 15:35:33 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-8.tower-120.messagelabs.com with SMTP; 22 Nov 2006 15:35:33 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAMFZWRY022879; Wed, 22 Nov 2006 10:35:33 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAMFZR3s022844; Wed, 22 Nov 2006 10:35:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Date: Wed, 22 Nov 2006 10:35:26 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <200611220517.kAM5HovP015397@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Thread-Index: AccN9lbE1uYq5Hm6ReWxU1Yhj7iL+wAU9j1A From: "Pfautz, Penn L, GBLAM" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dale: Thanks for your comments. I'm looking through the ones on explication but wanted to address some substantive ones Below: Penn=20 -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Wednesday, November 22, 2006 12:18 AM To: enum@ietf.org Subject: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs >There is also a lot of test discussing what is a "carrier-of-record". >But it seems to me that this is not a good idea -- if "infrastructure >ENUM" is to mean anything, the concept of the "carrier-of-record of an >E.164 number" must *already* be defined by some mechanism outside of >ENUM. It might be useful to elucidate what the various possibilities >are, but the text must make clear that carrier-of-record is externally >defined. Moving the discussion to section 2.2 seems to be a good idea. I believe the bullets in 2.1 make clear that carrier-of-record *is* externally defined and how in an easy to operationalize way while noting that national regulators have the final say. >* Section 3, item 2 > > 2. Queries of infrastructure ENUM fully qualified domain names MUST > return a result, even if the result is a Name Error (RCODE =3D = 3). > Queries must not be rejected, e.g., based on access control > lists. > >This seems to narrow the issue to a specific detail. Better would be >a general statement: > > 2. Queries of infrastructure ENUM fully qualified domain names MUST > return the same result regardless of the source of the query. > >Returning an empty response based on access control is no more helpful >than returning an NXDOMAIN based on access control. This requirement was to address a specific request from the chairs that queries not simply be dropped on the floor without response causing re-queries and traffic flood.=20 The requirement you propose is actually much different and, while the initial (e.g., Tier 1) response may not be origin-sensitive, further processing is likely to be since A carrier may have different POIs for different interconnection partners. >* Section 3, additional item > >This section needs a requirement statement about the interaction of >infrastructure ENUM with E.164 number portability. And given that the >number portability policies in various E.164 subdomains are likely to >change over time, number portability requirements seem to be particularly >important to specify well. I think the carrier-of-record definition has clear implications about the relationship Of infrastructure ENUM to number portability: if the number ports the right to register it moves to the recipient carrier as well.=20 _______________________________________________ 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 enum-bounces@ietf.org Wed Nov 22 11:33:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv1n-0004eu-6v; Wed, 22 Nov 2006 11:32:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv1l-0004ee-7h for enum@ietf.org; Wed, 22 Nov 2006 11:32:49 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmv1j-0007oD-UR for enum@ietf.org; Wed, 22 Nov 2006 11:32:49 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20061122163247b1100slbuve>; Wed, 22 Nov 2006 16:32:47 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAMGWk5K032561 for ; Wed, 22 Nov 2006 11:32:46 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAMGWkQc032557; Wed, 22 Nov 2006 11:32:46 -0500 Date: Wed, 22 Nov 2006 11:32:46 -0500 Message-Id: <200611221632.kAMGWkQc032557@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> (ppfautz@att.com) Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: "Pfautz, Penn L, GBLAM" >There is also a lot of test discussing what is a "carrier-of-record". >But it seems to me that this is not a good idea -- if "infrastructure >ENUM" is to mean anything, the concept of the "carrier-of-record of an >E.164 number" must *already* be defined by some mechanism outside of >ENUM. It might be useful to elucidate what the various possibilities >are, but the text must make clear that carrier-of-record is externally >defined. Moving the discussion to section 2.2 seems to be a good idea. I believe the bullets in 2.1 make clear that carrier-of-record *is* externally defined and how in an easy to operationalize way while noting that national regulators have the final say. I found the discussion quite confusing. Let me try to explain why: At the end of paragraph 2 of section 2.1, it says 'The "carrier-of-record" is:', and since the section is titled "Definition", this suggests that section 2.1 is authoritative in defining the term. Then there are three bullets which are presented as alternatives to each other, but it's not particularly clear which one applies in what cases. And at the end, there is a sentence saying the national authorities might change all this -- which suggests that the national authorities are the authoritative definition anyway. (BTW, shouldn't that last sentence be "It is understood that the definition of carrier-of-record for E.164 numbers associated with a geographic area is subject to modification by the national authorities with jurisdiction over that geographic area."? Otherwise, it sounds like the definition depends on the jurisdiction of where the reader is standing, not where the number is standing.) The central problem is that this section doesn't make it clear what the authoritative definition is. IMO, it needs to state first that the authoritative definition is in the telco universe. If it then wants to provide an explanation which is *likely* to remain consistent with the authoritative definition, that's fine. But the explication has got to be explicitly marked as non-authoritative, especially because it is in a section titled "Definition". (Remember -- You work for AT&T and are very familiar with the concept of carrier-of-record. I (and most of your readers) have only a vague idea of what carrier-of-record might mean.) This requirement was to address a specific request from the chairs that queries not simply be dropped on the floor without response causing re-queries and traffic flood. The requirement you propose is actually much different and, while the initial (e.g., Tier 1) response may not be origin-sensitive, further processing is likely to be since A carrier may have different POIs for different interconnection partners. OK, I hadn't looked at it like that. But then I think the second sentence of item 2 would be better phrased "Queries must not be discarded without response..." -- "rejected" to my mind means an explicit error response. I doubt the DNS RFCs use the term "rejected", but an NXDOMAIN response seems pretty close to "rejected" to me, especially if it was generated due to some permissions situation, rather than because there *really isn't* any information for that name. I think the carrier-of-record definition has clear implications about the relationship Of infrastructure ENUM to number portability: if the number ports the right to register it moves to the recipient carrier as well. If it's understood in the telco world that number porting changes the carrier-of-record of the number, then I see no reason to mention it in the I-D. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 23 11:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnH5O-00029b-Me; Thu, 23 Nov 2006 11:06:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnH5N-00029B-Fh for enum@ietf.org; Thu, 23 Nov 2006 11:06:01 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnH5M-0005Lz-9n for enum@ietf.org; Thu, 23 Nov 2006 11:06:01 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <2006112316055901200oraore>; Thu, 23 Nov 2006 16:05:59 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kANG5x5K005938 for ; Thu, 23 Nov 2006 11:05:59 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kANG5xbG005934; Thu, 23 Nov 2006 11:05:59 -0500 Date: Thu, 23 Nov 2006 11:05:59 -0500 Message-Id: <200611231605.kANG5xbG005934@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> (ppfautz@att.com) Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: "Pfautz, Penn L, GBLAM" The requirement you propose is actually much different and, while the initial (e.g., Tier 1) response may not be origin-sensitive, further processing is likely to be since A carrier may have different POIs for different interconnection partners. Hmmm... If that's so, you might want to add some explication of that in the requirements. The current definition suggests to the naive that the mapping from E.164 number to URI is offered to all comers . Indeed, from a technological point of view, it's a fairly complex feature to allow different mappings to be delivered to requests made on behalf of different originating parties. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 23 11:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHAz-0007rO-EE; Thu, 23 Nov 2006 11:11:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHAx-0007rG-Pi for enum@ietf.org; Thu, 23 Nov 2006 11:11:47 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnHAw-0006Aj-D2 for enum@ietf.org; Thu, 23 Nov 2006 11:11:47 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 23 Nov 2006 17:10:48 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C5280@oefeg-s04.oefeg.loc> In-Reply-To: <200611231605.kANG5xbG005934@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Thread-Index: AccPGV2xfxW9GRb3SIW6JL6/yt9y7gAAEPew From: "Stastny Richard" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I would not go down this path in ENUM We had this discussion also in Speermint and it seems to be very complex Leave it there ENUM is delivering an AoR, period Richard > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Thursday, November 23, 2006 5:06 PM > To: enum@ietf.org > Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs >=20 > From: "Pfautz, Penn L, GBLAM" >=20 > The requirement you propose is actually much different and, while the > initial (e.g., Tier 1) > response may not be origin-sensitive, further processing is likely to > be > since > A carrier may have different POIs for different interconnection > partners. >=20 > Hmmm... If that's so, you might want to add some explication of that > in the requirements. The current definition suggests to the naive > that the mapping from E.164 number to URI is offered to all comers . >=20 > Indeed, from a technological point of view, it's a fairly complex > feature to allow different mappings to be delivered to requests made > on behalf of different originating parties. >=20 > Dale >=20 > _______________________________________________ > 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 enum-bounces@ietf.org Thu Nov 23 11:58:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHst-00026F-OP; Thu, 23 Nov 2006 11:57:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHsr-000267-Fc for enum@ietf.org; Thu, 23 Nov 2006 11:57:09 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnHsn-0005vI-JZ for enum@ietf.org; Thu, 23 Nov 2006 11:57:09 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id F23064D0B1; Thu, 23 Nov 2006 17:56:45 +0100 (CET) Date: Thu, 23 Nov 2006 17:56:45 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Message-ID: <20061123165645.GA26860@nic.at> References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611231605.kANG5xbG005934@dragon.ariadne.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/23 17:11, Dale.Worley@comcast.net wrote: > From: "Pfautz, Penn L, GBLAM" > > The requirement you propose is actually much different and, while > the initial (e.g., Tier 1) response may not be origin-sensitive, > further processing is likely to be since A carrier may have > different POIs for different interconnection partners. > > Hmmm... If that's so, you might want to add some explication of that > in the requirements. The current definition suggests to the naive that > the mapping from E.164 number to URI is offered to all comers . > > Indeed, from a technological point of view, it's a fairly complex > feature to allow different mappings to be delivered to requests made > on behalf of different originating parties. I agree with Richard here: I-ENUM should return an AoR which act as a "name" and does not contain source specific routing information. It may well be that further processing is done on this AoR that leads to different ingress points depending on the source network. That, though, is out of scope for I-ENUM and thus need not be mentioned in this document. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 23 12:20:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIF6-0006sw-Ov; Thu, 23 Nov 2006 12:20:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIF5-0006sq-6h for enum@ietf.org; Thu, 23 Nov 2006 12:20:07 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnIF4-0001Xc-1O for enum@ietf.org; Thu, 23 Nov 2006 12:20:07 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id kANHKAF8015795; Thu, 23 Nov 2006 12:20:12 -0500 Received: from trutkowski-desk.verisign.com ([10.26.0.245]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 12:20:02 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Nov 2006 12:20:00 -0500 To: Otmar Lendl , enum@ietf.org From: Tony Rutkowski Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs In-Reply-To: <20061123165645.GA26860@nic.at> References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com> <20061123165645.GA26860@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2006 17:20:03.0088 (UTC) FILETIME=[9CB75100:01C70F23] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Otmar, >I agree with Richard here: I-ENUM should return an AoR which act >as a "name" and does not contain source specific routing information. But isn't this relevant under the Missoula Plan? --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 23 12:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIQs-0006IT-Ub; Thu, 23 Nov 2006 12:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIQr-0006IJ-SP for enum@ietf.org; Thu, 23 Nov 2006 12:32:17 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnIQq-0003jl-F7 for enum@ietf.org; Thu, 23 Nov 2006 12:32:17 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5815F8C43E; Thu, 23 Nov 2006 17:32:05 +0000 (GMT) In-Reply-To: <20061123165645.GA26860@nic.at> References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com> <20061123165645.GA26860@nic.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65AC5993-ED58-41D8-A9AC-7264B2F838AA@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Date: Thu, 23 Nov 2006 17:32:03 +0000 To: Otmar Lendl , NEO Pfautz Penn L X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Otmar, folks, Me too. We were talking about ->E2U<- NAPTRs, right? iENUM or (user) ENUM concentrates on NAPTRs using the 'E2U' DDDS application specified in RFC 3761. In effect, it returns a universal name, not a routing ID. Routing can and (IMHO) should be done elsewhere. D2U/D2T/D2S NAPTR and SRV lookups as per RFC 3263 (almost certainly in different zones) look like a much better way to deal with any such source differentiated processing. all the best, Lawrence On 23 Nov 2006, at 16:56, Otmar Lendl wrote: > On 2006/11/23 17:11, Dale.Worley@comcast.net wrote: >> From: "Pfautz, Penn L, GBLAM" >> >> The requirement you propose is actually much different and, while >> the initial (e.g., Tier 1) response may not be origin-sensitive, >> further processing is likely to be since A carrier may have >> different POIs for different interconnection partners. >> >> Hmmm... If that's so, you might want to add some explication of that >> in the requirements. The current definition suggests to the naive >> that >> the mapping from E.164 number to URI is offered to all comers . >> >> Indeed, from a technological point of view, it's a fairly complex >> feature to allow different mappings to be delivered to requests made >> on behalf of different originating parties. > > I agree with Richard here: I-ENUM should return an AoR which act > as a "name" and does not contain source specific routing information. > > It may well be that further processing is done on this AoR that leads > to different ingress points depending on the source network. > > That, though, is out of scope for I-ENUM and thus need not be > mentioned in this document. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > _______________________________________________ > 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 enum-bounces@ietf.org Sun Nov 26 16:40:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoRhU-0006A4-DX; Sun, 26 Nov 2006 16:38:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoRhT-00068u-Fe for enum@ietf.org; Sun, 26 Nov 2006 16:38:11 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GoRhS-00026L-6i for enum@ietf.org; Sun, 26 Nov 2006 16:38:11 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1164577089!16943810!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 21233 invoked from network); 26 Nov 2006 21:38:09 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 26 Nov 2006 21:38:09 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAQLc9kI028117 for ; Sun, 26 Nov 2006 16:38:09 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAQLc4So028107 for ; Sun, 26 Nov 2006 16:38:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Date: Sun, 26 Nov 2006 16:38:01 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E28E471@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <20061123165645.GA26860@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Thread-Index: AccPILcg7MNQx291RVygycVgNJHUMACgfO2Q From: "Pfautz, Penn L, GBLAM" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org To clarify: I do believe infrastructure ENUM will deliver a single AoR to all- and it will be in subsequent processing that differentiation takes place. I just didn't want to imply that the ultimate PoI derived would be the same for all. My apologies for any confusion. Penn=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Thursday, November 23, 2006 11:57 AM To: enum@ietf.org Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs On 2006/11/23 17:11, Dale.Worley@comcast.net wrote: > From: "Pfautz, Penn L, GBLAM" > > The requirement you propose is actually much different and, while > the initial (e.g., Tier 1) response may not be origin-sensitive, > further processing is likely to be since A carrier may have > different POIs for different interconnection partners. > > Hmmm... If that's so, you might want to add some explication of that > in the requirements. The current definition suggests to the naive that > the mapping from E.164 number to URI is offered to all comers . > > Indeed, from a technological point of view, it's a fairly complex > feature to allow different mappings to be delivered to requests made > on behalf of different originating parties. I agree with Richard here: I-ENUM should return an AoR which act as a "name" and does not contain source specific routing information. It may well be that further processing is done on this AoR that leads to different ingress points depending on the source network. That, though, is out of scope for I-ENUM and thus need not be mentioned in this document. /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 enum-bounces@ietf.org Mon Nov 27 15:06:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gomis-0000Xt-0e; Mon, 27 Nov 2006 15:05:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gomiq-0000Xk-Bp for enum@ietf.org; Mon, 27 Nov 2006 15:05:00 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gomip-0003ok-0y for enum@ietf.org; Mon, 27 Nov 2006 15:05:00 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2006112720043801300arrkke>; Mon, 27 Nov 2006 20:04:58 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kARK4c69009036 for ; Mon, 27 Nov 2006 15:04:38 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kARK4ckR009032; Mon, 27 Nov 2006 15:04:38 -0500 Date: Mon, 27 Nov 2006 15:04:38 -0500 Message-Id: <200611272004.kARK4ckR009032@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <20061123165645.GA26860@nic.at> (lendl@nic.at) Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com> <20061123165645.GA26860@nic.at> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: Otmar Lendl I agree with Richard here: I-ENUM should return an AoR which act as a "name" and does not contain source specific routing information. It may well be that further processing is done on this AoR that leads to different ingress points depending on the source network. That, though, is out of scope for I-ENUM and thus need not be mentioned in this document. If the carriers who are going to be the ones using I-ENUM need to have source-specific routing, we need to make sure that the I-ENUM system permits source-specific routing, in some method or another. Given its apparent importance, the requirements should at least mention the subject and require that we not generate a standard which cannot support source-specific routing. Although I agree that it would probably be best not to have source-specificity in the mapping to the SIP AoR, but rather downstream in processing from there. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 27 15:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQd-0003SF-Cj; Mon, 27 Nov 2006 15:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQQ-0003Ng-GI; Mon, 27 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonQQ-00020V-4i; Mon, 27 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id DE77732998; Mon, 27 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001Fs-Oy; Mon, 27 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-xmpp-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice 'XMPP' Author(s) : A. Mayrhofer Filename : draft-ietf-enum-xmpp-00.txt Pages : 8 Date : 2006-11-27 This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp:' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-xmpp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-xmpp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-xmpp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-27110854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-xmpp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-xmpp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27110854.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Nov 28 04:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozGM-0000lG-Jr; Tue, 28 Nov 2006 04:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozGL-0000hZ-C3 for enum@ietf.org; Tue, 28 Nov 2006 04:28:25 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GozGJ-0002i5-UL for enum@ietf.org; Tue, 28 Nov 2006 04:28:25 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 28 Nov 2006 10:27:32 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C52BA@oefeg-s04.oefeg.loc> In-Reply-To: <200611272004.kARK4ckR009032@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Thread-Index: AccSX2vRh1I4KRbuRyKSThJ8BHX0mQAbxvbg From: "Stastny Richard" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > If the carriers who are going to be the ones using I-ENUM need to have > source-specific routing, we need to make sure that the I-ENUM system > permits source-specific routing, in some method or another. Given its > apparent importance, the requirements should at least mention the > subject and require that we not generate a standard which cannot > support source-specific routing. There is one minor problem here: I-ENUM is based on the DNS and the DNS (at least the public DNS) has no method for source specific replies. So either we do not use the DNS for E.164 to URI mapping, or we change how the DNS works. Both options are not within the scope of ENUM WG Richard > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Monday, November 27, 2006 9:05 PM > To: enum@ietf.org > Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs >=20 > From: Otmar Lendl >=20 > I agree with Richard here: I-ENUM should return an AoR which act > as a "name" and does not contain source specific routing information. >=20 > It may well be that further processing is done on this AoR that leads > to different ingress points depending on the source network. >=20 > That, though, is out of scope for I-ENUM and thus need not be > mentioned in this document. >=20 > If the carriers who are going to be the ones using I-ENUM need to have > source-specific routing, we need to make sure that the I-ENUM system > permits source-specific routing, in some method or another. Given its > apparent importance, the requirements should at least mention the > subject and require that we not generate a standard which cannot > support source-specific routing. >=20 > Although I agree that it would probably be best not to have > source-specificity in the mapping to the SIP AoR, but rather > downstream in processing from there. >=20 > Dale >=20 > _______________________________________________ > 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 enum-bounces@ietf.org Tue Nov 28 10:18:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4iS-0004vj-Rx; Tue, 28 Nov 2006 10:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4iQ-0004vZ-TK for enum@ietf.org; Tue, 28 Nov 2006 10:17:46 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp4iO-0008EI-JD for enum@ietf.org; Tue, 28 Nov 2006 10:17:46 -0500 Received: from [10.10.0.218] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 28 Nov 2006 16:17:38 +0100 id 00000015.456C5312.00001F07 Message-ID: <456C52F5.20203@enum.at> Date: Tue, 28 Nov 2006 16:17:09 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi, i'd like to have at least 3 people look over our XMPP Enumservice draft. Any volunteers? (not just the "usual suspects" perhaps?) http://www.ietf.org/internet-drafts/draft-ietf-enum-xmpp-00.txt thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 10:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5FU-0002BD-N7; Tue, 28 Nov 2006 10:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5FT-0002B1-Ot for enum@ietf.org; Tue, 28 Nov 2006 10:51:55 -0500 Received: from cali.ucd.ie ([193.1.169.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5FL-0007Ed-FV for enum@ietf.org; Tue, 28 Nov 2006 10:51:55 -0500 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0J9G00A016CFCF00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for enum@ietf.org; Tue, 28 Nov 2006 15:51:26 +0000 (GMT) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0J9G00KM56PORV40@cali.ucd.ie>; Tue, 28 Nov 2006 15:51:24 +0000 (GMT) Date: Tue, 28 Nov 2006 15:51:53 +0000 From: Niall O'Reilly Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. In-reply-to: <456C52F5.20203@enum.at> To: Alexander Mayrhofer Message-id: <49F17D2C-11B6-4DF8-BF78-1578AECFDF8D@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.1 (Tiger) References: <456C52F5.20203@enum.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "'enum@ietf.org'" , Niall O'Reilly X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Nov 2006, at 15:17, Alexander Mayrhofer wrote: > i'd like to have at least 3 people look over our XMPP Enumservice > draft. Any > volunteers? (not just the "usual suspects" perhaps?) I've done this, and it seems good to me, except for the nit mentioned below. I don't recognize myself as a "usual suspect", but I'm not sure whether I'm competent either ... NIT: > In the context of this Enumservice, random clients may discover and > use the XMPP URIs/IRIs associated to an E.164 number, hence in most s/random/arbitrary/ Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFbFsfeYfkja6ZXtkRAlESAJ9l6moxjLseqcFrYbN2wBikOOYpfwCeKRhs joBKbPSoIP7wOwcRgouitSk= =mbo9 -----END PGP SIGNATURE----- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 11:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5uM-0006jZ-IS; Tue, 28 Nov 2006 11:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5uK-0006eD-Qe for enum@ietf.org; Tue, 28 Nov 2006 11:34:08 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5uJ-0006oj-Ep for enum@ietf.org; Tue, 28 Nov 2006 11:34:08 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id E813E8D073; Tue, 28 Nov 2006 16:33:55 +0000 (GMT) In-Reply-To: <200611272004.kARK4ckR009032@dragon.ariadne.com> References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com> <20061123165645.GA26860@nic.at> <200611272004.kARK4ckR009032@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B8CAE46-706F-45FA-8FA3-E05C8DA1B416@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs Date: Tue, 28 Nov 2006 16:33:54 +0000 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dale, folks, i-ENUM does not stand alone. Source specific routing may well be a requirement of the overall architecture, within which i-ENUM plays a part. Please explain why it is a requirement of i-ENUM itself (rather than other elements specific to the particular communications services offered)? all the best, Lawrence On 27 Nov 2006, at 20:04, Dale.Worley@comcast.net wrote: > From: Otmar Lendl > I agree with Richard here: I-ENUM should return an AoR which act > as a "name" and does not contain source specific routing > information. > > It may well be that further processing is done on this AoR that > leads > to different ingress points depending on the source network. > > That, though, is out of scope for I-ENUM and thus need not be > mentioned in this document. > > If the carriers who are going to be the ones using I-ENUM need to have > source-specific routing, we need to make sure that the I-ENUM system > permits source-specific routing, in some method or another. Given its > apparent importance, the requirements should at least mention the > subject and require that we not generate a standard which cannot > support source-specific routing. > > Although I agree that it would probably be best not to have > source-specificity in the mapping to the SIP AoR, but rather > downstream in processing from there. > > Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 13:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp88G-0004bT-Ju; Tue, 28 Nov 2006 13:56:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp88D-0004ZH-Jw for enum@ietf.org; Tue, 28 Nov 2006 13:56:37 -0500 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp88C-0003lb-C2 for enum@ietf.org; Tue, 28 Nov 2006 13:56:37 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20061128185622m14001jnide>; Tue, 28 Nov 2006 18:56:32 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kASIuL69012284 for ; Tue, 28 Nov 2006 13:56:21 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kASIuLZG012280; Tue, 28 Nov 2006 13:56:21 -0500 Date: Tue, 28 Nov 2006 13:56:21 -0500 Message-Id: <200611281856.kASIuLZG012280@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1B8CAE46-706F-45FA-8FA3-E05C8DA1B416@insensate.co.uk> (lconroy@insensate.co.uk) Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com> <20061123165645.GA26860@nic.at> <200611272004.kARK4ckR009032@dragon.ariadne.com> <1B8CAE46-706F-45FA-8FA3-E05C8DA1B416@insensate.co.uk> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: lconroy i-ENUM does not stand alone. Source specific routing may well be a requirement of the overall architecture, within which i-ENUM plays a part. Please explain why it is a requirement of i-ENUM itself (rather than other elements specific to the particular communications services offered)? I would say that it's a requirement that how we design I-ENUM *doesn't prevent* source-specific routing. Whether I-ENUM implements source-specific routing itself is a question to be decided later. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 15:35:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9ep-0002P8-2a; Tue, 28 Nov 2006 15:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9em-0002Ow-NB for enum@ietf.org; Tue, 28 Nov 2006 15:34:21 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9eh-0001MK-Tw for enum@ietf.org; Tue, 28 Nov 2006 15:34:20 -0500 Received: from [172.17.1.113] (unknown [202.10.81.200]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 7622D11A679 for ; Tue, 28 Nov 2006 15:34:08 -0500 (EST) Message-ID: <456C9D3C.6040104@e164.org> Date: Wed, 29 Nov 2006 07:34:04 +1100 From: Duane User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: enum@ietf.org Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at> In-Reply-To: <456C52F5.20203@enum.at> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Alexander Mayrhofer wrote: > i'd like to have at least 3 people look over our XMPP Enumservice draft. Any > volunteers? (not just the "usual suspects" perhaps?) For consistencies sake I thought XMPP should have been a sub-type of IM or X-IM or something similar, and grouped all similar IM services together, just like web services are grouped etc X-IM:XMPP X-IM:IRC X-IM:ICQ X-IM:YMSGR X-IM:MSN X-IM:AIM Rather then having XMPP as the enumservice type and no sub-type. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 15:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9uh-0007vD-Ts; Tue, 28 Nov 2006 15:50:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9uT-0007Rd-8D; Tue, 28 Nov 2006 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gp9uR-0005U4-SR; Tue, 28 Nov 2006 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C655F2AC59; Tue, 28 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gp9tx-0001A8-Hx; Tue, 28 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-branch-location-record-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-ietf-enum-branch-location-record-01.txt Pages : 8 Date : 2006-11-28 This documents defines the ENUM Branch Location record (EBL) which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL record is to provide a temporary solution for the Infrastructure ENUM tree location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-branch-location-record-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-branch-location-record-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-28105802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-branch-location-record-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-branch-location-record-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-28105802.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Nov 28 17:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBsu-0005Nw-0G; Tue, 28 Nov 2006 17:57:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBss-0005Mq-IX for enum@ietf.org; Tue, 28 Nov 2006 17:57:02 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBsr-00011l-9z for enum@ietf.org; Tue, 28 Nov 2006 17:57:02 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 25D7B4D529; Tue, 28 Nov 2006 23:56:46 +0100 (CET) Date: Tue, 28 Nov 2006 23:56:46 +0100 From: Otmar Lendl To: Duane Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Message-ID: <20061128225646.GB26860@nic.at> References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456C9D3C.6040104@e164.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/28 21:11, Duane wrote: > Alexander Mayrhofer wrote: > > > i'd like to have at least 3 people look over our XMPP Enumservice draft. Any > > volunteers? (not just the "usual suspects" perhaps?) > > For consistencies sake I thought XMPP should have been a sub-type of IM > or X-IM or something similar, and grouped all similar IM services > together, just like web services are grouped etc XMPP isn't just for IM. Google Talk uses XMPP for VoIP. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 18:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpC3L-0001og-Fz; Tue, 28 Nov 2006 18:07:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpC3G-0001lk-Ps for enum@ietf.org; Tue, 28 Nov 2006 18:07:47 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpC2t-0005VI-0E for enum@ietf.org; Tue, 28 Nov 2006 18:07:46 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 206354D52B; Wed, 29 Nov 2006 00:07:22 +0100 (CET) Date: Wed, 29 Nov 2006 00:07:22 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-branch-location-record-01.txt Message-ID: <20061128230722.GC26860@nic.at> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/11/28 21:11, Internet-Drafts@ietf.org wrote: > > Title : The ENUM Branch Location Record > Author(s) : O. Lendl > Filename : draft-ietf-enum-branch-location-record-01.txt Some remarks on the changes from -00 to -01: -01 does no longer define the specifics for the interim I-ENUM solution. This draft just defines the EBL record and specifies how a modified ENUM application can make use of EBL records to branch off from one tree into various sub-trees. I-ENUM only appears as the motivation and as an example. The main reasons for this change were discussions in San Diego on how to speed up the DNS RRtype assignment process. As this draft is now decoupled from I-ENUM specifics, it should be able to progress faster and get the IANA assignment via a test-drive of 2929bis. The proposed algorithm and RRType did not change at all. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 19:01:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpCso-0000qE-Vk; Tue, 28 Nov 2006 19:01:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpCsn-0000q9-Hz for enum@ietf.org; Tue, 28 Nov 2006 19:01:01 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpCsm-0000cf-8e for enum@ietf.org; Tue, 28 Nov 2006 19:01:01 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 7DD308D14F; Wed, 29 Nov 2006 00:00:59 +0000 (GMT) In-Reply-To: <20061128225646.GB26860@nic.at> References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Date: Wed, 29 Nov 2006 00:00:59 +0000 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: enum@ietf.org, Duane X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Otmar, Duane, folks, On 28 Nov 2006, at 22:56, Otmar Lendl wrote: Duane writ: >> For consistencies sake I thought XMPP should have been a sub-type >> of IM >> or X-IM or something similar, and grouped all similar IM services >> together, just like web services are grouped etc > XMPP isn't just for IM. Google Talk uses XMPP for VoIP. Well - maybe X-Voice:XMPP as well ? couldn't resist. atb, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 28 19:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpDao-0005d8-Eb; Tue, 28 Nov 2006 19:46:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpDam-0005d1-Tk for enum@ietf.org; Tue, 28 Nov 2006 19:46:28 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpDag-0005wt-34 for enum@ietf.org; Tue, 28 Nov 2006 19:46:28 -0500 Received: from [172.17.1.113] (unknown [202.10.81.200]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id A15FF11A679; Tue, 28 Nov 2006 19:46:15 -0500 (EST) Message-ID: <456CD852.1010303@e164.org> Date: Wed, 29 Nov 2006 11:46:10 +1100 From: Duane User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Otmar Lendl Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at> In-Reply-To: <20061128225646.GB26860@nic.at> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Otmar Lendl wrote: > XMPP isn't just for IM. Google Talk uses XMPP for VoIP. The same can be said for most if not all IM protocols. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 29 10:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRi0-0001iQ-Lo; Wed, 29 Nov 2006 10:50:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRhh-0001Ct-Ef; Wed, 29 Nov 2006 10:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpRhh-0001Gd-4K; Wed, 29 Nov 2006 10:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A29D3175B7; Wed, 29 Nov 2006 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GpRhC-00018d-4u; Wed, 29 Nov 2006 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Nov 2006 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-combined-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-ietf-enum-combined-02.txt Pages : 11 Date : 2006-11-29 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after approval of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-combined-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-combined-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-29074720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-combined-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-combined-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-29074720.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Nov 29 11:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSML-0002FX-Rz; Wed, 29 Nov 2006 11:32:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSMK-0002DT-Ue for enum@ietf.org; Wed, 29 Nov 2006 11:32:32 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpSMI-0004G3-K1 for enum@ietf.org; Wed, 29 Nov 2006 11:32:32 -0500 Received: from [10.10.0.218] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 29 Nov 2006 17:32:23 +0100 id 0000002A.456DB617.00003739 Message-ID: <456DB5FD.7000501@enum.at> Date: Wed, 29 Nov 2006 17:31:57 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Duane Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> In-Reply-To: <456C9D3C.6040104@e164.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Duane wrote: > Alexander Mayrhofer wrote: > >> i'd like to have at least 3 people look over our XMPP Enumservice draft. Any >> volunteers? (not just the "usual suspects" perhaps?) > > For consistencies sake I thought XMPP should have been a sub-type of IM > or X-IM or something similar, and grouped all similar IM services > together, just like web services are grouped etc Duane, thanks for the feedback. Actually, i thought about that, too, especially considering that a recent registration proposal for "im" has progressed (similar to the "pres" service). (draft-ietf-enum-im-service-01.txt) However, XMPP is pretty generic, and not limited to those services (similar to SIP), so i think it has deserved its own ENUM service. There are a lot of proposals to use XMPP for other purposes than im and presence.. The other alternative to refer to an XMPP IM service would be using an "im" Enumservice pointing to a "im:" URI which then resolves to XMPP using RFC3861 style NAPTRS (that would become a two-stage process), like: $ORIGIN 1.2.3.4.5.e164.arpa. IN NAPTR 10 100 "u" "E2U+im" "!^.*$!im:user@domain.com!" . together with $ORIGIN domain.com _im._xmpp SRV 0 0 5223 xmpphost.domain.com. (However, the "_xmpp" protocol label for the "_im" service label is not yet registered) Regarding the experimental Enumservice: I have a bit of a problem with "x-" services as long as anybody can use any of them for any purpose. it would be perfectly legal to use an "x-im:xmpp" enumservice for a different protocol (eg. HTTP, email, or even SIP) - "x-" services are only to be used privately, and interopability must not be expected. That might change with a "lightweigth" registration process for experimental service - but, unfortunately we are not there yet. So, to conclude, a new "XMPP" Enumservice seemed to be the most logical thing to do, considerung the flexibility of XMPP itself.. And, it's always the same story about "too much flexibility in the NAPTR - where to put the protocol, where to put the application"... comments appreciated. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 29 11:44:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSXI-0001YP-Eh; Wed, 29 Nov 2006 11:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSXH-0001X2-2B for enum@ietf.org; Wed, 29 Nov 2006 11:43:51 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpSXF-0006Aa-PI for enum@ietf.org; Wed, 29 Nov 2006 11:43:51 -0500 Received: from [10.10.0.218] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 29 Nov 2006 17:43:46 +0100 id 0000001E.456DB8C2.0000399C Message-ID: <456DB8A8.5000200@enum.at> Date: Wed, 29 Nov 2006 17:43:20 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Duane Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at> <456CD852.1010303@e164.org> In-Reply-To: <456CD852.1010303@e164.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: enum@ietf.org, Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Duane wrote: > Otmar Lendl wrote: > >> XMPP isn't just for IM. Google Talk uses XMPP for VoIP. > > The same can be said for most if not all IM protocols. > I think we will always have to deal with (at least) two "types" or registrations in ENUM. - The "application" type registration (like, in that case "im" pointing to an IM URI, which in turn resolves to an XMPP server). Examples: "im", "pres", "voice", "web", "ft" - The "protocol" registration (like "xmpp" in that case). Examples "sip", "h323", etc... I haven't yet found out which of the two the "holy grail" is - we also try to work on this issue in draft-ietf-enumservices-guide. contributions are very welcome for that document... cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 29 16:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWzK-0005Lu-6L; Wed, 29 Nov 2006 16:29:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWzI-0005Gb-3W for enum@ietf.org; Wed, 29 Nov 2006 16:29:04 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWzE-0008FU-5m for enum@ietf.org; Wed, 29 Nov 2006 16:29:04 -0500 Received: from [172.17.1.113] (unknown [202.10.81.200]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 56B7F11A678; Wed, 29 Nov 2006 16:28:55 -0500 (EST) Message-ID: <456DFB91.7040001@e164.org> Date: Thu, 30 Nov 2006 08:28:49 +1100 From: Duane User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Alexander Mayrhofer Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <456DB5FD.7000501@enum.at> In-Reply-To: <456DB5FD.7000501@enum.at> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Alexander Mayrhofer wrote: > thanks for the feedback. Actually, i thought about that, too, especially > considering that a recent registration proposal for "im" has progressed > (similar to the "pres" service). (draft-ietf-enum-im-service-01.txt) > > However, XMPP is pretty generic, and not limited to those services (similar > to SIP), so i think it has deserved its own ENUM service. There are a lot of > proposals to use XMPP for other purposes than im and presence.. I think you are over engineering things, basically if someone lists an IM address, regardless if it is MSN, YMGSR, XMPP, or whatever, everything else will need to be negotiated at the client level due to a number of reasons including privacy and security. IMHO, it is much better to make things simpler then to require users to add 50 different types to specify the capabilities in DNS which is merely a duplication of what is available from the information within the client. > Regarding the experimental Enumservice: I have a bit of a problem with "x-" > services as long as anybody can use any of them for any purpose. it would be > perfectly legal to use an "x-im:xmpp" enumservice for a different protocol > (eg. HTTP, email, or even SIP) - "x-" services are only to be used > privately, and interopability must not be expected. Perhaps I shouldn't have suggested x-im so easily, but instead use E2U+IMSGR instead, or anything really, the point is clients are capable to send information more securly on their capabilities, rather then specify all aspects that it can support which no one will ever use. > So, to conclude, a new "XMPP" Enumservice seemed to be the most logical > thing to do, considerung the flexibility of XMPP itself.. > > And, it's always the same story about "too much flexibility in the NAPTR - > where to put the protocol, where to put the application"... I disagree, people already find each other and the software tells them what the person they are conversing with is capable of already without the help of NAPTR, they do this using the XMPP address, or ICQ number, or email address registered with passport or any of the other established mechanisms. However what would be nice for things like GAIM and other clients that support multiple protocols is an easier way to filter for all IM services available. >From there the application can display to the end user not only the services that match what the user is signed up and/or currently registered against, but so the user can pick and choose which they actually want added. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 29 16:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpX5c-0001oA-TX; Wed, 29 Nov 2006 16:35:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpX5b-0001o0-71 for enum@ietf.org; Wed, 29 Nov 2006 16:35:35 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpX5V-0000V4-JH for enum@ietf.org; Wed, 29 Nov 2006 16:35:35 -0500 Received: from [172.17.1.113] (unknown [202.10.81.200]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id B5F0811A678; Wed, 29 Nov 2006 16:35:26 -0500 (EST) Message-ID: <456DFD1A.2060002@e164.org> Date: Thu, 30 Nov 2006 08:35:22 +1100 From: Duane User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Alexander Mayrhofer Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at> <456CD852.1010303@e164.org> <456DB8A8.5000200@enum.at> In-Reply-To: <456DB8A8.5000200@enum.at> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: enum@ietf.org, Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Alexander Mayrhofer wrote: > I haven't yet found out which of the two the "holy grail" is - we also try > to work on this issue in draft-ietf-enumservices-guide. contributions are > very welcome for that document... As far as I can see, virtually all current enumservices use subtype except h323, sip and pres, everything else has subtypes. Richard pointed out to me privately, that the only time it makes sense not to use a subtype is when there is duplication, eg sip:sip, but there is no subtype for sips, just the possibility of a different URI type. Perhaps e2u+pstn:sip, e2u+pstn:sips etc would have made more sense? e2u+pstn:sip is exists, well the sip part does, or maybe e2u+voip:sip would have made more sense. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 29 16:58:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXRE-0002Tg-Pz; Wed, 29 Nov 2006 16:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXRC-0002TX-Ud for enum@ietf.org; Wed, 29 Nov 2006 16:57:54 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpXR8-0003KE-Cp for enum@ietf.org; Wed, 29 Nov 2006 16:57:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Date: Wed, 29 Nov 2006 22:57:04 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C1E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Thread-Index: AccT/kSsvwn7RmX+TOeap/XU+FU6QwAAlH9u References: <456C52F5.20203@enum.at><456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at><456CD852.1010303@e164.org> <456DB8A8.5000200@enum.at> <456DFD1A.2060002@e164.org> From: "Stastny Richard" To: "Duane" , "Alexander Mayrhofer" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >Perhaps e2u+pstn:sip, e2u+pstn:sips etc would have made more sense? >e2u+pstn:sip is exists, well the sip part does, or maybe e2u+voip:sip >would have made more sense. I faintlycan remember voice:sip and voice:h323, what's left is = voice:tel this was two years ago =20 I have given up this discussion ;-) Richard ________________________________ Von: Duane [mailto:duane@e164.org] Gesendet: Mi 29.11.2006 22:35 An: Alexander Mayrhofer Cc: enum@ietf.org; Otmar Lendl Betreff: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Alexander Mayrhofer wrote: > I haven't yet found out which of the two the "holy grail" is - we also = try > to work on this issue in draft-ietf-enumservices-guide. contributions = are > very welcome for that document... As far as I can see, virtually all current enumservices use subtype except h323, sip and pres, everything else has subtypes. Richard pointed out to me privately, that the only time it makes sense not to use a subtype is when there is duplication, eg sip:sip, but there is no subtype for sips, just the possibility of a different URI type. Perhaps e2u+pstn:sip, e2u+pstn:sips etc would have made more sense? e2u+pstn:sip is exists, well the sip part does, or maybe e2u+voip:sip would have made more sense. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ 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 enum-bounces@ietf.org Wed Nov 29 17:18:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXkD-0007nw-TO; Wed, 29 Nov 2006 17:17:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXkC-0007np-Tq for enum@ietf.org; Wed, 29 Nov 2006 17:17:32 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXkA-0006C7-Tm for enum@ietf.org; Wed, 29 Nov 2006 17:17:32 -0500 Received: from [172.17.1.113] (unknown [202.10.81.200]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 0087211A660; Wed, 29 Nov 2006 17:17:23 -0500 (EST) Message-ID: <456E06EE.4010906@e164.org> Date: Thu, 30 Nov 2006 09:17:18 +1100 From: Duane User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at><456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at><456CD852.1010303@e164.org> <456DB8A8.5000200@enum.at> <456DFD1A.2060002@e164.org> <32755D354E6B65498C3BD9FD496C7D462C4C1E@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C1E@oefeg-s04.oefeg.loc> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: enum@ietf.org, Ed Guy , Alexander Mayrhofer X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >> Perhaps e2u+pstn:sip, e2u+pstn:sips etc would have made more sense? >> e2u+pstn:sip is exists, well the sip part does, or maybe e2u+voip:sip >> would have made more sense. > > I faintlycan remember voice:sip and voice:h323, what's left is voice:tel > > this was two years ago > > I have given up this discussion ;-) Perhaps Ed Guy should be using this as a template for IAX2, rather then rushing through yet another enumservice that can't easily be grouped with others... -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 29 20:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpapy-0004nU-7x; Wed, 29 Nov 2006 20:35:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpapw-0004me-Ak for enum@ietf.org; Wed, 29 Nov 2006 20:35:40 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpapt-00037G-No for enum@ietf.org; Wed, 29 Nov 2006 20:35:40 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id AE3848D37E; Thu, 30 Nov 2006 01:35:26 +0000 (GMT) In-Reply-To: <456DB8A8.5000200@enum.at> References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at> <456CD852.1010303@e164.org> <456DB8A8.5000200@enum.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <237A2882-907D-4BCA-8FDF-85ACE781FAEF@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Date: Thu, 30 Nov 2006 01:35:26 +0000 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: enum@ietf.org, Otmar Lendl , Duane X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Alex, folks, OK - this quest is a long one. On 29 Nov 2006, at 16:43, Alexander Mayrhofer wrote: > Duane wrote: >> Otmar Lendl wrote: >>> XMPP isn't just for IM. Google Talk uses XMPP for VoIP. (A puppy is not just for Christmas, it's for ... ?) >> The same can be said for most if not all IM protocols. > > I think we will always have to deal with (at least) two "types" of > registrations in ENUM. > > - The "application" type registration (like, in that case "im" > pointing to > an IM URI, which in turn resolves to an XMPP server). Examples: "im", > "pres", "voice", "web", "ft" > > - The "protocol" registration (like "xmpp" in that case). Examples > "sip", > "h323", etc... > > I haven't yet found out which of the two the "holy grail" is - we > also try > to work on this issue in draft-ietf-enumservices-guide. > contributions are > very welcome for that document... Seriously folks, this request for guideline text is timely. This discussion demonstrates that is it needed. IMHO, as a client I would like the Enumservice field to answer two questions: - "What are am going to do if you use this contact?", and - "How are you going to do it"? These map to the Eumservice Type and Subtype - hence 'voice' is the kind of thing you want to do, and 'tel' as the way you do it (by using a phone call). Other examples of answers to what? are "Web", "file transfer", "email", "fax", and "sms", "ems", "mms". How you do these things are variously to use 'http:','https:','ftp:', 'mailto:', and 'tel:' (according to RFC 4002 and RFC 4355). I guess you could stretch things to say that the "Pres" Enumservice tells you what kind of interaction is going to happen - I think RFC 3861 is the start of the trail for finding out how you do it. There are some Enumservices where you really have no idea what you're going to do - the joy of anticipation is left until later protocol-specific negotiation. For example, you have no way of knowing that the device you are going to get to by using a SIP URI is going to have a phone capability or not before you do the INVITE. Fortunately, almost all AoRs have phones associated with them. You might get unlucky and find an electric toaster at the other end, but it isn't that likely. If your gateway takes an incoming phone call and tries to connect it to a SIMPLE-only end point, well - life is hard. You could argue that any "protocol" registration like xmpp merely says that you don't or can't know in advance what kind of interaction is going to happen if you use this URL. All of these are really subtypes of the same Enumservice: "Do-You-Feel-Lucky-Punk?" My only concern is that I have a perfectly reasonable Jabber client that can do IM interaction, but it is not capable of voice (or, strictly, GoogleTalk). If the registrant really wants me to fire up a GoogleTalk client, then he should really say that this should start as a voice call - otherwise how is my ENUM client supposed to know what program it is supposed to fire up to handle the URI? I have no problem at all with an Enumservice registration not telling the client what kind of interaction to expect - it may be unknowable, as the protocol is so wide ranging that it could result in a full exchange of IM messages or World War Three. However, this does not, in my mind, preclude having another registration using that protocol that gives a hint on the kind of interaction that the client can expect to start. X-IM:xmpp and Voice:xmpp would help to tell me to fire up my Jabber client or to try to find a working Googletalk voice program for my Mac (or Linux box, or ...). As Alex says, you need both. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 30 01:34:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpfU5-0008TB-1N; Thu, 30 Nov 2006 01:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpfU3-0008T5-L6 for enum@ietf.org; Thu, 30 Nov 2006 01:33:23 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpfU2-00006Y-4d for enum@ietf.org; Thu, 30 Nov 2006 01:33:23 -0500 Received: from [172.17.1.113] (unknown [202.10.81.200]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 5991211A677; Thu, 30 Nov 2006 01:33:15 -0500 (EST) Message-ID: <456E7B25.6010701@e164.org> Date: Thu, 30 Nov 2006 17:33:09 +1100 From: Duane User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <20061128225646.GB26860@nic.at> <456CD852.1010303@e164.org> <456DB8A8.5000200@enum.at> <237A2882-907D-4BCA-8FDF-85ACE781FAEF@insensate.co.uk> In-Reply-To: <237A2882-907D-4BCA-8FDF-85ACE781FAEF@insensate.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org, Otmar Lendl , Alexander Mayrhofer X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: > However, this does not, in my mind, preclude having another registration > using that protocol that gives a hint on the kind of interaction that the > client can expect to start. X-IM:xmpp and Voice:xmpp would help to tell me > to fire up my Jabber client or to try to find a working Googletalk voice > program for my Mac (or Linux box, or ...). As I wrote in a previous email, people won't enter every possible type of enum service and how they can be contacted. This isn't how these services are used now, and I don't see it happening in future for 2 simple reasons, people are lazy, and more importantly what if I use MSN at work and at home, I use the MS client at work which supports all the bells and whistles, yet at home I use gaim which doesn't, yet both instances I use the same login details but I can't be bothered updating DNS 2 or more times a day just to update what the current client abilities are. While it might be possible to get some clients to interact with some enum roots, I doubt they will interact with all so people may in some cases be left doing manual updates and this just won't happen, so a simple I can be contacted by MSN with these details are the best way to attack this problem due to people being lazy. So if you make things too complicated people will end up ignoring enum completely and just falling back to what they already know and use all the time which makes this whole exercise a complete waste of time. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 30 04:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphpV-0005xH-Bp; Thu, 30 Nov 2006 04:03:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphpS-0005w0-Qj for enum@ietf.org; Thu, 30 Nov 2006 04:03:38 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GphpR-0006eM-65 for enum@ietf.org; Thu, 30 Nov 2006 04:03:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Date: Thu, 30 Nov 2006 10:02:45 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C52D6@oefeg-s04.oefeg.loc> In-Reply-To: <237A2882-907D-4BCA-8FDF-85ACE781FAEF@insensate.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Thread-Index: AccUH93H2PhVXxLsRnqa20RldxubkQAPSakQ From: "Stastny Richard" To: "lconroy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > However, this does not, in my mind, preclude having another registration > using that protocol that gives a hint on the kind of interaction that > the > client can expect to start. X-IM:xmpp and Voice:xmpp would help to > tell me > to fire up my Jabber client or to try to find a working Googletalk voice > program for my Mac (or Linux box, or ...). >=20 > As Alex says, you need both. I agree, because there is no solution to this problem. We should also not forget the basic requirement from Patrik: "A client must be able to decide on the NAPTR to choose without looking at the URI in the regexp." OTOH, the problem is not so big, IMO A jabber client may look for Enumservices XMPP, IM:XMPP, VOICE:XMPP (and not for SIP) A user may have only one, or he may either have XMPP or to different Enumservices pointing to IM:XMPP and VOICE:XMPP So the originator may choose depending on his client. Richard > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Thursday, November 30, 2006 2:35 AM > To: Alexander Mayrhofer > Cc: enum@ietf.org; Otmar Lendl; Duane > Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. >=20 > Hi Alex, folks, > OK - this quest is a long one. > On 29 Nov 2006, at 16:43, Alexander Mayrhofer wrote: > > Duane wrote: > >> Otmar Lendl wrote: > >>> XMPP isn't just for IM. Google Talk uses XMPP for VoIP. > (A puppy is not just for Christmas, it's for ... ?) > >> The same can be said for most if not all IM protocols. > > > > I think we will always have to deal with (at least) two "types" of > > registrations in ENUM. > > > > - The "application" type registration (like, in that case "im" > > pointing to > > an IM URI, which in turn resolves to an XMPP server). Examples: "im", > > "pres", "voice", "web", "ft" > > > > - The "protocol" registration (like "xmpp" in that case). Examples > > "sip", > > "h323", etc... > > > > I haven't yet found out which of the two the "holy grail" is - we > > also try > > to work on this issue in draft-ietf-enumservices-guide. > > contributions are > > very welcome for that document... >=20 > Seriously folks, this request for guideline text is timely. This > discussion > demonstrates that is it needed. >=20 > IMHO, as a client I would like the Enumservice field to answer two > questions: > - "What are am going to do if you use this contact?", and > - "How are you going to do it"? > These map to the Eumservice Type and Subtype - hence 'voice' is the > kind of > thing you want to do, and 'tel' as the way you do it (by using a > phone call). >=20 > Other examples of answers to what? are "Web", "file transfer", > "email", "fax", > and "sms", "ems", "mms". > How you do these things are variously to use 'http:','https:','ftp:', > 'mailto:', > and 'tel:' (according to RFC 4002 and RFC 4355). >=20 > I guess you could stretch things to say that the "Pres" Enumservice > tells you > what kind of interaction is going to happen - I think RFC 3861 is the > start of > the trail for finding out how you do it. >=20 > There are some Enumservices where you really have no idea what you're > going to > do - the joy of anticipation is left until later protocol-specific > negotiation. >=20 > For example, you have no way of knowing that the device you are going > to get > to by using a SIP URI is going to have a phone capability or not > before you > do the INVITE. Fortunately, almost all AoRs have phones associated > with them. > You might get unlucky and find an electric toaster at the other end, > but it > isn't that likely. If your gateway takes an incoming phone call and > tries to > connect it to a SIMPLE-only end point, well - life is hard. >=20 > You could argue that any "protocol" registration like xmpp merely > says that > you don't or can't know in advance what kind of interaction is going to > happen if you use this URL. All of these are really subtypes of the same > Enumservice: "Do-You-Feel-Lucky-Punk?" >=20 > My only concern is that I have a perfectly reasonable Jabber client > that can > do IM interaction, but it is not capable of voice (or, strictly, > GoogleTalk). >=20 > If the registrant really wants me to fire up a GoogleTalk client, then > he should really say that this should start as a voice call - > otherwise how > is my ENUM client supposed to know what program it is supposed to > fire up > to handle the URI? >=20 > I have no problem at all with an Enumservice registration not telling > the > client what kind of interaction to expect - it may be unknowable, as the > protocol is so wide ranging that it could result in a full exchange > of IM > messages or World War Three. >=20 > However, this does not, in my mind, preclude having another registration > using that protocol that gives a hint on the kind of interaction that > the > client can expect to start. X-IM:xmpp and Voice:xmpp would help to > tell me > to fire up my Jabber client or to try to find a working Googletalk voice > program for my Mac (or Linux box, or ...). >=20 > As Alex says, you need both. >=20 > all the best, > Lawrence >=20 >=20 > _______________________________________________ > 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 enum-bounces@ietf.org Thu Nov 30 09:26:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpmqw-0004SO-4q; Thu, 30 Nov 2006 09:25:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpmqv-0004S8-4G for enum@ietf.org; Thu, 30 Nov 2006 09:25:29 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpmqr-00052f-Sz for enum@ietf.org; Thu, 30 Nov 2006 09:25:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 09:24:51 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602713F7D@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated E.164 Plan - ITU-T Reference Thread-Index: AccUi0xHtyHF9ZraSx6VbOJIQLW9ew== From: "Livingood, Jason" To: X-OriginalArrivalTime: 30 Nov 2006 14:24:51.0428 (UTC) FILETIME=[4C2B8A40:01C7148B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Enum] Updated E.164 Plan - ITU-T Reference X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I have the reference below in an upcoming draft. But I think I saw something about this reference being out of date, maybe with something from 2005? Does anyone have this? ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. Thanks! Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 30 09:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn7O-0007l8-JY; Thu, 30 Nov 2006 09:42:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn7N-0007l0-Cd for enum@ietf.org; Thu, 30 Nov 2006 09:42:29 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gpn7M-0007LB-0Z for enum@ietf.org; Thu, 30 Nov 2006 09:42:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Updated E.164 Plan - ITU-T Reference Date: Thu, 30 Nov 2006 15:41:45 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C52E5@oefeg-s04.oefeg.loc> In-Reply-To: <45AEC6EF95942140888406588E1A6602713F7D@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Updated E.164 Plan - ITU-T Reference Thread-Index: AccUi0xHtyHF9ZraSx6VbOJIQLW9ewAAiIbg From: "Stastny Richard" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yes, all references in any draft to Rec. E.164 should have the date February 2005 Richard > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Thursday, November 30, 2006 3:25 PM > To: enum@ietf.org > Subject: [Enum] Updated E.164 Plan - ITU-T Reference >=20 > I have the reference below in an upcoming draft. But I think I saw > something about this reference being out of date, maybe with something > from 2005? Does anyone have this? >=20 > ITU-T, "The International Public Telecommunication Number Plan", > Recommendation E.164, May 1997. >=20 > Thanks! > Jason >=20 > _______________________________________________ > 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 enum-bounces@ietf.org Thu Nov 30 09:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn8h-00009q-M7; Thu, 30 Nov 2006 09:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn8f-000068-Qa for enum@ietf.org; Thu, 30 Nov 2006 09:43:49 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpn8e-0007a6-HY for enum@ietf.org; Thu, 30 Nov 2006 09:43:49 -0500 Received: from [10.10.0.218] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 30 Nov 2006 15:43:44 +0100 id 00000014.456EEE20.00000E19 Message-ID: <456EEE07.4060302@enum.at> Date: Thu, 30 Nov 2006 15:43:19 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] Updated E.164 Plan - ITU-T Reference References: <45AEC6EF95942140888406588E1A6602713F7D@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602713F7D@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: > I have the reference below in an upcoming draft. But I think I saw > something about this reference being out of date, maybe with something > from 2005? Does anyone have this? > > ITU-T, "The International Public Telecommunication Number Plan", > Recommendation E.164, May 1997. Yeah, there is a new revision of that. If you use xml2rfc, you might want to change that reference to: The international public telecommunication numbering plan ITU-T There might also be an "includeable" file on xml.ibiblio.org for that... cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 30 10:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoBO-0000F7-0E; Thu, 30 Nov 2006 10:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoBM-0000Cp-Bs for enum@ietf.org; Thu, 30 Nov 2006 10:50:40 -0500 Received: from open.nlnetlabs.nl ([213.154.224.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpoBJ-00076K-0W for enum@ietf.org; Thu, 30 Nov 2006 10:50:40 -0500 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.8/8.13.4) with ESMTP id kAUFo9nS021006; Thu, 30 Nov 2006 16:50:14 +0100 (CET) (envelope-from jaap@open.nlnetlabs.nl) Message-Id: <200611301550.kAUFo9nS021006@open.nlnetlabs.nl> To: "Stastny Richard" Subject: Re: [Enum] Updated E.164 Plan - ITU-T Reference In-reply-to: Your message of Thu, 30 Nov 2006 15:41:45 +0100. <32755D354E6B65498C3BD9FD496C7D463C52E5@oefeg-s04.oefeg.loc> Date: Thu, 30 Nov 2006 16:50:09 +0100 From: Jaap Akkerhuis X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on open.nlnetlabs.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: enum@ietf.org, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yes, all references in any draft to Rec. E.164 should have the date February 2005 Only when these versions of the E.164 were actually use. If the older versions were used, one should use that date. Just upping the date without checking whether changes were made is a dubious practice. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 30 16:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDY-00042h-6w; Thu, 30 Nov 2006 16:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDW-0003zx-J9 for enum@ietf.org; Thu, 30 Nov 2006 16:13:14 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GptDU-0006ih-0U for enum@ietf.org; Thu, 30 Nov 2006 16:13:14 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1GptD0-00004r-00 for enum@ietf.org; Thu, 30 Nov 2006 22:12:42 +0100 Date: Thu, 30 Nov 2006 22:12:31 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org Subject: RE: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C52D6@oefeg-s04.oefeg.loc> Message-ID: References: <32755D354E6B65498C3BD9FD496C7D463C52D6@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Following these discussions, we seem to lack the all-in-one ENUMservice for end-to-end communication; applicable for URIs that can be used for any of presence, IM, Voice, Video, application sharing or whatever people use the URI for. Spreading the same subtye to different types, e.g. im:xmpp, pres:xmpp, voice:xmpp and so on does not make much sense to me. To me it looks that the right solution is to specify an all-in-one ENUMservice type that can take different subtypes for the different "multi-service" protocols. In following examples lets call it e2ec (for end-2-end communication). Here some examples for services that offer at least presence and IM: e2ec:xmpp e2ec:icq e2ec:aim e2ec:ymsgr e2ec:skype e2ec:sip Here some examples of services used with audio and video: e2ec:h323 e2ec:iax2 As someone stated earlier in this thread, it is not really important, to get more information out of ENUM about the capabilities a user supports. This can be negotiated on the application protocol (XMPP, SIP, ...) level. This would deprecate some of the existing ENUMservices, e.g. sip, h323, ... What do you think about this idea? (appart from the backward-compatibiliy issues) cheers, Bernie PS: If people like this idea I might take the effort to write 'em down after returning from the Southern Hemisphere... On Thu, 30 Nov 2006, Stastny Richard wrote: >> However, this does not, in my mind, preclude having another > registration >> using that protocol that gives a hint on the kind of interaction that >> the >> client can expect to start. X-IM:xmpp and Voice:xmpp would help to >> tell me >> to fire up my Jabber client or to try to find a working Googletalk > voice >> program for my Mac (or Linux box, or ...). >> >> As Alex says, you need both. > > I agree, because there is no solution to this problem. > > We should also not forget the basic requirement from Patrik: > "A client must be able to decide on the NAPTR to choose without looking > at the URI in the regexp." > > OTOH, the problem is not so big, IMO > > A jabber client may look for Enumservices XMPP, IM:XMPP, VOICE:XMPP > (and not for SIP) > > A user may have only one, or he may either have XMPP or to different > Enumservices pointing to IM:XMPP and VOICE:XMPP > > So the originator may choose depending on his client. > > Richard > > > >> -----Original Message----- >> From: lconroy [mailto:lconroy@insensate.co.uk] >> Sent: Thursday, November 30, 2006 2:35 AM >> To: Alexander Mayrhofer >> Cc: enum@ietf.org; Otmar Lendl; Duane >> Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. >> >> Hi Alex, folks, >> OK - this quest is a long one. >> On 29 Nov 2006, at 16:43, Alexander Mayrhofer wrote: >>> Duane wrote: >>>> Otmar Lendl wrote: >>>>> XMPP isn't just for IM. Google Talk uses XMPP for VoIP. >> (A puppy is not just for Christmas, it's for ... ?) >>>> The same can be said for most if not all IM protocols. >>> >>> I think we will always have to deal with (at least) two "types" of >>> registrations in ENUM. >>> >>> - The "application" type registration (like, in that case "im" >>> pointing to >>> an IM URI, which in turn resolves to an XMPP server). Examples: > "im", >>> "pres", "voice", "web", "ft" >>> >>> - The "protocol" registration (like "xmpp" in that case). Examples >>> "sip", >>> "h323", etc... >>> >>> I haven't yet found out which of the two the "holy grail" is - we >>> also try >>> to work on this issue in draft-ietf-enumservices-guide. >>> contributions are >>> very welcome for that document... >> >> Seriously folks, this request for guideline text is timely. This >> discussion >> demonstrates that is it needed. >> >> IMHO, as a client I would like the Enumservice field to answer two >> questions: >> - "What are am going to do if you use this contact?", and >> - "How are you going to do it"? >> These map to the Eumservice Type and Subtype - hence 'voice' is the >> kind of >> thing you want to do, and 'tel' as the way you do it (by using a >> phone call). >> >> Other examples of answers to what? are "Web", "file transfer", >> "email", "fax", >> and "sms", "ems", "mms". >> How you do these things are variously to use 'http:','https:','ftp:', >> 'mailto:', >> and 'tel:' (according to RFC 4002 and RFC 4355). >> >> I guess you could stretch things to say that the "Pres" Enumservice >> tells you >> what kind of interaction is going to happen - I think RFC 3861 is the >> start of >> the trail for finding out how you do it. >> >> There are some Enumservices where you really have no idea what you're >> going to >> do - the joy of anticipation is left until later protocol-specific >> negotiation. >> >> For example, you have no way of knowing that the device you are going >> to get >> to by using a SIP URI is going to have a phone capability or not >> before you >> do the INVITE. Fortunately, almost all AoRs have phones associated >> with them. >> You might get unlucky and find an electric toaster at the other end, >> but it >> isn't that likely. If your gateway takes an incoming phone call and >> tries to >> connect it to a SIMPLE-only end point, well - life is hard. >> >> You could argue that any "protocol" registration like xmpp merely >> says that >> you don't or can't know in advance what kind of interaction is going > to >> happen if you use this URL. All of these are really subtypes of the > same >> Enumservice: "Do-You-Feel-Lucky-Punk?" >> >> My only concern is that I have a perfectly reasonable Jabber client >> that can >> do IM interaction, but it is not capable of voice (or, strictly, >> GoogleTalk). >> >> If the registrant really wants me to fire up a GoogleTalk client, then >> he should really say that this should start as a voice call - >> otherwise how >> is my ENUM client supposed to know what program it is supposed to >> fire up >> to handle the URI? >> >> I have no problem at all with an Enumservice registration not telling >> the >> client what kind of interaction to expect - it may be unknowable, as > the >> protocol is so wide ranging that it could result in a full exchange >> of IM >> messages or World War Three. >> >> However, this does not, in my mind, preclude having another > registration >> using that protocol that gives a hint on the kind of interaction that >> the >> client can expect to start. X-IM:xmpp and Voice:xmpp would help to >> tell me >> to fire up my Jabber client or to try to find a working Googletalk > voice >> program for my Mac (or Linux box, or ...). >> >> As Alex says, you need both. >> >> all the best, >> Lawrence >> >> >> _______________________________________________ >> 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 enum-bounces@ietf.org Thu Nov 30 16:42:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gptew-0006pn-Ma; Thu, 30 Nov 2006 16:41:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gptev-0006ph-HK for enum@ietf.org; Thu, 30 Nov 2006 16:41:33 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gptes-0004W8-Mv for enum@ietf.org; Thu, 30 Nov 2006 16:41:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Date: Thu, 30 Nov 2006 22:40:49 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C21@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Thread-Index: AccUxHMMQ8Uy1KslTLutpcWRIKsetQAAgpjO References: <32755D354E6B65498C3BD9FD496C7D463C52D6@oefeg-s04.oefeg.loc> From: "Stastny Richard" To: "Bernie Hoeneisen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Bernie, =20 the problem with ENUM and URIs is that all options are valid =20 Your proposal is ok, but covers only URIs which are used for protocols that allow negotiation =20 There is different types of URIs which a) do not allow negotiation. One example is tel one may use tel for voice, sms, mms, but there is no way until you try and it works or fails =20 b) may be used for different applications e.g mms:mailto =20 In addition we have the user, who may want to use one protocol for voice, another one for video, one for presence and one for = messaging, etc. =20 We had this discussion for years now, with no result. Everybody proposing a solution like you covers only part of the spectrum, the does not exist a perfect solution - or we would already have found it in 4 years =20 I think we have to live with this mess =20 Richard PS: Infrastructure ENUM will anyways only use sip, voice:tel, sms:mailto = and mms:mailto ;-) ________________________________ Von: Bernie Hoeneisen [mailto:bhoeneis@switch.ch] Gesendet: Do 30.11.2006 22:12 An: enum@ietf.org Betreff: RE: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. Following these discussions, we seem to lack the all-in-one ENUMservice for end-to-end communication; applicable for URIs that can be used for = any of presence, IM, Voice, Video, application sharing or whatever people = use the URI for. Spreading the same subtye to different types, e.g. im:xmpp, pres:xmpp, voice:xmpp and so on does not make much sense to me. To me it looks that the right solution is to specify an all-in-one ENUMservice type that can take different subtypes for the different "multi-service" protocols. In following examples lets call it e2ec (for end-2-end communication). Here some examples for services that offer at least presence and IM: e2ec:xmpp e2ec:icq e2ec:aim e2ec:ymsgr e2ec:skype e2ec:sip Here some examples of services used with audio and video: e2ec:h323 e2ec:iax2 As someone stated earlier in this thread, it is not really important, to get more information out of ENUM about the capabilities a user supports. This can be negotiated on the application protocol (XMPP, SIP, ...) = level. This would deprecate some of the existing ENUMservices, e.g. sip, h323, ... What do you think about this idea? (appart from the backward-compatibiliy issues) cheers, Bernie PS: If people like this idea I might take the effort to write 'em down after returning from the Southern Hemisphere... On Thu, 30 Nov 2006, Stastny Richard wrote: >> However, this does not, in my mind, preclude having another > registration >> using that protocol that gives a hint on the kind of interaction that >> the >> client can expect to start. X-IM:xmpp and Voice:xmpp would help to >> tell me >> to fire up my Jabber client or to try to find a working Googletalk > voice >> program for my Mac (or Linux box, or ...). >> >> As Alex says, you need both. > > I agree, because there is no solution to this problem. > > We should also not forget the basic requirement from Patrik: > "A client must be able to decide on the NAPTR to choose without = looking > at the URI in the regexp." > > OTOH, the problem is not so big, IMO > > A jabber client may look for Enumservices XMPP, IM:XMPP, VOICE:XMPP > (and not for SIP) > > A user may have only one, or he may either have XMPP or to different > Enumservices pointing to IM:XMPP and VOICE:XMPP > > So the originator may choose depending on his client. > > Richard > > > >> -----Original Message----- >> From: lconroy [mailto:lconroy@insensate.co.uk] >> Sent: Thursday, November 30, 2006 2:35 AM >> To: Alexander Mayrhofer >> Cc: enum@ietf.org; Otmar Lendl; Duane >> Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp.. >> >> Hi Alex, folks, >> OK - this quest is a long one. >> On 29 Nov 2006, at 16:43, Alexander Mayrhofer wrote: >>> Duane wrote: >>>> Otmar Lendl wrote: >>>>> XMPP isn't just for IM. Google Talk uses XMPP for VoIP. >> (A puppy is not just for Christmas, it's for ... ?) >>>> The same can be said for most if not all IM protocols. >>> >>> I think we will always have to deal with (at least) two "types" of >>> registrations in ENUM. >>> >>> - The "application" type registration (like, in that case "im" >>> pointing to >>> an IM URI, which in turn resolves to an XMPP server). Examples: > "im", >>> "pres", "voice", "web", "ft" >>> >>> - The "protocol" registration (like "xmpp" in that case). Examples >>> "sip", >>> "h323", etc... >>> >>> I haven't yet found out which of the two the "holy grail" is - we >>> also try >>> to work on this issue in draft-ietf-enumservices-guide. >>> contributions are >>> very welcome for that document... >> >> Seriously folks, this request for guideline text is timely. This >> discussion >> demonstrates that is it needed. >> >> IMHO, as a client I would like the Enumservice field to answer two >> questions: >> - "What are am going to do if you use this contact?", and >> - "How are you going to do it"? >> These map to the Eumservice Type and Subtype - hence 'voice' is the >> kind of >> thing you want to do, and 'tel' as the way you do it (by using a >> phone call). >> >> Other examples of answers to what? are "Web", "file transfer", >> "email", "fax", >> and "sms", "ems", "mms". >> How you do these things are variously to use 'http:','https:','ftp:', >> 'mailto:', >> and 'tel:' (according to RFC 4002 and RFC 4355). >> >> I guess you could stretch things to say that the "Pres" Enumservice >> tells you >> what kind of interaction is going to happen - I think RFC 3861 is the >> start of >> the trail for finding out how you do it. >> >> There are some Enumservices where you really have no idea what you're >> going to >> do - the joy of anticipation is left until later protocol-specific >> negotiation. >> >> For example, you have no way of knowing that the device you are going >> to get >> to by using a SIP URI is going to have a phone capability or not >> before you >> do the INVITE. Fortunately, almost all AoRs have phones associated >> with them. >> You might get unlucky and find an electric toaster at the other end, >> but it >> isn't that likely. If your gateway takes an incoming phone call and >> tries to >> connect it to a SIMPLE-only end point, well - life is hard. >> >> You could argue that any "protocol" registration like xmpp merely >> says that >> you don't or can't know in advance what kind of interaction is going > to >> happen if you use this URL. All of these are really subtypes of the > same >> Enumservice: "Do-You-Feel-Lucky-Punk?" >> >> My only concern is that I have a perfectly reasonable Jabber client >> that can >> do IM interaction, but it is not capable of voice (or, strictly, >> GoogleTalk). >> >> If the registrant really wants me to fire up a GoogleTalk client, = then >> he should really say that this should start as a voice call - >> otherwise how >> is my ENUM client supposed to know what program it is supposed to >> fire up >> to handle the URI? >> >> I have no problem at all with an Enumservice registration not telling >> the >> client what kind of interaction to expect - it may be unknowable, as > the >> protocol is so wide ranging that it could result in a full exchange >> of IM >> messages or World War Three. >> >> However, this does not, in my mind, preclude having another > registration >> using that protocol that gives a hint on the kind of interaction that >> the >> client can expect to start. X-IM:xmpp and Voice:xmpp would help to >> tell me >> to fire up my Jabber client or to try to find a working Googletalk > voice >> program for my Mac (or Linux box, or ...). >> >> As Alex says, you need both. >> >> all the best, >> Lawrence >> >> >> _______________________________________________ >> 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 30 19:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpwjs-0003rQ-PY; Thu, 30 Nov 2006 19:58:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpwjp-0003qW-VG; Thu, 30 Nov 2006 19:58:49 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpwjo-0007y9-Hv; Thu, 30 Nov 2006 19:58:49 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id kB10wmtX015422; Thu, 30 Nov 2006 16:58:48 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id kB10wmvk015421; Thu, 30 Nov 2006 16:58:48 -0800 Date: Thu, 30 Nov 2006 16:58:48 -0800 Message-Id: <200612010058.kB10wmvk015421@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.3 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 4769 on IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4769 Title: IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information Author: J. Livingood, R. Shockey Status: Standards Track Date: November 2006 Mailbox: jason_livingood@cable.comcast.com, richard.shockey@neustar.biz Pages: 13 Characters: 24945 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-pstn-05.txt URL: http://www.rfc-editor.org/rfc/rfc4769.txt This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. [STANDARDS TRACK] This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 30 19:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpwjh-0003ps-Lm; Thu, 30 Nov 2006 19:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpwje-0003pX-Mj; Thu, 30 Nov 2006 19:58:38 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpwjd-0007wt-49; Thu, 30 Nov 2006 19:58:38 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id kB10wa9R015412; Thu, 30 Nov 2006 16:58:36 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id kB10wadJ015411; Thu, 30 Nov 2006 16:58:36 -0800 Date: Thu, 30 Nov 2006 16:58:36 -0800 Message-Id: <200612010058.kB10wadJ015411@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 4725 on ENUM Validation Architecture X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4725 Title: ENUM Validation Architecture Author: A. Mayrhofer, B. Hoeneisen Status: Informational Date: November 2006 Mailbox: alexander.mayrhofer@enum.at, b.hoeneisen@ieee.org Pages: 17 Characters: 33216 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-validation-arch-04.txt URL: http://www.rfc-editor.org/rfc/rfc4725.txt An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure. This memo provides information for the Internet community. This document is a product of the Telephone Number Mapping Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum