From enum-bounces@ietf.org Tue Jan 02 06:15:49 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H1hbE-0004uP-Gi; Tue, 02 Jan 2007 06:14:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hbD-0004rR-Aj
	for enum@ietf.org; Tue, 02 Jan 2007 06:14:31 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hb8-0002dV-UJ
	for enum@ietf.org; Tue, 02 Jan 2007 06:14:31 -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 l02BEOe9022614Tue, 2 Jan 2007 11:14:24 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H1hb6-0005qg-00; Tue, 02 Jan 2007 11:14:24 +0000
Date: Tue, 2 Jan 2007 11:14:24 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070102111424.GI5435@finch-staff-1.thus.net>
References: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com>
User-Agent: Mutt/1.5.3i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: enum@ietf.org, rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Livingood, Jason said:
> Attached is the new -04 draft, which was just submitted to the editor.
[...]

> 5. Security and Privacy Considerations 
>     
>    Since Infrastructure ENUM is also implemented on the public Internet, 
>    the same security considerations apply as noted in RFC 3761. 
>      
>    In addition, since there is no opt-in for end-users, personally-
>    identifiable information (PII) must not be disclosed for any end-
>    user.  
>     
>    Thus, the information provided in the NAPTR records must not disclose 
>    any PII about the end-user such as a name in user-info. This can be 
>    achieved, for example, by entering the information in the format 
>    sip:<e164_phone_number>@provider.example.net,  
>    mailto:<e164_phone_number>@provider.example.net or sip:<opaque 
>    string>@provider.example.net. 

The UK's Office of the Information Commissioner have stated that the
identity of the provider used by a user *is* PII in this context.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Tue Jan 02 06:37:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H1hwt-0001xB-Lh; Tue, 02 Jan 2007 06:36:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hwr-0001x5-Le
	for enum@ietf.org; Tue, 02 Jan 2007 06:36:53 -0500
Received: from bay0-omc3-s16.bay0.hotmail.com ([65.54.246.216])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hwq-0008F9-9l
	for enum@ietf.org; Tue, 02 Jan 2007 06:36:53 -0500
Received: from hotmail.com ([65.54.174.89]) by bay0-omc3-s16.bay0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.2668); 
	Tue, 2 Jan 2007 03:36:52 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	Tue, 2 Jan 2007 03:36:51 -0800
Message-ID: <BAY103-DAV17C2A8F8E63C206F1ECDEC92BA0@phx.gbl>
Received: from 69.227.152.254 by BAY103-DAV17.phx.gbl with DAV;
	Tue, 02 Jan 2007 11:36:47 +0000
X-Originating-IP: [69.227.152.254]
X-Originating-Email: [home_pw@msn.com]
X-Sender: home_pw@msn.com
From: <home_pw@msn.com>
To: "Clive D.W. Feather" <clive@demon.net>
References: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com>
	<20070102111424.GI5435@finch-staff-1.thus.net>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Tue, 2 Jan 2007 03:37:04 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 02 Jan 2007 11:36:51.0760 (UTC)
	FILETIME=[4BDA0300:01C72E62]
X-Spam-Score: 0.7 (/)
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Is the legal opinion an assertion that:-

The fact of association of a provider with a consumer is 
PII, when its related to that users phone number 
registration?

Given the pretexting scandal, which showed up how limited 
privacy is in the US space, would we be now saying that even 
attempting to determine the association (search the DNS, or 
resolve a ENUM address) would be presumed to be an attempted 
act against that privacy interest?

This is a bit similar to another UK example. Given a URL, 
modifying it and resolving it can then be a criminal act - 
being an unlawful search that abuses the IT system in 
question, in an "unauthorized manner".

The value here is that folks establishing an expectation of 
privacy have concrete means of enforcing it. Its more than a 
vague idealistic idea, as in the traditional Internet where 
privacy was useful mostly for marketing.

----- Original Message -----
From: "Clive D.W. Feather" <clive@demon.net>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Cc: <enum@ietf.org>; <rich.shockey@neustar.biz>
Sent: Tuesday, January 02, 2007 3:14 AM
Subject: Re: [Enum] NITS review of 
draft-ietf-enum-infrastructure-03

> Livingood, Jason said:
>> Attached is the new -04 draft, which was just submitted 
>> to the editor.
> [...]
>
>> 5. Security and Privacy Considerations
>>
>>    Since Infrastructure ENUM is also implemented on the 
>> public Internet,
>>    the same security considerations apply as noted in RFC 
>> 3761.
>>
>>    In addition, since there is no opt-in for end-users, 
>> personally-
>>    identifiable information (PII) must not be disclosed 
>> for any end-
>>    user.
>>
>>    Thus, the information provided in the NAPTR records 
>> must not disclose
>>    any PII about the end-user such as a name in 
>> user-info. This can be
>>    achieved, for example, by entering the information in 
>> the format
>>    sip:<e164_phone_number>@provider.example.net,
>>    mailto:<e164_phone_number>@provider.example.net or 
>> sip:<opaque
>>    string>@provider.example.net.
>
> The UK's Office of the Information Commissioner have 
> stated that the
> identity of the provider used by a user *is* PII in this 
> context.
>
> -- 
> Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel: 
> +44 20 8495 6138
> Internet Expert     | Home:  <clive@davros.org>  | 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
> 

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



From enum-bounces@ietf.org Tue Jan 02 06:39:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H1hzV-0003Gs-Qc; Tue, 02 Jan 2007 06:39:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hzU-0003Gl-P5
	for enum@ietf.org; Tue, 02 Jan 2007 06:39:36 -0500
Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H1hzT-0003Sm-B1
	for enum@ietf.org; Tue, 02 Jan 2007 06:39:36 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by insensate.co.uk (Postfix) with ESMTP id 03EA092C5A;
	Tue,  2 Jan 2007 11:39:32 +0000 (GMT)
In-Reply-To: <20070102111424.GI5435@finch-staff-1.thus.net>
References: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com>
	<20070102111424.GI5435@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: <785A120B-9D8F-4928-8128-CBDB7EB1DDD4@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Tue, 2 Jan 2007 11:39:32 +0000
To: Clive D.W.Feather <clive@demon.net>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: enum@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi folks,
  I am unaware of a formal written opinion from the Information
Commissioner on this matter.
Until there is such a formal opinion and clarification on permitted
data, IMHO this draft is fine. Otherwise we are chasing phantoms.

If any NRA or equivalent data protection authority refused to permit
a necessary part of SIP URLs to be published, then doing so would
make VoIP in general rather hard. An originating system has to be able
to "find" the destination SIP provider or it isn't going to work. I hear
rumours, but I can't believe anyone intends to block VoIP in this way.

I'm waiting for an official, tested, opinion before making any other  
comment.

all the best,
   Lawrence

On 2 Jan 2007, at 11:14, Clive D.W. Feather wrote:
> Livingood, Jason said:
>>    In addition, since there is no opt-in for end-users, personally-
>>    identifiable information (PII) must not be disclosed for any end-
>>    user.
>>
>>    Thus, the information provided in the NAPTR records must not  
>> disclose
>>    any PII about the end-user such as a name in user-info. This  
>> can be
>>    achieved, for example, by entering the information in the format
>>    sip:<e164_phone_number>@provider.example.net,
>>    mailto:<e164_phone_number>@provider.example.net or sip:<opaque
>>    string>@provider.example.net.
>
> The UK's Office of the Information Commissioner have stated that the
> identity of the provider used by a user *is* PII in this context.


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



From enum-bounces@ietf.org Tue Jan 02 13:45:37 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H1od3-0000Im-5o; Tue, 02 Jan 2007 13:44:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H1od2-0000IU-BV
	for enum@ietf.org; Tue, 02 Jan 2007 13:44:52 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ocz-0008Jw-1R
	for enum@ietf.org; Tue, 02 Jan 2007 13:44:52 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2007 10:44:49 -0800
X-IronPort-AV: i="4.12,227,1165219200"; 
	d="scan'208"; a="49841453:sNHT47441092"
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 l02IimpQ011002; 
	Tue, 2 Jan 2007 13:44:48 -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 l02IimG9020508; 
	Tue, 2 Jan 2007 13:44:48 -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); 
	Tue, 2 Jan 2007 13:44:48 -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] NITS review of draft-ietf-enum-infrastructure-03
Date: Tue, 2 Jan 2007 13:44:47 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302621D8D@xmb-rtp-20b.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccuX41qpnSBv5jzRG6MrwTr1b/wWgAPiv7Q
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Clive D.W. Feather" <clive@demon.net>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>
X-OriginalArrivalTime: 02 Jan 2007 18:44:48.0463 (UTC)
	FILETIME=[145BF5F0:01C72E9E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1985; t=1167763488;
	x=1168627488; 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<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Enum]=20NITS=20review=20of=20draft-ietf-enum-infrast
	ructure-03 |Sender:=20
	|To:=20=22Clive=20D.W.=20Feather=22=20<clive@demon.net>,
	=0A=20=20=20=20=2
	0=20=20=20=22Livingood,=20Jason=22=20<Jason_Livingood@cable.comcast.com>;
	bh=EwZ8ojc9TFhHlKjBKWUFp3bbYv6q+Q/NjVVZqpwiM+k=;
	b=GWIGdGIugbArv2jToC/LpahrHQAscMzHyj1tkxw+rSAoBPNCGgvwV1MZAT2EnJr4WTrn1J/U
	Qtb1uGceCmmBCPcnu3JjURLvvqPmHl4w/A6dXSNBmyIMltp/RVjIFLBA;
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: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: enum@ietf.org, rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Clive,

I see no user at all here:

 sip:<e164_phone_number>@provider.example.net

Thus, PII is not an issue.

Mike



> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net]=20
> Sent: Tuesday, January 02, 2007 6:14 AM
> To: Livingood, Jason
> Cc: enum@ietf.org; rich.shockey@neustar.biz
> Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
>=20
> Livingood, Jason said:
> > Attached is the new -04 draft, which was just submitted to=20
> the editor.
> [...]
>=20
> > 5. Security and Privacy Considerations
> >    =20
> >    Since Infrastructure ENUM is also implemented on the=20
> public Internet,=20
> >    the same security considerations apply as noted in RFC 3761.=20
> >     =20
> >    In addition, since there is no opt-in for end-users, personally-
> >    identifiable information (PII) must not be disclosed for any end-
> >    user. =20
> >    =20
> >    Thus, the information provided in the NAPTR records must=20
> not disclose=20
> >    any PII about the end-user such as a name in user-info.=20
> This can be=20
> >    achieved, for example, by entering the information in the format=20
> >    sip:<e164_phone_number>@provider.example.net, =20
> >    mailto:<e164_phone_number>@provider.example.net or sip:<opaque=20
> >    string>@provider.example.net.=20
>=20
> The UK's Office of the Information Commissioner have stated=20
> that the identity of the provider used by a user *is* PII in=20
> this context.
>=20
> --=20
> Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:   =20
> +44 20 8495 6138
> Internet Expert     | Home:  <clive@davros.org>  | Fax:   =20
> +44 870 051 9937
> Demon Internet      | WWW: http://www.davros.org | Mobile:=20
> +44 7973 377646
> THUS plc            |                            |
>=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 Jan 02 15:51:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H1qaf-00054L-W0; Tue, 02 Jan 2007 15:50:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H1qae-00053M-Kh; Tue, 02 Jan 2007 15:50:32 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1H1qae-0004DK-BB; Tue, 02 Jan 2007 15:50:32 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 42D382ACC9;
	Tue,  2 Jan 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H1qaA-0002ma-0W; Tue, 02 Jan 2007 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: <E1H1qaA-0002ma-0W@stiedprstage1.ietf.org>
Date: Tue, 02 Jan 2007 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-04.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=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-04.txt
	Pages		: 6
	Date		: 2007-1-2
	
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-04.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-04.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-04.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: <2007-1-2113427.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-infrastructure-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-infrastructure-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-1-2113427.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 Jan 02 17:07:21 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H1rmC-0003Kf-N9; Tue, 02 Jan 2007 17:06:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rmC-0003Ka-Bu
	for enum@ietf.org; Tue, 02 Jan 2007 17:06:32 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rmB-0002QC-03
	for enum@ietf.org; Tue, 02 Jan 2007 17:06:32 -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
	l02M6FnH005372; Tue, 2 Jan 2007 14:06:21 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <enum@ietf.org>
Date: Tue, 2 Jan 2007 17:06:03 -0500
Message-ID: <021301c72eba$33009760$87201f0a@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcaqGAJLNfWlX+qNTGSuHne1ju0khA==
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: cab78e1e39c4b328567edb48482b6a69
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	'Leslie Daigle' <leslie@thinkingcat.com>,
	=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= <paf@cisco.com>,
	"'Peterson, Jon'" <jon.peterson@neustar.biz>
Subject: [Enum] ENUM WG Last Call for draft-ietf-enum-infrastructure-04.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


	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-04.txt
	Pages		: 6
	Date		: 2007-1-2
	
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-04.txt

The intent of the last call is to solicit comments before submitting the ID
to the IESG.

The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections which have
not gotten previous or adequate discussion, or minor errors which need
correction.

Work group last call will extend from today to Janurary 19, 2007 toinsure a
through and proper review during the holiday period though we can modify
that if new issues come up.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:57141@fwd.pulver.com
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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



From enum-bounces@ietf.org Wed Jan 03 10:27:33 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H280h-0004pu-Qh; Wed, 03 Jan 2007 10:26:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ovl-0004Lj-0A
	for enum@ietf.org; Tue, 02 Jan 2007 14:04:13 -0500
Received: from sirius.wcom.co.uk ([193.131.254.154]
	helo=sirius.emea.verizonbusiness.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ovj-0003U9-8a
	for enum@ietf.org; Tue, 02 Jan 2007 14:04:12 -0500
Received: from sirius.wcom.co.uk ([166.59.190.29] helo=sirius.emea.mci.com)
	by sirius.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H1ovZ-000339-8V; Tue, 02 Jan 2007 19:04:03 +0000
Received: from ocampa.emea.verizonbusiness.com (leste.wcom.co.uk
	[166.59.190.250]) by sirius.emea.mci.com (4.7.0.120) with ESMTP id ;
	Tue, 2 Jan 2007 19:03:38 GMT
Received: from ms-lon-exgw02.uk.mcilink.com ([166.59.191.19]
	helo=ms-lon-exgw02.emea.dsmain.com)
	by ocampa.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H1ovB-0000m4-Ql; Tue, 02 Jan 2007 19:03:37 +0000
Received: by ms-lon-exgw02.uk.mcilink.com with Internet Mail Service
	(5.5.2658.27) id <Z4G7T5MX>; Tue, 2 Jan 2007 19:03:23 -0000
Message-ID: <CA3896DB5903C14EAAC9D8E91D1167CBCC757F@ms-lon-exmb06.uk.mcilink.com>
From: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
To: "'mhammer@cisco.com'" <mhammer@cisco.com>, "'clive@demon.net'"
	<clive@demon.net>, "'Jason_Livingood@cable.comcast.com'"
	<Jason_Livingood@cable.comcast.com>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Tue, 2 Jan 2007 19:03:22 -0000 
X-Mailer: Internet Mail Service (5.5.2658.27)
MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40)
X-VZ-EMEA-Spam-Score: -498.4
	(---------------------------------------------------)
X-VZ-EMEA-Signature: c08bed470159a70d7222cafeac318b75
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027
X-Mailman-Approved-At: Wed, 03 Jan 2007 10:26:33 -0500
Cc: "'enum@ietf.org'" <enum@ietf.org>,
	"'rich.shockey@neustar.biz'" <rich.shockey@neustar.biz>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0235071684=="
Errors-To: enum-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0235071684==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C72EA0.AC35AF44"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C72EA0.AC35AF44
Content-Type: text/plain;
	charset="UTF-8"

Clive, are we dealing with an actual Internet versus Telco logic problem
here?

I'd tend to agree with Lawrence and also his comments re: formal statement
on subject in writing. I didn't spot anything in the DTI response from the
Commission on UK ENUM in general.

Ronan

-----Original Message-----
From: Michael Hammer (mhammer) <mhammer@cisco.com>
To: Clive D.W. Feather <clive@demon.net>; Livingood, Jason
<Jason_Livingood@cable.comcast.com>
CC: enum@ietf.org <enum@ietf.org>; rich.shockey@neustar.biz
<rich.shockey@neustar.biz>
Sent: Tue Jan 02 18:44:47 2007
Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03

Clive,

I see no user at all here:

 sip:<e164_phone_number>@provider.example.net

Thus, PII is not an issue.

Mike



> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net] 
> Sent: Tuesday, January 02, 2007 6:14 AM
> To: Livingood, Jason
> Cc: enum@ietf.org; rich.shockey@neustar.biz
> Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
> 
> Livingood, Jason said:
> > Attached is the new -04 draft, which was just submitted to 
> the editor.
> [...]
> 
> > 5. Security and Privacy Considerations
> >     
> >    Since Infrastructure ENUM is also implemented on the 
> public Internet, 
> >    the same security considerations apply as noted in RFC 3761. 
> >      
> >    In addition, since there is no opt-in for end-users, personally-
> >    identifiable information (PII) must not be disclosed for any end-
> >    user.  
> >     
> >    Thus, the information provided in the NAPTR records must 
> not disclose 
> >    any PII about the end-user such as a name in user-info. 
> This can be 
> >    achieved, for example, by entering the information in the format 
> >    sip:<e164_phone_number>@provider.example.net,  
> >    mailto:<e164_phone_number>@provider.example.net or sip:<opaque 
> >    string>@provider.example.net. 
> 
> The UK's Office of the Information Commissioner have stated 
> that the identity of the provider used by a user *is* PII in 
> this context.
> 
> -- 
> Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    
> +44 20 8495 6138
> Internet Expert     | Home:  <clive@davros.org>  | 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
> 

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

------_=_NextPart_001_01C72EA0.AC35AF44
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUTF-8">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>Re: [Enum] NITS review of =
draft-ietf-enum-infrastructure-03</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Clive, are we dealing with an actual Internet versus =
Telco logic problem here?</FONT>
</P>

<P><FONT SIZE=3D2>I'd tend to agree with Lawrence and also his comments =
re: formal statement on subject in writing. I didn't spot anything in =
the DTI response from the Commission on UK ENUM in general.</FONT></P>

<P><FONT SIZE=3D2>Ronan</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Hammer (mhammer) =
&lt;mhammer@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>To: Clive D.W. Feather &lt;clive@demon.net&gt;; =
Livingood, Jason &lt;Jason_Livingood@cable.comcast.com&gt;</FONT>
<BR><FONT SIZE=3D2>CC: enum@ietf.org &lt;enum@ietf.org&gt;; =
rich.shockey@neustar.biz &lt;rich.shockey@neustar.biz&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Tue Jan 02 18:44:47 2007</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Enum] NITS review of =
draft-ietf-enum-infrastructure-03</FONT>
</P>

<P><FONT SIZE=3D2>Clive,</FONT>
</P>

<P><FONT SIZE=3D2>I see no user at all here:</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;sip:&lt;e164_phone_number&gt;@provider.example.net</FONT>=

</P>

<P><FONT SIZE=3D2>Thus, PII is not an issue.</FONT>
</P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Clive D.W. Feather [<A =
HREF=3D"mailto:clive@demon.net">mailto:clive@demon.net</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 02, 2007 6:14 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Livingood, Jason</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: enum@ietf.org; =
rich.shockey@neustar.biz</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Enum] NITS review of =
draft-ietf-enum-infrastructure-03</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Livingood, Jason said:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Attached is the new -04 draft, which was =
just submitted to </FONT>
<BR><FONT SIZE=3D2>&gt; the editor.</FONT>
<BR><FONT SIZE=3D2>&gt; [...]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 5. Security and Privacy =
Considerations</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Since Infrastructure =
ENUM is also implemented on the </FONT>
<BR><FONT SIZE=3D2>&gt; public Internet, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; the same security =
considerations apply as noted in RFC 3761. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; In addition, since there =
is no opt-in for end-users, personally-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; identifiable information =
(PII) must not be disclosed for any end-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; user.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Thus, the information =
provided in the NAPTR records must </FONT>
<BR><FONT SIZE=3D2>&gt; not disclose </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; any PII about the =
end-user such as a name in user-info. </FONT>
<BR><FONT SIZE=3D2>&gt; This can be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; achieved, for example, =
by entering the information in the format </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; =
sip:&lt;e164_phone_number&gt;@provider.example.net,&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; =
mailto:&lt;e164_phone_number&gt;@provider.example.net or sip:&lt;opaque =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; =
string&gt;@provider.example.net. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The UK's Office of the Information Commissioner =
have stated </FONT>
<BR><FONT SIZE=3D2>&gt; that the identity of the provider used by a =
user *is* PII in </FONT>
<BR><FONT SIZE=3D2>&gt; this context.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Clive D.W. Feather&nbsp; | Work:&nbsp; =
&lt;clive@demon.net&gt;&nbsp;&nbsp; | Tel:&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; +44 20 8495 6138</FONT>
<BR><FONT SIZE=3D2>&gt; Internet Expert&nbsp;&nbsp;&nbsp;&nbsp; | =
Home:&nbsp; &lt;clive@davros.org&gt;&nbsp; | Fax:&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; +44 870 051 9937</FONT>
<BR><FONT SIZE=3D2>&gt; Demon Internet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
WWW: <A HREF=3D"http://www.davros.org" =
TARGET=3D"_blank">http://www.davros.org</A> | Mobile: </FONT>
<BR><FONT SIZE=3D2>&gt; +44 7973 377646</FONT>
<BR><FONT SIZE=3D2>&gt; THUS =
plc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; enum mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; enum@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>enum mailing list</FONT>
<BR><FONT SIZE=3D2>enum@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C72EA0.AC35AF44--


--===============0235071684==
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

--===============0235071684==--




From enum-bounces@ietf.org Wed Jan 03 15:51:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2D4H-0003d4-Eb; Wed, 03 Jan 2007 15:50:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2D4D-0003Yz-PB; Wed, 03 Jan 2007 15:50:33 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1H2D4C-0005GA-Fh; Wed, 03 Jan 2007 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 65C8F2ACCA;
	Wed,  3 Jan 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H2D3i-0001ms-5T; Wed, 03 Jan 2007 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: <E1H2D3i-0001ms-5T@stiedprstage1.ietf.org>
Date: Wed, 03 Jan 2007 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-xmpp-01.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=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-01.txt
	Pages		: 8
	Date		: 2007-1-3
	
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-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-xmpp-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-xmpp-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: <2007-1-3143252.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-xmpp-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-enum-xmpp-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-1-3143252.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 Jan 03 17:23:23 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2EVS-0002yf-4a; Wed, 03 Jan 2007 17:22:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2EVQ-0002yP-DJ; Wed, 03 Jan 2007 17:22:44 -0500
Received: from zeke.ecotroph.net ([69.31.8.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H2EVO-0007Ko-55; Wed, 03 Jan 2007 17:22:44 -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; Wed, 03 Jan 2007 17:21:56 -0500
	id 0158845C.459C2C84.00001B32
In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065501C086A4@isr-jlm-mail.Kayote.com>
References: <1DDB0D3CC4E7F14FAE946361C0A6065501C086A4@isr-jlm-mail.Kayote.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8C026ED6-14B5-4064-AD46-11E98A247775@hxr.us>
Content-Transfer-Encoding: 7bit
From: Andrew Newton <andy@hxr.us>
Date: Wed, 3 Jan 2007 17:22:19 -0500
To: speermint@ietf.org, enum@ietf.org, ietf-provreg@cafax.se
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: Cullen Jennings <fluffy@cisco.com>,
	David Schwartz <David.Schwartz@Kayote.com>,
	Jon Peterson <jon.peterson@neustar.biz>,
	Richard Shockey <richard@shockey.us>
Subject: [Enum] Re: [Speermint] FW: Preliminary BOF proposals due soon
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Alright, now that the holidays are over it is time to get moving on  
SIP peering provisioning. We have requested and received an ietf.org  
mailing list for PEPPERMINT.  The list info can be found here:
https://www1.ietf.org/mailman/listinfo/peppermint

A BoF proposal is forthcoming in a day or two.

-andy

On Dec 19, 2006, at 11:26 AM, David Schwartz wrote:

> I am 85% finished on an a draft describing requirements we have
> accumulated at XConnect. Hope to have this out by the end of the year.
>
> David
>
> -----Original Message-----
> From: Richard Shockey [mailto:richard@shockey.us]
> Sent: Tuesday, December 19, 2006 5:38 PM
> To: 'Andrew Newton'; 'Livingood, Jason'; 'David Meyer';
> speermint@ietf.org
> Cc: 'RAI ADs'
> Subject: [Speermint] FW: Preliminary BOF proposals due soon
>
>
>
> Andrew Newton and I will be proposing a BOF on SPEERMINT Provisioning
> issues
> for IETF 68 in Prague.
>
> If anyone has topic or is considering producing drafts related to
> provisioning issues please let Andy or I know.
>
>> -----Original Message-----
>> From: IETF Chair [mailto:chair@ietf.org]
>> Sent: Tuesday, December 19, 2006 3:39 AM
>> To: IETF Announcement list
>> Subject: Preliminary BOF proposals due soon
>>
>> As for the previous IETF, we're asking for preliminary BOF proposals
> to be
>> sent to the appropriate Area Director a little earlier, by January  
>> 15.
>> Even sooner would be better!
>>
>> Full list of dates:
>> http://www.ietf.org/meetings/68-cutoff_dates.html
>>
>> BOF wiki:
>> http://www1.tools.ietf.org/bof/trac/wiki
>>
>> Hints:
>> http://tools.ietf.org/html/draft-narten-successful-bof
>>
>>    Brian Carpenter
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint


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



From enum-bounces@ietf.org Thu Jan 04 11:43:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2Vg1-0007Zx-QZ; Thu, 04 Jan 2007 11:42:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Vfz-0007Yr-R0
	for enum@ietf.org; Thu, 04 Jan 2007 11:42:47 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Vfy-0008EZ-Em
	for enum@ietf.org; Thu, 04 Jan 2007 11:42:47 -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 l04GgeDU006284Thu, 4 Jan 2007 16:42:42 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H2Vfs-000D63-00; Thu, 04 Jan 2007 16:42:40 +0000
Date: Thu, 4 Jan 2007 16:42:40 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070104164240.GN98464@finch-staff-1.thus.net>
References: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com>
	<20070102111424.GI5435@finch-staff-1.thus.net>
	<785A120B-9D8F-4928-8128-CBDB7EB1DDD4@insensate.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <785A120B-9D8F-4928-8128-CBDB7EB1DDD4@insensate.co.uk>
User-Agent: Mutt/1.5.3i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: enum@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

lconroy said:
>  I am unaware of a formal written opinion from the Information
> Commissioner on this matter.

I'm not sure if it's formal and written, but I know that the OIC has
expressed this opinion. I'll see if I can track it down.

> Until there is such a formal opinion and clarification on permitted
> data, IMHO this draft is fine. Otherwise we are chasing phantoms.

On the contrary, the same issue is already causing problems within NICC
(the UK telecoms standards body).

> If any NRA or equivalent data protection authority refused to permit
> a necessary part of SIP URLs to be published, then doing so would
> make VoIP in general rather hard. An originating system has to be able
> to "find" the destination SIP provider or it isn't going to work. I hear
> rumours, but I can't believe anyone intends to block VoIP in this way.

There's a difference between User (opt-in) and Infrastructure (everyone is
included) Enum in this context. I'm referring to Infrastructure Enum only.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Thu Jan 04 11:43:45 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2Vgh-0007yQ-JB; Thu, 04 Jan 2007 11:43:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Vgg-0007xz-Ff
	for enum@ietf.org; Thu, 04 Jan 2007 11:43:30 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Vge-0000JH-Uv
	for enum@ietf.org; Thu, 04 Jan 2007 11:43:30 -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 l04GhQvo006672Thu, 4 Jan 2007 16:43:26 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H2Vgb-000D6l-00; Thu, 04 Jan 2007 16:43:25 +0000
Date: Thu, 4 Jan 2007 16:43:25 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070104164325.GO98464@finch-staff-1.thus.net>
References: <072C5B76F7CEAB488172C6F64B30B5E302621D8D@xmb-rtp-20b.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302621D8D@xmb-rtp-20b.amer.cisco.com>
User-Agent: Mutt/1.5.3i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: enum@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Michael Hammer (mhammer) said:
> I see no user at all here:
> 
>  sip:<e164_phone_number>@provider.example.net
> 
> Thus, PII is not an issue.

Sorry, that's just not a valid interpretation of the Data Protection Act.
The telephone number is sufficient key to make it "personal".

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Thu Jan 04 12:30:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2WPv-0005je-EJ; Thu, 04 Jan 2007 12:30:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WPu-0005jY-Cm
	for enum@ietf.org; Thu, 04 Jan 2007 12:30:14 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WPt-0006WT-2E
	for enum@ietf.org; Thu, 04 Jan 2007 12:30:14 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-4.cisco.com with ESMTP; 04 Jan 2007 09:30:12 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l04HUCf1011293; 
	Thu, 4 Jan 2007 09:30:12 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l04HUBlb015553;
	Thu, 4 Jan 2007 09:30:11 -0800 (PST)
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); 
	Thu, 4 Jan 2007 12:29: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] NITS review of draft-ietf-enum-infrastructure-03
Date: Thu, 4 Jan 2007 12:29:55 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3026B67CE@xmb-rtp-20b.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccwH3k2OGOamZmLSb2CCxrnYhgGIAABHnng
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Clive D.W. Feather" <clive@demon.net>
X-OriginalArrivalTime: 04 Jan 2007 17:29:56.0040 (UTC)
	FILETIME=[F37E1C80:01C73025]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1746; t=1167931812;
	x=1168795812; c=relaxed/simple; s=sjdkim5002;
	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<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Enum]=20NITS=20review=20of=20draft-ietf-enum-infrast
	ructure-03 |Sender:=20;
	bh=lxLKQ7VqTOdJuRV/9e639z315IxF/Om0EKX3RAmNUMI=;
	b=INpn3gW2/NGTjKL0XSKtJOUJZZy8SUqRHM4MaVaw8jCv00R4SiSdUOIq0XsSaDE5R8+St5Xu
	1W9wZRFcpnB/bCK/2XHZ2t7hd9lYz/5KLPlNXoeXlvHnoyvSVEViD4Yl;
Authentication-Results: sj-dkim-5; header.From=mhammer@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: enum@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Clive,

Are you saying the "Data Protection Act" or the "interpretation" of it
is out of touch with reality?

Without a "person" being identified or linked to the number, how can it
be "personal"?=20

If I publish +44* meaning all combinations of E.164 phone numbers
assigned to UK, have I just now violated that Act?

Using this Act as an excuse to preserve anti-competitive practices
(keeping call routing information limited to a small closed club) is not
in the public interest and not likely to hold up under scrutiny IMHO.

I would argue that the assignment of a public resource (E.164 numbers)
to a private entity by a government agency should be transparent, as
governments need to be held accountable to the public on how they govern
public resources.

Mike


> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net]=20
> Sent: Thursday, January 04, 2007 11:43 AM
> To: Michael Hammer (mhammer)
> Cc: Livingood, Jason; enum@ietf.org; rich.shockey@neustar.biz
> Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
>=20
> Michael Hammer (mhammer) said:
> > I see no user at all here:
> >=20
> >  sip:<e164_phone_number>@provider.example.net
> >=20
> > Thus, PII is not an issue.
>=20
> Sorry, that's just not a valid interpretation of the Data=20
> Protection Act.
> The telephone number is sufficient key to make it "personal".
>=20
> --=20
> Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:   =20
> +44 20 8495 6138
> Internet Expert     | Home:  <clive@davros.org>  | Fax:   =20
> +44 870 051 9937
> Demon Internet      | WWW: http://www.davros.org | Mobile:=20
> +44 7973 377646
> THUS plc            |                            |
>=20

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



From enum-bounces@ietf.org Thu Jan 04 14:56:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2YgX-0005dq-Au; Thu, 04 Jan 2007 14:55:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YgV-0005Vk-GA
	for enum@ietf.org; Thu, 04 Jan 2007 14:55:31 -0500
Received: from osprey.verisign.com ([216.168.239.75])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YgU-0000qR-A2
	for enum@ietf.org; Thu, 04 Jan 2007 14:55:31 -0500
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com
	[10.170.12.113])
	by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l04JtZFC020626;
	Thu, 4 Jan 2007 14:55:35 -0500
Received: from trutkowski-desk.verisign.com ([10.26.0.20]) by
	dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:55:26 -0500
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 04 Jan 2007 12:19:14 -0500
To: "Clive D.W. Feather" <clive@demon.net>,
	"Michael Hammer (mhammer)" <mhammer@cisco.com>
From: Tony Rutkowski <trutkowski@verisign.com>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
In-Reply-To: <20070104164325.GO98464@finch-staff-1.thus.net>
References: <072C5B76F7CEAB488172C6F64B30B5E302621D8D@xmb-rtp-20b.amer.cisco.com>
	<20070104164325.GO98464@finch-staff-1.thus.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <DUL1WNEXCN03jqueolj00004980@dul1wnexcn03.vcorp.ad.vrsn.com>
X-OriginalArrivalTime: 04 Jan 2007 19:55:26.0542 (UTC)
	FILETIME=[4746FEE0:01C7303A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: enum@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Clive,

Have you also considered the effects of the
EU Data Retention Directive?  It kicks into
force this year.  Art. 5, sec. 1.(a)(2)
clearly has significant ENUM implications.
The new U.S. CALEA IP telephony requirements
and their equivalents in other countries also
have ENUM implications.

--tony


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



From enum-bounces@ietf.org Thu Jan 04 17:19:43 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2avm-0002i9-OH; Thu, 04 Jan 2007 17:19:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2avl-0002i4-OG
	for enum@ietf.org; Thu, 04 Jan 2007 17:19:25 -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 1H2avk-0000wb-GD
	for enum@ietf.org; Thu, 04 Jan 2007 17:19:25 -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, 04 Jan 2007 17:18:53 -0500
	id 015884AC.459D7D4D.00001CDD
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3026B67CE@xmb-rtp-20b.amer.cisco.com>
References: <072C5B76F7CEAB488172C6F64B30B5E3026B67CE@xmb-rtp-20b.amer.cisco.com>
Mime-Version: 1.0
Message-Id: <02342AE2-8D51-4523-AB31-5BC04E27B669@hxr.us>
From: Andrew Newton <andy@hxr.us>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Thu, 4 Jan 2007 17:19:15 -0500
To: "Michael Hammer \"((mhammer))" <mhammer@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: enum@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	"Clive D.W. Feather" <clive@demon.net>, rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1437507489=="
Errors-To: enum-bounces@ietf.org

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--===============1437507489==
Content-Type: multipart/alternative;
	boundary="=_zeke.ecotroph.net-7393-1167949135-0001-2"

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zeke.ecotroph.net-7393-1167949135-0001-2
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit


On Jan 4, 2007, at 12:29 PM, Michael Hammer ((mhammer)) wrote:

> If I publish +44* meaning all combinations of E.164 phone numbers
> assigned to UK, have I just now violated that Act?
>
> Using this Act as an excuse to preserve anti-competitive practices
> (keeping call routing information limited to a small closed club)  
> is not
> in the public interest and not likely to hold up under scrutiny IMHO.

I tend to agree.  This is getting silly.  An E.164 might identify a  
person, but it just as likely is the phone number for the front desk,  
a pay telephone, or a fax machine.  Perhaps we should change the  
language to:

In addition, since there is an unknown probability that any part of  
the URI might in some theoretical way identify an actual person, care  
should be taken to consult the over-reaching and/or out-dated laws  
and regulations of the appropriate governing and oppressive regimes.

-andy
--=_zeke.ecotroph.net-7393-1167949135-0001-2
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier
	0.53.3

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; -kht=
ml-line-break: after-white-space; "><BR><DIV><DIV>On Jan 4, 2007, at 12:2=
9 PM, Michael Hammer ((mhammer)) wrote:</DIV><BR class=3D"Apple-interchan=
ge-newline"><BLOCKQUOTE type=3D"cite"><P style=3D"margin: 0.0px 0.0px 0.0=
px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helve=
tica">If I publish +44* meaning all combinations of E.164 phone numbers</=
FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helv=
etica" size=3D"3" style=3D"font: 12.0px Helvetica">assigned to UK, have I=
 just now violated that Act?</FONT></P> <P style=3D"margin: 0.0px 0.0px 0=
.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style=
=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Using this Act as an excuse to preserve =
anti-competitive practices</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0=
px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helve=
tica">(keeping call routing information limited to a small closed club) i=
s not</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D=
"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">in the public int=
erest and not likely to hold up under scrutiny IMHO.</FONT></P> </BLOCKQU=
OTE></DIV><BR><DIV>I tend to agree.=A0 This is getting silly.=A0 An E.164=
 might identify a person, but it just as likely is the phone number for t=
he front desk, a pay telephone, or a fax machine.=A0 Perhaps we should ch=
ange the language to:</DIV><DIV><BR class=3D"khtml-block-placeholder"></D=
IV><DIV>In addition, since there is an unknown probability that any part =
of the URI might in some=A0theoretical=A0way identify an actual person, c=
are should be taken to consult the over-reaching and/or out-dated laws an=
d regulations of the appropriate governing and oppressive regimes.</DIV><=
DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>-andy</DIV></BODY></=
HTML>
--=_zeke.ecotroph.net-7393-1167949135-0001-2--


--===============1437507489==
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

--===============1437507489==--




From enum-bounces@ietf.org Thu Jan 04 17:46:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2bLh-0004M8-C0; Thu, 04 Jan 2007 17:46:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bLf-0004L9-Eb
	for enum@ietf.org; Thu, 04 Jan 2007 17:46:11 -0500
Received: from sirius.wcom.co.uk ([193.131.254.154]
	helo=sirius.emea.verizonbusiness.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2bLc-0005y6-UC
	for enum@ietf.org; Thu, 04 Jan 2007 17:46:11 -0500
Received: from sirius.wcom.co.uk ([166.59.190.29] helo=sirius.emea.mci.com)
	by sirius.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H2bLX-00069G-5f; Thu, 04 Jan 2007 22:46:04 +0000
Received: from borg.emea.verizonbusiness.com (leste.wcom.co.uk
	[166.59.190.250]) by sirius.emea.mci.com (4.7.0.120) with ESMTP id ;
	Thu, 4 Jan 2007 22:45:58 GMT
Received: from ms-lon-exgw01.uk.mcilink.com ([170.127.78.40]
	helo=ms-lon-exgw01.emea.dsmain.com)
	by borg.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H2bLS-00018c-3J; Thu, 04 Jan 2007 22:45:58 +0000
Received: by ms-lon-exgw01.uk.mcilink.com with Internet Mail Service
	(5.5.2657.72) id <ZYQC5L8H>; Thu, 4 Jan 2007 22:45:44 -0000
Message-ID: <CA3896DB5903C14EAAC9D8E91D1167CBCC7590@ms-lon-exmb06.uk.mcilink.com>
From: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
To: "'andy@hxr.us'" <andy@hxr.us>, "'mhammer@cisco.com'" <mhammer@cisco.com>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Thu, 4 Jan 2007 22:45:43 -0000 
X-Mailer: Internet Mail Service (5.5.2657.72)
MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40)
X-VZ-EMEA-Spam-Score: -499.2
	(---------------------------------------------------)
X-VZ-EMEA-Signature: d9f6d5b2ecd633f3af636049dc36f05b
X-Spam-Score: 0.6 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: "'enum@ietf.org'" <enum@ietf.org>, "'clive@demon.net'" <clive@demon.net>,
	"'Jason_Livingood@cable.comcast.com'" <Jason_Livingood@cable.comcast.com>,
	"'rich.shockey@neustar.biz'" <rich.shockey@neustar.biz>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0197781353=="
Errors-To: enum-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0197781353==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73052.10CCA4B3"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C73052.10CCA4B3
Content-Type: text/plain;
	charset="utf-8"

Andrew,

This is not the case at all and I believe we've been around these issues
enough already overtime.

Clive, what exactly are you getting at? There are Data Protection provisions
in place in most member states to sufficiently protect User/s privacy.


Ronan


-----Original Message-----
From: Andrew Newton <andy@hxr.us>
To: Michael Hammer "((mhammer)) <mhammer@cisco.com>
CC: enum@ietf.org <enum@ietf.org>; Livingood, Jason
<Jason_Livingood@cable.comcast.com>; Clive D.W. Feather <clive@demon.net>;
rich.shockey@neustar.biz <rich.shockey@neustar.biz>
Sent: Thu Jan 04 22:19:15 2007
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03


On Jan 4, 2007, at 12:29 PM, Michael Hammer ((mhammer)) wrote:


If I publish +44* meaning all combinations of E.164 phone numbers

assigned to UK, have I just now violated that Act?




Using this Act as an excuse to preserve anti-competitive practices

(keeping call routing information limited to a small closed club) is not

in the public interest and not likely to hold up under scrutiny IMHO.


I tend to agree.  This is getting silly.  An E.164 might identify a person,
but it just as likely is the phone number for the front desk, a pay
telephone, or a fax machine.  Perhaps we should change the language to:

In addition, since there is an unknown probability that any part of the URI
might in some theoretical way identify an actual person, care should be
taken to consult the over-reaching and/or out-dated laws and regulations of
the appropriate governing and oppressive regimes.

-andy

------_=_NextPart_001_01C73052.10CCA4B3
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dutf-8">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>Re: [Enum] NITS review of =
draft-ietf-enum-infrastructure-03</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Andrew,</FONT>
</P>

<P><FONT SIZE=3D2>This is not the case at all and I believe we've been =
around these issues enough already overtime.</FONT>
</P>

<P><FONT SIZE=3D2>Clive, what exactly are you getting at? There are =
Data Protection provisions in place in most member states to =
sufficiently protect User/s privacy.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Ronan</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Andrew Newton &lt;andy@hxr.us&gt;</FONT>
<BR><FONT SIZE=3D2>To: Michael Hammer &quot;((mhammer)) =
&lt;mhammer@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>CC: enum@ietf.org &lt;enum@ietf.org&gt;; Livingood, =
Jason &lt;Jason_Livingood@cable.comcast.com&gt;; Clive D.W. Feather =
&lt;clive@demon.net&gt;; rich.shockey@neustar.biz =
&lt;rich.shockey@neustar.biz&gt;</FONT></P>

<P><FONT SIZE=3D2>Sent: Thu Jan 04 22:19:15 2007</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] NITS review of =
draft-ietf-enum-infrastructure-03</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Jan 4, 2007, at 12:29 PM, Michael Hammer =
((mhammer)) wrote:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>If I publish +44* meaning all combinations of E.164 =
phone numbers</FONT>
</P>

<P><FONT SIZE=3D2>assigned to UK, have I just now violated that =
Act?</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Using this Act as an excuse to preserve =
anti-competitive practices</FONT>
</P>

<P><FONT SIZE=3D2>(keeping call routing information limited to a small =
closed club) is not</FONT>
</P>

<P><FONT SIZE=3D2>in the public interest and not likely to hold up =
under scrutiny IMHO.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I tend to agree.&nbsp; This is getting silly.&nbsp; =
An E.164 might identify a person, but it just as likely is the phone =
number for the front desk, a pay telephone, or a fax machine.&nbsp; =
Perhaps we should change the language to:</FONT></P>

<P><FONT SIZE=3D2>In addition, since there is an unknown probability =
that any part of the URI might in some theoretical way identify an =
actual person, care should be taken to consult the over-reaching and/or =
out-dated laws and regulations of the appropriate governing and =
oppressive regimes.</FONT></P>

<P><FONT SIZE=3D2>-andy</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C73052.10CCA4B3--


--===============0197781353==
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

--===============0197781353==--




From enum-bounces@ietf.org Fri Jan 05 06:38:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2nNy-0005J6-1D; Fri, 05 Jan 2007 06:37:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nNx-0005J1-CV
	for enum@ietf.org; Fri, 05 Jan 2007 06:37: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 1H2nNw-0002R2-3t
	for enum@ietf.org; Fri, 05 Jan 2007 06:37:21 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id 4D1DF4C3BF; Fri,  5 Jan 2007 12:37:19 +0100 (CET)
Date: Fri, 5 Jan 2007 12:37:19 +0100
From: Otmar Lendl <lendl@nic.at>
To: enum@ietf.org
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070105113718.GB24048@enum.at>
References: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com>
	<20070102111424.GI5435@finch-staff-1.thus.net>
	<785A120B-9D8F-4928-8128-CBDB7EB1DDD4@insensate.co.uk>
	<20070104164240.GN98464@finch-staff-1.thus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070104164240.GN98464@finch-staff-1.thus.net>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/04 17:01, "Clive D.W. Feather" <clive@demon.net> wrote:
> lconroy said:
> 
> > If any NRA or equivalent data protection authority refused to permit
> > a necessary part of SIP URLs to be published, then doing so would
> > make VoIP in general rather hard. An originating system has to be able
> > to "find" the destination SIP provider or it isn't going to work. I hear
> > rumours, but I can't believe anyone intends to block VoIP in this way.
> 
> There's a difference between User (opt-in) and Infrastructure (everyone is
> included) Enum in this context. I'm referring to Infrastructure Enum only.

I'm not sure whether the suggested legal problems stem from EU law or
national .uk one. In any case, you might be interested to hear that
the Austrian NRA (RTR GmbH) happily signed a contract with us
designating us to run an infrastructure ENUM trial in the *public* DNS.

Whether that's just because we Austrians tend to be creative in the
interpretation of EU regulations or whether there is really no problem
there, I can't tell.

But it's a fact that we run an officially sanctioned I-ENUM trial
here in an EU member state.

/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 Jan 05 07:07:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2nqs-0007EM-5K; Fri, 05 Jan 2007 07:07:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nqq-0007E5-GN
	for enum@ietf.org; Fri, 05 Jan 2007 07:07:12 -0500
Received: from mail123.messagelabs.com ([85.158.136.3])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2nqj-0002TM-QS
	for enum@ietf.org; Fri, 05 Jan 2007 07:07:12 -0500
X-VirusChecked: Checked
X-Env-Sender: Paul.Rosbotham@cwmsg.cwplc.com
X-Msg-Ref: server-12.tower-123.messagelabs.com!1167998578!18457311!1
X-StarScan-Version: 5.5.10.7; banners=cwmsg.cwplc.com,-,-
X-Originating-IP: [194.6.6.11]
Received: (qmail 2258 invoked from network); 5 Jan 2007 12:02:58 -0000
Received: from relay.cwplc.com (HELO relay.cwplc.com) (194.6.6.11)
	by server-12.tower-123.messagelabs.com with SMTP;
	5 Jan 2007 12:02:58 -0000
Received: from GBCWSWIEC002.ad.plc.cwintra.com ([148.185.93.208])
	by relay.cwplc.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	l05C3EQ09825 for <enum@ietf.org>; Fri, 5 Jan 2007 12:03:14 GMT
Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by
	GBCWSWIEC002.ad.plc.cwintra.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 12:01:50 +0000
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] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 12:01:34 -0000
Message-ID: <9322B78036E1534A99B0BC51DEB0F9D6022CDCF7@GBCWSWIEM002.ad.plc.cwintra.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccwvmD1V5ejFpykQyyvvIia/GAmBQAAOKxg
From: "Rosbotham, Paul" <Paul.Rosbotham@cwmsg.cwplc.com>
To: <enum@ietf.org>
X-OriginalArrivalTime: 05 Jan 2007 12:01:50.0512 (UTC)
	FILETIME=[486AAB00:01C730C1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

OK,=20I've=20been=20trying=20to=20keep=20out=20of=20this=20but=20I=20guess=
=20I=20should=20step=20in=20and=20clarify,=20given=20it=20was=20me=20who=20=
had=20the=20meeting=20with=20the=20UK=20Information=20Commissioner's=20Off=
ice.

They=20had=20I-ENUM=20explained=20to=20them=20and=20expressed=20reservatio=
ns.=20=20Reservations,=20not=20outright=20written=20legal=20objections...t=
hey=20were=20asked=20to=20give=20an=20informal=20opinion=20and=20personall=
y=20I=20welcome=20that=20they=20did=20so.=20=20Laurence=20is=20correct,=20=
however,=20that=20there=20is=20no=20formal=20position.=20=20Similarly,=20C=
live=20is=20also=20correct=20to=20mention=20that=20there=20may=20be=20issu=
es.=20=20

I=20am=20not=20a=20lawyer,=20so=20apologies=20if=20any=20of=20this=20is=20=
garbled.=20=20The=20basic=20view=20was=20that=20although=20a=20telephone=20=
number=20in=20itself=20is=20not=20personal=20data,=20via=20the=20concept=20=
of=20"linked=20datasets",=20it=20can=20be=20combined=20with=20other=20data=
bases=20to=20produce=20things=20which=20represent=20privacy=20concerns=20u=
nder=20EU=20legislation.=20=20In=20particular,=20when=20linked=20with=20a=20=
telephone=20directory,=20it=20would=20allow=20the=20tying=20together=20of=20=
an=20individual=20and=20their=20telephone=20provider,=20which=20could=20be=
=20considered=20as=20personal=20data.=20=20In=20putting=20their=20number=20=
into=20a=20telephony=20directory,=20the=20end=20user=20consented=20to=20th=
at=20information=20being=20published,=20not=20for=20it=20to=20be=20possibl=
e=20to=20determine=20their=20choice=20of=20supplier.=20=20It's=20this=20"l=
inked=20datasets"=20consideration=20which=20leads=20to=20the=20rules=20aro=
und=20CLI=20transmission...the=20CLI=20isn't=20personal=20data=20but=20whe=
n=20linked=20to=20other=20data=20it=20becomes=20so=20:=20therefore=20if=20=
the=20customer=20wishes=20to=20withhold=20their=20CLI=20they=20can=20do=20=
so,=20and=20this=20is=20independent=20of=20whether=20they=20choose=20to=20=
be=20listed=20in=20a=20directory.=20=20The=20fact=20that=20some=20numbers=20=
relate=20to=20corporate=20entities=20is=20irrelevant...many=20belong=20to=20=
an=20individual.

In=20terms=20of=20the=20position=20elsewhere=20in=20the=20EU,=20I=20wouldn=
't=20comment.=20=20There=20isn't=20a=20formal=20position=20in=20the=20UK,=20=
just=20an=20informal=20reservation.=20=20My=20experience=20on=20other=20is=
sues=20relating=20to=20information=20privacy=20is=20that=20although=20the=20=
EU=20Directive=20may=20be=20pan-European,=20interpretation=20of=20it=20is=20=
not.=20=20The=20UK=20tends=20to=20take=20a=20middle=20line,=20with=20some=20=
countries=20being=20more=20liberal,=20others=20more=20conservative.=20=20I=
=20would=20query=20whether=20in=20the=20Austrian=20case=20approval=20was=20=
given=20by=20the=20telecoms=20regulator,=20or=20the=20information=20privac=
y=20regulator...these=20are=20typically=20not=20the=20same.=20=20However,=20=
if=20the=20Austrian=20information=20commissioner=20has=20given=20consent,=20=
well=20they=20know=20far=20more=20about=20Austrian=20legislation=20than=20=
I=20do=20so=20I=20wouldn't=20query=20that.

If=20the=20current=20informal=20position=20did=20harden=20into=20a=20forma=
l=20one,=20then=20the=20conclusion=20IMHO=20is=20that=20it=20could=20be=20=
difficult=20to=20put=20i-ENUM=20in=20public=20DNS.=20=20This=20doesn't=20m=
ean=20that=20CPs=20in=20other=20jurisdictions=20couldn't=20adopt=20that=20=
approach,=20but=20I=20have=20to=20act=20within=20my=20national=20law.

As=20to=20the=20opinions=20of=20others=20who=20assert=20that=20the=20UK=20=
Information=20Commissioner=20is=20wrong,=20well=20you're=20welcome=20to=20=
these=20opinions,=20but=20you'll=20forgive=20me=20if=20I=20listen=20to=20t=
he=20UK=20regulator=20when=20determining=20whether=20I'm=20compliant=20wit=
h=20legislation,=20rather=20than=20someone's=20opinion=20on=20a=20mailing=20=
list...

Regards

Paul=20Rosbotham=20
Manager,=20Interconnect=20Strategy=20&=20Technology=20Regulation
Cable=20&=20Wireless=20
www.cw.com



-----Original=20Message-----
From:=20Otmar=20Lendl=20[mailto:lendl@nic.at]
Sent:=2005=20January=202007=2011:37
To:=20enum@ietf.org
Subject:=20Re:=20[Enum]=20NITS=20review=20of=20draft-ietf-enum-infrastruct=
ure-03


On=202007/01/04=2017:01,=20"Clive=20D.W.=20Feather"=20<clive@demon.net>=20=
wrote:
>=20lconroy=20said:
>=20
>=20>=20If=20any=20NRA=20or=20equivalent=20data=20protection=20authority=20=
refused=20to=20permit
>=20>=20a=20necessary=20part=20of=20SIP=20URLs=20to=20be=20published,=20th=
en=20doing=20so=20would
>=20>=20make=20VoIP=20in=20general=20rather=20hard.=20An=20originating=20s=
ystem=20has=20to=20be=20able
>=20>=20to=20"find"=20the=20destination=20SIP=20provider=20or=20it=20isn't=
=20going=20to=20work.=20I=20hear
>=20>=20rumours,=20but=20I=20can't=20believe=20anyone=20intends=20to=20blo=
ck=20VoIP=20in=20this=20way.
>=20
>=20There's=20a=20difference=20between=20User=20(opt-in)=20and=20Infrastru=
cture=20(everyone=20is
>=20included)=20Enum=20in=20this=20context.=20I'm=20referring=20to=20Infra=
structure=20Enum=20only.

I'm=20not=20sure=20whether=20the=20suggested=20legal=20problems=20stem=20f=
rom=20EU=20law=20or
national=20.uk=20one.=20In=20any=20case,=20you=20might=20be=20interested=20=
to=20hear=20that
the=20Austrian=20NRA=20(RTR=20GmbH)=20happily=20signed=20a=20contract=20wi=
th=20us
designating=20us=20to=20run=20an=20infrastructure=20ENUM=20trial=20in=20th=
e=20*public*=20DNS.

Whether=20that's=20just=20because=20we=20Austrians=20tend=20to=20be=20crea=
tive=20in=20the
interpretation=20of=20EU=20regulations=20or=20whether=20there=20is=20reall=
y=20no=20problem
there,=20I=20can't=20tell.

But=20it's=20a=20fact=20that=20we=20run=20an=20officially=20sanctioned=20I=
-ENUM=20trial
here=20in=20an=20EU=20member=20state.

/ol
--=20
<=20Otmar=20Lendl=20(lendl@nic.at)=20|=20nic.at=20Systems=20Engineer=20>

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

This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20=
&=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs=
.=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec=
urity=20service,=20=20visit=20http://www.cw.com/uk/emailprotection/=20
=20
The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a=
nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten=
ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20=
not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop=
y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont=
ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20=
in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20=
are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me=
ssage=20and=20any=20attachments=20without=20retaining=20any=20copies.

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



From enum-bounces@ietf.org Fri Jan 05 07:29:36 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2oCF-0000YF-OD; Fri, 05 Jan 2007 07:29:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oCE-0000YA-EV
	for enum@ietf.org; Fri, 05 Jan 2007 07:29: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 1H2oCD-0007vO-5Q
	for enum@ietf.org; Fri, 05 Jan 2007 07:29:18 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id 92EE44C3BF; Fri,  5 Jan 2007 13:29:16 +0100 (CET)
Date: Fri, 5 Jan 2007 13:29:16 +0100
From: Otmar Lendl <lendl@nic.at>
To: enum@ietf.org
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070105122912.GA24574@nic.at>
References: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com>
	<20070102111424.GI5435@finch-staff-1.thus.net>
	<785A120B-9D8F-4928-8128-CBDB7EB1DDD4@insensate.co.uk>
	<20070104164240.GN98464@finch-staff-1.thus.net>
	<20070105113718.GB24048@enum.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070105113718.GB24048@enum.at>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/05 12:01, Otmar Lendl <lendl@nic.at> wrote:
> 
> But it's a fact that we run an officially sanctioned I-ENUM trial
> here in an EU member state.

Two more points on this:

* If the mapping "Telephone number" -> "provider" is one you're
  worried about being public, then Austria already has that 
  problem with all mobile numbers:

  The block allocations to carriers are simple, published, and 
  well known to the public. (e.g. +43 664 -> Mobilkom, +43 676
  -> T-Mobile, ...)

  If someone ported a number from one carrier to another
  then an announcement indicating the new carrier is played 
  every time such a number is called.
  
  That announcement was necessary as tariffs depend on the
  destination network, thus with MNP, consumers could
  no longer derive the tariff by simply looking at the
  number.

  The upshot is: it's trivial to find out which mobile
  carrier services a certain number.

* Maybe we need to stress one point from 
  draft-ietf-enum-infrastructure-enum-reqs-03 which
  is not mentioned in draft-ietf-enum-infrastructure-04:

>From "2.2.  Background"

| 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.

  In other words: the information found in the public I-ENUM
  tree (e.g. +43123456789@sip.example.net) does not enable
  anybody and his dog (and Nigerian spammers) to call that number
  directly from his robo-call Asterisk box using SIP.

  If you're no carrier with an established peering relationship
  with "example.net", then you gain next to nothing by knowing
  the mapping +43123456789 -> +43123456789@sip.example.net.

/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 Jan 05 08:47:21 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2pP7-0001W1-T8; Fri, 05 Jan 2007 08:46:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pP6-0001Vq-TZ
	for enum@ietf.org; Fri, 05 Jan 2007 08:46:40 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pP3-0000Bh-Tl
	for enum@ietf.org; Fri, 05 Jan 2007 08:46:40 -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
	l05DkMYw022216; Fri, 5 Jan 2007 05:46:28 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Rosbotham, Paul'" <Paul.Rosbotham@cwmsg.cwplc.com>, <enum@ietf.org>
Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 08:46:11 -0500
Message-ID: <024001c730cf$dd298dc0$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.3028
Thread-Index: AccwvmD1V5ejFpykQyyvvIia/GAmBQAAOKxgAAPlW2A=
In-Reply-To: <9322B78036E1534A99B0BC51DEB0F9D6022CDCF7@GBCWSWIEM002.ad.plc.cwintra.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: 8f374d0786b25a451ef87d82c076f593
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


The simple truth is you don't need to put I-ENUM in the public DNS and I
still can't understand why anyone would.

Carrier Interconnection is a function of trusted Registry Infrastructures
and the Policies associated with those Registries not the access method to
the data.

This IMHO this news out of the UK actually good news, hopefully it will
bring some folks to their senses especially about that bizarre CREW idea
floating around over there.



> -----Original Message-----
> From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwmsg.cwplc.com]
> Sent: Friday, January 05, 2007 7:02 AM
> To: enum@ietf.org
> Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
> 
> OK, I've been trying to keep out of this but I guess I should step in and
> clarify, given it was me who had the meeting with the UK Information
> Commissioner's Office.
> 
> They had I-ENUM explained to them and expressed reservations.
> Reservations, not outright written legal objections...they were asked to
> give an informal opinion and personally I welcome that they did so.
> Laurence is correct, however, that there is no formal position.
Similarly,
> Clive is also correct to mention that there may be issues.
> 
> I am not a lawyer, so apologies if any of this is garbled.  The basic view
> was that although a telephone number in itself is not personal data, via
> the concept of "linked datasets", it can be combined with other databases
> to produce things which represent privacy concerns under EU legislation.
> In particular, when linked with a telephone directory, it would allow the
> tying together of an individual and their telephone provider, which could
> be considered as personal data.  In putting their number into a telephony
> directory, the end user consented to that information being published, not
> for it to be possible to determine their choice of supplier.  It's this
> "linked datasets" consideration which leads to the rules around CLI
> transmission...the CLI isn't personal data but when linked to other data
> it becomes so : therefore if the customer wishes to withhold their CLI
> they can do so, and this is independent of whether they choose to be
> listed in a directory.  The fact that some numbers relate to corporate
> entities is irrelevant...many belong to an individual.
> 
> In terms of the position elsewhere in the EU, I wouldn't comment.  There
> isn't a formal position in the UK, just an informal reservation.  My
> experience on other issues relating to information privacy is that
> although the EU Directive may be pan-European, interpretation of it is
not.
> The UK tends to take a middle line, with some countries being more
liberal,
> others more conservative.  I would query whether in the Austrian case
> approval was given by the telecoms regulator, or the information privacy
> regulator...these are typically not the same.  However, if the Austrian
> information commissioner has given consent, well they know far more about
> Austrian legislation than I do so I wouldn't query that.
> 
> If the current informal position did harden into a formal one, then the
> conclusion IMHO is that it could be difficult to put i-ENUM in public DNS.
> This doesn't mean that CPs in other jurisdictions couldn't adopt that
> approach, but I have to act within my national law.
> 
> As to the opinions of others who assert that the UK Information
> Commissioner is wrong, well you're welcome to these opinions, but you'll
> forgive me if I listen to the UK regulator when determining whether I'm
> compliant with legislation, rather than someone's opinion on a mailing
> list...
> 
> Regards
> 
> Paul Rosbotham
> Manager, Interconnect Strategy & Technology Regulation
> Cable & Wireless
> www.cw.com
> 
> 
> 
> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]
> Sent: 05 January 2007 11:37
> To: enum@ietf.org
> Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
> 
> 
> On 2007/01/04 17:01, "Clive D.W. Feather" <clive@demon.net> wrote:
> > lconroy said:
> >
> > > If any NRA or equivalent data protection authority refused to permit
> > > a necessary part of SIP URLs to be published, then doing so would
> > > make VoIP in general rather hard. An originating system has to be able
> > > to "find" the destination SIP provider or it isn't going to work. I
> hear
> > > rumours, but I can't believe anyone intends to block VoIP in this way.
> >
> > There's a difference between User (opt-in) and Infrastructure (everyone
> is
> > included) Enum in this context. I'm referring to Infrastructure Enum
> only.
> 
> I'm not sure whether the suggested legal problems stem from EU law or
> national .uk one. In any case, you might be interested to hear that
> the Austrian NRA (RTR GmbH) happily signed a contract with us
> designating us to run an infrastructure ENUM trial in the *public* DNS.
> 
> Whether that's just because we Austrians tend to be creative in the
> interpretation of EU regulations or whether there is really no problem
> there, I can't tell.
> 
> But it's a fact that we run an officially sanctioned I-ENUM trial
> here in an EU member state.
> 
> /ol
> --
> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service,  visit
> http://www.cw.com/uk/emailprotection/
> 
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this
email.
> If you have received this e-mail in error, please notify the sender (whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining any copies.
> 
> _______________________________________________
> 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 Jan 05 10:03:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2qaf-0001rh-9A; Fri, 05 Jan 2007 10:02:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qae-0001rM-1Z
	for enum@ietf.org; Fri, 05 Jan 2007 10:02:40 -0500
Received: from gw.sidn.nl ([193.176.144.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2qaZ-0002Ok-Lp
	for enum@ietf.org; Fri, 05 Jan 2007 10:02:40 -0500
Received: from gw.sidn.nl (localhost [127.0.0.1])
	by localhost.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP id
	711593AB72 for <enum@ietf.org>; Fri,  5 Jan 2007 16:02:26 +0100 (CET)
Received: by gw.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP
	for <enum@ietf.org>; Fri,  5 Jan 2007 16:02:26 +0100 (CET)
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] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 16:02:26 +0100
Message-ID: <B33086268D53A0429A3AA2774C83892CDC59F7@KAEVS1.SIDN.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccwvmD1V5ejFpykQyyvvIia/GAmBQAAOKxgAAPlW2AAAQiQcA==
From: "Antoin Verschuren" <Antoin.Verschuren@sidn.nl>
To: <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Richard Shockey wrote:
> The simple truth is you don't need to put I-ENUM in the public DNS
> and I still can't understand why anyone would.

I can.
I can imagine a service where the authorisation to interconnect is
embeded in a device or software, not the network.
Supose I buy that service from Provider A who is a member of federation
A.
Now I want to use this device while I'm connected to the network of
provider B (and paying for it) who is not part of federation A or any
federation.
This means I need to query the tree and find out which interconnection
point of federation A is closest/fastest/most efficient for me to use. I
do not want to first go to provider A's network to find that out, when
my interconnection point might be my neighbour. I also don't want
povider B to selectively block this service for me.
If provider A and provider B both share this concept, than why should it
be forbidden ?
It's all a question of whether you want to have these end-to-end
devices, or that you want the network you're connected to to decide
which services you can use and how.
Some incumbants might want to keep I-ENUM closed, and then we need a 3th
ENUM tree for the providers that don't :-(
This closed version is called private ENUM.
The public DNS version is called Infrastructure ENUM, by definition.

> Carrier Interconnection is a function of trusted Registry
> Infrastructures and the Policies associated with those Registries not
> the access method to the data.

The interconnection might be in a trusted enviroment between certain
peers, but not the discovery of where the peer is to try to
interconnect, as this query might come from an unknown network.
This model will allow providers to open or close their network for
interconnection at their own insight, not forcing it.

> This IMHO this news out of the UK actually good news, hopefully it
> will bring some folks to their senses especially about that bizarre
> CREW idea floating around over there.

IMHO, the privacy considerations we should discuss in infrastructure
ENUM is that a provider is only allowed to publish NAPTR data that is
nessecary to service the service he sold the customer in relation to his
phonenumber.
Or to put it in simple words, I don't want my provider to publish my
email address, website or business card if I only bought a voice service
from him. So we should somehow define that in infrastructure ENUM, only
those records are allowed to be published that are nessecary to route
the service I bought. Perhaps only SIP ? Don't know, but I do know
that's what the discussion should be about, and how to phrase that.

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 Fri Jan 05 10:12:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2qkH-0006el-KV; Fri, 05 Jan 2007 10:12:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qkF-0006eR-Jo
	for enum@ietf.org; Fri, 05 Jan 2007 10:12:35 -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 1H2qkE-0004yG-6i
	for enum@ietf.org; Fri, 05 Jan 2007 10:12:35 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id 54A324C3BF; Fri,  5 Jan 2007 16:12:33 +0100 (CET)
Date: Fri, 5 Jan 2007 16:12:33 +0100
From: Otmar Lendl <lendl@nic.at>
To: enum@ietf.org
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070105151233.GA26539@nic.at>
References: <9322B78036E1534A99B0BC51DEB0F9D6022CDCF7@GBCWSWIEM002.ad.plc.cwintra.com>
	<024001c730cf$dd298dc0$22f0a544@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <024001c730cf$dd298dc0$22f0a544@cis.neustar.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/05 14:01, Richard Shockey <richard@shockey.us> wrote:
> 
> The simple truth is you don't need to put I-ENUM in the public DNS and I
> still can't understand why anyone would.

Oh, you don't need to have it in the public DNS.

That is, if you want to build a closed system for a single
administrative domain (e.g. a country). Within that country you can
decide who is a legitimate carrier, you can do access control on 
the DNS and as much legal hand-binding as you want.

Such a system was fine for the 20th century with neatly defined
and non-overlapping markets. 

It just breaks down if you take into account the state of networking
in the 21th century.

Do you want us to open the Austrian I-ENUM to every single small VoIP
carrier worldwide? If yes, what is then the real difference (other than
another charging point) to just using the public DNS?

You're replicating the PSTN trust model ("Trust all carriers").  Haven't
you noticed that this is breaking down left and right as the global SS7
network extends to locations which don't give a $#$%$% what the FCC or
the EU regulations dictate. For all I know, the PSTN guys are scrambling
to patch up their security model as they discovered that they can't just
trust all SS7 messages any more.

Once you distribute a "secret" widely, that information won't stay
secret. So why bother with this security by obscurity?

On the other hand, if we restrict access to the Austrian I-ENUM to local
carriers, then how is e.g. a German carrier supposed to select the
correct Austrian carrier which is probably present at a carrier hotel /
peering fabric in Frankfurt anyway? There is no technological need to
use special "transit carriers" for intra-european calls.

The sheer size of the NANP may skew your perception. Just try to imagine
that each US State were its own country with each own FCC and thus carrier
accredidation procedure. Now try to design a system for this scenario.

> Carrier Interconnection is a function of trusted Registry Infrastructures
> and the Policies associated with those Registries not the access method to
> the data.

I never understood why the Policies have to be associated with
Registries and not with Carriers themselves (other than the bottom
line of Registries).

> This IMHO this news out of the UK actually good news, hopefully it will
> bring some folks to their senses especially about that bizarre CREW idea
> floating around over there.

No comment on this, I defer to Jim.

/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 Jan 05 10:32:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2r2q-0006io-CO; Fri, 05 Jan 2007 10:31:48 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2r2o-0006if-TG; Fri, 05 Jan 2007 10:31:46 -0500
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1H2r2n-0000eq-LY; Fri, 05 Jan 2007 10:31:46 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 66FAC176DC;
	Fri,  5 Jan 2007 15:31:15 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H2r2J-0002pZ-0E; Fri, 05 Jan 2007 10:31:15 -0500
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1H2r2J-0002pZ-0E@stiedprstage1.ietf.org>
Date: Fri, 05 Jan 2007 10:31:15 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: enum@ietf.org
Subject: [Enum] Last Call: draft-ietf-enum-vcard (IANA Registration for
 vCard Enumservice) to Proposed Standard 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

The IESG has received a request from the Telephone Number Mapping WG 
(enum) to consider the following document:

- 'IANA Registration for vCard Enumservice '
   <draft-ietf-enum-vcard-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2007-01-19. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14058&rfc_flag=0


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



From enum-bounces@ietf.org Fri Jan 05 10:32:27 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2r3S-0007De-SO; Fri, 05 Jan 2007 10:32:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2r3S-0007Cg-Dn
	for enum@ietf.org; Fri, 05 Jan 2007 10:32:26 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2r3Q-00015O-AZ
	for enum@ietf.org; Fri, 05 Jan 2007 10:32: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] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 16:31:45 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C55@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccwvmD1V5ejFpykQyyvvIia/GAmBQAAOKxgAAPlW2AAA6wybw==
References: <024001c730cf$dd298dc0$22f0a544@cis.neustar.com>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <richard@shockey.us>, "Rosbotham, Paul" <Paul.Rosbotham@cwmsg.cwplc.com>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

This may work in the US with two carriers and one registry (Neustar)
International calls are done anyway via Skype.
=20
It does not work in Europe - and it would also not work in the US
with 100 carriers and 50 registries as Otmar says.
=20
BTW: Interconnction is done via sip URIs (Speermint) and not ENUM
=20
Richard
PS: Paul, your UK Information Commission arguments are
very similar to the discussion on how many angels may dance on a pin
=20
Otmars mentioning about mobile phones kills this argument anyway

________________________________

Von: Richard Shockey [mailto:richard@shockey.us]
Gesendet: Fr 05.01.2007 14:46
An: 'Rosbotham, Paul'; enum@ietf.org
Betreff: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03




The simple truth is you don't need to put I-ENUM in the public DNS and I
still can't understand why anyone would.

Carrier Interconnection is a function of trusted Registry =
Infrastructures
and the Policies associated with those Registries not the access method =
to
the data.

This IMHO this news out of the UK actually good news, hopefully it will
bring some folks to their senses especially about that bizarre CREW idea
floating around over there.



> -----Original Message-----
> From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwmsg.cwplc.com]
> Sent: Friday, January 05, 2007 7:02 AM
> To: enum@ietf.org
> Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
>
> OK, I've been trying to keep out of this but I guess I should step in =
and
> clarify, given it was me who had the meeting with the UK Information
> Commissioner's Office.
>
> They had I-ENUM explained to them and expressed reservations.
> Reservations, not outright written legal objections...they were asked =
to
> give an informal opinion and personally I welcome that they did so.
> Laurence is correct, however, that there is no formal position.
Similarly,
> Clive is also correct to mention that there may be issues.
>
> I am not a lawyer, so apologies if any of this is garbled.  The basic =
view
> was that although a telephone number in itself is not personal data, =
via
> the concept of "linked datasets", it can be combined with other =
databases
> to produce things which represent privacy concerns under EU =
legislation.
> In particular, when linked with a telephone directory, it would allow =
the
> tying together of an individual and their telephone provider, which =
could
> be considered as personal data.  In putting their number into a =
telephony
> directory, the end user consented to that information being published, =
not
> for it to be possible to determine their choice of supplier.  It's =
this
> "linked datasets" consideration which leads to the rules around CLI
> transmission...the CLI isn't personal data but when linked to other =
data
> it becomes so : therefore if the customer wishes to withhold their CLI
> they can do so, and this is independent of whether they choose to be
> listed in a directory.  The fact that some numbers relate to corporate
> entities is irrelevant...many belong to an individual.
>
> In terms of the position elsewhere in the EU, I wouldn't comment.  =
There
> isn't a formal position in the UK, just an informal reservation.  My
> experience on other issues relating to information privacy is that
> although the EU Directive may be pan-European, interpretation of it is
not.
> The UK tends to take a middle line, with some countries being more
liberal,
> others more conservative.  I would query whether in the Austrian case
> approval was given by the telecoms regulator, or the information =
privacy
> regulator...these are typically not the same.  However, if the =
Austrian
> information commissioner has given consent, well they know far more =
about
> Austrian legislation than I do so I wouldn't query that.
>
> If the current informal position did harden into a formal one, then =
the
> conclusion IMHO is that it could be difficult to put i-ENUM in public =
DNS.
> This doesn't mean that CPs in other jurisdictions couldn't adopt that
> approach, but I have to act within my national law.
>
> As to the opinions of others who assert that the UK Information
> Commissioner is wrong, well you're welcome to these opinions, but =
you'll
> forgive me if I listen to the UK regulator when determining whether =
I'm
> compliant with legislation, rather than someone's opinion on a mailing
> list...
>
> Regards
>
> Paul Rosbotham
> Manager, Interconnect Strategy & Technology Regulation
> Cable & Wireless
> www.cw.com
>
>
>
> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]
> Sent: 05 January 2007 11:37
> To: enum@ietf.org
> Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
>
>
> On 2007/01/04 17:01, "Clive D.W. Feather" <clive@demon.net> wrote:
> > lconroy said:
> >
> > > If any NRA or equivalent data protection authority refused to =
permit
> > > a necessary part of SIP URLs to be published, then doing so would
> > > make VoIP in general rather hard. An originating system has to be =
able
> > > to "find" the destination SIP provider or it isn't going to work. =
I
> hear
> > > rumours, but I can't believe anyone intends to block VoIP in this =
way.
> >
> > There's a difference between User (opt-in) and Infrastructure =
(everyone
> is
> > included) Enum in this context. I'm referring to Infrastructure Enum
> only.
>
> I'm not sure whether the suggested legal problems stem from EU law or
> national .uk one. In any case, you might be interested to hear that
> the Austrian NRA (RTR GmbH) happily signed a contract with us
> designating us to run an infrastructure ENUM trial in the *public* =
DNS.
>
> Whether that's just because we Austrians tend to be creative in the
> interpretation of EU regulations or whether there is really no problem
> there, I can't tell.
>
> But it's a fact that we run an officially sanctioned I-ENUM trial
> here in an EU member state.
>
> /ol
> --
> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>
> This e-mail has been scanned for viruses by the Cable & Wireless =
e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service,  visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also =
be
> subject to legal privilege. It is intended only for the recipient(s) =
named
> above. If you are not named above as a recipient, you must not read, =
copy,
> disclose, forward or otherwise use the information contained in this
email.
> If you have received this e-mail in error, please notify the sender =
(whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining any copies.
>
> _______________________________________________
> 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 Fri Jan 05 11:03:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2rWa-00025y-45; Fri, 05 Jan 2007 11:02:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rWZ-00025t-IJ
	for enum@ietf.org; Fri, 05 Jan 2007 11:02:31 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rWV-0000mO-30
	for enum@ietf.org; Fri, 05 Jan 2007 11:02:31 -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
	l05G2MHo019012; Fri, 5 Jan 2007 08:02:29 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Antoin Verschuren'" <Antoin.Verschuren@sidn.nl>, <enum@ietf.org>
Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 11:02:11 -0500
Message-ID: <00bb01c730e2$dd544ca0$87201f0a@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.3028
Thread-Index: AccwvmD1V5ejFpykQyyvvIia/GAmBQAAOKxgAAPlW2AAAQiQcAADzK3Q
In-Reply-To: <B33086268D53A0429A3AA2774C83892CDC59F7@KAEVS1.SIDN.local>
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: 386e0819b1192672467565a524848168
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


But the very definition of I-ENUM is service provider to service provider
interface not a User to Network interface.

If it SP to SP then the set of users is sufficiently small to permit various
forms of private data exchanges outside the scope of the DNS.

Everything else is better dealt with in User ENUM.

Simply because delegations in e164.arpa have not taken off as expected does
not mean that everyone has to try and fit every square peg into the round
hole of e164.arpa to economically justify its existence.

> -----Original Message-----
> From: Antoin Verschuren [mailto:Antoin.Verschuren@sidn.nl]
> Sent: Friday, January 05, 2007 10:02 AM
> To: enum@ietf.org
> Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
> 
> Richard Shockey wrote:
> > The simple truth is you don't need to put I-ENUM in the public DNS
> > and I still can't understand why anyone would.
> 
> I can.
> I can imagine a service where the authorisation to interconnect is
> embeded in a device or software, not the network.
> Supose I buy that service from Provider A who is a member of federation
> A.
> Now I want to use this device while I'm connected to the network of
> provider B (and paying for it) who is not part of federation A or any
> federation.
> This means I need to query the tree and find out which interconnection
> point of federation A is closest/fastest/most efficient for me to use. I
> do not want to first go to provider A's network to find that out, when
> my interconnection point might be my neighbour. I also don't want
> povider B to selectively block this service for me.
> If provider A and provider B both share this concept, than why should it
> be forbidden ?
> It's all a question of whether you want to have these end-to-end
> devices, or that you want the network you're connected to to decide
> which services you can use and how.
> Some incumbants might want to keep I-ENUM closed, and then we need a 3th
> ENUM tree for the providers that don't :-(
> This closed version is called private ENUM.
> The public DNS version is called Infrastructure ENUM, by definition.
> 
> > Carrier Interconnection is a function of trusted Registry
> > Infrastructures and the Policies associated with those Registries not
> > the access method to the data.
> 
> The interconnection might be in a trusted enviroment between certain
> peers, but not the discovery of where the peer is to try to
> interconnect, as this query might come from an unknown network.
> This model will allow providers to open or close their network for
> interconnection at their own insight, not forcing it.
> 
> > This IMHO this news out of the UK actually good news, hopefully it
> > will bring some folks to their senses especially about that bizarre
> > CREW idea floating around over there.
> 
> IMHO, the privacy considerations we should discuss in infrastructure
> ENUM is that a provider is only allowed to publish NAPTR data that is
> nessecary to service the service he sold the customer in relation to his
> phonenumber.
> Or to put it in simple words, I don't want my provider to publish my
> email address, website or business card if I only bought a voice service
> from him. So we should somehow define that in infrastructure ENUM, only
> those records are allowed to be published that are nessecary to route
> the service I bought. Perhaps only SIP ? Don't know, but I do know
> that's what the discussion should be about, and how to phrase that.
> 
> 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 Fri Jan 05 11:11:17 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2rez-0005tz-0m; Fri, 05 Jan 2007 11:11:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rex-0005tb-P6
	for enum@ietf.org; Fri, 05 Jan 2007 11:11:11 -0500
Received: from bay0-omc2-s16.bay0.hotmail.com ([65.54.246.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rew-0003Mm-9j
	for enum@ietf.org; Fri, 05 Jan 2007 11:11:11 -0500
Received: from BAY126-W22 ([65.55.131.57]) by bay0-omc2-s16.bay0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.2668); 
	Fri, 5 Jan 2007 08:11:09 -0800
X-Originating-IP: [75.213.105.102]
X-Originating-Email: [home_pw@msn.com]
Message-ID: <BAY126-W22107365625546CAE3702292BF0@phx.gbl>
From: Peter Williams <home_pw@msn.com>
To: <enum@ietf.org>
Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 08:11:08 -0800
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Jan 2007 16:11:09.0759 (UTC)
	FILETIME=[1CD29CF0:01C730E4]
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1273946893=="
Errors-To: enum-bounces@ietf.org

--===============1273946893==
Content-Type: multipart/alternative;
	boundary="_e0ea2c41-fb62-4599-a834-a6bb5bbcd6ae_"

--_e0ea2c41-fb62-4599-a834-a6bb5bbcd6ae_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20



> Richard> PS: Paul, your UK Information Commission arguments are> very sim=
ilar to the discussion on how many angels may dance on a pin> > Otmars ment=
ioning about mobile phones kills this argument anyway
I'm not so sure about these angles on the pinhead where each angel espies t=
he world from its facet for a living, unseen, covert, only sometimes visibl=
e: not quite among us but scheming nonetheless to organize the pins just so=
, the facets at just the right angle.
=20
Several trends are going on. Layer 2 switching is doing much of what IPv6 w=
as supposed to have done. Stacked switches and tunneling is making often ma=
king IP routing meaningless. LANs, MANs and PANs are evolving according to =
their own convergence dynamics. TLS and its handshakes are doing what IPSEC=
/ISAKMP were supposed to have done. WS-Security stack is doing what the upp=
er layer OSI stack was supposed to have done. All these are attacking the c=
oncept of the Network OS, that propelled Internet adoption - and necessaril=
y stymied other ways of thinking about technology adoption in secure global=
 networking.
=20
On the other hand, voip family is so much more effective than H323 gateways=
, particular in repurposing legacy local loops. But again, we see layer 2 s=
witching and vlans impacting IP, particular in mobile IP where a channel, a=
 port, a vlan, a fragment, and a nic have already converged into the same t=
hing, given 802.1x. In the wired world, we see the BRI D channel coming bac=
k into vogue, enabling voice and ethernet termination convergence even in t=
he US as streaming QOS begins to issue demands for tv (on no!, Milo Medin w=
as right all along!). In ENUM we obviously see the E.164 number as a switch=
ing/routable address, again. Stripped from .arpa, the role of the DNS as an=
 IP/ICMP technology is not as obviously necessary for the resolution proces=
s as it was: it may be the fallback when nothing better exists beyond ARPA =
control.
=20
The privacy principles relevant to the convergence of telephone and IP are =
by no means clear. Much of US internet thinking is set in stone: the past o=
f data vs voice, VANs vs telcos, backbone vs P2P, packet surveillance vs tr=
aditional voice wiretapping, security vs privacy. But swords are pulled fro=
m stones, as lots of 5 years olds know.
_________________________________________________________________
Type your favorite song.=A0 Get a customized station.=A0 Try MSN Radio powe=
red by Pandora.
http://radio.msn.com=

--_e0ea2c41-fb62-4599-a834-a6bb5bbcd6ae_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body><BR>&nbsp;<BR>

<HR id=3DstopSpelling>
<BR>
&gt; Richard<BR>&gt; PS: Paul, your UK Information Commission arguments are=
<BR>&gt; very similar to the discussion on how many angels may dance on a p=
in<BR>&gt; <BR>&gt; Otmars mentioning about mobile phones kills this argume=
nt anyway<BR><BR>
I'm not so sure about these angles on the pinhead where each angel espies t=
he world from its facet for a living, unseen, covert, only sometimes visibl=
e: not quite among us but scheming nonetheless to organize the pins just so=
, the facets at just the right angle.<BR>
&nbsp;<BR>
Several trends are going on. Layer 2 switching is doing much of what IPv6 w=
as supposed to have done. Stacked switches and tunneling is making often ma=
king IP routing meaningless. LANs, MANs and PANs are evolving according to =
their own convergence dynamics.&nbsp;TLS and its handshakes are doing what =
IPSEC/ISAKMP were supposed to have done. WS-Security stack is doing what th=
e upper layer OSI stack was supposed to have done. All these are attacking =
the concept of the Network OS, that propelled Internet adoption - and neces=
sarily stymied other ways of thinking about technology adoption in secure g=
lobal networking.<BR>
&nbsp;<BR>
On the other hand, voip family is so much more effective than H323 gateways=
, particular in repurposing legacy local loops. But again, we see layer&nbs=
p;2 switching and vlans impacting IP, particular in mobile IP where a chann=
el, a port, a vlan, a fragment,&nbsp;and a nic have already converged into =
the same thing, given 802.1x. In the wired world, we see the BRI D channel =
coming back into vogue, enabling voice and ethernet termination convergence=
 even in the US as streaming QOS begins to issue demands for tv (on no!, Mi=
lo Medin&nbsp;was right all along!). In ENUM we obviously see the E.164 num=
ber as a switching/routable address, again. Stripped from .arpa, the role o=
f the DNS as an IP/ICMP&nbsp;technology is not as obviously necessary for t=
he resolution process as it was: it may be the fallback when nothing better=
 exists beyond ARPA control.<BR>
&nbsp;<BR>
The privacy principles relevant to the convergence of telephone and IP are =
by no means clear. Much of US internet thinking is set in stone: the past o=
f data vs voice, VANs vs telcos, backbone vs P2P, packet surveillance vs tr=
aditional voice wiretapping, security vs privacy. But swords are pulled fro=
m stones, as lots of 5 years olds know.<BR><BR><br /><hr />Get free, person=
alized online radio with MSN Radio powered by Pandora. <a href=3D'http://ra=
dio.msn.com' target=3D'_new'>Try it!</a></body>
</html>=

--_e0ea2c41-fb62-4599-a834-a6bb5bbcd6ae_--


--===============1273946893==
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

--===============1273946893==--




From enum-bounces@ietf.org Fri Jan 05 11:15:21 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2ria-0007De-TU; Fri, 05 Jan 2007 11:14:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2riZ-0007DY-TE
	for enum@ietf.org; Fri, 05 Jan 2007 11:14:55 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2riY-0004sz-Es
	for enum@ietf.org; Fri, 05 Jan 2007 11:14:55 -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
	l05GEn2O022193; Fri, 5 Jan 2007 08:14:55 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Otmar Lendl'" <lendl@nic.at>, <enum@ietf.org>
Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 11:14:39 -0500
Message-ID: <00d001c730e4$9b3a1460$87201f0a@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.3028
Thread-Index: Accw2/Y1oaSQ0BqmR1CqkfarC730/QABwAOg
In-Reply-To: <20070105151233.GA26539@nic.at>
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: 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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]
> Sent: Friday, January 05, 2007 10:13 AM
> To: enum@ietf.org
> Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
> 
> On 2007/01/05 14:01, Richard Shockey <richard@shockey.us> wrote:
> >
> > The simple truth is you don't need to put I-ENUM in the public DNS and I
> > still can't understand why anyone would.
> 
> Oh, you don't need to have it in the public DNS.
> 
> That is, if you want to build a closed system for a single
> administrative domain (e.g. a country). Within that country you can
> decide who is a legitimate carrier, you can do access control on
> the DNS and as much legal hand-binding as you want.

But so long as nation-states continue to define who is or who is not a
carrier you will run into this. I am finally trying to deal with the world
as it is not what I think is should be.

> 
> Such a system was fine for the 20th century with neatly defined
> and non-overlapping markets.
> 
> It just breaks down if you take into account the state of networking
> in the 21th century.

No if it aint broke don't fix it. Its not about the DNS it's about data
exchanges. 

> 
> Do you want us to open the Austrian I-ENUM to every single small VoIP
> carrier worldwide? 

No actually ...

If yes, what is then the real difference (other than
> another charging point) to just using the public DNS?
> 
> You're replicating the PSTN trust model ("Trust all carriers"). 

Well if I'm a carrier I'm in a good position to define who I can trust and
why that does not mean I have to trust all carriers.

 Haven't
> you noticed that this is breaking down left and right as the global SS7
> network extends to locations which don't give a $#$%$% what the FCC or
> the EU regulations dictate. For all I know, the PSTN guys are scrambling
> to patch up their security model as they discovered that they can't just
> trust all SS7 messages any more.
> 
> Once you distribute a "secret" widely, that information won't stay
> secret. So why bother with this security by obscurity?

Some security is better than none which is what we have with the DNS.

> 
> On the other hand, if we restrict access to the Austrian I-ENUM to local
> carriers, then how is e.g. a German carrier supposed to select the
> correct Austrian carrier which is probably present at a carrier hotel /
> peering fabric in Frankfurt anyway? 

Have you heard of by-lateral agreements?

There is no technological need to
> use special "transit carriers" for intra-european calls.

Of course not but carrier interconnection and network peering even for IP is
all bilateral. I cannot peer with BT's IP backbone unless I can negotiate an
agreement with BT. That bilateral agreement ultimately becomes expressed as
my policy in by BGP tables.

Everything else is transit.

> 
> The sheer size of the NANP may skew your perception. Just try to imagine
> that each US State were its own country with each own FCC and thus carrier
> accredidation procedure. Now try to design a system for this scenario.

The ITU? 

> 
> > Carrier Interconnection is a function of trusted Registry
> Infrastructures
> > and the Policies associated with those Registries not the access method
> to
> > the data.
> 
> I never understood why the Policies have to be associated with
> Registries and not with Carriers themselves (other than the bottom
> line of Registries).

Well Carrier policy is expressed in how the registry data is used and the
common agreement between registry registrars on who can modify the registry.

> 
> > This IMHO this news out of the UK actually good news, hopefully it will
> > bring some folks to their senses especially about that bizarre CREW idea
> > floating around over there.
> 
> No comment on this, I defer to Jim.
> 
> /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 Fri Jan 05 11:28:42 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2rvg-0004uS-Fu; Fri, 05 Jan 2007 11:28:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rve-0004uL-QM
	for enum@ietf.org; Fri, 05 Jan 2007 11:28:26 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2rvd-0008Rt-GU
	for enum@ietf.org; Fri, 05 Jan 2007 11:28: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] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 17:27:13 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C58@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccwvmD1V5ejFpykQyyvvIia/GAmBQAAOKxgAAPlW2AAA6wybwAAZFBwAAGz61IAABws2A==
References: <9322B78036E1534A99B0BC51DEB0F9D6022CDCFC@GBCWSWIEM002.ad.plc.cwintra.com>
	<32755D354E6B65498C3BD9FD496C7D462C4C57@oefeg-s04.oefeg.loc>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

>>Otmars mentioning about mobile phones kills this argument anyway

>Not here it doesn't.  MNP means you don't know the carrier from the =
number range. =20
>For ported numbers, you're charged according to the number range (ie =
rangeholder rate), not the individual number (ie termination rate).

You are turning around cause and effect.
Nobody discussed privacy issues in choosing the charging

Richard


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



From enum-bounces@ietf.org Fri Jan 05 12:45:16 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2t7M-00022j-Ex; Fri, 05 Jan 2007 12:44:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t7L-0001xR-9r
	for enum@ietf.org; Fri, 05 Jan 2007 12:44:35 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2t7J-00018u-TE
	for enum@ietf.org; Fri, 05 Jan 2007 12:44:35 -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
	l05HiJDi008914 for <enum@ietf.org>; Fri, 5 Jan 2007 09:44:25 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <enum@ietf.org>
Date: Fri, 5 Jan 2007 12:44:00 -0500
Message-ID: <018901c730f1$15e3a300$87201f0a@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.3028
Thread-Index: Accw8RTF38JxWnnKQ1KxNeVlrO3oKg==
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Subject: [Enum] PEPPERMINT BOF FYI
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Peppermint BOF

Provisioning Extensions in Peering Registries for Multimedia
INTerconnection.

Mailing Lists:

To post to this list, send your email to:

peppermint@ietf.org

General information about the mailing list including subscription
information is at:

https://www1.ietf.org/mailman/listinfo/peppermint


BOF chairs:

Andrew Newton [andy@hxr.us]

Richard Shockey [rich.shockey@neustar.biz]

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD


BOF Purpose:

The ENUM and SPEERMINT working groups are working on various aspects of
Multi Media Interconnection. ENUM is specifically chartered to develop
protocols that involve the translation of E.164 numbers to URI's. SPEERMINT
has been chartered to develop best current practices among real-time
application service providers and how such services interconnect across
domain boundaries.

It is clear from discussions in both working groups that Multi-Media
Interconnection will require various forms of data to be exchanged among
administrative domains outside the normal scope of establishing a SIP
session. 

Such data exchanges might be provisioning of various forms of Registries
containing mappings of phone numbers to URI, policies surrounding the
admission to points of network interconnection and the distribution of
Registry data to various types of databases.

The purpose of the BOF is to determine the need and scope for such data
exchanges, what existing protocols need to be adapted to meet those needs
and the appropriate schema and queries are needed to facilitate such
exchanges.

The IETF has in the past done significant work on data exchanges among
various administrative entities. In particular the PROVREG working group
developed various schema and query mechanisms to facilitate the exchange of
data among domain name registries and registrars.

The ENUM Working group has adapted PROVREG working group protocols to
develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS
tree.  However, there has been little adoption of RFC 4114, and many of the
participants of the SPEERMINT working group require both data models and
protocol features not found in RFC 4114.

The proposed PEPPERMINT working group will build upon the knowledge gained
from those efforts, and the intent of this proposed working group is to find
a provisioning solution for peering as defined by SPEERMINT. The final work
product(s) from this working group will be based upon XML.  Additionally,
bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or
HTTP/SOAP. 

Proposed Deliverables

Requirements for SPEERMINT data exchange.

Provisioning of SPEERMINT data registries.

Provisioning of SPEERMINT/ENUM data caches.



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
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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



From enum-bounces@ietf.org Fri Jan 05 17:26:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2xVq-0005R1-BW; Fri, 05 Jan 2007 17:26:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2xVo-0005NI-FK
	for enum@ietf.org; Fri, 05 Jan 2007 17:26:08 -0500
Received: from sccrmhc12.comcast.net ([63.240.77.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2xVm-0000ZK-8q
	for enum@ietf.org; Fri, 05 Jan 2007 17:26:08 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc12) with ESMTP
	id <20070105222550012004gun7e>; Fri, 5 Jan 2007 22:26:03 +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 l05MPotb012233
	for <enum@ietf.org>; Fri, 5 Jan 2007 17:25:50 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l05MPoQb012229;
	Fri, 5 Jan 2007 17:25:50 -0500
Date: Fri, 5 Jan 2007 17:25:50 -0500
Message-Id: <200701052225.l05MPoQb012229@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <00d001c730e4$9b3a1460$87201f0a@cis.neustar.com>
	(richard@shockey.us)
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
References: <00d001c730e4$9b3a1460$87201f0a@cis.neustar.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Richard Shockey" <richard@shockey.us>

   > From: Otmar Lendl [mailto:lendl@nic.at]
   > 
   > That is, if you want to build a closed system for a single
   > administrative domain (e.g. a country). Within that country you can
   > decide who is a legitimate carrier, you can do access control on
   > the DNS and as much legal hand-binding as you want.

   But so long as nation-states continue to define who is or who is not a
   carrier you will run into this. I am finally trying to deal with the world
   as it is not what I think is should be.

But it can get complicated, and the complications can change fairly
quickly.  As you say, nation-states define who is a carrier and can
join the club.  But at least in the US, we're just one election from a
change in policy -- what if the FCC suddenly decides to "level the
playing field" between Verizon and Mom & Pop?  A shift in attitude
could change the set of carriers from a dozen or two to thousands.
And worse, members could join or leave the set quickly.

We at least need an architecture that won't fail under such a change.

Dale

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



From enum-bounces@ietf.org Fri Jan 05 18:20:20 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2yLd-0001Qf-OG; Fri, 05 Jan 2007 18:19:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yLc-0001QX-Jz
	for enum@ietf.org; Fri, 05 Jan 2007 18:19:40 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2yLa-00071Q-65
	for enum@ietf.org; Fri, 05 Jan 2007 18:19: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] NITS review of draft-ietf-enum-infrastructure-03
Date: Sat, 6 Jan 2007 00:19:00 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C5A@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccxGIGhHJsE0YkhSliAFbeDBqE44AABqX4w
References: <00d001c730e4$9b3a1460$87201f0a@cis.neustar.com>
	<200701052225.l05MPoQb012229@dragon.ariadne.com>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

>We at least need an architecture that won't fail under such a change.

Thank you, Dale
=20
Nobody prevents carriers to make private clubs, and they do already,
but any club can only serve a subset of subscribers

So we also need an option to include all subscribers, either direct or
indirect, e.g. draft-stastny-enum-ern-01.txt
=20
Richard


________________________________

Von: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
Gesendet: Fr 05.01.2007 23:25
An: enum@ietf.org
Betreff: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03



   From: "Richard Shockey" <richard@shockey.us>

   > From: Otmar Lendl [mailto:lendl@nic.at]
   >
   > That is, if you want to build a closed system for a single
   > administrative domain (e.g. a country). Within that country you can
   > decide who is a legitimate carrier, you can do access control on
   > the DNS and as much legal hand-binding as you want.

   But so long as nation-states continue to define who is or who is not =
a
   carrier you will run into this. I am finally trying to deal with the =
world
   as it is not what I think is should be.

But it can get complicated, and the complications can change fairly
quickly.  As you say, nation-states define who is a carrier and can
join the club.  But at least in the US, we're just one election from a
change in policy -- what if the FCC suddenly decides to "level the
playing field" between Verizon and Mom & Pop?  A shift in attitude
could change the set of carriers from a dozen or two to thousands.
And worse, members could join or leave the set quickly.

We at least need an architecture that won't fail under such a change.

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 Fri Jan 05 20:21:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H30En-0000W5-1u; Fri, 05 Jan 2007 20:20:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H30El-0000Vo-Ll
	for enum@ietf.org; Fri, 05 Jan 2007 20:20:43 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H30Ek-0001DG-1J
	for enum@ietf.org; Fri, 05 Jan 2007 20:20:43 -0500
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 05 Jan 2007 17:20:40 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l061KfMr020918; 
	Fri, 5 Jan 2007 17:20:41 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l061Kflb002579;
	Fri, 5 Jan 2007 17:20:41 -0800 (PST)
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, 5 Jan 2007 20:20:40 -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] NITS review of draft-ietf-enum-infrastructure-03
Date: Fri, 5 Jan 2007 20:20:37 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3026B6D40@xmb-rtp-20b.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Thread-Index: AccwvmD1V5ejFpykQyyvvIia/GAmBQAAOKxgABr6w0A=
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Rosbotham, Paul" <Paul.Rosbotham@cwmsg.cwplc.com>, <enum@ietf.org>
X-OriginalArrivalTime: 06 Jan 2007 01:20:40.0731 (UTC)
	FILETIME=[E10DAEB0:01C73130]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7494; t=1168046441;
	x=1168910441; c=relaxed/simple; s=sjdkim6002;
	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<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Enum]=20NITS=20review=20of=20draft-ietf-enum-infrast
	ructure-03 |Sender:=20;
	bh=o0ZwyPZ6YYLs7Cw967wwTDI3HJZJ1AzvtLEQqjsCVpg=;
	b=sQJWKnH0w+BHf+sgsK9YMu2yz2Ss52HSRY01MC6wtMjUiKEuHY7KHEk6nBXDpsgYllJgFZYF
	//cZO+o2b7YrFYKYnLgW8t+Yq/aVXEcK+c8EVUlzzROWO+wGWkwA5P1Z;
Authentication-Results: sj-dkim-6; header.From=mhammer@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Paul,

I certainly understand the need to follow policy and regulations of
one's nation-state.  However, those who make the laws need to understand
the resulting implications.

I understand that in "connecting the dots" one can arrive at a
conclusion that reveals information associated with a person.  But, if
you take that to its logical conclusion, no information of any kind
should ever be shared with anyone.  The key is to keep the focus on the
correct associations to protect; namely, the immediate ones tied to a
real human identity.  It is that last link to the person that makes the
revelation, not all the associations twenty steps removed.

It is the unintended consequences of application of rules with blinders
on that concern me.  The numbering and routing is crucial to the
functioning of the telephone network.  Restrictions on the sharing of
what number is served by what service provider can hamper the efficient
operation of the network and lead to designs that are anti-competitive.
And as has been pointed out, hiding certain associations is a lost
cause, unless you want to revoke number portability.

We need to design with 21 century thinking, not 20th century, with
respect to both regulation and technology.

Mike


> -----Original Message-----
> From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwmsg.cwplc.com]=20
> Sent: Friday, January 05, 2007 7:02 AM
> To: enum@ietf.org
> Subject: RE: [Enum] NITS review of draft-ietf-enum-infrastructure-03
>=20
> OK, I've been trying to keep out of this but I guess I should=20
> step in and clarify, given it was me who had the meeting with=20
> the UK Information Commissioner's Office.
>=20
> They had I-ENUM explained to them and expressed reservations.=20
>  Reservations, not outright written legal objections...they=20
> were asked to give an informal opinion and personally I=20
> welcome that they did so.  Laurence is correct, however, that=20
> there is no formal position.  Similarly, Clive is also=20
> correct to mention that there may be issues. =20
>=20
> I am not a lawyer, so apologies if any of this is garbled. =20
> The basic view was that although a telephone number in itself=20
> is not personal data, via the concept of "linked datasets",=20
> it can be combined with other databases to produce things=20
> which represent privacy concerns under EU legislation.  In=20
> particular, when linked with a telephone directory, it would=20
> allow the tying together of an individual and their telephone=20
> provider, which could be considered as personal data.  In=20
> putting their number into a telephony directory, the end user=20
> consented to that information being published, not for it to=20
> be possible to determine their choice of supplier.  It's this=20
> "linked datasets" consideration which leads to the rules=20
> around CLI transmission...the CLI isn't personal data but=20
> when linked to other data it becomes so : therefore if the=20
> customer wishes to withhold their CLI they can do so, and=20
> this is independent of whether they choose to be listed in a=20
> directory.  The fact that some numbers relate to corporate=20
> entities is irrelevant...many belong to an individual.
>=20
> In terms of the position elsewhere in the EU, I wouldn't=20
> comment.  There isn't a formal position in the UK, just an=20
> informal reservation.  My experience on other issues relating=20
> to information privacy is that although the EU Directive may=20
> be pan-European, interpretation of it is not.  The UK tends=20
> to take a middle line, with some countries being more=20
> liberal, others more conservative.  I would query whether in=20
> the Austrian case approval was given by the telecoms=20
> regulator, or the information privacy regulator...these are=20
> typically not the same.  However, if the Austrian information=20
> commissioner has given consent, well they know far more about=20
> Austrian legislation than I do so I wouldn't query that.
>=20
> If the current informal position did harden into a formal=20
> one, then the conclusion IMHO is that it could be difficult=20
> to put i-ENUM in public DNS.  This doesn't mean that CPs in=20
> other jurisdictions couldn't adopt that approach, but I have=20
> to act within my national law.
>=20
> As to the opinions of others who assert that the UK=20
> Information Commissioner is wrong, well you're welcome to=20
> these opinions, but you'll forgive me if I listen to the UK=20
> regulator when determining whether I'm compliant with=20
> legislation, rather than someone's opinion on a mailing list...
>=20
> Regards
>=20
> Paul Rosbotham
> Manager, Interconnect Strategy & Technology Regulation Cable=20
> & Wireless www.cw.com
>=20
>=20
>=20
> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]
> Sent: 05 January 2007 11:37
> To: enum@ietf.org
> Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
>=20
>=20
> On 2007/01/04 17:01, "Clive D.W. Feather" <clive@demon.net> wrote:
> > lconroy said:
> >=20
> > > If any NRA or equivalent data protection authority=20
> refused to permit=20
> > > a necessary part of SIP URLs to be published, then doing so would=20
> > > make VoIP in general rather hard. An originating system has to be=20
> > > able to "find" the destination SIP provider or it isn't going to=20
> > > work. I hear rumours, but I can't believe anyone intends=20
> to block VoIP in this way.
> >=20
> > There's a difference between User (opt-in) and Infrastructure=20
> > (everyone is
> > included) Enum in this context. I'm referring to=20
> Infrastructure Enum only.
>=20
> I'm not sure whether the suggested legal problems stem from=20
> EU law or national .uk one. In any case, you might be=20
> interested to hear that the Austrian NRA (RTR GmbH) happily=20
> signed a contract with us designating us to run an=20
> infrastructure ENUM trial in the *public* DNS.
>=20
> Whether that's just because we Austrians tend to be creative=20
> in the interpretation of EU regulations or whether there is=20
> really no problem there, I can't tell.
>=20
> But it's a fact that we run an officially sanctioned I-ENUM=20
> trial here in an EU member state.
>=20
> /ol
> --
> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >
>=20
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>=20
> This e-mail has been scanned for viruses by the Cable &=20
> Wireless e-mail security system - powered by MessageLabs. For=20
> more information on a proactive managed e-mail security=20
> service,  visit http://www.cw.com/uk/emailprotection/=20
> =20
> The information contained in this e-mail is confidential and=20
> may also be subject to legal privilege. It is intended only=20
> for the recipient(s) named above. If you are not named above=20
> as a recipient, you must not read, copy, disclose, forward or=20
> otherwise use the information contained in this email. If you=20
> have received this e-mail in error, please notify the sender=20
> (whose contact details are above) immediately by reply e-mail=20
> and delete the message and any attachments without retaining=20
> any copies.
>=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 Sat Jan 06 15:53:15 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H3IWa-000229-Vu; Sat, 06 Jan 2007 15:52:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H3IWa-00021h-4a
	for enum@ietf.org; Sat, 06 Jan 2007 15:52:20 -0500
Received: from shaun.rfc1035.com ([195.54.233.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3IWW-0001i8-LE
	for enum@ietf.org; Sat, 06 Jan 2007 15:52:20 -0500
Received: from [195.54.233.69] (HELO [195.54.233.69])
	by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4)
	with ESMTP id 140203 for enum@ietf.org; Sat, 06 Jan 2007 20:52:15 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
References: <7BE13EBEBD63E34EB84EF45ED97F2234123D25@exchsrv01.Timico.local>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B29488AC-3451-4D9B-BD40-A749C5FDC01E@rfc1035.com>
Content-Transfer-Encoding: 7bit
From: Jim Reid <jim@rfc1035.com>
Date: Sat, 6 Jan 2007 20:52:14 +0000
To: IETF ENUM WG <enum@ietf.org>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Subject: [Enum] Fwd: UK Enum Consortium cordially invites you to attend an
	Enum Workshop in London on 17th January 2007
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

I apologise if this is off topic for the list. However the  
announcement may be of interest to a many of the folk here.

Begin forwarded message:

> From: "Adrian Snell" <Adrian.Snell@timico.co.uk>
> Date: January 5, 2007 17:18:47 GMT
> To: <adrian.snell@timico.net>
> Subject: UK Enum Consortium cordially invites you to attend an Enum  
> Workshop in London on 17th January 2007
>
> Dear Sir / Madam
>
> I write, on behalf of the newly formed UK Enum Consortium Ltd, to
> provide an invitation to attend a Workshop on Enum in the UK.
> Where :     THE HOP CELLARS Function Rooms
>             24 Southwark Street, London, SE1 1TY, UK
>             Tel: 020 7403 6851
>             Email: hopcel@ballsbrothers.co.uk
>
> See :       http://www.ballsbrothers.co.uk/hop/   for further info  
> and Map.
>
> When :      from 13.00 ( for 13.30 start ) on Wednesday 17th  
> January 2007.
>
> Cost :      FREE to attend
>
> This Event is intended to provide you with an update on the current
> status of Enum in the UK and to provide information on the upcoming UK
> Tier 1 Public Tender and RFP process, as well as the expected schedule
> of events surrounding the RFP and selection of the successful  
> bidder as
> UKEC's appointed Tier 1 Enum Registry Operator.
>
> The Agenda includes:
>
> 1. Presentation on UKEC's work to date
>
> 2. Presentation on the form and process of the RFP
>
> 3. Presentation on Carrier Registrations in User Enum (CRUE)
>
> 4. UKEC Roadmap for 2007, and how you can get involved
>
>
> There will be plenty of opportunity for all attendees to ask questions
> and provide feedback to UKEC before the RFP launches.
>
> Who should attend:
> Industry followers and participants from across Europe, Potential  
> Tier 1
> Bidders, Electronic Communication Service Providers, Alternative
> Communication Service Providers, ISP's and infrastructure providers,
> potential Tier 2 Registrars, Enum Application Developers and anyone  
> with
> an interest in the future of convergence in telecommunications.
>
> Please feel free to forward this mail on to any interested party,
> however space is limited, so if possible, please confirm you intention
> to attend in advance to adrian.snell@timico.net
>
> UKEC Ltd.
> For further info on this event, or for press enquiries :
> adrian.snell@timico.net
> Due to distribution via a number of industry mailing lists, please
> accept my apologies if you receive this twice.


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



From enum-bounces@ietf.org Sat Jan 06 16:20:19 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H3IxL-0003bR-BR; Sat, 06 Jan 2007 16:19:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H3IxJ-0003bE-K4
	for enum@ietf.org; Sat, 06 Jan 2007 16:19:57 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3IxI-0000hT-6c
	for enum@ietf.org; Sat, 06 Jan 2007 16:19:57 -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
	l06LJmpQ025818; Sat, 6 Jan 2007 13:19:54 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Jim Reid'" <jim@rfc1035.com>, "'IETF ENUM WG'" <enum@ietf.org>
Subject: RE: [Enum] Fwd: UK Enum Consortium cordially invites you to attend
	anEnum Workshop in London on 17th January 2007
Date: Sat, 6 Jan 2007 16:19:37 -0500
Message-ID: <00bc01c731d8$61201d20$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.3028
Thread-Index: Accx1JcHk0t9cvSuT7GVQ4+gJ1g9xAAAy8Bw
In-Reply-To: <B29488AC-3451-4D9B-BD40-A749C5FDC01E@rfc1035.com>
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


A. Jim its is certainly not off topic and 

B. I admire your choice of meeting facilities. Its one way to get people
interested in public ENUM. :-)


> -----Original Message-----
> From: Jim Reid [mailto:jim@rfc1035.com]
> Sent: Saturday, January 06, 2007 3:52 PM
> To: IETF ENUM WG
> Subject: [Enum] Fwd: UK Enum Consortium cordially invites you to attend
> anEnum Workshop in London on 17th January 2007
> 
> I apologise if this is off topic for the list. However the
> announcement may be of interest to a many of the folk here.
> 
> Begin forwarded message:
> 
> > From: "Adrian Snell" <Adrian.Snell@timico.co.uk>
> > Date: January 5, 2007 17:18:47 GMT
> > To: <adrian.snell@timico.net>
> > Subject: UK Enum Consortium cordially invites you to attend an Enum
> > Workshop in London on 17th January 2007
> >
> > Dear Sir / Madam
> >
> > I write, on behalf of the newly formed UK Enum Consortium Ltd, to
> > provide an invitation to attend a Workshop on Enum in the UK.
> > Where :     THE HOP CELLARS Function Rooms
> >             24 Southwark Street, London, SE1 1TY, UK
> >             Tel: 020 7403 6851
> >             Email: hopcel@ballsbrothers.co.uk
> >
> > See :       http://www.ballsbrothers.co.uk/hop/   for further info
> > and Map.
> >
> > When :      from 13.00 ( for 13.30 start ) on Wednesday 17th
> > January 2007.
> >
> > Cost :      FREE to attend
> >
> > This Event is intended to provide you with an update on the current
> > status of Enum in the UK and to provide information on the upcoming UK
> > Tier 1 Public Tender and RFP process, as well as the expected schedule
> > of events surrounding the RFP and selection of the successful
> > bidder as
> > UKEC's appointed Tier 1 Enum Registry Operator.
> >
> > The Agenda includes:
> >
> > 1. Presentation on UKEC's work to date
> >
> > 2. Presentation on the form and process of the RFP
> >
> > 3. Presentation on Carrier Registrations in User Enum (CRUE)
> >
> > 4. UKEC Roadmap for 2007, and how you can get involved
> >
> >
> > There will be plenty of opportunity for all attendees to ask questions
> > and provide feedback to UKEC before the RFP launches.
> >
> > Who should attend:
> > Industry followers and participants from across Europe, Potential
> > Tier 1
> > Bidders, Electronic Communication Service Providers, Alternative
> > Communication Service Providers, ISP's and infrastructure providers,
> > potential Tier 2 Registrars, Enum Application Developers and anyone
> > with
> > an interest in the future of convergence in telecommunications.
> >
> > Please feel free to forward this mail on to any interested party,
> > however space is limited, so if possible, please confirm you intention
> > to attend in advance to adrian.snell@timico.net
> >
> > UKEC Ltd.
> > For further info on this event, or for press enquiries :
> > adrian.snell@timico.net
> > Due to distribution via a number of industry mailing lists, please
> > accept my apologies if you receive this twice.
> 
> 
> _______________________________________________
> 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 Jan 08 11:32:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H3xPQ-0004bo-HR; Mon, 08 Jan 2007 11:31:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xPP-0004bg-Sq
	for enum@ietf.org; Mon, 08 Jan 2007 11:31:39 -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 1H3vh8-0003VK-7o
	for enum@ietf.org; Mon, 08 Jan 2007 09:41:51 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id 75AE24C3D6; Mon,  8 Jan 2007 15:41:49 +0100 (CET)
Date: Mon, 8 Jan 2007 15:41:49 +0100
From: Otmar Lendl <lendl@nic.at>
To: Richard Shockey <richard@shockey.us>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070108144149.GA13916@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>,
	Richard Shockey <richard@shockey.us>, enum@ietf.org
References: <20070105151233.GA26539@nic.at>
	<00d001c730e4$9b3a1460$87201f0a@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d001c730e4$9b3a1460$87201f0a@cis.neustar.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/05 17:01, Richard Shockey <richard@shockey.us> wrote:
> > -----Original Message-----
> > From: Otmar Lendl [mailto:lendl@nic.at]
> > Sent: Friday, January 05, 2007 10:13 AM
> > To: enum@ietf.org
> > Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
> > 
> > On 2007/01/05 14:01, Richard Shockey <richard@shockey.us> wrote:
> > >
> > > The simple truth is you don't need to put I-ENUM in the public DNS and I
> > > still can't understand why anyone would.
> > 
> > Oh, you don't need to have it in the public DNS.
> > 
> > That is, if you want to build a closed system for a single
> > administrative domain (e.g. a country). Within that country you can
> > decide who is a legitimate carrier, you can do access control on
> > the DNS and as much legal hand-binding as you want.
> 
> But so long as nation-states continue to define who is or who is not a
> carrier you will run into this. 

For the write permission: Yes. 

To add numbers to I-ENUM you first have to get numbers assigned to
you in the first place. There are established procedures for that
in all jurisdictions, thus there is no need to invent new rules and
regulations. So that base is covered.

A carrier only has numbers from countries where he operates, is
accredited with the NRA, and thus can deal with local rules.

For the read permissions: No.

A subscriber can dial any international number he pleases. His carrier
has to route calls to countries where he is *not* an accredited carrier.
Maybe he has a peering relationship with the destination network. How
is he going to find out?

> I am finally trying to deal with the world
> as it is not what I think is should be.

You're not dealing with the world. You're dealing with individual
countries.

[...]
> 
> > If yes, what is then the real difference (other than
> > another charging point) to just using the public DNS?
> > 
> > You're replicating the PSTN trust model ("Trust all carriers"). 
> 
> Well if I'm a carrier I'm in a good position to define who I can trust and
> why that does not mean I have to trust all carriers.

Correct: You as the carrier want to decide whom to trust and thus from
whom to accept calls.

That's quite orthogonal to "who is allowed to see information about
numbers".

Is the carrier going to decide with whom he will to peer or will some
mandate concerning the availability of information restrict his choices?

> > 
> > Once you distribute a "secret" widely, that information won't stay
> > secret. So why bother with this security by obscurity?
> 
> Some security is better than none which is what we have with the DNS.

Yes, that will work out just as great as the idea of using social
security numbers as authentication tokens. Just restrict that
information to "authorized entities" and you have a decent system.

Indeed.

> > On the other hand, if we restrict access to the Austrian I-ENUM to local
> > carriers, then how is e.g. a German carrier supposed to select the
> > correct Austrian carrier which is probably present at a carrier hotel /
> > peering fabric in Frankfurt anyway? 
> 
> Have you heard of by-lateral agreements?

... which transfers that oh-so-secret information about who owns which 
numbers to an entity which is not bound by the NRA's privacy regulation. 
Sure, you try to fold them into the bi-lateral agreement. Good luck on
enforcing these when that routing information get re-injected in foreign
minute-reselling markets.

What if that a peering possible based on a mutually trusted TLS cert?

> There is no technological need to
> > use special "transit carriers" for intra-european calls.
> 
> Of course not but carrier interconnection and network peering even for IP is
> all bilateral. I cannot peer with BT's IP backbone unless I can negotiate an
> agreement with BT. That bilateral agreement ultimately becomes expressed as
> my policy in by BGP tables.

I wrote: "technological need". You wrote: "negotiate an agreement".
These are different facets of the peering problem space.

This is the crux of the matter: 

VoIP peering need not be about stringing a wire, but about establishing
a trust relationship. The distribution of number ownership tables 
isn't the crucial part of this.

(And we should be careful about BGP analogies. cf TRIP, RIR routing
registries, RIR IP assignement DBs, contract-less peering, ...)

> > The sheer size of the NANP may skew your perception. Just try to imagine
> > that each US State were its own country with each own FCC and thus carrier
> > accreditation procedure. Now try to design a system for this scenario.
> 
> The ITU? 

Hu?

The ITU is a VoIP Peering System?

The ITU will distribute Number->URI mappings to all carriers?

The ITU will determine whether someone is a legitimate carrier and thus
eligible to receive I-ENUM 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 Mon Jan 08 17:57:23 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H43QG-0001BD-71; Mon, 08 Jan 2007 17:56:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H43QE-0001Aq-SI
	for enum@ietf.org; Mon, 08 Jan 2007 17:56:54 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H43QB-0003sY-Sc
	for enum@ietf.org; Mon, 08 Jan 2007 17:56:54 -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
	l08Mum5Z032450 for <enum@ietf.org>; Mon, 8 Jan 2007 14:56:53 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'IETF ENUM WG'" <enum@ietf.org>
Date: Mon, 8 Jan 2007 17:56:34 -0500
Message-ID: <001a01c73378$40bbf3a0$22f0a544@cis.neustar.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001B_01C7334E.57E77240"
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-index: Accw64syBzzSkqrtSb6S0TiBsiVqmgAAOILAAKHcQoAAARXxIA==
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: 6f51ba5266426a53fc06c7d32a3c18b6
Subject: [Enum] 
	FW: draft-schwartz-peppermint-e164-provisioning-data-set-00.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C7334E.57E77240
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


FYI

> -----Original Message-----
> From: David Schwartz [mailto:David.Schwartz@Kayote.com]
> Sent: Monday, January 08, 2007 5:27 PM
> To: Andrew Newton; Richard Shockey
> Cc: peppermint@ietf.org; speermint@ietf.org
> Subject: draft-schwartz-peppermint-e164-provisioning-data-set-00.txt
> 
> Hi
> 
> I just submitted a 00 draft on provisioning data sets.
> 
> Until it shows up on the ID tracker you can use this version.
> 
> Cheers,
> 
> David

------=_NextPart_000_001B_01C7334E.57E77240
Content-Type: text/plain;
	name="Peppermint provisioning Version 00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Peppermint provisioning Version 00.txt"




Network Working Group                                        D. Schwartz
Internet-Draft                                           Kayote Networks
Intended status: Informational                                   E. Katz
Expires: July 5, 2007                           XConnect Global Networks
                                                            January 2007
=20

           E.164 Number Provisioning - Data Set Requirements
      draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2007).

Abstract

   This document outlines which information should be captured when
   E.164 numbers are provisioned within a central registry.  This
   document is not a specification but rather a set of information
   which, when associated with an addressable entity can assist in
   applying policy to subsequent queries.





Schwartz & Katz           Expires July 5, 2007                  [Page 1]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Provisioning Information  . . . . . . . . . . . . . . . . . . . 3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9






































Schwartz & Katz           Expires July 5, 2007                  [Page 2]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


1.  Introduction

   When writing rule based engines to provide filtered access to E.164
   data it is often necessary to have more information available for the
   query than just the address of record (AOR) that corresponds to a
   particular number.  This additional required information is the
   subject of this draft document.  The data set in this document can -
   and should be - extended and is intended to spur discussion that will
   result in a complete set.


2.  Scope

   This document focuses on the supporting data set that is required to
   properly provisioning E.164 numbers.  A discussion of the mechanism
   to transfer or upload this data to the registry or the protocols used
   for this purpose is beyond the scope of this document.


3.  Provisioning Information

   The provisioning data can be broken down into two categories: static
   and dynamic.  Static information is that which is associated with the
   owner of the resource and remains constant from query to query.
   Dynamic information is that which can be factored into "profiles" or
   views of the data, each with potentially different data.

   o  Static Information

      The data in this category relates to the identification, ownership
      and general validity of the number.

      1.  Value

          The value is the resource that is being sought.  This value
          may be a fully qualified E.164 number (e.g. 12127775555), or
          alternatively, the value may be a number representing a range
          of numbers (e.g. 1212777).  In this latter case the "length"
          field defined below is needed to establish the limits of the
          number range.

      2.  Range

          This and the next field are used to assist in resolving ranges
          into individual and unique valid E.164 numbers.  The Range
          field is a Boolean value, which indicates whether the resource
          specified in the "Value" field is a range that needs to be
          expanded out to the "length" number of digits, or



Schwartz & Katz           Expires July 5, 2007                  [Page 3]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


          alternatively, an individual number that does not require
          further manipulation.

      3.  Length

          This field is used for expanding ranges to individual unique
          numbers.

      4.  CreationDateTime

          The value "CreationDateTime" refers to the date on which this
          resource was first provisioned by this service provider.  If
          the date does not match the current date and time this record
          contains modifications to an existing Value.  If the date does
          match the current date than this is a new record.

          +  TimeZone

             All DateTime fields must include TimeZone information for
             normalization.

      5.  Type

          There is value in knowing what type of resource this is (e.g.
          residential, call shop, etc).  Different types of resources
          have different usage patterns and capturing this information
          can assist in developing fraud detection engines

      6.  Privacy

          This field is a flag indicating whether this number is
          publicly available to anyone or whether there has to be a
          predetermined policy in place in order for the number to be
          given out

      7.  Ownership

          The Ownership field consists of additional subfields defining
          the ownership of the provisioned e164 resource.  At any given
          time there can be multiple "owners" of a given resource.  The
          three levels described in this document are Carrier of Record,
          Service Provider and End User.  Since it is quite possible
          that these are three distinct entities they all must be
          specified for the provisioned resource.  Since regulatory
          issues allow for ownership transfer to and from different
          ServiceProviders, each ServiceProvider field must be qualified
          via activation dates.




Schwartz & Katz           Expires July 5, 2007                  [Page 4]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


          +  CarrierOfRecord

             As defined in [2] the Carrier of Record is typically a
             service provider that is authorized to issue E.164 numbers
             for the provisioning of PSTN service under the authority of
             a National Regulatory Authority (NRA).

          +  ServiceProvider

             The ServiceProvider field indicates the party that "sells"
             the resource to the end user.  ServiceProvider field is
             subject to dates as defined below.

             -  ActivationDateTime

                There are many reasons why it is possible for a number
                to be provisioned but not yet active.  For example,
                consider the situation in which a service provider
                provisions a number range, but activates only the actual
                numbers that have been "sold" to customers.  The
                existance of an "ActivationDateTime" field would enable
                the service to activate only a single number or range of
                numbers at some future time.

             -  DeactivationDateTime

                Similar to the ActivationDateTime field described above,
                a DeactivationDateTime field could be used to port
                numbers to a different provider to comply with regional
                number portability requirements.

             -  TimeZone

                All DateTime fields must include TimeZone information
                for normalization.

          +  EndUser

             The EndUser field indicates the user to which this number
             was provisioned.  Note that there can be subfields
             associated with the EndUser that provide more information
             about this user.  Only one such field (EndUserTimeZone) is
             presented here as it is useful when creating user based
             policy engines.

             -  EndUserTimeZone

                Knowing the time zone of the user to which this number



Schwartz & Katz           Expires July 5, 2007                  [Page 5]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


                is provisioned can assist in developing receiving user
                time based policy

   o  Dynamic Information

      The data in this section belongs in a category that is dependent
      on "who is asking".  Some of the provisioned information in this
      section is querying party dependent while other information is
      queried data dependent.  Each set of "dynamic" information is
      grouped into a "profile" or "view" and there are potentially many
      profiles for each static resource record.  Specifically, there is
      always at least one profile for each static record representing
      the "default" behavior and 0 or more "specialized" profiles that
      override the default profile for requests that match the criteria
      of the profile.

      *  Profile

         +  QueryDataInformation

            1.  Validity

                The validity field is used to define a window in which
                this profile is active.  The following three subfields
                provide higher resolution for this field.

                o  StartDateTime

                o  StopDateTime

                o  TimeZone

            2.  AddressOfRecord

                The AOR field documents the actual location information
                for the associated resource.  The following two
                subcategories are provided for additional flexibility.

                o  Regex

                o  TerminationDomain

         +  QueryingPartyInformation

            1.  QueryFromLocation

                This includes both a user id as well as an IP/s from
                where the queries will emanate.



Schwartz & Katz           Expires July 5, 2007                  [Page 6]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


                o  QueryUserID

                o  QueryUserAddress

            2.  QueryMechanism

                Depending on the query mechanism used, it may be more
                advantageous to resolve to a different AOR.  For
                example, depending on which protocol is used, it might
                be possible to provide more extensive routing
                information.  Alternatively, the registry may choose to
                send different information back to the querying party
                depending on the security of the query communication
                path.  This subsection delineates these considerations.

                o  QueryType

                   There are many protocols that can be used to perform
                   the query.  While ENUM is one of the more popular
                   protocols there is no reason other protocols (e.g.
                   SIP 302) cannot be used as well.  Thus the Type of
                   Query field indicates which protocol will be used for
                   this profile.

                o  QuerySecurity

                   It is important to secure the location lookup process
                   especially if the lookup is remote.  This Security
                   field would include values such as "=3DIPSec"[1]


4.  Security Considerations

   This document introduces no new security considerations.


5.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC2434].


6.  Acknowledgements

   This document is based in part on contributions made by Brocha
   Strous, David Koppel, Ofer Mizrachi, Mike Grynberg and Yael Berlinger
   of Kayote Networks and Natan Tiefenbrun of XConnect Global Networks.




Schwartz & Katz           Expires July 5, 2007                  [Page 7]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


7.  References

7.1.   Normative References

   [1]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

7.2.   Informative References

   [2]  Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements",
         draft-ietf-enum-infrastructure-enum-reqs-03.txt, August 2006.


Authors' Addresses

   David Schwartz
   Kayote Networks
   Malcha Technology Park
   Building # 1
   Jerusalem  90961
   Israel

   Phone: +972 52 347 4656
   Email: david.schwartz@kayote.com
   URI:   www.kayote.com


   Eli Katz
   XConnect Global Networks
   1 Ballards Lane
   London  N3 1LQ
   United Kingdom

   Phone: +44 (0) 870 794 9990
   Fax:   +44 (0) 870 794 9991
   Email: ekatz@xconnect.net
   URI:   www.xconnect.net














Schwartz & Katz           Expires July 5, 2007                  [Page 8]
=0C
Internet-Draft         E.164 provisioning data set          January 2007


Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Schwartz & Katz           Expires July 5, 2007                  [Page 9]
=0C

------=_NextPart_000_001B_01C7334E.57E77240
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_001B_01C7334E.57E77240--





From enum-bounces@ietf.org Thu Jan 11 15:51:13 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H56sf-000688-9P; Thu, 11 Jan 2007 15:50:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H56sd-000658-ET; Thu, 11 Jan 2007 15:50:35 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1H56sb-0003lw-0d; Thu, 11 Jan 2007 15:50:35 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E88E72ACE2;
	Thu, 11 Jan 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H56s6-0007vE-Lx; Thu, 11 Jan 2007 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: <E1H56s6-0007vE-Lx@stiedprstage1.ietf.org>
Date: Thu, 11 Jan 2007 15:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: enum@ietf.org
Subject: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=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 UNUSED
	Author(s)	: R. Stastny, et al.
	Filename	: draft-ietf-enum-unused-00.txt
	Pages		: 26
	Date		: 2007-1-11
	
   This document registers the Enumservice "unused" using the URI scheme
   "data:" as per the IANA registration process defined in the ENUM
   specification, RFC 3761.  This Enumservice may be used to indicate
   that the E.164 number (or E.164 number range) tied to the domain in
   which the enclosing NAPTR is published is not allocated or assigned
   for communications service.  When such an indication is provided, an
   ENUM client can detect calls that will fail "early".


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-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-unused-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-unused-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: <2007-1-11125055.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-unused-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-enum-unused-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-1-11125055.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 Jan 11 16:19:39 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H57KL-00011O-6o; Thu, 11 Jan 2007 16:19:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H57KK-00011D-8K
	for enum@ietf.org; Thu, 11 Jan 2007 16:19:12 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57KI-0005md-Qw
	for enum@ietf.org; Thu, 11 Jan 2007 16:19:12 -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
	l0BLIxZf020516 for <enum@ietf.org>; Thu, 11 Jan 2007 13:19:04 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'IETF ENUM WG'" <enum@ietf.org>
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Date: Thu, 11 Jan 2007 16:18:45 -0500
Message-ID: <014401c735c6$164f9720$f3201f0a@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acc1wiyCBLlbqIZ9Ss2fR97JHAinuAAA7CaQ
In-Reply-To: <E1H56s6-0007vE-Lx@stiedprstage1.ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
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: 25620135586de10c627e3628c432b04a
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



Folks I hope we can have a through review of this document in the upcoming
weeks this is a very useful document to folks and I can see going to WGLC
very quickly on this.



> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Thursday, January 11, 2007 3:50 PM
> To: i-d-announce@ietf.org
> Cc: enum@ietf.org
> Subject: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Telephone Number Mapping Working Group of
> the IETF.
> 
> 	Title		: IANA Registration for Enumservice UNUSED
> 	Author(s)	: R. Stastny, et al.
> 	Filename	: draft-ietf-enum-unused-00.txt
> 	Pages		: 26
> 	Date		: 2007-1-11
> 
>    This document registers the Enumservice "unused" using the URI scheme
>    "data:" as per the IANA registration process defined in the ENUM
>    specification, RFC 3761.  This Enumservice may be used to indicate
>    that the E.164 number (or E.164 number range) tied to the domain in
>    which the enclosing NAPTR is published is not allocated or assigned
>    for communications service.  When such an indication is provided, an
>    ENUM client can detect calls that will fail "early".
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-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-unused-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-unused-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.


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



From enum-bounces@ietf.org Thu Jan 11 16:26:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H57RD-0007BG-U2; Thu, 11 Jan 2007 16:26:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H57RD-0007Aa-44
	for enum@ietf.org; Thu, 11 Jan 2007 16:26:19 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57R9-0007Fd-3V
	for enum@ietf.org; Thu, 11 Jan 2007 16:26:19 -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
	l0BLPUL1022040; Thu, 11 Jan 2007 13:25:35 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'IETF ENUM WG'" <enum@ietf.org>
Date: Thu, 11 Jan 2007 16:25:18 -0500
Message-ID: <015401c735c6$ff70fca0$f3201f0a@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acc1xv2PFMFZSwsVTr27EfPo9zhgdw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
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: 9466e0365fc95844abaf7c3f15a05c7d
Cc: =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= <paf@cisco.com>
Subject: [Enum] Its that time of year again ... Prague is coming up
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



The chairs would like advanced notice on any agenda items or new WG items
people have for Prague ASAP.

We are slowly but deliberately winding down our work item list with the
major item remaining the revision of RFC 3761 to Draft.

One of the major discussion items the chairs will have is ENUM WG scope and
goals for 07, if any.


 

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
Skype:"rshockey101"
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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



From enum-bounces@ietf.org Thu Jan 11 18:21:36 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H59E4-0000Rz-Ao; Thu, 11 Jan 2007 18:20:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H59E2-0000Rl-Fh
	for enum@ietf.org; Thu, 11 Jan 2007 18:20:50 -0500
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H59E0-00020C-CT
	for enum@ietf.org; Thu, 11 Jan 2007 18:20:50 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-14.tower-121.messagelabs.com!1168557647!7805430!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 19475 invoked from network); 11 Jan 2007 23:20:47 -0000
Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4)
	by server-14.tower-121.messagelabs.com with SMTP;
	11 Jan 2007 23:20:47 -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 l0BNKljF028827; 
	Thu, 11 Jan 2007 18:20:47 -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 l0BNKUCu028660; 
	Thu, 11 Jan 2007 18:20:39 -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] I-D ACTION:draft-ietf-enum-unused-00.txt
Date: Thu, 11 Jan 2007 18:20:07 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0E78EB65@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <014401c735c6$164f9720$f3201f0a@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Thread-Index: Acc1wiyCBLlbqIZ9Ss2fR97JHAinuAAA7CaQAAORZ3A=
From: "Pfautz, Penn L, GBLAM" <ppfautz@att.com>
To: <richard@shockey.us>, "IETF ENUM WG" <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

I guess I have a lot of questions about this document.

1. How does this relate to "void"? Is it replacing it or doing something
else?

2. The draft seems directed to user ENUM and, as such, I'm not sure this
is the right place for information not about user registrations which at
least part of this (unassigned numbers, unallocated ranges) seems to be.
There is an implicit burden placed on Service Providers and NRAs that
not all will find acceptable. I think we're crossing the streams here.

3. I still have problems seeing the problem. We're talking about calls
to numbers that aren't in service. Unless the caller is a spammer (in
which case, why help them?) isn't it just an error that won't be
repeated when the call goes the PSTN and an error message is provided?
How frequent will these calls be?=20
BTW, I've not convinced about the looping issue. Shouldn't the gateway
to which call to ENUM-only ranges would be routed provide a "not in
service" message? =20

4. Re security, I think there should be an acknowledgement that this
approach would support identification of unpublished numbers in the
Security section rather than a vague reference to conditions in 7.4. I'm
pretty sure my NRA would NOT want this implemented.

5. In 7.4 case 3 the fallback seems to imply the SP will provision a
capability record indicating the services it provides for the block if
the user doesn't choose to register. If this is user ENUM why do this?

6. Finally some nits: 7.3.2 has a reference to RFC 308 rather than 2308
and the statement in 7.2.1.1 that fixed numbering plans typically
require the full number to be dialed is not true, at least in the NANP.
A number of US states will give up their 7-digit home NPA dialing over
their (or more likely your) dead body :-)

Maybe it's late in the day and I just need a drink...

Happy New Year

Penn

-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us]=20
Sent: Thursday, January 11, 2007 4:19 PM
To: 'IETF ENUM WG'
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt



Folks I hope we can have a through review of this document in the
upcoming
weeks this is a very useful document to folks and I can see going to
WGLC
very quickly on this.



> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Thursday, January 11, 2007 3:50 PM
> To: i-d-announce@ietf.org
> Cc: enum@ietf.org
> Subject: [Enum] I-D ACTION:draft-ietf-enum-unused-00.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		: IANA Registration for Enumservice UNUSED
> 	Author(s)	: R. Stastny, et al.
> 	Filename	: draft-ietf-enum-unused-00.txt
> 	Pages		: 26
> 	Date		: 2007-1-11
>=20
>    This document registers the Enumservice "unused" using the URI
scheme
>    "data:" as per the IANA registration process defined in the ENUM
>    specification, RFC 3761.  This Enumservice may be used to indicate
>    that the E.164 number (or E.164 number range) tied to the domain in
>    which the enclosing NAPTR is published is not allocated or assigned
>    for communications service.  When such an indication is provided,
an
>    ENUM client can detect calls that will fail "early".
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-00.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-unused-00.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-unused-00.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

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



From enum-bounces@ietf.org Fri Jan 12 05:03:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5JF9-0006Nw-Ut; Fri, 12 Jan 2007 05:02:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H5JF8-0006Nn-Lz
	for enum@ietf.org; Fri, 12 Jan 2007 05:02:38 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5JF7-0001Ln-V2
	for enum@ietf.org; Fri, 12 Jan 2007 05:02: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] I-D ACTION:draft-ietf-enum-unused-00.txt
Date: Fri, 12 Jan 2007 11:01:55 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D463C54A7@oefeg-s04.oefeg.loc>
In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0E78EB65@ACCLUST02EVS1.ugd.att.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Thread-Index: Acc1wiyCBLlbqIZ9Ss2fR97JHAinuAAA7CaQAAORZ3AAFe4+QA==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Pfautz, Penn L, GBLAM" <ppfautz@att.com>, "IETF ENUM WG" <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Penn,

thank you for your comments

> I guess I have a lot of questions about this document.

Some answers
>=20
> 1. How does this relate to "void"? Is it replacing it or doing
something
> else?

It is replacing "void". We thought this was clear after the 100+ e-mails
exchanged in November. We originally planned to call the draft
draft-ietf-enum-void-03 and only change the Enumservice to "unused",
but because we changed the I-D extensively, it
was also agreed in San Diego with the co-chairs to rename
it to draft-ietf-enum-unused-00 and do another WGLC.

>=20
> 2. The draft seems directed to user ENUM and, as such, I'm not sure
this
> is the right place for information not about user registrations which
at
> least part of this (unassigned numbers, unallocated ranges) seems to
be.
> There is an implicit burden placed on Service Providers and NRAs that
> not all will find acceptable. I think we're crossing the streams here.

When "void" was started, there was only user ENUM. Since there is
no distinction yet between Enumservices for user and infrastructure
ENUM, "unused" may be used in both also (and in private ENUMs)

We see the usage mainly in Infrastructure ENUM, where it may be used
by carriers. We do not think that carriers will provide unassigned
numbers
in User ENUM. It will definitely be used and useful in private ENUMs.

In user ENUM it may be used by NRAs for unallocated ranges and it
will be needed for "ENUM only" ranges
>=20
> 3. I still have problems seeing the problem. We're talking about calls
> to numbers that aren't in service. Unless the caller is a spammer (in
> which case, why help them?) isn't it just an error that won't be
> repeated when the call goes the PSTN and an error message is provided?
> How frequent will these calls be?

Of course, now it is a matter of efficiency. And finally, you need
something if there is no PSTN.

> BTW, I've not convinced about the looping issue. Shouldn't the gateway
> to which call to ENUM-only ranges would be routed provide a "not in
> service" message?

And how does the gateway know when to provide a "not in service
message"?
You are assuming that there is a dedicated gateway for a given number
range
We are assuming that a gateway may serve potentially all number ranges.

>=20
> 4. Re security, I think there should be an acknowledgement that this
> approach would support identification of unpublished numbers in the
> Security section rather than a vague reference to conditions in 7.4.
I'm
> pretty sure my NRA would NOT want this implemented.

We will think about this

>=20
> 5. In 7.4 case 3 the fallback seems to imply the SP will provision a
> capability record indicating the services it provides for the block if
> the user doesn't choose to register. If this is user ENUM why do this?

Lawrence? I think this is the case for the UK variant?
>=20
> 6. Finally some nits: 7.3.2 has a reference to RFC 308 rather than
2308

Thanks

> and the statement in 7.2.1.1 that fixed numbering plans typically
> require the full number to be dialed is not true, at least in the
NANP.
> A number of US states will give up their 7-digit home NPA dialing over
> their (or more likely your) dead body :-)

Typically is not all

>=20
> Maybe it's late in the day and I just need a drink...
>=20
> Happy New Year
>=20
> Penn
>=20
> -----Original Message-----
> From: Richard Shockey [mailto:richard@shockey.us]
> Sent: Thursday, January 11, 2007 4:19 PM
> To: 'IETF ENUM WG'
> Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
>=20
>=20
>=20
> Folks I hope we can have a through review of this document in the
> upcoming
> weeks this is a very useful document to folks and I can see going to
> WGLC
> very quickly on this.
>=20
>=20
>=20
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Thursday, January 11, 2007 3:50 PM
> > To: i-d-announce@ietf.org
> > Cc: enum@ietf.org
> > Subject: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Telephone Number Mapping Working
> Group of
> > the IETF.
> >
> > 	Title		: IANA Registration for Enumservice UNUSED
> > 	Author(s)	: R. Stastny, et al.
> > 	Filename	: draft-ietf-enum-unused-00.txt
> > 	Pages		: 26
> > 	Date		: 2007-1-11
> >
> >    This document registers the Enumservice "unused" using the URI
> scheme
> >    "data:" as per the IANA registration process defined in the ENUM
> >    specification, RFC 3761.  This Enumservice may be used to
indicate
> >    that the E.164 number (or E.164 number range) tied to the domain
in
> >    which the enclosing NAPTR is published is not allocated or
assigned
> >    for communications service.  When such an indication is provided,
> an
> >    ENUM client can detect calls that will fail "early".
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-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-unused-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-unused-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.
>=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


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



From enum-bounces@ietf.org Fri Jan 12 07:08:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5LBm-0001EU-V6; Fri, 12 Jan 2007 07:07:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LBm-0001CE-9o
	for enum@ietf.org; Fri, 12 Jan 2007 07:07:18 -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 1H5LBk-0007zB-Hw
	for enum@ietf.org; Fri, 12 Jan 2007 07:07:18 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by insensate.co.uk (Postfix) with ESMTP id 6FFBD94CAA;
	Fri, 12 Jan 2007 12:07:13 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7558EAB5-7E41-41B3-AB18-1679C5383D4C@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Date: Fri, 12 Jan 2007 12:07:13 +0000
To: NEO Pfautz Penn L <ppfautz@att.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: IETF ENUM WG <enum@ietf.org>, Richard Stastny <richard.stastny@oefeg.at>
Subject: [Enum] Re: Unused-00
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Penn, Richard, folks,
  I also appreciate the comments. I trust you did get a drink after  
reading this.
-------------
Re. 3.5 (The gateway loop issue) -
There are gateways that try to place calls to VoIP end points using  
ENUM already.
Such gateways may not be aware of the entire numbering plans around  
the world.
It is not possible for such an "unaware" gateway to know what case it  
is handling.
Provisioning NAPTRs as proposed gives it that knowledge.

The loop need not be with a single unit. We have seen a different  
gateway selected
by a "drop back" to the PSTN, followed by an attempt to direct a call  
to an endpoint
via ENUM. The second gateway instance does not know that the first  
unit has tried
ENUM and dropped back to the PSTN. Such "extended" loops do occur.  
They can be
avoided if 'unused' are provisioned as we recommend.
-------------

Re. 7.4 (information leakage)
In our defence, I should point out that the last paragraph in 7.1 was  
originally
a separate sub-section, covering the different choices that NRAs can  
and have made.
We had feedback from our in-house reviewers that this did not help  
(and made the
document even longer), so we trimmed it to just the important case -  
you may not
be allowed to publish data that allows such leakage.

We also put this in as the first condition for provisioning cases 2,  
3 to help
it "stand out".

The paragraph in section 7.1 and those conditions in 7.4 don't seem  
vague or hidden
to me (or to my in-house reviewers). If anyone has text he/she finds  
clearer than
'the NRA allows identification of unused/"in service" numbers' then  
please feel
free to propose it.

Usually the security section of an RFC concerns the security of the  
protocol
rather than the operational issues (I know - we have had comments on  
that with
other documents). That's why this important issue is the  
"operational" section.

If people (including the AD and IESG who have to read all this stuff)  
are happy
for this issue and its needed context/ explanation to be added to the  
security
considerations section as well then I'm happy.

-------------

Re. 7.4 cases 2 and 3 - This draft tries to cover all of the possible  
cases.
Where the CSP is not allowed to or will not provision each of the  
ENUM domains,
the alternative allows the Client to know what capability to try  
rather than guess.
The short answer is yes.

<CRUE>
With apologies to our esteemed co-chair, one option being considered  
in the UK for
"user" ENUM is a hybrid scheme (called CRUE, for Carrier Registration  
in User ENUM).
It is designed to allow carriers to indicate how "user" ENUM clients  
should process
calls. Provisioning in this Block domain allows a carrier to indicate  
to clients
that do not have access to private or infrastructure schemes how they  
should handle
a call that has no specific ENUM registration for the number queried.

In this scheme, the end user device (or PBX, or whatever) making a  
call wants to
handle that call using ENUM information, if available. This client  
decides what
to do with the call, not just relying on the the originating  
carrier's choices.
The ENUM client may well be interested in user ENUM data, taking into  
account
the called subscriber's choices for appropriate communications (Cases  
4 or 5).

Where there is no ENUM registration for a number (Cases 2 or 3) the  
carrier
can indicate its preferred treatment for calls to that block of  
numbers. This
bypasses the originating carrier, as that may well not be considering  
"user"
ENUM queries in its call processing.

Note - using this alternative and provisioning a record in the Block  
domain
is a choice on the part of the CSP. Likewise, performing the second  
query is
a choice of the client.

For more information on CRUE, come to the pub next Wednesday (see  
Jim's earlier
email :).
</CRUE>

For open number plans, using a similar technique is also interesting.  
The
registrant for a number in such a plan may well configure such a  
record the
apex of its zone, allowing calling ENUM clients to know what to do if  
the number
queried does not have special treatment - for example, to deliver the  
call to the
SIP AoR associated with a receptionist.
-------------

all the best,
   Lawrence


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



From enum-bounces@ietf.org Fri Jan 12 23:30:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5aVw-0005ui-OI; Fri, 12 Jan 2007 23:29:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5aVu-0005tc-LS; Fri, 12 Jan 2007 23:29:06 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H5aVs-0002bo-Bi; Fri, 12 Jan 2007 23:29:06 -0500
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 12 Jan 2007 20:29:03 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0D4T2Ia012932; 
	Fri, 12 Jan 2007 20:29:02 -0800
Received: from [192.168.1.9] (sjc-vpn7-387.cisco.com [10.21.145.131])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0D4T2nF020709;
	Fri, 12 Jan 2007 20:29:02 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <F488C7FA-A0AB-44D2-A995-1A44AE183FF6@cisco.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: rai@ietf.org, avt@ietf.org, ECRIT <ecrit@ietf.org>, enum@ietf.org,
	mmusic@ietf.org, sigtran@ietf.org, simple@ietf.org, geopriv@ietf.org,
	ieprep@ietf.org, SIP <sip@ietf.org>, sipping@ietf.org,
	speechsc@ietf.org, speermint@ietf.org, xcon@ietf.org,
	RAI Chairs <rai-chairs@ietf.org>, RAI Discuss <rai-discuss@ietf.org>
From: Cullen Jennings <fluffy@cisco.com>
Date: Fri, 12 Jan 2007 20:28:52 -0800
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=484; t=1168662542;
	x=1169526542; c=relaxed/relaxed; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20New=20RAI=20mailing=20list=20formed |Sender:=20;
	bh=oy9hMDTAd3CLwx2VjaSlGDIiUGc4zeKQTh4WxAq1xfU=;
	b=nzE6bx99AfmpN9XXdKKYeMzdSrPYLU0XznGtkrDuKY24XeITEuEnaaVR9hz7VFmVb9njtbTr
	5VVkwN8evTl13ZapqifDuRHeokxVdDOoFkvhoDOAduovqFL7TFD5fRZC;
Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: [Enum] New RAI mailing list formed
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Please don't reply to this message so you don't cross post to all the  
groups.

A new mailing list for announcement and discussion of general topics  
of interest to RAI Area has been created. The list is rai@ietf.org

You can subscribe at:
https://www1.ietf.org/mailman/listinfo/rai
Or by sending email with a body containing "subscribe" to rai- 
request@ietf.org

Please do subscribe to it so you can find announcements for things  
like RAI BOFs.

Thanks,
Cullen & Jon


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



From enum-bounces@ietf.org Tue Jan 16 11:33:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H6rEb-0007zK-2B; Tue, 16 Jan 2007 11:32:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rEY-0007ya-HV
	for enum@ietf.org; Tue, 16 Jan 2007 11:32:27 -0500
Received: from rwcrmhc14.comcast.net ([204.127.192.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6rEU-0002A2-UP
	for enum@ietf.org; Tue, 16 Jan 2007 11:32:26 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc14) with ESMTP
	id <20070116163221m140036klqe>; Tue, 16 Jan 2007 16:32:22 +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 l0GGWKbM024463
	for <enum@ietf.org>; Tue, 16 Jan 2007 11:32:20 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0GGWKqh024459;
	Tue, 16 Jan 2007 11:32:20 -0500
Date: Tue, 16 Jan 2007 11:32:20 -0500
Message-Id: <200701161632.l0GGWKqh024459@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
X-Spam-Score: 0.2 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Subject: [Enum] draft-ietf-enum-unused-00.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

There are some exposition problems with this draft that should be
addressed.  They center around the description of numbering plans and
are rather confusing to the naive reader.  For example, in section
7.2.1:

   7.2.1.  Closed Numbering Plans

   In many countries closed numbering plans are in use.  In such a
   scheme, all valid telephone numbers have a defined length - the
   number of digits used for the subscriber number is fixed.  Thus, for
   a given initial digit string, the length of the subsequent digit
   string together constituting a valid telephone number is known.  All
   other digit strings are invalid.

As I read this, it means that all E.164 nubmers for a particular
country have the same length.  E.g., in North America, a subscriber
number is 10 digits (or 11 if you count the country code).

   In these scenarios, a block of telephone numbers will be allocated to
   a service provider, and that provider will in turn assign individual
   telephone numbers for services it provides to end customers.
   Telephone numbers are of a defined length whether or not they are
   allocated or assigned.

So far, so good.

   For example, for the initial digit string "+44160649", the subsequent
   number string is three digits in length.  However, for the initial
   digit string "+44160650", the subsequent string is four digits in
   length.

At this point, I have a problem.  If one adds three digits to
"44160649" to make a number, then numbers have 11 digits.  But if one
adds four digits to "44160650", then numbers have 8 digits.

As far as I can tell, the solution to this contradiction is that
"subscriber number" refers to the digits that are after the block
prefix, and "initial digit string" refers to the digits that compose
the block prefix.

But that is not how people outside telephony think about E.164 numbers
-- to them, if you say "the number of digits used for the subscriber
number is fixed", they think you mean that all numbers in the country
code have the same length.  If you are using "subscriber number" in
this specialized way, make sure that you clearly define it as such
before using it.  (There is no preceeding use of "subscriber number"
in the draft.)

----

In section 7.2.2, the draft says "The only restriction is that all
these initial digit patterns representing telephone numbers are
unique."  I think this means "The only restriction is that no assigned
telephone number may be a prefix of another."

----

As far as I can tell from 7.2.2.1, under an open number plan, some
customers can be assigned prefixes, and the customer can select how
many digits are allowed after the prefix, and which of those sets of
digits are valid numbers.  That is, the customer is assigned a block
of numbers.  But 7.2.2 only speaks of assigning single numbers to
customers:  "Typically, it allocates number blocks from within this
range to providers, who will in turn assign telephone numbers to their
customers."

----

There is also the question of how this infrastructure interacts with
number portability, which leads to situations where any given range of
numbers is likely to be a mosaic of assignments to different carriers.

Dale

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



From enum-bounces@ietf.org Tue Jan 16 12:49:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H6sQZ-0004CJ-Gh; Tue, 16 Jan 2007 12:48:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sQX-0004BN-ME
	for enum@ietf.org; Tue, 16 Jan 2007 12:48:53 -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 1H6sQQ-0007mT-PL
	for enum@ietf.org; Tue, 16 Jan 2007 12:48:52 -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 Wed, 17 Jan 2007 02:49:09 +0900
	by nida.or.kr with ESMTP CrediShield
X-MAIL-FROM: jhlim@nida.or.kr
Received: from userbase (localhost [127.0.0.1])
	by mail.nic.or.kr (v3smtp 8.11.6.9/8.11.0) with SMTP id l0GHlsV23679;
	Wed, 17 Jan 2007 02:48:04 +0900 (KST)
Message-ID: <001401c73996$84448870$c432a8c0@userbase>
From: "JoonHyung Lim" <jhlim@nida.or.kr>
To: <Richard.Stastny@oefeg.at>, <enum@ietf.org>
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 02:48:12 +0900
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0158469983=="
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0158469983==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0011_01C739E1.EDBCB2A0"

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C739E1.EDBCB2A0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGksDQoNCkZpcnN0IG9mIGFsbCwgSSdtIGdsYWQgdG8gcmVhZCB0aGlzIGRyYWZ0IGJlY2F1c2Ug
SSdtIG5vdyBkZWFsaW5nIHdpdGggYWxtb3N0IHNhbWUgc2NlbmFyaW8gb2YgUmNvZGUgYXMgeW91
IHdyb3RlIGluIHNlY3Rpb24zLCBmb3IgcmV2aXNpbmcgZHJhZnQoZHJhZnQtbGltLWtpbS1lbnVt
LWJhc2VkLXNvZnRzd2l0Y2gtMDAudHh0KSB0aGF0IEkgc3VibWl0dGVkIG9uIGxhc3QgbWVldGlu
ZyBhcyBhIGFnZW5kYS4gQWNjb3JkaW5nIHRvIG91ciB0cmlhbCBleHBlcmllbmNlLCBJIHRoaW5r
IHRoaXMgZHJhZnQgd2lsbCBiZSB1c2VmdWwgZm9yIGluZnJhc3RydWN0dXJlIEVOVU0uIA0KDQoN
Cj4+IEJUVywgSSd2ZSBub3QgY29udmluY2VkIGFib3V0IHRoZSBsb29waW5nIGlzc3VlLiBTaG91
bGRuJ3QgdGhlIGdhdGV3YXkNCj4+IHRvIHdoaWNoIGNhbGwgdG8gRU5VTS1vbmx5IHJhbmdlcyB3
b3VsZCBiZSByb3V0ZWQgcHJvdmlkZSBhICJub3QgaW4NCj4+IHNlcnZpY2UiIG1lc3NhZ2U/DQoN
Cj5BbmQgaG93IGRvZXMgdGhlIGdhdGV3YXkga25vdyB3aGVuIHRvIHByb3ZpZGUgYSAibm90IGlu
IHNlcnZpY2UNCj5tZXNzYWdlIj8NCj5Zb3UgYXJlIGFzc3VtaW5nIHRoYXQgdGhlcmUgaXMgYSBk
ZWRpY2F0ZWQgZ2F0ZXdheSBmb3IgYSBnaXZlbiBudW1iZXINCj5yYW5nZQ0KPldlIGFyZSBhc3N1
bWluZyB0aGF0IGEgZ2F0ZXdheSBtYXkgc2VydmUgcG90ZW50aWFsbHkgYWxsIG51bWJlciByYW5n
ZXMuDQoNCg0KSW4gc2VjdGlvbjMuNSwgSWYgSSdtIHJpZ2h0LCBJIGZlZWwgdGhpcyBzZWVtcyBm
b2N1c2VkIG9uIHNvLWNhbGxlZCAiZ2VuZXJpYyBnYXRld2F5IiBmb3IgKzQzNzgwIGNhc2UgYXMg
ZGVzY3JpYmVkIG9uIGVudW0uYXQgc2l0ZS4gSSBhZ3JlZSB0aGlzIGlzIGdvb2QgZXhhbXBsZSB3
aGljaCBtYWtlcyBwZW9wbGUgdW5kZXJzdGFuZCB3aHkgInVudXNlZCIgZW51bXNlcnZpY2UgdHlw
ZSBuZWVkZWQsIGFuZCB3aHkgZGVmYXVsdCBzdHJhdGVneSBkb2Vzbid0IHdvcmsgaW4gdGhpcyBj
b25kaXRpb24uIGhvd2V2ZXIgSSB0aGluayB0aGVyZSBtaWdodCBiZSBhIG1pc3VuZGVyc3RhbmRp
bmcgdGhhdCAidW51c2VkIiBlbnVtc2VydmljZSB0eXBlIGlzIG9ubHkgdXNlZCBmb3IgZGVkaWNh
dGVkIGdhdGV3YXkgZm9yIGdpdmVuIG51bWJlci4NCg0KU28sIEkgdGhpbmsgaWYgeW91IGFkZCBz
b21lIGNvbW1lbnRzIGFib3V0IGxvb3BpbmcgaW4gY2FzZSBvZiBhbGwgbnVtYmVyIHJhbmdlcyBh
ZG9wdGVkIG9uIGdhdGV3YXksIG9uIGVuZCBvZiBzZWN0aW9uIDMuNSwgbW90aXZhdGlvbiBvZiBk
cmFmdCB3aWxsIGJlIG1vcmUgZ2VuZXJpYy4gDQoNCmp1c3Qgb3Bpbmlvbi4NCg0KUmVnYXJkcy4N
Cg0KSm9vbkh5dW5nIExpbSwgTklEQQ==

------=_NextPart_000_0011_01C739E1.EDBCB2A0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA2LjAwLjU3MzAuMTEiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF
QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9VGFob21hPkhpLDwv
Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+PC9GT05UPiZuYnNwOzwvRElWPg0K
PERJVj48Rk9OVCBmYWNlPVRhaG9tYT5GaXJzdCBvZiBhbGwsIEknbSBnbGFkIHRvIHJlYWQgdGhp
cyBkcmFmdCBiZWNhdXNlIA0KSSdtJm5ic3A7bm93IGRlYWxpbmcgd2l0aCBhbG1vc3Qgc2FtZSBz
Y2VuYXJpbyBvZiBSY29kZSBhcyB5b3Ugd3JvdGUgaW4gDQpzZWN0aW9uMywgZm9yJm5ic3A7cmV2
aXNpbmcgZHJhZnQoZHJhZnQtbGltLWtpbS1lbnVtLWJhc2VkLXNvZnRzd2l0Y2gtMDAudHh0KSAN
CnRoYXQgSSBzdWJtaXR0ZWQgb24gbGFzdCBtZWV0aW5nIGFzIGEgYWdlbmRhLiZuYnNwO0FjY29y
ZGluZyB0byBvdXIgdHJpYWwgDQpleHBlcmllbmNlLCBJIHRoaW5rJm5ic3A7dGhpcyBkcmFmdCB3
aWxsIGJlIHVzZWZ1bCBmb3IgaW5mcmFzdHJ1Y3R1cmUgRU5VTS4gDQo8L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIGZhY2U9VGFob21hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6
ZT0yPjwvRk9OVD48Rk9OVCBzaXplPTI+PC9GT05UPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQg
DQpzaXplPTI+PC9GT05UPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD48
QlI+PEZPTlQgDQpmYWNlPVRhaG9tYT4mZ3Q7Jmd0OyBCVFcsIEkndmUgbm90IGNvbnZpbmNlZCBh
Ym91dCB0aGUgbG9vcGluZyBpc3N1ZS4gU2hvdWxkbid0IA0KdGhlIGdhdGV3YXk8QlI+Jmd0OyZn
dDsgdG8gd2hpY2ggY2FsbCB0byBFTlVNLW9ubHkgcmFuZ2VzIHdvdWxkIGJlIHJvdXRlZCANCnBy
b3ZpZGUgYSAibm90IGluPEJSPiZndDsmZ3Q7IHNlcnZpY2UiIG1lc3NhZ2U/PEJSPjxCUj4mZ3Q7
QW5kIGhvdyBkb2VzIHRoZSANCmdhdGV3YXkga25vdyB3aGVuIHRvIHByb3ZpZGUgYSAibm90IGlu
IHNlcnZpY2U8QlI+Jmd0O21lc3NhZ2UiPzxCUj4mZ3Q7WW91IGFyZSANCmFzc3VtaW5nIHRoYXQg
dGhlcmUgaXMgYSBkZWRpY2F0ZWQgZ2F0ZXdheSBmb3IgYSBnaXZlbiANCm51bWJlcjxCUj4mZ3Q7
cmFuZ2U8QlI+Jmd0O1dlIGFyZSBhc3N1bWluZyB0aGF0IGEgZ2F0ZXdheSBtYXkgc2VydmUgcG90
ZW50aWFsbHkgDQphbGwgbnVtYmVyIHJhbmdlcy48QlI+PEJSPjwvRk9OVD48L0RJVj4NCjxESVY+
PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9VGFob21hIHNpemU9Mz5JbiBzZWN0aW9uMy41LCBJZiBJ
J20gcmlnaHQsIEkgZmVlbCANCnRoaXMgc2VlbXMgZm9jdXNlZCBvbiBzby1jYWxsZWQgImdlbmVy
aWMgZ2F0ZXdheSIgZm9yICs0Mzc4MCBjYXNlIGFzIGRlc2NyaWJlZCANCm9uIGVudW0uYXQgc2l0
ZS4gSSBhZ3JlZSB0aGlzIGlzIGdvb2QgZXhhbXBsZSB3aGljaCBtYWtlcyBwZW9wbGUgdW5kZXJz
dGFuZCANCndoeSZuYnNwOyJ1bnVzZWQiIGVudW1zZXJ2aWNlIHR5cGUgbmVlZGVkLCBhbmQgd2h5
IGRlZmF1bHQgc3RyYXRlZ3kgZG9lc24ndCB3b3JrIA0KaW4gdGhpcyBjb25kaXRpb24uIGhvd2V2
ZXIgSSB0aGluayB0aGVyZSZuYnNwO21pZ2h0Jm5ic3A7YmUgYSBtaXN1bmRlcnN0YW5kaW5nIA0K
dGhhdCAidW51c2VkIiBlbnVtc2VydmljZSB0eXBlIGlzIG9ubHkgdXNlZCBmb3IgZGVkaWNhdGVk
IGdhdGV3YXkgZm9yIGdpdmVuIA0KbnVtYmVyLjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG
T05UIHNpemU9Mj48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTM+PC9GT05UPjwvRk9OVD4mbmJzcDs8
L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9VGFob21hIHNpemU9Mz5TbywgSSB0
aGluayBpZiB5b3UgYWRkIHNvbWUgDQpjb21tZW50cyZuYnNwO2Fib3V0IGxvb3BpbmcgaW4gY2Fz
ZSBvZiBhbGwgbnVtYmVyIHJhbmdlcyBhZG9wdGVkIG9uIGdhdGV3YXksIA0Kb248L0ZPTlQ+PC9G
T05UPjxGT05UIHNpemU9Mj48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTM+IGVuZCBvZiBzZWN0aW9u
IDMuNSwgDQo8L0ZPTlQ+PC9GT05UPjxGT05UIGZhY2U9VGFob21hPm1vdGl2YXRpb24gb2YgZHJh
ZnQgd2lsbCBiZSBtb3JlIGdlbmVyaWMuIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl
PVRhaG9tYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VGFob21hPmp1c3Qg
b3Bpbmlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VGFob21hPjwvRk9OVD4mbmJz
cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+UmVnYXJkcy48L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIGZhY2U9VGFob21hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj
ZT1UYWhvbWE+Sm9vbkh5dW5nIExpbSwgTklEQTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0011_01C739E1.EDBCB2A0--




--===============0158469983==
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

--===============0158469983==--






From enum-bounces@ietf.org Tue Jan 16 13:36:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H6tAF-0005Ks-1N; Tue, 16 Jan 2007 13:36:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tAD-0005Kg-2a
	for enum@ietf.org; Tue, 16 Jan 2007 13:36:05 -0500
Received: from mail146.messagelabs.com ([216.82.245.131])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6tA9-0007RB-MT
	for enum@ietf.org; Tue, 16 Jan 2007 13:36:05 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-14.tower-146.messagelabs.com!1168972558!829595!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 21481 invoked from network); 16 Jan 2007 18:35:58 -0000
Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4)
	by server-14.tower-146.messagelabs.com with SMTP;
	16 Jan 2007 18:35:58 -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 l0GIZvvc011205; 
	Tue, 16 Jan 2007 13:35:58 -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 l0GIZlW8011105; 
	Tue, 16 Jan 2007 13:35:49 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Date: Tue, 16 Jan 2007 13:35:35 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0E8088E5@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <001401c73996$84448870$c432a8c0@userbase>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Thread-Index: Acc5ltODh8IgadO5SZmQxuwHDP9hVQABagqw
From: "Pfautz, Penn L, GBLAM" <ppfautz@att.com>
To: "JoonHyung Lim" <jhlim@nida.or.kr>, <Richard.Stastny@oefeg.at>,
	<enum@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1859231217=="
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1859231217==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7399D.1D795EAB"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7399D.1D795EAB
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I think I understand the arguments for the need for this for ENUM only
ranges, at least as things have been implemented. Otherwise I don't see
looping as an issue.
I would caution folks not to assume this capability will be implemented
universally, even if infrastructure ENUM, especially if publicly
queryable.

________________________________

From: JoonHyung Lim [mailto:jhlim@nida.or.kr]=20
Sent: Tuesday, January 16, 2007 12:48 PM
To: Richard.Stastny@oefeg.at; enum@ietf.org
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt


Hi,
=20
First of all, I'm glad to read this draft because I'm now dealing with
almost same scenario of Rcode as you wrote in section3, for revising
draft(draft-lim-kim-enum-based-softswitch-00.txt) that I submitted on
last meeting as a agenda. According to our trial experience, I think
this draft will be useful for infrastructure ENUM.=20
=20

>> BTW, I've not convinced about the looping issue. Shouldn't the
gateway
>> to which call to ENUM-only ranges would be routed provide a "not in
>> service" message?

>And how does the gateway know when to provide a "not in service
>message"?
>You are assuming that there is a dedicated gateway for a given number
>range
>We are assuming that a gateway may serve potentially all number ranges.


In section3.5, If I'm right, I feel this seems focused on so-called
"generic gateway" for +43780 case as described on enum.at site. I agree
this is good example which makes people understand why "unused"
enumservice type needed, and why default strategy doesn't work in this
condition. however I think there might be a misunderstanding that
"unused" enumservice type is only used for dedicated gateway for given
number.
=20
So, I think if you add some comments about looping in case of all number
ranges adopted on gateway, on end of section 3.5, motivation of draft
will be more generic.=20
=20
just opinion.
=20
Regards.
=20
JoonHyung Lim, NIDA

------_=_NextPart_001_01C7399D.1D795EAB
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D586053118-16012007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I think I understand the arguments for the need =
for this=20
for ENUM only ranges, at least as things have been implemented. =
Otherwise&nbsp;I=20
don't see looping as an issue.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D586053118-16012007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I would caution folks not to assume this =
capability will be=20
implemented universally, even if infrastructure ENUM, especially if =
publicly=20
queryable.</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> JoonHyung Lim =
[mailto:jhlim@nida.or.kr]=20
<BR><B>Sent:</B> Tuesday, January 16, 2007 12:48 PM<BR><B>To:</B>=20
Richard.Stastny@oefeg.at; enum@ietf.org<BR><B>Subject:</B> RE: [Enum] =
I-D=20
ACTION:draft-ietf-enum-unused-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma>Hi,</FONT></DIV>
<DIV><FONT face=3DTahoma></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma>First of all, I'm glad to read this draft =
because=20
I'm&nbsp;now dealing with almost same scenario of Rcode as you wrote in=20
section3, for&nbsp;revising =
draft(draft-lim-kim-enum-based-softswitch-00.txt)=20
that I submitted on last meeting as a agenda.&nbsp;According to our =
trial=20
experience, I think&nbsp;this draft will be useful for infrastructure =
ENUM.=20
</FONT></DIV>
<DIV><FONT face=3DTahoma></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT><FONT size=3D2></FONT><FONT =
size=3D2></FONT><FONT=20
size=3D2></FONT><FONT size=3D2></FONT><FONT size=3D2></FONT><BR><FONT=20
face=3DTahoma>&gt;&gt; BTW, I've not convinced about the looping issue. =
Shouldn't=20
the gateway<BR>&gt;&gt; to which call to ENUM-only ranges would be =
routed=20
provide a "not in<BR>&gt;&gt; service" message?<BR><BR>&gt;And how does =
the=20
gateway know when to provide a "not in =
service<BR>&gt;message"?<BR>&gt;You are=20
assuming that there is a dedicated gateway for a given=20
number<BR>&gt;range<BR>&gt;We are assuming that a gateway may serve =
potentially=20
all number ranges.<BR><BR></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DTahoma size=3D3>In section3.5, If I'm =
right, I feel=20
this seems focused on so-called "generic gateway" for +43780 case as =
described=20
on enum.at site. I agree this is good example which makes people =
understand=20
why&nbsp;"unused" enumservice type needed, and why default strategy =
doesn't work=20
in this condition. however I think there&nbsp;might&nbsp;be a =
misunderstanding=20
that "unused" enumservice type is only used for dedicated gateway for =
given=20
number.</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DTahoma =
size=3D3></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DTahoma size=3D3>So, I think if you add =
some=20
comments&nbsp;about looping in case of all number ranges adopted on =
gateway,=20
on</FONT></FONT><FONT size=3D2><FONT face=3DTahoma size=3D3> end of =
section 3.5,=20
</FONT></FONT><FONT face=3DTahoma>motivation of draft will be more =
generic.=20
</FONT></DIV>
<DIV><FONT face=3DTahoma></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma>just opinion.</FONT></DIV>
<DIV><FONT face=3DTahoma></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma>Regards.</FONT></DIV>
<DIV><FONT face=3DTahoma></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma>JoonHyung Lim, NIDA</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C7399D.1D795EAB--


--===============1859231217==
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

--===============1859231217==--




From enum-bounces@ietf.org Tue Jan 16 17:40:06 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H6wxq-0004So-Ho; Tue, 16 Jan 2007 17:39:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wxp-0004Si-DU
	for enum@ietf.org; Tue, 16 Jan 2007 17:39:33 -0500
Received: from mx4.nominet.org.uk ([213.248.199.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wxk-0006Qy-Um
	for enum@ietf.org; Tue, 16 Jan 2007 17:39:33 -0500
Received: from unknown (HELO notes1.nominet.org.uk) ([213.248.197.128])
	by mx4.nominet.org.uk with ESMTP; 16 Jan 2007 22:39:26 +0000
X-IronPort-AV: i="4.13,198,1167609600"; d="scan'208"; a="6241301:sNHT38633760"
In-Reply-To: <7558EAB5-7E41-41B3-AB18-1679C5383D4C@insensate.co.uk>
To: IETF ENUM WG <enum@ietf.org>
Subject: Re: [Enum] Re: Unused-00 - CRUE
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V702MAC_11052006 November 05, 2006
Message-ID: <OF4155CAFE.FE9CF90B-ON80257265.007C0BEC-80257265.007C755D@nominet.org.uk>
From: Jay Daley <jay@nominet.org.uk>
Date: Tue, 16 Jan 2007 22:39:25 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25,
	2006) at 16/01/2007 10:39:25 PM,
	Serialize complete at 16/01/2007 10:39:25 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: lconroy <lconroy@insensate.co.uk>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

lconroy <lconroy@insensate.co.uk> wrote on 12/01/2007 12:07:13:

> For more information on CRUE, come to the pub next Wednesday (see 
> Jim's earlier
> email :).
> </CRUE>

Those of you who cannot make it can get the CRUE document here:

        http://download.nominet.org.uk/ENUM/CRUEv7.pdf

Jay Daley
Nominet UK

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



From enum-bounces@ietf.org Tue Jan 16 18:25:57 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H6xg9-0000zc-Uq; Tue, 16 Jan 2007 18:25:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xg9-0000zW-B8
	for enum@ietf.org; Tue, 16 Jan 2007 18:25:21 -0500
Received: from mx3.nominet.org.uk ([213.248.199.23])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6xg8-0006px-1s
	for enum@ietf.org; Tue, 16 Jan 2007 18:25:21 -0500
Received: from unknown (HELO notes1.nominet.org.uk) ([213.248.197.128])
	by mx3.nominet.org.uk with ESMTP; 16 Jan 2007 23:25:17 +0000
X-IronPort-AV: i="4.13,198,1167609600"; d="scan'208"; a="6755299:sNHT39261444"
In-Reply-To: <20070104164240.GN98464@finch-staff-1.thus.net>
To: "Clive D.W. Feather" <clive@demon.net>
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V702MAC_11052006 November 05, 2006
Message-ID: <OF7ED1E7E2.91F61A7C-ON80257265.007F674E-80257265.0080A80F@nominet.org.uk>
From: Jay Daley <jay@nominet.org.uk>
Date: Tue, 16 Jan 2007 23:25:16 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25,
	2006) at 16/01/2007 11:25:16 PM,
	Serialize complete at 16/01/2007 11:25:16 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: enum@ietf.org, lconroy <lconroy@insensate.co.uk>, "Livingood,
	Jason" <Jason_Livingood@cable.comcast.com>, rich.shockey@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Clive

"Clive D.W. Feather" <clive@demon.net> wrote on 04/01/2007 16:42:40:

> lconroy said:
> >  I am unaware of a formal written opinion from the Information
> > Commissioner on this matter.
> 
> I'm not sure if it's formal and written, but I know that the OIC has
> expressed this opinion. I'll see if I can track it down.

No need to track it down as I was in the room when the opinion was given. 
It was clearly stated as an opinion from OfCom (the UK telecoms regulator) 
that OIC (the UK data protection people) deferred to.

The view was - currently the identification of a provider for a particular 
consumer number is not trivial, and if the number is ported then 
potentially requires significant industry knowledge.  If the provider name 
were part of the SIP URL then this would be trivial and so would need 
end-user consent, along with all other PII.  However this was only a 
matter of moving from not trivial to trivial and so could be avoided by 
using a non-trivial URL.  They went on to say that if a WHOIS lookup were 
required to make the connection between the SIP URL and the provider then 
this was not trivial and so there would not be a problem.

I argued (quite strongly) that for a technical person the distinction 
between trivial and non-trivial in this issue was very fine.  However the 
view of the regulator was that it was about how trivial/non-trivial it was 
for the average person in the street, not a technical person.

Strange I know, but it is something we are constrained by.  Personally I 
do not think the text in the draft needs to change as a result.

Jay Daley
Nominet UK

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



From enum-bounces@ietf.org Wed Jan 17 03:38:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H76IN-00079O-W1; Wed, 17 Jan 2007 03:37:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H76IM-000792-6g
	for enum@ietf.org; Wed, 17 Jan 2007 03:37:22 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H76IH-0002Vr-On
	for enum@ietf.org; Wed, 17 Jan 2007 03:37:22 -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 l0H8bGtl006218Wed, 17 Jan 2007 08:37:16 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H76IF-0009MH-00; Wed, 17 Jan 2007 08:37:15 +0000
Date: Wed, 17 Jan 2007 08:37:15 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: Dale.Worley@comcast.net
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070117083715.GA32449@finch-staff-1.thus.net>
References: <200701161632.l0GGWKqh024459@dragon.ariadne.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200701161632.l0GGWKqh024459@dragon.ariadne.com>
User-Agent: Mutt/1.5.3i
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Dale.Worley@comcast.net said:
>    7.2.1.  Closed Numbering Plans
> 
>    In many countries closed numbering plans are in use.  In such a
>    scheme, all valid telephone numbers have a defined length - the
>    number of digits used for the subscriber number is fixed.  Thus, for
>    a given initial digit string, the length of the subsequent digit
>    string together constituting a valid telephone number is known.  All
>    other digit strings are invalid.
> 
> As I read this, it means that all E.164 nubmers for a particular
> country have the same length.

No. It says that the first N digits (for some value of N which may depend
on the number) tells you how long the number is.

For example, in the UK, +442 or +447 tells you there is another 9 digits
to come, but +441 or +448 doesn't - the length depends on more digits.

> E.g., in North America, a subscriber
> number is 10 digits (or 11 if you count the country code).

Apparently not. I am told that numbers beginning +109 are a digit longer.

>    For example, for the initial digit string "+44160649", the subsequent
>    number string is three digits in length.  However, for the initial
>    digit string "+44160650", the subsequent string is four digits in
>    length.
> 
> At this point, I have a problem.  If one adds three digits to
> "44160649" to make a number, then numbers have 11 digits.  But if one
> adds four digits to "44160650", then numbers have 8 digits.

12 digits, you mean.

> As far as I can tell, the solution to this contradiction is that
> "subscriber number" refers to the digits that are after the block
> prefix, and "initial digit string" refers to the digits that compose
> the block prefix.

Right. The meaning of "block" varies - in the UK, the longest such is (I
think) +44845464N, where there are no subsequent digits if N is 7 but 2
otherwise.

> In section 7.2.2, the draft says "The only restriction is that all
> these initial digit patterns representing telephone numbers are
> unique."  I think this means "The only restriction is that no assigned
> telephone number may be a prefix of another."

Right.

> As far as I can tell from 7.2.2.1, under an open number plan, some
> customers can be assigned prefixes, and the customer can select how
> many digits are allowed after the prefix, and which of those sets of
> digits are valid numbers.

Not just that: the customer can select which suffices are valid *and these
can be different lengths*. In other words, if I am allocated +99923456
(I use +999 because I don't know of a valid example) I can decide that
the valid numbers are:

  +999 23456 0
  +999 23456 1x
  +999 23456 2xxx
  +999 23456 4xx

> There is also the question of how this infrastructure interacts with
> number portability, which leads to situations where any given range of
> numbers is likely to be a mosaic of assignments to different carriers.

Do you mean open plans, or in general? I can't speak to open plans, but at
least in the UK portability is unrelated to number length.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Wed Jan 17 04:43:29 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H77Jb-0006br-OD; Wed, 17 Jan 2007 04:42:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H77Ja-0006bl-As
	for enum@ietf.org; Wed, 17 Jan 2007 04:42:42 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H77JY-00033J-Dc
	for enum@ietf.org; Wed, 17 Jan 2007 04:42: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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 10:41:56 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469E4@oefeg-s04.oefeg.loc>
In-Reply-To: <20070117083715.GA32449@finch-staff-1.thus.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6Es1DvUarxlRRRzKH8f8QVJ4/RwAAVytQ
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Clive D.W. Feather" <clive@demon.net>,
	<Dale.Worley@comcast.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Thank you Clive, you answered all the questions already

One more clarification to your last reply:

> > There is also the question of how this infrastructure interacts with
> > number portability, which leads to situations where any given range
of
> > numbers is likely to be a mosaic of assignments to different
carriers.
>=20
> Do you mean open plans, or in general? I can't speak to open plans,
but at
> least in the UK portability is unrelated to number length.

In open numbering plans everything may be variable:

If one looks at the Figure B.1/E.164 - Addressing by an ISDN Number
in Rec. E.164 Annex B.3.2, the N(S)N part of an E.164 number is
divided in the NDC (Network Destination Code) and the SN (Subscriber
Number)

The SN is further divided in a Partial Number and what?

The reminder of the SN is not named, we in Austria call it
Pilot Number.

The Partial Numbers are used for DDI (Direct Dialling In)

>From this figure one can derive the following:

A full E.164 number is the Pilot Number + the Partial Number

In closed numbering plans the SN is fixed, so the fixed length
includes the Pilot Number + the Partial Number.

In open numbering plans such as in Austria (and Germany) both
the Pilot Number and the Partial Number can be variable length

The numbering ordinance from the regulator defines the length
of the Pilot Number and is very complicated:

The NDC is between 1 and 4 digits

A Pilot Number is 5 digits
EXCEPT:
In NDCs 316, 463, 512, 662, 732, 2236, 2252, 5572 and 7242=20
6 digits
in NDC 1 it is 7 digits

On request you may get more digits, up to 13 digits
in NDC 1, in all other NDC up to 14 digits (including CC)

Companies may also get shorter numbers, depending
on size of company (UNI) -1 or -2 digits

All this rules are only for Pilot numbers and
for Carriers
Any subscriber may add Partial Numbers behind the
Pilot Number (this was something we had to take over
from the old analog system)
The Operator (Carrier) does not know about the length
and structure of the Partial Numbers (=3D private number plan)

It is recommended the whole E.164 does not exceed
14 digits to make the number reachable internationally

Now to Number Portability (NP):

Only Pilot Numbers are portable. One cannot
port his company number with DDI to another
after retirement or leaving the company.

Additional Information:

Assume the Vienna E.164 Number +43 1 2345678-222

*43 is the CC
1 is the NDC
2345678-222 is the SN
+43 1 2345678 is the Pilot Number (portable)
222 is the Partial Number (DDI)
(Note: there may exist also an E.164
+43 1 2345678-3333

To reach the switchboard, you may dial
+43 1 2345678-0
BUT, you may also dial
+43 1 2345678

The call is terminated at the PBX and after
a time-out you fall back to the switch-board

You also fall back to the switchboard if
you under-dial or dial a non-existent partial number

All this makes a lot of fun with ENUM

Regards
Richard

> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net]
> Sent: Wednesday, January 17, 2007 9:37 AM
> To: Dale.Worley@comcast.net
> Cc: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>=20
> Dale.Worley@comcast.net said:
> >    7.2.1.  Closed Numbering Plans
> >
> >    In many countries closed numbering plans are in use.  In such a
> >    scheme, all valid telephone numbers have a defined length - the
> >    number of digits used for the subscriber number is fixed.  Thus,
for
> >    a given initial digit string, the length of the subsequent digit
> >    string together constituting a valid telephone number is known.
All
> >    other digit strings are invalid.
> >
> > As I read this, it means that all E.164 nubmers for a particular
> > country have the same length.
>=20
> No. It says that the first N digits (for some value of N which may
depend
> on the number) tells you how long the number is.
>=20
> For example, in the UK, +442 or +447 tells you there is another 9
digits
> to come, but +441 or +448 doesn't - the length depends on more digits.
>=20
> > E.g., in North America, a subscriber
> > number is 10 digits (or 11 if you count the country code).
>=20
> Apparently not. I am told that numbers beginning +109 are a digit
longer.
>=20
> >    For example, for the initial digit string "+44160649", the
subsequent
> >    number string is three digits in length.  However, for the
initial
> >    digit string "+44160650", the subsequent string is four digits in
> >    length.
> >
> > At this point, I have a problem.  If one adds three digits to
> > "44160649" to make a number, then numbers have 11 digits.  But if
one
> > adds four digits to "44160650", then numbers have 8 digits.
>=20
> 12 digits, you mean.
>=20
> > As far as I can tell, the solution to this contradiction is that
> > "subscriber number" refers to the digits that are after the block
> > prefix, and "initial digit string" refers to the digits that compose
> > the block prefix.
>=20
> Right. The meaning of "block" varies - in the UK, the longest such is
(I
> think) +44845464N, where there are no subsequent digits if N is 7 but
2
> otherwise.
>=20
> > In section 7.2.2, the draft says "The only restriction is that all
> > these initial digit patterns representing telephone numbers are
> > unique."  I think this means "The only restriction is that no
assigned
> > telephone number may be a prefix of another."
>=20
> Right.
>=20
> > As far as I can tell from 7.2.2.1, under an open number plan, some
> > customers can be assigned prefixes, and the customer can select how
> > many digits are allowed after the prefix, and which of those sets of
> > digits are valid numbers.
>=20
> Not just that: the customer can select which suffices are valid *and
these
> can be different lengths*. In other words, if I am allocated +99923456
> (I use +999 because I don't know of a valid example) I can decide that
> the valid numbers are:
>=20
>   +999 23456 0
>   +999 23456 1x
>   +999 23456 2xxx
>   +999 23456 4xx
>=20
> > There is also the question of how this infrastructure interacts with
> > number portability, which leads to situations where any given range
of
> > numbers is likely to be a mosaic of assignments to different
carriers.
>=20
> Do you mean open plans, or in general? I can't speak to open plans,
but at
> least in the UK portability is unrelated to number length.
>=20
> --
> Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495
> 6138
> Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051
> 9937
> Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973
377646
> THUS plc            |                            |
>=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 Jan 17 04:47:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H77Nm-0000rE-0B; Wed, 17 Jan 2007 04:47:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H77Nk-0000nm-QL
	for enum@ietf.org; Wed, 17 Jan 2007 04:47:00 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H77Ni-0003uh-OF
	for enum@ietf.org; Wed, 17 Jan 2007 04:47:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 10:46:23 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469E5@oefeg-s04.oefeg.loc>
In-Reply-To: <001401c73996$84448870$c432a8c0@userbase>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Thread-Index: Acc5lnovXmbG5lwNTbucseyGClpAogAhaN0A
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "JoonHyung Lim" <jhlim@nida.or.kr>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1410201580=="
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1410201580==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73A1C.59A193C4"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73A1C.59A193C4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>So, I think if you add some comments about looping in case of all
number ranges adopted on gateway, on end of section >3.5, motivation of
draft will be more generic.=20

=20

Thank you for the comment, we will include this in the next release

=20

Richard

=20

=20

________________________________

From: JoonHyung Lim [mailto:jhlim@nida.or.kr]=20
Sent: Tuesday, January 16, 2007 6:48 PM
To: Stastny Richard; enum@ietf.org
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt

=20

Hi,

=20

First of all, I'm glad to read this draft because I'm now dealing with
almost same scenario of Rcode as you wrote in section3, for revising
draft(draft-lim-kim-enum-based-softswitch-00.txt) that I submitted on
last meeting as a agenda. According to our trial experience, I think
this draft will be useful for infrastructure ENUM.=20

=20


>> BTW, I've not convinced about the looping issue. Shouldn't the
gateway
>> to which call to ENUM-only ranges would be routed provide a "not in
>> service" message?

>And how does the gateway know when to provide a "not in service
>message"?
>You are assuming that there is a dedicated gateway for a given number
>range
>We are assuming that a gateway may serve potentially all number ranges.

In section3.5, If I'm right, I feel this seems focused on so-called
"generic gateway" for +43780 case as described on enum.at site. I agree
this is good example which makes people understand why "unused"
enumservice type needed, and why default strategy doesn't work in this
condition. however I think there might be a misunderstanding that
"unused" enumservice type is only used for dedicated gateway for given
number.

=20

So, I think if you add some comments about looping in case of all number
ranges adopted on gateway, on end of section 3.5, motivation of draft
will be more generic.=20

=20

just opinion.

=20

Regards.

=20

JoonHyung Lim, NIDA


------_=_NextPart_001_01C73A1C.59A193C4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Gulim";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Gulim;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.E-MailFormatvorlage17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DDE link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Tahoma'>&gt;So, I think if you add some =
comments&nbsp;about
looping in case of all number ranges adopted on gateway, on end of =
section &gt;3.5,
motivation of draft will be more generic. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Tahoma'>Thank you for the comment, we will include =
this in
the next release<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:Tahoma'>Richard</span></font><span =
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3DGulim><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
JoonHyung Lim
[mailto:jhlim@nida.or.kr] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
16, 2007
6:48 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stastny Richard; =
enum@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [Enum] I-D
ACTION:draft-ietf-enum-unused-00.txt</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3DGulim><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span =
style=3D'font-size:12.0pt;
font-family:Tahoma'>Hi,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span =
style=3D'font-size:12.0pt;
font-family:Tahoma'>First of all, I'm glad to read this draft because
I'm&nbsp;now dealing with almost same scenario of Rcode as you wrote in
section3, for&nbsp;revising =
draft(draft-lim-kim-enum-based-softswitch-00.txt) that
I submitted on last meeting as a agenda.&nbsp;According to our trial
experience, I think&nbsp;this draft will be useful for infrastructure =
ENUM. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
face=3DGulim><span
style=3D'font-size:12.0pt'><br>
</span></font><font face=3DTahoma><span =
style=3D'font-family:Tahoma'>&gt;&gt; BTW,
I've not convinced about the looping issue. Shouldn't the gateway<br>
&gt;&gt; to which call to ENUM-only ranges would be routed provide a =
&quot;not
in<br>
&gt;&gt; service&quot; message?<br>
<br>
&gt;And how does the gateway know when to provide a &quot;not in =
service<br>
&gt;message&quot;?<br>
&gt;You are assuming that there is a dedicated gateway for a given =
number<br>
&gt;range<br>
&gt;We are assuming that a gateway may serve potentially all number =
ranges.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span =
style=3D'font-size:12.0pt;
font-family:Tahoma'>In section3.5, If I'm right, I feel this seems =
focused on
so-called &quot;generic gateway&quot; for +43780 case as described on =
enum.at
site. I agree this is good example which makes people understand
why&nbsp;&quot;unused&quot; enumservice type needed, and why default =
strategy
doesn't work in this condition. however I think there&nbsp;might&nbsp;be =
a
misunderstanding that &quot;unused&quot; enumservice type is only used =
for
dedicated gateway for given number.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span =
style=3D'font-size:12.0pt;
font-family:Tahoma'>So, I think if you add some comments&nbsp;about =
looping in
case of all number ranges adopted on gateway, on end of section 3.5, =
motivation
of draft will be more generic. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span =
style=3D'font-size:12.0pt;
font-family:Tahoma'>just opinion.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span =
style=3D'font-size:12.0pt;
font-family:Tahoma'>Regards.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTahoma><span =
style=3D'font-size:12.0pt;
font-family:Tahoma'>JoonHyung Lim, NIDA</span></font><o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C73A1C.59A193C4--


--===============1410201580==
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

--===============1410201580==--




From enum-bounces@ietf.org Wed Jan 17 05:04:09 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H77e4-0000QW-2a; Wed, 17 Jan 2007 05:03:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H77e2-0000Py-BF
	for enum@ietf.org; Wed, 17 Jan 2007 05:03:50 -0500
Received: from sirius.wcom.co.uk ([193.131.254.154]
	helo=sirius.emea.verizonbusiness.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77e0-0007aW-7u
	for enum@ietf.org; Wed, 17 Jan 2007 05:03:50 -0500
Received: from sirius.wcom.co.uk ([166.59.190.29] helo=sirius.emea.mci.com)
	by sirius.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H77dj-0001LT-P1; Wed, 17 Jan 2007 10:03:36 +0000
Received: from ocampa.emea.verizonbusiness.com (leste.wcom.co.uk
	[166.59.190.250]) by sirius.emea.mci.com (4.7.0.120) with ESMTP id ;
	Wed, 17 Jan 2007 10:03:10 GMT
Received: from ms-lon-exgw01.uk.mcilink.com ([170.127.78.40]
	helo=ms-lon-exgw01.emea.dsmain.com)
	by ocampa.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H77dO-0002Ok-6P; Wed, 17 Jan 2007 10:03:10 +0000
Received: by ms-lon-exgw01.uk.mcilink.com with Internet Mail Service
	(5.5.2657.72) id <ZYQDNBMG>; Wed, 17 Jan 2007 10:02:57 -0000
Message-ID: <CA3896DB5903C14EAAC9D8E91D1167CBCC76C6@ms-lon-exmb06.uk.mcilink.com>
From: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
To: "'Richard.Stastny@oefeg.at'" <Richard.Stastny@oefeg.at>,
	"'clive@demon.net'" <clive@demon.net>, "'Dale.Worley@comcast.net'"
	<Dale.Worley@comcast.net>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 10:02:54 -0000
X-Mailer: Internet Mail Service (5.5.2657.72)
MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40)
X-VZ-EMEA-Spam-Score: -499.5
	(---------------------------------------------------)
X-VZ-EMEA-Signature: 31ef6414b34af09378150588bdd19c5b
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a
Cc: "'enum@ietf.org'" <enum@ietf.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1461789381=="
Errors-To: enum-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1461789381==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73A1E.A7BE1075"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C73A1E.A7BE1075
Content-Type: text/plain;
	charset="UTF-8"

Richard,

DDI being suffix to national numbering schema expected rather than the old
telco PABX DDI as many know it!

There is no escape from this in Austria, Germany and perhaps one other
country.

Ronan


-----Original Message-----
From: Stastny Richard <Richard.Stastny@oefeg.at>
To: Clive D.W. Feather <clive@demon.net>; Dale.Worley@comcast.net
<Dale.Worley@comcast.net>
CC: enum@ietf.org <enum@ietf.org>
Sent: Wed Jan 17 09:41:56 2007
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt

Thank you Clive, you answered all the questions already

One more clarification to your last reply:

> > There is also the question of how this infrastructure interacts with
> > number portability, which leads to situations where any given range
of
> > numbers is likely to be a mosaic of assignments to different
carriers.
> 
> Do you mean open plans, or in general? I can't speak to open plans,
but at
> least in the UK portability is unrelated to number length.

In open numbering plans everything may be variable:

If one looks at the Figure B.1/E.164 - Addressing by an ISDN Number
in Rec. E.164 Annex B.3.2, the N(S)N part of an E.164 number is
divided in the NDC (Network Destination Code) and the SN (Subscriber
Number)

The SN is further divided in a Partial Number and what?

The reminder of the SN is not named, we in Austria call it
Pilot Number.

The Partial Numbers are used for DDI (Direct Dialling In)

>From this figure one can derive the following:

A full E.164 number is the Pilot Number + the Partial Number

In closed numbering plans the SN is fixed, so the fixed length
includes the Pilot Number + the Partial Number.

In open numbering plans such as in Austria (and Germany) both
the Pilot Number and the Partial Number can be variable length

The numbering ordinance from the regulator defines the length
of the Pilot Number and is very complicated:

The NDC is between 1 and 4 digits

A Pilot Number is 5 digits
EXCEPT:
In NDCs 316, 463, 512, 662, 732, 2236, 2252, 5572 and 7242 
6 digits
in NDC 1 it is 7 digits

On request you may get more digits, up to 13 digits
in NDC 1, in all other NDC up to 14 digits (including CC)

Companies may also get shorter numbers, depending
on size of company (UNI) -1 or -2 digits

All this rules are only for Pilot numbers and
for Carriers
Any subscriber may add Partial Numbers behind the
Pilot Number (this was something we had to take over
from the old analog system)
The Operator (Carrier) does not know about the length
and structure of the Partial Numbers (= private number plan)

It is recommended the whole E.164 does not exceed
14 digits to make the number reachable internationally

Now to Number Portability (NP):

Only Pilot Numbers are portable. One cannot
port his company number with DDI to another
after retirement or leaving the company.

Additional Information:

Assume the Vienna E.164 Number +43 1 2345678-222

*43 is the CC
1 is the NDC
2345678-222 is the SN
+43 1 2345678 is the Pilot Number (portable)
222 is the Partial Number (DDI)
(Note: there may exist also an E.164
+43 1 2345678-3333

To reach the switchboard, you may dial
+43 1 2345678-0
BUT, you may also dial
+43 1 2345678

The call is terminated at the PBX and after
a time-out you fall back to the switch-board

You also fall back to the switchboard if
you under-dial or dial a non-existent partial number

All this makes a lot of fun with ENUM

Regards
Richard

> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net]
> Sent: Wednesday, January 17, 2007 9:37 AM
> To: Dale.Worley@comcast.net
> Cc: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
> 
> Dale.Worley@comcast.net said:
> >    7.2.1.  Closed Numbering Plans
> >
> >    In many countries closed numbering plans are in use.  In such a
> >    scheme, all valid telephone numbers have a defined length - the
> >    number of digits used for the subscriber number is fixed.  Thus,
for
> >    a given initial digit string, the length of the subsequent digit
> >    string together constituting a valid telephone number is known.
All
> >    other digit strings are invalid.
> >
> > As I read this, it means that all E.164 nubmers for a particular
> > country have the same length.
> 
> No. It says that the first N digits (for some value of N which may
depend
> on the number) tells you how long the number is.
> 
> For example, in the UK, +442 or +447 tells you there is another 9
digits
> to come, but +441 or +448 doesn't - the length depends on more digits.
> 
> > E.g., in North America, a subscriber
> > number is 10 digits (or 11 if you count the country code).
> 
> Apparently not. I am told that numbers beginning +109 are a digit
longer.
> 
> >    For example, for the initial digit string "+44160649", the
subsequent
> >    number string is three digits in length.  However, for the
initial
> >    digit string "+44160650", the subsequent string is four digits in
> >    length.
> >
> > At this point, I have a problem.  If one adds three digits to
> > "44160649" to make a number, then numbers have 11 digits.  But if
one
> > adds four digits to "44160650", then numbers have 8 digits.
> 
> 12 digits, you mean.
> 
> > As far as I can tell, the solution to this contradiction is that
> > "subscriber number" refers to the digits that are after the block
> > prefix, and "initial digit string" refers to the digits that compose
> > the block prefix.
> 
> Right. The meaning of "block" varies - in the UK, the longest such is
(I
> think) +44845464N, where there are no subsequent digits if N is 7 but
2
> otherwise.
> 
> > In section 7.2.2, the draft says "The only restriction is that all
> > these initial digit patterns representing telephone numbers are
> > unique."  I think this means "The only restriction is that no
assigned
> > telephone number may be a prefix of another."
> 
> Right.
> 
> > As far as I can tell from 7.2.2.1, under an open number plan, some
> > customers can be assigned prefixes, and the customer can select how
> > many digits are allowed after the prefix, and which of those sets of
> > digits are valid numbers.
> 
> Not just that: the customer can select which suffices are valid *and
these
> can be different lengths*. In other words, if I am allocated +99923456
> (I use +999 because I don't know of a valid example) I can decide that
> the valid numbers are:
> 
>   +999 23456 0
>   +999 23456 1x
>   +999 23456 2xxx
>   +999 23456 4xx
> 
> > There is also the question of how this infrastructure interacts with
> > number portability, which leads to situations where any given range
of
> > numbers is likely to be a mosaic of assignments to different
carriers.
> 
> Do you mean open plans, or in general? I can't speak to open plans,
but at
> least in the UK portability is unrelated to number length.
> 
> --
> Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495
> 6138
> Internet Expert     | Home:  <clive@davros.org>  | 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


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

------_=_NextPart_001_01C73A1E.A7BE1075
Content-Type: text/html;
	charset="UTF-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34">
<TITLE>Re: [Enum] draft-ietf-enum-unused-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Richard,</FONT>
</P>

<P><FONT SIZE=2>DDI being suffix to national numbering schema expected rather than the old telco PABX DDI as many know it!</FONT>
</P>

<P><FONT SIZE=2>There is no escape from this in Austria, Germany and perhaps one other country.</FONT>
</P>

<P><FONT SIZE=2>Ronan</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Stastny Richard &lt;Richard.Stastny@oefeg.at&gt;</FONT>
<BR><FONT SIZE=2>To: Clive D.W. Feather &lt;clive@demon.net&gt;; Dale.Worley@comcast.net &lt;Dale.Worley@comcast.net&gt;</FONT>
<BR><FONT SIZE=2>CC: enum@ietf.org &lt;enum@ietf.org&gt;</FONT>
<BR><FONT SIZE=2>Sent: Wed Jan 17 09:41:56 2007</FONT>
<BR><FONT SIZE=2>Subject: RE: [Enum] draft-ietf-enum-unused-00.txt</FONT>
</P>

<P><FONT SIZE=2>Thank you Clive, you answered all the questions already</FONT>
</P>

<P><FONT SIZE=2>One more clarification to your last reply:</FONT>
</P>

<P><FONT SIZE=2>&gt; &gt; There is also the question of how this infrastructure interacts with</FONT>
<BR><FONT SIZE=2>&gt; &gt; number portability, which leads to situations where any given range</FONT>
<BR><FONT SIZE=2>of</FONT>
<BR><FONT SIZE=2>&gt; &gt; numbers is likely to be a mosaic of assignments to different</FONT>
<BR><FONT SIZE=2>carriers.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Do you mean open plans, or in general? I can't speak to open plans,</FONT>
<BR><FONT SIZE=2>but at</FONT>
<BR><FONT SIZE=2>&gt; least in the UK portability is unrelated to number length.</FONT>
</P>

<P><FONT SIZE=2>In open numbering plans everything may be variable:</FONT>
</P>

<P><FONT SIZE=2>If one looks at the Figure B.1/E.164 - Addressing by an ISDN Number</FONT>
<BR><FONT SIZE=2>in Rec. E.164 Annex B.3.2, the N(S)N part of an E.164 number is</FONT>
<BR><FONT SIZE=2>divided in the NDC (Network Destination Code) and the SN (Subscriber</FONT>
<BR><FONT SIZE=2>Number)</FONT>
</P>

<P><FONT SIZE=2>The SN is further divided in a Partial Number and what?</FONT>
</P>

<P><FONT SIZE=2>The reminder of the SN is not named, we in Austria call it</FONT>
<BR><FONT SIZE=2>Pilot Number.</FONT>
</P>

<P><FONT SIZE=2>The Partial Numbers are used for DDI (Direct Dialling In)</FONT>
</P>

<P><FONT SIZE=2>&gt;From this figure one can derive the following:</FONT>
</P>

<P><FONT SIZE=2>A full E.164 number is the Pilot Number + the Partial Number</FONT>
</P>

<P><FONT SIZE=2>In closed numbering plans the SN is fixed, so the fixed length</FONT>
<BR><FONT SIZE=2>includes the Pilot Number + the Partial Number.</FONT>
</P>

<P><FONT SIZE=2>In open numbering plans such as in Austria (and Germany) both</FONT>
<BR><FONT SIZE=2>the Pilot Number and the Partial Number can be variable length</FONT>
</P>

<P><FONT SIZE=2>The numbering ordinance from the regulator defines the length</FONT>
<BR><FONT SIZE=2>of the Pilot Number and is very complicated:</FONT>
</P>

<P><FONT SIZE=2>The NDC is between 1 and 4 digits</FONT>
</P>

<P><FONT SIZE=2>A Pilot Number is 5 digits</FONT>
<BR><FONT SIZE=2>EXCEPT:</FONT>
<BR><FONT SIZE=2>In NDCs 316, 463, 512, 662, 732, 2236, 2252, 5572 and 7242 </FONT>
<BR><FONT SIZE=2>6 digits</FONT>
<BR><FONT SIZE=2>in NDC 1 it is 7 digits</FONT>
</P>

<P><FONT SIZE=2>On request you may get more digits, up to 13 digits</FONT>
<BR><FONT SIZE=2>in NDC 1, in all other NDC up to 14 digits (including CC)</FONT>
</P>

<P><FONT SIZE=2>Companies may also get shorter numbers, depending</FONT>
<BR><FONT SIZE=2>on size of company (UNI) -1 or -2 digits</FONT>
</P>

<P><FONT SIZE=2>All this rules are only for Pilot numbers and</FONT>
<BR><FONT SIZE=2>for Carriers</FONT>
<BR><FONT SIZE=2>Any subscriber may add Partial Numbers behind the</FONT>
<BR><FONT SIZE=2>Pilot Number (this was something we had to take over</FONT>
<BR><FONT SIZE=2>from the old analog system)</FONT>
<BR><FONT SIZE=2>The Operator (Carrier) does not know about the length</FONT>
<BR><FONT SIZE=2>and structure of the Partial Numbers (= private number plan)</FONT>
</P>

<P><FONT SIZE=2>It is recommended the whole E.164 does not exceed</FONT>
<BR><FONT SIZE=2>14 digits to make the number reachable internationally</FONT>
</P>

<P><FONT SIZE=2>Now to Number Portability (NP):</FONT>
</P>

<P><FONT SIZE=2>Only Pilot Numbers are portable. One cannot</FONT>
<BR><FONT SIZE=2>port his company number with DDI to another</FONT>
<BR><FONT SIZE=2>after retirement or leaving the company.</FONT>
</P>

<P><FONT SIZE=2>Additional Information:</FONT>
</P>

<P><FONT SIZE=2>Assume the Vienna E.164 Number +43 1 2345678-222</FONT>
</P>

<P><FONT SIZE=2>*43 is the CC</FONT>
<BR><FONT SIZE=2>1 is the NDC</FONT>
<BR><FONT SIZE=2>2345678-222 is the SN</FONT>
<BR><FONT SIZE=2>+43 1 2345678 is the Pilot Number (portable)</FONT>
<BR><FONT SIZE=2>222 is the Partial Number (DDI)</FONT>
<BR><FONT SIZE=2>(Note: there may exist also an E.164</FONT>
<BR><FONT SIZE=2>+43 1 2345678-3333</FONT>
</P>

<P><FONT SIZE=2>To reach the switchboard, you may dial</FONT>
<BR><FONT SIZE=2>+43 1 2345678-0</FONT>
<BR><FONT SIZE=2>BUT, you may also dial</FONT>
<BR><FONT SIZE=2>+43 1 2345678</FONT>
</P>

<P><FONT SIZE=2>The call is terminated at the PBX and after</FONT>
<BR><FONT SIZE=2>a time-out you fall back to the switch-board</FONT>
</P>

<P><FONT SIZE=2>You also fall back to the switchboard if</FONT>
<BR><FONT SIZE=2>you under-dial or dial a non-existent partial number</FONT>
</P>

<P><FONT SIZE=2>All this makes a lot of fun with ENUM</FONT>
</P>

<P><FONT SIZE=2>Regards</FONT>
<BR><FONT SIZE=2>Richard</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Clive D.W. Feather [<A HREF="mailto:clive@demon.net">mailto:clive@demon.net</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 17, 2007 9:37 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Dale.Worley@comcast.net</FONT>
<BR><FONT SIZE=2>&gt; Cc: enum@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [Enum] draft-ietf-enum-unused-00.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dale.Worley@comcast.net said:</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; 7.2.1.&nbsp; Closed Numbering Plans</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; In many countries closed numbering plans are in use.&nbsp; In such a</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; scheme, all valid telephone numbers have a defined length - the</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; number of digits used for the subscriber number is fixed.&nbsp; Thus,</FONT>
<BR><FONT SIZE=2>for</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; a given initial digit string, the length of the subsequent digit</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; string together constituting a valid telephone number is known.</FONT>
<BR><FONT SIZE=2>All</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; other digit strings are invalid.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; As I read this, it means that all E.164 nubmers for a particular</FONT>
<BR><FONT SIZE=2>&gt; &gt; country have the same length.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No. It says that the first N digits (for some value of N which may</FONT>
<BR><FONT SIZE=2>depend</FONT>
<BR><FONT SIZE=2>&gt; on the number) tells you how long the number is.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; For example, in the UK, +442 or +447 tells you there is another 9</FONT>
<BR><FONT SIZE=2>digits</FONT>
<BR><FONT SIZE=2>&gt; to come, but +441 or +448 doesn't - the length depends on more digits.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; E.g., in North America, a subscriber</FONT>
<BR><FONT SIZE=2>&gt; &gt; number is 10 digits (or 11 if you count the country code).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Apparently not. I am told that numbers beginning +109 are a digit</FONT>
<BR><FONT SIZE=2>longer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; For example, for the initial digit string &quot;+44160649&quot;, the</FONT>
<BR><FONT SIZE=2>subsequent</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; number string is three digits in length.&nbsp; However, for the</FONT>
<BR><FONT SIZE=2>initial</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; digit string &quot;+44160650&quot;, the subsequent string is four digits in</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; length.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; At this point, I have a problem.&nbsp; If one adds three digits to</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;44160649&quot; to make a number, then numbers have 11 digits.&nbsp; But if</FONT>
<BR><FONT SIZE=2>one</FONT>
<BR><FONT SIZE=2>&gt; &gt; adds four digits to &quot;44160650&quot;, then numbers have 8 digits.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 12 digits, you mean.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; As far as I can tell, the solution to this contradiction is that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;subscriber number&quot; refers to the digits that are after the block</FONT>
<BR><FONT SIZE=2>&gt; &gt; prefix, and &quot;initial digit string&quot; refers to the digits that compose</FONT>
<BR><FONT SIZE=2>&gt; &gt; the block prefix.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Right. The meaning of &quot;block&quot; varies - in the UK, the longest such is</FONT>
<BR><FONT SIZE=2>(I</FONT>
<BR><FONT SIZE=2>&gt; think) +44845464N, where there are no subsequent digits if N is 7 but</FONT>
<BR><FONT SIZE=2>2</FONT>
<BR><FONT SIZE=2>&gt; otherwise.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; In section 7.2.2, the draft says &quot;The only restriction is that all</FONT>
<BR><FONT SIZE=2>&gt; &gt; these initial digit patterns representing telephone numbers are</FONT>
<BR><FONT SIZE=2>&gt; &gt; unique.&quot;&nbsp; I think this means &quot;The only restriction is that no</FONT>
<BR><FONT SIZE=2>assigned</FONT>
<BR><FONT SIZE=2>&gt; &gt; telephone number may be a prefix of another.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Right.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; As far as I can tell from 7.2.2.1, under an open number plan, some</FONT>
<BR><FONT SIZE=2>&gt; &gt; customers can be assigned prefixes, and the customer can select how</FONT>
<BR><FONT SIZE=2>&gt; &gt; many digits are allowed after the prefix, and which of those sets of</FONT>
<BR><FONT SIZE=2>&gt; &gt; digits are valid numbers.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Not just that: the customer can select which suffices are valid *and</FONT>
<BR><FONT SIZE=2>these</FONT>
<BR><FONT SIZE=2>&gt; can be different lengths*. In other words, if I am allocated +99923456</FONT>
<BR><FONT SIZE=2>&gt; (I use +999 because I don't know of a valid example) I can decide that</FONT>
<BR><FONT SIZE=2>&gt; the valid numbers are:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; +999 23456 0</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; +999 23456 1x</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; +999 23456 2xxx</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; +999 23456 4xx</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; There is also the question of how this infrastructure interacts with</FONT>
<BR><FONT SIZE=2>&gt; &gt; number portability, which leads to situations where any given range</FONT>
<BR><FONT SIZE=2>of</FONT>
<BR><FONT SIZE=2>&gt; &gt; numbers is likely to be a mosaic of assignments to different</FONT>
<BR><FONT SIZE=2>carriers.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Do you mean open plans, or in general? I can't speak to open plans,</FONT>
<BR><FONT SIZE=2>but at</FONT>
<BR><FONT SIZE=2>&gt; least in the UK portability is unrelated to number length.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --</FONT>
<BR><FONT SIZE=2>&gt; Clive D.W. Feather&nbsp; | Work:&nbsp; &lt;clive@demon.net&gt;&nbsp;&nbsp; | Tel:&nbsp;&nbsp;&nbsp; +44 20 8495</FONT>
<BR><FONT SIZE=2>&gt; 6138</FONT>
<BR><FONT SIZE=2>&gt; Internet Expert&nbsp;&nbsp;&nbsp;&nbsp; | Home:&nbsp; &lt;clive@davros.org&gt;&nbsp; | Fax:&nbsp;&nbsp;&nbsp; +44 870 051</FONT>
<BR><FONT SIZE=2>&gt; 9937</FONT>
<BR><FONT SIZE=2>&gt; Demon Internet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | WWW: <A HREF="http://www.davros.org" TARGET="_blank">http://www.davros.org</A> | Mobile: +44 7973</FONT>
<BR><FONT SIZE=2>377646</FONT>
<BR><FONT SIZE=2>&gt; THUS plc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; enum mailing list</FONT>
<BR><FONT SIZE=2>&gt; enum@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/enum" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>
</P>
<BR>

<P><FONT SIZE=2>_______________________________________________</FONT>
<BR><FONT SIZE=2>enum mailing list</FONT>
<BR><FONT SIZE=2>enum@ietf.org</FONT>
<BR><FONT SIZE=2><A HREF="https://www1.ietf.org/mailman/listinfo/enum" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C73A1E.A7BE1075--


--===============1461789381==
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

--===============1461789381==--




From enum-bounces@ietf.org Wed Jan 17 05:08:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H77iw-0002PP-Ai; Wed, 17 Jan 2007 05:08:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H77iu-0002IU-Tn
	for enum@ietf.org; Wed, 17 Jan 2007 05:08:52 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H77it-0008Rq-Jt
	for enum@ietf.org; Wed, 17 Jan 2007 05:08: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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 11:08:16 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469E6@oefeg-s04.oefeg.loc>
In-Reply-To: <CA3896DB5903C14EAAC9D8E91D1167CBCC76C6@ms-lon-exmb06.uk.mcilink.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6HrMsr1ST21qwRm6A3c9eVStHCAAAFGdw
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>, <clive@demon.net>,
	<Dale.Worley@comcast.net>
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Ronan,

>DDI being suffix to national numbering schema expected rather than the
old >telco PABX DDI as many know it!=20

I do not really understand what you want to say

>There is no escape from this in Austria, Germany and perhaps one other
>country.=20

Do you mean Austria has to change this?

No plans yet

Richard



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



From enum-bounces@ietf.org Wed Jan 17 05:18:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H77rg-0000Pu-TA; Wed, 17 Jan 2007 05:17:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H77rg-0000Pd-06
	for enum@ietf.org; Wed, 17 Jan 2007 05:17:56 -0500
Received: from cyclone.wcom.co.uk ([193.131.254.139]
	helo=cyclone.emea.verizonbusiness.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77rc-0001vF-Bu
	for enum@ietf.org; Wed, 17 Jan 2007 05:17:55 -0500
Received: from borg.emea.mci.com ([166.59.191.249]
	helo=ocampa.emea.verizonbusiness.com)
	by cyclone.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H77rZ-0002z3-Vf; Wed, 17 Jan 2007 10:17:51 +0000
Received: from ms-lon-exgw02.uk.mcilink.com ([166.59.191.19]
	helo=ms-lon-exgw02.emea.dsmain.com)
	by ocampa.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H77rQ-0002lu-S9; Wed, 17 Jan 2007 10:17:40 +0000
Received: by ms-lon-exgw02.uk.mcilink.com with Internet Mail Service
	(5.5.2658.27) id <C2R323W7>; Wed, 17 Jan 2007 10:17:40 -0000
Message-ID: <CA3896DB5903C14EAAC9D8E91D1167CBCC76C7@ms-lon-exmb06.uk.mcilink.com>
From: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
To: "'Richard.Stastny@oefeg.at'" <Richard.Stastny@oefeg.at>, 
	"'clive@demon.net'" <clive@demon.net>, "'Dale.Worley@comcast.net'"
	<Dale.Worley@comcast.net>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 10:17:39 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2658.27)
X-VZ-EMEA-Spam-Score: -499.5
	(---------------------------------------------------)
X-VZ-EMEA-Signature: dc26a97c7218fabf0bcd563b60ce98c0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: "'enum@ietf.org'" <enum@ietf.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0900572877=="
Errors-To: enum-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0900572877==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73A20.B7A9D8B1"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C73A20.B7A9D8B1
Content-Type: text/plain;
	charset="UTF-8"

Richard,

Just so we don't confuse people, DDI in ENUM speak is different to DDI PSTN
speak. What we mean in the ENUM context is digits over and above the
expected national lengths, whereas in PSTN speak we or many understand it to
conform or be part of a ISDN standard set up or config.

No, we couldn't have any changes not after debating it for so long at this
stage. 

Austria are after all leading the charge!!

Ronan 


-----Original Message-----
From: Stastny Richard <Richard.Stastny@oefeg.at>
To: Lupton, Ronan; clive@demon.net <clive@demon.net>;
Dale.Worley@comcast.net <Dale.Worley@comcast.net>
CC: enum@ietf.org <enum@ietf.org>
Sent: Wed Jan 17 10:08:16 2007
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt


Ronan,

>DDI being suffix to national numbering schema expected rather than the
old >telco PABX DDI as many know it! 

I do not really understand what you want to say

>There is no escape from this in Austria, Germany and perhaps one other
>country. 

Do you mean Austria has to change this?

No plans yet

Richard



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

------_=_NextPart_001_01C73A20.B7A9D8B1
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUTF-8">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>Re: [Enum] draft-ietf-enum-unused-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Richard,</FONT>
</P>

<P><FONT SIZE=3D2>Just so we don't confuse people, DDI in ENUM speak is =
different to DDI PSTN speak. What we mean in the ENUM context is digits =
over and above the expected national lengths, whereas in PSTN speak we =
or many understand it to conform or be part of a ISDN standard set up =
or config.</FONT></P>

<P><FONT SIZE=3D2>No, we couldn't have any changes not after debating =
it for so long at this stage. </FONT>
</P>

<P><FONT SIZE=3D2>Austria are after all leading the charge!!</FONT>
</P>

<P><FONT SIZE=3D2>Ronan </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stastny Richard =
&lt;Richard.Stastny@oefeg.at&gt;</FONT>
<BR><FONT SIZE=3D2>To: Lupton, Ronan; clive@demon.net =
&lt;clive@demon.net&gt;; Dale.Worley@comcast.net =
&lt;Dale.Worley@comcast.net&gt;</FONT>
<BR><FONT SIZE=3D2>CC: enum@ietf.org &lt;enum@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Wed Jan 17 10:08:16 2007</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Enum] =
draft-ietf-enum-unused-00.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Ronan,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;DDI being suffix to national numbering schema =
expected rather than the</FONT>
<BR><FONT SIZE=3D2>old &gt;telco PABX DDI as many know it! </FONT>
</P>

<P><FONT SIZE=3D2>I do not really understand what you want to =
say</FONT>
</P>

<P><FONT SIZE=3D2>&gt;There is no escape from this in Austria, Germany =
and perhaps one other</FONT>
<BR><FONT SIZE=3D2>&gt;country. </FONT>
</P>

<P><FONT SIZE=3D2>Do you mean Austria has to change this?</FONT>
</P>

<P><FONT SIZE=3D2>No plans yet</FONT>
</P>

<P><FONT SIZE=3D2>Richard</FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>enum mailing list</FONT>
<BR><FONT SIZE=3D2>enum@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C73A20.B7A9D8B1--


--===============0900572877==
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

--===============0900572877==--




From enum-bounces@ietf.org Wed Jan 17 05:27:21 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H780k-0003Yq-Ta; Wed, 17 Jan 2007 05:27:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H780j-0003Yk-Rt
	for enum@ietf.org; Wed, 17 Jan 2007 05:27:17 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H780i-0004Cw-ET
	for enum@ietf.org; Wed, 17 Jan 2007 05:27:17 -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] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 11:26:40 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469E7@oefeg-s04.oefeg.loc>
In-Reply-To: <CA3896DB5903C14EAAC9D8E91D1167CBCC76C7@ms-lon-exmb06.uk.mcilink.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6IKs2Hne/dVcfRxaZ9l9WcikhZQAAFcjA
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Ronan,

>Just so we don't confuse people, DDI in ENUM speak is different to DDI
PSTN >speak. What we mean in the ENUM context is digits over and above
the >expected national lengths, whereas in PSTN speak we or many
understand it >to conform or be part of an ISDN standard set up or
config.

This is not correct:
1. There is no "expected" national length in open numbering plans

2. Please look at E.164-Annex B

"In instances where a partial number is utilized, the number will be
used in the context of direct-dialling-in supplementary service."

This has nothing to do with ISDN Subaddress

SA is something else and comes after the partial number:

B.3.4 "Sub-addressing may be used separately or in combination with the=20
partial number"

Richard

>No, we couldn't have any changes not after debating it for so long at
this >stage.=20
>Austria are after all leading the charge!!=20
>Ronan=20

-----Original Message-----=20
From: Stastny Richard <Richard.Stastny@oefeg.at>=20
To: Lupton, Ronan; clive@demon.net <clive@demon.net>;
Dale.Worley@comcast.net <Dale.Worley@comcast.net>=20
CC: enum@ietf.org <enum@ietf.org>=20
Sent: Wed Jan 17 10:08:16 2007=20
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt=20

Ronan,=20
>DDI being suffix to national numbering schema expected rather than the=20
old >telco PABX DDI as many know it!=20
I do not really understand what you want to say=20
>There is no escape from this in Austria, Germany and perhaps one other=20
>country.=20
Do you mean Austria has to change this?=20
No plans yet=20
Richard=20

_______________________________________________=20
enum mailing list=20
enum@ietf.org=20
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 Wed Jan 17 05:43:43 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H78GA-0002xH-7X; Wed, 17 Jan 2007 05:43:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H78G9-0002uy-Fw
	for enum@ietf.org; Wed, 17 Jan 2007 05:43:13 -0500
Received: from gregale.wcom.co.uk ([193.131.254.138]
	helo=gregale.emea.verizonbusiness.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78G6-00072i-M3
	for enum@ietf.org; Wed, 17 Jan 2007 05:43:13 -0500
Received: from gregale.wcom.co.uk ([170.127.79.98] helo=gregale.emea.mci.com)
	by gregale.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H78Fz-0004Cz-Ap; Wed, 17 Jan 2007 10:43:05 +0000
Received: from borg.emea.verizonbusiness.com (vardar [170.127.64.33])
	by gregale.emea.mci.com (4.7.0.120) with ESMTP id ;
	Wed, 17 Jan 2007 10:42:37 GMT
Received: from ms-lon-exgw02.uk.mcilink.com ([166.59.191.19]
	helo=ms-lon-exgw02.emea.dsmain.com)
	by borg.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H78FZ-0005bI-20; Wed, 17 Jan 2007 10:42:37 +0000
Received: by ms-lon-exgw02.uk.mcilink.com with Internet Mail Service
	(5.5.2658.27) id <C2R32QQ3>; Wed, 17 Jan 2007 10:42:24 -0000
Message-ID: <CA3896DB5903C14EAAC9D8E91D1167CBCC76C9@ms-lon-exmb06.uk.mcilink.com>
From: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
To: "'Richard.Stastny@oefeg.at'" <Richard.Stastny@oefeg.at>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 10:42:23 -0000
X-Mailer: Internet Mail Service (5.5.2658.27)
MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40)
X-VZ-EMEA-Spam-Score: -499.5
	(---------------------------------------------------)
X-VZ-EMEA-Signature: 1a6abe392d8f5737049fff0bbd7900a9
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae
Cc: "'enum@ietf.org'" <enum@ietf.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0738405046=="
Errors-To: enum-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0738405046==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73A24.2BFD66F9"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C73A24.2BFD66F9
Content-Type: text/plain;
	charset="UTF-8"

Richard,

Indeed the key phrase being 'open numbering plans' many states have standard
length plans, unless they opt for open numbering plans. I have the standard
on my desk here.

Many do not treat the DDI definition as we discuss it on IETF ENUM as the
potential additional of suffix digits that it would take to 'literally' call
someone in a open numbering plan.

So you can take back that I am incorrect and I will admit that I could have
used a better form of words.

Many your suggestion to abolish open numbering plans is indeed fruitful ;0)
it would make ENUM easier.

Ronan


-----Original Message-----
From: Stastny Richard <Richard.Stastny@oefeg.at>
To: Lupton, Ronan
CC: enum@ietf.org <enum@ietf.org>
Sent: Wed Jan 17 10:26:40 2007
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt

Ronan,

>Just so we don't confuse people, DDI in ENUM speak is different to DDI
PSTN >speak. What we mean in the ENUM context is digits over and above
the >expected national lengths, whereas in PSTN speak we or many
understand it >to conform or be part of an ISDN standard set up or
config.

This is not correct:
1. There is no "expected" national length in open numbering plans

2. Please look at E.164-Annex B

"In instances where a partial number is utilized, the number will be
used in the context of direct-dialling-in supplementary service."

This has nothing to do with ISDN Subaddress

SA is something else and comes after the partial number:

B.3.4 "Sub-addressing may be used separately or in combination with the 
partial number"

Richard

>No, we couldn't have any changes not after debating it for so long at
this >stage. 
>Austria are after all leading the charge!! 
>Ronan 

-----Original Message----- 
From: Stastny Richard <Richard.Stastny@oefeg.at> 
To: Lupton, Ronan; clive@demon.net <clive@demon.net>;
Dale.Worley@comcast.net <Dale.Worley@comcast.net> 
CC: enum@ietf.org <enum@ietf.org> 
Sent: Wed Jan 17 10:08:16 2007 
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt 

Ronan, 
>DDI being suffix to national numbering schema expected rather than the 
old >telco PABX DDI as many know it! 
I do not really understand what you want to say 
>There is no escape from this in Austria, Germany and perhaps one other 
>country. 
Do you mean Austria has to change this? 
No plans yet 
Richard 

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

------_=_NextPart_001_01C73A24.2BFD66F9
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUTF-8">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>Re: [Enum] draft-ietf-enum-unused-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Richard,</FONT>
</P>

<P><FONT SIZE=3D2>Indeed the key phrase being 'open numbering plans' =
many states have standard length plans, unless they opt for open =
numbering plans. I have the standard on my desk here.</FONT></P>

<P><FONT SIZE=3D2>Many do not treat the DDI definition as we discuss it =
on IETF ENUM as the potential additional of suffix digits that it would =
take to 'literally' call someone in a open numbering plan.</FONT></P>

<P><FONT SIZE=3D2>So you can take back that I am incorrect and I will =
admit that I could have used a better form of words.</FONT>
</P>

<P><FONT SIZE=3D2>Many your suggestion to abolish open numbering plans =
is indeed fruitful ;0) it would make ENUM easier.</FONT>
</P>

<P><FONT SIZE=3D2>Ronan</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stastny Richard =
&lt;Richard.Stastny@oefeg.at&gt;</FONT>
<BR><FONT SIZE=3D2>To: Lupton, Ronan</FONT>
<BR><FONT SIZE=3D2>CC: enum@ietf.org &lt;enum@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Wed Jan 17 10:26:40 2007</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Enum] =
draft-ietf-enum-unused-00.txt</FONT>
</P>

<P><FONT SIZE=3D2>Ronan,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Just so we don't confuse people, DDI in ENUM =
speak is different to DDI</FONT>
<BR><FONT SIZE=3D2>PSTN &gt;speak. What we mean in the ENUM context is =
digits over and above</FONT>
<BR><FONT SIZE=3D2>the &gt;expected national lengths, whereas in PSTN =
speak we or many</FONT>
<BR><FONT SIZE=3D2>understand it &gt;to conform or be part of an ISDN =
standard set up or</FONT>
<BR><FONT SIZE=3D2>config.</FONT>
</P>

<P><FONT SIZE=3D2>This is not correct:</FONT>
<BR><FONT SIZE=3D2>1. There is no &quot;expected&quot; national length =
in open numbering plans</FONT>
</P>

<P><FONT SIZE=3D2>2. Please look at E.164-Annex B</FONT>
</P>

<P><FONT SIZE=3D2>&quot;In instances where a partial number is =
utilized, the number will be</FONT>
<BR><FONT SIZE=3D2>used in the context of direct-dialling-in =
supplementary service.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>This has nothing to do with ISDN Subaddress</FONT>
</P>

<P><FONT SIZE=3D2>SA is something else and comes after the partial =
number:</FONT>
</P>

<P><FONT SIZE=3D2>B.3.4 &quot;Sub-addressing may be used separately or =
in combination with the </FONT>
<BR><FONT SIZE=3D2>partial number&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Richard</FONT>
</P>

<P><FONT SIZE=3D2>&gt;No, we couldn't have any changes not after =
debating it for so long at</FONT>
<BR><FONT SIZE=3D2>this &gt;stage. </FONT>
<BR><FONT SIZE=3D2>&gt;Austria are after all leading the charge!! =
</FONT>
<BR><FONT SIZE=3D2>&gt;Ronan </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Stastny Richard =
&lt;Richard.Stastny@oefeg.at&gt; </FONT>
<BR><FONT SIZE=3D2>To: Lupton, Ronan; clive@demon.net =
&lt;clive@demon.net&gt;;</FONT>
<BR><FONT SIZE=3D2>Dale.Worley@comcast.net =
&lt;Dale.Worley@comcast.net&gt; </FONT>
<BR><FONT SIZE=3D2>CC: enum@ietf.org &lt;enum@ietf.org&gt; </FONT>
<BR><FONT SIZE=3D2>Sent: Wed Jan 17 10:08:16 2007 </FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Enum] draft-ietf-enum-unused-00.txt =
</FONT>
</P>

<P><FONT SIZE=3D2>Ronan, </FONT>
<BR><FONT SIZE=3D2>&gt;DDI being suffix to national numbering schema =
expected rather than the </FONT>
<BR><FONT SIZE=3D2>old &gt;telco PABX DDI as many know it! </FONT>
<BR><FONT SIZE=3D2>I do not really understand what you want to say =
</FONT>
<BR><FONT SIZE=3D2>&gt;There is no escape from this in Austria, Germany =
and perhaps one other </FONT>
<BR><FONT SIZE=3D2>&gt;country. </FONT>
<BR><FONT SIZE=3D2>Do you mean Austria has to change this? </FONT>
<BR><FONT SIZE=3D2>No plans yet </FONT>
<BR><FONT SIZE=3D2>Richard </FONT>
</P>

<P><FONT SIZE=3D2>_______________________________________________ =
</FONT>
<BR><FONT SIZE=3D2>enum mailing list </FONT>
<BR><FONT SIZE=3D2>enum@ietf.org </FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A> =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C73A24.2BFD66F9--


--===============0738405046==
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

--===============0738405046==--




From enum-bounces@ietf.org Wed Jan 17 06:35:18 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H794H-00050D-VG; Wed, 17 Jan 2007 06:35:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H794G-000506-G8
	for enum@ietf.org; Wed, 17 Jan 2007 06:35:00 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H794F-0003DU-29
	for enum@ietf.org; Wed, 17 Jan 2007 06:35:00 -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 l0HBYvhE019208Wed, 17 Jan 2007 11:34:57 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H794D-000Dch-00; Wed, 17 Jan 2007 11:34:57 +0000
Date: Wed, 17 Jan 2007 11:34:57 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070117113457.GA51908@finch-staff-1.thus.net>
References: <20070117083715.GA32449@finch-staff-1.thus.net>
	<32755D354E6B65498C3BD9FD496C7D466469E4@oefeg-s04.oefeg.loc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466469E4@oefeg-s04.oefeg.loc>
User-Agent: Mutt/1.5.3i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: enum@ietf.org, Dale.Worley@comcast.net
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Stastny Richard said:
> Thank you Clive, you answered all the questions already

You're welcome.

I thought about this a bit more (during my morning commute) and I think
that the key difference is:

* In a "closed plan", end users are allocated numbers or blocks of numbers,
  but have no (direct) control over the length of these numbers.
* In an "open plan", end users are allocated prefixes and may create
  numbers of any length (subject to some overall limit) starting with those
  prefixes.

It's usual in a closed plan for numbers to be in blocks such that all
numbers in that block are the same length. For example, most of +1 is one
such block, and +442 and +447 are other such blocks. However, there is no
rule that can be written about this and adjacent numbers may be of
different lengths (ask about the UK's 0800 mess, but only after you've
bought me a drink). However, no number is a proper prefix of another.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Wed Jan 17 08:24:01 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7AlB-0002KT-4f; Wed, 17 Jan 2007 08:23:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7AlA-0002KO-DP
	for enum@ietf.org; Wed, 17 Jan 2007 08:23:24 -0500
Received: from sccrmhc15.comcast.net ([204.127.200.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Al9-0004AB-4v
	for enum@ietf.org; Wed, 17 Jan 2007 08:23:24 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc15) with ESMTP
	id <2007011713232201500s7mhoe>; Wed, 17 Jan 2007 13:23:22 +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 l0HDNMbM007858
	for <enum@ietf.org>; Wed, 17 Jan 2007 08:23:22 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0HDNMHO007854;
	Wed, 17 Jan 2007 08:23:22 -0500
Date: Wed, 17 Jan 2007 08:23:22 -0500
Message-Id: <200701171323.l0HDNMHO007854@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <20070117083715.GA32449@finch-staff-1.thus.net> (clive@demon.net)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <200701161632.l0GGWKqh024459@dragon.ariadne.com>
	<20070117083715.GA32449@finch-staff-1.thus.net>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Clive D.W. Feather" <clive@demon.net>

   Dale.Worley@comcast.net said:
   >    7.2.1.  Closed Numbering Plans
   > 
   >    In many countries closed numbering plans are in use.  In such a
   >    scheme, all valid telephone numbers have a defined length - the
   >    number of digits used for the subscriber number is fixed.  Thus, for
   >    a given initial digit string, the length of the subsequent digit
   >    string together constituting a valid telephone number is known.  All
   >    other digit strings are invalid.
   > 
   > As I read this, it means that all E.164 nubmers for a particular
   > country have the same length.

   No. It says that the first N digits (for some value of N which may depend
   on the number) tells you how long the number is.

Actually, that's what you *want it to mean*.

What it *says* is that all numbers in the closed numbering plan (which
is presumably an attribute of the country's prefix, since the scope of
a "numbering plan" is not otherwise specified) have the same length.

   For example, in the UK, +442 or +447 tells you there is another 9 digits
   to come, but +441 or +448 doesn't - the length depends on more digits.

That is, the UK, +44, does *not* have a closed numbering plan by the above
definition.

   > E.g., in North America, a subscriber
   > number is 10 digits (or 11 if you count the country code).

   Apparently not. I am told that numbers beginning +109 are a digit longer.

I've never heard of that.

   >    For example, for the initial digit string "+44160649", the subsequent
   >    number string is three digits in length.  However, for the initial
   >    digit string "+44160650", the subsequent string is four digits in
   >    length.
   > 
   > At this point, I have a problem.  If one adds three digits to
   > "44160649" to make a number, then numbers have 11 digits.  But if one
   > adds four digits to "44160650", then numbers have 8 digits.

   12 digits, you mean.

Oops, yes.

   > As far as I can tell, the solution to this contradiction is that
   > "subscriber number" refers to the digits that are after the block
   > prefix, and "initial digit string" refers to the digits that compose
   > the block prefix.

   Right. The meaning of "block" varies - in the UK, the longest such is (I
   think) +44845464N, where there are no subsequent digits if N is 7 but 2
   otherwise.

OK, but make sure that you state that meaning of "subscriber number"
clearly at the beginning, as it is unnatural to someone whose primary
interface with the PSTN is through dialing calls.

Perhaps I can sum up the above in a rule of thumb:  PSTN people tend
to think of the grouping of numbers into blocks as intrinsic, and are
constantly aware of where the block-prefix boundary is in a number.
Everybody else is entirely unaware that numbers are grouped into
blocks, and so any concept that hinges on the block structure must be
explicitly explained as such.

   > There is also the question of how this infrastructure interacts with
   > number portability, which leads to situations where any given range of
   > numbers is likely to be a mosaic of assignments to different carriers.

   Do you mean open plans, or in general? I can't speak to open plans, but at
   least in the UK portability is unrelated to number length.

The question isn't number length, but where the DNS zones are broken.
Much current thinking assumes that the DNS zones are broken at the
block boundaries.  This makes sense if all the numbers in a block are
controlled by one carrier.  But if the numbers are controlled by
different carriers, the block may be covered by a patchwork of DNS
zones; in the worst case, each number could be a separate zone.

Dale

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



From enum-bounces@ietf.org Wed Jan 17 08:49:18 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7B9t-0006aM-Gs; Wed, 17 Jan 2007 08:48:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7B9s-0006aE-6t
	for enum@ietf.org; Wed, 17 Jan 2007 08:48:56 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7B9q-0002SQ-NU
	for enum@ietf.org; Wed, 17 Jan 2007 08:48:56 -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] Re: Unused-00 - CRUE
Date: Wed, 17 Jan 2007 14:48:11 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469EC@oefeg-s04.oefeg.loc>
In-Reply-To: <OF4155CAFE.FE9CF90B-ON80257265.007C0BEC-80257265.007C755D@nominet.org.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Re: Unused-00 - CRUE
Thread-Index: Acc5vzUSdzs4ugaHT/SweE2TMmmuSgAfPNYA
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Jay Daley" <jay@nominet.org.uk>,
	"IETF ENUM WG" <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: lconroy <lconroy@insensate.co.uk>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

After reading the mentioned CRUE document, I have some
comments:

Privacy:

CRUE says:

"3.2.2  Carrier identification in NAPTR

However OfCom have indicated one area of concern that needs to be
addresses by carriers intending to use=20
this service.  Currently it is not possible to determine by simple
examination of a database whether a number=20
has been ported and to whom it has been ported.  With this system this
may be possible by use of DNS=20
lookups  and  cross-referencing  with  the  information  on  IP  address
allocation  held  by  Regional  Internet=20
Registries.

OfCom are clear that it is not practical to completely prevent such
information exposure, but that suitable=20
measures must be put into place to ensure that it is not trivial.  They
have therefore concentrated on the name=20
of the server given in the SIP record.  If the name of the operating
telco is immediately obvious from reading=20
the name (e.g. sip1.bt.com) then this is not acceptable, but if it is
not (e.g. sip1.internet.co.uk) then this is=20
acceptable."

I think this is completely nonsense:

Since CRUE requires that all entries of a Carrier are the same,
one simple has to look up one number he knows which carrier it is,
Retrieve the domain name and then he looks up the number in question

This is not even secrecy by obscurity.

So you could as well enter bt.com in the first place.

So either these paragraphs are cancelled or CRUE cannot be implemented.

I also consider this a bit weird:

"4.  The data about a participating telco's SIP gateways will be public.
For security and operational=20
reasons, most telcos choose not publish details of their interconnect
points and network topology.=20
They may not even disclose this to other telcos."


Can one please explain to me how a telco may interconnect with other
telcos if they do not disclose details of their interconnection points
to them?

Ah, yes, use XConnect ;-)

Richard



> -----Original Message-----
> From: Jay Daley [mailto:jay@nominet.org.uk]
> Sent: Tuesday, January 16, 2007 11:39 PM
> To: IETF ENUM WG
> Cc: lconroy
> Subject: Re: [Enum] Re: Unused-00 - CRUE
>=20
> lconroy <lconroy@insensate.co.uk> wrote on 12/01/2007 12:07:13:
>=20
> > For more information on CRUE, come to the pub next Wednesday (see
> > Jim's earlier
> > email :).
> > </CRUE>
>=20
> Those of you who cannot make it can get the CRUE document here:
>=20
>         http://download.nominet.org.uk/ENUM/CRUEv7.pdf
>=20
> Jay Daley
> Nominet UK
>=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 Jan 17 09:07:30 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7BRV-00089U-RU; Wed, 17 Jan 2007 09:07:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BRT-00089K-Mg
	for enum@ietf.org; Wed, 17 Jan 2007 09:07:07 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7BRS-00074F-11
	for enum@ietf.org; Wed, 17 Jan 2007 09:07: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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 15:06:20 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469ED@oefeg-s04.oefeg.loc>
In-Reply-To: <200701171323.l0HDNMHO007854@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6Oq84TTxM9soVRIu+z8e+CBXuuwABD5eQ
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


First I have to say that draft-ietf-enum-unused-00 is not a
complete explanation of open an closed numbering plans and also
not one of open and closed dialing plans (which are different),
but the IANA registration of Enumservice "unused".

We tried to give only the main examples how to use "unused" in
the different numbering plans.

And I have to admit, the issue is confusing

Anyway:

> The question isn't number length, but where the DNS zones are broken.
> Much current thinking assumes that the DNS zones are broken at the
> block boundaries.  This makes sense if all the numbers in a block are
> controlled by one carrier.  But if the numbers are controlled by
> different carriers, the block may be covered by a patchwork of DNS
> zones; in the worst case, each number could be a separate zone.

Exactly, and this is the preferred implementation for all "used"
numbers.

The problem with "unused" in open numbering plans (what kind of ever)
is,
that you cannot say how long a number will be as long as it is not
assigned.

And the only way out of this in open numbering plans is the usage of=20
the "Closest encloser"

In closed numbering plans, either with all numbers the same length,
or with a fixed length per block/range, the best way (considering
number portability) is always to enter all numbers into the DNS.

Richard



> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: Wednesday, January 17, 2007 2:23 PM
> To: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>=20
>    From: "Clive D.W. Feather" <clive@demon.net>
>=20
>    Dale.Worley@comcast.net said:
>    >    7.2.1.  Closed Numbering Plans
>    >
>    >    In many countries closed numbering plans are in use.  In such
a
>    >    scheme, all valid telephone numbers have a defined length -
the
>    >    number of digits used for the subscriber number is fixed.
Thus,
> for
>    >    a given initial digit string, the length of the subsequent
digit
>    >    string together constituting a valid telephone number is
known.
> All
>    >    other digit strings are invalid.
>    >
>    > As I read this, it means that all E.164 nubmers for a particular
>    > country have the same length.
>=20
>    No. It says that the first N digits (for some value of N which may
> depend
>    on the number) tells you how long the number is.
>=20
> Actually, that's what you *want it to mean*.
>=20
> What it *says* is that all numbers in the closed numbering plan (which
> is presumably an attribute of the country's prefix, since the scope of
> a "numbering plan" is not otherwise specified) have the same length.
>=20
>    For example, in the UK, +442 or +447 tells you there is another 9
> digits
>    to come, but +441 or +448 doesn't - the length depends on more
digits.
>=20
> That is, the UK, +44, does *not* have a closed numbering plan by the
above
> definition.
>=20
>    > E.g., in North America, a subscriber
>    > number is 10 digits (or 11 if you count the country code).
>=20
>    Apparently not. I am told that numbers beginning +109 are a digit
> longer.
>=20
> I've never heard of that.
>=20
>    >    For example, for the initial digit string "+44160649", the
> subsequent
>    >    number string is three digits in length.  However, for the
initial
>    >    digit string "+44160650", the subsequent string is four digits
in
>    >    length.
>    >
>    > At this point, I have a problem.  If one adds three digits to
>    > "44160649" to make a number, then numbers have 11 digits.  But if
one
>    > adds four digits to "44160650", then numbers have 8 digits.
>=20
>    12 digits, you mean.
>=20
> Oops, yes.
>=20
>    > As far as I can tell, the solution to this contradiction is that
>    > "subscriber number" refers to the digits that are after the block
>    > prefix, and "initial digit string" refers to the digits that
compose
>    > the block prefix.
>=20
>    Right. The meaning of "block" varies - in the UK, the longest such
is
> (I
>    think) +44845464N, where there are no subsequent digits if N is 7
but 2
>    otherwise.
>=20
> OK, but make sure that you state that meaning of "subscriber number"
> clearly at the beginning, as it is unnatural to someone whose primary
> interface with the PSTN is through dialing calls.
>=20
> Perhaps I can sum up the above in a rule of thumb:  PSTN people tend
> to think of the grouping of numbers into blocks as intrinsic, and are
> constantly aware of where the block-prefix boundary is in a number.
> Everybody else is entirely unaware that numbers are grouped into
> blocks, and so any concept that hinges on the block structure must be
> explicitly explained as such.
>=20
>    > There is also the question of how this infrastructure interacts
with
>    > number portability, which leads to situations where any given
range
> of
>    > numbers is likely to be a mosaic of assignments to different
> carriers.
>=20
>    Do you mean open plans, or in general? I can't speak to open plans,
but
> at
>    least in the UK portability is unrelated to number length.
>=20
> The question isn't number length, but where the DNS zones are broken.
> Much current thinking assumes that the DNS zones are broken at the
> block boundaries.  This makes sense if all the numbers in a block are
> controlled by one carrier.  But if the numbers are controlled by
> different carriers, the block may be covered by a patchwork of DNS
> zones; in the worst case, each number could be a separate zone.
>=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 Wed Jan 17 09:20:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7Bdn-0006zC-Da; Wed, 17 Jan 2007 09:19:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Bdl-0006xc-04
	for enum@ietf.org; Wed, 17 Jan 2007 09:19:49 -0500
Received: from alnrmhc12.comcast.net ([204.127.225.92])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Bdj-000170-Q2
	for enum@ietf.org; Wed, 17 Jan 2007 09:19:48 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc12) with ESMTP
	id <20070117141947b1200jr93qe>; Wed, 17 Jan 2007 14:19: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 l0HEJkbM011988
	for <enum@ietf.org>; Wed, 17 Jan 2007 09:19:46 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0HEJkZl011984;
	Wed, 17 Jan 2007 09:19:46 -0500
Date: Wed, 17 Jan 2007 09:19:46 -0500
Message-Id: <200701171419.l0HEJkZl011984@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [Enum] draft-ietf-enum-unused-00.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

To isolate my point, let me quote the beginning of 7.2.1:

   In many countries closed numbering plans are in use.  In such a
   scheme, all valid telephone numbers have a defined length - the
   number of digits used for the subscriber number is fixed.

To me, this means a system like North America, +1, where all E.164
numbers (all subscriber numbers) have the same length (11 digits).

Dale

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



From enum-bounces@ietf.org Wed Jan 17 09:24:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7BiJ-0000QC-Ga; Wed, 17 Jan 2007 09:24:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BiI-0000Pi-Bi
	for enum@ietf.org; Wed, 17 Jan 2007 09:24:30 -0500
Received: from rwcrmhc14.comcast.net ([216.148.227.154])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7BiG-0001fU-3V
	for enum@ietf.org; Wed, 17 Jan 2007 09:24:30 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc14) with ESMTP
	id <20070117142426m140035g68e>; Wed, 17 Jan 2007 14:24:27 +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 l0HEOPbM012355
	for <enum@ietf.org>; Wed, 17 Jan 2007 09:24:25 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0HEOPMU012351;
	Wed, 17 Jan 2007 09:24:25 -0500
Date: Wed, 17 Jan 2007 09:24:25 -0500
Message-Id: <200701171424.l0HEOPMU012351@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <32755D354E6B65498C3BD9FD496C7D466469ED@oefeg-s04.oefeg.loc>
	(Richard.Stastny@oefeg.at)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D466469ED@oefeg-s04.oefeg.loc>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Stastny Richard" <Richard.Stastny@oefeg.at>

   We tried to give only the main examples how to use "unused" in
   the different numbering plans.

   And I have to admit, the issue is confusing

True.  But it seems that some critical issues in handling "unused"
regard interactions with numbering plans, so I think you're going to
have to explain numbering plans clearly.  You may be able to be
briefer (and so dodge having to explain some things) by describing
only open numbering plans, and their critical feature:  that numbers
not only differ in length, but they differ in length even within
allocation blocks, and are only set when a deal is reached with a
customer.

   The problem with "unused" in open numbering plans (what kind of
   ever) is, that you cannot say how long a number will be as long as
   it is not assigned.

   And the only way out of this in open numbering plans is the usage
   of the "Closest encloser"

Hmmm, has anyone implemented number portability within an open
numbering block?

Dale

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



From enum-bounces@ietf.org Wed Jan 17 09:31:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7BoX-0003Mm-Jp; Wed, 17 Jan 2007 09:30:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BoT-0003KP-Vf
	for enum@ietf.org; Wed, 17 Jan 2007 09:30:53 -0500
Received: from alnrmhc12.comcast.net ([206.18.177.52])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7BlC-00024Y-7x
	for enum@ietf.org; Wed, 17 Jan 2007 09:27:32 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc12) with ESMTP
	id <20070117142729b1200jp8mae>; Wed, 17 Jan 2007 14:27:29 +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 l0HERTbM012590
	for <enum@ietf.org>; Wed, 17 Jan 2007 09:27:29 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0HERTas012586;
	Wed, 17 Jan 2007 09:27:29 -0500
Date: Wed, 17 Jan 2007 09:27:29 -0500
Message-Id: <200701171427.l0HERTas012586@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <32755D354E6B65498C3BD9FD496C7D466469E7@oefeg-s04.oefeg.loc>
	(Richard.Stastny@oefeg.at)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D466469E7@oefeg-s04.oefeg.loc>
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Stastny Richard" <Richard.Stastny@oefeg.at>

   This has nothing to do with ISDN Subaddress

Is there a way to use a subaddress with a number that is translated
through ENUM?

Dale

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



From enum-bounces@ietf.org Wed Jan 17 09:31:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7BoS-0003K4-OX; Wed, 17 Jan 2007 09:30:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BoR-0003JD-Jm
	for enum@ietf.org; Wed, 17 Jan 2007 09:30:51 -0500
Received: from mx4.nominet.org.uk ([213.248.199.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7BoP-0003E3-Am
	for enum@ietf.org; Wed, 17 Jan 2007 09:30:51 -0500
Received: from unknown (HELO notes1.nominet.org.uk) ([213.248.197.128])
	by mx4.nominet.org.uk with ESMTP; 17 Jan 2007 14:30:48 +0000
X-IronPort-AV: i="4.13,199,1167609600"; d="scan'208"; a="6254080:sNHT38607404"
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466469EC@oefeg-s04.oefeg.loc>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>
Subject: RE: [Enum] Re: Unused-00 - CRUE
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V702MAC_11052006 November 05, 2006
Message-ID: <OF8B619747.4A0D6D8D-ON80257266.004F8069-80257266.004FB8B2@nominet.org.uk>
From: Jay Daley <jay@nominet.org.uk>
Date: Wed, 17 Jan 2007 14:30:46 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25,
	2006) at 17/01/2007 02:30:48 PM,
	Serialize complete at 17/01/2007 02:30:48 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: IETF ENUM WG <enum@ietf.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Richard

"Stastny Richard" <Richard.Stastny@oefeg.at> wrote on 17/01/2007 13:48:11:

> I think this is completely nonsense:

You are not alone.

> So either these paragraphs are cancelled or CRUE cannot be implemented.

If that is what the regulator wants then ...

> 
> I also consider this a bit weird:
> 
> "4.  The data about a participating telco's SIP gateways will be public.
> For security and operational 
> reasons, most telcos choose not publish details of their interconnect
> points and network topology. 
> They may not even disclose this to other telcos."
> 
> 
> Can one please explain to me how a telco may interconnect with other
> telcos if they do not disclose details of their interconnection points
> to them?

CRUE by definition is within the public tree.  This means that anyone, not 
just telcos can see this information.

Jay Daley
Nominet UK

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

From enum-bounces@ietf.org Wed Jan 17 09:32:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7Bpj-0003jU-2G; Wed, 17 Jan 2007 09:32:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Bpi-0003jO-6D
	for enum@ietf.org; Wed, 17 Jan 2007 09:32:10 -0500
Received: from alnrmhc13.comcast.net ([204.127.225.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Bpg-0003Wy-Vx
	for enum@ietf.org; Wed, 17 Jan 2007 09:32:10 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc13) with ESMTP
	id <20070117143208b1300329v8e>; Wed, 17 Jan 2007 14:32:08 +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 l0HEW7bM012915
	for <enum@ietf.org>; Wed, 17 Jan 2007 09:32:07 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0HEW7To012911;
	Wed, 17 Jan 2007 09:32:07 -0500
Date: Wed, 17 Jan 2007 09:32:07 -0500
Message-Id: <200701171432.l0HEW7To012911@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <32755D354E6B65498C3BD9FD496C7D466469EC@oefeg-s04.oefeg.loc>
	(Richard.Stastny@oefeg.at)
Subject: Re: [Enum] Re: Unused-00 - CRUE
References: <32755D354E6B65498C3BD9FD496C7D466469EC@oefeg-s04.oefeg.loc>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   CRUE says:

   If the name of the operating telco is immediately obvious from
   reading the name (e.g. sip1.bt.com) then this is not acceptable,
   but if it is not (e.g. sip1.internet.co.uk) then this is
   acceptable."

Has anyone pointed out to these people that "internet.co.uk" *is* an
immediatly obvious identifier for a company?

   "4.  The data about a participating telco's SIP gateways will be
   public.  For security and operational reasons, most telcos choose
   not publish details of their interconnect points and network
   topology.  They may not even disclose this to other telcos."

The only way this can make sense is if "interconnect points" and
"network topology" refers to PSTN interconnects, not PSTN-to-Internet
interconnects.

Dale

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



From enum-bounces@ietf.org Wed Jan 17 09:32:15 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7Bpn-0003rf-Cc; Wed, 17 Jan 2007 09:32:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Bpm-0003lu-0i
	for enum@ietf.org; Wed, 17 Jan 2007 09:32:14 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Bpk-0003XO-L2
	for enum@ietf.org; Wed, 17 Jan 2007 09:32: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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 15:31:22 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469F2@oefeg-s04.oefeg.loc>
In-Reply-To: <200701171419.l0HEJkZl011984@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6QoLECY5Pgb6nSvivwywHHyQ0UgAAYUUg
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

I have to admit that this sentence is not clear and
we will re-write it

Richard

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: Wednesday, January 17, 2007 3:20 PM
> To: enum@ietf.org
> Subject: [Enum] draft-ietf-enum-unused-00.txt
>=20
> To isolate my point, let me quote the beginning of 7.2.1:
>=20
>    In many countries closed numbering plans are in use.  In such a
>    scheme, all valid telephone numbers have a defined length - the
>    number of digits used for the subscriber number is fixed.
>=20
> To me, this means a system like North America, +1, where all E.164
> numbers (all subscriber numbers) have the same length (11 digits).
>=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 Wed Jan 17 09:37:25 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7Bui-00074R-Lc; Wed, 17 Jan 2007 09:37:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Buh-00074J-FO
	for enum@ietf.org; Wed, 17 Jan 2007 09:37:19 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Buf-0004Gw-0l
	for enum@ietf.org; Wed, 17 Jan 2007 09:37:19 -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] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 15:36:26 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469F3@oefeg-s04.oefeg.loc>
In-Reply-To: <200701171424.l0HEOPMU012351@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6QyyaksaNeDI4Sw+LdUjLP+8MdgAAR/tQ
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

> You may be able to be
> briefer (and so dodge having to explain some things) by describing
> only open numbering plans, and their critical feature:  that numbers
> not only differ in length, but they differ in length even within
> allocation blocks, and are only set when a deal is reached with a
> customer.

We will try to make the text more readable. Thanks for the comment.

> Hmmm, has anyone implemented number portability within an open
> numbering block?

Of course. And as you said, the length is set if it is assigned by
the donor and it stays the same length until is unassigned (and
falls back into the pool of the donor).

Richard

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: Wednesday, January 17, 2007 3:24 PM
> To: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>=20
>    From: "Stastny Richard" <Richard.Stastny@oefeg.at>
>=20
>    We tried to give only the main examples how to use "unused" in
>    the different numbering plans.
>=20
>    And I have to admit, the issue is confusing
>=20
> True.  But it seems that some critical issues in handling "unused"
> regard interactions with numbering plans, so I think you're going to
> have to explain numbering plans clearly.  You may be able to be
> briefer (and so dodge having to explain some things) by describing
> only open numbering plans, and their critical feature:  that numbers
> not only differ in length, but they differ in length even within
> allocation blocks, and are only set when a deal is reached with a
> customer.
>=20
>    The problem with "unused" in open numbering plans (what kind of
>    ever) is, that you cannot say how long a number will be as long as
>    it is not assigned.
>=20
>    And the only way out of this in open numbering plans is the usage
>    of the "Closest encloser"
>=20
> Hmmm, has anyone implemented number portability within an open
> numbering block?
>=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 Wed Jan 17 09:43:12 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7Bzy-0002FN-M8; Wed, 17 Jan 2007 09:42:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Bzx-0002Cw-CD
	for enum@ietf.org; Wed, 17 Jan 2007 09:42:45 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Bzw-0005Oz-1y
	for enum@ietf.org; Wed, 17 Jan 2007 09:42:45 -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] Re: Unused-00 - CRUE
Date: Wed, 17 Jan 2007 15:41:58 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469F4@oefeg-s04.oefeg.loc>
In-Reply-To: <200701171432.l0HEW7To012911@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Re: Unused-00 - CRUE
Thread-Index: Acc6RDTUec2PdCr0SM6GAn4p+VonWQAASZTw
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

>    "4.  The data about a participating telco's SIP gateways will be
>    public.  For security and operational reasons, most telcos choose
>    not publish details of their interconnect points and network
>    topology.  They may not even disclose this to other telcos."
>=20
> The only way this can make sense is if "interconnect points" and
> "network topology" refers to PSTN interconnects, not PSTN-to-Internet
> interconnects.

You forgot Internet-to-Internet Interconnection points.

The SIP URI in CRUE is to be used also for I2I interconnect

Richard

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



From enum-bounces@ietf.org Wed Jan 17 09:43:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7C0w-0002XD-Ks; Wed, 17 Jan 2007 09:43:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C0v-0002VX-4i
	for enum@ietf.org; Wed, 17 Jan 2007 09:43:45 -0500
Received: from mx4.nominet.org.uk ([213.248.199.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7C0s-0005VV-Sc
	for enum@ietf.org; Wed, 17 Jan 2007 09:43:45 -0500
Received: from unknown (HELO notes1.nominet.org.uk) ([213.248.197.128])
	by mx4.nominet.org.uk with ESMTP; 17 Jan 2007 14:43:42 +0000
X-IronPort-AV: i="4.13,199,1167609600"; d="scan'208"; a="6254206:sNHT32347084"
In-Reply-To: <200701171432.l0HEW7To012911@dragon.ariadne.com>
To: Dale.Worley@comcast.net
Subject: Re: [Enum] Re: Unused-00 - CRUE
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V702MAC_11052006 November 05, 2006
Message-ID: <OF185D28DC.DB36AEBD-ON80257266.0050A537-80257266.0050E6FC@nominet.org.uk>
From: Jay Daley <jay@nominet.org.uk>
Date: Wed, 17 Jan 2007 14:43:40 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25,
	2006) at 17/01/2007 02:43:41 PM,
	Serialize complete at 17/01/2007 02:43:41 PM
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Dale.Worley@comcast.net wrote on 17/01/2007 14:32:07:

>    CRUE says:
> 
>    If the name of the operating telco is immediately obvious from
>    reading the name (e.g. sip1.bt.com) then this is not acceptable,
>    but if it is not (e.g. sip1.internet.co.uk) then this is
>    acceptable."
> 
> Has anyone pointed out to these people that "internet.co.uk" *is* an
> immediatly obvious identifier for a company?

Yes. 

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



From enum-bounces@ietf.org Wed Jan 17 09:50:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7C6b-0006aq-Rc; Wed, 17 Jan 2007 09:49:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C6Z-0006aY-VT
	for enum@ietf.org; Wed, 17 Jan 2007 09:49:35 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7C6Y-0006QW-49
	for enum@ietf.org; Wed, 17 Jan 2007 09:49:35 -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] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 15:48:32 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D466469F5@oefeg-s04.oefeg.loc>
In-Reply-To: <200701171427.l0HERTas012586@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6RBIzbA90mRP6T+K+SeQOSKGjeAAAZ0RA
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

>=20
> Is there a way to use a subaddress with a number that is translated
> through ENUM?
>=20
This is a good question:

First: ENUM is only to be used for E.164 numbers. Since the SA is
not part of an E.164 number, it cannot be used by the originator
to be queried in ENUM.

It has to be signalled separately

This raises the question how to detect the SA part in a dialstring

I have no idea

Additional note: as far as I know there exist some parameters
to the tel: URI so signal isdn SA.

But this does not help ENUM

Richard


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



From enum-bounces@ietf.org Wed Jan 17 10:46:53 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7Czb-0003tu-23; Wed, 17 Jan 2007 10:46:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CzZ-0003t4-Pw
	for enum@ietf.org; Wed, 17 Jan 2007 10:46:25 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7CzY-0000pj-G1
	for enum@ietf.org; Wed, 17 Jan 2007 10:46:25 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2007 07:46:07 -0800
X-IronPort-AV: i="4.13,199,1167638400"; 
	d="scan'208"; a="50995038:sNHT48270537184"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0HFk6gF007621; 
	Wed, 17 Jan 2007 10:46:06 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0HFk6OA003000; 
	Wed, 17 Jan 2007 10:46:06 -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); 
	Wed, 17 Jan 2007 10:46:06 -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-unused-00.txt
Date: Wed, 17 Jan 2007 10:46:05 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <20070117083715.GA32449@finch-staff-1.thus.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6Ewcj4DyZ3dlaQrO75WwYUEbpJwAOtEhA
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Clive D.W. Feather" <clive@demon.net>, <Dale.Worley@comcast.net>
X-OriginalArrivalTime: 17 Jan 2007 15:46:06.0579 (UTC)
	FILETIME=[99D08C30:01C73A4E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1698; t=1169048766;
	x=1169912766; 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<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Enum]=20draft-ietf-enum-unused-00.txt
	|Sender:=20
	|To:=20=22Clive=20D.W.=20Feather=22=20<clive@demon.net>,
	=20<Dale.Worley@c omcast.net>;
	bh=fgQWH14cpLcK0hRkh0G6o1wa4XfLodsCI6hbU/iQM/Q=;
	b=Sp7rZLgAxlO81uP1aUzmyU21Rqplag06UzKXEiNK/GXAnyv0WfsP5GuacNVATMD/2JeQaYlw
	vMaQV9VDlYPNqKbDgtC98b1mXRouswnRX6IDznI5n/w5kjOhbjXkh7Bg;
Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Clive,

This may be a useful resource to you:
http://www.nationalnanpa.com/index.html

One comment below.

Mike


> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net]=20
> Sent: Wednesday, January 17, 2007 3:37 AM
> To: Dale.Worley@comcast.net
> Cc: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>=20
> Dale.Worley@comcast.net said:
> >    7.2.1.  Closed Numbering Plans
> >=20
> >    In many countries closed numbering plans are in use.  In such a
> >    scheme, all valid telephone numbers have a defined length - the
> >    number of digits used for the subscriber number is=20
> fixed.  Thus, for
> >    a given initial digit string, the length of the subsequent digit
> >    string together constituting a valid telephone number is=20
> known.  All
> >    other digit strings are invalid.
> >=20
> > As I read this, it means that all E.164 nubmers for a particular=20
> > country have the same length.
>=20
> No. It says that the first N digits (for some value of N=20
> which may depend on the number) tells you how long the number is.
>=20
> For example, in the UK, +442 or +447 tells you there is=20
> another 9 digits to come, but +441 or +448 doesn't - the=20
> length depends on more digits.
>=20
> > E.g., in North America, a subscriber
> > number is 10 digits (or 11 if you count the country code).
>=20
> Apparently not. I am told that numbers beginning +109 are a=20
> digit longer.

I do not believe this is a valid E.164 number.  There are no NPA
assigned starting with 0 or 1.

I suspect this is a dial string, where the 0 or 10 indicates request for
operator assistance.

[snip]

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



From enum-bounces@ietf.org Wed Jan 17 13:15:56 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7FJQ-0000Sh-Dg; Wed, 17 Jan 2007 13:15:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7FJP-0000Oe-Ep
	for enum@ietf.org; Wed, 17 Jan 2007 13:15:03 -0500
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7FJO-0003uk-2z
	for enum@ietf.org; Wed, 17 Jan 2007 13:15:03 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l0HI7IS21253; Wed, 17 Jan 2007 13:07:18 -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] draft-ietf-enum-unused-00.txt
Date: Wed, 17 Jan 2007 13:14:56 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA30F983FE8@zcarhxm0.corp.nortel.com>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466469F2@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6QoLECY5Pgb6nSvivwywHHyQ0UgAAYUUgAAdd0qA=
From: "James McEachern" <jmce@nortel.com>
To: <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: Stastny Richard <Richard.Stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Richard,=20
I agree it would be a good idea to rewrite this sentence.  While you are
at it, I suggest you look at the next sentence as well.  It currently
says:

"Thus, for a given initial digit string, the length of the subsequent
digit string together constituting a valid telephone number is known." =20

The problem is that this could be interpreted as saying that for *any*
initial digit string, the length of the ... valid telephone number is
known.  Clearly this is not the case for "+441606" - but since "+441606"
is "a given initial digit string" the existing text appears to imply
that it should.

BTW, I did eventually figure out what this section was saying, but it
took a while...

Jim

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20
Sent: Wednesday, January 17, 2007 9:31 AM
To: Dale.Worley@comcast.net; enum@ietf.org
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt

I have to admit that this sentence is not clear and
we will re-write it

Richard

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: Wednesday, January 17, 2007 3:20 PM
> To: enum@ietf.org
> Subject: [Enum] draft-ietf-enum-unused-00.txt
>=20
> To isolate my point, let me quote the beginning of 7.2.1:
>=20
>    In many countries closed numbering plans are in use.  In such a
>    scheme, all valid telephone numbers have a defined length - the
>    number of digits used for the subscriber number is fixed.
>=20
> To me, this means a system like North America, +1, where all E.164
> numbers (all subscriber numbers) have the same length (11 digits).
>=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

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



From enum-bounces@ietf.org Wed Jan 17 17:24:06 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7JBW-0003hT-MH; Wed, 17 Jan 2007 17:23:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JBV-0003hB-I1
	for enum@ietf.org; Wed, 17 Jan 2007 17:23:09 -0500
Received: from sccrmhc15.comcast.net ([63.240.77.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JBT-0006IM-Az
	for enum@ietf.org; Wed, 17 Jan 2007 17:23:09 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc15) with ESMTP
	id <2007011722230601500s9q2qe>; Wed, 17 Jan 2007 22:23: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 l0HMN6bM014785
	for <enum@ietf.org>; Wed, 17 Jan 2007 17:23:06 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0HMN6xD014781;
	Wed, 17 Jan 2007 17:23:06 -0500
Date: Wed, 17 Jan 2007 17:23:06 -0500
Message-Id: <200701172223.l0HMN6xD014781@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
	(mhammer@cisco.com)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: Clive D.W. Feather [mailto:clive@demon.net] 
   
   Apparently not. I am told that numbers beginning +109 are a 
   digit longer.

   From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>

   This may be a useful resource to you:
   http://www.nationalnanpa.com/index.html

I see from http://www.nationalnanpa.com/area_codes/index.html that the
prefixes +1 [1-9]9[0-9] are described "The 80 codes in this format,
called expansion codes, have been reserved for use during the period
when the current 10-digit NANP number format undergoes expansion."

I suspect that this means that there is a standby plan to extend the
"area code" (first three digits) to four digits, by mapping

+1 xxx yyy zzzz -> +1 x9xx yyy zzzz

This would lead to "the numbers beginning +1x9 are a digit longer".

Dale

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



From enum-bounces@ietf.org Wed Jan 17 17:29:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7JHV-0006r4-7b; Wed, 17 Jan 2007 17:29:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JHT-0006qw-NK
	for enum@ietf.org; Wed, 17 Jan 2007 17:29:19 -0500
Received: from rwcrmhc12.comcast.net ([204.127.192.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JHS-00071Z-FM
	for enum@ietf.org; Wed, 17 Jan 2007 17:29:19 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc12) with ESMTP
	id <20070117222915m12002o761e>; Wed, 17 Jan 2007 22:29:15 +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 l0HMTEbM015269
	for <enum@ietf.org>; Wed, 17 Jan 2007 17:29:14 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0HMTEMx015265;
	Wed, 17 Jan 2007 17:29:14 -0500
Date: Wed, 17 Jan 2007 17:29:14 -0500
Message-Id: <200701172229.l0HMTEMx015265@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <32755D354E6B65498C3BD9FD496C7D466469F5@oefeg-s04.oefeg.loc>
	(Richard.Stastny@oefeg.at)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D466469F5@oefeg-s04.oefeg.loc>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Stastny Richard" <Richard.Stastny@oefeg.at>

   Additional note: as far as I know there exist some parameters
   to the tel: URI so signal isdn SA.

In RFC 3966:

5.2.  ISDN Subaddresses

   A phone number MAY also contain an 'isdn-subaddress' parameter that
   indicates an ISDN subaddress.
   ISDN subaddresses typically contain International Alphabet 5 (IA5
   [T.50]) characters but may contain any octet value.

Note that the BNF variable for this parameter is "isdn-subaddress",
but the parameter name itself is "isub".

It would be sensible if the ENUM resolution process attached the isub
parameter from the tel URI onto the SIP URI obtained from resolution,
but I don't think there is any specification for that.

Dale

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



From enum-bounces@ietf.org Wed Jan 17 17:47:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7JYV-00009N-FO; Wed, 17 Jan 2007 17:46:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JYT-0008TJ-WF
	for enum@ietf.org; Wed, 17 Jan 2007 17:46:54 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7JYS-0000Y7-AT
	for enum@ietf.org; Wed, 17 Jan 2007 17:46:53 -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-unused-00.txt
Date: Wed, 17 Jan 2007 23:43:05 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C61@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6huEIpHWi/10PTbKbhxC124wPVQAAfkfZ
References: <32755D354E6B65498C3BD9FD496C7D466469F5@oefeg-s04.oefeg.loc>
	<200701172229.l0HMTEMx015265@dragon.ariadne.com>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

>It would be sensible if the ENUM resolution process attached the isub
>parameter from the tel URI onto the SIP URI obtained from resolution,
>but I don't think there is any specification for that.

This is not the problem - a tel: or sip: URI in an ENUM NAPTR
may always contain the isdn-subaddress

The problem is that you cannot query an E.164 number + SA
in ENUM and e.g. get different results for each SA
=20
Richard


________________________________

Von: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
Gesendet: Mi 17.01.2007 23:29
An: enum@ietf.org
Betreff: Re: [Enum] draft-ietf-enum-unused-00.txt



   From: "Stastny Richard" <Richard.Stastny@oefeg.at>

   Additional note: as far as I know there exist some parameters
   to the tel: URI so signal isdn SA.

In RFC 3966:

5.2.  ISDN Subaddresses

   A phone number MAY also contain an 'isdn-subaddress' parameter that
   indicates an ISDN subaddress.
   ISDN subaddresses typically contain International Alphabet 5 (IA5
   [T.50]) characters but may contain any octet value.

Note that the BNF variable for this parameter is "isdn-subaddress",
but the parameter name itself is "isub".

It would be sensible if the ENUM resolution process attached the isub
parameter from the tel URI onto the SIP URI obtained from resolution,
but I don't think there is any specification for that.

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 Wed Jan 17 18:44:56 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7KS7-0002Qd-U2; Wed, 17 Jan 2007 18:44:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KS6-0002Lg-7r
	for enum@ietf.org; Wed, 17 Jan 2007 18:44:22 -0500
Received: from shaun.rfc1035.com ([195.54.233.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7KS1-0007qx-1j
	for enum@ietf.org; Wed, 17 Jan 2007 18:44:22 -0500
Received: from [212.158.216.75] (account jim HELO [10.59.1.115])
	by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4)
	with ESMTPSA id 141103; Wed, 17 Jan 2007 23:44:13 +0000
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466469EC@oefeg-s04.oefeg.loc>
References: <32755D354E6B65498C3BD9FD496C7D466469EC@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: <10CA84D8-5D9D-486F-838A-A1C93756B6B4@rfc1035.com>
Content-Transfer-Encoding: 7bit
From: Jim Reid <jim@rfc1035.com>
Subject: Re: [Enum] Re: Unused-00 - CRUE
Date: Wed, 17 Jan 2007 23:43:15 +0000
To: "Stastny Richard" <Richard.Stastny@oefeg.at>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: Jay Daley <jay@nominet.org.uk>, IETF ENUM WG <enum@ietf.org>,
	lconroy <lconroy@insensate.co.uk>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: thebitbucket@rfc1035.com
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On Jan 17, 2007, at 13:48, Stastny Richard wrote:

> After reading the mentioned CRUE document, I have some comments:

Until the CRUE document surfaces in this WG as an I-D I think it is  
out of scope for this list. Any followup discussion about the merits  
or otherwise of this scheme should take place elsewhere.

> I think this is completely nonsense:

So what?

> Since CRUE requires that all entries of a Carrier are the same,
> one simple has to look up one number he knows which carrier it is,
> Retrieve the domain name and then he looks up the number in question
>
> This is not even secrecy by obscurity.

Nobody is claiming it is "secure" or "anonymising". As far as the  
Regulator is concerned, obscuring the name of the sip server as  
proposed is good enough. [It raises a barrier that will deter the  
average citizen, but wouldn't make any difference to the tiny  
percentage of the planet that has a clue about how the internet  
works.] You Richard don't have to like it or implement CRUE, just as  
I don't have to like or implement the eccentricities of the Austrian  
telephone numbering plan. CRUE is a UK matter, at least in the first  
instance. If you want to improve that document, feel free to  
participate in UK ENUM meetings.

CRUE isn't even up for discussion in this WG yet: nobody's submitted  
a draft or proposed it as a work item.

> So you could as well enter bt.com in the first place.
>
> So either these paragraphs are cancelled or CRUE cannot be  
> implemented.

Richard, I humbly suggest you take these remarks elsewhere. As  
currently proposed, CRUE *has* been implemented and there is  
considerable interest from Communication Service Providers in the UK  
in using this scheme once commercial ENUM activities start under  
4.4.e164.arpa. So what you've said here is 100% wrong.

> Can one please explain to me how a telco may interconnect with other
> telcos if they do not disclose details of their interconnection points
> to them?

You have completely missed the point. All this section of the CRUE  
document does is illustrate one of the potential drawbacks of  
participating. Whether CRUE is or isn't used for interconnect is  
irrelevant. The idea was originally developed for an entirely  
different objective, namely bulk data population of 4.4.e164.arpa =>  
increased use of ENUM-aware software and services because lookups  
would be more likely to get meaningful data back from the DNS. That  
the data entered using CRUE *might* be used for interconnect or for  
SIP peering is fortunate side-effect.

Can we all now please shut up about CRUE and get back to commenting  
on enum-unused-03? Thanks.

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



From enum-bounces@ietf.org Wed Jan 17 18:47:25 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7KV2-0003eU-OZ; Wed, 17 Jan 2007 18:47:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KV1-0003eD-PB
	for enum@ietf.org; Wed, 17 Jan 2007 18:47:23 -0500
Received: from shaun.rfc1035.com ([195.54.233.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7KV0-00087y-EQ
	for enum@ietf.org; Wed, 17 Jan 2007 18:47:23 -0500
Received: from [212.158.216.75] (account jim HELO [10.59.1.115])
	by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4)
	with ESMTPSA id 141108; Wed, 17 Jan 2007 23:47:21 +0000
In-Reply-To: <200701171432.l0HEW7To012911@dragon.ariadne.com>
References: <32755D354E6B65498C3BD9FD496C7D466469EC@oefeg-s04.oefeg.loc>
	<200701171432.l0HEW7To012911@dragon.ariadne.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F4781C3A-0807-456C-87C5-638B274E630E@rfc1035.com>
Content-Transfer-Encoding: 7bit
From: Jim Reid <jim@rfc1035.com>
Subject: Re: [Enum] Re: Unused-00 - CRUE
Date: Wed, 17 Jan 2007 23:46:24 +0000
To: Dale.Worley@comcast.net
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On Jan 17, 2007, at 14:32, Dale.Worley@comcast.net wrote:

> Has anyone pointed out to these people that "internet.co.uk" *is* an
> immediatly obvious identifier for a company?

<scarcasm on>
WHAT??? Do you mean someone can *do that* with a domain name?
<\scarcasm>

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



From enum-bounces@ietf.org Thu Jan 18 10:07:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7YqU-00006Y-IA; Thu, 18 Jan 2007 10:06:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YqT-0008Sx-8v
	for enum@ietf.org; Thu, 18 Jan 2007 10:06:29 -0500
Received: from sccrmhc11.comcast.net ([204.127.200.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7YqS-0005Ih-2T
	for enum@ietf.org; Thu, 18 Jan 2007 10:06:29 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc11) with ESMTP
	id <2007011815062701100hj7d6e>; Thu, 18 Jan 2007 15:06:27 +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 l0IF6QbM023758
	for <enum@ietf.org>; Thu, 18 Jan 2007 10:06:26 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0IF6QqV023754;
	Thu, 18 Jan 2007 10:06:26 -0500
Date: Thu, 18 Jan 2007 10:06:26 -0500
Message-Id: <200701181506.l0IF6QqV023754@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <32755D354E6B65498C3BD9FD496C7D462C4C61@oefeg-s04.oefeg.loc>
	(Richard.Stastny@oefeg.at)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D466469F5@oefeg-s04.oefeg.loc>
	<200701172229.l0HMTEMx015265@dragon.ariadne.com>
	<32755D354E6B65498C3BD9FD496C7D462C4C61@oefeg-s04.oefeg.loc>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Stastny Richard" <Richard.Stastny@oefeg.at>

   >It would be sensible if the ENUM resolution process attached the isub
   >parameter from the tel URI onto the SIP URI obtained from resolution,
   >but I don't think there is any specification for that.

   This is not the problem - a tel: or sip: URI in an ENUM NAPTR
   may always contain the isdn-subaddress

Yes, but if I write "tel:12125551212;isub=1234" the isub information
is lost when it is resolved into a SIP URI.  Or at least, as far as I
can figure out from a quick scan of RFC 3761 and 3764.  Ideally, the
ENUM resolution process would specify that the isub parameter would be
carried from the tel: URI to the sip: URI.

   The problem is that you cannot query an E.164 number + SA in ENUM
   and e.g. get different results for each SA

True, though presently I don't see that as a major problem, because
the E.164 number has to be allocated to one customer, who can then run
a proxy that will forward requests based on SA to various
destinations.

Hmmmm, in some models of User-ENUM, a user could install ENUM records
not for his E.164 number, but for longer numbers with that E.164
number as prefix, and achieve an effect much like what you want.

Dale

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



From enum-bounces@ietf.org Thu Jan 18 10:50:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7ZWg-00006D-Az; Thu, 18 Jan 2007 10:50:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZWe-000053-Qq
	for enum@ietf.org; Thu, 18 Jan 2007 10:50:04 -0500
Received: from [62.47.121.5] (helo=mail.oefeg.at)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7ZWa-0004gV-23
	for enum@ietf.org; Thu, 18 Jan 2007 10:50: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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Thu, 18 Jan 2007 16:49:21 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D46646A13@oefeg-s04.oefeg.loc>
In-Reply-To: <200701181506.l0IF6QqV023754@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc7ElVjvbGviTSjRtKY8P74Wn5xrgABXl5w
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Dale.Worley@comcast.net>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

> Yes, but if I write "tel:12125551212;isub=3D1234" the isub information
> is lost when it is resolved into a SIP URI.

No, you can carry all tel parameters to the sip URI
sip:+12125551212;isub=3D1234@provider.net

> Hmmmm, in some models of User-ENUM, a user could install ENUM records
> not for his E.164 number, but for longer numbers with that E.164
> number as prefix, and achieve an effect much like what you want.

I do not think that this is possible

Richard

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: Thursday, January 18, 2007 4:06 PM
> To: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>=20
>    From: "Stastny Richard" <Richard.Stastny@oefeg.at>
>=20
>    >It would be sensible if the ENUM resolution process attached the
isub
>    >parameter from the tel URI onto the SIP URI obtained from
resolution,
>    >but I don't think there is any specification for that.
>=20
>    This is not the problem - a tel: or sip: URI in an ENUM NAPTR
>    may always contain the isdn-subaddress
>=20
> Yes, but if I write "tel:12125551212;isub=3D1234" the isub information
> is lost when it is resolved into a SIP URI.  Or at least, as far as I
> can figure out from a quick scan of RFC 3761 and 3764.  Ideally, the
> ENUM resolution process would specify that the isub parameter would be
> carried from the tel: URI to the sip: URI.
>=20
>    The problem is that you cannot query an E.164 number + SA in ENUM
>    and e.g. get different results for each SA
>=20
> True, though presently I don't see that as a major problem, because
> the E.164 number has to be allocated to one customer, who can then run
> a proxy that will forward requests based on SA to various
> destinations.
>=20
> Hmmmm, in some models of User-ENUM, a user could install ENUM records
> not for his E.164 number, but for longer numbers with that E.164
> number as prefix, and achieve an effect much like what you want.
>=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 Jan 18 12:45:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bKY-0005zB-Rw; Thu, 18 Jan 2007 12:45:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bKX-0005si-DJ; Thu, 18 Jan 2007 12:45:41 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H7bKV-0002ue-JC; Thu, 18 Jan 2007 12:45:41 -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
	l0IHjRu3010475; Thu, 18 Jan 2007 09:45:34 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <iesg-secretary@ietf.org>, <enum@ietf.org>
Date: Thu, 18 Jan 2007 12:45:18 -0500
Message-ID: <087b01c73b28$6c0f9680$85211f0a@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.3028
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYg==
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: 21c69d3cfc2dd19218717dbe1d974352
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	=?us-ascii?Q?'Patrik_Faltstrom'?= <paf@cisco.com>,
	'Jon Peterson' <jon.peterson@neustar.biz>
Subject: [Enum] Request for Publication -
	draft-ietf-enum-branch-location-record-02.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


	Title		: The ENUM Branch Location Record
	Author(s)	: O. Lendl
	Filename	: draft-ietf-enum-branch-location-record-02.txt
	Pages		: 9
	Date		: 2006-12-12
	
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-0
2.txt



This document has been extensively discussed in the WG in 2005 and 2006

This is a request for publication for one IETF ENUM WG working group
document.

A two week WG last call on this document concluded on January 15, 2007.

There were no additional comments from the last call.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:57141@fwd.pulver.com
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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

From enum-bounces@ietf.org Thu Jan 18 12:45:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bK4-0005F1-4x; Thu, 18 Jan 2007 12:45:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bK2-0005Eg-DE; Thu, 18 Jan 2007 12:45:10 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H7bJz-0002sb-T0; Thu, 18 Jan 2007 12:45:10 -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
	l0IHitj3010379; Thu, 18 Jan 2007 09:45:02 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <iesg-secretary@ietf.org>, <enum@ietf.org>
Date: Thu, 18 Jan 2007 12:44:45 -0500
Message-ID: <087a01c73b28$58b0f070$85211f0a@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.3028
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYg==
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: cab78e1e39c4b328567edb48482b6a69
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	=?us-ascii?Q?'Patrik_Faltstrom'?= <paf@cisco.com>,
	'Jon Peterson' <jon.peterson@neustar.biz>
Subject: [Enum] Request for Publication -  draft-ietf-enum-combined-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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Title		: Combined User and Infrastructure ENUM in the
e164.arpa tree
	Author(s)	: M. Haberler, R. Stastny
	Filename	: draft-ietf-enum-combined-03.txt
	Pages		: 12
	Date		: 2006-12-15
	
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-03.txt

This document has been extensively discussed in the WG in 2005, 2006.

This is a request for publication for one IETF ENUM WG working group
document.

A two week WG last call on this document concluded on January 15, 2007.

There were no additional comments from the last call.

The document listed above is intended to be Informaitonal.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:57141@fwd.pulver.com
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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





From enum-bounces@ietf.org Thu Jan 18 12:45:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bKY-0005zB-Rw; Thu, 18 Jan 2007 12:45:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bKX-0005si-DJ; Thu, 18 Jan 2007 12:45:41 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H7bKV-0002ue-JC; Thu, 18 Jan 2007 12:45:41 -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
	l0IHjRu3010475; Thu, 18 Jan 2007 09:45:34 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <iesg-secretary@ietf.org>, <enum@ietf.org>
Date: Thu, 18 Jan 2007 12:45:18 -0500
Message-ID: <087b01c73b28$6c0f9680$85211f0a@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.3028
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYg==
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: 21c69d3cfc2dd19218717dbe1d974352
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	=?us-ascii?Q?'Patrik_Faltstrom'?= <paf@cisco.com>,
	'Jon Peterson' <jon.peterson@neustar.biz>
Subject: [Enum] Request for Publication -
	draft-ietf-enum-branch-location-record-02.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


	Title		: The ENUM Branch Location Record
	Author(s)	: O. Lendl
	Filename	: draft-ietf-enum-branch-location-record-02.txt
	Pages		: 9
	Date		: 2006-12-12
	
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-0
2.txt



This document has been extensively discussed in the WG in 2005 and 2006

This is a request for publication for one IETF ENUM WG working group
document.

A two week WG last call on this document concluded on January 15, 2007.

There were no additional comments from the last call.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:57141@fwd.pulver.com
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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

From enum-bounces@ietf.org Thu Jan 18 12:45:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bK4-0005F1-4x; Thu, 18 Jan 2007 12:45:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bK2-0005Eg-DE; Thu, 18 Jan 2007 12:45:10 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H7bJz-0002sb-T0; Thu, 18 Jan 2007 12:45:10 -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
	l0IHitj3010379; Thu, 18 Jan 2007 09:45:02 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <iesg-secretary@ietf.org>, <enum@ietf.org>
Date: Thu, 18 Jan 2007 12:44:45 -0500
Message-ID: <087a01c73b28$58b0f070$85211f0a@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.3028
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYg==
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: cab78e1e39c4b328567edb48482b6a69
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	=?us-ascii?Q?'Patrik_Faltstrom'?= <paf@cisco.com>,
	'Jon Peterson' <jon.peterson@neustar.biz>
Subject: [Enum] Request for Publication -  draft-ietf-enum-combined-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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Title		: Combined User and Infrastructure ENUM in the
e164.arpa tree
	Author(s)	: M. Haberler, R. Stastny
	Filename	: draft-ietf-enum-combined-03.txt
	Pages		: 12
	Date		: 2006-12-15
	
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-03.txt

This document has been extensively discussed in the WG in 2005, 2006.

This is a request for publication for one IETF ENUM WG working group
document.

A two week WG last call on this document concluded on January 15, 2007.

There were no additional comments from the last call.

The document listed above is intended to be Informaitonal.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:57141@fwd.pulver.com
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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





From enum-bounces@ietf.org Thu Jan 18 12:53:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bRc-0003Kh-Ff; Thu, 18 Jan 2007 12:53:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7bRb-0003Kb-Az; Thu, 18 Jan 2007 12:52:59 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H7bRZ-0003Ur-U2; Thu, 18 Jan 2007 12:52:59 -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
	l0IHqT7o011586; Thu, 18 Jan 2007 09:52:42 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <iesg-secretary@ietf.org>, <enum@ietf.org>
Date: Thu, 18 Jan 2007 12:52:15 -0500
Message-ID: <088101c73b29$6736c8d0$85211f0a@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYg==
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: 21c69d3cfc2dd19218717dbe1d974352
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= <paf@cisco.com>,
	'Jon Peterson' <jon.peterson@neustar.biz>
Subject: [Enum] Request for Publication -
	draft-ietf-enum-infrastructure-04.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


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-04.txt
	Pages		: 6
	Date		: 2007-1-2
	
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-04.txt

This document has been extensively discussed in the WG in 2005 and 2006.

This is a request for publication for one IETF ENUM WG working group
document.

A two week WG last call on this document concluded on January 18, 2007.

There were no additional comments from the last call.

The document listed above is intended to Informational.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:57141@fwd.pulver.com
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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



From enum-bounces@ietf.org Thu Jan 18 15:49:55 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7eBv-0007Cz-7t; Thu, 18 Jan 2007 15:48:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eBu-0007CN-1i
	for enum@ietf.org; Thu, 18 Jan 2007 15:48:58 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eBs-0005l1-OF
	for enum@ietf.org; Thu, 18 Jan 2007 15:48:58 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 15:48:56 -0500
X-IronPort-AV: i="4.13,206,1167627600"; 
	d="scan'208"; a="111987492:sNHT46986946"
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 l0IKmusE024383; 
	Thu, 18 Jan 2007 15:48:56 -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 l0IKmuVT004986; 
	Thu, 18 Jan 2007 15:48:56 -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); 
	Thu, 18 Jan 2007 15:48: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-unused-00.txt
Date: Thu, 18 Jan 2007 15:48:55 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302780D3C@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <200701172223.l0HMN6xD014781@dragon.ariadne.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc6hlur35Hm0442QziXMXaeHL3x5AAuy9QQ
References: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
	<200701172223.l0HMN6xD014781@dragon.ariadne.com>
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: <Dale.Worley@comcast.net>, <enum@ietf.org>
X-OriginalArrivalTime: 18 Jan 2007 20:48:56.0344 (UTC)
	FILETIME=[12406980:01C73B42]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1443; t=1169153336;
	x=1170017336; 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<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Enum]=20draft-ietf-enum-unused-00.txt
	|Sender:=20
	|To:=20<Dale.Worley@comcast.net>,=20<enum@ietf.org>;
	bh=7qJs/hOdEKf7gh0kKCsKyKNSgOkAr58M0jqnrB6CbWc=;
	b=DJ5UmdZ524J82RDvby1fp1p28JmkZGB7c4aBN09x2nDlh6ZBQfChfb+YEL8AMcty+yiRYs6D
	YlSCk3vF5HXHIu2uZXRiFNrSI4POVI9UioDBExG8y13R6MGuEz4XLPVb;
Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Dale,

Good point.  But, to be clear, the first digit after +1 will not be 0.

Area codes:  19xx, 29xx, 39xx, 49xx, 59xx, 69xx, 79xx, 89xx, 99xx

Mike=20

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20
> Sent: Wednesday, January 17, 2007 5:23 PM
> To: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>=20
>    From: Clive D.W. Feather [mailto:clive@demon.net]=20
>   =20
>    Apparently not. I am told that numbers beginning +109 are a=20
>    digit longer.
>=20
>    From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
>=20
>    This may be a useful resource to you:
>    http://www.nationalnanpa.com/index.html
>=20
> I see from http://www.nationalnanpa.com/area_codes/index.html=20
> that the prefixes +1 [1-9]9[0-9] are described "The 80 codes=20
> in this format, called expansion codes, have been reserved=20
> for use during the period when the current 10-digit NANP=20
> number format undergoes expansion."
>=20
> I suspect that this means that there is a standby plan to=20
> extend the "area code" (first three digits) to four digits, by mapping
>=20
> +1 xxx yyy zzzz -> +1 x9xx yyy zzzz
>=20
> This would lead to "the numbers beginning +1x9 are a digit longer".
>=20
> Dale
>=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 Thu Jan 18 16:23:36 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7eix-00047W-LW; Thu, 18 Jan 2007 16:23:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eiw-000479-2G
	for enum@ietf.org; Thu, 18 Jan 2007 16:23:06 -0500
Received: from rwcrmhc12.comcast.net ([204.127.192.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eiu-000479-QU
	for enum@ietf.org; Thu, 18 Jan 2007 16:23:06 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc12) with ESMTP
	id <20070118212247m12002lahge>; Thu, 18 Jan 2007 21:23:03 +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 l0ILMkbM018737
	for <enum@ietf.org>; Thu, 18 Jan 2007 16:22:46 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0ILMkeu018733;
	Thu, 18 Jan 2007 16:22:46 -0500
Date: Thu, 18 Jan 2007 16:22:46 -0500
Message-Id: <200701182122.l0ILMkeu018733@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <32755D354E6B65498C3BD9FD496C7D46646A13@oefeg-s04.oefeg.loc>
	(Richard.Stastny@oefeg.at)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D46646A13@oefeg-s04.oefeg.loc>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Stastny Richard" <Richard.Stastny@oefeg.at>

   > Yes, but if I write "tel:12125551212;isub=1234" the isub information
   > is lost when it is resolved into a SIP URI.

   No, you can carry all tel parameters to the sip URI
   sip:+12125551212;isub=1234@provider.net

But I don't see any prescription anywhere that you *should*, and
without that, many resolvers *won't*.

   > Hmmmm, in some models of User-ENUM, a user could install ENUM records
   > not for his E.164 number, but for longer numbers with that E.164
   > number as prefix, and achieve an effect much like what you want.

   I do not think that this is possible

It depends on how your DNS is managed.  But it would be a hack and not
be assured of interoperability.

Dale

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



From enum-bounces@ietf.org Thu Jan 18 16:59:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7fHX-0004s3-DP; Thu, 18 Jan 2007 16:58:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7fHW-0004ry-BA
	for enum@ietf.org; Thu, 18 Jan 2007 16:58:50 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7fHV-0000mV-14
	for enum@ietf.org; Thu, 18 Jan 2007 16:58:50 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 16:58:49 -0500
X-IronPort-AV: i="4.13,206,1167627600"; 
	d="scan'208"; a="111992455:sNHT49340126"
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/8.12.11) with ESMTP id l0ILwmfO009629; 
	Thu, 18 Jan 2007 16:58:48 -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 l0ILwmOA017470; 
	Thu, 18 Jan 2007 16:58:48 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 18 Jan 2007 16:58:48 -0500
Received: from [161.44.182.244] ([161.44.182.244]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 18 Jan 2007 16:58:48 -0500
Message-ID: <45AFED98.1070907@cisco.com>
Date: Thu, 18 Jan 2007 16:58:48 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D46646A13@oefeg-s04.oefeg.loc>
	<200701182122.l0ILMkeu018733@dragon.ariadne.com>
In-Reply-To: <200701182122.l0ILMkeu018733@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jan 2007 21:58:48.0331 (UTC)
	FILETIME=[D4DEDDB0:01C73B4B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1568; t=1169157528;
	x=1170021528; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Enum]=20draft-ietf-enum-unused-00.txt
	|Sender:=20 |To:=20Dale.Worley@comcast.net;
	bh=VMi1q9ULGiSUBFi3lXmrDbaQStV6yJIPiJVEivnDRMQ=;
	b=Oh5QbAqS+dRWiXoF7bbh7hwwgJDe+ki9ffRT3RK/D40IpC7IhxVVqUmY94oO7XW74ayCra1M
	b82UBPyvqvVZlVqOrKooS935fmodeZz91ZY3yBMto8brmFUjaBNaExTa;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



Dale.Worley@comcast.net wrote:
>    From: "Stastny Richard" <Richard.Stastny@oefeg.at>
> 
>    > Yes, but if I write "tel:12125551212;isub=1234" the isub information
>    > is lost when it is resolved into a SIP URI.
> 
>    No, you can carry all tel parameters to the sip URI
>    sip:+12125551212;isub=1234@provider.net
> 
> But I don't see any prescription anywhere that you *should*, and
> without that, many resolvers *won't*.

So is Richard suggesting that if the enum mapping is:
    tel:12125551212 => sip:+12125551212@provider.net

then the following should also occur:
    tel:12125551212;isub=1234 => sip:+12125551212;isub=1234@provider.net

???

I am certainly not aware of how you would get that to happen.
Even if you could, what if the enum mapping is:

    tel:12125551212 => sip:john.doe@provider.net

Do you then want the following mapping to also occur:

    tel:12125551212;isub=1234 => sip:john.doe;isub=1234@provider.net

That seems rather inappropriate to me.

	Paul

>    > Hmmmm, in some models of User-ENUM, a user could install ENUM records
>    > not for his E.164 number, but for longer numbers with that E.164
>    > number as prefix, and achieve an effect much like what you want.
> 
>    I do not think that this is possible
> 
> It depends on how your DNS is managed.  But it would be a hack and not
> be assured of interoperability.
> 
> 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 Thu Jan 18 20:41:33 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7ik4-0003xt-V3; Thu, 18 Jan 2007 20:40:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ik4-0003xo-Iy
	for enum@ietf.org; Thu, 18 Jan 2007 20:40:32 -0500
Received: from alnrmhc14.comcast.net ([204.127.225.94])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ik3-0002Zy-Bz
	for enum@ietf.org; Thu, 18 Jan 2007 20:40:32 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc14) with ESMTP
	id <20070119014030b1400rn0tse>; Fri, 19 Jan 2007 01:40:30 +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 l0J1eTbM005121
	for <enum@ietf.org>; Thu, 18 Jan 2007 20:40:29 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0J1eTR1005117;
	Thu, 18 Jan 2007 20:40:29 -0500
Date: Thu, 18 Jan 2007 20:40:29 -0500
Message-Id: <200701190140.l0J1eTR1005117@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <45AFED98.1070907@cisco.com> (pkyzivat@cisco.com)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D46646A13@oefeg-s04.oefeg.loc>
	<200701182122.l0ILMkeu018733@dragon.ariadne.com>
	<45AFED98.1070907@cisco.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: Paul Kyzivat <pkyzivat@cisco.com>

   So is Richard suggesting that if the enum mapping is:
       tel:12125551212 => sip:+12125551212@provider.net

   then the following should also occur:
       tel:12125551212;isub=1234 => sip:+12125551212;isub=1234@provider.net

I'm thinking that this would be a good idea:

tel:12125551212;isub=1234 => sip:+12125551212@provider.net;isub=1234

   I am certainly not aware of how you would get that to happen.
   Even if you could, what if the enum mapping is:

       tel:12125551212 => sip:john.doe@provider.net

   Do you then want the following mapping to also occur:

       tel:12125551212;isub=1234 => sip:john.doe;isub=1234@provider.net

   That seems rather inappropriate to me.

But consider:

tel:12125551212;isub=1234 => sip:john.doe@provider.net;isub=1234

If UAs ignore URI-parameters that they don't understand, it's
upward-compatible.

Dale

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



From enum-bounces@ietf.org Fri Jan 19 03:33:01 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7pAA-0004y0-Cv; Fri, 19 Jan 2007 03:31:54 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7pA9-0004xs-5X
	for enum@ietf.org; Fri, 19 Jan 2007 03:31:53 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7pA7-00053Y-0b
	for enum@ietf.org; Fri, 19 Jan 2007 03:31:52 -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 l0J8VkFR007517Fri, 19 Jan 2007 08:31:46 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H7pA2-000GB2-00; Fri, 19 Jan 2007 08:31:46 +0000
Date: Fri, 19 Jan 2007 08:31:46 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: Dale.Worley@comcast.net
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070119083146.GK53247@finch-staff-1.thus.net>
References: <200701161632.l0GGWKqh024459@dragon.ariadne.com>
	<20070117083715.GA32449@finch-staff-1.thus.net>
	<200701171323.l0HDNMHO007854@dragon.ariadne.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200701171323.l0HDNMHO007854@dragon.ariadne.com>
User-Agent: Mutt/1.5.3i
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Dale.Worley@comcast.net said:
>    > There is also the question of how this infrastructure interacts with
>    > number portability, which leads to situations where any given range of
>    > numbers is likely to be a mosaic of assignments to different carriers.
> 
>    Do you mean open plans, or in general? I can't speak to open plans, but at
>    least in the UK portability is unrelated to number length.
> 
> The question isn't number length, but where the DNS zones are broken.
> Much current thinking assumes that the DNS zones are broken at the
> block boundaries.  This makes sense if all the numbers in a block are
> controlled by one carrier.  But if the numbers are controlled by
> different carriers, the block may be covered by a patchwork of DNS
> zones; in the worst case, each number could be a separate zone.

Then I think that "current thinking" will need to change. As soon as number
portability is allowed, it becomes possible for adjacent numbers to be
controlled by different carriers without restriction.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Jan 19 03:33:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7pBa-0005Cn-11; Fri, 19 Jan 2007 03:33:22 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7pBX-0005Ai-Ra
	for enum@ietf.org; Fri, 19 Jan 2007 03:33:19 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7pBW-00059B-DL
	for enum@ietf.org; Fri, 19 Jan 2007 03:33:19 -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 l0J8XFh4008158Fri, 19 Jan 2007 08:33:15 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H7pBT-000GF0-00; Fri, 19 Jan 2007 08:33:15 +0000
Date: Fri, 19 Jan 2007 08:33:15 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070119083315.GL53247@finch-staff-1.thus.net>
References: <20070117083715.GA32449@finch-staff-1.thus.net>
	<072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
User-Agent: Mutt/1.5.3i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: enum@ietf.org, Dale.Worley@comcast.net
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

>>> E.g., in North America, a subscriber
>>> number is 10 digits (or 11 if you count the country code).
>> Apparently not. I am told that numbers beginning +109 are a 
>> digit longer.
> I do not believe this is a valid E.164 number.  There are no NPA
> assigned starting with 0 or 1.

I'm skeptical myself, and have asked the originator of the comment for more
information.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Jan 19 03:38:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7pGb-0000Ws-34; Fri, 19 Jan 2007 03:38:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7pGZ-0000Rh-7B
	for enum@ietf.org; Fri, 19 Jan 2007 03:38:31 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7pGX-0005nK-Oe
	for enum@ietf.org; Fri, 19 Jan 2007 03:38:31 -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 l0J8cSE7010117Fri, 19 Jan 2007 08:38:28 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H7pGW-000GKF-00; Fri, 19 Jan 2007 08:38:28 +0000
Date: Fri, 19 Jan 2007 08:38:28 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: Dale.Worley@comcast.net
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070119083828.GM53247@finch-staff-1.thus.net>
References: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
	<200701172223.l0HMN6xD014781@dragon.ariadne.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200701172223.l0HMN6xD014781@dragon.ariadne.com>
User-Agent: Mutt/1.5.3i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Dale.Worley@comcast.net said:
> I see from http://www.nationalnanpa.com/area_codes/index.html that the
> prefixes +1 [1-9]9[0-9]

You mean +1 [2-9]9[0-9].

> I suspect that this means that there is a standby plan to extend the
> "area code" (first three digits) to four digits, by mapping
> 
> +1 xxx yyy zzzz -> +1 x9xx yyy zzzz
> 
> This would lead to "the numbers beginning +1x9 are a digit longer".

That might be the explanation, yes.

However, CNAC say on their site that the planned expansion is to:

   NXXX-XNXX-XXXX

(sic).

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Jan 19 05:31:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7r13-000874-8B; Fri, 19 Jan 2007 05:30:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7r11-00086y-UU
	for enum@ietf.org; Fri, 19 Jan 2007 05:30:35 -0500
Received: from mail139.messagelabs.com ([85.158.137.67])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7r0y-0004fi-D3
	for enum@ietf.org; Fri, 19 Jan 2007 05:30:35 -0500
X-VirusChecked: Checked
X-Env-Sender: Paul.Rosbotham@cwmsg.cwplc.com
X-Msg-Ref: server-11.tower-139.messagelabs.com!1169202603!4366412!1
X-StarScan-Version: 5.5.10.7; banners=cwmsg.cwplc.com,-,-
X-Originating-IP: [194.6.6.11]
Received: (qmail 7231 invoked from network); 19 Jan 2007 10:30:03 -0000
Received: from relay.cwplc.com (HELO relay.cwplc.com) (194.6.6.11)
	by server-11.tower-139.messagelabs.com with SMTP;
	19 Jan 2007 10:30:03 -0000
Received: from GBCWSWIEC001.ad.plc.cwintra.com ([148.185.93.207])
	by relay.cwplc.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	l0JAUKO24367; Fri, 19 Jan 2007 10:30:20 GMT
Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by
	GBCWSWIEC001.ad.plc.cwintra.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 10:30:38 +0000
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] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 10:30:37 -0000
Message-ID: <9322B78036E1534A99B0BC51DEB0F9D6022CDD82@GBCWSWIEM002.ad.plc.cwintra.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc7pWZQTECjW/whQkenOojvU4WlyAADoqow
From: "Rosbotham, Paul" <Paul.Rosbotham@cwmsg.cwplc.com>
To: "Clive D.W. Feather" <clive@demon.net>, <Dale.Worley@comcast.net>
X-OriginalArrivalTime: 19 Jan 2007 10:30:38.0453 (UTC)
	FILETIME=[DC993A50:01C73BB4]
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
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

OK,=20I'll=20hold=20up=20my=20hands...I'm=20Clive's=20source.

I=20can=20point=20to=20the=20following=20ranges

+1=20090=20444=2043xx=20x
+1=20090=20835=2047xx=20x
+1=20090=20871=2027xx=20x

which=20are=20freephone=20ranges,=20I=20believe=20Canadian?=20=20I=20have=20=
specific=20numbers=20in=20these=20ranges=20which=20I've=20tested=20this=20=
morning=20and=20fail=20if=20dialed=20in=20the=20format=20e.g.=20+1=20090=20=
444=2043xx=20but=20succeed=20in=20the=20format=20+1=20090=20444=2043xxx=20=
(reluctant=20to=20publish=20the=20details=20as=20obviously=20the=20custome=
r=20e.g.=20IBM=20will=20be=20paying=20for=20the=20inbound=20call).

Obviously=20NANP=20is=20not=20my=20expertise,=20but=20I=20understand=20tha=
t=20there's=20a=20bit=20of=20quirk=20of=20the=20system=20that=20NANPA=20do=
n't=20directly=20administer=20freephone=20ranges,=20hence=20these=20discre=
pancies.=20=20Happy=20to=20be=20corrected=20on=20that,=20though.

Regards

Paul=20

-----Original=20Message-----
From:=20Clive=20D.W.=20Feather=20[mailto:clive@demon.net]
Sent:=2019=20January=202007=2008:38
To:=20Dale.Worley@comcast.net
Cc:=20enum@ietf.org
Subject:=20Re:=20[Enum]=20draft-ietf-enum-unused-00.txt


Dale.Worley@comcast.net=20said:
>=20I=20see=20from=20http://www.nationalnanpa.com/area_codes/index.html=20=
that=20the
>=20prefixes=20+1=20[1-9]9[0-9]

You=20mean=20+1=20[2-9]9[0-9].

>=20I=20suspect=20that=20this=20means=20that=20there=20is=20a=20standby=20=
plan=20to=20extend=20the
>=20"area=20code"=20(first=20three=20digits)=20to=20four=20digits,=20by=20=
mapping
>=20
>=20+1=20xxx=20yyy=20zzzz=20->=20+1=20x9xx=20yyy=20zzzz
>=20
>=20This=20would=20lead=20to=20"the=20numbers=20beginning=20+1x9=20are=20a=
=20digit=20longer".

That=20might=20be=20the=20explanation,=20yes.

However,=20CNAC=20say=20on=20their=20site=20that=20the=20planned=20expansi=
on=20is=20to:

=20=20=20NXXX-XNXX-XXXX

(sic).

--=20
Clive=20D.W.=20Feather=20=20|=20Work:=20=20<clive@demon.net>=20=20=20|=20T=
el:=20=20=20=20+44=2020=208495=206138
Internet=20Expert=20=20=20=20=20|=20Home:=20=20<clive@davros.org>=20=20|=20=
Fax:=20=20=20=20+44=20870=20051=209937
Demon=20Internet=20=20=20=20=20=20|=20WWW:=20http://www.davros.org=20|=20M=
obile:=20+44=207973=20377646
THUS=20plc=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|

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

This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20=
&=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs=
.=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec=
urity=20service,=20visit=20http://www.cw.com/uk/emailprotection/=20

The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a=
nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten=
ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20=
not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop=
y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont=
ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20=
in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20=
are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me=
ssage=20and=20any=20attachments=20without=20retaining=20any=20copies.
=20
Cable=20and=20Wireless=20plc=20
Registered=20in=20England=20and=20Wales.=20=20Company=20Number=20238525=20=

Registered=20office:=207th=20Floor,=20The=20Point,=2037=20North=20Wharf=20=
Road,=20London=20W2=201LA

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



From enum-bounces@ietf.org Fri Jan 19 05:50:45 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7rK5-0001nv-HY; Fri, 19 Jan 2007 05:50:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7rK5-0001nm-1O
	for enum@ietf.org; Fri, 19 Jan 2007 05:50:17 -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 1H7rK3-00078h-P8
	for enum@ietf.org; Fri, 19 Jan 2007 05:50:17 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id 0A85F4C97C; Fri, 19 Jan 2007 11:50:03 +0100 (CET)
Date: Fri, 19 Jan 2007 11:50:03 +0100
From: Otmar Lendl <lendl@nic.at>
To: enum@ietf.org
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070119105002.GA6341@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, enum@ietf.org
References: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
	<200701172223.l0HMN6xD014781@dragon.ariadne.com>
	<20070119083828.GM53247@finch-staff-1.thus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070119083828.GM53247@finch-staff-1.thus.net>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/19 09:01, "Clive D.W. Feather" <clive@demon.net> wrote:
> 
> However, CNAC say on their site that the planned expansion is to:
> 
>    NXXX-XNXX-XXXX
> 

If that contigency plan ever needs to be implemented, that's going
to be an interesting change. Based on my experience in trying to enter
Austrian phone numbers into American web-forms/paper-forms/databases
which often are hardcoded to accept only (XXX) YYY ZZZZ, the
introduction of these longer numbers will have a quite significant
effect on a large number of IT systems.

That's not quite on the scale of the Y2K issue, but probably
close to what Germany went through when they changed from 
4-digit zip codes to 5-digit ones in '93.

/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 Jan 19 07:53:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7tEm-0006qi-8e; Fri, 19 Jan 2007 07:52:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tEl-0006qc-21
	for enum@ietf.org; Fri, 19 Jan 2007 07:52:55 -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 1H7tEe-0001nr-1Y
	for enum@ietf.org; Fri, 19 Jan 2007 07:52:55 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by insensate.co.uk (Postfix) with ESMTP id 888D096083;
	Fri, 19 Jan 2007 12:52:44 +0000 (GMT)
In-Reply-To: <F1A1D21DA394814E824AC89F5A005BA30F983FE8@zcarhxm0.corp.nortel.com>
References: <F1A1D21DA394814E824AC89F5A005BA30F983FE8@zcarhxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E9B86B14-C29D-423D-91A6-E88FD2C6C585@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 12:52:43 +0000
To: James McEachern <jmce@nortel.com>, Dale.Worley@comcast.net
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Cc: enum@ietf.org, Stastny Richard <Richard.Stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Folks,
[sorry about the delay in sending this - just got back in email range
  after the storms in Europe made life interesting]

  As the author of this particular bit of text, I apologise for the
confusion it has apparently sown.

IGNORING dialling plans and CONSIDERING ONLY number plans:-

 From my perspective, there are closed and open numbering plans.
Within closed numbering plans, there are fixed numbering plans.

The UK does not have a fixed numbering plan - it is, however, closed.
If you have a block number, you know how long the subsequent digits
will be.

I understood that the NANP has a fixed numbering plan. All digit
strings are the same length. IIUC, it appears that this is not (or
is not going to be) the case. There are or will be a mix of different
number lengths.
I stand corrected and I have learnt my new thing for today.

If there are no longer any fully fixed number plans, then we can
(happily) remove the sub-section on fixed numbering plans.

To reiterate, this whole section says nothing of the dialling
plans used - some places may choose to "optimise" the dialling plan
processed, some others may not.

In closed numbering plans, an end user gets a number of a defined
length (defined by the initial digit string - +44160650 is a different
string from +44160649). It is indeed true that the prefix +441606 does
not define the subsequent number length. That is NOT the initial digit
string I used in the examples).

I chose "initial digit string", but "prefix" would cause exactly the
same problems. It is imprecise, as closed-but-not-fixed numbering plans
can have different lengths of such prefix/initial digit strings that
define the length of the subsequent digit strings.

If anyone can think of text (other than initial digit string or prefix)
to describe clearly these variable length prefixes I (and Richard) will
be happy. E.164 doesn't do this (or other things, as Richard has already
pointed out).

all the best,
   Lawrence

On 17 Jan 2007, at 18:14, James McEachern wrote:
> Richard,
> I agree it would be a good idea to rewrite this sentence.  While  
> you are
> at it, I suggest you look at the next sentence as well.  It currently
> says:
>
> "Thus, for a given initial digit string, the length of the subsequent
> digit string together constituting a valid telephone number is known."
>
> The problem is that this could be interpreted as saying that for *any*
> initial digit string, the length of the ... valid telephone number is
> known.  Clearly this is not the case for "+441606" - but since  
> "+441606"
> is "a given initial digit string" the existing text appears to imply
> that it should.
>
> BTW, I did eventually figure out what this section was saying, but it
> took a while...
>
> Jim
>
> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Wednesday, January 17, 2007 9:31 AM
> To: Dale.Worley@comcast.net; enum@ietf.org
> Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
>
> I have to admit that this sentence is not clear and
> we will re-write it
>
> Richard
>
>> -----Original Message-----
>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
>> Sent: Wednesday, January 17, 2007 3:20 PM
>> To: enum@ietf.org
>> Subject: [Enum] draft-ietf-enum-unused-00.txt
>>
>> To isolate my point, let me quote the beginning of 7.2.1:
>>
>>    In many countries closed numbering plans are in use.  In such a
>>    scheme, all valid telephone numbers have a defined length - the
>>    number of digits used for the subscriber number is fixed.
>>
>> To me, this means a system like North America, +1, where all E.164
>> numbers (all subscriber numbers) have the same length (11 digits).
>>
>> 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
>
> _______________________________________________
> 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 Jan 19 07:56:17 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7tHz-0000Ef-KG; Fri, 19 Jan 2007 07:56:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tHy-0000Bk-4t
	for enum@ietf.org; Fri, 19 Jan 2007 07:56:14 -0500
Received: from mail120.messagelabs.com ([216.82.250.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7tHs-0002QQ-Nv
	for enum@ietf.org; Fri, 19 Jan 2007 07:56:14 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-11.tower-120.messagelabs.com!1169211364!12898609!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 27691 invoked from network); 19 Jan 2007 12:56:04 -0000
Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4)
	by server-11.tower-120.messagelabs.com with SMTP;
	19 Jan 2007 12:56:04 -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 l0JCu4o1023026; 
	Fri, 19 Jan 2007 07:56:04 -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 l0JCu13P023004; 
	Fri, 19 Jan 2007 07:56:02 -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] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 07:56:00 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0E882470@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <20070119083828.GM53247@finch-staff-1.thus.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc7pUV0Oc8N9KEsTJG7oulLFf/SzgAI6RKQ
From: "Pfautz, Penn L, GBLAM" <ppfautz@att.com>
To: "Clive D.W. Feather" <clive@demon.net>, <Dale.Worley@comcast.net>
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

 Yes, the most current plan is different as you indicate.
The N9X NPA codes are reserved for an earlier plan (and still are) but
the industry's most recent recommendation for expansion no longer relies
on them:

http://www.atis.org/inc/docs/finaldocs/020107029.doc



-----Original Message-----
From: Clive D.W. Feather [mailto:clive@demon.net]=20
Sent: Friday, January 19, 2007 3:38 AM
To: Dale.Worley@comcast.net
Cc: enum@ietf.org
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt

Dale.Worley@comcast.net said:
> I see from http://www.nationalnanpa.com/area_codes/index.html that the
> prefixes +1 [1-9]9[0-9]

You mean +1 [2-9]9[0-9].

> I suspect that this means that there is a standby plan to extend the
> "area code" (first three digits) to four digits, by mapping
>=20
> +1 xxx yyy zzzz -> +1 x9xx yyy zzzz
>=20
> This would lead to "the numbers beginning +1x9 are a digit longer".

That might be the explanation, yes.

However, CNAC say on their site that the planned expansion is to:

   NXXX-XNXX-XXXX

(sic).

--=20
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495
6138
Internet Expert     | Home:  <clive@davros.org>  | 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

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



From enum-bounces@ietf.org Fri Jan 19 08:06:44 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7tRk-000577-O8; Fri, 19 Jan 2007 08:06:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tRk-000572-29
	for enum@ietf.org; Fri, 19 Jan 2007 08:06:20 -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 1H7tRi-0004AC-LC
	for enum@ietf.org; Fri, 19 Jan 2007 08:06:20 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by insensate.co.uk (Postfix) with ESMTP id 13A109609D;
	Fri, 19 Jan 2007 13:06:18 +0000 (GMT)
In-Reply-To: <200701181506.l0IF6QqV023754@dragon.ariadne.com>
References: <32755D354E6B65498C3BD9FD496C7D466469F5@oefeg-s04.oefeg.loc>
	<200701172229.l0HMTEMx015265@dragon.ariadne.com>
	<32755D354E6B65498C3BD9FD496C7D462C4C61@oefeg-s04.oefeg.loc>
	<200701181506.l0IF6QqV023754@dragon.ariadne.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5C899721-78BD-44C7-88B6-100AA5C9503A@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 13:06:16 +0000
To: Dale.Worley@comcast.net
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: IETF ENUM WG <enum@ietf.org>, Richard Stastny <richard.stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Dale, Richard, folks,
  This thread reflects earlier discussion on the IPTEL list when 3966
was being developed (and other threads covering mapping of tel: paras
into sip: URIs). Search for tel: paramaters vs. uri: parameters.

However, we do need to be careful about what is meant by mapping.

It looks like Dale is talking about provisioning sub-domains into ENUM
space to cover digit strings of which the end parts are sub-addresses.

However... A client may know that a sub-address is not part of an E.164
number. It surely will know this if it gets a tel: URI with an ;isub
parameter. The main value is the E.164 number. The ;isub is discrete.

Section 2 of RFC 3761 is specific:
  "ENUM compliant applications MUST only query DNS for what it believes
   is an E.164 number."

My interpretation is that this bars creating separate sub-domains for
such concatenated numbers, as they are not E.164 numbers.

all the best,
   Lawrence


On 18 Jan 2007, at 15:06, Dale.Worley@comcast.net wrote:
>    From: "Stastny Richard" <Richard.Stastny@oefeg.at>
>> It would be sensible if the ENUM resolution process attached the isub
>> parameter from the tel URI onto the SIP URI obtained from resolution,
>> but I don't think there is any specification for that.
>
>    This is not the problem - a tel: or sip: URI in an ENUM NAPTR
>    may always contain the isdn-subaddress
>
> Yes, but if I write "tel:12125551212;isub=1234" the isub information
> is lost when it is resolved into a SIP URI.  Or at least, as far as I
> can figure out from a quick scan of RFC 3761 and 3764.  Ideally, the
> ENUM resolution process would specify that the isub parameter would be
> carried from the tel: URI to the sip: URI.
>
>    The problem is that you cannot query an E.164 number + SA in ENUM
>    and e.g. get different results for each SA
>
> True, though presently I don't see that as a major problem, because
> the E.164 number has to be allocated to one customer, who can then run
> a proxy that will forward requests based on SA to various
> destinations.
>
> Hmmmm, in some models of User-ENUM, a user could install ENUM records
> not for his E.164 number, but for longer numbers with that E.164
> number as prefix, and achieve an effect much like what you want.
>
> Dale


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



From enum-bounces@ietf.org Fri Jan 19 08:12:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7tY4-0007He-3P; Fri, 19 Jan 2007 08:12:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tY2-0007HL-V4
	for enum@ietf.org; Fri, 19 Jan 2007 08:12:50 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7tY1-0004ob-G6
	for enum@ietf.org; Fri, 19 Jan 2007 08:12: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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Jan 2007 14:12:11 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D46646A2C@oefeg-s04.oefeg.loc>
In-Reply-To: <5C899721-78BD-44C7-88B6-100AA5C9503A@insensate.co.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Isdn subaddresses
Thread-Index: Acc7yohKPY5Gbpb+TgidxWh+OFZnxQAAGeCg
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "lconroy" <lconroy@insensate.co.uk>,
	<Dale.Worley@comcast.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: IETF ENUM WG <enum@ietf.org>
Subject: [Enum] Isdn subaddresses
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

> My interpretation is that this bars creating separate sub-domains for
> such concatenated numbers, as they are not E.164 numbers.

That is what I said

And BTW, I would like to move this discussion somewhere else
because it is completely off-topic re "unused"

I would also like to move the discussions about 11D NANPA
numbers of this thread

Richard

> -----Original Message-----
> From: lconroy [mailto:lconroy@insensate.co.uk]
> Sent: Friday, January 19, 2007 2:06 PM
> To: Dale.Worley@comcast.net
> Cc: IETF ENUM WG; Stastny Richard
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>=20
> Hi Dale, Richard, folks,
>   This thread reflects earlier discussion on the IPTEL list when 3966
> was being developed (and other threads covering mapping of tel: paras
> into sip: URIs). Search for tel: paramaters vs. uri: parameters.
>=20
> However, we do need to be careful about what is meant by mapping.
>=20
> It looks like Dale is talking about provisioning sub-domains into ENUM
> space to cover digit strings of which the end parts are sub-addresses.
>=20
> However... A client may know that a sub-address is not part of an
E.164
> number. It surely will know this if it gets a tel: URI with an ;isub
> parameter. The main value is the E.164 number. The ;isub is discrete.
>=20
> Section 2 of RFC 3761 is specific:
>   "ENUM compliant applications MUST only query DNS for what it
believes
>    is an E.164 number."
>=20
> My interpretation is that this bars creating separate sub-domains for
> such concatenated numbers, as they are not E.164 numbers.
>=20
> all the best,
>    Lawrence
>=20
>=20
> On 18 Jan 2007, at 15:06, Dale.Worley@comcast.net wrote:
> >    From: "Stastny Richard" <Richard.Stastny@oefeg.at>
> >> It would be sensible if the ENUM resolution process attached the
isub
> >> parameter from the tel URI onto the SIP URI obtained from
resolution,
> >> but I don't think there is any specification for that.
> >
> >    This is not the problem - a tel: or sip: URI in an ENUM NAPTR
> >    may always contain the isdn-subaddress
> >
> > Yes, but if I write "tel:12125551212;isub=3D1234" the isub =
information
> > is lost when it is resolved into a SIP URI.  Or at least, as far as
I
> > can figure out from a quick scan of RFC 3761 and 3764.  Ideally, the
> > ENUM resolution process would specify that the isub parameter would
be
> > carried from the tel: URI to the sip: URI.
> >
> >    The problem is that you cannot query an E.164 number + SA in ENUM
> >    and e.g. get different results for each SA
> >
> > True, though presently I don't see that as a major problem, because
> > the E.164 number has to be allocated to one customer, who can then
run
> > a proxy that will forward requests based on SA to various
> > destinations.
> >
> > Hmmmm, in some models of User-ENUM, a user could install ENUM
records
> > not for his E.164 number, but for longer numbers with that E.164
> > number as prefix, and achieve an effect much like what you want.
> >
> > Dale


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



From enum-bounces@ietf.org Fri Jan 19 10:04:13 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7vH6-0001CG-Sr; Fri, 19 Jan 2007 10:03:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vH4-00015r-V9
	for enum@ietf.org; Fri, 19 Jan 2007 10:03:26 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vH3-0005fq-It
	for enum@ietf.org; Fri, 19 Jan 2007 10:03:26 -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
	l0JF2q3K031251; Fri, 19 Jan 2007 07:02:58 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Rosbotham, Paul'" <Paul.Rosbotham@cwmsg.cwplc.com>,
	"'Clive D.W. Feather'" <clive@demon.net>, <Dale.Worley@comcast.net>
References: <9322B78036E1534A99B0BC51DEB0F9D6022CDD82@GBCWSWIEM002.ad.plc.cwintra.com>
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 10:02:37 -0500
Message-ID: <023101c73bda$e0726090$85211f0a@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: <9322B78036E1534A99B0BC51DEB0F9D6022CDD82@GBCWSWIEM002.ad.plc.cwintra.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: Acc7pWZQTECjW/whQkenOojvU4WlyAADoqowAAmtWtA=
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: 8abaac9e10c826e8252866cbe6766464
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



> -----Original Message-----
> From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwmsg.cwplc.com]
> Sent: Friday, January 19, 2007 5:31 AM
> To: Clive D.W. Feather; Dale.Worley@comcast.net
> Cc: enum@ietf.org
> Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
> 
> OK, I'll hold up my hands...I'm Clive's source.
> 
> I can point to the following ranges
> 
> +1 090 444 43xx x
> +1 090 835 47xx x
> +1 090 871 27xx x
> 
> which are freephone ranges, I believe Canadian?  I have specific numbers
> in these ranges which I've tested this morning and fail if dialed in the
> format e.g. +1 090 444 43xx but succeed in the format +1 090 444 43xxx
> (reluctant to publish the details as obviously the customer e.g. IBM will
> be paying for the inbound call).
> 
> Obviously NANP is not my expertise, but I understand that there's a bit of
> quirk of the system that NANPA don't directly administer freephone ranges,
> hence these discrepancies.  Happy to be corrected on that, though.

Paul you are correct the NANP does not control any of the free phone ranges
800 or 8X8.




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



From enum-bounces@ietf.org Fri Jan 19 10:18:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7vV1-0000ld-Df; Fri, 19 Jan 2007 10:17:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vUz-0000lX-UG
	for enum@ietf.org; Fri, 19 Jan 2007 10:17:49 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vUy-0007Tv-Hk
	for enum@ietf.org; Fri, 19 Jan 2007 10:17: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
	l0JFHYVM001726; Fri, 19 Jan 2007 07:17:40 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Clive D.W. Feather'" <clive@demon.net>, <Dale.Worley@comcast.net>
References: <200701161632.l0GGWKqh024459@dragon.ariadne.com><20070117083715.GA32449@finch-staff-1.thus.net><200701171323.l0HDNMHO007854@dragon.ariadne.com>
	<20070119083146.GK53247@finch-staff-1.thus.net>
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 10:17:24 -0500
Message-ID: <023e01c73bdc$ed9a8840$85211f0a@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: <20070119083146.GK53247@finch-staff-1.thus.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: Acc7pE5w/EfTapItQ9+6YAZBRIrkygANuMaQ
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
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net]
> Sent: Friday, January 19, 2007 3:32 AM
> To: Dale.Worley@comcast.net
> Cc: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
> 
> Dale.Worley@comcast.net said:
> >    > There is also the question of how this infrastructure interacts
> with
> >    > number portability, which leads to situations where any given range
> of
> >    > numbers is likely to be a mosaic of assignments to different
> carriers.
> >
> >    Do you mean open plans, or in general? I can't speak to open plans,
> but at
> >    least in the UK portability is unrelated to number length.
> >
> > The question isn't number length, but where the DNS zones are broken.
> > Much current thinking assumes that the DNS zones are broken at the
> > block boundaries.  This makes sense if all the numbers in a block are
> > controlled by one carrier.  But if the numbers are controlled by
> > different carriers, the block may be covered by a patchwork of DNS
> > zones; in the worst case, each number could be a separate zone.
> 
> Then I think that "current thinking" will need to change. As soon as
> number
> portability is allowed, it becomes possible for adjacent numbers to be
> controlled by different carriers without restriction.
> 

Yep which is why that delegation on anything other than the full E.164
number is not a good idea.

Block delegation in the context of infrastructure ENUM is simply a foolish
idea if there even the remote chance that LNP will be implemented within a
national administration. If fact IMHO it's a foolish idea period. Whether
the numbering plan is fixed or variable length is irrelevant.

It would be helpful if people stopped thinking this is about the DNS, its
not. Its how carriers find points of interconnection. The DNS IMHO is only a
form of query response mechanism.

For administrative consistency it is much better that the national registry
be fully authoritative for the entire number range and probably it maintain
the entire NAPTR record set in order to create a level playing field among
competing application providers.

Again it should be noted that the Number Data Registry should be considered
a separate entity from how the data is to be distributed. I wont repeat
myself that its my ongoing belief that for carrier infrastructure routing
applications the global DNS is NOT an appropriate form of distribution. 





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



From enum-bounces@ietf.org Fri Jan 19 11:42:45 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7woD-0001e4-N0; Fri, 19 Jan 2007 11:41:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7woC-0001dx-6M; Fri, 19 Jan 2007 11:41:44 -0500
Received: from mail.pts.se ([192.121.211.220] helo=mail2.pts.se)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H7wo7-000107-CK; Fri, 19 Jan 2007 11:41:44 -0500
Received: from safir.pts.se (safir.pts.ad [192.121.215.23]) by mail2.pts.se
	(Clearswift SMTPRS 5.2.5) with ESMTP id
	<T7d47dba1f0c079d3dc1df4@mail2.pts.se>; 
	Fri, 19 Jan 2007 17:41:28 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: SV: [Enum] Request for Publication
	-draft-ietf-enum-infrastructure-04.txt
Date: Fri, 19 Jan 2007 17:41:30 +0100
Message-ID: <1050E7CDAF4ED042BA2096CC187A79A70335A5F1@safir.pts.ad>
In-Reply-To: <088101c73b29$6736c8d0$85211f0a@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Request for Publication
	-draft-ietf-enum-infrastructure-04.txt
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYiAFO6UA
References: <088101c73b29$6736c8d0$85211f0a@cis.neustar.com>
From: <Joakim.Stralmark@pts.se>
To: <richard@shockey.us>,
	<iesg-secretary@ietf.org>,
	<enum@ietf.org>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: fluffy@cisco.com, paf@cisco.com, jon.peterson@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hello

I did send some comments during the last call to Richard Shockey on the =
4th of january 2007 on three of the I-Ds concerning I-ENUM - I reproduce =
my comments here again:


Anyway comments on:

Draft-ietf-enum-infrastructure-04 - in 7.1 for [2] it should be 2005 for =
ITU-T Rec. E.164

Draft-ietf-enum-combined-03 - there is a spelling error in 3 (two is =
after each other). The last paragraph in 3 might not be liked by some =
Goverments... The whole chapter 4 might be more considerd by NRAs =
because it puts an burden on them to act before they are consulted on =
this matter (remember all the debates in the past about User-ENUM and =
the delegation of e164.arpa). In 7 last paragraph - is it already =
deceided that the correct domain for the long-term solution is =
ie164.arpa? Otherwise it might not be appropriate to state that in this =
coming RFC and it would be better to save that statement when this has =
been decided by the correct Internet organization (e.g. IAB). In 8 I =
think it would be nice to avoid the usage of "golden tree".

Draft-ietf-enum-branch-location-record-02 - just delete "golden tree" in =
clause 1 and 3.



Sincerely

Joaim Str=E5lmark
Swedish NRA/Administration=20

-----Ursprungligt meddelande-----
Fr=E5n: Richard Shockey [mailto:richard@shockey.us]=20
Skickat: den 18 januari 2007 18:52
Till: iesg-secretary@ietf.org; enum@ietf.org
Kopia: 'Cullen Jennings'; 'Patrik F=E4ltstr=F6m'; 'Jon Peterson'
=C4mne: [Enum] Request for Publication =
-draft-ietf-enum-infrastructure-04.txt


Title		: The E.164 to Uniform Resource Identifiers=20
                          (URI) Dynamic Delegation Discovery System=20
                          (DDDS) Application for Infrastructure ENUM
	Author(s)	: J. Livingood, et al.
	Filename	: draft-ietf-enum-infrastructure-04.txt
	Pages		: 6
	Date		: 2007-1-2
=09
This document defines a use case as well as a proposal for a parallel=20
   namespace to "e164.arpa" as defined in RFC3761, to be used for=20
   Infrastructure ENUM purposes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-04.txt=


This document has been extensively discussed in the WG in 2005 and 2006.

This is a request for publication for one IETF ENUM WG working group =
document.

A two week WG last call on this document concluded on January 18, 2007.

There were no additional comments from the last call.

The document listed above is intended to Informational.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org =
sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 =
703.593.2683 <mailto:richard(at)shockey.us> =
<mailto:richard.shockey(at)neustar.biz>






_______________________________________________
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 Jan 19 11:59:51 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7x5Q-0003Fm-22; Fri, 19 Jan 2007 11:59:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7x5O-0003Fg-O8; Fri, 19 Jan 2007 11:59:30 -0500
Received: from cali.ucd.ie ([193.1.169.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H7x5G-0002xZ-E8; Fri, 19 Jan 2007 11:59:30 -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 <0JC400J01KGHZ200@cali.ucd.ie> (original mail from
	Niall.oReilly@ucd.ie) ; Fri, 19 Jan 2007 16:58:40 +0000 (GMT)
Received: from [137.43.2.214] by cali.ucd.ie
	(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
	with ESMTPSA id <0JC4003KPKHSDPC0@cali.ucd.ie>; Fri,
	19 Jan 2007 16:58:40 +0000 (GMT)
Date: Fri, 19 Jan 2007 16:59:22 +0000
From: Niall O'Reilly <Niall.oReilly@ucd.ie>
Subject: Re: [Enum] Request for Publication
	-draft-ietf-enum-infrastructure-04.txt
In-reply-to: <1050E7CDAF4ED042BA2096CC187A79A70335A5F1@safir.pts.ad>
To: Joakim.Stralmark@pts.se
Message-id: <3969ED80-01F9-455E-B9F5-FD9360908CBE@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: <088101c73b29$6736c8d0$85211f0a@cis.neustar.com>
	<1050E7CDAF4ED042BA2096CC187A79A70335A5F1@safir.pts.ad>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: enum@ietf.org, fluffy@cisco.com, jon.peterson@neustar.biz,
	richard@shockey.us, iesg-secretary@ietf.org, paf@cisco.com,
	Niall O'Reilly <Niall.oReilly@ucd.ie>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


On 19 Jan 2007, at 16:41, Joakim.Stralmark@pts.se wrote:
> In 7 last paragraph - is it already deceided that the correct
> domain for the long-term solution is ie164.arpa?

	It looks to me that 'ie164.arpa' and 'e164.arpa' are so close that
	the risk of confusion is too high.  I shouldn't be surprised if this
	decision (if actually made) were to become a matter of regret at
	some stage in the future.

	[Units omitted] 0,02 and maybe not worth even that much.

	/Niall


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



From enum-bounces@ietf.org Fri Jan 19 12:33:49 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7xc9-0006U8-P7; Fri, 19 Jan 2007 12:33:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xc8-0006Tw-KL
	for enum@ietf.org; Fri, 19 Jan 2007 12:33:20 -0500
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7xc7-0000sN-9l
	for enum@ietf.org; Fri, 19 Jan 2007 12:33:20 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-10.tower-121.messagelabs.com!1169227998!13295644!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 4035 invoked from network); 19 Jan 2007 17:33:18 -0000
Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4)
	by server-10.tower-121.messagelabs.com with SMTP;
	19 Jan 2007 17:33:18 -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 l0JHXG6p029272; 
	Fri, 19 Jan 2007 12:33:18 -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 l0JHX6K8029174; 
	Fri, 19 Jan 2007 12:33:11 -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] Request for
	Publication-draft-ietf-enum-infrastructure-04.txt
Date: Fri, 19 Jan 2007 12:33:09 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0E88292E@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <1050E7CDAF4ED042BA2096CC187A79A70335A5F1@safir.pts.ad>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Request for
	Publication-draft-ietf-enum-infrastructure-04.txt
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYiAFO6UAAAHSTdA=
From: "Pfautz, Penn L, GBLAM" <ppfautz@att.com>
To: <Joakim.Stralmark@pts.se>, <richard@shockey.us>, <enum@ietf.org>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: fluffy@cisco.com, paf@cisco.com, jon.peterson@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Joakim:
Actually I thought it was now decided that the IETF would punt on the =
apex domain for infrastructure ENUM leaving that as something to be =
decided by the ITU.

Penn

-----Original Message-----
From: Joakim.Stralmark@pts.se [mailto:Joakim.Stralmark@pts.se]=20
Sent: Friday, January 19, 2007 11:42 AM
To: richard@shockey.us; iesg-secretary@ietf.org; enum@ietf.org
Cc: fluffy@cisco.com; paf@cisco.com; jon.peterson@neustar.biz
Subject: SV: [Enum] Request for =
Publication-draft-ietf-enum-infrastructure-04.txt

Hello

I did send some comments during the last call to Richard Shockey on the =
4th of january 2007 on three of the I-Ds concerning I-ENUM - I reproduce =
my comments here again:


Anyway comments on:

Draft-ietf-enum-infrastructure-04 - in 7.1 for [2] it should be 2005 for =
ITU-T Rec. E.164

Draft-ietf-enum-combined-03 - there is a spelling error in 3 (two is =
after each other). The last paragraph in 3 might not be liked by some =
Goverments... The whole chapter 4 might be more considerd by NRAs =
because it puts an burden on them to act before they are consulted on =
this matter (remember all the debates in the past about User-ENUM and =
the delegation of e164.arpa). In 7 last paragraph - is it already =
deceided that the correct domain for the long-term solution is =
ie164.arpa? Otherwise it might not be appropriate to state that in this =
coming RFC and it would be better to save that statement when this has =
been decided by the correct Internet organization (e.g. IAB). In 8 I =
think it would be nice to avoid the usage of "golden tree".

Draft-ietf-enum-branch-location-record-02 - just delete "golden tree" in =
clause 1 and 3.



Sincerely

Joaim Str=E5lmark
Swedish NRA/Administration=20

-----Ursprungligt meddelande-----
Fr=E5n: Richard Shockey [mailto:richard@shockey.us]=20
Skickat: den 18 januari 2007 18:52
Till: iesg-secretary@ietf.org; enum@ietf.org
Kopia: 'Cullen Jennings'; 'Patrik F=E4ltstr=F6m'; 'Jon Peterson'
=C4mne: [Enum] Request for Publication =
-draft-ietf-enum-infrastructure-04.txt


Title		: The E.164 to Uniform Resource Identifiers=20
                          (URI) Dynamic Delegation Discovery System=20
                          (DDDS) Application for Infrastructure ENUM
	Author(s)	: J. Livingood, et al.
	Filename	: draft-ietf-enum-infrastructure-04.txt
	Pages		: 6
	Date		: 2007-1-2
=09
This document defines a use case as well as a proposal for a parallel=20
   namespace to "e164.arpa" as defined in RFC3761, to be used for=20
   Infrastructure ENUM purposes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-04.txt=


This document has been extensively discussed in the WG in 2005 and 2006.

This is a request for publication for one IETF ENUM WG working group =
document.

A two week WG last call on this document concluded on January 18, 2007.

There were no additional comments from the last call.

The document listed above is intended to Informational.



Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org =
sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 =
703.593.2683 <mailto:richard(at)shockey.us> =
<mailto:richard.shockey(at)neustar.biz>






_______________________________________________
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 Fri Jan 19 12:55:44 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7xxF-0000bK-ME; Fri, 19 Jan 2007 12:55:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7xxD-0000as-GG; Fri, 19 Jan 2007 12:55:07 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1H7xxC-0004OV-4C; Fri, 19 Jan 2007 12:55: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] Request for
	Publication-draft-ietf-enum-infrastructure-04.txt
Date: Fri, 19 Jan 2007 18:54:29 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C65@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Request for
	Publication-draft-ietf-enum-infrastructure-04.txt
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYiAFO6UAAAJEVX0=
References: <088101c73b29$6736c8d0$85211f0a@cis.neustar.com>
	<1050E7CDAF4ED042BA2096CC187A79A70335A5F1@safir.pts.ad>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <Joakim.Stralmark@pts.se>, <richard@shockey.us>, <iesg-secretary@ietf.org>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: fluffy@cisco.com, paf@cisco.com, jon.peterson@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Joakin,
=20
Thanky you for the comments
=20

>Draft-ietf-enum-combined-03 - there is a spelling error in 3 (two is =
after each other).=20
=20
? do not find it - could you please be more exact
=20
>The last paragraph in 3 might not be liked by some Goverments...=20
=20
Why not?
=20
>The whole chapter 4 might be more considerd by NRAs because it puts an =
burden on them to act before they are consulted >on this matter =
(remember all the debates in the past about User-ENUM and the delegation =
of e164.arpa).=20

If a government does not like the idea of a branch in e164.arpa, they =
will not implement it. This chapter is
the essence of the appoach
=20
>In 7 last paragraph - is it already deceided that the correct domain =
for the long-term solution is ie164.arpa? Otherwise it might >not be =
appropriate to state that in this coming RFC and it would be better to =
save that statement when this has been decided >by the correct Internet =
organization (e.g. IAB).
=20
This is an example only:
It s clearly stated:
=20
 "This assumes that the apex for the long-term solution is "ie164.arpa".
=20
=20
> In 8 I think it would be nice to avoid the usage of "golden tree".

ok
=20
Richard

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



From enum-bounces@ietf.org Fri Jan 19 12:56:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7xyp-0001Px-Sd; Fri, 19 Jan 2007 12:56:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xyo-0001Pr-Ge
	for enum@ietf.org; Fri, 19 Jan 2007 12:56:46 -0500
Received: from sccrmhc13.comcast.net ([204.127.200.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7xyk-0004ny-88
	for enum@ietf.org; Fri, 19 Jan 2007 12:56:46 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc13) with ESMTP
	id <2007011917564101300lui42e>; Fri, 19 Jan 2007 17:56:41 +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 l0JHufbM011962
	for <enum@ietf.org>; Fri, 19 Jan 2007 12:56:41 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0JHuf90011958;
	Fri, 19 Jan 2007 12:56:41 -0500
Date: Fri, 19 Jan 2007 12:56:41 -0500
Message-Id: <200701191756.l0JHuf90011958@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <45948D80.2010309@e164.org> (duane@e164.org)
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>
	<456E7B25.6010701@e164.org> <45948D80.2010309@e164.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: Duane <duane@e164.org>

   I've had a re-think on this, at least to a limited extent, take for
   example jingle/xmpp integration into Asterisk/FreeSwitch etc, asterisk
   obviously can't text message (unless you wanted to go into text to
   speech/speech to text), and a client like gaim can't handle voice, so I
   guess this is where listing type of services available in DNS comes in
   so clients don't need to handshake to indicate what they can accept.
   Although I guess the down side to not listing is of course lagged
   initial setup, but would this be detrimental?

Actually, I think this is not the problem it appears to be.  Consider
if I've registered my SIP AOR in the ENUM database for my E.164
number.  And consider that that AOR routes to two UAs:  one is my desk
phone, which can handle audio media, and one is my IM client, which
can handle (whatever the SIP IM conversation media name is).

If someone attempts to call me with an audio device, it will send an
INVITE to the AOR, and the proxy will fork it to both of my UAs.  But
the SDP negotiation with the IM client will fail becuase there's no
common media type, whereas the SDP negotiation with the phone will
progress to an early dialog and ring my phone.

The reverse happens if someone attempts to connect to my E.164 number
using a SIMPLE IM client.

The reason this works is that although, as you say, this requires
clients "to handshake to indicate what they can accept", SIP *already*
does the handshaking to determine which UA can accept what.

(Asterisk, perhaps, cannot handle text messaging, but that would be
because Asterisk isn't a real SIP proxy.  Whereas sipX, SER, etc. can
handle text messaging transparently.)

Dale

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



From enum-bounces@ietf.org Fri Jan 19 13:07:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7y9I-00080g-LF; Fri, 19 Jan 2007 13:07:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7y9H-00080b-Np
	for enum@ietf.org; Fri, 19 Jan 2007 13:07:35 -0500
Received: from rwcrmhc12.comcast.net ([216.148.227.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7y9G-000772-GY
	for enum@ietf.org; Fri, 19 Jan 2007 13:07:35 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc12) with ESMTP
	id <20070119180733m12002l2rue>; Fri, 19 Jan 2007 18:07:33 +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 l0JI7WbM012743
	for <enum@ietf.org>; Fri, 19 Jan 2007 13:07:32 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0JI7WqY012739;
	Fri, 19 Jan 2007 13:07:32 -0500
Date: Fri, 19 Jan 2007 13:07:32 -0500
Message-Id: <200701191807.l0JI7WqY012739@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <20070119105002.GA6341@nic.at> (lendl@nic.at)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <072C5B76F7CEAB488172C6F64B30B5E30278076A@xmb-rtp-20b.amer.cisco.com>
	<200701172223.l0HMN6xD014781@dragon.ariadne.com>
	<20070119083828.GM53247@finch-staff-1.thus.net>
	<20070119105002.GA6341@nic.at>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: Otmar Lendl <lendl@nic.at>

   If that contigency plan ever needs to be implemented, that's going
   to be an interesting change. Based on my experience in trying to enter
   Austrian phone numbers into American web-forms/paper-forms/databases
   which often are hardcoded to accept only (XXX) YYY ZZZZ, the
   introduction of these longer numbers will have a quite significant
   effect on a large number of IT systems.

The NANP document says that they will need 10 years to implement the
change.

Dale

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



From enum-bounces@ietf.org Fri Jan 19 13:12:49 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7yEH-00032X-Co; Fri, 19 Jan 2007 13:12:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yEF-00031i-Oe
	for enum@ietf.org; Fri, 19 Jan 2007 13:12:43 -0500
Received: from wodka.aus-biz.com ([65.23.153.32])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7yE8-00070w-Kp
	for enum@ietf.org; Fri, 19 Jan 2007 13:12:43 -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 C242B11A597
	for <enum@ietf.org>; Fri, 19 Jan 2007 13:12:32 -0500 (EST)
Message-ID: <45B10A13.4010000@e164.org>
Date: Sat, 20 Jan 2007 05:12:35 +1100
From: Duane <duane@e164.org>
User-Agent: Thunderbird 2.0b1 (X11/20061206)
MIME-Version: 1.0
To: enum@ietf.org
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>	<456E7B25.6010701@e164.org>
	<45948D80.2010309@e164.org>
	<200701191756.l0JHuf90011958@dragon.ariadne.com>
In-Reply-To: <200701191756.l0JHuf90011958@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Dale.Worley@comcast.net wrote:

> The reason this works is that although, as you say, this requires
> clients "to handshake to indicate what they can accept", SIP *already*
> does the handshaking to determine which UA can accept what.

As I stated, the down side to leaving it up to proxies etc to figure out 
who can support what is that could introduce lag in the call setups, but 
this on it's own shouldn't be too bad, but combined with times to do 
enum lookups in the first place, is this likely to be a problem?

-- 

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 Fri Jan 19 13:49:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7ynF-00054z-TH; Fri, 19 Jan 2007 13:48:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ynF-00054t-35
	for enum@ietf.org; Fri, 19 Jan 2007 13:48:53 -0500
Received: from rwcrmhc15.comcast.net ([204.127.192.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ynC-0001ZS-RL
	for enum@ietf.org; Fri, 19 Jan 2007 13:48:53 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc15) with ESMTP
	id <20070119184839m1500bsf9ae>; Fri, 19 Jan 2007 18:48:50 +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 l0JImcbM015753
	for <enum@ietf.org>; Fri, 19 Jan 2007 13:48:38 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0JImcBG015749;
	Fri, 19 Jan 2007 13:48:38 -0500
Date: Fri, 19 Jan 2007 13:48:38 -0500
Message-Id: <200701191848.l0JImcBG015749@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <45B10A13.4010000@e164.org> (duane@e164.org)
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>	<456E7B25.6010701@e164.org>
	<45948D80.2010309@e164.org>
	<200701191756.l0JHuf90011958@dragon.ariadne.com>
	<45B10A13.4010000@e164.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: Duane <duane@e164.org>

   As I stated, the down side to leaving it up to proxies etc to figure out 
   who can support what is that could introduce lag in the call setups, but 
   this on it's own shouldn't be too bad, but combined with times to do 
   enum lookups in the first place, is this likely to be a problem?

Well, you want to do that forking in parallel, so all the negotiations
proceed in parallel.  Then your setup time is no more than for
attempting to connect to only the UA which will ultimately succeed.

Dale

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

From enum-bounces@ietf.org Fri Jan 19 13:49:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7yng-0005Hq-CY; Fri, 19 Jan 2007 13:49:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ynf-0005H0-6z
	for enum@ietf.org; Fri, 19 Jan 2007 13:49:19 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ynd-0001f2-PJ
	for enum@ietf.org; Fri, 19 Jan 2007 13:49:19 -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
	l0JIn9vf015446; Fri, 19 Jan 2007 10:49:17 -0800
From: richard@shockey.us
To: <enum@ietf.org>
Date: Fri, 19 Jan 2007 13:49:00 -0500
Organization: NeuStar, Inc,
Message-ID: <002d01c73bfa$7d40ccd0$85211f0a@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.3028
Thread-Index: AccrWvTBHkLoevN9S92qU1gQFIvKZA==
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.7 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	=?us-ascii?Q?'Patrik_Faltstrom'?= <paf@cisco.com>, "'Peterson,
	Jon'" <jon.peterson@neustar.biz>
Subject: [Enum] ENUM WG Last Call for draft-ietf-enum-xmpp-01.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rich.shockey@neustar.biz
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



	Title		: IANA Registration for Enumservice 'XMPP'
	Author(s)	: A. Mayrhofer
	Filename	: draft-ietf-enum-xmpp-01.txt
	Pages		: 8
	Date		: 2007-1-3
	
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-01.txt


The intent of the last call is to solicit comments before submitting the ID
to the IESG as a Proposed Standard.

The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections which have
not gotten previous or adequate discussion, or minor errors which need
correction.

Work group last call will extend to Monday Feb 5 insure a through and proper
review during the holiday period though we can modify that if new issues
come up.


Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:5651(at)neustarlab.biz
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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





From enum-bounces@ietf.org Fri Jan 19 13:49:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7ynF-00054z-TH; Fri, 19 Jan 2007 13:48:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ynF-00054t-35
	for enum@ietf.org; Fri, 19 Jan 2007 13:48:53 -0500
Received: from rwcrmhc15.comcast.net ([204.127.192.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ynC-0001ZS-RL
	for enum@ietf.org; Fri, 19 Jan 2007 13:48:53 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc15) with ESMTP
	id <20070119184839m1500bsf9ae>; Fri, 19 Jan 2007 18:48:50 +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 l0JImcbM015753
	for <enum@ietf.org>; Fri, 19 Jan 2007 13:48:38 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0JImcBG015749;
	Fri, 19 Jan 2007 13:48:38 -0500
Date: Fri, 19 Jan 2007 13:48:38 -0500
Message-Id: <200701191848.l0JImcBG015749@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <45B10A13.4010000@e164.org> (duane@e164.org)
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>	<456E7B25.6010701@e164.org>
	<45948D80.2010309@e164.org>
	<200701191756.l0JHuf90011958@dragon.ariadne.com>
	<45B10A13.4010000@e164.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: Duane <duane@e164.org>

   As I stated, the down side to leaving it up to proxies etc to figure out 
   who can support what is that could introduce lag in the call setups, but 
   this on it's own shouldn't be too bad, but combined with times to do 
   enum lookups in the first place, is this likely to be a problem?

Well, you want to do that forking in parallel, so all the negotiations
proceed in parallel.  Then your setup time is no more than for
attempting to connect to only the UA which will ultimately succeed.

Dale

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

From enum-bounces@ietf.org Fri Jan 19 13:49:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7yng-0005Hq-CY; Fri, 19 Jan 2007 13:49:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ynf-0005H0-6z
	for enum@ietf.org; Fri, 19 Jan 2007 13:49:19 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ynd-0001f2-PJ
	for enum@ietf.org; Fri, 19 Jan 2007 13:49:19 -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
	l0JIn9vf015446; Fri, 19 Jan 2007 10:49:17 -0800
From: richard@shockey.us
To: <enum@ietf.org>
Date: Fri, 19 Jan 2007 13:49:00 -0500
Organization: NeuStar, Inc,
Message-ID: <002d01c73bfa$7d40ccd0$85211f0a@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.3028
Thread-Index: AccrWvTBHkLoevN9S92qU1gQFIvKZA==
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.7 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: 'Cullen Jennings' <fluffy@cisco.com>,
	=?us-ascii?Q?'Patrik_Faltstrom'?= <paf@cisco.com>, "'Peterson,
	Jon'" <jon.peterson@neustar.biz>
Subject: [Enum] ENUM WG Last Call for draft-ietf-enum-xmpp-01.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rich.shockey@neustar.biz
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



	Title		: IANA Registration for Enumservice 'XMPP'
	Author(s)	: A. Mayrhofer
	Filename	: draft-ietf-enum-xmpp-01.txt
	Pages		: 8
	Date		: 2007-1-3
	
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-01.txt


The intent of the last call is to solicit comments before submitting the ID
to the IESG as a Proposed Standard.

The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections which have
not gotten previous or adequate discussion, or minor errors which need
correction.

Work group last call will extend to Monday Feb 5 insure a through and proper
review during the holiday period though we can modify that if new issues
come up.


Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:5651(at)neustarlab.biz
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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





From enum-bounces@ietf.org Fri Jan 19 13:58:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7ywm-0002Ne-8z; Fri, 19 Jan 2007 13:58:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ywl-0002NZ-Kc
	for enum@ietf.org; Fri, 19 Jan 2007 13:58:43 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ywj-00032Q-8G
	for enum@ietf.org; Fri, 19 Jan 2007 13:58:43 -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
	l0JIwQL3017498; Fri, 19 Jan 2007 10:58:36 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Clive D.W. Feather'" <clive@demon.net>, <Dale.Worley@comcast.net>
References: <200701161632.l0GGWKqh024459@dragon.ariadne.com><20070117083715.GA32449@finch-staff-1.thus.net><200701171323.l0HDNMHO007854@dragon.ariadne.com>
	<20070119083146.GK53247@finch-staff-1.thus.net>
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 13:58:13 -0500
Message-ID: <004b01c73bfb$c9ae6c70$85211f0a@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.3028
In-reply-to: <20070119083146.GK53247@finch-staff-1.thus.net>
Thread-Index: Acc7pE5w/EfTapItQ9+6YAZBRIrkygANuMaQ
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
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



> -----Original Message-----
> From: Clive D.W. Feather [mailto:clive@demon.net]
> Sent: Friday, January 19, 2007 3:32 AM
> To: Dale.Worley@comcast.net
> Cc: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
> 
> Dale.Worley@comcast.net said:
> >    > There is also the question of how this infrastructure interacts
> with
> >    > number portability, which leads to situations where any given range
> of
> >    > numbers is likely to be a mosaic of assignments to different
> carriers.
> >
> >    Do you mean open plans, or in general? I can't speak to open plans,
> but at
> >    least in the UK portability is unrelated to number length.
> >
> > The question isn't number length, but where the DNS zones are broken.
> > Much current thinking assumes that the DNS zones are broken at the
> > block boundaries.  This makes sense if all the numbers in a block are
> > controlled by one carrier.  But if the numbers are controlled by
> > different carriers, the block may be covered by a patchwork of DNS
> > zones; in the worst case, each number could be a separate zone.
> 
> Then I think that "current thinking" will need to change. As soon as
> number
> portability is allowed, it becomes possible for adjacent numbers to be
> controlled by different carriers without restriction.
> 

Yep which is why that delegation on anything other than the full E.164
number is not a good idea.

Block delegation in the context of infrastructure ENUM is simply a foolish
idea if there even the remote chance that LNP will be implemented within a
national administration. If fact IMHO it's a foolish idea period. Whether
the numbering plan is fixed or variable length is irrelevant.

It would be helpful if people stopped thinking this is about the DNS, its
not. Its how carriers find points of interconnection. The DNS IMHO is only a
form of query response mechanism.

For administrative consistency it is much better that the national registry
be fully authoritative for the entire number range and probably it maintain
the entire NAPTR record set in order to create a level playing field among
competing application providers.

Again it should be noted that the Number Data Registry should be considered
a separate entity from how the data is to be distributed. I wont repeat
myself that its my ongoing belief that for carrier infrastructure routing
applications the global DNS is NOT an appropriate form of distribution. 





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



From enum-bounces@ietf.org Fri Jan 19 14:23:36 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7zKM-00060z-0f; Fri, 19 Jan 2007 14:23:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zKK-00060c-UR
	for enum@ietf.org; Fri, 19 Jan 2007 14:23:04 -0500
Received: from sccrmhc13.comcast.net ([204.127.200.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7zKJ-0008TU-OG
	for enum@ietf.org; Fri, 19 Jan 2007 14:23:04 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc13) with ESMTP
	id <2007011919225201300m1qqpe>; Fri, 19 Jan 2007 19:22: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 l0JJMqbM018250
	for <enum@ietf.org>; Fri, 19 Jan 2007 14:22:52 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0JJMqQI018246;
	Fri, 19 Jan 2007 14:22:52 -0500
Date: Fri, 19 Jan 2007 14:22:52 -0500
Message-Id: <200701191922.l0JJMqQI018246@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <004b01c73bfb$c9ae6c70$85211f0a@cis.neustar.com>
	(richard@shockey.us)
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
References: <200701161632.l0GGWKqh024459@dragon.ariadne.com><20070117083715.GA32449@finch-staff-1.thus.net><200701171323.l0HDNMHO007854@dragon.ariadne.com>
	<20070119083146.GK53247@finch-staff-1.thus.net>
	<004b01c73bfb$c9ae6c70$85211f0a@cis.neustar.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Richard Shockey" <richard@shockey.us>

   It would be helpful if people stopped thinking this is about the
   DNS, its not. Its how carriers find points of interconnection. The
   DNS IMHO is only a form of query response mechanism.

That's true, but without a defined query/reponse mechanism into an
open and public database, we aren't creating an "open standard" that
is directly usable by everybody.  So far, I haven't heard anyone
suggest any mechanism other than DNS.

Dale

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



From enum-bounces@ietf.org Fri Jan 19 14:41:42 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7zbu-0005Wg-Rm; Fri, 19 Jan 2007 14:41:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zbt-0005W3-VS
	for enum@ietf.org; Fri, 19 Jan 2007 14:41:13 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7zbs-0003EJ-J7
	for enum@ietf.org; Fri, 19 Jan 2007 14:41:13 -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
	l0JJf4G1025922; Fri, 19 Jan 2007 11:41:11 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <Dale.Worley@comcast.net>, <enum@ietf.org>
References: <200701161632.l0GGWKqh024459@dragon.ariadne.com><20070117083715.GA32449@finch-staff-1.thus.net><200701171323.l0HDNMHO007854@dragon.ariadne.com><20070119083146.GK53247@finch-staff-1.thus.net><004b01c73bfb$c9ae6c70$85211f0a@cis.neustar.com>
	<200701191922.l0JJMqQI018246@dragon.ariadne.com>
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 14:40:53 -0500
Message-ID: <007f01c73c01$bd74c9d0$85211f0a@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.3028
In-reply-to: <200701191922.l0JJMqQI018246@dragon.ariadne.com>
Thread-Index: Acc7/0QvxH0jbpAzT0OoZmlevCsotQAAW1RA
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: 52e1467c2184c31006318542db5614d5
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


If the Carrier Routing Registry were fully authoritative for the entire
national number range then SIP Redirect could be used as well for the query
response. Slower but it would work, plus you could then use SIP
Authentication to control access. 

I just don't believe a Carrier Routing Registry should be open to the
"public".

The issues of Public vs Infrastructure ENUM are as I've said before
orthogonal.

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: Friday, January 19, 2007 2:23 PM
> To: enum@ietf.org
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
> 
>    From: "Richard Shockey" <richard@shockey.us>
> 
>    It would be helpful if people stopped thinking this is about the
>    DNS, its not. Its how carriers find points of interconnection. The
>    DNS IMHO is only a form of query response mechanism.
> 
> That's true, but without a defined query/reponse mechanism into an
> open and public database, we aren't creating an "open standard" that
> is directly usable by everybody.  So far, I haven't heard anyone
> suggest any mechanism other than DNS.
> 
> 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 Fri Jan 19 14:59:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7zsi-0005Of-RF; Fri, 19 Jan 2007 14:58:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zsh-0005OZ-Qo
	for enum@ietf.org; Fri, 19 Jan 2007 14:58:35 -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 1H7zsg-00063u-I1
	for enum@ietf.org; Fri, 19 Jan 2007 14:58:35 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id 7A9CA4C98E; Fri, 19 Jan 2007 20:58:27 +0100 (CET)
Date: Fri, 19 Jan 2007 20:58:27 +0100
From: Otmar Lendl <lendl@nic.at>
To: Richard Shockey <richard@shockey.us>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070119195827.GA17877@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>,
	Richard Shockey <richard@shockey.us>,
	"'Clive D.W. Feather'" <clive@demon.net>, Dale.Worley@comcast.net,
	enum@ietf.org
References: <20070119083146.GK53247@finch-staff-1.thus.net>
	<023e01c73bdc$ed9a8840$85211f0a@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <023e01c73bdc$ed9a8840$85211f0a@cis.neustar.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: enum@ietf.org, Dale.Worley@comcast.net,
	"'Clive D.W. Feather'" <clive@demon.net>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/19 16:01, Richard Shockey <richard@shockey.us> wrote:
> 
> Block delegation in the context of infrastructure ENUM is simply a foolish
> idea if there even the remote chance that LNP will be implemented within a
> national administration. If fact IMHO it's a foolish idea period. Whether
> the numbering plan is fixed or variable length is irrelevant.

I fully agree with you here.  But to expand on ..

> It would be helpful if people stopped thinking this is about the DNS, its
> not. Its how carriers find points of interconnection. The DNS IMHO is only a
> form of query response mechanism.

it's worth noting that your first paragraph talks about "block
delegation" which sounds like DNS language and has a specific meaning there 
(i.e. NS records).

Another thing worth noting is that fact that "block provisioning" (i.e.
provisioning a whole block of number with one transaction into the
registry) does make a lot of sense in the context of I-ENUM. But that,
see above, should not be confused with what can be seen in the DNS.

> For administrative consistency it is much better that the national registry
> be fully authoritative for the entire number range and probably it maintain
> the entire NAPTR record set in order to create a level playing field among
> competing application providers.

Agreed again.

/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 Jan 19 15:49:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H80eQ-0003qT-2H; Fri, 19 Jan 2007 15:47:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H80eO-0003qN-8Z
	for enum@ietf.org; Fri, 19 Jan 2007 15:47:52 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H80eM-0006lO-TV
	for enum@ietf.org; Fri, 19 Jan 2007 15:47:52 -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
	l0JKlN6Z013107; Fri, 19 Jan 2007 12:47:29 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Otmar Lendl'" <lendl@nic.at>
References: <20070119083146.GK53247@finch-staff-1.thus.net>
	<023e01c73bdc$ed9a8840$85211f0a@cis.neustar.com>
	<20070119195827.GA17877@nic.at>
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Fri, 19 Jan 2007 15:47:10 -0500
Message-ID: <00c101c73c0a$ff7362c0$85211f0a@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.3028
In-reply-to: <20070119195827.GA17877@nic.at>
Thread-Index: Acc8BDuNZC/8KSG3TsCifPEkmOMEhQABWu1A
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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: enum@ietf.org, Dale.Worley@comcast.net,
	"'Clive D.W. Feather'" <clive@demon.net>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


> 
> it's worth noting that your first paragraph talks about "block
> delegation" which sounds like DNS language and has a specific meaning
> there
> (i.e. NS records).
> 
> Another thing worth noting is that fact that "block provisioning" (i.e.
> provisioning a whole block of number with one transaction into the
> registry) does make a lot of sense in the context of I-ENUM. But that,
> see above, should not be confused with what can be seen in the DNS.

I certainly agree and that is exactly the kind of issue PEPPERMINT can
hopefully address. The only exception to the matter is again one of LNP.
Granted the NANP is unique in that there is no service distinction between
fixed and mobile numbers it should be noted that over 85% of the 10K NPA NXX
blocks are in fact now "contaminated" ( yes the actual term of art) due to
both LNP and Pooling which in the NANPA context is a number conservation
measure requiring carriers to give back to the numbering plan unused 1K
blocks if required.

> 
> > For administrative consistency it is much better that the national
> registry be fully authoritative for the entire number range and probably
it maintain the entire NAPTR record set in order to create a level playing
field among competing application providers.
> 
> Agreed again.

I'm glad we agree again here. The real issues of carrier interconnection in
I-ENUM really have noting to do with the DNS but the administrative policies
and procedures by which a National Numbering Registry is organized,
provisioned and ultimately distributed... the Global DNS being one of many
possible distribution methods.




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



From enum-bounces@ietf.org Sat Jan 20 08:23:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H8GB2-00009p-CG; Sat, 20 Jan 2007 08:22:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H8GB1-00009k-3Y
	for enum@ietf.org; Sat, 20 Jan 2007 08:22:35 -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 1H8GAz-0008Jh-G8
	for enum@ietf.org; Sat, 20 Jan 2007 08:22:35 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by insensate.co.uk (Postfix) with ESMTP id 67B66963F9;
	Sat, 20 Jan 2007 13:22:28 +0000 (GMT)
In-Reply-To: <00c101c73c0a$ff7362c0$85211f0a@cis.neustar.com>
References: <20070119083146.GK53247@finch-staff-1.thus.net>
	<023e01c73bdc$ed9a8840$85211f0a@cis.neustar.com>
	<20070119195827.GA17877@nic.at>
	<00c101c73c0a$ff7362c0$85211f0a@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: <992A9705-659F-4441-98AA-84469E431546@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Date: Sat, 20 Jan 2007 13:22:27 +0000
To: richard@shockey.us
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: enum@ietf.org, "'Clive D.W. Feather'" <clive@demon.net>,
	Dale.Worley@comcast.net, 'Otmar Lendl' <lendl@nic.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi esteemed Co-Chair, Otmar, folks,

   I am having trouble working out what this thread has to do with  
the subject.
The authors' goal of this is to collect comments on this draft and to  
update
it to reflect those comments. We're trying to do this, but there are  
a lot of
OT posts *FOR THIS THREAD*.

The posts on NANP have clarified that it is not (or will not be) a fixed
numbering plan. Fine - I can remove the suggestion that it is, and  
apologise
for this unwarranted assumption (even if I'm not alone in that :).

The discussion on "prefix"/"initial digit string" shows that some  
folk may
misunderstand, and so that sentence needs a change.

"unused" already states that the C-o-R may be able to provision every  
ENUM
domain for which it is responsible. If there are parts of the tree  
for which
an entity is not responsible, then it is "from the Ministry of  
stating the
bleedin' obvious" that it should not try to provision entries for  
those parts.

If not all ENUM domains may be provisioned, then this may lead to  
several
NAPTRs being provisioned, as these reflect the apexes of the number  
groups
that are that CSP's responsibility. If there is total fragmentation,  
then
by definition this will require all of the ENUM domains to be  
provisioned,
or else there is no way to use ENUM. No surprise there, and I do not see
where in the unused draft it implies otherwise.

If there is to be a central DNS registry with NO delegation, then it  
will
be a matter for that registry and its customers to decide what goes  
where.
I guess that a communications service provider may still have a say  
in what
is delivered in response to queries for a telephone number for which  
that
provider is providing service. The effect is the same - the NAPTR is  
going
to be provisioned, and we are merely arguing about who runs the name  
servers.
That, IMHO, is irrelevant to the use of one NAPTR or another. In both  
cases,
I don't see what change would be needed to the unused draft.

If this is not to be DNS at all, then why the heck are we discussing  
a NAPTR
on the IETF ENUM mailing list, and what is the protocol that is to be  
defined
(i.e. what the IETF does)?

A plea: For anything unrelated to the unused draft, could folk PLEASE  
use a
different, appropriate, subject?

In some cases, it's reasonable to use a different mailing list.
IPTEL/SIPPING and Peppermint seem to be better targets for these.

all the best,
   Lawrence

On 19 Jan 2007, at 20:47, Richard Shockey wrote:
>> In response to Otmar's comments:
>> it's worth noting that your first paragraph talks about "block
>> delegation" which sounds like DNS language and has a specific meaning
>> there
>> (i.e. NS records).
>>
>> Another thing worth noting is that fact that "block  
>> provisioning" (i.e.
>> provisioning a whole block of number with one transaction into the
>> registry) does make a lot of sense in the context of I-ENUM. But  
>> that,
>> see above, should not be confused with what can be seen in the DNS.
>
> I certainly agree and that is exactly the kind of issue PEPPERMINT can
> hopefully address. The only exception to the matter is again one of  
> LNP.
> Granted the NANP is unique in that there is no service distinction  
> between
> fixed and mobile numbers it should be noted that over 85% of the  
> 10K NPA NXX
> blocks are in fact now "contaminated" ( yes the actual term of art)  
> due to
> both LNP and Pooling which in the NANPA context is a number  
> conservation
> measure requiring carriers to give back to the numbering plan  
> unused 1K
> blocks if required.
>
>>
>>> For administrative consistency it is much better that the national
>> registry be fully authoritative for the entire number range and  
>> probably
> it maintain the entire NAPTR record set in order to create a level  
> playing
> field among competing application providers.
>>
>> Agreed again.
>
> I'm glad we agree again here. The real issues of carrier  
> interconnection in
> I-ENUM really have noting to do with the DNS but the administrative  
> policies
> and procedures by which a National Numbering Registry is organized,
> provisioned and ultimately distributed... the Global DNS being one  
> of many
> possible distribution methods.


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



From enum-bounces@ietf.org Mon Jan 22 04:58:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H8vvZ-00017u-I3; Mon, 22 Jan 2007 04:57:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vvX-00015B-MD
	for enum@ietf.org; Mon, 22 Jan 2007 04:57:23 -0500
Received: from anchor-internal-1.mail.demon.net ([195.173.56.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8vvV-0003wH-9n
	for enum@ietf.org; Mon, 22 Jan 2007 04:57:23 -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 l0M9vC32011256Mon, 22 Jan 2007 09:57:18 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36
	#1) id 1H8vvL-000Kqe-00; Mon, 22 Jan 2007 09:57:11 +0000
Date: Mon, 22 Jan 2007 09:57:11 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
Message-ID: <20070122095711.GR60599@finch-staff-1.thus.net>
References: <20070119083146.GK53247@finch-staff-1.thus.net>
	<023e01c73bdc$ed9a8840$85211f0a@cis.neustar.com>
	<20070119195827.GA17877@nic.at>
	<00c101c73c0a$ff7362c0$85211f0a@cis.neustar.com>
	<992A9705-659F-4441-98AA-84469E431546@insensate.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <992A9705-659F-4441-98AA-84469E431546@insensate.co.uk>
User-Agent: Mutt/1.5.3i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: enum@ietf.org, Dale.Worley@comcast.net, 'Otmar Lendl' <lendl@nic.at>,
	richard@shockey.us
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

lconroy said:
> "unused" already states that the C-o-R may be able to provision every  
> ENUM
> domain for which it is responsible. If there are parts of the tree  
> for which
> an entity is not responsible, then it is "from the Ministry of  
> stating the
> bleedin' obvious" that it should not try to provision entries for  
> those parts.

Not so obvious.

Under the UK rules, my employer (THUS) is "rangeholder" for +44 20 7958 xxxx.
Some of the numbers in that block have been ported to C&W.

Incoming calls to those C&W numbers don't work unless we co-operate, so
there is a sense in which we, as rangeholder, are responsible for them. On
the other hand, the numbers are used by a C&W customer, so there's a sense
in which C&W are responsible.

It needs to be explicitly stated that THUS should *not* try to provision
entries for the ported numbers even though they have some responsibility.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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 Mon Jan 22 05:09:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H8w6t-0005hS-Ld; Mon, 22 Jan 2007 05:09:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H8w6s-0005h8-Fh
	for enum@ietf.org; Mon, 22 Jan 2007 05:09:06 -0500
Received: from sirius.wcom.co.uk ([193.131.254.154]
	helo=sirius.emea.verizonbusiness.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8w6q-0005SS-Sx
	for enum@ietf.org; Mon, 22 Jan 2007 05:09:06 -0500
Received: from sirius.wcom.co.uk ([166.59.190.29] helo=sirius.emea.mci.com)
	by sirius.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H8w6X-0000Cp-UH; Mon, 22 Jan 2007 10:08:47 +0000
Received: from breen.emea.verizonbusiness.com (leste.wcom.co.uk
	[166.59.190.250]) by sirius.emea.mci.com (4.7.0.120) with ESMTP id ;
	Mon, 22 Jan 2007 10:07:21 GMT
Received: from ms-lon-exgw02.uk.mcilink.com ([166.59.191.19]
	helo=ms-lon-exgw02.emea.dsmain.com)
	by breen.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1H8w5B-00068A-69; Mon, 22 Jan 2007 10:07:21 +0000
Received: by ms-lon-exgw02.uk.mcilink.com with Internet Mail Service
	(5.5.2658.27) id <C2R33NQZ>; Mon, 22 Jan 2007 10:07:03 -0000
Message-ID: <CA3896DB5903C14EAAC9D8E91D1167CBCC772F@ms-lon-exmb06.uk.mcilink.com>
From: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
To: "'Clive D.W. Feather'" <clive@demon.net>, lconroy <lconroy@insensate.co.uk>
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
Date: Mon, 22 Jan 2007 10:07:00 -0000
X-Mailer: Internet Mail Service (5.5.2658.27)
MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40)
X-VZ-EMEA-Spam-Score: -499.5
	(---------------------------------------------------)
X-VZ-EMEA-Signature: 749f0ef35e791e2a65d84159e2c1bdab
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc: enum@ietf.org, Dale.Worley@comcast.net, 'Otmar Lendl' <lendl@nic.at>,
	richard@shockey.us
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0156270077=="
Errors-To: enum-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0156270077==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73E0D.0E44D699"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C73E0D.0E44D699
Content-Type: text/plain


Clive, is this not just a hangover from the 'return to block holder'
solution that the UK implemented on PSTN networks many years ago now?

Whilst your range holder status does not amend for the UK PSTN and TDM
traffic, the onward SIP/ENUM operator which a subscribed end-user would:

1. Know that they are the donor of the ported number PSTN; and
2. Have obligations on the PSTN to service the end-user via the address
which in this case is a number, to include potentially SIP services.

I believe you might need to take a look at the Haberler and Stastny work on
portabilty which I think works to a large extent.

This is not rocket science at all.

Ronan 

-----Original Message-----
From: Clive D.W. Feather [mailto:clive@demon.net] 
Sent: 22 January 2007 09:57
To: lconroy
Cc: enum@ietf.org; Dale.Worley@comcast.net; 'Otmar Lendl';
richard@shockey.us
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt

lconroy said:
> "unused" already states that the C-o-R may be able to provision every 
> ENUM domain for which it is responsible. If there are parts of the 
> tree for which an entity is not responsible, then it is "from the 
> Ministry of stating the bleedin' obvious" that it should not try to 
> provision entries for those parts.

Not so obvious.

Under the UK rules, my employer (THUS) is "rangeholder" for +44 20 7958
xxxx.
Some of the numbers in that block have been ported to C&W.

Incoming calls to those C&W numbers don't work unless we co-operate, so
there is a sense in which we, as rangeholder, are responsible for them. On
the other hand, the numbers are used by a C&W customer, so there's a sense
in which C&W are responsible.

It needs to be explicitly stated that THUS should *not* try to provision
entries for the ported numbers even though they have some responsibility.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | 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

------_=_NextPart_001_01C73E0D.0E44D699
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: [Enum] draft-ietf-enum-unused-00.txt</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Clive, is this not just a hangover from the 'return =
to block holder' solution that the UK implemented on PSTN networks many =
years ago now?</FONT></P>

<P><FONT SIZE=3D2>Whilst your range holder status does not amend for =
the UK PSTN and TDM traffic, the onward SIP/ENUM operator which a =
subscribed end-user would:</FONT></P>

<P><FONT SIZE=3D2>1. Know that they are the donor of the ported number =
PSTN; and</FONT>
<BR><FONT SIZE=3D2>2. Have obligations on the PSTN to service the =
end-user via the address which in this case is a number, to include =
potentially SIP services.</FONT></P>

<P><FONT SIZE=3D2>I believe you might need to take a look at the =
Haberler and Stastny work on portabilty which I think works to a large =
extent.</FONT></P>

<P><FONT SIZE=3D2>This is not rocket science at all.</FONT>
</P>

<P><FONT SIZE=3D2>Ronan </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Clive D.W. Feather [<A =
HREF=3D"mailto:clive@demon.net">mailto:clive@demon.net</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: 22 January 2007 09:57</FONT>
<BR><FONT SIZE=3D2>To: lconroy</FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; Dale.Worley@comcast.net; 'Otmar =
Lendl'; richard@shockey.us</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] =
draft-ietf-enum-unused-00.txt</FONT>
</P>

<P><FONT SIZE=3D2>lconroy said:</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;unused&quot; already states that the =
C-o-R may be able to provision every </FONT>
<BR><FONT SIZE=3D2>&gt; ENUM domain for which it is responsible. If =
there are parts of the </FONT>
<BR><FONT SIZE=3D2>&gt; tree for which an entity is not responsible, =
then it is &quot;from the </FONT>
<BR><FONT SIZE=3D2>&gt; Ministry of stating the bleedin' obvious&quot; =
that it should not try to </FONT>
<BR><FONT SIZE=3D2>&gt; provision entries for those parts.</FONT>
</P>

<P><FONT SIZE=3D2>Not so obvious.</FONT>
</P>

<P><FONT SIZE=3D2>Under the UK rules, my employer (THUS) is =
&quot;rangeholder&quot; for +44 20 7958 xxxx.</FONT>
<BR><FONT SIZE=3D2>Some of the numbers in that block have been ported =
to C&amp;W.</FONT>
</P>

<P><FONT SIZE=3D2>Incoming calls to those C&amp;W numbers don't work =
unless we co-operate, so there is a sense in which we, as rangeholder, =
are responsible for them. On the other hand, the numbers are used by a =
C&amp;W customer, so there's a sense in which C&amp;W are =
responsible.</FONT></P>

<P><FONT SIZE=3D2>It needs to be explicitly stated that THUS should =
*not* try to provision entries for the ported numbers even though they =
have some responsibility.</FONT></P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Clive D.W. Feather&nbsp; | Work:&nbsp; =
&lt;clive@demon.net&gt;&nbsp;&nbsp; | Tel:&nbsp;&nbsp;&nbsp; +44 20 =
8495 6138</FONT>
<BR><FONT SIZE=3D2>Internet Expert&nbsp;&nbsp;&nbsp;&nbsp; | =
Home:&nbsp; &lt;clive@davros.org&gt;&nbsp; | Fax:&nbsp;&nbsp;&nbsp; +44 =
870 051 9937</FONT>
<BR><FONT SIZE=3D2>Demon Internet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | WWW: =
<A HREF=3D"http://www.davros.org" =
TARGET=3D"_blank">http://www.davros.org</A> | Mobile: +44 7973 =
377646</FONT>
<BR><FONT SIZE=3D2>THUS =
plc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; |</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>enum mailing list</FONT>
<BR><FONT SIZE=3D2>enum@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C73E0D.0E44D699--


--===============0156270077==
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

--===============0156270077==--




From enum-bounces@ietf.org Tue Jan 23 13:35:17 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9QTa-000745-JT; Tue, 23 Jan 2007 13:34:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9QTZ-00073x-Aq; Tue, 23 Jan 2007 13:34:33 -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 1H9QTU-0002j7-4a; Tue, 23 Jan 2007 13:34:33 -0500
Received: from ([24.40.15.118])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.29762663;
	Tue, 23 Jan 2007 13:34:15 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PACDCEXCSMTP04.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 13:34:15 -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] Request for
	Publication-draft-ietf-enum-infrastructure-04.txt
Date: Tue, 23 Jan 2007 13:34:14 -0500
Message-ID: <45AEC6EF95942140888406588E1A6602B3B93E@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Request for
	Publication-draft-ietf-enum-infrastructure-04.txt
Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYiAFO6UAAM0nxjA=
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <Joakim.Stralmark@pts.se>, <richard@shockey.us>, <iesg-secretary@ietf.org>,
	<enum@ietf.org>
X-OriginalArrivalTime: 23 Jan 2007 18:34:15.0714 (UTC)
	FILETIME=[15E2E020:01C73F1D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: fluffy@cisco.com, paf@cisco.com, jon.peterson@neustar.biz
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

> Anyway comments on:
>=20
> Draft-ietf-enum-infrastructure-04 - in 7.1 for [2] it should=20
> be 2005 for ITU-T Rec. E.164

That was my oversight.  I corrected it in another draft I was working on
and forgot to update this one.  I will make that change and spin a -05.

Jason

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



From enum-bounces@ietf.org Wed Jan 24 15:50:55 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9p4x-0007zv-KO; Wed, 24 Jan 2007 15:50:47 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9p4j-0007ak-HG; Wed, 24 Jan 2007 15:50:33 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1H9p4j-0008Hx-0r; Wed, 24 Jan 2007 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 D8A712ACFE;
	Wed, 24 Jan 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H9p4E-0008W8-Ig; Wed, 24 Jan 2007 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: <E1H9p4E-0008W8-Ig@stiedprstage1.ietf.org>
Date: Wed, 24 Jan 2007 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-05.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=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-05.txt
	Pages		: 6
	Date		: 2007-1-24
	
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-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-infrastructure-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-infrastructure-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: <2007-1-24134638.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-infrastructure-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-infrastructure-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-1-24134638.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 Jan 24 15:51:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9p4Y-000765-3R; Wed, 24 Jan 2007 15:50:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9p4G-0006ue-HD; Wed, 24 Jan 2007 15:50:04 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H9p4G-000241-3C; Wed, 24 Jan 2007 15:50:04 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 720B826F16;
	Wed, 24 Jan 2007 20:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H9p4E-0008Vz-Gi; Wed, 24 Jan 2007 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: <E1H9p4E-0008Vz-Gi@stiedprstage1.ietf.org>
Date: Wed, 24 Jan 2007 15: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-04.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=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-04.txt
	Pages		: 12
	Date		: 2007-1-24
	
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-04.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-04.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-04.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: <2007-1-24134110.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-combined-04.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-enum-combined-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-1-24134110.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 Jan 24 17:16:23 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9qPS-0000hP-0n; Wed, 24 Jan 2007 17:16:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qPQ-0000gK-Mt
	for enum@ietf.org; Wed, 24 Jan 2007 17:16:00 -0500
Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qPP-0003zg-E4
	for enum@ietf.org; Wed, 24 Jan 2007 17:16:00 -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] I-D ACTION:draft-ietf-enum-infrastructure-05.txt 
Date: Wed, 24 Jan 2007 17:15:36 -0500
Message-ID: <45AEC6EF95942140888406588E1A6602B3B9A8@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-05.txt 
Thread-Index: Acc/+ZOFe2Z9BI8UTtWxL2j9AmwabQAC3kwA
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <enum@ietf.org>
X-OriginalArrivalTime: 24 Jan 2007 22:15:36.0384 (UTC)
	FILETIME=[2C320C00:01C74005]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

The only change of content here was the Normative Reference #2 (section
7.1) to refer to the newer ITU docs -- per feedback in WGLC.

Regards
Jason

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
> Sent: Wednesday, January 24, 2007 3:50 PM
> To: i-d-announce@ietf.org
> Cc: enum@ietf.org
> Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-05.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Telephone Number Mapping=20
> Working Group of the IETF.
>=20
> 	Title		: The E.164 to Uniform Resource Identifiers=20
>                           (URI) Dynamic Delegation Discovery System=20
>                           (DDDS) Application for Infrastructure ENUM
> 	Author(s)	: J. Livingood, et al.
> 	Filename	: draft-ietf-enum-infrastructure-05.txt
> 	Pages		: 6
> 	Date		: 2007-1-24
> =09
> This document defines a use case as well as a proposal for a parallel=20
>    namespace to "e164.arpa" as defined in RFC3761, to be used for=20
>    Infrastructure ENUM purposes.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastruc
> ture-05.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to i-d-announce-request@ietf.org with the word=20
> unsubscribe in the body of the message.=20
> 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=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then=20
> "get draft-ietf-enum-infrastructure-05.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> 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-05.txt".
> =09
> 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=20
> 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=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-Draft.
>=20

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



From enum-bounces@ietf.org Wed Jan 24 21:58:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9unx-0007Ge-4j; Wed, 24 Jan 2007 21:57:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9unv-0007GM-S0
	for enum@ietf.org; Wed, 24 Jan 2007 21:57:35 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9unu-0008GK-EK
	for enum@ietf.org; Wed, 24 Jan 2007 21:57:35 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l0P2vSb21681; Wed, 24 Jan 2007 21:57: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] draft-ietf-enum-unused-00.txt
Date: Wed, 24 Jan 2007 21:57:24 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA30FB964B4@zcarhxm0.corp.nortel.com>
In-Reply-To: <E9B86B14-C29D-423D-91A6-E88FD2C6C585@insensate.co.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] draft-ietf-enum-unused-00.txt
Thread-Index: Acc7yLv9NMA5g6ePRXGe/xG4hz8wQwEYcCmQ
From: "James McEachern" <jmce@nortel.com>
To: "lconroy" <lconroy@insensate.co.uk>, <Dale.Worley@comcast.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Cc: enum@ietf.org, Stastny Richard <Richard.Stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Lawrence,
In the spirit of concrete suggestions focused on the "unused" draft, I'd
like to propose text that may clarify some of the confusion about closed
number plans.  Specifically:

Existing text:
7.2.1.  Closed Numbering Plans
In many countries closed numbering plans are in use.  In such a scheme,
all valid telephone numbers have a defined length - the number of digits
used for the subscriber number is fixed.  Thus, for a given initial
digit string, the length of the subsequent digit string together
constituting a valid telephone number is known.  All other digit strings
are invalid.

--- proposed alternate text ---
In many countries closed numbering plans are in use.  In such a scheme,
the originating system can unambiguously determine when a telephone
number is complete (i.e. when no more digits are required).  Thus, in
closed numbering plans it is always possible to identify invalid digit
strings that have too few, or too many, digits.
--- end proposed alternate text ---

It seems to me we can sidestep the whole issue of "initial digit
strings" because the essential characteristic of the closed numbering
plan is that you can always identify invalid numbers a priori.

I think the rest of section 7.2.1 can probably stand as is.

... hope this helps.

Jim

-----Original Message-----
From: lconroy [mailto:lconroy@insensate.co.uk]=20
Sent: Friday, January 19, 2007 7:53 AM
To: McEachern, James (CAR:AR00); Dale.Worley@comcast.net
Cc: enum@ietf.org; Stastny Richard
Subject: Re: [Enum] draft-ietf-enum-unused-00.txt

Hi Folks,
[sorry about the delay in sending this - just got back in email range
  after the storms in Europe made life interesting]

  As the author of this particular bit of text, I apologise for the
confusion it has apparently sown.

IGNORING dialling plans and CONSIDERING ONLY number plans:-

 From my perspective, there are closed and open numbering plans.
Within closed numbering plans, there are fixed numbering plans.

The UK does not have a fixed numbering plan - it is, however, closed.
If you have a block number, you know how long the subsequent digits
will be.

I understood that the NANP has a fixed numbering plan. All digit
strings are the same length. IIUC, it appears that this is not (or
is not going to be) the case. There are or will be a mix of different
number lengths.
I stand corrected and I have learnt my new thing for today.

If there are no longer any fully fixed number plans, then we can
(happily) remove the sub-section on fixed numbering plans.

To reiterate, this whole section says nothing of the dialling
plans used - some places may choose to "optimise" the dialling plan
processed, some others may not.

In closed numbering plans, an end user gets a number of a defined
length (defined by the initial digit string - +44160650 is a different
string from +44160649). It is indeed true that the prefix +441606 does
not define the subsequent number length. That is NOT the initial digit
string I used in the examples).

I chose "initial digit string", but "prefix" would cause exactly the
same problems. It is imprecise, as closed-but-not-fixed numbering plans
can have different lengths of such prefix/initial digit strings that
define the length of the subsequent digit strings.

If anyone can think of text (other than initial digit string or prefix)
to describe clearly these variable length prefixes I (and Richard) will
be happy. E.164 doesn't do this (or other things, as Richard has already
pointed out).

all the best,
   Lawrence

On 17 Jan 2007, at 18:14, James McEachern wrote:
> Richard,
> I agree it would be a good idea to rewrite this sentence.  While =20
> you are
> at it, I suggest you look at the next sentence as well.  It currently
> says:
>
> "Thus, for a given initial digit string, the length of the subsequent
> digit string together constituting a valid telephone number is known."
>
> The problem is that this could be interpreted as saying that for *any*
> initial digit string, the length of the ... valid telephone number is
> known.  Clearly this is not the case for "+441606" - but since =20
> "+441606"
> is "a given initial digit string" the existing text appears to imply
> that it should.
>
> BTW, I did eventually figure out what this section was saying, but it
> took a while...
>
> Jim
>
> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Wednesday, January 17, 2007 9:31 AM
> To: Dale.Worley@comcast.net; enum@ietf.org
> Subject: RE: [Enum] draft-ietf-enum-unused-00.txt
>
> I have to admit that this sentence is not clear and
> we will re-write it
>
> Richard
>
>> -----Original Message-----
>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
>> Sent: Wednesday, January 17, 2007 3:20 PM
>> To: enum@ietf.org
>> Subject: [Enum] draft-ietf-enum-unused-00.txt
>>
>> To isolate my point, let me quote the beginning of 7.2.1:
>>
>>    In many countries closed numbering plans are in use.  In such a
>>    scheme, all valid telephone numbers have a defined length - the
>>    number of digits used for the subscriber number is fixed.
>>
>> To me, this means a system like North America, +1, where all E.164
>> numbers (all subscriber numbers) have the same length (11 digits).
>>
>> 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
>
> _______________________________________________
> 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 Jan 26 10:31:43 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAT1d-0002kx-B9; Fri, 26 Jan 2007 10:30:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT1c-0002ks-HG
	for enum@ietf.org; Fri, 26 Jan 2007 10:30:00 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAT1a-0005kb-56
	for enum@ietf.org; Fri, 26 Jan 2007 10:30:00 -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
	l0QFTpYw001496 for <enum@ietf.org>; Fri, 26 Jan 2007 07:29:57 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <enum@ietf.org>
Date: Fri, 26 Jan 2007 10:29:42 -0500
Message-ID: <03cf01c7415e$cde5a8e0$ee201f0a@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.3028
Thread-Index: AcdBXsxsRZjx5f3CR7G/MU/EXO3h/w==
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] SECOND CALL Request for Agenda items for IETF ENUM in prague.
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


If we anticipate any new drafts coming etc or requests for time let us know
ASAP.


Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
Skype:"rshockey101"
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>






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



From enum-bounces@ietf.org Fri Jan 26 10:35:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAT6O-0005Kf-0M; Fri, 26 Jan 2007 10:34:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT6N-0005Ka-1R
	for enum@ietf.org; Fri, 26 Jan 2007 10:34:55 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAT6K-0006Sz-Kf
	for enum@ietf.org; Fri, 26 Jan 2007 10:34:55 -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
	l0QFYnkC002597 for <enum@ietf.org>; Fri, 26 Jan 2007 07:34:54 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <enum@ietf.org>
Date: Fri, 26 Jan 2007 10:34:39 -0500
Message-ID: <03d801c7415f$7f3b4dc0$ee201f0a@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.3028
Thread-Index: AcdBBweD7AnKMk8ARieTkWXUBRCrtwAWHKOw
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: 0ddefe323dd869ab027dbfff7eff0465
Subject: [Enum] FW: Internet-Drafts Submission Cutoff Dates for the 68th
	IETF Meeting in Prague, Czech Republic
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



> -----Original Message-----
> From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]
> Sent: Friday, January 26, 2007 12:00 AM
> To: ietf-announce@ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting
> in Prague, Czech Republic
> 
> 
> There are two (2) Internet-Draft cutoff dates for the 68th
> IETF Meeting in Prague, Czech Republic:
> 
> February 26th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
> 
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> February 26th at 9:00 AM ET. As always, all initial submissions with a
> filename beginning with "draft-ietf" must be approved by the
> appropriate WG Chair before they can be processed or announced.  The
> Secretariat would appreciate receiving WG Chair approval by Monday,
> February 19th at 9:00 AM ET.
> 
> March 5th: Cutoff Date for Revised (i.e., version -01 and higher)
> Internet-Draft Submissions
> 
> All revised Internet-Drafts (version -01 and higher) must be submitted
> by Monday, March 5th at 9:00 AM ET.
> 
> Initial and revised Internet-Drafts received after their respective
> cutoff dates will not be made available in the Internet-Drafts
> directory or announced until on or after Monday, March 19th at 9:00
> AM ET, when Internet-Draft posting resumes.  Please do not wait until
> the last minute to submit.
> 
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> internet-drafts@ietf.org.
> 
> The IETF Secretariat
> 
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 68th IETF Meeting can be found at
> http://www.ietf.org/meetings/cutoff_dates_68.html.
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce


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



From enum-bounces@ietf.org Fri Jan 26 12:34:39 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAUxW-0004ud-1E; Fri, 26 Jan 2007 12:33:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUxU-0004uS-RO
	for enum@ietf.org; Fri, 26 Jan 2007 12:33:52 -0500
Received: from wodka.aus-biz.com ([65.23.153.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUxS-0008CU-IA
	for enum@ietf.org; Fri, 26 Jan 2007 12:33:52 -0500
Received: from [192.168.1.103] (cpe-24-210-132-91.woh.res.rr.com
	[24.210.132.91])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by wodka.aus-biz.com (Postfix) with ESMTP id 5EA0211A60B;
	Fri, 26 Jan 2007 12:33:45 -0500 (EST)
Message-ID: <45BA3B80.5000206@e164.org>
Date: Fri, 26 Jan 2007 12:33:52 -0500
From: Duane <duane@e164.org>
User-Agent: Thunderbird 2.0b2 (X11/20070116)
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>,  enum@ietf.org
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D463C54A7@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C54A7@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Stastny Richard wrote:

Not sure if this is inline with your draft or not, but e164.org 
publishes wild card records to route all toll free numbers for a number 
of countries via 1 or more companies that offer routing and in return 
they earn revenue from the calls they route.

However it is not desirable to have some of these calls routed via VoIP, 
at least at this point in time, and people want to inject a no-voip 
response into dns to exclude these numbers.

One reason people want to exclude some numbers is because the call goes 
to a modem bank, and the provider routing the calls doesn't support t.38.

At the same time we don't want to remove the listing for these toll free 
routes as many people take advantage of them to bypass toll charges when 
calling from other countries or bypassing toll charges introduced by 
mobile phone carriers. We would also like to avoid listing every 
possible valid route, so some form of method to exclude records is 
needed, but without hard failing the call.

-- 

Best regards,
  Duane

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



From enum-bounces@ietf.org Fri Jan 26 13:13:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAVZr-0002Og-78; Fri, 26 Jan 2007 13:13:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVZp-0002OQ-JG
	for enum@ietf.org; Fri, 26 Jan 2007 13:13:29 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAVZo-0005bk-7u
	for enum@ietf.org; Fri, 26 Jan 2007 13:13: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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Enum] no-voip
Date: Fri, 26 Jan 2007 19:09:46 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C67@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] no-voip
Thread-Index: AcdBcA/nHTz+j8GxRaGdrR8lSyzRqwABRmDE
References: <32755D354E6B65498C3BD9FD496C7D463C54A7@oefeg-s04.oefeg.loc>
	<45BA3B80.5000206@e164.org>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Duane" <duane@e164.org>,
	<enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


>Not sure if this is inline with your draft or not,=20
=20
No, it is not. unused is only for unallocated/unassigned numbers
=20
>but e164.org
>publishes wild card records to route all toll free numbers for a number
>of countries via 1 or more companies that offer routing and in return
>they earn revenue from the calls they route.

>However it is not desirable to have some of these calls routed via =
VoIP,
>at least at this point in time, and people want to inject a no-voip
>response into dns to exclude these numbers.

>One reason people want to exclude some numbers is because the call goes
>to a modem bank, and the provider routing the calls doesn't support =
t.38.

>At the same time we don't want to remove the listing for these toll =
free
>routes as many people take advantage of them to bypass toll charges =
when
>calling from other countries or bypassing toll charges introduced by
>mobile phone carriers. We would also like to avoid listing every
>possible valid route, so some form of method to exclude records is
>needed, but without hard failing the call.
=20
You may use voice:tel or pstn:tel for these type of calls
=20
Richard

--

Best regards,
  Duane


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



From enum-bounces@ietf.org Fri Jan 26 15:19:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAXX5-0000zh-TY; Fri, 26 Jan 2007 15:18:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXX4-0000xz-Qx
	for enum@ietf.org; Fri, 26 Jan 2007 15:18: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 1HAXX3-00088G-HT
	for enum@ietf.org; Fri, 26 Jan 2007 15:18:46 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id 426B74C973; Fri, 26 Jan 2007 21:18:32 +0100 (CET)
Date: Fri, 26 Jan 2007 21:18:32 +0100
From: Otmar Lendl <lendl@nic.at>
To: Duane <duane@e164.org>
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
Message-ID: <20070126201831.GB18412@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, Duane <duane@e164.org>,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
References: <32755D354E6B65498C3BD9FD496C7D463C54A7@oefeg-s04.oefeg.loc>
	<45BA3B80.5000206@e164.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45BA3B80.5000206@e164.org>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: enum@ietf.org, Stastny Richard <Richard.Stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/26 18:01, Duane <duane@e164.org> wrote:
> Not sure if this is inline with your draft or not, but e164.org 
> publishes wild card records to route all toll free numbers for a number 
> of countries via 1 or more companies that offer routing and in return 
> they earn revenue from the calls they route.

[..]

> At the same time we don't want to remove the listing for these toll free 
> routes as many people take advantage of them to bypass toll charges when 
> calling from other countries or bypassing toll charges introduced by 
> mobile phone carriers. We would also like to avoid listing every 
> possible valid route, so some form of method to exclude records is 
> needed, but without hard failing the call.

If I get this correctly, then you have the following wildcard in
your zonefile

*.0.0.8.1.e164.org. 600 IN  NAPTR   200 10 "u" "E2U+SIP"
	"!^\\+1800(.*)$!sip:1800\\1@tf.voipmich.com!" .
*.0.0.8.1.e164.org. 600 IN  NAPTR   200 10 "u" "E2U+SIP"
	"!^\\+1800(.*)$!sip:1800\\1@sip.tollfreegateway.com!" .

and you want no ENUM response to e.g. +1800FAXTOME.

You don't have to address this on the ENUM service-type layer, you can
exclude any number from this wildcard by adding *any* RR at that
number's ENUM domain.

e.g. 

3.6.6.8.9.2.3.0.0.1.e164.org. IN TXT "dummy"

should do.

While adding a pstn:tel NAPTR there might be the more correct way to go,
this approach has the advantage that most ENUM clients just get no
records back and thus revert to the defaul call processing.

/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 Jan 26 16:09:47 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAYK7-0006ek-Lp; Fri, 26 Jan 2007 16:09:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYK6-0006eJ-5v
	for enum@ietf.org; Fri, 26 Jan 2007 16:09:26 -0500
Received: from wodka.aus-biz.com ([65.23.153.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAYK1-0007nj-Sk
	for enum@ietf.org; Fri, 26 Jan 2007 16:09:26 -0500
Received: from [192.168.1.103] (cpe-24-210-132-91.woh.res.rr.com
	[24.210.132.91])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by wodka.aus-biz.com (Postfix) with ESMTP id 4636B11A60B
	for <enum@ietf.org>; Fri, 26 Jan 2007 16:09:21 -0500 (EST)
Message-ID: <45BA6E07.5040208@e164.org>
Date: Fri, 26 Jan 2007 16:09:27 -0500
From: Duane <duane@e164.org>
User-Agent: Thunderbird 2.0b2 (X11/20070116)
MIME-Version: 1.0
To: enum@ietf.org
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
References: <32755D354E6B65498C3BD9FD496C7D463C54A7@oefeg-s04.oefeg.loc>	<45BA3B80.5000206@e164.org>
	<20070126201831.GB18412@nic.at>
In-Reply-To: <20070126201831.GB18412@nic.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Otmar Lendl wrote:

> You don't have to address this on the ENUM service-type layer, you can
> exclude any number from this wildcard by adding *any* RR at that
> number's ENUM domain.
> 
> e.g. 
> 
> 3.6.6.8.9.2.3.0.0.1.e164.org. IN TXT "dummy"

This will only work if the client specifies TXT or ANY, if they search 
for NAPTR records specifically the server will still return NAPTR 
records higher in the tree.

The only way to prevent this is with a NAPTR record.

-- 

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 Sat Jan 27 09:07:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAoBX-00054i-CR; Sat, 27 Jan 2007 09:05:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAoBV-00054a-V6
	for enum@ietf.org; Sat, 27 Jan 2007 09:05:37 -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 1HAoBT-0007FA-Lf
	for enum@ietf.org; Sat, 27 Jan 2007 09:05:37 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by insensate.co.uk (Postfix) with ESMTP id 9C88097518;
	Sat, 27 Jan 2007 14:05:12 +0000 (GMT)
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C67@oefeg-s04.oefeg.loc>
References: <32755D354E6B65498C3BD9FD496C7D463C54A7@oefeg-s04.oefeg.loc>
	<45BA3B80.5000206@e164.org>
	<32755D354E6B65498C3BD9FD496C7D462C4C67@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: <990CEC4C-BC77-4E7B-8661-72FD09E2279F@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] no-voip
Date: Sat, 27 Jan 2007 14:05:12 +0000
To: Richard Stastny <Richard.Stastny@oefeg.at>, richard@shockey.us,
	=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: IETF ENUM WG <enum@ietf.org>, Duane <duane@e164.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Richard, Duane, Richard, Patrik, folks,
First - I am beginning to wonder if there should be a separate slot for
discussions that are not concerned directly with unused, but are related
to using the stuff that has been standardised already.

Esteemed co-chairs - would it be sensible to split out the narrow  
"unused"
Enumservice from the more general provisioning and use stuff?
As an alternative, should this be in PEPPERMINT or DNSOPS or DNSEXT?

As Richard says, there is a perfectly usable way of achieving what  
you seem
to want to do - voice:tel. This says to place a call via the PSTN,  
and is
already an RFC (RFC 4415). You don't need unused.

Second - PSTN:tel?
Maybe X-PSTN:tel would be better if you want to do something  
"different".

Final point - Wildcards are evil. If you must play with loaded weapons,
see RFC 4592.

all the best,

On 26 Jan 2007, at 18:09, Stastny Richard wrote:
>> Not sure if this is inline with your draft or not,
> No, it is not. unused is only for unallocated/unassigned numbers
>
>> but e164.org
>> publishes wild card records to route all toll free numbers for a  
>> number
>> of countries via 1 or more companies that offer routing and in return
>> they earn revenue from the calls they route.
>> However it is not desirable to have some of these calls routed via  
>> VoIP,
>> at least at this point in time, and people want to inject a no-voip
>> response into dns to exclude these numbers.
>> One reason people want to exclude some numbers is because the call  
>> goes
>> to a modem bank, and the provider routing the calls doesn't  
>> support t.38.
>> At the same time we don't want to remove the listing for these  
>> toll free
>> routes as many people take advantage of them to bypass toll  
>> charges when
>> calling from other countries or bypassing toll charges introduced by
>> mobile phone carriers. We would also like to avoid listing every
>> possible valid route, so some form of method to exclude records is
>> needed, but without hard failing the call.
> You may use voice:tel or pstn:tel for these type of calls
>
> Richard
>
> --
>
> Best regards,
>   Duane
>
>
> _______________________________________________
> 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 Jan 28 23:21:50 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBNzc-0001w6-Hk; Sun, 28 Jan 2007 23:19:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBNza-0001vw-Ib
	for enum@ietf.org; Sun, 28 Jan 2007 23:19:42 -0500
Received: from ext-sendmail2.labs.att.com ([205.173.58.20]
	helo=sendmail2.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBNzY-0002pV-7w
	for enum@ietf.org; Sun, 28 Jan 2007 23:19:42 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail2.labs.att.com (8.13.7/8.13.1) with ESMTP id l0T4JdLI029743
	for <enum@ietf.org>; Sun, 28 Jan 2007 22:19:39 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0T4Ht1C021089
	for <enum@ietf.org>; Sun, 28 Jan 2007 22:17:55 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 28 Jan 2007 22:19:39 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 28 Jan 2007 22:19:38 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF0478077F@TSMAIL2.ad.tri.sbc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdDXLD1A5nk0V90TNqS9xzWgrgwdQ==
From: "Jackson, James" <james_jackson@labs.att.com>
To: <enum@ietf.org>
X-OriginalArrivalTime: 29 Jan 2007 04:19:39.0410 (UTC)
	FILETIME=[B14E4F20:01C7435C]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Subject: [Enum] Proposal for new enumservice "voicemail", using SIP URI
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1517986633=="
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1517986633==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7435C.B128F8FC"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7435C.B128F8FC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would like to submit a registration for a new enumservice "voicemail"
using a SIP URI. Voicemail platforms are often accessible via SIP and it
would be desirable for callers to have the option to go straight to
voicemail rather than participate in an interactive form of
communication.

=20

Any feedback from the group would be much appreciated.

=20

Thanks,

James


------_=_NextPart_001_01C7435C.B128F8FC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I would like to submit a registration for a new =
enumservice &#8220;voicemail&#8221;
using a SIP URI. Voicemail platforms are often accessible via SIP and it =
would
be desirable for callers to have the option to go straight to voicemail =
rather
than participate in an interactive form of =
communication.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Any feedback from the group would be much =
appreciated.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>James<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C7435C.B128F8FC--


--===============1517986633==
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

--===============1517986633==--




From enum-bounces@ietf.org Mon Jan 29 08:53:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBWw2-0008NO-7v; Mon, 29 Jan 2007 08:52:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWw1-0008NI-MQ
	for enum@ietf.org; Mon, 29 Jan 2007 08:52:37 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBWw0-00065t-3c
	for enum@ietf.org; Mon, 29 Jan 2007 08:52:37 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-5.cisco.com with ESMTP; 29 Jan 2007 05:52:35 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0TDqZ3n020859; 
	Mon, 29 Jan 2007 05:52:35 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0TDqJHC028251;
	Mon, 29 Jan 2007 05:52:34 -0800 (PST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 08:52:27 -0500
Received: from [161.44.183.228] ([161.44.183.228]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 08:52:27 -0500
Message-ID: <45BDFC1A.6080108@cisco.com>
Date: Mon, 29 Jan 2007 08:52:26 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Jackson, James" <james_jackson@labs.att.com>
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
References: <0CED449E95A92A42991EB71B778C17BF0478077F@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF0478077F@TSMAIL2.ad.tri.sbc.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 29 Jan 2007 13:52:27.0407 (UTC)
	FILETIME=[B63A79F0:01C743AC]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1014; t=1170078755;
	x=1170942755; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Enum]=20Proposal=20for=20new=20enumservice=20=22voic
	email=22,=20using=20SIP=20URI |Sender:=20;
	bh=BpP4l24xXzcL19r1Sev6MwBph2W3W8ywrJEK+O+za50=;
	b=Wxtug/dTjUKaMWkSnTj/SYcAQY+c+HOaCe9ZCUthJ1qMVtXIUR0VlwfQAmIaghtLJSbZveb5
	SuSVk5lkb5T4a56BdHPWZBhmbWlyZBd0ErabjFqgJmcw3ORNqPmQfTET;
Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

I think the use of new enumservices for stuff like this is getting 
entirely out of hand. The proposed solution would work for E.164 
numbers, but the same functionality is of equal relevance for regular 
SIP URIs.

There is already a mechanism (callerprefs) for requesting (or refusing) 
the voicemail service associated with a sip AoR.

	Paul

Jackson, James wrote:
> I would like to submit a registration for a new enumservice “voicemail” 
> using a SIP URI. Voicemail platforms are often accessible via SIP and it 
> would be desirable for callers to have the option to go straight to 
> voicemail rather than participate in an interactive form of communication.
> 
>  
> 
> Any feedback from the group would be much appreciated.
> 
>  
> 
> Thanks,
> 
> James
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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 Jan 29 11:50:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBZhs-0007sr-5I; Mon, 29 Jan 2007 11:50:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZhq-0007sL-3q
	for enum@ietf.org; Mon, 29 Jan 2007 11:50:10 -0500
Received: from ext-sendmail1.labs.att.com ([205.173.58.19]
	helo=sendmail1.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZhi-00059v-6w
	for enum@ietf.org; Mon, 29 Jan 2007 11:50:10 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail1.labs.att.com (8.13.7/8.13.1) with ESMTP id l0TGT5n5006788; 
	Mon, 29 Jan 2007 10:29:05 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0TGnvHh023314;
	Mon, 29 Jan 2007 10:49:57 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 10:49:57 -0600
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] Proposal for new enumservice "voicemail", using SIP URI
Date: Mon, 29 Jan 2007 10:49:56 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF04780AF1@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <45BDFC1A.6080108@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdDrMAgeTK4qM57TIm/O2qCye5bEwADIb2Q
References: <0CED449E95A92A42991EB71B778C17BF0478077F@TSMAIL2.ad.tri.sbc.com>
	<45BDFC1A.6080108@cisco.com>
From: "Jackson, James" <james_jackson@labs.att.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 29 Jan 2007 16:49:57.0140 (UTC)
	FILETIME=[81F6C540:01C743C5]
X-Spam-Score: 0.1 (/)
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


I think applicability to E.164 only would also apply to the VPIM service
etc.=20

I agree that callerprefs is an attractive way to address the problem. At
the same time, I would expect it to be much more difficult to achieve
ubiquitous support for callerprefs.

James



-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Monday, January 29, 2007 7:52 AM
To: Jackson, James
Cc: enum@ietf.org
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

I think the use of new enumservices for stuff like this is getting=20
entirely out of hand. The proposed solution would work for E.164=20
numbers, but the same functionality is of equal relevance for regular=20
SIP URIs.

There is already a mechanism (callerprefs) for requesting (or refusing)=20
the voicemail service associated with a sip AoR.

	Paul

Jackson, James wrote:
> I would like to submit a registration for a new enumservice
"voicemail"=20
> using a SIP URI. Voicemail platforms are often accessible via SIP and
it=20
> would be desirable for callers to have the option to go straight to=20
> voicemail rather than participate in an interactive form of
communication.
>=20
> =20
>=20
> Any feedback from the group would be much appreciated.
>=20
> =20
>=20
> Thanks,
>=20
> James
>=20
>=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 Jan 29 12:56:07 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBaij-00048N-Qa; Mon, 29 Jan 2007 12:55:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBaij-00048H-40
	for enum@ietf.org; Mon, 29 Jan 2007 12:55:09 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBaih-0006L3-Nt
	for enum@ietf.org; Mon, 29 Jan 2007 12:55:09 -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 BDBE456845
	for <enum@ietf.org>; Mon, 29 Jan 2007 09:54:56 -0800 (PST)
	(envelope-from spouliotte@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: 0.180,BAYES_99: 3.67,USER_IN_WHITELIST: -30,
	CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -26.150
X-Spam-Level: 
Received: from [128.177.199.55] ([128.177.199.55])
	(authenticated user spouliotte@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits))
	for enum@ietf.org; Mon, 29 Jan 2007 09:54:55 -0800
User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Mon, 29 Jan 2007 09:54:43 -0800
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
From: Shawn Pouliotte <Shawn.Pouliotte@nominum.com>
To: <enum@ietf.org>
Message-ID: <C1E374E3.5565%spouliotte@nominum.com>
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP
 URI
Thread-Index: AcdDzo4dzHYw6K/BEduj5QAX8iZ51g==
In-Reply-To: <45BDFC1A.6080108@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

James,

Is there some functionality that you envision that cannot be achieved with
the current services? I tend to agree that the service set is getting a
little unruly and for the most part people are only using the basic ones
thus far.=20

Can you elaborate on your requirements?

Thanks
Shawn


On 1/29/07 5:52 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

> I think the use of new enumservices for stuff like this is getting
> entirely out of hand. The proposed solution would work for E.164
> numbers, but the same functionality is of equal relevance for regular
> SIP URIs.
>=20
> There is already a mechanism (callerprefs) for requesting (or refusing)
> the voicemail service associated with a sip AoR.
>=20
> Paul
>=20
> Jackson, James wrote:
>> I would like to submit a registration for a new enumservice =B3voicemail=B2
>> using a SIP URI. Voicemail platforms are often accessible via SIP and it
>> would be desirable for callers to have the option to go straight to
>> voicemail rather than participate in an interactive form of communicatio=
n.
>>=20
>> =20
>>=20
>> Any feedback from the group would be much appreciated.
>>=20
>> =20
>>=20
>> Thanks,
>>=20
>> James
>>=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




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



From enum-bounces@ietf.org Mon Jan 29 13:11:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBayF-00020L-78; Mon, 29 Jan 2007 13:11:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBayE-00020B-HR
	for enum@ietf.org; Mon, 29 Jan 2007 13:11:10 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBay9-0008Dn-71
	for enum@ietf.org; Mon, 29 Jan 2007 13:11:10 -0500
Received: from ([10.52.116.31])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.29798708;
	Mon, 29 Jan 2007 13:10:44 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PAOAKEXCSMTP02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 13:10:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Date: Mon, 29 Jan 2007 13:10:30 -0500
Message-ID: <45AEC6EF95942140888406588E1A6602B3BA43@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdDXLD1A5nk0V90TNqS9xzWgrgwdQAcm5Hw
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Jackson, James" <james_jackson@labs.att.com>,
	<enum@ietf.org>
X-OriginalArrivalTime: 29 Jan 2007 18:10:43.0834 (UTC)
	FILETIME=[CAD195A0:01C743D0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0586253985=="
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0586253985==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C743D0.CAAD4AE2"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C743D0.CAAD4AE2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

How is this not already covered by RFC4238?
=20
Service Name: E.164 to VPIM MailTo: URL=20
   URI Type: "Mailto:"=20
   Type: VPIM=20
   Subtype: MAILTO=20
   Functional Specification: See section 4.2 through 4.4 of [RFC4238]
   Intended Usage: COMMON=20
   Author: Greg Vaudreuil (gregv@ieee.org)=20

Service Name: E.164 to VPIM LDAP URL=20
   URI Type: "LDAP:"=20
   Type: VPIM=20
   Subtype: LDAP=20
   Functional Specification: See section 3.2 through 3.3 of [RFC4238]
   Intended Usage: COMMON=20
   Author: Greg Vaudreuil (gregv@ieee.org)=20




________________________________

	From: Jackson, James [mailto:james_jackson@labs.att.com]=20
	Sent: Sunday, January 28, 2007 11:20 PM
	To: enum@ietf.org
	Subject: [Enum] Proposal for new enumservice "voicemail", using
SIP URI
=09
=09

	I would like to submit a registration for a new enumservice
"voicemail" using a SIP URI. Voicemail platforms are often accessible
via SIP and it would be desirable for callers to have the option to go
straight to voicemail rather than participate in an interactive form of
communication.

	=20

	Any feedback from the group would be much appreciated.

	=20

	Thanks,

	James


------_=_NextPart_001_01C743D0.CAAD4AE2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: #606420; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: #606420; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3D#606420 link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D462465817-29012007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>How is this not already covered by=20
RFC4238?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D462465817-29012007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D462465817-29012007>Service =
Name: E.164 to=20
VPIM MailTo: URL <BR>&nbsp;&nbsp; URI Type: "Mailto:" <BR>&nbsp;&nbsp; =
Type:=20
VPIM <BR>&nbsp;&nbsp; Subtype: MAILTO <BR>&nbsp;&nbsp; Functional =
Specification:=20
See section 4.2 through 4.4 of [RFC4238]<BR>&nbsp;&nbsp; Intended Usage: =
COMMON=20
<BR>&nbsp;&nbsp; Author: Greg Vaudreuil (gregv@ieee.org) <BR><BR>Service =
Name:=20
E.164 to VPIM LDAP URL <BR>&nbsp;&nbsp; URI Type: "LDAP:" =
<BR>&nbsp;&nbsp; Type:=20
VPIM <BR>&nbsp;&nbsp; Subtype: LDAP <BR>&nbsp;&nbsp; Functional =
Specification:=20
See section 3.2 through 3.3 of [RFC4238]<BR>&nbsp;&nbsp; Intended Usage: =
COMMON=20
<BR>&nbsp;&nbsp; Author: Greg Vaudreuil (gregv@ieee.org)=20
<BR><BR></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Jackson, James=20
  [mailto:james_jackson@labs.att.com] <BR><B>Sent:</B> Sunday, January =
28, 2007=20
  11:20 PM<BR><B>To:</B> enum@ietf.org<BR><B>Subject:</B> [Enum] =
Proposal for=20
  new enumservice "voicemail", using SIP URI<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I would like to submit a =

  registration for a new enumservice &#8220;voicemail&#8221; using a SIP =
URI. Voicemail=20
  platforms are often accessible via SIP and it would be desirable for =
callers=20
  to have the option to go straight to voicemail rather than participate =
in an=20
  interactive form of communication.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Any feedback from the =
group would=20
  be much appreciated.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">James<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------_=_NextPart_001_01C743D0.CAAD4AE2--


--===============0586253985==
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

--===============0586253985==--




From enum-bounces@ietf.org Mon Jan 29 13:57:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBbfq-0003dG-M0; Mon, 29 Jan 2007 13:56:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbfp-0003c3-E7
	for enum@ietf.org; Mon, 29 Jan 2007 13:56:13 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbfn-0004yC-0z
	for enum@ietf.org; Mon, 29 Jan 2007 13:56:13 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2007 10:56:10 -0800
X-IronPort-AV: i="4.13,253,1167638400"; 
	d="scan'208"; a="51813797:sNHT47404252"
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 l0TIuAdE026997; 
	Mon, 29 Jan 2007 13:56:10 -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 l0TIu8VV002292; 
	Mon, 29 Jan 2007 13:56:10 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 13:56:07 -0500
Received: from [161.44.183.228] ([161.44.183.228]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 13:56:07 -0500
Message-ID: <45BE4347.20007@cisco.com>
Date: Mon, 29 Jan 2007 13:56:07 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Jackson, James" <james_jackson@labs.att.com>
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
References: <0CED449E95A92A42991EB71B778C17BF0478077F@TSMAIL2.ad.tri.sbc.com>
	<45BDFC1A.6080108@cisco.com>
	<0CED449E95A92A42991EB71B778C17BF04780AF1@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF04780AF1@TSMAIL2.ad.tri.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Jan 2007 18:56:07.0551 (UTC)
	FILETIME=[2247D0F0:01C743D7]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1930; t=1170096970;
	x=1170960970; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Enum]=20Proposal=20for=20new=20enumservice=20=22voic
	email=22,=20using=20SIP=20URI |Sender:=20
	|To:=20=22Jackson,=20James=22=20<james_jackson@labs.att.com>;
	bh=ZP4aJXBDArjyll8P0sigEyrWgzjj/6t6ohVbdoLRRv0=;
	b=KCj7Aucru52BpCHojPQs4AAVE6O+/uHrKPEfaEZAF7Rb37U6vjiO2EGiy3kiGjS2GU0ocgNP
	9rBVLo7mWoXhu3JIgzHeq4Jif1jWIM0QdyD+w4ZsZvOabpRCRj/sSNtZ;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
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 <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



Jackson, James wrote:
> I think applicability to E.164 only would also apply to the VPIM service
> etc. 
> 
> I agree that callerprefs is an attractive way to address the problem. At
> the same time, I would expect it to be much more difficult to achieve
> ubiquitous support for callerprefs.

It may be difficult to achieve ubiquitous support for the enum proposal 
too. It requires that there exist a unique, globally routable and 
stable, URI for referencing a users voicemail. I think there are many 
deployments in which that will not be the case. (IMS for example.)

	Paul

> James
> 
> 
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Monday, January 29, 2007 7:52 AM
> To: Jackson, James
> Cc: enum@ietf.org
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
> URI
> 
> I think the use of new enumservices for stuff like this is getting 
> entirely out of hand. The proposed solution would work for E.164 
> numbers, but the same functionality is of equal relevance for regular 
> SIP URIs.
> 
> There is already a mechanism (callerprefs) for requesting (or refusing) 
> the voicemail service associated with a sip AoR.
> 
> 	Paul
> 
> Jackson, James wrote:
>> I would like to submit a registration for a new enumservice
> "voicemail" 
>> using a SIP URI. Voicemail platforms are often accessible via SIP and
> it 
>> would be desirable for callers to have the option to go straight to 
>> voicemail rather than participate in an interactive form of
> communication.
>>  
>>
>> Any feedback from the group would be much appreciated.
>>
>>  
>>
>> Thanks,
>>
>> James
>>
>>
>>
> ------------------------------------------------------------------------
>> _______________________________________________
>> 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 Jan 29 15:07:06 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBcls-0006Ks-Nl; Mon, 29 Jan 2007 15:06:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBclr-0006EZ-PP
	for enum@ietf.org; Mon, 29 Jan 2007 15:06:31 -0500
Received: from ext-sendmail1.labs.att.com ([205.173.58.19]
	helo=sendmail1.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBclo-00072y-BY
	for enum@ietf.org; Mon, 29 Jan 2007 15:06:31 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail1.labs.att.com (8.13.7/8.13.1) with ESMTP id l0TJjX8n010034; 
	Mon, 29 Jan 2007 13:45:33 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0TK4cr2003468;
	Mon, 29 Jan 2007 14:04:38 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 14:06:25 -0600
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] Proposal for new enumservice "voicemail", using SIP URI
Date: Mon, 29 Jan 2007 14:06:24 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <C1E374E3.5565%spouliotte@nominum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdDzo4dzHYw6K/BEduj5QAX8iZ51gADoOYg
References: <45BDFC1A.6080108@cisco.com> <C1E374E3.5565%spouliotte@nominum.com>
From: "Jackson, James" <james_jackson@labs.att.com>
To: "Shawn Pouliotte" <Shawn.Pouliotte@nominum.com>, <enum@ietf.org>
X-OriginalArrivalTime: 29 Jan 2007 20:06:25.0424 (UTC)
	FILETIME=[F4542900:01C743E0]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


I'll try to elaborate a bit on the scenario I had in mind. A caller =
wants to leave a voice message for the callee - they do not wish to =
communicate with the callee directly. An ENUM query for the callee's =
E.164 number returns a voicemail service that includes a SIP URI for =
their voicemail. This URI could be a single generic URI that corresponds =
to the voicemail system or it could include the Call Forwarding Number =
of the callee. The client can optionally specify the mailbox in SIP by =
using a URI parameter as defined in RFC4458 i.e. target=3Dmailbox. If no =
mailbox is specified, the voicemail system will prompt for a mailbox.

The existing SIP service could be used in conjunction with callerprefs =
instead of this mechanism although IMHO I think that getting every =
client and proxy to support callerprefs would be much more difficult.

If the voicemail system supports access via E-mail (VPIM, IVM etc), the =
client can easily use that via ENUM lookup. However, if the voicemail =
system only supports access via SIP, it is at somewhat of a loss.

James=20

-----Original Message-----
From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com]=20
Sent: Monday, January 29, 2007 11:55 AM
To: enum@ietf.org
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP =
URI

James,

Is there some functionality that you envision that cannot be achieved =
with
the current services? I tend to agree that the service set is getting a
little unruly and for the most part people are only using the basic ones
thus far.=20

Can you elaborate on your requirements?

Thanks
Shawn


On 1/29/07 5:52 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

> I think the use of new enumservices for stuff like this is getting
> entirely out of hand. The proposed solution would work for E.164
> numbers, but the same functionality is of equal relevance for regular
> SIP URIs.
>=20
> There is already a mechanism (callerprefs) for requesting (or =
refusing)
> the voicemail service associated with a sip AoR.
>=20
> Paul
>=20
> Jackson, James wrote:
>> I would like to submit a registration for a new enumservice =
=B3voicemail=B2
>> using a SIP URI. Voicemail platforms are often accessible via SIP and =
it
>> would be desirable for callers to have the option to go straight to
>> voicemail rather than participate in an interactive form of =
communication.
>>=20
>> =20
>>=20
>> Any feedback from the group would be much appreciated.
>>=20
>> =20
>>=20
>> Thanks,
>>=20
>> James
>>=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




_______________________________________________
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 Jan 29 15:42:20 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBdKN-0004MH-F5; Mon, 29 Jan 2007 15:42:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdKN-0004MC-3W
	for enum@ietf.org; Mon, 29 Jan 2007 15:42:11 -0500
Received: from alnrmhc15.comcast.net ([206.18.177.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdKL-0005K5-Sq
	for enum@ietf.org; Mon, 29 Jan 2007 15:42:11 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc15) with ESMTP
	id <20070129204209b1500kutufe>; Mon, 29 Jan 2007 20:42:09 +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 l0TKg898015274
	for <enum@ietf.org>; Mon, 29 Jan 2007 15:42:08 -0500
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0TKg8G6015270;
	Mon, 29 Jan 2007 15:42:08 -0500
Date: Mon, 29 Jan 2007 15:42:08 -0500
Message-Id: <200701292042.l0TKg8G6015270@dragon.ariadne.com>
To: enum@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
	(james_jackson@labs.att.com)
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
References: <45BDFC1A.6080108@cisco.com> <C1E374E3.5565%spouliotte@nominum.com>
	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

   From: "Jackson, James" <james_jackson@labs.att.com>

   The existing SIP service could be used in conjunction with
   callerprefs instead of this mechanism although IMHO I think that
   getting every client and proxy to support callerprefs would be much
   more difficult.

Though would it be more difficult than getting every callee to install
the right information into ENUM?

Dale

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



From enum-bounces@ietf.org Mon Jan 29 16:16:53 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBdqf-0001T6-3G; Mon, 29 Jan 2007 16:15:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBdqd-0001SE-PW; Mon, 29 Jan 2007 16:15:31 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HBdqb-0007Vi-7Z; Mon, 29 Jan 2007 16:15:31 -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
	l0TLFEeS020981; Mon, 29 Jan 2007 13:15:22 -0800
From: "Richard Shockey" <richard@shockey.us>
To: <enum@ietf.org>, <PEPPERMINT@ietf.org>, <speermint@ietf.org>
Date: Mon, 29 Jan 2007 16:15:00 -0500
Message-ID: <011001c743ea$8d53b4f0$67201f0a@cis.neustar.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0111_01C743C0.A47DACF0"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcdD5yT2a/a8URTkTpisJWeWrU35bwAA0uTQ
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: 287c806b254c6353fcb09ee0e53bbc5e
Cc: 
Subject: [Enum] FYI - -D
	ACTION:draft-newton-peppermint-problem-statement-00.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0111_01C743C0.A47DACF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Monday, January 29, 2007 3:50 PM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-newton-peppermint-problem-statement-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Provisioning Extensions in Peering Registries for
> Multimedia Interconnection (PEPPERMINT) Problem Statement
> 	Author(s)	: A. Newton
> 	Filename	: draft-newton-peppermint-problem-statement-00.txt
> 	Pages		: 13
> 	Date		: 2007-1-29
> 
>    This document contains descriptions of the problems faced by
>    operators and participants of multimedia interconnection (i.e.  SIP)
>    peering registries with respect to identity provisioning.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-newton-peppermint-problem-
> statement-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-newton-peppermint-problem-statement-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-newton-peppermint-problem-statement-
> 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_000_0111_01C743C0.A47DACF0
Content-Type: Message/External-body;
	name="ATT00146.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00146.dat"

Content-Type: text/plain
Content-ID: <2007-1-29110404.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-newton-peppermint-problem-statement-00.txt

------=_NextPart_000_0111_01C743C0.A47DACF0
Content-Type: Message/External-body;
	name="draft-newton-peppermint-problem-statement-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-newton-peppermint-problem-statement-00.txt"

Content-Type: text/plain
Content-ID: <2007-1-29110404.I-D@ietf.org>


------=_NextPart_000_0111_01C743C0.A47DACF0
Content-Type: text/plain;
	name="ATT00149.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00149.txt"

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_0111_01C743C0.A47DACF0
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_0111_01C743C0.A47DACF0--





From enum-bounces@ietf.org Mon Jan 29 16:18:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBdtm-0002QP-8m; Mon, 29 Jan 2007 16:18:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdtk-0002Pf-Ue
	for enum@ietf.org; Mon, 29 Jan 2007 16:18:44 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdth-0003NL-Vf
	for enum@ietf.org; Mon, 29 Jan 2007 16:18:44 -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 54F5E56823
	for <enum@ietf.org>; Mon, 29 Jan 2007 13:18:30 -0800 (PST)
	(envelope-from spouliotte@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: 0.177,BAYES_99: 3.67,USER_IN_WHITELIST: -30,
	CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -26.153
X-Spam-Level: 
Received: from [128.177.199.55] ([128.177.199.55])
	(authenticated user spouliotte@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits))
	for enum@ietf.org; Mon, 29 Jan 2007 13:18:27 -0800
User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Mon, 29 Jan 2007 13:16:50 -0800
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
From: Shawn Pouliotte <Shawn.Pouliotte@nominum.com>
To: <enum@ietf.org>
Message-ID: <C1E3A442.5588%spouliotte@nominum.com>
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP
 URI
Thread-Index: AcdDzo4dzHYw6K/BEduj5QAX8iZ51gADoOYgAANuKvk=
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hmmm,

Certainly makes logical sense to me - particularly in a private application=
.
4458 really talks about connecting and not how one gets the address in the
first place. It also presumes its a terminating service (which it typically
is) however having access via enum would allow it to be leveraged on
origination.=20

Shawn




On 1/29/07 12:06 PM, "Jackson, James" <james_jackson@labs.att.com> wrote:

>=20
> I'll try to elaborate a bit on the scenario I had in mind. A caller wants=
 to
> leave a voice message for the callee - they do not wish to communicate wi=
th
> the callee directly. An ENUM query for the callee's E.164 number returns =
a
> voicemail service that includes a SIP URI for their voicemail. This URI c=
ould
> be a single generic URI that corresponds to the voicemail system or it co=
uld
> include the Call Forwarding Number of the callee. The client can optional=
ly
> specify the mailbox in SIP by using a URI parameter as defined in RFC4458=
 i.e.
> target=3Dmailbox. If no mailbox is specified, the voicemail system will pro=
mpt
> for a mailbox.
>=20
> The existing SIP service could be used in conjunction with callerprefs in=
stead
> of this mechanism although IMHO I think that getting every client and pro=
xy to
> support callerprefs would be much more difficult.
>=20
> If the voicemail system supports access via E-mail (VPIM, IVM etc), the c=
lient
> can easily use that via ENUM lookup. However, if the voicemail system onl=
y
> supports access via SIP, it is at somewhat of a loss.
>=20
> James=20
>=20
> -----Original Message-----
> From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com]
> Sent: Monday, January 29, 2007 11:55 AM
> To: enum@ietf.org
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP U=
RI
>=20
> James,
>=20
> Is there some functionality that you envision that cannot be achieved wit=
h
> the current services? I tend to agree that the service set is getting a
> little unruly and for the most part people are only using the basic ones
> thus far.=20
>=20
> Can you elaborate on your requirements?
>=20
> Thanks
> Shawn
>=20
>=20
> On 1/29/07 5:52 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
>=20
>> I think the use of new enumservices for stuff like this is getting
>> entirely out of hand. The proposed solution would work for E.164
>> numbers, but the same functionality is of equal relevance for regular
>> SIP URIs.
>>=20
>> There is already a mechanism (callerprefs) for requesting (or refusing)
>> the voicemail service associated with a sip AoR.
>>=20
>> Paul
>>=20
>> Jackson, James wrote:
>>> I would like to submit a registration for a new enumservice =B3voicemail=B2
>>> using a SIP URI. Voicemail platforms are often accessible via SIP and i=
t
>>> would be desirable for callers to have the option to go straight to
>>> voicemail rather than participate in an interactive form of communicati=
on.
>>>=20
>>> =20
>>>=20
>>> Any feedback from the group would be much appreciated.
>>>=20
>>> =20
>>>=20
>>> Thanks,
>>>=20
>>> James
>>>=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
>=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




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



From enum-bounces@ietf.org Tue Jan 30 09:50:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBuHt-0000uz-Gz; Tue, 30 Jan 2007 09:48:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBuHs-0000uW-4a
	for enum@ietf.org; Tue, 30 Jan 2007 09:48:44 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBuHq-00016E-LV
	for enum@ietf.org; Tue, 30 Jan 2007 09:48:44 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 30 Jan 2007 09:48:42 -0500
X-IronPort-AV: i="4.13,257,1167627600"; 
	d="scan'208"; a="112750111:sNHT68447906"
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/8.12.11) with ESMTP id l0UEmgM8020829; 
	Tue, 30 Jan 2007 09:48:42 -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 l0UEmeVT026608; 
	Tue, 30 Jan 2007 09:48:42 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 09:48:39 -0500
Received: from [161.44.183.228] ([161.44.183.228]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 09:48:39 -0500
Message-ID: <45BF5AC6.7020803@cisco.com>
Date: Tue, 30 Jan 2007 09:48:38 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Jackson, James" <james_jackson@labs.att.com>
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
References: <45BDFC1A.6080108@cisco.com> <C1E374E3.5565%spouliotte@nominum.com>
	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 30 Jan 2007 14:48:39.0427 (UTC)
	FILETIME=[BA85A530:01C7447D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4753; t=1170168522;
	x=1171032522; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Enum]=20Proposal=20for=20new=20enumservice=20=22voic
	email=22,=20using=20SIP=20URI |Sender:=20
	|To:=20=22Jackson,=20James=22=20<james_jackson@labs.att.com>;
	bh=TqFvRUXIPAM879qtymS6OmTeYYfuTLFgcPNrKhnJmJY=;
	b=z7UMugZWO9wrMLXdCPMTgXUNgmVuBl24/EvGmBSi0C0D+GiKdVFMEolZaIuQi95BxGTvohli
	IQulbTG2Xl0VVkY6WWXeWVmA5sq0T4iS7Ka8oee3eRYgC+uOjoTrmEye;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



Jackson, James wrote:
> I'll try to elaborate a bit on the scenario I had in mind.
> A caller wants to leave a voice message for the callee -
> they do not wish to communicate with the callee directly.
> An ENUM query for the callee's E.164 number returns a
> voicemail service that includes a SIP URI for their voicemail.
> This URI could be a single generic URI that corresponds to
> the voicemail system or it could include the Call Forwarding
> Number of the callee. The client can optionally specify the
> mailbox in SIP by using a URI parameter as defined in RFC4458
> i.e. target=mailbox. If no mailbox is specified, the
> voicemail system will prompt for a mailbox.

The above assumes that the VM system is arranged in a suitable way. 
Notably that it has a unique and globally routable URI of its own for 
each mailbox (possibly by a common URI plus a parameter identifying the 
mailbox). Or at least that there is a single globally routable URI for 
the VM server and that the caller will be satisfied with having to enter 
the target phone number a second time.

It also of course assumes that the calling UA has some UI with its user 
to indicate a desire for reaching only VM, and that it will do the ENUM 
query and be familiar with the proposed new enum service.

And of course it also depends on user enum having  been deployed for the 
target number.

> The existing SIP service could be used in conjunction with
> callerprefs instead of this mechanism although IMHO I think
> that getting every client and proxy to support callerprefs
> would be much more difficult.

IMO it is easier to use callerprefs than this proposal. It still 
requires a UI to indicate a desire to do this - that is the same. Then 
it need only insert suitable callerpref headers into the request.

It does not require that the UAC do ENUM, though it is ok if it does. If 
ENUM is done at all, it can be done by a server along the way. And it 
needn't be user enum.

It does require that the home proxy of the target support callerprefs, 
and arrange things so that the VM server is managed in a way compatible 
with use of callerprefs in this way. AFAIK that is not typically the way 
it is today. But then of course this new enum service isn't deployed 
today as well, nor is user enum very widely deployed.

	Paul

> If the voicemail system supports access via E-mail (VPIM,
> IVM etc), the client can easily use that via ENUM lookup.
> However, if the voicemail system only supports access via
> SIP, it is at somewhat of a loss.
> 
> James 
> 
> -----Original Message-----
> From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com] 
> Sent: Monday, January 29, 2007 11:55 AM
> To: enum@ietf.org
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
> 
> James,
> 
> Is there some functionality that you envision that cannot be achieved with
> the current services? I tend to agree that the service set is getting a
> little unruly and for the most part people are only using the basic ones
> thus far. 
> 
> Can you elaborate on your requirements?
> 
> Thanks
> Shawn
> 
> 
> On 1/29/07 5:52 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
> 
>> I think the use of new enumservices for stuff like this is getting
>> entirely out of hand. The proposed solution would work for E.164
>> numbers, but the same functionality is of equal relevance for regular
>> SIP URIs.
>>
>> There is already a mechanism (callerprefs) for requesting (or refusing)
>> the voicemail service associated with a sip AoR.
>>
>> Paul
>>
>> Jackson, James wrote:
>>> I would like to submit a registration for a new enumservice ³voicemail²
>>> using a SIP URI. Voicemail platforms are often accessible via SIP and it
>>> would be desirable for callers to have the option to go straight to
>>> voicemail rather than participate in an interactive form of communication.
>>>
>>>  
>>>
>>> Any feedback from the group would be much appreciated.
>>>
>>>  
>>>
>>> Thanks,
>>>
>>> James
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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 Jan 30 10:49:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBvEB-0002To-7B; Tue, 30 Jan 2007 10:48:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvE9-0002TY-Ss
	for enum@ietf.org; Tue, 30 Jan 2007 10:48:57 -0500
Received: from ext-sendmail1.labs.att.com ([205.173.58.19]
	helo=sendmail1.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvE5-0002WC-Nl
	for enum@ietf.org; Tue, 30 Jan 2007 10:48:57 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail1.labs.att.com (8.13.7/8.13.1) with ESMTP id l0UFRtiE023359; 
	Tue, 30 Jan 2007 09:27:55 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0UFmphG019180;
	Tue, 30 Jan 2007 09:48:51 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 09:48:51 -0600
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] Proposal for new enumservice "voicemail", using SIP URI
Date: Tue, 30 Jan 2007 09:48:51 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF047BC33F@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <45BF5AC6.7020803@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdEfcBiRtSVfSHASS63ge8N2iTqFAABEhew
References: <45BDFC1A.6080108@cisco.com> <C1E374E3.5565%spouliotte@nominum.com>
	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
	<45BF5AC6.7020803@cisco.com>
From: "Jackson, James" <james_jackson@labs.att.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 30 Jan 2007 15:48:51.0785 (UTC)
	FILETIME=[23A7BB90:01C74486]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


In reality we would not have UAs doing ENUM queries or necessarily using =
a UI. Caller would simply dial something like *99 + number to reach =
callee's voicemail. ENUM query would be done by the network. If =
supported, the network would also be the one inserting the URI parameter =
to tell voicemail what the mailbox is. Also, this would most likely be =
deployed with some form of infra ENUM rather than user ENUM. Infra ENUM =
will already be populated to support VoIP peering so the terminating =
network need only provide an additional entry for voicemail rather than =
modify their infrastructure to support callerprefs. Perhaps this is too =
much of a niche application.

James=20

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Tuesday, January 30, 2007 8:49 AM
To: Jackson, James
Cc: Shawn Pouliotte; enum@ietf.org
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP =
URI



Jackson, James wrote:
> I'll try to elaborate a bit on the scenario I had in mind.
> A caller wants to leave a voice message for the callee -
> they do not wish to communicate with the callee directly.
> An ENUM query for the callee's E.164 number returns a
> voicemail service that includes a SIP URI for their voicemail.
> This URI could be a single generic URI that corresponds to
> the voicemail system or it could include the Call Forwarding
> Number of the callee. The client can optionally specify the
> mailbox in SIP by using a URI parameter as defined in RFC4458
> i.e. target=3Dmailbox. If no mailbox is specified, the
> voicemail system will prompt for a mailbox.

The above assumes that the VM system is arranged in a suitable way.=20
Notably that it has a unique and globally routable URI of its own for=20
each mailbox (possibly by a common URI plus a parameter identifying the=20
mailbox). Or at least that there is a single globally routable URI for=20
the VM server and that the caller will be satisfied with having to enter =

the target phone number a second time.

It also of course assumes that the calling UA has some UI with its user=20
to indicate a desire for reaching only VM, and that it will do the ENUM=20
query and be familiar with the proposed new enum service.

And of course it also depends on user enum having  been deployed for the =

target number.

> The existing SIP service could be used in conjunction with
> callerprefs instead of this mechanism although IMHO I think
> that getting every client and proxy to support callerprefs
> would be much more difficult.

IMO it is easier to use callerprefs than this proposal. It still=20
requires a UI to indicate a desire to do this - that is the same. Then=20
it need only insert suitable callerpref headers into the request.

It does not require that the UAC do ENUM, though it is ok if it does. If =

ENUM is done at all, it can be done by a server along the way. And it=20
needn't be user enum.

It does require that the home proxy of the target support callerprefs,=20
and arrange things so that the VM server is managed in a way compatible=20
with use of callerprefs in this way. AFAIK that is not typically the way =

it is today. But then of course this new enum service isn't deployed=20
today as well, nor is user enum very widely deployed.

	Paul

> If the voicemail system supports access via E-mail (VPIM,
> IVM etc), the client can easily use that via ENUM lookup.
> However, if the voicemail system only supports access via
> SIP, it is at somewhat of a loss.
>=20
> James=20
>=20
> -----Original Message-----
> From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com]=20
> Sent: Monday, January 29, 2007 11:55 AM
> To: enum@ietf.org
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using =
SIP URI
>=20
> James,
>=20
> Is there some functionality that you envision that cannot be achieved =
with
> the current services? I tend to agree that the service set is getting =
a
> little unruly and for the most part people are only using the basic =
ones
> thus far.=20
>=20
> Can you elaborate on your requirements?
>=20
> Thanks
> Shawn
>=20
>=20
> On 1/29/07 5:52 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
>=20
>> I think the use of new enumservices for stuff like this is getting
>> entirely out of hand. The proposed solution would work for E.164
>> numbers, but the same functionality is of equal relevance for regular
>> SIP URIs.
>>
>> There is already a mechanism (callerprefs) for requesting (or =
refusing)
>> the voicemail service associated with a sip AoR.
>>
>> Paul
>>
>> Jackson, James wrote:
>>> I would like to submit a registration for a new enumservice =
=B3voicemail=B2
>>> using a SIP URI. Voicemail platforms are often accessible via SIP =
and it
>>> would be desirable for callers to have the option to go straight to
>>> voicemail rather than participate in an interactive form of =
communication.
>>>
>>> =20
>>>
>>> Any feedback from the group would be much appreciated.
>>>
>>> =20
>>>
>>> Thanks,
>>>
>>> James
>>>
>>>
>>> =
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>=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
>=20

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



From enum-bounces@ietf.org Tue Jan 30 10:56:51 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBvLV-0008C5-7c; Tue, 30 Jan 2007 10:56:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvLT-0008Bz-GW
	for enum@ietf.org; Tue, 30 Jan 2007 10:56:31 -0500
Received: from wodka.aus-biz.com ([65.23.153.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvLP-0004VN-6p
	for enum@ietf.org; Tue, 30 Jan 2007 10:56:31 -0500
Received: from [192.168.1.103] (cpe-65-24-79-168.columbus.res.rr.com
	[65.24.79.168])
	(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 F343111A62E;
	Tue, 30 Jan 2007 10:56:23 -0500 (EST)
Message-ID: <45BF6AB1.1000802@e164.org>
Date: Tue, 30 Jan 2007 10:56:33 -0500
From: Duane <duane@e164.org>
User-Agent: Thunderbird 2.0b2 (X11/20070116)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
References: <45BDFC1A.6080108@cisco.com>
	<C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
	<45BF5AC6.7020803@cisco.com>
In-Reply-To: <45BF5AC6.7020803@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>, "Jackson,
	James" <james_jackson@labs.att.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Paul Kyzivat wrote:

> The above assumes that the VM system is arranged in a suitable way. 
> Notably that it has a unique and globally routable URI of its own for 
> each mailbox (possibly by a common URI plus a parameter identifying the 
> mailbox). Or at least that there is a single globally routable URI for 
> the VM server and that the caller will be satisfied with having to enter 
> the target phone number a second time.

While I won't go into the merits of having such an enum service, 
(although couldn't it just be a sub-type of pstn?) it seems pretty 
trivial to me to be just another SIP URI that could easily be setup, 
both in DNS and in most/all software driven PBXs.

eg

sip:123456@example.com
voicemail:vm-123456@example.com

On the PBX you simply look for vm- strip it and send the call into the 
voicemail system.

eg

100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .

-- 

Best regards,
  Duane

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



From enum-bounces@ietf.org Tue Jan 30 12:05:37 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBwQ0-0001KE-Fw; Tue, 30 Jan 2007 12:05:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwPz-0001Ie-0o
	for enum@ietf.org; Tue, 30 Jan 2007 12:05:15 -0500
Received: from ext-sendmail1.labs.att.com ([205.173.58.19]
	helo=sendmail1.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwPv-0001V3-Fv
	for enum@ietf.org; Tue, 30 Jan 2007 12:05:15 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail1.labs.att.com (8.13.7/8.13.1) with ESMTP id l0UGi700024880; 
	Tue, 30 Jan 2007 10:44:07 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0UH51O1030198;
	Tue, 30 Jan 2007 11:05:01 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 11:05:01 -0600
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] Proposal for new enumservice "voicemail", using SIP URI
Date: Tue, 30 Jan 2007 11:05:02 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <45BF6AB1.1000802@e164.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdEhzRHT4qMPqd1RZitBLLbFjEDrQAB9W0A
References: <45BDFC1A.6080108@cisco.com>
	<C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
	<45BF5AC6.7020803@cisco.com> <45BF6AB1.1000802@e164.org>
From: "Jackson, James" <james_jackson@labs.att.com>
To: "Duane" <duane@e164.org>, "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 30 Jan 2007 17:05:01.0680 (UTC)
	FILETIME=[C7865F00:01C74490]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


I have been thinking about the PSTN service in another context, but
perhaps it is more generally applicable here. Specifically, consider the
case where the called number is purely PSTN and you want to reach their
voicemail. In theory an ENUM query could return the Call Forwarding
Number and the call could be forwarded out a Media Gateway. The mailbox
would be indicated by the Redirecting Number.

James

-----Original Message-----
From: Duane [mailto:duane@e164.org]=20
Sent: Tuesday, January 30, 2007 9:57 AM
To: Paul Kyzivat
Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

Paul Kyzivat wrote:

> The above assumes that the VM system is arranged in a suitable way.=20
> Notably that it has a unique and globally routable URI of its own for=20
> each mailbox (possibly by a common URI plus a parameter identifying
the=20
> mailbox). Or at least that there is a single globally routable URI for

> the VM server and that the caller will be satisfied with having to
enter=20
> the target phone number a second time.

While I won't go into the merits of having such an enum service,=20
(although couldn't it just be a sub-type of pstn?) it seems pretty=20
trivial to me to be just another SIP URI that could easily be setup,=20
both in DNS and in most/all software driven PBXs.

eg

sip:123456@example.com
voicemail:vm-123456@example.com

On the PBX you simply look for vm- strip it and send the call into the=20
voicemail system.

eg

100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .

--=20

Best regards,
  Duane

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



From enum-bounces@ietf.org Tue Jan 30 12:48:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBx41-0006YK-L0; Tue, 30 Jan 2007 12:46:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx41-0006YF-5P
	for enum@ietf.org; Tue, 30 Jan 2007 12:46:37 -0500
Received: from sirius.wcom.co.uk ([193.131.254.154]
	helo=sirius.emea.verizonbusiness.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBx3z-0005rf-FV
	for enum@ietf.org; Tue, 30 Jan 2007 12:46:37 -0500
Received: from sirius.wcom.co.uk ([166.59.190.29] helo=sirius.emea.mci.com)
	by sirius.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1HBx3q-0001Kj-Bi; Tue, 30 Jan 2007 17:46:28 +0000
Received: from ocampa.emea.verizonbusiness.com (leste.wcom.co.uk
	[166.59.190.250]) by sirius.emea.mci.com (4.7.0.120) with ESMTP id ;
	Tue, 30 Jan 2007 17:45:57 GMT
Received: from ms-lon-exgw02.uk.mcilink.com ([166.59.191.19]
	helo=ms-lon-exgw02.emea.dsmain.com)
	by ocampa.emea.verizonbusiness.com with esmtp (Exim 4.42)
	id 1HBx3N-0005ck-2Z; Tue, 30 Jan 2007 17:45:57 +0000
Received: by ms-lon-exgw02.uk.mcilink.com with Internet Mail Service
	(5.5.2658.27) id <C2R36907>; Tue, 30 Jan 2007 17:45:51 -0000
Message-ID: <CA3896DB5903C14EAAC9D8E91D1167CBCC7879@ms-lon-exmb06.uk.mcilink.com>
From: "Lupton, Ronan" <ronan.lupton@ie.verizonbusiness.com>
To: "'Jackson, James'" <james_jackson@labs.att.com>, Duane <duane@e164.org>,
	Paul Kyzivat <pkyzivat@cisco.com>
Subject: RE: [Enum] Proposal for new enumservice "voicemail", using SIP UR
	I
Date: Tue, 30 Jan 2007 17:45:49 -0000
X-Mailer: Internet Mail Service (5.5.2658.27)
MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40)
X-VZ-EMEA-Spam-Score: -499.5
	(---------------------------------------------------)
X-VZ-EMEA-Signature: 25f382197cd4f61845ec6b35251e0846
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0543864131=="
Errors-To: enum-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0543864131==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C74495.BAB373AF"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C74495.BAB373AF
Content-Type: text/plain


How about we just leave voicemail to the User?

>From a policy point of voice I think its better and also if SPIT and online
telemarketing takes off we may avoid nasty surpriese in our voicemail boxes.

Would a DNS entry for online VM have repercussions for 'do not call' and
'telemarketing regulations'?

Couple of comments [I have already made to James]:

1. Voicemail being the logical 'treatment' for calls that go unanswered
might already exist at the choice of the called party? i.e., User Busy, no
user responding, no answer from the user.
[JJ] I'm focusing on the scenario where the caller is specifically trying to
get to callee's voicemail.
2. A separate URI for Voicemail open up access for SPIT in the medium term?
[JJ] That's true, but also applicable to the VPIM enumservice or using
callerprefs. 
3. In stating point 2. most voicemail on fixed networks is a User controlled
whilst on mobile networks is facilitated by an extra digit being inserted
for remote access, which to some extent is also User controlled should the
User opt to turn on Voicemail.


Though I can see why it would be useful as a stand alone. I thought someone
had done this already but have forgotten what the detail or debate was.


Ronan 

-----Original Message-----
From: Jackson, James [mailto:james_jackson@labs.att.com] 
Sent: 30 January 2007 17:05
To: Duane; Paul Kyzivat
Cc: enum@ietf.org; Shawn Pouliotte
Subject: RE: [Enum] Proposal for new enumservice "voicemail", using SIP URI


I have been thinking about the PSTN service in another context, but perhaps
it is more generally applicable here. Specifically, consider the case where
the called number is purely PSTN and you want to reach their voicemail. In
theory an ENUM query could return the Call Forwarding Number and the call
could be forwarded out a Media Gateway. The mailbox would be indicated by
the Redirecting Number.

James

-----Original Message-----
From: Duane [mailto:duane@e164.org]
Sent: Tuesday, January 30, 2007 9:57 AM
To: Paul Kyzivat
Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI

Paul Kyzivat wrote:

> The above assumes that the VM system is arranged in a suitable way. 
> Notably that it has a unique and globally routable URI of its own for 
> each mailbox (possibly by a common URI plus a parameter identifying
the 
> mailbox). Or at least that there is a single globally routable URI for

> the VM server and that the caller will be satisfied with having to
enter 
> the target phone number a second time.

While I won't go into the merits of having such an enum service, (although
couldn't it just be a sub-type of pstn?) it seems pretty trivial to me to be
just another SIP URI that could easily be setup, both in DNS and in most/all
software driven PBXs.

eg

sip:123456@example.com
voicemail:vm-123456@example.com

On the PBX you simply look for vm- strip it and send the call into the 
voicemail system.

eg

100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .

-- 

Best regards,
  Duane

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

------_=_NextPart_001_01C74495.BAB373AF
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: [Enum] Proposal for new enumservice &quot;voicemail&quot;, =
using SIP URI</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>How about we just leave voicemail to the User?</FONT>
</P>

<P><FONT SIZE=3D2>From a policy point of voice I think its better and =
also if SPIT and online telemarketing takes off we may avoid nasty =
surpriese in our voicemail boxes.</FONT></P>

<P><FONT SIZE=3D2>Would a DNS entry for online VM have repercussions =
for 'do not call' and 'telemarketing regulations'?</FONT>
</P>

<P><FONT SIZE=3D2>Couple of comments [I have already made to =
James]:</FONT>
</P>

<P><FONT SIZE=3D2>1. Voicemail being the logical 'treatment' for calls =
that go unanswered might already exist at the choice of the called =
party? i.e., User Busy, no user responding, no answer from the =
user.</FONT></P>

<P><FONT SIZE=3D2>[JJ] I'm focusing on the scenario where the caller is =
specifically trying to get to callee's voicemail.</FONT>
<BR><FONT SIZE=3D2>2. A separate URI for Voicemail open up access for =
SPIT in the medium term?</FONT>
<BR><FONT SIZE=3D2>[JJ] That's true, but also applicable to the VPIM =
enumservice or using callerprefs. </FONT>
<BR><FONT SIZE=3D2>3. In stating point 2. most voicemail on fixed =
networks is a User controlled whilst on mobile networks is facilitated =
by an extra digit being inserted for remote access, which to some =
extent is also User controlled should the User opt to turn on =
Voicemail.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Though I can see why it would be useful as a stand =
alone. I thought someone had done this already but have forgotten what =
the detail or debate was.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Ronan </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jackson, James [<A =
HREF=3D"mailto:james_jackson@labs.att.com">mailto:james_jackson@labs.att=
.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: 30 January 2007 17:05</FONT>
<BR><FONT SIZE=3D2>To: Duane; Paul Kyzivat</FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; Shawn Pouliotte</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Enum] Proposal for new enumservice =
&quot;voicemail&quot;, using SIP URI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I have been thinking about the PSTN service in =
another context, but perhaps it is more generally applicable here. =
Specifically, consider the case where the called number is purely PSTN =
and you want to reach their voicemail. In theory an ENUM query could =
return the Call Forwarding Number and the call could be forwarded out a =
Media Gateway. The mailbox would be indicated by the Redirecting =
Number.</FONT></P>

<P><FONT SIZE=3D2>James</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Duane [<A =
HREF=3D"mailto:duane@e164.org">mailto:duane@e164.org</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 30, 2007 9:57 AM</FONT>
<BR><FONT SIZE=3D2>To: Paul Kyzivat</FONT>
<BR><FONT SIZE=3D2>Cc: Jackson, James; enum@ietf.org; Shawn =
Pouliotte</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] Proposal for new enumservice =
&quot;voicemail&quot;, using SIP URI</FONT>
</P>

<P><FONT SIZE=3D2>Paul Kyzivat wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The above assumes that the VM system is arranged =
in a suitable way. </FONT>
<BR><FONT SIZE=3D2>&gt; Notably that it has a unique and globally =
routable URI of its own for </FONT>
<BR><FONT SIZE=3D2>&gt; each mailbox (possibly by a common URI plus a =
parameter identifying</FONT>
<BR><FONT SIZE=3D2>the </FONT>
<BR><FONT SIZE=3D2>&gt; mailbox). Or at least that there is a single =
globally routable URI for</FONT>
</P>

<P><FONT SIZE=3D2>&gt; the VM server and that the caller will be =
satisfied with having to</FONT>
<BR><FONT SIZE=3D2>enter </FONT>
<BR><FONT SIZE=3D2>&gt; the target phone number a second time.</FONT>
</P>

<P><FONT SIZE=3D2>While I won't go into the merits of having such an =
enum service, (although couldn't it just be a sub-type of pstn?) it =
seems pretty trivial to me to be just another SIP URI that could easily =
be setup, both in DNS and in most/all software driven PBXs.</FONT></P>

<P><FONT SIZE=3D2>eg</FONT>
</P>

<P><FONT SIZE=3D2>sip:123456@example.com</FONT>
<BR><FONT SIZE=3D2>voicemail:vm-123456@example.com</FONT>
</P>

<P><FONT SIZE=3D2>On the PBX you simply look for vm- strip it and send =
the call into the </FONT>
<BR><FONT SIZE=3D2>voicemail system.</FONT>
</P>

<P><FONT SIZE=3D2>eg</FONT>
</P>

<P><FONT SIZE=3D2>100 10 &quot;u&quot; &quot;E2U+PSTN&quot; =
&quot;!^(.*)$!sip:\\1@example.com!&quot; .</FONT>
<BR><FONT SIZE=3D2>100 10 &quot;u&quot; &quot;E2U+PSTN&quot; =
&quot;!^(.*)$!voicemail:vm-\\1@example.com!&quot; .</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
</P>

<P><FONT SIZE=3D2>Best regards,</FONT>
<BR><FONT SIZE=3D2>&nbsp; Duane</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>enum mailing list</FONT>
<BR><FONT SIZE=3D2>enum@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C74495.BAB373AF--


--===============0543864131==
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

--===============0543864131==--




From enum-bounces@ietf.org Tue Jan 30 14:35:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HByjm-0000Q9-Vm; Tue, 30 Jan 2007 14:33:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HByjk-0000NC-8D
	for enum@ietf.org; Tue, 30 Jan 2007 14:33:48 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HByji-0003KF-SJ
	for enum@ietf.org; Tue, 30 Jan 2007 14:33:48 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-4.cisco.com with ESMTP; 30 Jan 2007 11:33:46 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0UJXkrB031596; 
	Tue, 30 Jan 2007 11:33:46 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0UJXbnL002334;
	Tue, 30 Jan 2007 11:33:41 -0800 (PST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 14:33:37 -0500
Received: from [161.44.183.228] ([161.44.183.228]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 14:33:36 -0500
Message-ID: <45BF9D90.3050008@cisco.com>
Date: Tue, 30 Jan 2007 14:33:36 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Jackson, James" <james_jackson@labs.att.com>
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI
References: <45BDFC1A.6080108@cisco.com>
	<C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
	<45BF5AC6.7020803@cisco.com> <45BF6AB1.1000802@e164.org>
	<0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jan 2007 19:33:36.0819 (UTC)
	FILETIME=[895CA030:01C744A5]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2918; t=1170185626;
	x=1171049626; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Enum]=20Proposal=20for=20new=20enumservice=20=22voic
	email=22,=20using=20SIP=20URI |Sender:=20;
	bh=B0U21J9Emc277Ti6ST/VZnKwtZwEIvfKGFLn7jGH6vE=;
	b=IK0FANOnhfRtjiXRBcYnB5DOCNZNmcfu7HJwECbKOlt509caKbb+K4GzqoswYEeS917dMS3Y
	23zDeCIKyF42RW/8sSie8rkBRIijP13RjOT9LzG3jnw3Xf001cKnlaxE;
Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>,
	Duane <duane@e164.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

A fundamental problem I have with using ENUM is that it is fundamentally 
tied to cases where the address of the callee is an E.164 number. That 
is fine in cases where the problem is intrinsically tied to the use of a 
phone number. But it is an unappealing solution to any problem that also 
applies when the callee is identified by a SIP URI. I certainly see that 
to be the case here. I just as well may want to get to the VM for 
sip:alice@atlanta.com as for tel:+12125551234.

BTW, that also means that indicating you want VM by prefixing the 
address with *99 isn't an ideal interface. I guess it is *an* interface, 
that might be suitable for UAs that can only deal with numbers. But 
another interface will be needed for alphanumeric calling. I don't think 
the concept of adding to the callee's URI is appropriate in this case. 
Whatever technique does work for alphanumeric URIs would hopefully work 
for phone numbers as well. In general a sip UA supports a telephone 
dialing interface already needs to recognize and locally process some 
star codes, so it ought to be able to do so for this one too.

	Paul

Jackson, James wrote:
> I have been thinking about the PSTN service in another context, but
> perhaps it is more generally applicable here. Specifically, consider the
> case where the called number is purely PSTN and you want to reach their
> voicemail. In theory an ENUM query could return the Call Forwarding
> Number and the call could be forwarded out a Media Gateway. The mailbox
> would be indicated by the Redirecting Number.
> 
> James
> 
> -----Original Message-----
> From: Duane [mailto:duane@e164.org] 
> Sent: Tuesday, January 30, 2007 9:57 AM
> To: Paul Kyzivat
> Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
> URI
> 
> Paul Kyzivat wrote:
> 
>> The above assumes that the VM system is arranged in a suitable way. 
>> Notably that it has a unique and globally routable URI of its own for 
>> each mailbox (possibly by a common URI plus a parameter identifying
> the 
>> mailbox). Or at least that there is a single globally routable URI for
> 
>> the VM server and that the caller will be satisfied with having to
> enter 
>> the target phone number a second time.
> 
> While I won't go into the merits of having such an enum service, 
> (although couldn't it just be a sub-type of pstn?) it seems pretty 
> trivial to me to be just another SIP URI that could easily be setup, 
> both in DNS and in most/all software driven PBXs.
> 
> eg
> 
> sip:123456@example.com
> voicemail:vm-123456@example.com
> 
> On the PBX you simply look for vm- strip it and send the call into the 
> voicemail system.
> 
> eg
> 
> 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
> 

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



From enum-bounces@ietf.org Tue Jan 30 14:50:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HByzK-0007lF-8N; Tue, 30 Jan 2007 14:49:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HByzJ-0007jp-1j
	for enum@ietf.org; Tue, 30 Jan 2007 14:49:53 -0500
Received: from ext-sendmail1.labs.att.com ([205.173.58.19]
	helo=sendmail1.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HByzF-0006bf-Ix
	for enum@ietf.org; Tue, 30 Jan 2007 14:49:53 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail1.labs.att.com (8.13.7/8.13.1) with ESMTP id l0UJSTvA027436; 
	Tue, 30 Jan 2007 13:28:29 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0UJnP6c018525;
	Tue, 30 Jan 2007 13:49:25 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 13:49:25 -0600
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] Proposal for new enumservice "voicemail", using SIP URI
Date: Tue, 30 Jan 2007 13:49:26 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF047BC775@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <45BF9D90.3050008@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdEpZBNviY6NEgjQzymiv4mlJilLAAAMgCQ
References: <45BDFC1A.6080108@cisco.com>
	<C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
	<45BF5AC6.7020803@cisco.com> <45BF6AB1.1000802@e164.org>
	<0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
	<45BF9D90.3050008@cisco.com>
From: "Jackson, James" <james_jackson@labs.att.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 30 Jan 2007 19:49:25.0367 (UTC)
	FILETIME=[BEBD9070:01C744A7]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>,
	Duane <duane@e164.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


I agree that callerprefs is a potential solution for the SIP URI case. I
don't see how it would address the Tel URI case though, or to be more
specific the case where the voicemail system is in the PSTN.

James

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Tuesday, January 30, 2007 1:34 PM
To: Jackson, James
Cc: Duane; enum@ietf.org; Shawn Pouliotte
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

A fundamental problem I have with using ENUM is that it is fundamentally

tied to cases where the address of the callee is an E.164 number. That=20
is fine in cases where the problem is intrinsically tied to the use of a

phone number. But it is an unappealing solution to any problem that also

applies when the callee is identified by a SIP URI. I certainly see that

to be the case here. I just as well may want to get to the VM for=20
sip:alice@atlanta.com as for tel:+12125551234.

BTW, that also means that indicating you want VM by prefixing the=20
address with *99 isn't an ideal interface. I guess it is *an* interface,

that might be suitable for UAs that can only deal with numbers. But=20
another interface will be needed for alphanumeric calling. I don't think

the concept of adding to the callee's URI is appropriate in this case.=20
Whatever technique does work for alphanumeric URIs would hopefully work=20
for phone numbers as well. In general a sip UA supports a telephone=20
dialing interface already needs to recognize and locally process some=20
star codes, so it ought to be able to do so for this one too.

	Paul

Jackson, James wrote:
> I have been thinking about the PSTN service in another context, but
> perhaps it is more generally applicable here. Specifically, consider
the
> case where the called number is purely PSTN and you want to reach
their
> voicemail. In theory an ENUM query could return the Call Forwarding
> Number and the call could be forwarded out a Media Gateway. The
mailbox
> would be indicated by the Redirecting Number.
>=20
> James
>=20
> -----Original Message-----
> From: Duane [mailto:duane@e164.org]=20
> Sent: Tuesday, January 30, 2007 9:57 AM
> To: Paul Kyzivat
> Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
SIP
> URI
>=20
> Paul Kyzivat wrote:
>=20
>> The above assumes that the VM system is arranged in a suitable way.=20
>> Notably that it has a unique and globally routable URI of its own for

>> each mailbox (possibly by a common URI plus a parameter identifying
> the=20
>> mailbox). Or at least that there is a single globally routable URI
for
>=20
>> the VM server and that the caller will be satisfied with having to
> enter=20
>> the target phone number a second time.
>=20
> While I won't go into the merits of having such an enum service,=20
> (although couldn't it just be a sub-type of pstn?) it seems pretty=20
> trivial to me to be just another SIP URI that could easily be setup,=20
> both in DNS and in most/all software driven PBXs.
>=20
> eg
>=20
> sip:123456@example.com
> voicemail:vm-123456@example.com
>=20
> On the PBX you simply look for vm- strip it and send the call into the

> voicemail system.
>=20
> eg
>=20
> 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
>=20

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



From enum-bounces@ietf.org Tue Jan 30 15:03:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBzBQ-0005Re-6u; Tue, 30 Jan 2007 15:02:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzBO-0005RX-LZ
	for enum@ietf.org; Tue, 30 Jan 2007 15:02:22 -0500
Received: from ext-sendmail2.labs.att.com ([205.173.58.20]
	helo=sendmail2.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBzBM-00086T-9T
	for enum@ietf.org; Tue, 30 Jan 2007 15:02:22 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail2.labs.att.com (8.13.7/8.13.1) with ESMTP id l0UK26PX025041; 
	Tue, 30 Jan 2007 14:02:06 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0UK0CF3014889;
	Tue, 30 Jan 2007 14:00:13 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 14:02:04 -0600
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] Proposal for new enumservice "voicemail", using SIP URI
Date: Tue, 30 Jan 2007 14:02:05 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF047BC7BF@TSMAIL2.ad.tri.sbc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdEpZBNviY6NEgjQzymiv4mlJilLAAAMgCQAACyEEA=
References: <45BDFC1A.6080108@cisco.com>
	<C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com>
	<45BF5AC6.7020803@cisco.com> <45BF6AB1.1000802@e164.org>
	<0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
	<45BF9D90.3050008@cisco.com> 
From: "Jackson, James" <james_jackson@labs.att.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 30 Jan 2007 20:02:04.0440 (UTC)
	FILETIME=[832EE980:01C744A9]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>,
	Duane <duane@e164.org>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org




Let's say this was modeled after the enumservice voice... in this case
we would have enumservice voicemail using a Tel URI.

James

-----Original Message-----
From: Jackson, James=20
Sent: Tuesday, January 30, 2007 1:49 PM
To: 'Paul Kyzivat'
Cc: Duane; enum@ietf.org; Shawn Pouliotte
Subject: RE: [Enum] Proposal for new enumservice "voicemail", using SIP
URI


I agree that callerprefs is a potential solution for the SIP URI case. I
don't see how it would address the Tel URI case though, or to be more
specific the case where the voicemail system is in the PSTN.

James

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Tuesday, January 30, 2007 1:34 PM
To: Jackson, James
Cc: Duane; enum@ietf.org; Shawn Pouliotte
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

A fundamental problem I have with using ENUM is that it is fundamentally

tied to cases where the address of the callee is an E.164 number. That=20
is fine in cases where the problem is intrinsically tied to the use of a

phone number. But it is an unappealing solution to any problem that also

applies when the callee is identified by a SIP URI. I certainly see that

to be the case here. I just as well may want to get to the VM for=20
sip:alice@atlanta.com as for tel:+12125551234.

BTW, that also means that indicating you want VM by prefixing the=20
address with *99 isn't an ideal interface. I guess it is *an* interface,

that might be suitable for UAs that can only deal with numbers. But=20
another interface will be needed for alphanumeric calling. I don't think

the concept of adding to the callee's URI is appropriate in this case.=20
Whatever technique does work for alphanumeric URIs would hopefully work=20
for phone numbers as well. In general a sip UA supports a telephone=20
dialing interface already needs to recognize and locally process some=20
star codes, so it ought to be able to do so for this one too.

	Paul

Jackson, James wrote:
> I have been thinking about the PSTN service in another context, but
> perhaps it is more generally applicable here. Specifically, consider
the
> case where the called number is purely PSTN and you want to reach
their
> voicemail. In theory an ENUM query could return the Call Forwarding
> Number and the call could be forwarded out a Media Gateway. The
mailbox
> would be indicated by the Redirecting Number.
>=20
> James
>=20
> -----Original Message-----
> From: Duane [mailto:duane@e164.org]=20
> Sent: Tuesday, January 30, 2007 9:57 AM
> To: Paul Kyzivat
> Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
SIP
> URI
>=20
> Paul Kyzivat wrote:
>=20
>> The above assumes that the VM system is arranged in a suitable way.=20
>> Notably that it has a unique and globally routable URI of its own for

>> each mailbox (possibly by a common URI plus a parameter identifying
> the=20
>> mailbox). Or at least that there is a single globally routable URI
for
>=20
>> the VM server and that the caller will be satisfied with having to
> enter=20
>> the target phone number a second time.
>=20
> While I won't go into the merits of having such an enum service,=20
> (although couldn't it just be a sub-type of pstn?) it seems pretty=20
> trivial to me to be just another SIP URI that could easily be setup,=20
> both in DNS and in most/all software driven PBXs.
>=20
> eg
>=20
> sip:123456@example.com
> voicemail:vm-123456@example.com
>=20
> On the PBX you simply look for vm- strip it and send the call into the

> voicemail system.
>=20
> eg
>=20
> 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
>=20

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



From enum-bounces@ietf.org Tue Jan 30 16:06:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HC09t-00041G-DV; Tue, 30 Jan 2007 16:04:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HC09r-0003zV-V0
	for enum@ietf.org; Tue, 30 Jan 2007 16:04:51 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HC09i-0001U8-JX
	for enum@ietf.org; Tue, 30 Jan 2007 16:04: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] Proposal for new enumservice "voicemail", using SIP URI
Date: Tue, 30 Jan 2007 22:03:11 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com>
	<45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
	<45BF9D90.3050008@cisco.com>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

I fully support this argument
Richard

________________________________

Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Gesendet: Di 30.01.2007 20:33
An: Jackson, James
Cc: enum@ietf.org; Shawn Pouliotte; Duane
Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using SIP =
URI



A fundamental problem I have with using ENUM is that it is fundamentally
tied to cases where the address of the callee is an E.164 number. That
is fine in cases where the problem is intrinsically tied to the use of a
phone number. But it is an unappealing solution to any problem that also
applies when the callee is identified by a SIP URI. I certainly see that
to be the case here. I just as well may want to get to the VM for
sip:alice@atlanta.com as for tel:+12125551234.

BTW, that also means that indicating you want VM by prefixing the
address with *99 isn't an ideal interface. I guess it is *an* interface,
that might be suitable for UAs that can only deal with numbers. But
another interface will be needed for alphanumeric calling. I don't think
the concept of adding to the callee's URI is appropriate in this case.
Whatever technique does work for alphanumeric URIs would hopefully work
for phone numbers as well. In general a sip UA supports a telephone
dialing interface already needs to recognize and locally process some
star codes, so it ought to be able to do so for this one too.

        Paul

Jackson, James wrote:
> I have been thinking about the PSTN service in another context, but
> perhaps it is more generally applicable here. Specifically, consider =
the
> case where the called number is purely PSTN and you want to reach =
their
> voicemail. In theory an ENUM query could return the Call Forwarding
> Number and the call could be forwarded out a Media Gateway. The =
mailbox
> would be indicated by the Redirecting Number.
>
> James
>
> -----Original Message-----
> From: Duane [mailto:duane@e164.org]
> Sent: Tuesday, January 30, 2007 9:57 AM
> To: Paul Kyzivat
> Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using =
SIP
> URI
>
> Paul Kyzivat wrote:
>
>> The above assumes that the VM system is arranged in a suitable way.
>> Notably that it has a unique and globally routable URI of its own for
>> each mailbox (possibly by a common URI plus a parameter identifying
> the
>> mailbox). Or at least that there is a single globally routable URI =
for
>
>> the VM server and that the caller will be satisfied with having to
> enter
>> the target phone number a second time.
>
> While I won't go into the merits of having such an enum service,
> (although couldn't it just be a sub-type of pstn?) it seems pretty
> trivial to me to be just another SIP URI that could easily be setup,
> both in DNS and in most/all software driven PBXs.
>
> eg
>
> sip:123456@example.com
> voicemail:vm-123456@example.com
>
> On the PBX you simply look for vm- strip it and send the call into the
> voicemail system.
>
> eg
>
> 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
>

_______________________________________________
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 Jan 30 17:39:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HC1cI-0000Q0-HD; Tue, 30 Jan 2007 17:38:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1cH-0000Mr-QT
	for enum@ietf.org; Tue, 30 Jan 2007 17:38:17 -0500
Received: from ext-sendmail1.labs.att.com ([205.173.58.19]
	helo=sendmail1.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC1cC-000188-QD
	for enum@ietf.org; Tue, 30 Jan 2007 17:38:17 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail1.labs.att.com (8.13.7/8.13.1) with ESMTP id l0UMHBVT029959; 
	Tue, 30 Jan 2007 16:17:11 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0UMaB33002017;
	Tue, 30 Jan 2007 16:36:16 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 16:38:03 -0600
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] Proposal for new enumservice "voicemail", using SIP URI
Date: Tue, 30 Jan 2007 16:38:02 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF047BCAFF@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAHfe8A=
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com>
	<32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
From: "Jackson, James" <james_jackson@labs.att.com>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 30 Jan 2007 22:38:03.0318 (UTC)
	FILETIME=[4D825D60:01C744BF]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


I'm not sure I follow. It sounds to me that we're saying that
callerprefs is the correct way to do this for a SIP URI and since we
want the same logic to apply to SIP URI and Tel URI, then we shouldn't
use ENUM to do this for Tel URI either ? So there is no benefit in using
ENUM if it only enables calls to terminate to voicemail systems that
reside in the PSTN ?
=20
James

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20
Sent: Tuesday, January 30, 2007 3:03 PM
To: Paul Kyzivat
Cc: enum@ietf.org
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

I fully support this argument
Richard

________________________________

Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Gesendet: Di 30.01.2007 20:33
An: Jackson, James
Cc: enum@ietf.org; Shawn Pouliotte; Duane
Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI



A fundamental problem I have with using ENUM is that it is fundamentally
tied to cases where the address of the callee is an E.164 number. That
is fine in cases where the problem is intrinsically tied to the use of a
phone number. But it is an unappealing solution to any problem that also
applies when the callee is identified by a SIP URI. I certainly see that
to be the case here. I just as well may want to get to the VM for
sip:alice@atlanta.com as for tel:+12125551234.

BTW, that also means that indicating you want VM by prefixing the
address with *99 isn't an ideal interface. I guess it is *an* interface,
that might be suitable for UAs that can only deal with numbers. But
another interface will be needed for alphanumeric calling. I don't think
the concept of adding to the callee's URI is appropriate in this case.
Whatever technique does work for alphanumeric URIs would hopefully work
for phone numbers as well. In general a sip UA supports a telephone
dialing interface already needs to recognize and locally process some
star codes, so it ought to be able to do so for this one too.

        Paul

Jackson, James wrote:
> I have been thinking about the PSTN service in another context, but
> perhaps it is more generally applicable here. Specifically, consider
the
> case where the called number is purely PSTN and you want to reach
their
> voicemail. In theory an ENUM query could return the Call Forwarding
> Number and the call could be forwarded out a Media Gateway. The
mailbox
> would be indicated by the Redirecting Number.
>
> James
>
> -----Original Message-----
> From: Duane [mailto:duane@e164.org]
> Sent: Tuesday, January 30, 2007 9:57 AM
> To: Paul Kyzivat
> Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
SIP
> URI
>
> Paul Kyzivat wrote:
>
>> The above assumes that the VM system is arranged in a suitable way.
>> Notably that it has a unique and globally routable URI of its own for
>> each mailbox (possibly by a common URI plus a parameter identifying
> the
>> mailbox). Or at least that there is a single globally routable URI
for
>
>> the VM server and that the caller will be satisfied with having to
> enter
>> the target phone number a second time.
>
> While I won't go into the merits of having such an enum service,
> (although couldn't it just be a sub-type of pstn?) it seems pretty
> trivial to me to be just another SIP URI that could easily be setup,
> both in DNS and in most/all software driven PBXs.
>
> eg
>
> sip:123456@example.com
> voicemail:vm-123456@example.com
>
> On the PBX you simply look for vm- strip it and send the call into the
> voicemail system.
>
> eg
>
> 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
>

_______________________________________________
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 Jan 30 18:30:17 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HC2Px-0006ce-Vz; Tue, 30 Jan 2007 18:29:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Pw-0006cY-Mh
	for enum@ietf.org; Tue, 30 Jan 2007 18:29:36 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2Pu-0005Ir-CA
	for enum@ietf.org; Tue, 30 Jan 2007 18:29:36 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 30 Jan 2007 18:29:34 -0500
X-IronPort-AV: i="4.13,259,1167627600"; 
	d="scan'208"; a="112791450:sNHT50908872"
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/8.12.11) with ESMTP id l0UNTYYl000826; 
	Tue, 30 Jan 2007 18:29:34 -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 l0UNTXVT021966; 
	Tue, 30 Jan 2007 18:29:33 -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); 
	Tue, 30 Jan 2007 18:29:33 -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] Proposal for new enumservice "voicemail", using SIP URI
Date: Tue, 30 Jan 2007 18:29:31 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3028A2D85@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Proposal for new enumservice "voicemail", using SIP URI
Thread-Index: AcdEhzRHT4qMPqd1RZitBLLbFjEDrQAB9W0AAA3Vq8A=
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com>
	<45BF6AB1.1000802@e164.org>
	<0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com>
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Jackson, James" <james_jackson@labs.att.com>, "Duane" <duane@e164.org>,
	"Paul Kyzivat \(pkyzivat\)" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 30 Jan 2007 23:29:33.0597 (UTC)
	FILETIME=[7F7584D0:01C744C6]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2452; t=1170199774;
	x=1171063774; c=relaxed/simple; s=rtpdkim2001;
	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<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Enum]=20Proposal=20for=20new=20enumservice=20=22voic
	email=22,=20using=20SIP=20URI |Sender:=20
	|To:=20=22Jackson, =20James=22=20<james_jackson@labs.att.com>,
	=20=22Duane= 22=20<duane@e164.org>,
	=0A=20=20=20=20=20=20=20=20=22Paul=20Kyzivat=20\(pky
	zivat\)=22=20<pkyzivat@cisco.com>;
	bh=R/eJRwBiKh6wVE+iq1dStYGMNH0TRa7ZYpMCr4c1i2Y=;
	b=Lr/LCCAfybtZNwBgv4Ctn+tOJpKHk0gMNDc4Vpbeqnc8y/6wC6Of9T383pgvkZZZmwxZXv58
	QJYO41Afo2mmWrxCD5/HvKm6yh2P0ldAHnuiVIlDMxHs0Hg3CXFZq+HW;
Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: enum@ietf.org, Shawn Pouliotte <Shawn.Pouliotte@nominum.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

James,

Do you want to turn the DNS into a softswitch?

This seems a slippery slope.

Mike
=20

> -----Original Message-----
> From: Jackson, James [mailto:james_jackson@labs.att.com]=20
> Sent: Tuesday, January 30, 2007 12:05 PM
> To: Duane; Paul Kyzivat (pkyzivat)
> Cc: enum@ietf.org; Shawn Pouliotte
> Subject: RE: [Enum] Proposal for new enumservice "voicemail",=20
> using SIP URI
>=20
>=20
> I have been thinking about the PSTN service in another=20
> context, but perhaps it is more generally applicable here.=20
> Specifically, consider the case where the called number is=20
> purely PSTN and you want to reach their voicemail. In theory=20
> an ENUM query could return the Call Forwarding Number and the=20
> call could be forwarded out a Media Gateway. The mailbox=20
> would be indicated by the Redirecting Number.
>=20
> James
>=20
> -----Original Message-----
> From: Duane [mailto:duane@e164.org]
> Sent: Tuesday, January 30, 2007 9:57 AM
> To: Paul Kyzivat
> Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> Subject: Re: [Enum] Proposal for new enumservice "voicemail",=20
> using SIP URI
>=20
> Paul Kyzivat wrote:
>=20
> > The above assumes that the VM system is arranged in a suitable way.=20
> > Notably that it has a unique and globally routable URI of=20
> its own for=20
> > each mailbox (possibly by a common URI plus a parameter identifying
> the=20
> > mailbox). Or at least that there is a single globally=20
> routable URI for
>=20
> > the VM server and that the caller will be satisfied with having to
> enter=20
> > the target phone number a second time.
>=20
> While I won't go into the merits of having such an enum=20
> service, (although couldn't it just be a sub-type of pstn?)=20
> it seems pretty trivial to me to be just another SIP URI that=20
> could easily be setup, both in DNS and in most/all software=20
> driven PBXs.
>=20
> eg
>=20
> sip:123456@example.com
> voicemail:vm-123456@example.com
>=20
> On the PBX you simply look for vm- strip it and send the call=20
> into the=20
> voicemail system.
>=20
> eg
>=20
> 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
>=20
> --=20
>=20
> Best regards,
>   Duane
>=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 Jan 30 22:21:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HC61I-0006Er-7X; Tue, 30 Jan 2007 22:20:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HC61H-0006Em-3P
	for enum@ietf.org; Tue, 30 Jan 2007 22:20:23 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC61E-0003Nn-K2
	for enum@ietf.org; Tue, 30 Jan 2007 22:20:23 -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
	l0V3JqG7030732; Tue, 30 Jan 2007 19:20:05 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
	"'Paul Kyzivat'" <pkyzivat@cisco.com>
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com>
	<32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
Date: Tue, 30 Jan 2007 22:19:39 -0500
Message-ID: <011001c744e6$a7f4e5c0$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.3028
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4A=
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C6C@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: b132cb3ed2d4be2017585bf6859e1ede
Cc: enum@ietf.org
Subject: [Enum] The larger issue here.
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat as well. And with
the argument that Jason Livingood makes that this is really covered By RFC
4238.

Chair hat on...

The larger issue is one we will need to deal with in Prague is that this
work group is winding down. With the Infrastructure ENUM issues now in the
hands of "higher authority" we have only one real task which is the
advancement of RFC 3761 to Draft.

We do need to declare victory here and start to close up shop unless there
is compelling technical reasons not to do so and frankly I have not seen one
recently.


> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Tuesday, January 30, 2007 4:03 PM
> To: Paul Kyzivat
> Cc: enum@ietf.org
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
> URI
> 
> I fully support this argument
> Richard
> 
> ________________________________
> 
> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Gesendet: Di 30.01.2007 20:33
> An: Jackson, James
> Cc: enum@ietf.org; Shawn Pouliotte; Duane
> Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
> URI
> 
> 
> 
> A fundamental problem I have with using ENUM is that it is fundamentally
> tied to cases where the address of the callee is an E.164 number. That
> is fine in cases where the problem is intrinsically tied to the use of a
> phone number. But it is an unappealing solution to any problem that also
> applies when the callee is identified by a SIP URI. I certainly see that
> to be the case here. I just as well may want to get to the VM for
> sip:alice@atlanta.com as for tel:+12125551234.
> 
> BTW, that also means that indicating you want VM by prefixing the
> address with *99 isn't an ideal interface. I guess it is *an* interface,
> that might be suitable for UAs that can only deal with numbers. But
> another interface will be needed for alphanumeric calling. I don't think
> the concept of adding to the callee's URI is appropriate in this case.
> Whatever technique does work for alphanumeric URIs would hopefully work
> for phone numbers as well. In general a sip UA supports a telephone
> dialing interface already needs to recognize and locally process some
> star codes, so it ought to be able to do so for this one too.
> 
>         Paul
> 
> Jackson, James wrote:
> > I have been thinking about the PSTN service in another context, but
> > perhaps it is more generally applicable here. Specifically, consider the
> > case where the called number is purely PSTN and you want to reach their
> > voicemail. In theory an ENUM query could return the Call Forwarding
> > Number and the call could be forwarded out a Media Gateway. The mailbox
> > would be indicated by the Redirecting Number.
> >
> > James
> >
> > -----Original Message-----
> > From: Duane [mailto:duane@e164.org]
> > Sent: Tuesday, January 30, 2007 9:57 AM
> > To: Paul Kyzivat
> > Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> > Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
> > URI
> >
> > Paul Kyzivat wrote:
> >
> >> The above assumes that the VM system is arranged in a suitable way.
> >> Notably that it has a unique and globally routable URI of its own for
> >> each mailbox (possibly by a common URI plus a parameter identifying
> > the
> >> mailbox). Or at least that there is a single globally routable URI for
> >
> >> the VM server and that the caller will be satisfied with having to
> > enter
> >> the target phone number a second time.
> >
> > While I won't go into the merits of having such an enum service,
> > (although couldn't it just be a sub-type of pstn?) it seems pretty
> > trivial to me to be just another SIP URI that could easily be setup,
> > both in DNS and in most/all software driven PBXs.
> >
> > eg
> >
> > sip:123456@example.com
> > voicemail:vm-123456@example.com
> >
> > On the PBX you simply look for vm- strip it and send the call into the
> > voicemail system.
> >
> > eg
> >
> > 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> > 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
> >
> 
> _______________________________________________
> 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 Jan 30 22:59:20 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HC6cO-0001IL-Gs; Tue, 30 Jan 2007 22:58:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6cN-0001IC-If
	for enum@ietf.org; Tue, 30 Jan 2007 22:58:43 -0500
Received: from ext-sendmail1.labs.att.com ([205.173.58.19]
	helo=sendmail1.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC6cK-000234-1p
	for enum@ietf.org; Tue, 30 Jan 2007 22:58:43 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail1.labs.att.com (8.13.7/8.13.1) with ESMTP id l0V3bUf4000391; 
	Tue, 30 Jan 2007 21:37:30 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0V3uVqA005017;
	Tue, 30 Jan 2007 21:56:35 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Jan 2007 21:58:23 -0600
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] The larger issue here.
Date: Tue, 30 Jan 2007 21:58:23 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF047BCC95@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] The larger issue here.
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4AAAUYS0A==
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com><32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
	<011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
From: "Jackson, James" <james_jackson@labs.att.com>
To: <richard@shockey.us>, "Stastny Richard" <Richard.Stastny@oefeg.at>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 31 Jan 2007 03:58:23.0933 (UTC)
	FILETIME=[0DE376D0:01C744EC]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


That's fine. RFC4238 works great if the voicemail system implements VPIM
- most do not. The VPIM service defines e-mail access to voicemail much
like the ifax service defines e-mail access to fax. However, there is
also a fax service for PSTN. If someone could shed some light on why a
voicemail service for PSTN is unreasonable that would be appreciated.

Thanks,
James

-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us]=20
Sent: Tuesday, January 30, 2007 9:20 PM
To: 'Stastny Richard'; 'Paul Kyzivat'
Cc: enum@ietf.org
Subject: [Enum] The larger issue here.


Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat as well. And
with
the argument that Jason Livingood makes that this is really covered By
RFC
4238.

Chair hat on...

The larger issue is one we will need to deal with in Prague is that this
work group is winding down. With the Infrastructure ENUM issues now in
the
hands of "higher authority" we have only one real task which is the
advancement of RFC 3761 to Draft.

We do need to declare victory here and start to close up shop unless
there
is compelling technical reasons not to do so and frankly I have not seen
one
recently.


> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Tuesday, January 30, 2007 4:03 PM
> To: Paul Kyzivat
> Cc: enum@ietf.org
> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
SIP
> URI
>=20
> I fully support this argument
> Richard
>=20
> ________________________________
>=20
> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Gesendet: Di 30.01.2007 20:33
> An: Jackson, James
> Cc: enum@ietf.org; Shawn Pouliotte; Duane
> Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using
SIP
> URI
>=20
>=20
>=20
> A fundamental problem I have with using ENUM is that it is
fundamentally
> tied to cases where the address of the callee is an E.164 number. That
> is fine in cases where the problem is intrinsically tied to the use of
a
> phone number. But it is an unappealing solution to any problem that
also
> applies when the callee is identified by a SIP URI. I certainly see
that
> to be the case here. I just as well may want to get to the VM for
> sip:alice@atlanta.com as for tel:+12125551234.
>=20
> BTW, that also means that indicating you want VM by prefixing the
> address with *99 isn't an ideal interface. I guess it is *an*
interface,
> that might be suitable for UAs that can only deal with numbers. But
> another interface will be needed for alphanumeric calling. I don't
think
> the concept of adding to the callee's URI is appropriate in this case.
> Whatever technique does work for alphanumeric URIs would hopefully
work
> for phone numbers as well. In general a sip UA supports a telephone
> dialing interface already needs to recognize and locally process some
> star codes, so it ought to be able to do so for this one too.
>=20
>         Paul
>=20
> Jackson, James wrote:
> > I have been thinking about the PSTN service in another context, but
> > perhaps it is more generally applicable here. Specifically, consider
the
> > case where the called number is purely PSTN and you want to reach
their
> > voicemail. In theory an ENUM query could return the Call Forwarding
> > Number and the call could be forwarded out a Media Gateway. The
mailbox
> > would be indicated by the Redirecting Number.
> >
> > James
> >
> > -----Original Message-----
> > From: Duane [mailto:duane@e164.org]
> > Sent: Tuesday, January 30, 2007 9:57 AM
> > To: Paul Kyzivat
> > Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> > Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
SIP
> > URI
> >
> > Paul Kyzivat wrote:
> >
> >> The above assumes that the VM system is arranged in a suitable way.
> >> Notably that it has a unique and globally routable URI of its own
for
> >> each mailbox (possibly by a common URI plus a parameter identifying
> > the
> >> mailbox). Or at least that there is a single globally routable URI
for
> >
> >> the VM server and that the caller will be satisfied with having to
> > enter
> >> the target phone number a second time.
> >
> > While I won't go into the merits of having such an enum service,
> > (although couldn't it just be a sub-type of pstn?) it seems pretty
> > trivial to me to be just another SIP URI that could easily be setup,
> > both in DNS and in most/all software driven PBXs.
> >
> > eg
> >
> > sip:123456@example.com
> > voicemail:vm-123456@example.com
> >
> > On the PBX you simply look for vm- strip it and send the call into
the
> > voicemail system.
> >
> > eg
> >
> > 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> > 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
> >
>=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


_______________________________________________
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 Jan 31 04:43:44 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCBz2-0008UD-8f; Wed, 31 Jan 2007 04:42:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBz0-0008TB-Ur
	for enum@ietf.org; Wed, 31 Jan 2007 04:42:26 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCByQ-0001U7-RM
	for enum@ietf.org; Wed, 31 Jan 2007 04:41: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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 31 Jan 2007 10:41:16 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D46646AD9@oefeg-s04.oefeg.loc>
In-Reply-To: <011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The larger issue here.
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4AADWBkMA==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <richard@shockey.us>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: enum@ietf.org
Subject: [Enum] RE: The larger issue here.
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Richard Shockey wrote:
>=20
> The larger issue is one we will need to deal with in Prague is that
this
> work group is winding down. With the Infrastructure ENUM issues now in
the
> hands of "higher authority" we have only one real task which is the
> advancement of RFC 3761 to Draft.
>=20
> We do need to declare victory here and start to close up shop unless
there
> is compelling technical reasons not to do so and frankly I have not
seen
> one recently.
>=20

I agree

What we have to find out before we close shop is how someone
may propose an Enumservice (template?) and who is making=20
finally a decision.

We need also to have a procedure for x- Enumservices

Richard


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



From enum-bounces@ietf.org Wed Jan 31 10:40:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCHY9-0002B1-FD; Wed, 31 Jan 2007 10:39:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHY7-0002Ar-PU
	for enum@ietf.org; Wed, 31 Jan 2007 10:39:03 -0500
Received: from shaun.rfc1035.com ([195.54.233.68])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCHY3-00085T-B6
	for enum@ietf.org; Wed, 31 Jan 2007 10:39:03 -0500
Received: from [195.54.233.69] (HELO [195.54.233.69])
	by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4)
	with ESMTP id 142119 for enum@ietf.org; Wed, 31 Jan 2007 15:38:57 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <20442F63-016E-4725-AD7B-373AAD2FE663@rfc1035.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF ENUM WG <enum@ietf.org>
From: Jim Reid <jim@rfc1035.com>
Date: Wed, 31 Jan 2007 15:38:56 +0000
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Subject: [Enum] UK Tier-1 RFP launched
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

I am delighted to tell you that the UK ENUM Consortium has just  
launched the RFP/ITT for the UK Tier 1 Registry, on schedule as  
promised. I will be informing the RIPE and IETF ENUM mailing lists.  
Mail is also being sent to those who attended the UKEC workshop on  
Jan 17th. Please pass on this news to anyone else who might be  
interested.

The ITT and related documents can be downloaded from:

	http://www.ukenumc.org/documents/index.html.

Presentations and other details from the workshop that was held on  
Jan 17th can be found there too.

Organisations planning to respond to the ITT need to inform UKEC of  
that intent by Feb 7th. Responses to the ITT must be submitted before  
noon on Feb 28th.

There may be stale DNS data in some name server caches that will  
prevent email being delivered to the contact email address mentioned  
in the ITT. This should expire in a few hours, allowing the email to  
flow. Please contact me directly if this continues to be problem.


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



From enum-bounces@ietf.org Wed Jan 31 10:55:49 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCHo2-00014T-Im; Wed, 31 Jan 2007 10:55:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHo1-00014N-GK
	for enum@ietf.org; Wed, 31 Jan 2007 10:55:29 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHnz-0001U8-3e
	for enum@ietf.org; Wed, 31 Jan 2007 10:55:29 -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
	l0VFtLGF030073; Wed, 31 Jan 2007 07:55:27 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Stastny Richard'" <Richard.Stastny@oefeg.at>
References: <011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
	<32755D354E6B65498C3BD9FD496C7D46646AD9@oefeg-s04.oefeg.loc>
Subject: RE: [Enum] RE: The larger issue here.
Date: Wed, 31 Jan 2007 10:54:07 -0500
Message-ID: <001701c74550$0b9df530$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.3028
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4AADWBkMAANHQNw
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646AD9@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: c1c65599517f9ac32519d043c37c5336
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Wednesday, January 31, 2007 4:41 AM
> To: richard@shockey.us
> Cc: enum@ietf.org
> Subject: [Enum] RE: The larger issue here.
> 
> 
> Richard Shockey wrote:
> >
> > The larger issue is one we will need to deal with in Prague is that
> this work group is winding down. With the Infrastructure ENUM issues now
in the hands of "higher authority" we have only one real task which is the
> > advancement of RFC 3761 to Draft.

 > > We do need to declare victory here and start to close up shop unless
> there is compelling technical reasons not to do so and frankly I have not
> seen one recently.
> >
> 
> I agree
> 
> What we have to find out before we close shop is how someone
> may propose an Enumservice (template?) and who is making
> finally a decision.

Yes thank you and that is the task of the ENUM service registration draft,
which we need to review in Prague. I think Jason has been frustrated at the
lack of input to the document.

> 
> We need also to have a procedure for x- Enumservices.

I suspect it will be like many of the routine IANA procedures with a expert
committee appointed

> 
> 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 Wed Jan 31 11:01:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCHsv-00050x-TN; Wed, 31 Jan 2007 11:00:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHss-00050F-Ld
	for enum@ietf.org; Wed, 31 Jan 2007 11:00:30 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHsr-0002lA-56
	for enum@ietf.org; Wed, 31 Jan 2007 11:00:30 -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
	l0VG0GCp031555; Wed, 31 Jan 2007 08:00:21 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Jackson, James'" <james_jackson@labs.att.com>,
	"'Stastny Richard'" <Richard.Stastny@oefeg.at>,
	"'Paul Kyzivat'" <pkyzivat@cisco.com>
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com><32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
	<011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
	<0CED449E95A92A42991EB71B778C17BF047BCC95@TSMAIL2.ad.tri.sbc.com>
Subject: RE: [Enum] The larger issue here.
Date: Wed, 31 Jan 2007 10:59:02 -0500
Message-ID: <001b01c74550$bb6f6b10$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.3028
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4AAAUYS0AAZU/sg
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF047BCC95@TSMAIL2.ad.tri.sbc.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: 33cc095b503da4365ce57c727e553cf1
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Because the IETF defines the voice mail service for the PSTN as the VPIM
standard. We generally don't go around creating enum services for things
that are not defined as a standard.

Frankly,  from the comments you are seeing I would not be optimistic on the
chances a draft along the lines you propose would make it through the WG.

> -----Original Message-----
> From: Jackson, James [mailto:james_jackson@labs.att.com]
> Sent: Tuesday, January 30, 2007 10:58 PM
> To: richard@shockey.us; Stastny Richard; Paul Kyzivat
> Cc: enum@ietf.org
> Subject: RE: [Enum] The larger issue here.
> 
> 
> That's fine. RFC4238 works great if the voicemail system implements VPIM
> - most do not. The VPIM service defines e-mail access to voicemail much
> like the ifax service defines e-mail access to fax. However, there is
> also a fax service for PSTN. If someone could shed some light on why a
> voicemail service for PSTN is unreasonable that would be appreciated.
> 
> Thanks,
> James
> 
> -----Original Message-----
> From: Richard Shockey [mailto:richard@shockey.us]
> Sent: Tuesday, January 30, 2007 9:20 PM
> To: 'Stastny Richard'; 'Paul Kyzivat'
> Cc: enum@ietf.org
> Subject: [Enum] The larger issue here.
> 
> 
> Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat as well. And
> with
> the argument that Jason Livingood makes that this is really covered By
> RFC
> 4238.
> 
> Chair hat on...
> 
> The larger issue is one we will need to deal with in Prague is that this
> work group is winding down. With the Infrastructure ENUM issues now in
> the
> hands of "higher authority" we have only one real task which is the
> advancement of RFC 3761 to Draft.
> 
> We do need to declare victory here and start to close up shop unless
> there
> is compelling technical reasons not to do so and frankly I have not seen
> one
> recently.
> 
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> > Sent: Tuesday, January 30, 2007 4:03 PM
> > To: Paul Kyzivat
> > Cc: enum@ietf.org
> > Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
> SIP
> > URI
> >
> > I fully support this argument
> > Richard
> >
> > ________________________________
> >
> > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Gesendet: Di 30.01.2007 20:33
> > An: Jackson, James
> > Cc: enum@ietf.org; Shawn Pouliotte; Duane
> > Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using
> SIP
> > URI
> >
> >
> >
> > A fundamental problem I have with using ENUM is that it is
> fundamentally
> > tied to cases where the address of the callee is an E.164 number. That
> > is fine in cases where the problem is intrinsically tied to the use of
> a
> > phone number. But it is an unappealing solution to any problem that
> also
> > applies when the callee is identified by a SIP URI. I certainly see
> that
> > to be the case here. I just as well may want to get to the VM for
> > sip:alice@atlanta.com as for tel:+12125551234.
> >
> > BTW, that also means that indicating you want VM by prefixing the
> > address with *99 isn't an ideal interface. I guess it is *an*
> interface,
> > that might be suitable for UAs that can only deal with numbers. But
> > another interface will be needed for alphanumeric calling. I don't
> think
> > the concept of adding to the callee's URI is appropriate in this case.
> > Whatever technique does work for alphanumeric URIs would hopefully
> work
> > for phone numbers as well. In general a sip UA supports a telephone
> > dialing interface already needs to recognize and locally process some
> > star codes, so it ought to be able to do so for this one too.
> >
> >         Paul
> >
> > Jackson, James wrote:
> > > I have been thinking about the PSTN service in another context, but
> > > perhaps it is more generally applicable here. Specifically, consider
> the
> > > case where the called number is purely PSTN and you want to reach
> their
> > > voicemail. In theory an ENUM query could return the Call Forwarding
> > > Number and the call could be forwarded out a Media Gateway. The
> mailbox
> > > would be indicated by the Redirecting Number.
> > >
> > > James
> > >
> > > -----Original Message-----
> > > From: Duane [mailto:duane@e164.org]
> > > Sent: Tuesday, January 30, 2007 9:57 AM
> > > To: Paul Kyzivat
> > > Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> > > Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
> SIP
> > > URI
> > >
> > > Paul Kyzivat wrote:
> > >
> > >> The above assumes that the VM system is arranged in a suitable way.
> > >> Notably that it has a unique and globally routable URI of its own
> for
> > >> each mailbox (possibly by a common URI plus a parameter identifying
> > > the
> > >> mailbox). Or at least that there is a single globally routable URI
> for
> > >
> > >> the VM server and that the caller will be satisfied with having to
> > > enter
> > >> the target phone number a second time.
> > >
> > > While I won't go into the merits of having such an enum service,
> > > (although couldn't it just be a sub-type of pstn?) it seems pretty
> > > trivial to me to be just another SIP URI that could easily be setup,
> > > both in DNS and in most/all software driven PBXs.
> > >
> > > eg
> > >
> > > sip:123456@example.com
> > > voicemail:vm-123456@example.com
> > >
> > > On the PBX you simply look for vm- strip it and send the call into
> the
> > > voicemail system.
> > >
> > > eg
> > >
> > > 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> > > 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
> > >
> >
> > _______________________________________________
> > 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 Wed Jan 31 11:12:39 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCI48-0003QB-7n; Wed, 31 Jan 2007 11:12:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI43-0003Fb-HY
	for enum@ietf.org; Wed, 31 Jan 2007 11:12:03 -0500
Received: from shaun.rfc1035.com ([195.54.233.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCI2V-0006HR-KF
	for enum@ietf.org; Wed, 31 Jan 2007 11:10:28 -0500
Received: from [195.54.233.69] (HELO [195.54.233.69])
	by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4)
	with ESMTP id 142132; Wed, 31 Jan 2007 16:10:26 +0000
In-Reply-To: <001701c74550$0b9df530$22f0a544@cis.neustar.com>
References: <011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
	<32755D354E6B65498C3BD9FD496C7D46646AD9@oefeg-s04.oefeg.loc>
	<001701c74550$0b9df530$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: <12A510FD-6309-4F2B-96D4-AA64C75450B3@rfc1035.com>
Content-Transfer-Encoding: 7bit
From: Jim Reid <jim@rfc1035.com>
Subject: Re: [Enum] RE: The larger issue here.
Date: Wed, 31 Jan 2007 16:10:25 +0000
To: richard@shockey.us
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: enum@ietf.org, 'Stastny Richard' <Richard.Stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On Jan 31, 2007, at 15:54, Richard Shockey wrote:

> Yes thank you and that is the task of the ENUM service registration  
> draft,
> which we need to review in Prague. I think Jason has been  
> frustrated at the
> lack of input to the document.
>
>>
>> We need also to have a procedure for x- Enumservices.
>
> I suspect it will be like many of the routine IANA procedures with  
> a expert
> committee appointed

FWIW, this mirrors a similar concern in the dnsop WG. There the issue  
is getting a lightweight procedure for issuing codes for new resource  
record types. The WG is debugging a process that involves an expert  
(singular) making a determination. I think this model may well be a  
good idea for this WG too. IMO if an expert committee is going to be  
appointed to decide about subtypes (ie registrations for new ENUM  
services fields), you might as well just leave that to the whole WG.

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



From enum-bounces@ietf.org Wed Jan 31 11:56:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCIkO-0004d5-MF; Wed, 31 Jan 2007 11:55:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIkN-0004cz-AT
	for enum@ietf.org; Wed, 31 Jan 2007 11:55:47 -0500
Received: from ext-sendmail2.labs.att.com ([205.173.58.20]
	helo=sendmail2.labs.att.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIkH-00067j-It
	for enum@ietf.org; Wed, 31 Jan 2007 11:55:47 -0500
Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com
	[144.60.9.139])
	by sendmail2.labs.att.com (8.13.7/8.13.1) with ESMTP id l0VGtcTc006805; 
	Wed, 31 Jan 2007 10:55:38 -0600
Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228])
	by labs.att.com (8.13.6/8.13.1) with ESMTP id l0VGre7T004186;
	Wed, 31 Jan 2007 10:53:42 -0600
Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by
	TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Jan 2007 10:55:35 -0600
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] The larger issue here.
Date: Wed, 31 Jan 2007 10:55:34 -0600
Message-ID: <0CED449E95A92A42991EB71B778C17BF047FAE62@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <001b01c74550$bb6f6b10$22f0a544@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] The larger issue here.
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4AAAUYS0AAZU/sgAACS/gA=
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com><32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
	<011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
	<0CED449E95A92A42991EB71B778C17BF047BCC95@TSMAIL2.ad.tri.sbc.com>
	<001b01c74550$bb6f6b10$22f0a544@cis.neustar.com>
From: "Jackson, James" <james_jackson@labs.att.com>
To: <richard@shockey.us>, "Stastny Richard" <Richard.Stastny@oefeg.at>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 31 Jan 2007 16:55:35.0813 (UTC)
	FILETIME=[A0A7AB50:01C74558]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


It's fair for the IETF to assume that Unified Messaging platforms
supporting voicemail/fax/e-mail should all do VPIM. However, I wouldn't
say it's correct to assume that all voicemail systems will be Unified
Messaging platforms, or for that matter that voicemail and e-mail would
even necessarily be provided by the same entity.

Would the enumservices fax (for PSTN) and voice (for PSTN) be considered
standards ? I suppose we could call T.30 the standard for fax. So then
this looks more like the voice service but for non-interactive sessions.
Perhaps an alpha-pager using the TAP protocol would be fine since there
is a more defined application-level standard ?

Based on the feedback, I don't think I'll be submitting a draft :) I
just want to understand the logic for why a particular contribution
would or would not be useful. I apologize if this discussion is viewed
as disruptive to the group. Anyone can certainly respond to me off-line
if they like.

James

-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us]=20
Sent: Wednesday, January 31, 2007 9:59 AM
To: Jackson, James; 'Stastny Richard'; 'Paul Kyzivat'
Cc: enum@ietf.org
Subject: RE: [Enum] The larger issue here.


Because the IETF defines the voice mail service for the PSTN as the VPIM
standard. We generally don't go around creating enum services for things
that are not defined as a standard.

Frankly,  from the comments you are seeing I would not be optimistic on
the
chances a draft along the lines you propose would make it through the
WG.

> -----Original Message-----
> From: Jackson, James [mailto:james_jackson@labs.att.com]
> Sent: Tuesday, January 30, 2007 10:58 PM
> To: richard@shockey.us; Stastny Richard; Paul Kyzivat
> Cc: enum@ietf.org
> Subject: RE: [Enum] The larger issue here.
>=20
>=20
> That's fine. RFC4238 works great if the voicemail system implements
VPIM
> - most do not. The VPIM service defines e-mail access to voicemail
much
> like the ifax service defines e-mail access to fax. However, there is
> also a fax service for PSTN. If someone could shed some light on why a
> voicemail service for PSTN is unreasonable that would be appreciated.
>=20
> Thanks,
> James
>=20
> -----Original Message-----
> From: Richard Shockey [mailto:richard@shockey.us]
> Sent: Tuesday, January 30, 2007 9:20 PM
> To: 'Stastny Richard'; 'Paul Kyzivat'
> Cc: enum@ietf.org
> Subject: [Enum] The larger issue here.
>=20
>=20
> Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat as well. And
> with
> the argument that Jason Livingood makes that this is really covered By
> RFC
> 4238.
>=20
> Chair hat on...
>=20
> The larger issue is one we will need to deal with in Prague is that
this
> work group is winding down. With the Infrastructure ENUM issues now in
> the
> hands of "higher authority" we have only one real task which is the
> advancement of RFC 3761 to Draft.
>=20
> We do need to declare victory here and start to close up shop unless
> there
> is compelling technical reasons not to do so and frankly I have not
seen
> one
> recently.
>=20
>=20
> > -----Original Message-----
> > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> > Sent: Tuesday, January 30, 2007 4:03 PM
> > To: Paul Kyzivat
> > Cc: enum@ietf.org
> > Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
> SIP
> > URI
> >
> > I fully support this argument
> > Richard
> >
> > ________________________________
> >
> > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Gesendet: Di 30.01.2007 20:33
> > An: Jackson, James
> > Cc: enum@ietf.org; Shawn Pouliotte; Duane
> > Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using
> SIP
> > URI
> >
> >
> >
> > A fundamental problem I have with using ENUM is that it is
> fundamentally
> > tied to cases where the address of the callee is an E.164 number.
That
> > is fine in cases where the problem is intrinsically tied to the use
of
> a
> > phone number. But it is an unappealing solution to any problem that
> also
> > applies when the callee is identified by a SIP URI. I certainly see
> that
> > to be the case here. I just as well may want to get to the VM for
> > sip:alice@atlanta.com as for tel:+12125551234.
> >
> > BTW, that also means that indicating you want VM by prefixing the
> > address with *99 isn't an ideal interface. I guess it is *an*
> interface,
> > that might be suitable for UAs that can only deal with numbers. But
> > another interface will be needed for alphanumeric calling. I don't
> think
> > the concept of adding to the callee's URI is appropriate in this
case.
> > Whatever technique does work for alphanumeric URIs would hopefully
> work
> > for phone numbers as well. In general a sip UA supports a telephone
> > dialing interface already needs to recognize and locally process
some
> > star codes, so it ought to be able to do so for this one too.
> >
> >         Paul
> >
> > Jackson, James wrote:
> > > I have been thinking about the PSTN service in another context,
but
> > > perhaps it is more generally applicable here. Specifically,
consider
> the
> > > case where the called number is purely PSTN and you want to reach
> their
> > > voicemail. In theory an ENUM query could return the Call
Forwarding
> > > Number and the call could be forwarded out a Media Gateway. The
> mailbox
> > > would be indicated by the Redirecting Number.
> > >
> > > James
> > >
> > > -----Original Message-----
> > > From: Duane [mailto:duane@e164.org]
> > > Sent: Tuesday, January 30, 2007 9:57 AM
> > > To: Paul Kyzivat
> > > Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> > > Subject: Re: [Enum] Proposal for new enumservice "voicemail",
using
> SIP
> > > URI
> > >
> > > Paul Kyzivat wrote:
> > >
> > >> The above assumes that the VM system is arranged in a suitable
way.
> > >> Notably that it has a unique and globally routable URI of its own
> for
> > >> each mailbox (possibly by a common URI plus a parameter
identifying
> > > the
> > >> mailbox). Or at least that there is a single globally routable
URI
> for
> > >
> > >> the VM server and that the caller will be satisfied with having
to
> > > enter
> > >> the target phone number a second time.
> > >
> > > While I won't go into the merits of having such an enum service,
> > > (although couldn't it just be a sub-type of pstn?) it seems pretty
> > > trivial to me to be just another SIP URI that could easily be
setup,
> > > both in DNS and in most/all software driven PBXs.
> > >
> > > eg
> > >
> > > sip:123456@example.com
> > > voicemail:vm-123456@example.com
> > >
> > > On the PBX you simply look for vm- strip it and send the call into
> the
> > > voicemail system.
> > >
> > > eg
> > >
> > > 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
> > > 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
> > >
> >
> > _______________________________________________
> > 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
>=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 Wed Jan 31 12:31:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCJIB-0000Fr-Oq; Wed, 31 Jan 2007 12:30:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJIA-0000Fc-3N
	for enum@ietf.org; Wed, 31 Jan 2007 12:30:42 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJI4-0000IM-HH
	for enum@ietf.org; Wed, 31 Jan 2007 12:30:42 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2007 09:30:36 -0800
X-IronPort-AV: i="4.13,263,1167638400"; 
	d="scan'208"; a="51969820:sNHT59593372"
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/8.12.11) with ESMTP id l0VHUamO017368; 
	Wed, 31 Jan 2007 12:30:36 -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 l0VHURVh008415; 
	Wed, 31 Jan 2007 12:30:36 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Jan 2007 12:30:33 -0500
Received: from [161.44.183.228] ([161.44.183.228]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Jan 2007 12:30:33 -0500
Message-ID: <45C0D239.7000309@cisco.com>
Date: Wed, 31 Jan 2007 12:30:33 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Jackson, James" <james_jackson@labs.att.com>
Subject: Re: [Enum] The larger issue here.
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com>	<0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com><32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc>
	<011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
	<0CED449E95A92A42991EB71B778C17BF047BCC95@TSMAIL2.ad.tri.sbc.com>
	<001b01c74550$bb6f6b10$22f0a544@cis.neustar.com>
	<0CED449E95A92A42991EB71B778C17BF047FAE62@TSMAIL2.ad.tri.sbc.com>
In-Reply-To: <0CED449E95A92A42991EB71B778C17BF047FAE62@TSMAIL2.ad.tri.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Jan 2007 17:30:33.0626 (UTC)
	FILETIME=[830C87A0:01C7455D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7876; t=1170264636;
	x=1171128636; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Enum]=20The=20larger=20issue=20here.
	|Sender:=20
	|To:=20=22Jackson,=20James=22=20<james_jackson@labs.att.com>;
	bh=q/5tcWQiRjmo2IBff1dhU3eObIayEdgphohbA6KYwb0=;
	b=QEbZjuNP1u7tZGtHfk07aAyb5BWP37BBve6WwEdJdTkPSjpuf65GFFa6c2iIWRdIQOSh85us
	IwjAaP7O9P1ZaeeU3gb3suY78MLQxXMQcy2xYSYHMd5ZJdcyugJ6iiRQ;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af
Cc: enum@ietf.org, Stastny Richard <Richard.Stastny@oefeg.at>,
	richard@shockey.us
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



Jackson, James wrote:
> It's fair for the IETF to assume that Unified Messaging platforms
> supporting voicemail/fax/e-mail should all do VPIM. However, I wouldn't
> say it's correct to assume that all voicemail systems will be Unified
> Messaging platforms, or for that matter that voicemail and e-mail would
> even necessarily be provided by the same entity.
> 
> Would the enumservices fax (for PSTN) and voice (for PSTN) be considered
> standards ? I suppose we could call T.30 the standard for fax. So then
> this looks more like the voice service but for non-interactive sessions.
> Perhaps an alpha-pager using the TAP protocol would be fine since there
> is a more defined application-level standard ?
> 
> Based on the feedback, I don't think I'll be submitting a draft :) I
> just want to understand the logic for why a particular contribution
> would or would not be useful. I apologize if this discussion is viewed
> as disruptive to the group. Anyone can certainly respond to me off-line
> if they like.

I don't view your submission and discussion as disruptive.

It is natural for there to be different views on how something should be 
done, and often the people holding those views don't realize that 
alternative views exist. Having the discussion surfaces the issues, 
which is a good thing.

	Paul

> James
> 
> -----Original Message-----
> From: Richard Shockey [mailto:richard@shockey.us] 
> Sent: Wednesday, January 31, 2007 9:59 AM
> To: Jackson, James; 'Stastny Richard'; 'Paul Kyzivat'
> Cc: enum@ietf.org
> Subject: RE: [Enum] The larger issue here.
> 
> 
> Because the IETF defines the voice mail service for the PSTN as the VPIM
> standard. We generally don't go around creating enum services for things
> that are not defined as a standard.
> 
> Frankly,  from the comments you are seeing I would not be optimistic on
> the
> chances a draft along the lines you propose would make it through the
> WG.
> 
>> -----Original Message-----
>> From: Jackson, James [mailto:james_jackson@labs.att.com]
>> Sent: Tuesday, January 30, 2007 10:58 PM
>> To: richard@shockey.us; Stastny Richard; Paul Kyzivat
>> Cc: enum@ietf.org
>> Subject: RE: [Enum] The larger issue here.
>>
>>
>> That's fine. RFC4238 works great if the voicemail system implements
> VPIM
>> - most do not. The VPIM service defines e-mail access to voicemail
> much
>> like the ifax service defines e-mail access to fax. However, there is
>> also a fax service for PSTN. If someone could shed some light on why a
>> voicemail service for PSTN is unreasonable that would be appreciated.
>>
>> Thanks,
>> James
>>
>> -----Original Message-----
>> From: Richard Shockey [mailto:richard@shockey.us]
>> Sent: Tuesday, January 30, 2007 9:20 PM
>> To: 'Stastny Richard'; 'Paul Kyzivat'
>> Cc: enum@ietf.org
>> Subject: [Enum] The larger issue here.
>>
>>
>> Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat as well. And
>> with
>> the argument that Jason Livingood makes that this is really covered By
>> RFC
>> 4238.
>>
>> Chair hat on...
>>
>> The larger issue is one we will need to deal with in Prague is that
> this
>> work group is winding down. With the Infrastructure ENUM issues now in
>> the
>> hands of "higher authority" we have only one real task which is the
>> advancement of RFC 3761 to Draft.
>>
>> We do need to declare victory here and start to close up shop unless
>> there
>> is compelling technical reasons not to do so and frankly I have not
> seen
>> one
>> recently.
>>
>>
>>> -----Original Message-----
>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
>>> Sent: Tuesday, January 30, 2007 4:03 PM
>>> To: Paul Kyzivat
>>> Cc: enum@ietf.org
>>> Subject: Re: [Enum] Proposal for new enumservice "voicemail", using
>> SIP
>>> URI
>>>
>>> I fully support this argument
>>> Richard
>>>
>>> ________________________________
>>>
>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>> Gesendet: Di 30.01.2007 20:33
>>> An: Jackson, James
>>> Cc: enum@ietf.org; Shawn Pouliotte; Duane
>>> Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using
>> SIP
>>> URI
>>>
>>>
>>>
>>> A fundamental problem I have with using ENUM is that it is
>> fundamentally
>>> tied to cases where the address of the callee is an E.164 number.
> That
>>> is fine in cases where the problem is intrinsically tied to the use
> of
>> a
>>> phone number. But it is an unappealing solution to any problem that
>> also
>>> applies when the callee is identified by a SIP URI. I certainly see
>> that
>>> to be the case here. I just as well may want to get to the VM for
>>> sip:alice@atlanta.com as for tel:+12125551234.
>>>
>>> BTW, that also means that indicating you want VM by prefixing the
>>> address with *99 isn't an ideal interface. I guess it is *an*
>> interface,
>>> that might be suitable for UAs that can only deal with numbers. But
>>> another interface will be needed for alphanumeric calling. I don't
>> think
>>> the concept of adding to the callee's URI is appropriate in this
> case.
>>> Whatever technique does work for alphanumeric URIs would hopefully
>> work
>>> for phone numbers as well. In general a sip UA supports a telephone
>>> dialing interface already needs to recognize and locally process
> some
>>> star codes, so it ought to be able to do so for this one too.
>>>
>>>         Paul
>>>
>>> Jackson, James wrote:
>>>> I have been thinking about the PSTN service in another context,
> but
>>>> perhaps it is more generally applicable here. Specifically,
> consider
>> the
>>>> case where the called number is purely PSTN and you want to reach
>> their
>>>> voicemail. In theory an ENUM query could return the Call
> Forwarding
>>>> Number and the call could be forwarded out a Media Gateway. The
>> mailbox
>>>> would be indicated by the Redirecting Number.
>>>>
>>>> James
>>>>
>>>> -----Original Message-----
>>>> From: Duane [mailto:duane@e164.org]
>>>> Sent: Tuesday, January 30, 2007 9:57 AM
>>>> To: Paul Kyzivat
>>>> Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
>>>> Subject: Re: [Enum] Proposal for new enumservice "voicemail",
> using
>> SIP
>>>> URI
>>>>
>>>> Paul Kyzivat wrote:
>>>>
>>>>> The above assumes that the VM system is arranged in a suitable
> way.
>>>>> Notably that it has a unique and globally routable URI of its own
>> for
>>>>> each mailbox (possibly by a common URI plus a parameter
> identifying
>>>> the
>>>>> mailbox). Or at least that there is a single globally routable
> URI
>> for
>>>>> the VM server and that the caller will be satisfied with having
> to
>>>> enter
>>>>> the target phone number a second time.
>>>> While I won't go into the merits of having such an enum service,
>>>> (although couldn't it just be a sub-type of pstn?) it seems pretty
>>>> trivial to me to be just another SIP URI that could easily be
> setup,
>>>> both in DNS and in most/all software driven PBXs.
>>>>
>>>> eg
>>>>
>>>> sip:123456@example.com
>>>> voicemail:vm-123456@example.com
>>>>
>>>> On the PBX you simply look for vm- strip it and send the call into
>> the
>>>> voicemail system.
>>>>
>>>> eg
>>>>
>>>> 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" .
>>>> 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
>>>>
>>> _______________________________________________
>>> 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 Wed Jan 31 15:10:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCLlk-0006Yz-1Y; Wed, 31 Jan 2007 15:09:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLlh-0006Wr-9A
	for enum@ietf.org; Wed, 31 Jan 2007 15:09:21 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCLj7-0004L7-FP
	for enum@ietf.org; Wed, 31 Jan 2007 15:06:42 -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
	l0VK6TCS022850; Wed, 31 Jan 2007 12:06:35 -0800
From: "Richard Shockey" <richard@shockey.us>
To: "'Jim Reid'" <jim@rfc1035.com>
References: <011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
	<32755D354E6B65498C3BD9FD496C7D46646AD9@oefeg-s04.oefeg.loc>
	<001701c74550$0b9df530$22f0a544@cis.neustar.com>
	<12A510FD-6309-4F2B-96D4-AA64C75450B3@rfc1035.com>
Subject: RE: [Enum] RE: The larger issue here.
Date: Wed, 31 Jan 2007 15:06:22 -0500
Message-ID: <00c101c74573$48582400$67201f0a@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.3028
Thread-Index: AcdFUlbYKUTY2FAIRDaoxWzuSLv76gAIFYSg
In-Reply-To: <12A510FD-6309-4F2B-96D4-AA64C75450B3@rfc1035.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: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: enum@ietf.org, 'Stastny Richard' <Richard.Stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



> -----Original Message-----
> From: Jim Reid [mailto:jim@rfc1035.com]
> Sent: Wednesday, January 31, 2007 11:10 AM
> To: richard@shockey.us
> Cc: 'Stastny Richard'; enum@ietf.org
> Subject: Re: [Enum] RE: The larger issue here.
> 
> On Jan 31, 2007, at 15:54, Richard Shockey wrote:
> 
> > Yes thank you and that is the task of the ENUM service registration
> > draft,
> > which we need to review in Prague. I think Jason has been
> > frustrated at the
> > lack of input to the document.
> >
> >>
> >> We need also to have a procedure for x- Enumservices.
> >
> > I suspect it will be like many of the routine IANA procedures with
> > a expert
> > committee appointed
> 
> FWIW, this mirrors a similar concern in the dnsop WG. There the issue
> is getting a lightweight procedure for issuing codes for new resource
> record types. The WG is debugging a process that involves an expert
> (singular) making a determination. I think this model may well be a
> good idea for this WG too. 

Hummm interesting. What does the text look like for the procedure?


IMO if an expert committee is going to be
> appointed to decide about subtypes (ie registrations for new ENUM
> services fields), you might as well just leave that to the whole WG.

Well that "committee" of experts may be 2 individuals. The ultimate issue is
the WG will start to wind down this year, stop meeting, the list and the
formal WG probably remain open but dormant for some time due to liaison
requirements with the ITU etc.  



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



From enum-bounces@ietf.org Wed Jan 31 15:34:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCM8o-0002Cd-EM; Wed, 31 Jan 2007 15:33:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCM8n-0002CY-Nl
	for enum@ietf.org; Wed, 31 Jan 2007 15:33:13 -0500
Received: from shaun.rfc1035.com ([195.54.233.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCM8l-0005Lp-4j
	for enum@ietf.org; Wed, 31 Jan 2007 15:33:13 -0500
Received: from [195.54.233.69] (HELO [195.54.233.69])
	by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4)
	with ESMTP id 142165; Wed, 31 Jan 2007 20:33:08 +0000
In-Reply-To: <00c101c74573$48582400$67201f0a@cis.neustar.com>
References: <011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com>
	<32755D354E6B65498C3BD9FD496C7D46646AD9@oefeg-s04.oefeg.loc>
	<001701c74550$0b9df530$22f0a544@cis.neustar.com>
	<12A510FD-6309-4F2B-96D4-AA64C75450B3@rfc1035.com>
	<00c101c74573$48582400$67201f0a@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: <D8E06CED-90C1-4186-9B61-AEEF1CD4B123@rfc1035.com>
Content-Transfer-Encoding: 7bit
From: Jim Reid <jim@rfc1035.com>
Subject: Re: [Enum] RE: The larger issue here.
Date: Wed, 31 Jan 2007 20:33:07 +0000
To: <richard@shockey.us>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: enum@ietf.org, 'Stastny Richard' <Richard.Stastny@oefeg.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On Jan 31, 2007, at 20:06, Richard Shockey wrote:

>>> I suspect it will be like many of the routine IANA procedures with
>>> a expert committee appointed
>>
>> FWIW, this mirrors a similar concern in the dnsop WG. There the issue
>> is getting a lightweight procedure for issuing codes for new resource
>> record types. The WG is debugging a process that involves an expert
>> (singular) making a determination. I think this model may well be a
>> good idea for this WG too.
>
> Hummm interesting. What does the text look like for the procedure?

See RFC2929bis. The DNSEXT co-chairs appointed one of your  
colleagues, Ed Lewis, to be the expert reviewer.


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