From enum-bounces@ietf.org Sun Jan 01 16:43:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtAz5-0003Je-NH; Sun, 01 Jan 2006 16:43:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtAz3-0003CM-70 for enum@megatron.ietf.org; Sun, 01 Jan 2006 16:43:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16120 for ; Sun, 1 Jan 2006 16:42:08 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtB3y-0000f0-KZ for enum@ietf.org; Sun, 01 Jan 2006 16:48:28 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k01LhUEE027288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jan 2006 13:43:43 -0800 Message-ID: <43B84CDE.7070500@shockey.us> Date: Sun, 01 Jan 2006 16:42:54 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: henry@pulver.com References: <200512292232.jBTMWsgS011371@mailapps.uoregon.edu> In-Reply-To: <200512292232.jBTMWsgS011371@mailapps.uoregon.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, lendl@nic.at Subject: [Enum] Re: [voipeer] I-D: Publishing SIP Peering Policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Henry Sinnreich wrote: > This is seems to be an excellent approach and I suggest we discuss it on the > list and close at the 65 IETF meeting in March. > > Are there any issues with overloading the DNS? None that I can think of ..if the DNS can survive RFID and the ONS it can survive anything. Actually VoIP will be much less a burden on the DNS than SMTP lookups are now. There is vastly more email sent than VoIP calls I would imagine. > > Maybe it would be useful to define XML based policy profiles and have them > registered at IANA? I'm wondering if the structure of some of the work in geopriv is applicable here especially some if the ideas in eXtensible Access Control Markup Language (XACML) http://www.tschofenig.com/drafts/draft-tschofenig-geopriv-authz-policies-00.txt http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-07.txt > > Thanks, Henry > > > > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler > Sent: Thursday, December 29, 2005 9:33 AM > To: voipeer@lists.uoregon.edu > Cc: enum@ietf.org; lendl@nic.at > Subject: [voipeer] I-D: Publishing SIP Peering Policy > > [we've worked out a method to publish SIP peering policy through the > DNS. It falls into SPEERMINT territory but I think it's relevant for > ENUM as well. > here's the gist in a nutshell - flames on. -mah] > > -- > > There will be many, potentially incompatible SIP peering schemes, and > looking > at a SIP URI does not help in deciding wether it is reachable (or > "peerable"). Such > information could be managed in local tables at the egress point. > However, such static > setup information is unwieldy to manage and similar in nature to a > hosts.txt table, or > static routes, and associated disadvantages. > > To aid runtime discovery of "peerable" destinations, and facilitate > management of > peering arrangements (including auto-discovery of new peering > partners which subscribe > to the same set of policies), we propose to name the scheme(s) used > by a provider and > publish them in the DNS, by specialized NAPTR RRs. This enables the > egress point to > decide - in advance and without pre-configuration of peers - wether > the ingress > point will accept a SIP INVITE, and which technique should be employed. > Our proposal also allows smooth migration between peering methods and > helps reduce > the complexity of arrangements by introducing federations, of which a > bilateral > arrangement is just a special case. > > Our proposal focuses on the URI level, and assumes that E.164 numbers > are already > mapped to a URI, for instance by some form of ENUM. > > This draft addresses the problem of managing the peering fabric from > an end-to-end > perspective, which is a core task of the SPEERMINT charter. > > Michael Haberler > Otmar Lendl > > > On 2005/12/28 16:12, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Publishing SIP Peering Policy > > Author(s) : O. Lendl > > Filename : draft-lendl-sip-peering-policy-00.txt > > Pages : 16 > > Date : 2005-12-28 > > > > This documents proposes the use of DNS entries to publish a SIP > > proxy's policy for accepting incoming calls. Such published policies > > can be used to selectively establish peering relationships between > > VoIP service providers. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.txt > > > > [...] > > ____________________________________________________________________________ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > > _____________________________________________________________________________ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 03 03:25:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EthTy-0002vh-Ft; Tue, 03 Jan 2006 03:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EthTw-0002vZ-3k for enum@megatron.ietf.org; Tue, 03 Jan 2006 03:25:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18678 for ; Tue, 3 Jan 2006 03:24:09 -0500 (EST) Received: from ws1.dns-hosting.info ([81.23.228.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EthZ8-00012f-1J for enum@ietf.org; Tue, 03 Jan 2006 03:30:48 -0500 Received: from [192.168.0.6] (mit.xs4all.nl [213.84.95.205]) (authenticated bits=0) by ws1.dns-hosting.info (8.13.5/8.13.5/Debian-3) with ESMTP id k038Os6W020795 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 3 Jan 2006 09:24:55 +0100 In-Reply-To: <6.2.5.6.2.20051229161919.08110568@inode.at> References: <6.2.5.6.2.20051229161919.08110568@inode.at> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94662C6D-237E-4C65-9DDD-56A2E1B07868@ag-projects.com> Content-Transfer-Encoding: 7bit From: Adrian Georgescu Subject: Re: [Enum] I-D: Publishing SIP Peering Policy Date: Tue, 3 Jan 2006 09:24:52 +0100 To: Michael Haberler , lendl@nic.at X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hello Michael and Otmar, I believe this is a very good framework to start build on. By storing the desired peering information at the destination instead of the source or a central place the information will always be up to date as the owner of the domain is directly interested to keep its own DNS data in sync with his policy. This is clever and makes perfect sense. I fully support what is described in this draft. Regards, Adrian On Dec 29, 2005, at 4:32 PM, Michael Haberler wrote: > [we've worked out a method to publish SIP peering policy through > the DNS. It falls into SPEERMINT territory but I think it's > relevant for ENUM as well. > here's the gist in a nutshell - flames on. -mah] > > -- > > There will be many, potentially incompatible SIP peering schemes, > and looking > at a SIP URI does not help in deciding wether it is reachable (or > "peerable"). Such > information could be managed in local tables at the egress point. > However, such static > setup information is unwieldy to manage and similar in nature to a > hosts.txt table, or > static routes, and associated disadvantages. > > To aid runtime discovery of "peerable" destinations, and facilitate > management of > peering arrangements (including auto-discovery of new peering > partners which subscribe > to the same set of policies), we propose to name the scheme(s) used > by a provider and > publish them in the DNS, by specialized NAPTR RRs. This enables the > egress point to > decide - in advance and without pre-configuration of peers - wether > the ingress > point will accept a SIP INVITE, and which technique should be > employed. > Our proposal also allows smooth migration between peering methods > and helps reduce > the complexity of arrangements by introducing federations, of which > a bilateral > arrangement is just a special case. > > Our proposal focuses on the URI level, and assumes that E.164 > numbers are already > mapped to a URI, for instance by some form of ENUM. > > This draft addresses the problem of managing the peering fabric > from an end-to-end > perspective, which is a core task of the SPEERMINT charter. > > Michael Haberler > Otmar Lendl > > > On 2005/12/28 16:12, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet- > Drafts directories. > > > > > > Title : Publishing SIP Peering Policy > > Author(s) : O. Lendl > > Filename : draft-lendl-sip-peering-policy-00.txt > > Pages : 16 > > Date : 2005-12-28 > > > > This documents proposes the use of DNS entries to publish a SIP > > proxy's policy for accepting incoming calls. Such published > policies > > can be used to selectively establish peering relationships > between > > VoIP service providers. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering- > policy-00.txt > > > > [...] > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 03 18:46:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etvr8-0000I4-EW; Tue, 03 Jan 2006 18:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etvr6-0000Hr-QJ for enum@megatron.ietf.org; Tue, 03 Jan 2006 18:46:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05609 for ; Tue, 3 Jan 2006 18:45:01 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtvwT-0006Af-5G for enum@ietf.org; Tue, 03 Jan 2006 18:51:49 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k03Nk68W003472; Tue, 3 Jan 2006 15:46:06 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k03Nk17e003471; Tue, 3 Jan 2006 15:46:01 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 3 Jan 2006 15:46:01 -0800 From: David Meyer To: Henry Sinnreich Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Message-ID: <20060103234601.GA3434@1-4-5.net> References: <6.2.5.6.2.20051229161919.08110568@inode.at> <200512292231.RAA26485@ietf.org> Mime-Version: 1.0 In-Reply-To: <200512292231.RAA26485@ietf.org> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: enum@ietf.org, voipeer@lists.uoregon.edu, lendl@nic.at X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0099962020==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0099962020== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: > This is seems to be an excellent approach and I suggest we discuss it on the > list and close at the 65 IETF meeting in March. Ditto (and happy new year everyone). BTW, I've been trying to spin up the speermint@ietf.org mailing list, but there have been a few snafus. I'll let folks know when that one is up. Dave --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDuwy5ORgD1qCZ2KcRAv0NAKCUkG4JJjH0Fl+ll46Svul5AqaMdACfZCNm mNxOZ52war8H+KcxQLXoiw8= =H7Z0 -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- --===============0099962020== 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 --===============0099962020==-- From enum-bounces@ietf.org Wed Jan 04 12:43:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCfO-00065X-Jy; Wed, 04 Jan 2006 12:43:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCfN-00063b-2g for enum@megatron.ietf.org; Wed, 04 Jan 2006 12:43:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05021 for ; Wed, 4 Jan 2006 12:42:02 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCks-0001u1-Pq for enum@ietf.org; Wed, 04 Jan 2006 12:49:00 -0500 Received: from [10.31.13.101] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k04HhQRV006311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jan 2006 09:43:28 -0800 Message-ID: <43BC0917.4010901@shockey.us> Date: Wed, 04 Jan 2006 12:42:47 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <6.2.5.6.2.20051229161919.08110568@inode.at> <200512292231.RAA26485@ietf.org> <20060103234601.GA3434@1-4-5.net> In-Reply-To: <20060103234601.GA3434@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Henry Sinnreich , lendl@nic.at, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org David Meyer wrote: > On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: > >>This is seems to be an excellent approach and I suggest we discuss it on the >>list and close at the 65 IETF meeting in March. > This is a general question for the list in general. Presuming you could query a network for its VoIP peering policy. What data on terms and conditions of peering would one need to encapsulate? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 04 15:50:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFaP-00027r-46; Wed, 04 Jan 2006 15:50:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFa9-0001tT-Pw; Wed, 04 Jan 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24145; Wed, 4 Jan 2006 15:48:49 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFfg-0008LP-IC; Wed, 04 Jan 2006 15:55:49 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EuFa5-00080R-EZ; Wed, 04 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-pstn-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for an Enumservice Containing PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-02.txt Pages : 11 Date : 2006-1-4 This document registers the Enumservice 'pstn' and subtype 'tel' using the URI scheme 'tel:', as well as the subtype 'sip' using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-pstn-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-pstn-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-4112721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-pstn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-pstn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-4112721.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 04 16:47:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGU2-0007v7-PI; Wed, 04 Jan 2006 16:47:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGU1-0007tK-7W for enum@megatron.ietf.org; Wed, 04 Jan 2006 16:47:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07874 for ; Wed, 4 Jan 2006 16:46:34 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuGZY-0004MB-Gl for enum@ietf.org; Wed, 04 Jan 2006 16:53:33 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k04Lla5X026746; Wed, 4 Jan 2006 13:47:36 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k04LlXfx026745; Wed, 4 Jan 2006 13:47:33 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 4 Jan 2006 13:47:33 -0800 From: David Meyer To: voipeer@lists.uoregon.edu, enum@ietf.org Message-ID: <20060104214733.GA26682@1-4-5.net> References: <6.2.5.6.2.20051229161919.08110568@inode.at> <94662C6D-237E-4C65-9DDD-56A2E1B07868@ag-projects.com> Mime-Version: 1.0 In-Reply-To: <94662C6D-237E-4C65-9DDD-56A2E1B07868@ag-projects.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: llynch@uoregon.edu Subject: [Enum] speermint@ietf.org is up (new "voipeer" list) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0007182859==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0007182859== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, Please subscribe to speermint@ietf.org, and lets move our discussion(s) there. Please see=20 https://www1.ietf.org/mailman/listinfo/speermint As an list administrative point, we'll subscribe speermint@ietf.org to voipeer after we see the traffic die down over there (hopefully a couple of weeks or so).=20 Thanks, Dave --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDvEJ1ORgD1qCZ2KcRAsOvAJ9OVQPdQoxHIpOYXWi1cyLJyWyr8wCfYtKf dtmlElQwnbkBYsBWCqE2T+g= =6vWR -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- --===============0007182859== 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 --===============0007182859==-- From enum-bounces@ietf.org Wed Jan 04 17:39:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuHII-00086g-HB; Wed, 04 Jan 2006 17:39:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuHIH-00085N-EV for enum@megatron.ietf.org; Wed, 04 Jan 2006 17:39:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13408 for ; Wed, 4 Jan 2006 17:38:30 -0500 (EST) 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 1EuHNp-00069G-LV for enum@ietf.org; Wed, 04 Jan 2006 17:45:30 -0500 Received: from ([10.20.9.174]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16055825; Wed, 04 Jan 2006 17:39:07 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 17:39:06 -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-pstn-02.txt Date: Wed, 4 Jan 2006 17:39:06 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39D22@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-pstn-02.txt Thread-Index: AcYRczcYONGsYkFDQMaYPhmVuubgPQADCnKg From: "Livingood, Jason" To: X-OriginalArrivalTime: 04 Jan 2006 22:39:06.0892 (UTC) FILETIME=[ABE2BCC0:01C6117F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This new I-D only included changes in the document reference to draft-ietf-iptel-tel-np-08 (which incremented from -07 to -08). That I-D should go to the RFC editor shortly - we need to ping IPTEL on status. If there are any other comments on this I-D, please send them now... Thanks! Jason > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, January 04, 2006 3:50 PM > To: i-d-announce@ietf.org > Cc: enum@ietf.org > Subject: [Enum] I-D ACTION:draft-ietf-enum-pstn-02.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 : IANA Registration for an Enumservice =20 > Containing PSTN Signaling Information > Author(s) : J. Livingood, R. Shockey > Filename : draft-ietf-enum-pstn-02.txt > Pages : 11 > Date : 2006-1-4 > =09 > This document registers the Enumservice 'pstn' and subtype 'tel'=20 > using the URI scheme 'tel:', as well as the subtype 'sip'=20 > using the=20 > URI scheme 'sip' as per the IANA registration process=20 > defined in the=20 > ENUM specification, RFC 3761. This data is used to facilitate the=20 > routing of telephone calls in those countries where Number=20 > Portability exists. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-02.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 >=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 > "get draft-ietf-enum-pstn-02.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 >=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-pstn-02.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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 09:50:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWRX-0006P0-Q1; Thu, 05 Jan 2006 09:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWRV-0006Ol-1Y for enum@megatron.ietf.org; Thu, 05 Jan 2006 09:50:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22955 for ; Thu, 5 Jan 2006 09:49:00 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWXC-00052H-HI for enum@ietf.org; Thu, 05 Jan 2006 09:56:11 -0500 Received: from [10.31.13.193] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k05Eoi8r020397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2006 06:50:45 -0800 Message-ID: <43BD3196.9040706@shockey.us> Date: Thu, 05 Jan 2006 09:47:50 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-pstn-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Jason and I would like the list to give our draft some extensive review. We have not heard much specific feedback on the draft which we assume to be that all is in order. We'd like to bring the draft to WGLC as soon as practical so if there are comments we'd like to see them now. Thanks. > > Title : IANA Registration for an Enumservice > Containing PSTN Signaling Information > Author(s) : J. Livingood, R. Shockey > Filename : draft-ietf-enum-pstn-02.txt > Pages : 11 > Date : 2006-1-4 > > This document registers the Enumservice 'pstn' and subtype 'tel' > using the URI scheme 'tel:', as well as the subtype 'sip' using the > URI scheme 'sip' as per the IANA registration process defined in the > ENUM specification, RFC 3761. This data is used to facilitate the > routing of telephone calls in those countries where Number > Portability exists. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-enum-pstn-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-pstn-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 11:04:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXbN-0004sZ-T2; Thu, 05 Jan 2006 11:04:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXbK-0004rG-03 for enum@megatron.ietf.org; Thu, 05 Jan 2006 11:04:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01775 for ; Thu, 5 Jan 2006 11:03:14 -0500 (EST) Message-Id: <200601051603.LAA01775@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuXgz-0007pl-Az for enum@ietf.org; Thu, 05 Jan 2006 11:10:24 -0500 Received: (qmail 21614 invoked by uid 510); 5 Jan 2006 11:18:30 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.34):. Processed in 1.158372 secs); 05 Jan 2006 16:18:30 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in 1.158372 secs Process 21609) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Thu, 05 Jan 2006 16:18:28 +0000 From: "Henry Sinnreich" To: "'Richard Shockey'" , "'David Meyer'" Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Thu, 5 Jan 2006 10:04:11 -0600 Organization: pulver.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYRWR6cO5A+HxXnQhiXopzGBRrMrAAtPPWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43BC0917.4010901@shockey.us> X-Antivirus-MYDOMAIN-Message-ID: <113647790983521609@mail.pulver.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d Cc: enum@ietf.org, voipeer@lists.uoregon.edu, lendl@nic.at, carlberg@g11.org.uk X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1723445962==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1723445962== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01C611DF.6428C310" This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01C611DF.6428C310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am not sure if everyone is aware of the recent I-D by K. Carlberg and what it says ( I have added boldface and underline): http://www.ietf.org/internet-drafts/draft-ietf-ieprep-domain-frame-06.txt Needless to say I whole heartedly agree and suggest to include this into the philosophy of the documents of this WG. 1.1. Differences between Single and Inter-domain The progression of our work in the following sections is helped by stating some key differences between the single and inter-domain cases. From a general perspective, one can start by observing the following: a) Congruent with physical topology of resources, each domain is an authority zone and there is currently no scalable way to transfer authority between zones. b) Each authority zone is under separate management c) Authority zones are run by competitors, which acts as further deterrent to transferring authority. As a result of the initial statements in (a) through (c) above, addi- tional observations can be made that distinguish the single and inter-domain case, as stated in the following" d) Different policies might be implemented in different administrative domains. e) There is an absence of any practical method for ingress nodes of a transit domain to authenticate all of the IP network layer packets that have labels indicating a preference or importance. f) Given item (d) above, all current inter-domain QoS mechanisms at the network level generally create easily exploited and significantly painful DoS/DDoS attack vectors on the network. Thanks, Henry -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Wednesday, January 04, 2006 11:43 AM To: David Meyer Cc: Henry Sinnreich; 'Michael Haberler'; voipeer@lists.uoregon.edu; enum@ietf.org; lendl@nic.at Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy David Meyer wrote: > On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: > >>This is seems to be an excellent approach and I suggest we discuss it on the >>list and close at the 65 IETF meeting in March. > This is a general question for the list in general. Presuming you could query a network for its VoIP peering policy. What data on terms and conditions of peering would one need to encapsulate? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------=_NextPart_000_00D7_01C611DF.6428C310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not sure if everyone is aware of the recent I-D by K. = Carlberg and what it says ( I have added boldface and = underline):

 

http://www.ietf.org/internet-drafts/draft-ietf-ieprep-domain-fr= ame-06.txt

 

Needless to say I whole heartedly agree and suggest to include = this into the philosophy of the documents of this = WG.

 

1.1.  Differences between Single and = Inter-domain

 

   The progression of our work in the following = sections is helped by

   stating some key differences between the single and inter-domain

   cases.  From a general perspective, one can = start by observing the

   following:

 

    a) = Congruent with physical topology of resources, each = domain

     = ;  is an authority zone and there is currently no scalable = way

     = ;  to transfer authority between zones.

    b) Each = authority zone is under separate management

    c) = Authority zones are run by competitors, which acts as

     = ;  further deterrent to transferring = authority.

 

   As a result of = the initial statements in (a) through (c) above, = addi-

   tional = observations can be made that distinguish the single and

   inter-domain = case, as stated in the following"

 

    d) = Different policies might be implemented in = different

     = ;  administrative domains.

 

    e) There = is an absence of any practical method for ingress nodes = of

     = ;  a transit domain to authenticate all of the IP network = layer

     = ;  packets that have labels indicating a preference or = importance.

 

    f) = Given item (d) above, all current inter-domain QoS = mechanisms

     = ;  at the network level generally create easily exploited = and

     = ;  significantly painful DoS/DDoS attack vectors on the = network.

 

 

Thanks, Henry

 

 

-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us]
Sent: Wednesday, January 04, 2006 11:43 AM
To: David Meyer
Cc: Henry Sinnreich; 'Michael Haberler'; voipeer@lists.uoregon.edu; enum@ietf.org; lendl@nic.at
Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering = Policy

 

David Meyer wrote:

> On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich = wrote:

>

>>This is seems to be an excellent approach and I suggest = we discuss it on the

>>list and close at the 65 IETF meeting in = March.

>

 

 

This is a general question for the list in = general.

 

Presuming you could query a network for its VoIP peering = policy.

 

What data on terms and conditions of peering would one need to = encapsulate?

 

 

--

 

 

 >>>>>>>>>>>>>>>= ;>>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>&= gt;>

Richard Shockey, Director - Member of Technical = Staff

NeuStar Inc.

46000 Center Oak Plaza  -   Sterling, VA  = 20166

sip:rshockey(at)iptel.org   = sip:57141(at)fwd.pulver.com

ENUM +87810-13313-31331

PSTN Office +1 571.434.5651 PSTN Mobile +1 = 703.593.2683

Fax: +1 815.333.1237

<mailto:richard(at)shockey.us> = or

<mailto:richard.shockey(at)neustar.biz>

<http://www.neustar.biz> ; = <http://www.enum.org>

<<<<<<<<<<<<<<<<&= lt;<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<<<= ; 

 

 

------=_NextPart_000_00D7_01C611DF.6428C310-- --===============1723445962== 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 --===============1723445962==-- From enum-bounces@ietf.org Thu Jan 05 12:46:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZBs-0002p7-To; Thu, 05 Jan 2006 12:46:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZBq-0002o7-5W; Thu, 05 Jan 2006 12:46:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16405; Thu, 5 Jan 2006 12:45:02 -0500 (EST) Received: from smartmx-04.inode.at ([213.229.60.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZHS-0003rr-Tg; Thu, 05 Jan 2006 12:52:13 -0500 Received: from [81.223.16.194] (port=4591 helo=mah9.inode.at) by smartmx-04.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EuZBb-00024j-TE; Thu, 05 Jan 2006 18:46:04 +0100 Message-Id: <6.2.5.6.2.20060105183823.05668bd0@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2006 18:45:51 +0100 To: Richard Shockey , David Meyer From: Michael Haberler Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy In-Reply-To: <43BC0917.4010901@shockey.us> References: <6.2.5.6.2.20051229161919.08110568@inode.at> <200512292231.RAA26485@ietf.org> <20060103234601.GA3434@1-4-5.net> <43BC0917.4010901@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2A2DBA9 X-Spam-Score: 0.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, lendl@nic.at, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 18:42 04.01.2006, Richard Shockey wrote: >David Meyer wrote: >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: >> >>>This is seems to be an excellent approach and I suggest we discuss it on the >>>list and close at the 65 IETF meeting in March. > > >This is a general question for the list in general. > >Presuming you could query a network for its VoIP peering policy. > >What data on terms and conditions of peering would one need to encapsulate? here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >_____________________________________________________________________________ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 13:40:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua29-0002S9-Nj; Thu, 05 Jan 2006 13:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua27-0002Qq-2G; Thu, 05 Jan 2006 13:40:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24749; Thu, 5 Jan 2006 13:39:03 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eua7o-0005wt-Kb; Thu, 05 Jan 2006 13:46:15 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 05 Jan 2006 10:40:07 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05Ie6jt026177; Thu, 5 Jan 2006 10:40:07 -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.211); Thu, 5 Jan 2006 13:40: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: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 5 Jan 2006 13:40:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3EF39FB@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYSIClLAV0sSq29TFyYQ9QarFeRaQABze2A From: "Michael Hammer \(mhammer\)" To: "Michael Haberler" , "Richard Shockey" , "David Meyer" X-OriginalArrivalTime: 05 Jan 2006 18:40:06.0585 (UTC) FILETIME=[72CF4A90:01C61227] X-Spam-Score: 0.8 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Is this another way of asking if a domain can have only a single policy? Mike =20 > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Michael Haberler > Sent: Thursday, January 05, 2006 12:46 PM > To: Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org;=20 > voipeer@lists.uoregon.edu > Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing=20 > SIP PeeringPolicy >=20 > At 18:42 04.01.2006, Richard Shockey wrote: >=20 > >David Meyer wrote: > >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: > >> > >>>This is seems to be an excellent approach and I suggest we=20 > discuss it=20 > >>>on the list and close at the 65 IETF meeting in March. > > > > > >This is a general question for the list in general. > > > >Presuming you could query a network for its VoIP peering policy. > > > >What data on terms and conditions of peering would one need=20 > to encapsulate? >=20 >=20 > here's what we could think of - terms and conditions=20 > basically come from the following four realms: >=20 > * Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS >=20 > * Contractual > - Do I need to sign a contract (with whomever) beforehand? >=20 > * Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. >=20 > * Financial > - No settlement? > - If yes, how. >=20 > Note that we are NOT proposing to auto-detect, auto-match=20 > this full gamut of policy elements - we need to finish this=20 > in time; auto-matching legal & regulatory aspects is out of=20 > scope for us. >=20 > Another general question is the following: Is the peering=20 > policy a function of the recipient's domain, or one of the=20 > full URI? In other words, is peering done one the domain=20 > level (and thus equal to all users ain that domain) or do we=20 > need to support policies which differ amongst users? >=20 >=20 > Michael Haberler > Otmar Lendl >=20 >=20 >=20 >=20 >=20 >=20 > >-- > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > >46000 Center Oak Plaza - Sterling, VA 20166 > >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > >ENUM +87810-13313-31331 > >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > >Fax: +1 815.333.1237 > > or > > > > ; =20 > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >_____________________________________________________________ > __________ > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 13:58:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaJG-0006Ma-6O; Thu, 05 Jan 2006 13:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaJE-0006MK-9J; Thu, 05 Jan 2006 13:58:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26726; Thu, 5 Jan 2006 13:56:44 -0500 (EST) Received: from smartmx-09.inode.at ([213.229.60.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaOw-0006da-MA; Thu, 05 Jan 2006 14:03:56 -0500 Received: from [81.223.16.194] (port=4643 helo=mah9.inode.at) by smartmx-09.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EuaJA-0003Hy-V5; Thu, 05 Jan 2006 19:57:57 +0100 Message-Id: <6.2.5.6.2.20060105195222.05bb4690@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2006 19:57:50 +0100 To: "Michael Hammer \(mhammer\)" From: Michael Haberler Subject: RE: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3EF39FB@xmb-rtp-20b.amer.ci sco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3EF39FB@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5B1F139B X-Spam-Score: 2.2 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 19:40 05.01.2006, Michael Hammer \(mhammer\) wrote: >Is this another way of asking if a domain can have only a single policy? > >Mike no, it's the list of issues which we believe one would consider when defining a policy as per draft-lendl-sip-peering-policy-00.txt: - a policy is tacked onto a federation, be it explicit or ad-hoc - a domain may publish an arbitrary number of federations -Michael > > > > -----Original Message----- > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] On Behalf Of Michael Haberler > > Sent: Thursday, January 05, 2006 12:46 PM > > To: Richard Shockey; David Meyer > > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; > > voipeer@lists.uoregon.edu > > Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing > > SIP PeeringPolicy > > > > At 18:42 04.01.2006, Richard Shockey wrote: > > > > >David Meyer wrote: > > >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: > > >> > > >>>This is seems to be an excellent approach and I suggest we > > discuss it > > >>>on the list and close at the 65 IETF meeting in March. > > > > > > > > >This is a general question for the list in general. > > > > > >Presuming you could query a network for its VoIP peering policy. > > > > > >What data on terms and conditions of peering would one need > > to encapsulate? > > > > > > here's what we could think of - terms and conditions > > basically come from the following four realms: > > > > * Technical > > - What SIP transport is required? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 16:00:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EucDp-0002i0-0M; Thu, 05 Jan 2006 16:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EucDn-0002hc-94 for enum@megatron.ietf.org; Thu, 05 Jan 2006 16:00:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13993 for ; Thu, 5 Jan 2006 15:59:14 -0500 (EST) Message-Id: <200601052059.PAA13993@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EucJX-0003Wf-5L for enum@ietf.org; Thu, 05 Jan 2006 16:06:27 -0500 Received: (qmail 26913 invoked by uid 510); 5 Jan 2006 16:14:41 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.34):. Processed in 0.858455 secs); 05 Jan 2006 21:14:41 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in 0.858455 secs Process 26908) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Thu, 05 Jan 2006 21:14:40 +0000 From: "Henry Sinnreich" To: "'Michael Haberler'" , "'Richard Shockey'" , "'David Meyer'" Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Thu, 5 Jan 2006 15:00:17 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYSIioIHXyqa8jxTuysPakUOVRXywAFLqsw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.5.6.2.20060105183823.05668bd0@inode.at> X-Antivirus-MYDOMAIN-Message-ID: <113649568083526908@mail.pulver.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org, lendl@nic.at X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org A scalable approach must include peering policies that can be matched without human intervention. Today, it is best effort QoS with no other strings attached. It will be interesting to see if it possible to have anything else better than best effort: Maybe some DSCP to start with. A DSCP for QoS may be a good start for interdomain VoIP. What other policies could be automated for matching by machines? I would avoid having a big registrar in the sky, other than DNS and ENUM, since otherwise we will be back to politics again. Besides: Everybody will want to be this registrar :-) Also known as a settlement house. We could end up with just as many settlement providers as there are VoIP islands. The latest count is 552 at http://www.myvoipprovider.com/ Starting with ENUM/DNS discovery as you have proposed and DiffServ between consenting peering VoIP providers would be a great accomplishment by this WG! Thanks, Henry -----Original Message----- From: Michael Haberler [mailto:mah@inode.at] Sent: Thursday, January 05, 2006 11:46 AM To: Richard Shockey; David Meyer Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; lendl@nic.at; speermint@ietf.org Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy At 18:42 04.01.2006, Richard Shockey wrote: >David Meyer wrote: >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: >> >>>This is seems to be an excellent approach and I suggest we discuss it on the >>>list and close at the 65 IETF meeting in March. > > >This is a general question for the list in general. > >Presuming you could query a network for its VoIP peering policy. > >What data on terms and conditions of peering would one need to encapsulate? here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >___________________________________________________________________________ __ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 16:56:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eud5y-0007VQ-T9; Thu, 05 Jan 2006 16:56:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eud5v-0007V0-EB; Thu, 05 Jan 2006 16:56:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27692; Thu, 5 Jan 2006 16:55:10 -0500 (EST) Received: from smartmx-03.inode.at ([213.229.60.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EudBd-0008BY-9T; Thu, 05 Jan 2006 17:02:24 -0500 Received: from [81.223.16.194] (port=4816 helo=mah9.inode.at) by smartmx-03.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Eud5j-0001pR-Ar; Thu, 05 Jan 2006 22:56:15 +0100 Message-Id: <6.2.5.6.2.20060105222928.05bce9c0@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2006 22:56:02 +0100 To: "Khan, Sohel Q [CTO]" , "Richard Shockey" , "David Meyer" From: Michael Haberler Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E03B63E41@PLSWB08C.ad.sprin t.com> References: <978886E57CC1D64EAFAC157B98E36F9E03B63E41@PLSWB08C.ad.sprint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5B1F139B X-Spam-Score: 0.8 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, lendl@nic.at, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 22:20 05.01.2006, Khan, Sohel Q [CTO] wrote: > >We also need to address: how does a mobile user enjoy the outcome of his >home admin-domain policy when the he is visiting a foreign admin-domain >that implements a different policy. Sohel, we're just having very modest goals here - addressing the basic problem of interworking between ITAD's represented by SIP domains without assuming the whole world runs open URIs, with acceptable management load and in finite time (this year, that is). The GSM association is a quite good example for a federation, which sets rules for traffic between their members. Why dont you guys just go for that and be done? I understand that IMS roaming is a bit of a home-grown challenge but I would be very hesitant to take on fixing it on the plate in this working group. We need to sort this out though wether that's in scope - what is the WG opinion here? -Michael >-----Original Message----- >From: owner-voipeer@lists.uoregon.edu >[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler >Sent: Thursday, January 05, 2006 11:46 AM >To: Richard Shockey; David Meyer >Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; >lendl@nic.at; speermint@ietf.org >Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > > >here's what we could think of - terms and conditions basically come >from the following four realms: > >* Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS > >* Contractual > - Do I need to sign a contract (with whomever) beforehand? > >* Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. > >* Financial > - No settlement? > - If yes, how. > >Note that we are NOT proposing to auto-detect, auto-match this full >gamut of policy elements - we need to finish this in time; auto-matching >legal & regulatory aspects is out of scope for us. > >Another general question is the following: Is the peering policy a >function of the recipient's domain, or one of the full URI? In other >words, is peering done one the domain level (and thus equal to all users >ain that domain) or do we need to support policies which differ amongst >users? > > >Michael Haberler >Otmar Lendl > > > > > > > >-- > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > >46000 Center Oak Plaza - Sterling, VA 20166 > >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > >ENUM +87810-13313-31331 > >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > >Fax: +1 815.333.1237 > > or > > > > ; > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >_______________________________________________________________________ > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > >________________________________________________________________________ >_____ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 18:06:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueC4-0004sN-GI; Thu, 05 Jan 2006 18:06:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueC2-0004sD-7n; Thu, 05 Jan 2006 18:06:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07006; Thu, 5 Jan 2006 18:05:34 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EueHn-0002Uj-HU; Thu, 05 Jan 2006 18:12:48 -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: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Fri, 6 Jan 2006 00:10:21 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4751@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYSIehxht7gcx+xTzSKmNLqj2eyDwAGvdaQAAPUvsA= From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-Spam-Score: 0.8 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org =20 >We also need to address: how does a mobile user enjoy the outcome of = his >home admin-domain policy when the he is visiting a foreign admin-domain >that implements a different policy. First someone needs to explain to me what "visiting a foreign domain" means on the public Internet. I always register with my home domain. I may use a different access, but I am always contacted via my home domain, using my home profile. I would consider it very strange if e.g. the Mariott in New York where I = am currently connected would screen my incoming calls depending on THEIR = policy Richard ________________________________ Von: speermint-bounces@ietf.org im Auftrag von Khan, Sohel Q [CTO] Gesendet: Do 05.01.2006 22:20 An: Michael Haberler; Richard Shockey; David Meyer Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; = voipeer@lists.uoregon.edu Betreff: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = PeeringPolicy We also need to address: how does a mobile user enjoy the outcome of his home admin-domain policy when the he is visiting a foreign admin-domain that implements a different policy. -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler Sent: Thursday, January 05, 2006 11:46 AM To: Richard Shockey; David Meyer Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; lendl@nic.at; speermint@ietf.org Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >_______________________________________________________________________ >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html ________________________________________________________________________ _____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ 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 05 18:17:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueM0-0001Zv-4U; Thu, 05 Jan 2006 18:17:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueLy-0001Zl-Jl; Thu, 05 Jan 2006 18:17:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08564; Thu, 5 Jan 2006 18:15:51 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EueRk-0002tr-MS; Thu, 05 Jan 2006 18:23:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Fri, 6 Jan 2006 00:20:50 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4 From: "Stastny Richard" To: "Michael Haberler" , "Richard Shockey" , "David Meyer" X-Spam-Score: 0.8 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, lendl@nic.at, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >Another general question is the following: Is the peering policy a >function of the recipient's domain, or one of the full URI? In other >words, is peering done one the domain level (and thus equal to all >users ain that domain) or do we need to support policies which differ = amongst >users? This is a very interesting point I am considering since some time. Basically the final decision which calls one wants to accept is an end-users decision. If I as an end-user decide to accept a call from anybody, this is my decision. The policy in the lendl I-D is only for the whole domain, a policy on a single URI level is possible here only by giving always the weakest policy, which would be the "." and = therefore useless. On the other hand, with ENUM a policy for a single E.164 number=20 would be possible. Any ideas how to extend this to URIs? Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Michael Haberler Gesendet: Do 05.01.2006 18:45 An: Richard Shockey; David Meyer Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; lendl@nic.at; = voipeer@lists.uoregon.edu Betreff: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy At 18:42 04.01.2006, Richard Shockey wrote: >David Meyer wrote: >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: >> >>>This is seems to be an excellent approach and I suggest we discuss it = on the >>>list and close at the 65 IETF meeting in March. > > >This is a general question for the list in general. > >Presuming you could query a network for its VoIP peering policy. > >What data on terms and conditions of peering would one need to = encapsulate? here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ = amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >________________________________________________________________________= _____ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ 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 05 18:36:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eueex-0007RB-Sa; Thu, 05 Jan 2006 18:36:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eueev-0007R3-92; Thu, 05 Jan 2006 18:36:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11087; Thu, 5 Jan 2006 18:35:25 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euekb-0003au-0H; Thu, 05 Jan 2006 18:42:36 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 4EB7F78420; Thu, 5 Jan 2006 23:35:47 +0000 (GMT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4751@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4751@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 5 Jan 2006 23:35:54 +0000 To: "Stastny Richard" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Henry Sinnreich , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, folks, ... but, then again, the Marriot doesn't charge you to receive calls. When looking at IMS, I am reminded of the following quote: "In C++ it's harder to shoot yourself in the foot, but when you do, =20 you blow off your whole leg." =97 Bjarne Stroustrup. Re. the draft - which is what this thread WAS about... IMO, it's an excellent start - lots of fixmes, but a solid base on =20 which to build. As mentioned by others, I also wonder about whether or not a domain =20 is the atomic level for a particular federated policy. This SEEMs to be =20 appropriate, but I can't picture every possible scenario. I AM reminded of the discussion a few years back on the phone context =20= for the tel: URL. At least for SIP peering as discussed in the draft, one may have =20= a simpler problem to solve, and SIP does use a domain as an atomic element: One is going to talk to a server, and through SRVs and the whacky =20 load-balancing NAPTRs, that/those server(s) claim to be authoritative for that =20 domain's SIP processing, so I think it/they will apply a consistent policy ***FOR =20 PEERING***. This is different from an individual recipient's policies; I would =20 assume that executing those policies is a job for the end user (or his/her agent). IMHO, executing Individual policies is way out of scope for ENUM, and =20= speermint, and anything else that is dealing purely with peering. If that =20 Individual's device has registered with a different domain, then it's no surprise if a =20 different policy is applied. Peering had better work on IMS, or GSMA have not been doing their job =20= - either way, how is this the IETF's problem? all the best & happy new year, Lawrence On 5 Jan 2006, at 23:10, Stastny Richard wrote: >> We also need to address: how does a mobile user enjoy the outcome =20 >> of his >> home admin-domain policy when the he is visiting a foreign admin-=20 >> domain >> that implements a different policy. > > First someone needs to explain to me what "visiting a foreign domain" > means on the public Internet. > > I always register with my home domain. I may use a different access, > but I am always contacted via my home domain, using my home profile. > > I would consider it very strange if e.g. the Mariott in New York =20 > where I am > currently connected would screen my incoming calls depending on =20 > THEIR policy > > Richard > > > ________________________________ > > Von: speermint-bounces@ietf.org im Auftrag von Khan, Sohel Q [CTO] > Gesendet: Do 05.01.2006 22:20 > An: Michael Haberler; Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; =20 > voipeer@lists.uoregon.edu > Betreff: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP =20 > PeeringPolicy > > > > > We also need to address: how does a mobile user enjoy the outcome =20 > of his > home admin-domain policy when the he is visiting a foreign admin-=20 > domain > that implements a different policy. > > > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler > Sent: Thursday, January 05, 2006 11:46 AM > To: Richard Shockey; David Meyer > Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; > lendl@nic.at; speermint@ietf.org > Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > > > here's what we could think of - terms and conditions basically come > from the following four realms: > > * Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS > > * Contractual > - Do I need to sign a contract (with whomever) beforehand? > > * Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. > > * Financial > - No settlement? > - If yes, how. > > Note that we are NOT proposing to auto-detect, auto-match this full > gamut of policy elements - we need to finish this in time; auto-=20 > matching > legal & regulatory aspects is out of scope for us. > > Another general question is the following: Is the peering policy a > function of the recipient's domain, or one of the full URI? In other > words, is peering done one the domain level (and thus equal to all =20 > users > ain that domain) or do we need to support policies which differ =20 > amongst > users? > > > Michael Haberler > Otmar Lendl > > > > > > >> -- >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >> ENUM +87810-13313-31331 >> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >> Fax: +1 815.333.1237 >> or >> >> ; >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> _____________________________________________________________________=20= >> __ >> ______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > ______________________________________________________________________=20= > __ > _____ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > > > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 05 19:29:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufTa-0007Zi-2A; Thu, 05 Jan 2006 19:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufTX-0007Z9-3v for enum@megatron.ietf.org; Thu, 05 Jan 2006 19:28:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17719 for ; Thu, 5 Jan 2006 19:27:43 -0500 (EST) Message-Id: <200601060027.TAA17719@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EufZJ-00060G-LS for enum@ietf.org; Thu, 05 Jan 2006 19:34:58 -0500 Received: (qmail 20208 invoked by uid 510); 5 Jan 2006 19:43:08 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.34):. Processed in 1.188403 secs); 06 Jan 2006 00:43:08 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in 1.188403 secs Process 20203) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Fri, 06 Jan 2006 00:43:07 +0000 From: "Henry Sinnreich" To: "'lconroy'" , "'Stastny Richard'" Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 5 Jan 2006 18:28:46 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYSUs4JEzQvKJE/R/2tsF0GO47V2wABRKRw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Antivirus-MYDOMAIN-Message-ID: <113650818783520203@mail.pulver.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org, 'Richard Shockey' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >Peering had better work on IMS, or GSMA have not been doing their job >- either way, >how is this the IETF's problem? Correct! I believe this sums it up. Thanks, Henry -----Original Message----- From: lconroy [mailto:lconroy@insensate.co.uk] Sent: Thursday, January 05, 2006 5:36 PM To: Stastny Richard Cc: Khan, Sohel Q [CTO]; Michael Haberler; Richard Shockey; David Meyer; enum@ietf.org; Henry Sinnreich; speermint@ietf.org; voipeer@lists.uoregon.edu Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Hi Richard, folks, ... but, then again, the Marriot doesn't charge you to receive calls. When looking at IMS, I am reminded of the following quote: "In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." - Bjarne Stroustrup. Re. the draft - which is what this thread WAS about... IMO, it's an excellent start - lots of fixmes, but a solid base on which to build. As mentioned by others, I also wonder about whether or not a domain is the atomic level for a particular federated policy. This SEEMs to be appropriate, but I can't picture every possible scenario. I AM reminded of the discussion a few years back on the phone context for the tel: URL. At least for SIP peering as discussed in the draft, one may have a simpler problem to solve, and SIP does use a domain as an atomic element: One is going to talk to a server, and through SRVs and the whacky load-balancing NAPTRs, that/those server(s) claim to be authoritative for that domain's SIP processing, so I think it/they will apply a consistent policy ***FOR PEERING***. This is different from an individual recipient's policies; I would assume that executing those policies is a job for the end user (or his/her agent). IMHO, executing Individual policies is way out of scope for ENUM, and speermint, and anything else that is dealing purely with peering. If that Individual's device has registered with a different domain, then it's no surprise if a different policy is applied. Peering had better work on IMS, or GSMA have not been doing their job - either way, how is this the IETF's problem? all the best & happy new year, Lawrence On 5 Jan 2006, at 23:10, Stastny Richard wrote: >> We also need to address: how does a mobile user enjoy the outcome >> of his >> home admin-domain policy when the he is visiting a foreign admin- >> domain >> that implements a different policy. > > First someone needs to explain to me what "visiting a foreign domain" > means on the public Internet. > > I always register with my home domain. I may use a different access, > but I am always contacted via my home domain, using my home profile. > > I would consider it very strange if e.g. the Mariott in New York > where I am > currently connected would screen my incoming calls depending on > THEIR policy > > Richard > > > ________________________________ > > Von: speermint-bounces@ietf.org im Auftrag von Khan, Sohel Q [CTO] > Gesendet: Do 05.01.2006 22:20 > An: Michael Haberler; Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; > voipeer@lists.uoregon.edu > Betreff: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP > PeeringPolicy > > > > > We also need to address: how does a mobile user enjoy the outcome > of his > home admin-domain policy when the he is visiting a foreign admin- > domain > that implements a different policy. > > > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler > Sent: Thursday, January 05, 2006 11:46 AM > To: Richard Shockey; David Meyer > Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; > lendl@nic.at; speermint@ietf.org > Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > > > here's what we could think of - terms and conditions basically come > from the following four realms: > > * Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS > > * Contractual > - Do I need to sign a contract (with whomever) beforehand? > > * Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. > > * Financial > - No settlement? > - If yes, how. > > Note that we are NOT proposing to auto-detect, auto-match this full > gamut of policy elements - we need to finish this in time; auto- > matching > legal & regulatory aspects is out of scope for us. > > Another general question is the following: Is the peering policy a > function of the recipient's domain, or one of the full URI? In other > words, is peering done one the domain level (and thus equal to all > users > ain that domain) or do we need to support policies which differ > amongst > users? > > > Michael Haberler > Otmar Lendl > > > > > > >> -- >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >> ENUM +87810-13313-31331 >> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >> Fax: +1 815.333.1237 >> or >> >> ; >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> _____________________________________________________________________ >> __ >> ______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > ______________________________________________________________________ > __ > _____ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > > > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 06 08:07:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EurJw-0000UM-0v; Fri, 06 Jan 2006 08:07:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufMf-0004PV-Hf; Thu, 05 Jan 2006 19:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17336; Thu, 5 Jan 2006 19:20:35 -0500 (EST) Received: from h139-142-184-176.roothosts.com ([139.142.184.176] helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EufSO-0005oV-SB; Thu, 05 Jan 2006 19:27:50 -0500 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 7028CE872; Thu, 5 Jan 2006 19:21:25 -0500 (EST) Message-ID: <43BDB7B9.2050902@e164.org> Date: Thu, 05 Jan 2006 19:20:09 -0500 From: Duane User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 06 Jan 2006 08:07:50 -0500 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org, lendl@nic.at, Henry Sinnreich , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > On the other hand, with ENUM a policy for a single E.164 number > would be possible. > > Any ideas how to extend this to URIs? most things in NAPTR are similar to: x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+HTTP" "!.*!HTTP://www.example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+MAILTO" "!.*!MAILTO:user@example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+ADDRESS" "!.*!ADDRESS:/CN=Fred Smith/STREET=123 Xyz St/L=Bedrock/ST=RA/C=Gondwana Land/PC=123456789!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+SIP" "!^\\+13609681666$!sip:user@example.com!" . Wouldn't be hard to do something like this, but incorporate the end users connection preferences similar to the document posted earlier. -- 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://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "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 06 08:08:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EurKS-0000hn-0h; Fri, 06 Jan 2006 08:08:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufUf-0007rF-0U; Thu, 05 Jan 2006 19:30:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17784; Thu, 5 Jan 2006 19:28:52 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EufaL-00061l-SN; Thu, 05 Jan 2006 19:36:07 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-126.messagelabs.com!1136507386!11656473!2 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17460 invoked from network); 6 Jan 2006 00:29:49 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-126.messagelabs.com with SMTP; 6 Jan 2006 00:29:49 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 43AED14A000FB57D; Thu, 5 Jan 2006 19:29:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Thu, 5 Jan 2006 18:29:44 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C005@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSV1rh5iTjPd0wRYqV54ZwVCzzSQAAIBfw From: "Dolly, Martin C" To: "Duane" , "Stastny Richard" X-Spam-Score: 0.6 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-Mailman-Approved-At: Fri, 06 Jan 2006 08:08:23 -0500 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org, lendl@nic.at, Henry Sinnreich , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0338991992==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0338991992== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61258.4A769CFF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61258.4A769CFF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 I was curious, being there is so much marketing advertising (via links) = on these e-mail lists, whether I can put a plug in for my brothers = printing businsess, or is that the line where this e-amil list draws the = line between technical versus "other" on this list? =20 Cheers, =20 Martin -----Original Message----- From: owner-voipeer@lists.uoregon.edu = [mailto:owner-voipeer@lists.uoregon.edu]On Behalf Of Duane Sent: Thursday, January 05, 2006 7:20 PM To: Stastny Richard Cc: Michael Haberler; Richard Shockey; David Meyer; enum@ietf.org; Henry = Sinnreich; speermint@ietf.org; lendl@nic.at; voipeer@lists.uoregon.edu Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Stastny Richard wrote: > On the other hand, with ENUM a policy for a single E.164 number=20 > would be possible. >=20 > Any ideas how to extend this to URIs? most things in NAPTR are similar to: x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+HTTP"=20 "!.*!HTTP://www.example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+MAILTO"=20 "!.*!MAILTO: user@example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+ADDRESS"=20 "!.*!ADDRESS:/CN=3DFred Smith/STREET=3D123 Xyz = St/L=3DBedrock/ST=3DRA/C=3DGondwana=20 Land/PC=3D123456789!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+SIP"=20 "!^\\ +13609681666$!sip: user@example.com!" . Wouldn't be hard to do something like this, but incorporate the end=20 users connection preferences similar to the document posted earlier. --=20 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://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _________________________________________________________________________= ____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html ------_=_NextPart_001_01C61258.4A769CFF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering = Policy
Hello,
 
I was=20 curious, being there is so much marketing advertising (via links) on = these=20 e-mail lists, whether I can put a plug in for my brothers printing = businsess, or=20 is that the line where this e-amil list draws the line between technical = versus=20 "other" on this list?
 
Cheers,
 
Martin
-----Original Message-----
From:=20 owner-voipeer@lists.uoregon.edu = [mailto:owner-voipeer@lists.uoregon.edu]On=20 Behalf Of Duane
Sent: Thursday, January 05, 2006 7:20=20 PM
To: Stastny Richard
Cc: Michael Haberler; = Richard=20 Shockey; David Meyer; enum@ietf.org; Henry Sinnreich; = speermint@ietf.org;=20 lendl@nic.at; voipeer@lists.uoregon.edu
Subject: Re: [Enum] = RE:=20 [voipeer] I-D: Publishing SIP Peering = Policy

Stastny=20 Richard wrote:

> On the other hand, with ENUM a policy for a = single=20 E.164 number
> would be possible.
>
> Any ideas = how to=20 extend this to URIs?

most things in NAPTR are similar=20 to:

x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" = "E2U+HTTP"=20
"!.*!HTTP://www.example.com!" .
x.x.x.x.x.x.x.x.x.x.x.e164.org. = 600 IN=20 NAPTR 100 10 "u" "E2U+MAILTO"
"!.*!MAILTO:user@example.com!"=20 .
x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" = "E2U+ADDRESS"=20
"!.*!ADDRESS:/CN=3DFred Smith/STREET=3D123 Xyz = St/L=3DBedrock/ST=3DRA/C=3DGondwana=20
Land/PC=3D123456789!" .
x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN = NAPTR 100=20 10 "u" "E2U+SIP"
"!^\\+13609681666$!sip:user@example.com!" = .

Wouldn't be=20 hard to do something like this, but incorporate the end
users = connection=20 preferences similar to the document posted earlier.

-- =

Best=20 regards,
Duane

http://www.cacert.org - Free = Security=20 Certificates
http://www.nodedb.com -=20 Think globally, network locally
http://www.sydneywireless.com = -=20 Telecommunications Freedom
http://happysnapper.com.au - = Sell your=20 photos over the net!
http://e164.org - Using=20 Enum.164 to interconnect asterisk servers

"In the long run the=20 pessimist may be proved right,
but the optimist has a better time = on the=20 = trip."
_______________________________________________________________= ______________
List=20 Archive: http://darkwing.uor= egon.edu/~llynch/voipeer/
User=20 Tools: http://darkwing= .uoregon.edu/~llynch/voipeer.html
= ------_=_NextPart_001_01C61258.4A769CFF-- --===============0338991992== 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 --===============0338991992==-- From enum-bounces@ietf.org Fri Jan 06 12:32:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvRc-0006oX-Mm; Fri, 06 Jan 2006 12:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvRa-0006n7-JE; Fri, 06 Jan 2006 12:32:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16716; Fri, 6 Jan 2006 12:30:46 -0500 (EST) 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 1EuvXW-0000UC-GN; Fri, 06 Jan 2006 12:38:10 -0500 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16105273; Fri, 06 Jan 2006 12:31:22 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Jan 2006 12:31:21 -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: [voipeer] I-D: Publishing SIP Peering Policy Date: Fri, 6 Jan 2006 12:31:20 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39D6A@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZA= From: "Livingood, Jason" To: "Stastny Richard" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-OriginalArrivalTime: 06 Jan 2006 17:31:21.0922 (UTC) FILETIME=[02BB6A20:01C612E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, lendl@nic.at X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > >Another general question is the following: Is the peering policy a=20 > >function of the recipient's domain, or one of the full URI? In other=20 > >words, is peering done one the domain level (and thus equal to all=20 > >users ain that domain) or do we need to support policies=20 > which differ=20 > >amongst users? >=20 > This is a very interesting point I am considering since some time. >=20 > Basically the final decision which calls one wants to accept=20 > is an end-users decision. If I as an end-user decide to=20 > accept a call from anybody, this is my decision. The policy=20 > in the lendl I-D is only for the whole domain, a policy on a=20 > single URI level is possible here only by giving always the=20 > weakest policy, which would be the "." and therefore useless. (BTW, have not read this I-D in full yet.) In a given domain you could have several service types, differentiated perhaps by using sub-domains. Each of these may have differing QoS expectations, costs, and associated peering policies. Seems like it is whatever is to the right of the @ in the URI. In the same way that you associate certain resource records for a domain and different ones for each sub-domain -- control of which can be delegated out, say to an enterprise, then you could presumably do the same here. (I'd leave examination of the user portion of the URI, to the left of the @ sign, to the application that answers the callflow rather than burdening the DNS with such complexity, as with email where you find MX records in the DNS and the SMTP server looks at the user name and determines proper treatment once a message is received.) For example even within a domain you may want a few sub-domains and these may well have very different associated policies, and security and QoS expectations:=20 12159817813@foo.bar - general flat-rate consumer voip service 12159817600@smb.foo.bar - small-medium sized business voip, may involve IP-PBXs as endpoints, whatever 12159817601@enterprise.foo.bar - enterprise customers with higher QoS expectations 12159817602@free.foo.bar - free im & voip application service with best-efforts QoS (meaning no QoS) I like the discussion so far... Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 06 13:20:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwCa-0007k9-Ay; Fri, 06 Jan 2006 13:20:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwCY-0007k1-U4; Fri, 06 Jan 2006 13:20:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19977; Fri, 6 Jan 2006 13:19:18 -0500 (EST) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwIT-0001uu-W9; Fri, 06 Jan 2006 13:26:43 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Fri, 6 Jan 2006 13:19:35 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006010613193432410 ; Fri, 06 Jan 2006 13:19:34 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Jan 2006 13:19:34 -0500 Message-Id: <84E5D7F15F52D34DA84C9C90ACE6554F622BEF@0591-its-exmp01.us.saic.com> From: "Roy, Radhika R." To: "Livingood, Jason" , Stastny Richard , Michael Haberler , Richard Shockey , David Meyer Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peer ingPolicy Date: Fri, 6 Jan 2006 13:19:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075170345==" Sender: enum-bounces@ietf.org 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. --===============1075170345== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C612ED.B6EAE4AB" 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_01C612ED.B6EAE4AB Content-Type: text/plain; charset="iso-8859-1" Please see inline [RRR]. For example even within a domain you may want a few sub-domains and these may well have very different associated policies, and security and QoS expectations: 12159817813@foo.bar - general flat-rate consumer voip service 12159817600@smb.foo.bar - small-medium sized business voip, may involve IP-PBXs as endpoints, whatever 12159817601@enterprise.foo.bar - enterprise customers with higher QoS expectations 12159817602@free.foo.bar - free im & voip application service with best-efforts QoS (meaning no QoS) [RRR] Domain name cannot be associated with any specific services per URL/URI standards. It is true that a domain may have many sub-domains. [RRR] Certain other mechanisms need to be found out to associate with services, NOT directly in domain name URLs/URIs. ------_=_NextPart_001_01C612ED.B6EAE4AB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = PeeringPolicy

Please see inline [RRR].

For example even within a domain

you may want a few sub-domains and these may well have very = different

associated policies, and security and QoS expectations: =

12159817813@foo.bar

        - general flat-rate consumer voip = service

12159817600@smb.foo.bar

        - small-medium sized business voip, = may involve IP-PBXs as

endpoints, whatever

12159817601@enterprise.foo.bar

        - enterprise customers with higher = QoS expectations

12159817602@free.foo.bar

        - free im & voip application = service with best-efforts QoS

(meaning no QoS)

[RRR]  Domain name cannot = be associated with any specific services per URL/URI = standards. It is true that a domain may have many = sub-domains.

[RRR] Certain other mechanisms need to be found out to = associate with services, NOT directly in domain name = URLs/URIs. =

------_=_NextPart_001_01C612ED.B6EAE4AB-- --===============1075170345== 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 --===============1075170345==-- From enum-bounces@ietf.org Sun Jan 08 23:28:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvoeO-0000Ow-IJ; Sun, 08 Jan 2006 23:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvoeK-0000Nd-Fd; Sun, 08 Jan 2006 23:28:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13432; Sun, 8 Jan 2006 23:27:33 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evoki-0007HI-R5; Sun, 08 Jan 2006 23:35:31 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k094SMj13582; Sun, 8 Jan 2006 23:28:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Sun, 8 Jan 2006 23:28:19 -0500 Message-ID: Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZAAbPS90A== From: "James McEachern" To: "Livingood, Jason" , "Stastny Richard" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, lendl@nic.at X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I'm not sure I follow this completely, but it seems to suggest that an = enterprise customer would not be able to get high quality when making a = call (inter-domain) to someone who subscribed to "general flat-rate = consumer voip" - even if the enterprise user was making the call, and = willing to pay for it. This seems counter-intuitive to me. Jim=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Livingood, Jason Sent: Friday, January 06, 2006 12:31 PM (BTW, have not read this I-D in full yet.) In a given domain you could have several service types, differentiated perhaps by using sub-domains. Each of these may have differing QoS expectations, costs, and associated peering policies. Seems like it is whatever is to the right of the @ in the URI. In the same way that you associate certain resource records for a domain and different ones for each sub-domain -- control of which can be delegated out, say to an enterprise, then you could presumably do the same here. (I'd leave examination of the user portion of the URI, to the left of the @ sign, to the application that answers the callflow rather than burdening the DNS with such complexity, as with email where you find MX records in the DNS and the SMTP server looks at the user name and determines proper treatment once a message is received.) For example even within a domain you may want a few sub-domains and these may well have very different associated policies, and security and QoS expectations:=20 12159817813@foo.bar - general flat-rate consumer voip service 12159817600@smb.foo.bar - small-medium sized business voip, may involve IP-PBXs as endpoints, whatever 12159817601@enterprise.foo.bar - enterprise customers with higher QoS expectations 12159817602@free.foo.bar - free im & voip application service with best-efforts QoS (meaning no QoS) I like the discussion so far... Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 09 12:36:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0x0-00071y-6p; Mon, 09 Jan 2006 12:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0wx-0006x1-Vg; Mon, 09 Jan 2006 12:36:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05873; Mon, 9 Jan 2006 12:35:36 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew13T-0005Nc-Ib; Mon, 09 Jan 2006 12:43:42 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id DBEB81A488; Mon, 9 Jan 2006 18:36:43 +0100 (CET) Date: Mon, 9 Jan 2006 18:36:43 +0100 From: Otmar Lendl To: Stastny Richard Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Message-ID: <20060109173643.GA15301@nic.at> Mail-Followup-To: Otmar Lendl , Stastny Richard , Michael Haberler , Richard Shockey , David Meyer , enum@ietf.org, Henry Sinnreich , speermint@ietf.org, voipeer@lists.uoregon.edu References: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org, Henry Sinnreich , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org [I will stop crossposting to the voipeer and enum@ietf lists, IMHO this belongs to the speermint list.] On 2006/01/06 00:01, Stastny Richard wrote: > >Another general question is the following: Is the peering policy a > >function of the recipient's domain, or one of the full URI? In other > >words, is peering done one the domain level (and thus equal to all > >users ain that domain) or do we need to support policies which differ amongst > >users? > > This is a very interesting point I am considering since some time. > > Basically the final decision which calls one wants to accept is an > end-users decision. If I as an end-user decide to accept a call from > anybody, this is my decision. The policy in the lendl I-D is only > for the whole domain, a policy on a single URI level is possible here > only by giving always the weakest policy, which would be the "." and therefore > useless. Right now in the PSTN, we have peering policies on a carrier-level and individual per-subscriber policies as well. E.g. consider the various call-blocking feature US-based carriers have deployed over the last years to combat telemarketers and anonymous calls. As far as I know, such individual blocks are internal to a carrier and not announced to others. The same can be implemented in a SIP setting: The domain policies tell you that the destination network will talk to you over IP, but then there still is the option to block the call inside the destination network for any reason. The only new part here is that we might need an additional SIP error code indicating "I blocked this call, you might try some other route" (in contrast to "This user is not available at all") Such user-specific blocks could be implements purely on the user's SIP device. As Jason wrote, if you really want to run separate policies for a set of users for inter-provider routing, then you can use different domains. > On the other hand, with ENUM a policy for a single E.164 number > would be possible. Yes, but one design criteria was independence from E.164 numbers. The scheme needs to work in a pure SIP world as well. > Any ideas how to extend this to URIs? Do we really need to? In the email world this isn't done, too. All current protocols regarding proxy and transport selection for SIP are only based on the domain. I don't want to diverge from that model. /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 09 13:20:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1cx-0002gi-Gc; Mon, 09 Jan 2006 13:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1cu-0002gI-3v for enum@megatron.ietf.org; Mon, 09 Jan 2006 13:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09426 for ; Mon, 9 Jan 2006 13:18:56 -0500 (EST) Message-Id: <200601091818.NAA09426@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1jR-0006ua-Db for enum@ietf.org; Mon, 09 Jan 2006 13:27:01 -0500 Received: (qmail 27205 invoked by uid 510); 9 Jan 2006 13:35:35 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.111.112):. Processed in 0.880192 secs); 09 Jan 2006 18:35:35 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in 0.880192 secs Process 27199) Received: from c-67-187-111-112.hsd1.wa.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@67.187.111.112) by 192.246.69.184 with SMTP; Mon, 09 Jan 2006 18:35:34 +0000 From: "Henry Sinnreich" To: "'Otmar Lendl'" Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Mon, 9 Jan 2006 12:19:37 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYVRXNrHjJG2MNVSEqjMWgcqdsOSQAAGprg In-Reply-To: <20060109173643.GA15301@nic.at> X-Antivirus-MYDOMAIN-Message-ID: <113683173483527199@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , speermint@ietf.org, 'Richard Shockey' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar, You say: >All current protocols regarding proxy and transport selection for SIP >are only based on the domain. I don't want to diverge from that model. What business has the broadband provider to mess with the user preferences? Users and enterprises pay for a certain bandwidth and hopefully will have the choice to pay extra for Diff Serv and that's the end of it. If one domain has DiffServ and the other does not, it's up to the users to continue the call or switch over to some other networks, such as mobile or PSTN. And also to tell the other party to please subscribe to better broadband :-) What do you think? Thanks, Henry -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Monday, January 09, 2006 11:37 AM To: Stastny Richard Cc: Michael Haberler; Richard Shockey; David Meyer; enum@ietf.org; Henry Sinnreich; speermint@ietf.org; voipeer@lists.uoregon.edu Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy [I will stop crossposting to the voipeer and enum@ietf lists, IMHO this belongs to the speermint list.] On 2006/01/06 00:01, Stastny Richard wrote: > >Another general question is the following: Is the peering policy a > >function of the recipient's domain, or one of the full URI? In other > >words, is peering done one the domain level (and thus equal to all > >users ain that domain) or do we need to support policies which differ amongst > >users? > > This is a very interesting point I am considering since some time. > > Basically the final decision which calls one wants to accept is an > end-users decision. If I as an end-user decide to accept a call from > anybody, this is my decision. The policy in the lendl I-D is only > for the whole domain, a policy on a single URI level is possible here > only by giving always the weakest policy, which would be the "." and therefore > useless. Right now in the PSTN, we have peering policies on a carrier-level and individual per-subscriber policies as well. E.g. consider the various call-blocking feature US-based carriers have deployed over the last years to combat telemarketers and anonymous calls. As far as I know, such individual blocks are internal to a carrier and not announced to others. The same can be implemented in a SIP setting: The domain policies tell you that the destination network will talk to you over IP, but then there still is the option to block the call inside the destination network for any reason. The only new part here is that we might need an additional SIP error code indicating "I blocked this call, you might try some other route" (in contrast to "This user is not available at all") Such user-specific blocks could be implements purely on the user's SIP device. As Jason wrote, if you really want to run separate policies for a set of users for inter-provider routing, then you can use different domains. > On the other hand, with ENUM a policy for a single E.164 number > would be possible. Yes, but one design criteria was independence from E.164 numbers. The scheme needs to work in a pure SIP world as well. > Any ideas how to extend this to URIs? Do we really need to? In the email world this isn't done, too. All current protocols regarding proxy and transport selection for SIP are only based on the domain. I don't want to diverge from that model. /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 09 17:17:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5Ka-00064I-7b; Mon, 09 Jan 2006 17:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5KX-00062U-J0; Mon, 09 Jan 2006 17:17:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03279; Mon, 9 Jan 2006 17:16:12 -0500 (EST) 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 1Ew5R3-00084y-1H; Mon, 09 Jan 2006 17:24:19 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16162258; Mon, 09 Jan 2006 17:17:05 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 17:17:05 -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: [voipeer] I-D: Publishing SIP Peering Policy Date: Mon, 9 Jan 2006 17:17:04 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39DCE@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZAAbPS90AA0bcRQ From: "Livingood, Jason" To: "James McEachern" , "Stastny Richard" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-OriginalArrivalTime: 09 Jan 2006 22:17:05.0482 (UTC) FILETIME=[6C5452A0:01C6156A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, lendl@nic.at X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The items listed were for example purposes. I just wanted to illustrate that a provider may wish to vary VoIP peering policies by sub-domain rather than having just one policy at the domain level. I just listed quick examples for each sub-domain, segmented by some illustrative customer types (SMB, enterprise, consumer, etc.). And w/r/t my enterprise example, I actually meant to indicate that they had very high QoS expectations and policies, but no matter... ;-) Jason > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Sunday, January 08, 2006 11:28 PM > To: Livingood, Jason; Stastny Richard; Michael Haberler;=20 > Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; lendl@nic.at > Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >=20 > I'm not sure I follow this completely, but it seems to=20 > suggest that an enterprise customer would not be able to get=20 > high quality when making a call (inter-domain) to someone who=20 > subscribed to "general flat-rate consumer voip" - even if the=20 > enterprise user was making the call, and willing to pay for=20 > it. This seems counter-intuitive to me. >=20 > Jim=20 >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Livingood, Jason > Sent: Friday, January 06, 2006 12:31 PM >=20 >=20 > (BTW, have not read this I-D in full yet.) >=20 > In a given domain you could have several service types,=20 > differentiated perhaps by using sub-domains. Each of these=20 > may have differing QoS expectations, costs, and associated=20 > peering policies. Seems like it is whatever is to the right=20 > of the @ in the URI. In the same way that you associate=20 > certain resource records for a domain and different ones for=20 > each sub-domain -- control of which can be delegated out, say=20 > to an enterprise, then you could presumably do the same here.=20 > (I'd leave examination of the user portion of the URI, to=20 > the left of the @ sign, to the application that answers the=20 > callflow rather than burdening the DNS with such complexity,=20 > as with email where you find MX records in the DNS and the=20 > SMTP server looks at the user name and determines proper=20 > treatment once a message is received.) For example even=20 > within a domain you may want a few sub-domains and these may=20 > well have very different associated policies, and security=20 > and QoS expectations:=20 >=20 > 12159817813@foo.bar > - general flat-rate consumer voip service >=20 > 12159817600@smb.foo.bar > - small-medium sized business voip, may involve IP-PBXs=20 > as endpoints, whatever >=20 > 12159817601@enterprise.foo.bar > - enterprise customers with higher QoS expectations >=20 > 12159817602@free.foo.bar > - free im & voip application service with best-efforts=20 > QoS (meaning no QoS) >=20 > I like the discussion so far... >=20 > Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 09 18:05:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew65M-00056o-VU; Mon, 09 Jan 2006 18:05:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew65J-00055W-V3; Mon, 09 Jan 2006 18:05:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06374; Mon, 9 Jan 2006 18:04:34 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6Bt-000116-Ep; Mon, 09 Jan 2006 18:12:42 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 80B861A606; Tue, 10 Jan 2006 00:05:40 +0100 (CET) Date: Tue, 10 Jan 2006 00:05:40 +0100 From: Otmar Lendl To: Henry Sinnreich Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Message-ID: <20060109230539.GH9002@nic.at> Mail-Followup-To: Otmar Lendl , Henry Sinnreich , 'Michael Haberler' , 'Richard Shockey' , 'David Meyer' , enum@ietf.org, speermint@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' References: <20060109173643.GA15301@nic.at> <200601091820.k09IK6Wx049276@mx5.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601091820.k09IK6Wx049276@mx5.univie.ac.at> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , speermint@ietf.org, 'Richard Shockey' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2006/01/09 19:01, Henry Sinnreich wrote: > Otmar, > > You say: > > >All current protocols regarding proxy and transport selection for SIP > >are only based on the domain. I don't want to diverge from that model. > > What business has the broadband provider to mess with the user preferences? > Users and enterprises pay for a certain bandwidth and hopefully will have > the choice to pay extra for Diff Serv and that's the end of it. In an ideal world, yes. > If one domain has DiffServ and the other does not, it's up to the users to > continue the call or switch over to some other networks, such as mobile or > PSTN. And also to tell the other party to please subscribe to better > broadband :-) > > What do you think? > My problem with this idea is that "domain" in the sense of SIP-servers is an application layer notion. DiffServ is a layer 3 issue. My layer 3 network does not neccessarily know which applications I run over them. If my ISP also acts as my SIP provider, then yes: one can link these two layers into one integrated QoS solution. AFAIK this is one of the aims of the IMS. One of the local Austrian ISPs uses this for his VoIP service: they use separate VLANs/QoS planes for their VoIP offering. My private playground is quite different: I use an Asterisk installation on a box (the same one I write this mail on) colocated at ISP A whereas my SIP-phone at home is connected via ISP B. The gateway to the PSTN is operated by a commercial provider who uses ISP C. If you add my ENUM nameservers, you get one more ISP into the picture. To top it off, I could add a SIP line to my office phone which would bring our office connectivity into the game were we basically run own multihomed network. I really don't know how to get seamless QoS in such a setting. (As you mentioned before: layer3 networks can't just trust each other's DiffServ settings.) /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 Wed Jan 11 12:07:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjRF-0002Ec-Ln; Wed, 11 Jan 2006 12:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjRD-0002E5-3X; Wed, 11 Jan 2006 12:07:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27020; Wed, 11 Jan 2006 12:05:47 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwjY9-0000zw-Om; Wed, 11 Jan 2006 12:14:18 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2006 09:06:57 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0BH6iR2026991; Wed, 11 Jan 2006 09:06:56 -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.211); Wed, 11 Jan 2006 12:06:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Wed, 11 Jan 2006 12:06:54 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYVcXSrzRNkn9vZQlyTqzaipt4R0wBXneKA From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , "Henry Sinnreich" X-OriginalArrivalTime: 11 Jan 2006 17:06:55.0342 (UTC) FILETIME=[6CA5D0E0:01C616D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , speermint@ietf.org, Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org There MUST be some association of IP layer protocol elements to L5 traffic needs, such as low delay, packet loss etc. If the L5 need is real-time transmission, and that translates to a DSCP marking, then the IP network needs to meet that need one way or another or very simply the real-time service breaks. The alternative is that the peering always must include both L5 and L3 and you get a half-step instead of full-step in evolution from PSTN to IP. Put another way, is it really necessary to have L5 transit networks? If you insist that L3 always be paired with L5 for real-time, that is what you get. Mike > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu=20 > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl > Sent: Monday, January 09, 2006 6:06 PM > To: Henry Sinnreich > Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer';=20 > enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu;=20 > 'Stastny Richard' > Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >=20 > On 2006/01/09 19:01, Henry Sinnreich wrote: > > Otmar, > >=20 > > You say: > >=20 > > >All current protocols regarding proxy and transport=20 > selection for SIP=20 > > >are only based on the domain. I don't want to diverge from=20 > that model. > >=20 > > What business has the broadband provider to mess with the=20 > user preferences? > > Users and enterprises pay for a certain bandwidth and=20 > hopefully will=20 > > have the choice to pay extra for Diff Serv and that's the end of it. >=20 > In an ideal world, yes. >=20 > > If one domain has DiffServ and the other does not, it's up to the=20 > > users to continue the call or switch over to some other=20 > networks, such=20 > > as mobile or PSTN. And also to tell the other party to please=20 > > subscribe to better broadband :-) > >=20 > > What do you think? > >=20 >=20 > My problem with this idea is that "domain" in the sense of=20 > SIP-servers is an application layer notion. >=20 > DiffServ is a layer 3 issue. My layer 3 network does not=20 > neccessarily know which applications I run over them. >=20 > If my ISP also acts as my SIP provider, then yes: one can=20 > link these two layers into one integrated QoS solution. AFAIK=20 > this is one of the aims of the IMS. One of the local Austrian=20 > ISPs uses this for his VoIP service: they use separate=20 > VLANs/QoS planes for their VoIP offering. >=20 > My private playground is quite different: I use an Asterisk=20 > installation on a box (the same one I write this mail on)=20 > colocated at ISP A whereas my SIP-phone at home is connected=20 > via ISP B. The gateway to the PSTN is operated by a=20 > commercial provider who uses ISP C. > If you add my ENUM nameservers, you get one more ISP into the picture. > To top it off, I could add a SIP line to my office phone=20 > which would bring our office connectivity into the game were=20 > we basically run own multihomed network. >=20 > I really don't know how to get seamless QoS in such a setting. >=20 > (As you mentioned before: layer3 networks can't just trust=20 > each other's DiffServ settings.) >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >=20 > ______________________________________________________________ > _______________ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 11 12:34:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewjs0-0004Pk-Vn; Wed, 11 Jan 2006 12:34:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewjrz-0004PA-8k; Wed, 11 Jan 2006 12:34:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29007; Wed, 11 Jan 2006 12:33:26 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewjyt-0001pp-Nk; Wed, 11 Jan 2006 12:41:58 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0BHYrx6013551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2006 09:34:54 -0800 Message-ID: <43C54193.3000202@shockey.us> Date: Wed, 11 Jan 2006 12:34:11 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , speermint@ietf.org, Otmar Lendl , Henry Sinnreich X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Michael Hammer (mhammer) wrote: > There MUST be some association of IP layer protocol elements to L5 > traffic needs, such as low delay, packet loss etc. If the L5 need is > real-time transmission, and that translates to a DSCP marking, then the > IP network needs to meet that need one way or another or very simply the > real-time service breaks. The alternative is that the peering always > must include both L5 and L3 and you get a half-step instead of full-step > in evolution from PSTN to IP. > > Put another way, is it really necessary to have L5 transit networks? If > you insist that L3 always be paired with L5 for real-time, that is what > you get. > > Mike > I dont disagree and this is exactly the point Dave Oran made in BC but I recall the general consensus in the room was that that specific problem was out of scope for speermint now but that the proposed solution should be able to accomodiate this requirement in the future. Which is why some form of general purpose XML based admission control mechanism seems interesting here. As part of that admission control protocol would be information on network state in order to permit the peering parties to judge whether interconnection ( under these terms at these points )is even possible. > > >>-----Original Message----- >>From: owner-voipeer@lists.uoregon.edu >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>Sent: Monday, January 09, 2006 6:06 PM >>To: Henry Sinnreich >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>'Stastny Richard' >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >> >>On 2006/01/09 19:01, Henry Sinnreich wrote: >> >>>Otmar, >>> >>>You say: >>> >>> >>>>All current protocols regarding proxy and transport >> >>selection for SIP >> >>>>are only based on the domain. I don't want to diverge from >> >>that model. >> >>>What business has the broadband provider to mess with the >> >>user preferences? >> >>>Users and enterprises pay for a certain bandwidth and >> >>hopefully will >> >>>have the choice to pay extra for Diff Serv and that's the end of it. >> >>In an ideal world, yes. >> >> >>>If one domain has DiffServ and the other does not, it's up to the >>>users to continue the call or switch over to some other >> >>networks, such >> >>>as mobile or PSTN. And also to tell the other party to please >>>subscribe to better broadband :-) >>> >>>What do you think? >>> >> >>My problem with this idea is that "domain" in the sense of >>SIP-servers is an application layer notion. >> >>DiffServ is a layer 3 issue. My layer 3 network does not >>neccessarily know which applications I run over them. >> >>If my ISP also acts as my SIP provider, then yes: one can >>link these two layers into one integrated QoS solution. AFAIK >>this is one of the aims of the IMS. One of the local Austrian >>ISPs uses this for his VoIP service: they use separate >>VLANs/QoS planes for their VoIP offering. >> >>My private playground is quite different: I use an Asterisk >>installation on a box (the same one I write this mail on) >>colocated at ISP A whereas my SIP-phone at home is connected >>via ISP B. The gateway to the PSTN is operated by a >>commercial provider who uses ISP C. >>If you add my ENUM nameservers, you get one more ISP into the picture. >>To top it off, I could add a SIP line to my office phone >>which would bring our office connectivity into the game were >>we basically run own multihomed network. >> >>I really don't know how to get seamless QoS in such a setting. >> >>(As you mentioned before: layer3 networks can't just trust >>each other's DiffServ settings.) >> >>/ol >>-- >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>______________________________________________________________ >>_______________ >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >> > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 11 13:02:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkIo-0005Qg-OD; Wed, 11 Jan 2006 13:02:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkIm-0005Q9-Az; Wed, 11 Jan 2006 13:02:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00826; Wed, 11 Jan 2006 13:01:05 -0500 (EST) Received: from zcars04e.nortel.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwkPe-0002eD-7l; Wed, 11 Jan 2006 13:09:37 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k0BHwIV10056; Wed, 11 Jan 2006 12:58:18 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 13:01:54 -0500 Received: from [127.0.0.1] ([47.130.16.144] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 13:01:53 -0500 Message-ID: <43C5480B.4080906@nortel.com> Date: Wed, 11 Jan 2006 13:01:47 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 18:01:54.0048 (UTC) FILETIME=[1AD46800:01C616D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , speermint@ietf.org, Otmar Lendl , Henry Sinnreich X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The MSF is defining a scenario they hope to demonstrate, where media paths cross different domains from signalling. The signalling may be of the form visited originating network - home originating network - home terminating network - visited terminating network. This typical scenario is an obvious example of L5 transit. Then the media path is optimized to run directly between the visited networks, possibly by way of a different transit network offering QoS based on diffserv markings at the egress points of the visited networks. L5 and L3 are linked in the originating and terminating visited networks, but not in between. Michael Hammer (mhammer) wrote: > There MUST be some association of IP layer protocol elements to L5 > traffic needs, such as low delay, packet loss etc. If the L5 need is > real-time transmission, and that translates to a DSCP marking, then the > IP network needs to meet that need one way or another or very simply the > real-time service breaks. The alternative is that the peering always > must include both L5 and L3 and you get a half-step instead of full-step > in evolution from PSTN to IP. > > Put another way, is it really necessary to have L5 transit networks? If > you insist that L3 always be paired with L5 for real-time, that is what > you get. > > Mike > > > >>-----Original Message----- >>From: owner-voipeer@lists.uoregon.edu >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>Sent: Monday, January 09, 2006 6:06 PM >>To: Henry Sinnreich >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>'Stastny Richard' >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >> >>On 2006/01/09 19:01, Henry Sinnreich wrote: >> >>>Otmar, >>> >>>You say: >>> >>> >>>>All current protocols regarding proxy and transport >> >>selection for SIP >> >>>>are only based on the domain. I don't want to diverge from >> >>that model. >> >>>What business has the broadband provider to mess with the >> >>user preferences? >> >>>Users and enterprises pay for a certain bandwidth and >> >>hopefully will >> >>>have the choice to pay extra for Diff Serv and that's the end of it. >> >>In an ideal world, yes. >> >> >>>If one domain has DiffServ and the other does not, it's up to the >>>users to continue the call or switch over to some other >> >>networks, such >> >>>as mobile or PSTN. And also to tell the other party to please >>>subscribe to better broadband :-) >>> >>>What do you think? >>> >> >>My problem with this idea is that "domain" in the sense of >>SIP-servers is an application layer notion. >> >>DiffServ is a layer 3 issue. My layer 3 network does not >>neccessarily know which applications I run over them. >> >>If my ISP also acts as my SIP provider, then yes: one can >>link these two layers into one integrated QoS solution. AFAIK >>this is one of the aims of the IMS. One of the local Austrian >>ISPs uses this for his VoIP service: they use separate >>VLANs/QoS planes for their VoIP offering. >> >>My private playground is quite different: I use an Asterisk >>installation on a box (the same one I write this mail on) >>colocated at ISP A whereas my SIP-phone at home is connected >>via ISP B. The gateway to the PSTN is operated by a >>commercial provider who uses ISP C. >>If you add my ENUM nameservers, you get one more ISP into the picture. >>To top it off, I could add a SIP line to my office phone >>which would bring our office connectivity into the game were >>we basically run own multihomed network. >> >>I really don't know how to get seamless QoS in such a setting. >> >>(As you mentioned before: layer3 networks can't just trust >>each other's DiffServ settings.) >> >>/ol >>-- >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>______________________________________________________________ >>_______________ >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >> > > > _______________________________________________ > 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 Wed Jan 11 13:42:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewkvm-00081K-NJ; Wed, 11 Jan 2006 13:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewkvl-00081C-HV; Wed, 11 Jan 2006 13:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02763; Wed, 11 Jan 2006 13:41:25 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ewl2g-0003dE-KY; Wed, 11 Jan 2006 13:49:57 -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: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Wed, 11 Jan 2006 19:46:09 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C476A@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYW2apwuUX7HvisSN++NFgJzGXxcwABNBJ9 From: "Stastny Richard" To: "Tom-PT Taylor" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, Otmar Lendl , voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Again =20 Can anybody please explain to me what the term "visited" originating or = terminating network means on L5 =20 Both end-users are registered at their respective home networks (aka SIP servers). I always thought the SIP model is a trapezoid and=20 not a hexagon =20 QoS happens at or below L3 and should be negotiated by the end-user with his acces provider. =20 Richard ________________________________ Von: Tom-PT Taylor [mailto:taylor@nortel.com] Gesendet: Mi 11.01.2006 19:01 An: Michael Hammer (mhammer) Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org; = voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = Peering Policy The MSF is defining a scenario they hope to demonstrate, where media paths cross different domains from signalling. The signalling may be of the form visited originating network - home originating network - home terminating network - visited terminating network. This typical scenario is an obvious example of L5 transit. Then the media path is optimized to run directly between the visited networks, possibly by way of a different transit network offering QoS based on diffserv markings at the egress points of the visited networks. L5 and L3 are linked in the originating and terminating visited networks, but not in between. Michael Hammer (mhammer) wrote: > There MUST be some association of IP layer protocol elements to L5 > traffic needs, such as low delay, packet loss etc. If the L5 need is > real-time transmission, and that translates to a DSCP marking, then = the > IP network needs to meet that need one way or another or very simply = the > real-time service breaks. The alternative is that the peering always > must include both L5 and L3 and you get a half-step instead of = full-step > in evolution from PSTN to IP. > > Put another way, is it really necessary to have L5 transit networks? = If > you insist that L3 always be paired with L5 for real-time, that is = what > you get. > > Mike > > > >>-----Original Message----- >>From: owner-voipeer@lists.uoregon.edu >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>Sent: Monday, January 09, 2006 6:06 PM >>To: Henry Sinnreich >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>'Stastny Richard' >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >> >>On 2006/01/09 19:01, Henry Sinnreich wrote: >> >>>Otmar, >>> >>>You say: >>> >>> >>>>All current protocols regarding proxy and transport >> >>selection for SIP >> >>>>are only based on the domain. I don't want to diverge from >> >>that model. >> >>>What business has the broadband provider to mess with the >> >>user preferences? >> >>>Users and enterprises pay for a certain bandwidth and >> >>hopefully will >> >>>have the choice to pay extra for Diff Serv and that's the end of it. >> >>In an ideal world, yes. >> >> >>>If one domain has DiffServ and the other does not, it's up to the >>>users to continue the call or switch over to some other >> >>networks, such >> >>>as mobile or PSTN. And also to tell the other party to please >>>subscribe to better broadband :-) >>> >>>What do you think? >>> >> >>My problem with this idea is that "domain" in the sense of >>SIP-servers is an application layer notion. >> >>DiffServ is a layer 3 issue. My layer 3 network does not >>neccessarily know which applications I run over them. >> >>If my ISP also acts as my SIP provider, then yes: one can >>link these two layers into one integrated QoS solution. AFAIK >>this is one of the aims of the IMS. One of the local Austrian >>ISPs uses this for his VoIP service: they use separate >>VLANs/QoS planes for their VoIP offering. >> >>My private playground is quite different: I use an Asterisk >>installation on a box (the same one I write this mail on) >>colocated at ISP A whereas my SIP-phone at home is connected >>via ISP B. The gateway to the PSTN is operated by a >>commercial provider who uses ISP C. >>If you add my ENUM nameservers, you get one more ISP into the picture. >>To top it off, I could add a SIP line to my office phone >>which would bring our office connectivity into the game were >>we basically run own multihomed network. >> >>I really don't know how to get seamless QoS in such a setting. >> >>(As you mentioned before: layer3 networks can't just trust >>each other's DiffServ settings.) >> >>/ol >>-- >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>______________________________________________________________ >>_______________ >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >> > > > _______________________________________________ > 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 Wed Jan 11 21:02:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwrnV-0005aY-Hs; Wed, 11 Jan 2006 21:02:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwrnU-0005aB-6R; Wed, 11 Jan 2006 21:02:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06291; Wed, 11 Jan 2006 21:01:18 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwruR-0001DA-Td; Wed, 11 Jan 2006 21:09:54 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0C20Zi10775; Wed, 11 Jan 2006 18:00:35 -0800 (PST) Message-Id: <200601120200.k0C20Zi10775@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 11 Jan 2006 18:00:35 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 4355 on IANA Registration for Enumservices email, fax, mms, ems, and sms X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4355 Title: IANA Registration for Enumservices email, fax, mms, ems, and sms Author(s): R. Brandner, L. Conroy, R. Stastny Status: Standards Track Date: January 2006 Mailbox: rudolf.brandner@siemens.com, lwc@roke.co.uk, Richard.stastny@oefeg.at Pages: 16 Characters: 30218 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-msg-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4355.txt This document registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761. This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060111175902.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4355 --OtherAccess Content-Type: Message/External-body; name="rfc4355.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060111175902.RFC@RFC-EDITOR.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 12 16:19:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9qn-00057s-Kz; Thu, 12 Jan 2006 16:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9ql-00057E-I5 for enum@megatron.ietf.org; Thu, 12 Jan 2006 16:19:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24123 for ; Thu, 12 Jan 2006 16:17:53 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex9xv-0003Qj-Sx for enum@ietf.org; Thu, 12 Jan 2006 16:26:41 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0CLJaH2015254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Jan 2006 13:19:38 -0800 Message-ID: <43C6C7BF.6080800@shockey.us> Date: Thu, 12 Jan 2006 16:18:55 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: [Enum] Reminder IETF 65 Dallas X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Its coming so I'd like folks to start thinking about what the Agenda will be. We'll probably request the usual 2 or 2/12 hr slot. ############# January 16, Monday - Working Group and BOF scheduling begins February 13, Monday - Cutoff date for requests to schedule Working Group and BOF meetings at 17:00 ET (22:00 GMT) February 17, Friday - Preliminary agenda published for comment February 20, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (14:00 GMT) February 22, Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 09:00 ET (14:00 GMT) February 27, Monday - Final Working Group and BOF agenda to be published February 27, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 GMT) March 6, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 GMT) March 8, Wednesday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET (17:00 GMT) March 13, Monday - Working Group agendas due date by 12:00 ET (17:00 GMT), upload using IETF Meeting Materials Management Tool March 13, Monday - Registration cancellation cut-off at 17:00 ET (22:00 GMT) March 19-24, 2006 - 65th IETF Meeting in Dallas, TX, USA April 21, Friday - Proceedings submission cutoff date by 17:00 ET (21:00 GMT), upload using IETF Meeting Materials Management Tool. May 8, Monday - Proceedings submission corrections cutoff date by 17:00 ET (21:00 GMT), upload using IETF Meeting Materials Management Tool ** Times are in US Eastern Time and GMT ** -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 16:10:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWBp-000524-30; Fri, 13 Jan 2006 16:10:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWBn-00051b-Fc for enum@megatron.ietf.org; Fri, 13 Jan 2006 16:10:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10867 for ; Fri, 13 Jan 2006 16:09:04 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWJ8-0004nP-MF for enum@ietf.org; Fri, 13 Jan 2006 16:18:04 -0500 Received: from [10.31.32.200] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0DLAmiw019209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jan 2006 13:10:49 -0800 Message-ID: <43C8172E.60306@shockey.us> Date: Fri, 13 Jan 2006 16:10:06 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=UTF-8; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id k0DLAmiw019209 X-Spam-Score: 0.8 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Subject: [Enum] For your generous consideration: Fwd: I-D ACTION:draft-shockey-enum-cnam-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -------- Original Message -------- Subject: I-D ACTION:draft-shockey-enum-cnam-00.txt Date: Fri, 13 Jan 2006 15:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : IANA Registration for an Enumservice and =C2=93tel=C2=94 Parameter for Calling Name=20 Delivery(CNAM) Information Author(s) : R. Shockey, J. Livingood Filename : draft-shockey-enum-cnam-00.txt Pages : 10 Date : 2006-1-13 =09 This document registers the Enumservice =C2=93cnam=C2=94 and subtype = =C2=93tel=C2=94 using the URI scheme =C2=91tel:=C2=92, as per the IANA registration p= rocess defined in the ENUM specification, RFC 3761. In addition this document registers the parameter =C2=93cnam=C2=94 in= the IANA =C2=93tel=C2=94 Parameter Registry defined in RFCXXX. This data is u= sed to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the PSTN that may be displayed on VoIP or other Real-time Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shockey-enum-cnam-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=20 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 usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shockey-enum-cnam-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-shockey-enum-cnam-00.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 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 16:54:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWsF-0006Od-7Q; Fri, 13 Jan 2006 16:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWsD-0006F2-Q5 for enum@megatron.ietf.org; Fri, 13 Jan 2006 16:54:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14790 for ; Fri, 13 Jan 2006 16:52:52 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWzX-0006ki-4h for enum@ietf.org; Fri, 13 Jan 2006 17:01:53 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 13 Jan 2006 13:53:52 -0800 X-IronPort-AV: i="3.99,366,1131350400"; d="scan'208"; a="1766581617:sNHT4048220238" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0DLqsQd017684; Fri, 13 Jan 2006 13:53:52 -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.211); Fri, 13 Jan 2006 16:53:47 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 16:53:47 -0500 Message-ID: <43C8216A.4070203@cisco.com> Date: Fri, 13 Jan 2006 16:53:46 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.shockey@neustar.biz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 21:53:47.0183 (UTC) FILETIME=[D487D3F0:01C6188B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org Subject: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, I understand the rationale for providing cnam as something that can be obtained from enum. What I don't understand is the rationale for making it a tel uri parameter. Do you expect it to actually appear in a tel uri anywhere except the output of this particular enum lookup? I can mostly think of reasons why that would be a bad idea. I am guessing this is just a matter that the enum translations need to be URIs, so you needed some URI that could contain the name. And tel was one choice close at hand. It all seems pretty circular, with the entry for the number containing a tel uri for the same number, plus the cnam parameter. It also introduces an unnecessary bit of overhead because of this redundancy. Seems like there should be some other URx scheme that would be suitable to just contain the name. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 17:12:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXA2-0002WT-Ey; Fri, 13 Jan 2006 17:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXA1-0002WN-5e for enum@megatron.ietf.org; Fri, 13 Jan 2006 17:12:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16103 for ; Fri, 13 Jan 2006 17:11:18 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExXHO-0007R9-HR for enum@ietf.org; Fri, 13 Jan 2006 17:20:19 -0500 Received: from [10.31.13.200] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0DMD3Yl027666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2006 14:13:05 -0800 Message-ID: <43C825C4.5000409@shockey.us> Date: Fri, 13 Jan 2006 17:12:20 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <43C8216A.4070203@cisco.com> In-Reply-To: <43C8216A.4070203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Paul Kyzivat wrote: > Richard, > > I understand the rationale for providing cnam as something that can be > obtained from enum. What I don't understand is the rationale for making > it a tel uri parameter. Do you expect it to actually appear in a tel uri > anywhere except the output of this particular enum lookup? Probably not. I can mostly > think of reasons why that would be a bad idea. If you could elaborate on why the use of the tel URI's would be a bad idea that would be helpful ..we envisioned using SIP URI's as equally bad. > I am guessing this is just a matter that the enum translations need to > be URIs, so you needed some URI that could contain the name. And tel was > one choice close at hand. It was a practical choice yes. > It all seems pretty circular, with the entry for the number containing a > tel uri for the same number, plus the cnam parameter. It also introduces > an unnecessary bit of overhead because of this redundancy. > > Seems like there should be some other URx scheme that would be suitable > to just contain the name. Ideas? > > Paul > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 18:13:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExY6h-0001Ao-07; Fri, 13 Jan 2006 18:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExY6g-0001Ah-5p for enum@megatron.ietf.org; Fri, 13 Jan 2006 18:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19661 for ; Fri, 13 Jan 2006 18:11:54 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExYE1-00012E-91 for enum@ietf.org; Fri, 13 Jan 2006 18:20:56 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2006 18:13:05 -0500 X-IronPort-AV: i="3.99,367,1131339600"; d="scan'208"; a="80234171:sNHT32958336" 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 k0DNCb6b020306; Fri, 13 Jan 2006 18:13:02 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 18:12:57 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 18:12:53 -0500 Message-ID: <43C833F4.7080100@cisco.com> Date: Fri, 13 Jan 2006 18:12:52 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <43C8216A.4070203@cisco.com> <43C825C4.5000409@shockey.us> In-Reply-To: <43C825C4.5000409@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2006 23:12:53.0750 (UTC) FILETIME=[E1B47960:01C61896] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org [Igot bounced from the enum list on the original posting. Will see if this works.] comments inline. Paul Richard Shockey wrote: > Paul Kyzivat wrote: > >> Richard, >> >> I understand the rationale for providing cnam as something that can be >> obtained from enum. What I don't understand is the rationale for >> making it a tel uri parameter. > > Do you expect it to actually appear in a tel uri > >> anywhere except the output of this particular enum lookup? > > > Probably not. > > I can mostly > >> think of reasons why that would be a bad idea. > > > If you could elaborate on why the use of the tel URI's would be a bad > idea that would be helpful ..we envisioned using SIP URI's as equally bad. That isn't what I meant. What I meant was that using tel URIs *containing a cnam parameter* is a bad idea. For instance, consider the following: INVITE ... From: "George W. Bush" and further assume that the enum lookup, according to your proposal, of +12125551234 comes back with tel:+12125551234;cnam=janedoe Then what is the proper calling name to use??? In sip the display name already provides a, uri scheme independent, way to convey the name. Having a way to convey the name *in* certain kinds of URIs just makes things complicated. >> I am guessing this is just a matter that the enum translations need to >> be URIs, so you needed some URI that could contain the name. And tel >> was one choice close at hand. > > It was a practical choice yes. > >> It all seems pretty circular, with the entry for the number containing >> a tel uri for the same number, plus the cnam parameter. It also >> introduces an unnecessary bit of overhead because of this redundancy. >> >> Seems like there should be some other URx scheme that would be >> suitable to just contain the name. > > Ideas? Taking a quick scan of the IANA scheme registry, I came up with data: as in: data:,George%20W%20Bush That seems to do the job. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 18:28:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYLD-0006V9-SB; Fri, 13 Jan 2006 18:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYLC-0006V1-6o for enum@megatron.ietf.org; Fri, 13 Jan 2006 18:28:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21073 for ; Fri, 13 Jan 2006 18:26:54 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExYSZ-0001gc-6I for enum@ietf.org; Fri, 13 Jan 2006 18:35:57 -0500 Content-class: urn:content-classes:message Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Jan 2006 00:29:38 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Thread-Index: AcYYjyej9xoBiZovRs+zIGmHxfGvRwAChE3h From: "Stastny Richard" To: "Richard Shockey" , "Paul Kyzivat" X-Spam-Score: 0.8 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >Ideas? vcard? You may then display even more information if the B-terminal supports it Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Richard Shockey Gesendet: Fr 13.01.2006 23:12 An: Paul Kyzivat Cc: enum@ietf.org; richard.shockey@neustar.biz Betreff: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Paul Kyzivat wrote: > Richard, > > I understand the rationale for providing cnam as something that can be > obtained from enum. What I don't understand is the rationale for = making > it a tel uri parameter. Do you expect it to actually appear in a tel uri > anywhere except the output of this particular enum lookup? Probably not. I can mostly > think of reasons why that would be a bad idea. If you could elaborate on why the use of the tel URI's would be a bad idea that would be helpful ..we envisioned using SIP URI's as equally = bad. > I am guessing this is just a matter that the enum translations need to > be URIs, so you needed some URI that could contain the name. And tel = was > one choice close at hand. It was a practical choice yes. > It all seems pretty circular, with the entry for the number containing = a > tel uri for the same number, plus the cnam parameter. It also = introduces > an unnecessary bit of overhead because of this redundancy. > > Seems like there should be some other URx scheme that would be = suitable > to just contain the name. Ideas? > > Paul > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 21:01:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExajA-0007d0-K8; Fri, 13 Jan 2006 21:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exaj8-0007cJ-H2 for enum@megatron.ietf.org; Fri, 13 Jan 2006 21:01:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07094 for ; Fri, 13 Jan 2006 20:59:47 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExaqW-0000mx-5P for enum@ietf.org; Fri, 13 Jan 2006 21:08:50 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0E21Gqr020049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2006 18:01:24 -0800 Message-ID: <43C85B42.2010101@shockey.us> Date: Fri, 13 Jan 2006 21:00:34 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <43C8216A.4070203@cisco.com> <43C825C4.5000409@shockey.us> <43C833F4.7080100@cisco.com> In-Reply-To: <43C833F4.7080100@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id k0E21Gqr020049 X-Spam-Score: 0.8 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, mmaharishi@verisign.com, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Paul Kyzivat wrote: > [Igot bounced from the enum list on the original posting. Will see if=20 > this works.] It did. >> >> If you could elaborate on why the use of the tel URI's would be a bad=20 >> idea that would be helpful ..we envisioned using SIP URI's as equally=20 >> bad. >=20 > That isn't what I meant. What I meant was that using tel URIs=20 > *containing a cnam parameter* is a bad idea. For instance, consider the= =20 > following: >=20 > INVITE ... > From: "George W. Bush" >=20 > and further assume that the enum lookup, according to your proposal, of= =20 > +12125551234 comes back with tel:+12125551234;cnam=3Djanedoe >=20 > Then what is the proper calling name to use??? IMHO that which service provider policy determines to be the most=20 authoritative which means IMHO the ENUM CNAM query aka janedoe in your ca= se. That obviously does not mean that a proxy can then rewrite the From=20 field data only that it is not authoritative for CNAM display purposes. Out thinking in the next version of this draft is that only RFC 3325=20 P-Asserted Identity can be authoritative for Display Name transport=20 within SIP headers. >=20 > In sip the display name already provides a, uri scheme independent, way= =20 > to convey the name. Having a way to convey the name *in* certain kinds=20 > of URIs just makes things complicated. Yes but there is a substantial back channel argument that you need to=20 convey display name policy in a response in some manner. As some of my distinguished colleagues from Verisign Msr Kevin=20 McCandless and Manjul Maharishi have pointed out to me.... The PSTN defines several values for CNAM data in the event that there=20 are restrictions or that the data is unavaiable. These are defined as=20 "Reason for Absence of Name" [R3-50] in GR-1188 Consequently the following responses to a query from a well known=20 database may need to be reserved. Cnam=3Dp for =93Private=94 defined as the Calling Party does not wish to= have=20 their Display Name displayed. Cnam=3Do for =93not available/unaviable=94 defined as the well known data= base=20 has no data available for that particular E.164 number >=20 >>> I am guessing this is just a matter that the enum translations need=20 >>> to be URIs, so you needed some URI that could contain the name. And=20 >>> tel was one choice close at hand. >> >> It was a practical choice yes. >> >>> It all seems pretty circular, with the entry for the number=20 >>> containing a tel uri for the same number, plus the cnam parameter. It= =20 >>> also introduces an unnecessary bit of overhead because of this=20 >>> redundancy. >>> >>> Seems like there should be some other URx scheme that would be=20 >>> suitable to just contain the name. >> >> Ideas? >=20 > Taking a quick scan of the IANA scheme registry, I came up with data: a= s=20 > in: >=20 > data:,George%20W%20Bush >=20 > That seems to do the job. >=20 Yuck .. Well Ok you could say E2U+cnam:data data:,George%20W%20Bush or data:,p for privacy values .. right ? I'm not dismissing the idea out of hand. Lets make it clear your belief is that the fundamental concept of using=20 a 3761 Query to find CNAM data is sound. Your only issue is with what is=20 the appropriate URI returned. Correct? If the issue is what is the URI vehicle then .... ..again why would tel:=20 be so bad? Inquiring minds. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 21:10:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExasK-0005lg-NK; Fri, 13 Jan 2006 21:10:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExasI-0005kf-VB for enum@megatron.ietf.org; Fri, 13 Jan 2006 21:10:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08155 for ; Fri, 13 Jan 2006 21:09:16 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exazj-0001Fg-Ll for enum@ietf.org; Fri, 13 Jan 2006 21:18:20 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0E2Ag1R021256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2006 18:10:45 -0800 Message-ID: <43C85D78.5030108@shockey.us> Date: Fri, 13 Jan 2006 21:10:00 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Paul Kyzivat X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >> Ideas? > > vcard? Again let me make sure we are on the same page here the issue is NOT about using 3761 to find authoritative Display Name Information only what is the appropriate URI vehicle to carry that data. Then to your point the vcard would have to carry within it some policy flags as to which elements could be on not be displayed. > > You may then display even more information if the B-terminal supports it This is interesting since the vcard could also have a URI for html data as well. I've always wanted to see a "display" URI in SIP headers so that when I called the pizza parlor on the terminal you could have some cool html specials displayed instead of the crappy audio commercial you usually get stuck with. Well in any event this is exactly the kind of discussion I had hoped to kick off. > > Richard > > > > __ -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 13 21:54:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbYZ-0004m2-Mr; Fri, 13 Jan 2006 21:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbYX-0004lK-T5 for enum@megatron.ietf.org; Fri, 13 Jan 2006 21:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11010 for ; Fri, 13 Jan 2006 21:52:55 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exbfw-0002j4-S7 for enum@ietf.org; Fri, 13 Jan 2006 22:01:59 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0E2sbo8026061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2006 18:54:38 -0800 Message-ID: <43C867C7.4040800@shockey.us> Date: Fri, 13 Jan 2006 21:53:59 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> <43C85D78.5030108@shockey.us> In-Reply-To: <43C85D78.5030108@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , Paul Kyzivat Subject: [Enum] CNAM on further reflection X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > Stastny Richard wrote: >>> Ideas? >> >> vcard? > > > Again let me make sure we are on the same page here the issue is NOT > about using 3761 to find authoritative Display Name Information only > what is the appropriate URI vehicle to carry that data. > > > Then to your point the vcard would have to carry within it some policy > flags as to which elements could be on not be displayed. > >> >> You may then display even more information if the B-terminal supports it On further reflection the issue in your proposal then is how does the proxy know what the C/UA is capable of supporting in its display. Any URI proposed must at minimum support the 15 character ASCII in the ANSI specs. The called party's proxy then must be able to parse not only the policy of what can and cannot be displayed but also what the CU/A is capable of dealing with and not creating too much processing overhead for the called parties proxy. This IMHO was the biggest failure of most ENUM MMS routing schemes. Instead of using SIP SDP negotiation first to discover the display capabilities of the mobile CUA you sent the MMS object directly to the MMSC without knowing if the CUA could even display the object. This is clearly a vastly more interesting subject than classic Caller Display Name. So the issue at hand is then can a URI object be defined that A. is compatible with existing ANSI standards but is extensible enough to provide for Rich Display Name capabilities in the future? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jan 15 11:00:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAIn-0006Kd-H7; Sun, 15 Jan 2006 11:00:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAIm-0006IL-AI for enum@megatron.ietf.org; Sun, 15 Jan 2006 11:00:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24022 for ; Sun, 15 Jan 2006 10:58:10 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExtRJ-0000Gy-6Q for enum@ietf.org; Sat, 14 Jan 2006 17:00:01 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 0319B79033; Sat, 14 Jan 2006 21:51:28 +0000 (GMT) In-Reply-To: <43C867C7.4040800@shockey.us> References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> <43C85D78.5030108@shockey.us> <43C867C7.4040800@shockey.us> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] CNAM on further reflection Date: Sat, 14 Jan 2006 21:51:27 +0000 To: Richard Shockey X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , Paul Kyzivat X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Folks, it MUST be me. How the heck is a proxy supposed to know what display capabilities a recipient terminal that answers a call has (i.e. at that point)? Let me guess - yet another complex subscribe/notify/term cap scheme. Of course, if the caller has an ENUM entry, then problem solved. CNAM appears to be a mechanism for providing text via some other means (i.e. not under the control of the calling party). However, in both cases, why not pass an http: URI to that terminal (which DOES know its own display capabilities authoritatively) and leave it at that. The only policy is whether or not one passes the http: URI to the destination, or some means for the callee to get that URI. It may be that what you're really talking about is a gateway, NOT a proxy - this, however, is not at all clear. your confusedly (as we trialled a super-CLI with ENUM that in the UK), Lawrence On 14 Jan 2006, at 02:53, Richard Shockey wrote: > Richard Shockey wrote: >> Stastny Richard wrote: >>>> Ideas? >>> >>> vcard? >> Again let me make sure we are on the same page here the issue is >> NOT about using 3761 to find authoritative Display Name >> Information only what is the appropriate URI vehicle to carry that >> data. >> Then to your point the vcard would have to carry within it some >> policy flags as to which elements could be on not be displayed. >>> >>> You may then display even more information if the B-terminal >>> supports it > > On further reflection the issue in your proposal then is how does > the proxy know what the C/UA is capable of supporting in its display. > > Any URI proposed must at minimum support the 15 character ASCII in > the ANSI specs. The called party's proxy then must be able to parse > not only the policy of what can and cannot be displayed but also > what the CU/A is capable of dealing with and not creating too much > processing overhead for the called parties proxy. > > This IMHO was the biggest failure of most ENUM MMS routing schemes. > Instead of using SIP SDP negotiation first to discover the display > capabilities of the mobile CUA you sent the MMS object directly to > the MMSC without knowing if the CUA could even display the object. > > This is clearly a vastly more interesting subject than classic > Caller Display Name. > > So the issue at hand is then can a URI object be defined that A. is > compatible with existing ANSI standards but is extensible enough to > provide for Rich Display Name capabilities in the future? > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jan 15 11:43:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAy5-0002op-Hu; Sun, 15 Jan 2006 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAtO-0001Fp-Gu for enum@megatron.ietf.org; Sun, 15 Jan 2006 11:38:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15219 for ; Sun, 15 Jan 2006 10:41:48 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exzqi-0006zh-84 for enum@ietf.org; Sat, 14 Jan 2006 23:50:40 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Jan 2006 20:42:36 -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 k0F4gZWF009938 for ; Sat, 14 Jan 2006 20:42:35 -0800 (PST) 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.211); Sat, 14 Jan 2006 23:42:35 -0500 Received: from [10.86.240.231] ([10.86.240.231]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 14 Jan 2006 23:42:34 -0500 Message-ID: <43C9D2BA.7050308@cisco.com> Date: Sat, 14 Jan 2006 23:42:34 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2006 04:42:34.0892 (UTC) FILETIME=[1A98F4C0:01C6198E] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: 7bit Subject: [Enum] test X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org please ignore _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jan 15 18:44:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyHYA-0007a9-8b; Sun, 15 Jan 2006 18:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyHY8-0007Zz-9i for enum@megatron.ietf.org; Sun, 15 Jan 2006 18:44:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24568 for ; Sun, 15 Jan 2006 18:43:16 -0500 (EST) Received: from relay2.mail.twtelecom.net ([216.54.204.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyHft-0008Va-Q8 for enum@ietf.org; Sun, 15 Jan 2006 18:52:45 -0500 Received: from [172.28.172.140] (66-193-155-2.gen.twtelecom.net [66.193.155.2]) by relay2.mail.twtelecom.net (Postfix) with ESMTP id E981DC064; Sun, 15 Jan 2006 17:44:29 -0600 (CST) Message-ID: <43CADE5C.5060903@shockey.us> Date: Sun, 15 Jan 2006 18:44:28 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] CNAM on further reflection References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> <43C85D78.5030108@shockey.us> <43C867C7.4040800@shockey.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , Paul Kyzivat X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi Folks, > it MUST be me. > How the heck is a proxy supposed to know what display capabilities > a recipient terminal that answers a call has (i.e. at that point)? > Let me guess - yet another complex subscribe/notify/term cap scheme. > > Of course, if the caller has an ENUM entry, then problem solved. > > CNAM appears to be a mechanism for providing text via some other > means (i.e. not under the control of the calling party). Yes if the calling party is on the PSTN then they are not in direct control of the Caller Display name for that number. This is another of those wonderful NO TCAP ID we're so fond of. > > However, in both cases, why not pass an http: URI to that terminal > (which DOES know its own display capabilities authoritatively) and > leave it at that. HTTP and what HTML, XML? > > The only policy is whether or not one passes the http: URI to the > destination, or some means for the callee to get that URI. yes In the PSTN policy is maintained by the calling party as to whether the Display Name Information is passed to the called party. This BTW is not currently available in SIP. There has been a interesting discussion in SIPPING of how can a called party deal with anonymous calls. > > It may be that what you're really talking about is a gateway, NOT > a proxy - this, however, is not at all clear. yes sorry ... > > your confusedly (as we trialled a super-CLI with ENUM that in the UK), Really ? HTML based? > Lawrence > > On 14 Jan 2006, at 02:53, Richard Shockey wrote: >> Richard Shockey wrote: >>> Stastny Richard wrote: >>>>> Ideas? >>>> >>>> vcard? >>> Again let me make sure we are on the same page here the issue is NOT >>> about using 3761 to find authoritative Display Name Information only >>> what is the appropriate URI vehicle to carry that data. >>> Then to your point the vcard would have to carry within it some >>> policy flags as to which elements could be on not be displayed. >>>> >>>> You may then display even more information if the B-terminal >>>> supports it >> >> On further reflection the issue in your proposal then is how does the >> proxy know what the C/UA is capable of supporting in its display. >> >> Any URI proposed must at minimum support the 15 character ASCII in the >> ANSI specs. The called party's proxy then must be able to parse not >> only the policy of what can and cannot be displayed but also what the >> CU/A is capable of dealing with and not creating too much processing >> overhead for the called parties proxy. >> >> This IMHO was the biggest failure of most ENUM MMS routing schemes. >> Instead of using SIP SDP negotiation first to discover the display >> capabilities of the mobile CUA you sent the MMS object directly to the >> MMSC without knowing if the CUA could even display the object. >> >> This is clearly a vastly more interesting subject than classic Caller >> Display Name. >> >> So the issue at hand is then can a URI object be defined that A. is >> compatible with existing ANSI standards but is extensible enough to >> provide for Rich Display Name capabilities in the future? >> > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jan 15 20:39:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyJLJ-0008Kd-18; Sun, 15 Jan 2006 20:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyJLH-0008KP-7a for enum@megatron.ietf.org; Sun, 15 Jan 2006 20:39:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00584 for ; Sun, 15 Jan 2006 20:38:06 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyJT5-0003sz-Jh for enum@ietf.org; Sun, 15 Jan 2006 20:47:37 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 0188E7915F; Mon, 16 Jan 2006 01:38:53 +0000 (GMT) In-Reply-To: <43CADE5C.5060903@shockey.us> References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> <43C85D78.5030108@shockey.us> <43C867C7.4040800@shockey.us> <43CADE5C.5060903@shockey.us> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] CNAM on further reflection Date: Mon, 16 Jan 2006 01:38:51 +0000 To: Richard Shockey X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , Paul Kyzivat X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 15 Jan 2006, at 23:44, Richard Shockey wrote: > lconroy wrote: > > This is another of those wonderful NO TCAP ID we're so fond of. > >> However, in both cases, why not pass an http: URI to that terminal >> (which DOES know its own display capabilities authoritatively) and >> leave it at that. > > HTTP and what HTML, XML? The stored web page need not be very complex at all, and can be totally pre-generated - holding something like a img tag pointing to a picture on flikr, plus the caller's name (text) as the alt parameter. In our tests we cheated by having the web page title as the name of the caller, so for a REALLY bad hack, one could just look at the http: URI and extract the leaf file name without all that messy HTTP transaction stuff - ugly, but OK in our environment. For a "richer experience", I'm AssUMing that the recipient can do HTTP/HTML (i.e there is a web client or browser available). We knocked up a set of HTML pages in our tests, but XML would be fine. > >> The only policy is whether or not one passes the http: URI to the >> destination, or some means for the callee to get that URI. > > yes In the PSTN policy is maintained by the calling party as to > whether the Display Name Information is passed to the called party. > > This BTW is not currently available in SIP. > There has been a interesting discussion in SIPPING of how can a > called party deal with anonymous calls. There has indeed :). >> It may be that what you're really talking about is a gateway, NOT >> a proxy - this, however, is not at all clear. > yes sorry ... I thought so - in that case, maybe the file name hack will get wider use. The gateway can do an ENUM lookup, and find the text associated with that web entry. Hurl. >> your confusedly (as we trialled a super-CLI with ENUM that in the >> UK), > Really ? HTML based? Remember - we were using a stand-alone ENUM client that we hooked into a proprietary SIP program - the ENUM client was passed the From: with an incoming call, broke out the userpart, treated that as a telephone number, and did an ENUM lookup. If there was a web:http NAPTR in the queried ENUM zone, the ENUM client triggered an HTTP get and the page was displayed. (as mentioned, the early demo just displayed the leaf file name it found in the web NAPTR). All the code was Deeply Ugly, but it WAS a proof-of- concept. The key point is that a SIP program is not just a SIP UAS. SIP as a protocol can't hack it, but that doesn't mean that the program can't use other mechanisms - an ENUM client is pretty small, and firing up a browser is relatively trivial on Windoz and on real operating systems. [Hence the major warnings in TS 102.172 and in RFC 4002 :] Finally, as in all these things there's a user ENUM way (we tested it) and an Infrastructure ENUM way - I guess that PSTN is the latter, and if you went for an ENUM approach zones would not be accessible to the public. If callers DO have user ENUM, then the callee must not get any telephone number or they can do the lookup (even if the call comes in on the steam line). The effect that the CEO's mug shot appearing on a PC screen has on phone call answering technique is quite impressive. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 16 05:20:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyRTi-0006Cd-IG; Mon, 16 Jan 2006 05:20:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyRTg-0006CY-PC for enum@megatron.ietf.org; Mon, 16 Jan 2006 05:20:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00565 for ; Mon, 16 Jan 2006 05:19:20 -0500 (EST) Received: from [159.226.7.151] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EyRb2-0002uJ-Rr for enum@ietf.org; Mon, 16 Jan 2006 05:28:54 -0500 Received: (eyou send program); Mon, 16 Jan 2006 18:19:17 +0800 Message-ID: <337406757.16031@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.151 with SMTP; Mon, 16 Jan 2006 18:19:17 +0800 Message-ID: <01af01c61a86$4c3e9ef0$6306e29f@cnnicchenh> From: "chenhui" To: Date: Mon, 16 Jan 2006 18:19:13 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: =?gb2312?B?J831ILflJw==?= Subject: [Enum] The use of "service type" and "subtype" fieldsin ENUM record X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0300740951==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0300740951== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AC_01C61AC9.5A3BB950" This is a multi-part message in MIME format. ------=_NextPart_000_01AC_01C61AC9.5A3BB950 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBhcmUgY29uc2lkZXJpbmcgaG93IHRvIGltcGxlbWVudCBFTlVNIHJlc29s dmVyIGludG8gY3VycmVudCBjb21tdW5pY2F0aW9uIGNsaWVudHMgb3Igc2VydmljZSBzeXN0ZW1z Lg0KDQpOb3cgbW9zdCBvZiBjdXJyZW50IGNvbW11bmljYXRpb24gYXBwbGljYXRpb25zIGRvIG5v dCBzdXBwb3J0IEVOVU0gcmVzb2x1dGlvbiwgYWx0aG91Z2ggRU5VTSByZWNvcmRzIGNhbiBiZSBy ZXRpZXZlZCBieSAibnNsb29rdXAiIG9yICJkaWciIHF1ZXJ5ICJOQVBUUiIgcmVzb3VyY2UgcmVj b3JkcywgZGlmZmVyZW50IGNsaWVudHMgb3Igc2VydmljZSBzeXN0ZW1zIGNhbiBub3Qgc3VwcG9y dCBhbGwgcmV0dXJuZWQgcmVzdWx0cy4gVGhhdCBpcywgc29tZSByZWNvcmRzIGFyZSB1c2VsZXNz IGZvciBzcGVjaWZpYyBzZXJ2aWNlcy4gQWxzbywgdG9vIG1hbnkgdXNlbGVzcyByZWNvcmRzIHdp bGwgYWZmZWN0IHNlcnZpY2UgcGVyZm9ybWFuY2UuDQoNClVzaW5nIGZpbHRlciBpcyBhIHVzZWZ1 bCBtZXRob2QgdG8gcmVzb2x2ZSB0aGlzIHByb2JsZW0uIFRvIHVzZSAic2VydmljZSB0eXBlIiBh bmQgInN1YnR5cGUiLCBvbmx5IHZhbHVhYmxlIHJlc3VsdHMgY2FuIGJlIHJldHVybmVkLiANCg0K QnV0LCB3ZSBhcmUgbm90IHN1cmUgaG93IGNhbiBtYWtlIHRoZSBFTlVNIHJlc29sdmVyIHdvcmtz IG1vcmUgcmVhc29uYWJsZS4gQmVjYXVzZSBleGFjdCAic2VydmljZSB0eXBlIiBhbmQgInN1YnR5 cGUiIHdpbGwgZmlsdGVyIG1hbnkgcmVzdWx0cywgaW5jbHVkaW5nIG9mIG9sZCAic2VydmljZSB0 eXBlIi4gRm9yIGV4YW1wbGUsIHRoZXJlIGlzIGFuIEVOVU0gbnVtYmVyIGhhdmluZyBOQVBUUiBy ZWNvcmRzIG9mICJFMlUrZW1haWw6bWFpbHRvIiwgIkUyVStzbXM6bWFpbHRvIiwgYW5kICJFMlUr ZW1zOm1haWx0byIsIGlmIHRoZSBmaWx0ZXIgaXMgIkUyVStzbXM6bWFpbHRvIiwgaXQganVzdCBy ZXR1cm5zIE5BUFRSIHJlY29yZHMgd2l0aCBleGFjdCAic2VydmljZSB0eXBlIiBhbmQgInN1YnR5 cGUiLiBPciBpZiB0aGVyZSBpcyBubyBhbnkgY29ycmVzcG9uZGluZyByZWNvcmQsIHRoaXMgY2Fs bCB3aWxsIGJlIGZhaWxlZC4gVG9vIG11Y2ggZmFpbHVyZSB3aWxsIGFmZmVjdCBzZXJ2aWNlIHBl cmZvcm1hbmNlLg0KDQpBbm90aGVyIHdheSBpcyB0byBzdXBwb3J0IG5vdCBleGFjdCBmaWx0ZXIs IGxpa2Ugb25seSBieSAic3VidHlwZSIuIFRoZSBFTlVNIHJlc29sdmVyIGNhbiByZXR1cm4gYWxs IHJlbGF0aXZlIHJlY29yZHMgb2YgIkUyVStlbWFpbDptYWlsdG8iLCAiRTJVK3NtczptYWlsdG8i LCBhbmQgIkUyVStlbXM6bWFpbHRvIi4gQXBwbGljYXRpb24gY2xpZW50cyBvciBzZXJ2aWNlIHN5 c3RlbXMgY2FuIGF1dG9tYXRpY2FsbHkgY2hvb3NlIGl0cyBwZXJmZXJyZWQgcmVzdWx0cy4gSG93 ZXZlciwgdGhpcyBtYXkgaW50cm9kdWNlIG1vcmUgc2VydmljZSBkZWxheS4NCg0KV2hhdCBpcyB0 aGUgYmVzdCB3YXk/IERvIHlvdSBoYXZlIGFueSBzdWdnZXN0aW9uIG9uIHRoaXMgcHJvYmxlbT8N Cg0KQlRXLCBXZSBmaW5kIHRoYXQgSUFOQSBoYXMgcHVibGlzaGVkIEVOVU0gc2VydmljZXMgb24g SmFuIDEwdGgsMjAwNi4gVGhlIHdlYnBhZ2UgaXMgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy9lbnVtLXNlcnZpY2VzDQo= ------=_NextPart_000_01AC_01C61AC9.5A3BB950 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4MDIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkhpIGFsbCw8L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mz5X ZSBhcmUgY29uc2lkZXJpbmcgaG93IHRvIGltcGxlbWVudCBFTlVNIHJlc29sdmVyIA0KaW50byBj dXJyZW50IGNvbW11bmljYXRpb24gY2xpZW50cyBvciBzZXJ2aWNlIHN5c3RlbXMuPEJSPjxCUj5O b3cgbW9zdCBvZiANCmN1cnJlbnQgY29tbXVuaWNhdGlvbiBhcHBsaWNhdGlvbnMgZG8gbm90IHN1 cHBvcnQgRU5VTSByZXNvbHV0aW9uLCBhbHRob3VnaCBFTlVNIA0KcmVjb3JkcyBjYW4gYmUgcmV0 aWV2ZWQgYnkgIm5zbG9va3VwIiBvciAiZGlnIiBxdWVyeSAiTkFQVFIiIHJlc291cmNlIHJlY29y ZHMsIA0KZGlmZmVyZW50IGNsaWVudHMgb3Igc2VydmljZSBzeXN0ZW1zIGNhbiBub3Qgc3VwcG9y dCBhbGwgcmV0dXJuZWQgcmVzdWx0cy4gVGhhdCANCmlzLCBzb21lIHJlY29yZHMgYXJlIHVzZWxl c3MgZm9yIHNwZWNpZmljIHNlcnZpY2VzLiBBbHNvLCB0b28gbWFueSB1c2VsZXNzIA0KcmVjb3Jk cyB3aWxsIGFmZmVjdCBzZXJ2aWNlIHBlcmZvcm1hbmNlLjxCUj48QlI+VXNpbmcgZmlsdGVyIGlz IGEgdXNlZnVsIG1ldGhvZCANCnRvIHJlc29sdmUgdGhpcyBwcm9ibGVtLiBUbyB1c2UgInNlcnZp Y2UgdHlwZSIgYW5kICJzdWJ0eXBlIiwgb25seSB2YWx1YWJsZSANCnJlc3VsdHMgY2FuIGJlIHJl dHVybmVkLiA8L0ZPTlQ+PC9GT05UPjwvRElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEJSPjxGT05U IHNpemU9Mz5CdXQsIHdlIGFyZSBub3Qgc3VyZSBob3cgY2FuIG1ha2UgdGhlIEVOVU0gcmVzb2x2 ZXIgd29ya3MgDQptb3JlIHJlYXNvbmFibGUuIEJlY2F1c2UgZXhhY3QgInNlcnZpY2UgdHlwZSIg YW5kICJzdWJ0eXBlIiB3aWxsIGZpbHRlciBtYW55IA0KcmVzdWx0cywgaW5jbHVkaW5nIG9mIG9s ZCAic2VydmljZSB0eXBlIi4gRm9yIGV4YW1wbGUsIHRoZXJlIGlzIGFuIEVOVU0gbnVtYmVyIA0K aGF2aW5nIE5BUFRSIHJlY29yZHMgb2YgIkUyVStlbWFpbDptYWlsdG8iLCAiRTJVK3NtczptYWls dG8iLCBhbmQgDQoiRTJVK2VtczptYWlsdG8iLCBpZiB0aGUgZmlsdGVyIGlzICJFMlUrc21zOm1h aWx0byIsIGl0IGp1c3QgcmV0dXJucyBOQVBUUiANCnJlY29yZHMgd2l0aCBleGFjdCAic2Vydmlj ZSB0eXBlIiBhbmQgInN1YnR5cGUiLiBPciBpZiB0aGVyZSBpcyBubyBhbnkgDQpjb3JyZXNwb25k aW5nIHJlY29yZCwgdGhpcyBjYWxsIHdpbGwgYmUgZmFpbGVkLiBUb28gbXVjaCBmYWlsdXJlIHdp bGwgYWZmZWN0IA0Kc2VydmljZSBwZXJmb3JtYW5jZS48QlI+PEJSPkFub3RoZXIgd2F5IGlzIHRv IHN1cHBvcnQgbm90IGV4YWN0IGZpbHRlciwgbGlrZSANCm9ubHkgYnkgInN1YnR5cGUiLiBUaGUg RU5VTSByZXNvbHZlciBjYW4gcmV0dXJuIGFsbCByZWxhdGl2ZSByZWNvcmRzIG9mIA0KIkUyVStl bWFpbDptYWlsdG8iLCAiRTJVK3NtczptYWlsdG8iLCBhbmQgIkUyVStlbXM6bWFpbHRvIi4gQXBw bGljYXRpb24gY2xpZW50cyANCm9yIHNlcnZpY2Ugc3lzdGVtcyBjYW4gYXV0b21hdGljYWxseSBj aG9vc2UgaXRzIHBlcmZlcnJlZCByZXN1bHRzLiBIb3dldmVyLCB0aGlzIA0KbWF5IGludHJvZHVj ZSBtb3JlIHNlcnZpY2UgZGVsYXkuPEJSPjxCUj5XaGF0IGlzIHRoZSBiZXN0IHdheT8gRG8geW91 IGhhdmUgYW55IA0Kc3VnZ2VzdGlvbiBvbiB0aGlzIHByb2JsZW0/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEZP TlQgc2l6ZT0zPkJUVywgV2UgZmluZCB0aGF0IElBTkEgaGFzIHB1Ymxpc2hlZCZuYnNwO0VOVU0g DQpzZXJ2aWNlcyBvbiBKYW4gMTB0aCwyMDA2LiBUaGUgd2VicGFnZSBpcyA8L0ZPTlQ+PEEgDQpo cmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2VudW0tc2VydmljZXMiPjxGT05U IA0Kc2l6ZT0zPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZW51bS1zZXJ2aWNlczwv Rk9OVD48L0E+PEJSPjwvRk9OVD48L0RJVj48L0ZPTlQ+PEZPTlQgDQpzaXplPTI+PC9GT05UPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_01AC_01C61AC9.5A3BB950-- --===============0300740951== 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 --===============0300740951==-- From enum-bounces@ietf.org Mon Jan 16 06:37:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySfp-0000U8-MH; Mon, 16 Jan 2006 06:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySfm-0000RJ-Ke for enum@megatron.ietf.org; Mon, 16 Jan 2006 06:37:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05141 for ; Mon, 16 Jan 2006 06:35:54 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EySnh-00056l-1e for enum@ietf.org; Mon, 16 Jan 2006 06:45:29 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id A89E97921C; Mon, 16 Jan 2006 11:36:35 +0000 (GMT) In-Reply-To: <337406757.16031@cnnic.cn> References: <337406757.16031@cnnic.cn> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <010342E2-E165-470E-A8A0-8734A9B1CA37@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] The use of "service type" and "subtype" fieldsin ENUM record Date: Mon, 16 Jan 2006 11:36:34 +0000 To: chenhui X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG , =?UTF-8?B?546LIOWzsA==?= , Julian Rose X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi there, filter design depends on what you want to do. If the ENUM client is in a voice gateway, then it's fairly simple. NOTE: The following is just an "Implementation description". There are many ways one could process the NAPTRs - this is just the way WE did it in the U.K. trials. ---- In our systems, we used the "simple" pattern matching scheme mentioned in the "Experiences" draft to handle both RFC2916-style and RFC3261- style NAPTRs. [Tokenise services field on '+' character, expect (and remove) token "E2U", then process the rest]. If the client has communication systems that can provide a given teleservice (like voice) then that will be included in the filter - IMHO, this must be more flexible that an explicit string match against "voice:tel". We sub-tokenised each Enumservice on ':' character, "cheated" by creating a protocol sub-token for those Enumservices where it is implicit (H323, SIP) and re-wrote the RFC2916-style "ldap" and "mailto" services into "ldap:ldap" and "email:mailto", then pattern matched the generated list of "published services" against the capabilities of the client. Our clients could handle voice, so we matched against {voice:tel, sip:sip} (and voice:sip, as we were using TS 102 172 as well as the IETF/IANA services). For messaging, we matched against {{email:mailto, sms:mailto, mms:mailto, ems:mailto} and {sms:tel, mms:tel, ems:tel} and {fax:tel}}, which triggered one of three external communications programs - we did not have a program to support ifax:mailto, so just pattern matching against {*:mailto} would not work. For mobile clients with no email, SIP or fax support, we just matched against {voice:tel} and {sms:tel, mms:tel, ems:tel} to run the voice or text features of the phone. This worked well, but as you say it does require some processing to get NAPTRs and their services field into a single list of "all teleservices supported". The capabilities of the client devices was fixed so we could have "hard wired" the "local support" match lists - however, we wanted the user to be able to "switch off" sending an SMS/MMS/EMS message - this just consisted of removing those items {sms:tel,mms:tel, ems:tel} from the "locally supported" list. ---- To summarise the steps: - process the NAPTRs to generate one list of "published services" of the form : - match this against a list of "locally supported services", ordered according to the user's choice (e.g. voice first, then message using mailto, then SMS/MMS/EMS message, then fax) - generate a list of "successful" matches, with a pointer to the NAPTR(s) that held the service and to the local program that needs to be run. ---- As a final note - we kept a "winning list" rather than a single answer so that, if the first choice failed, the ENUM client could try the next without re-processing. This worked as the TTLs on the NAPTRs were a few minutes - if the NAPTRs had very short TTLs (e.g. 1 second), this would not have been valid. I hope this helps, Lawrence On 16 Jan 2006, at 10:19, chenhui wrote: > Hi all, > > We are considering how to implement ENUM resolver into current > communication clients or service systems. > > Now most of current communication applications do not support ENUM > resolution, although ENUM records can be retieved by "nslookup" or > "dig" query "NAPTR" resource records, different clients or service > systems can not support all returned results. That is, some records > are useless for specific services. Also, too many useless records > will affect service performance. > > Using filter is a useful method to resolve this problem. To use > "service type" and "subtype", only valuable results can be returned. > > But, we are not sure how can make the ENUM resolver works more > reasonable. Because exact "service type" and "subtype" will filter > many results, including of old "service type". For example, there > is an ENUM number having NAPTR records of "E2U+email:mailto", "E2U > +sms:mailto", and "E2U+ems:mailto", if the filter is "E2U > +sms:mailto", it just returns NAPTR records with exact "service > type" and "subtype". Or if there is no any corresponding record, > this call will be failed. Too much failure will affect service > performance. > > Another way is to support not exact filter, like only by "subtype". > The ENUM resolver can return all relative records of "E2U > +email:mailto", "E2U+sms:mailto", and "E2U+ems:mailto". Application > clients or service systems can automatically choose its perferred > results. However, this may introduce more service delay. > > What is the best way? Do you have any suggestion on this problem? > > BTW, We find that IANA has published ENUM services on Jan 10th, > 2006. The webpage is http://www.iana.org/assignments/enum-services > _______________________________________________ > 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 16 08:37:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUYF-0006zi-LQ; Mon, 16 Jan 2006 08:37:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUYD-0006z7-Db for enum@megatron.ietf.org; Mon, 16 Jan 2006 08:37:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13391 for ; Mon, 16 Jan 2006 08:36:12 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyUg5-0001PW-Tv for enum@ietf.org; Mon, 16 Jan 2006 08:45:49 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Jan 2006 08:37:25 -0500 X-IronPort-AV: i="3.99,371,1131339600"; d="scan'208"; a="80325809:sNHT34531608" 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 k0GDbJ6H010121; Mon, 16 Jan 2006 08:37:20 -0500 (EST) 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.211); Mon, 16 Jan 2006 08:37:19 -0500 Received: from [10.86.240.231] ([10.86.240.231]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 08:37:18 -0500 Message-ID: <43CBA18D.2040703@cisco.com> Date: Mon, 16 Jan 2006 08:37:17 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] CNAM on further reflection References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> <43C85D78.5030108@shockey.us> <43C867C7.4040800@shockey.us> <43CADE5C.5060903@shockey.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2006 13:37:18.0844 (UTC) FILETIME=[F88943C0:01C61AA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I can no longer figure out what this discussion is about - it seems to be all over the map. I see several distinct issues here: - sip caller identity issues: . what information in an incoming sip request does the recipient use as identifying info about the caller? . given that the identity info has been isolated from the request, what is displayed to the called user? - dealing with calls from PSTN to a sip environment: . how is the info from the pstn environment transformed into sip identity information? - dealing with calls from a sip environment to the PSTN . how is info from the sip environment transformed into info that causes the right thing to happen in the pstn environment I *thought* this CNAM proposal was just about transformations from the PSTN environment to the sip environment. The whole discussion of vcard seems to have strayed into sip caller identity issues. One think I would like ensure is that a callee in a sip environment not need to do something different when receiving a call from the PSTN than it does when receiving a native sip call. Paul lconroy wrote: > > On 15 Jan 2006, at 23:44, Richard Shockey wrote: > >> lconroy wrote: >> >> This is another of those wonderful NO TCAP ID we're so fond of. >> >>> However, in both cases, why not pass an http: URI to that terminal >>> (which DOES know its own display capabilities authoritatively) and >>> leave it at that. >> >> >> HTTP and what HTML, XML? > > > The stored web page need not be very complex at all, and can be totally > pre-generated - holding something like a img tag pointing to a picture > on flikr, plus the caller's name (text) as the alt parameter. > > In our tests we cheated by having the web page title as the name of the > caller, so for a REALLY bad hack, one could just look at the http: URI > and extract the leaf file name without all that messy HTTP transaction > stuff - ugly, but OK in our environment. For a "richer experience", I'm > AssUMing that the recipient can do HTTP/HTML (i.e there is a web client > or browser available). We knocked up a set of HTML pages in our tests, > but XML would be fine. > >> >>> The only policy is whether or not one passes the http: URI to the >>> destination, or some means for the callee to get that URI. >> >> >> yes In the PSTN policy is maintained by the calling party as to >> whether the Display Name Information is passed to the called party. >> >> This BTW is not currently available in SIP. >> There has been a interesting discussion in SIPPING of how can a >> called party deal with anonymous calls. > > > There has indeed :). > >>> It may be that what you're really talking about is a gateway, NOT >>> a proxy - this, however, is not at all clear. >> >> yes sorry ... > > > I thought so - in that case, maybe the file name hack will get wider use. > The gateway can do an ENUM lookup, and find the text associated with that > web entry. Hurl. > >>> your confusedly (as we trialled a super-CLI with ENUM that in the UK), >> >> Really ? HTML based? > > > Remember - we were using a stand-alone ENUM client that we hooked into > a proprietary SIP program - the ENUM client was passed the From: with an > incoming call, broke out the userpart, treated that as a telephone number, > and did an ENUM lookup. > > If there was a web:http NAPTR in the queried ENUM zone, the ENUM client > triggered an HTTP get and the page was displayed. > (as mentioned, the early demo just displayed the leaf file name it > found in > the web NAPTR). All the code was Deeply Ugly, but it WAS a proof-of- > concept. > > The key point is that a SIP program is not just a SIP UAS. SIP as a > protocol > can't hack it, but that doesn't mean that the program can't use other > mechanisms > - an ENUM client is pretty small, and firing up a browser is relatively > trivial > on Windoz and on real operating systems. > > [Hence the major warnings in TS 102.172 and in RFC 4002 :] > > Finally, as in all these things there's a user ENUM way (we tested it) > and an Infrastructure ENUM way - I guess that PSTN is the latter, and if > you went for an ENUM approach zones would not be accessible to the public. > > If callers DO have user ENUM, then the callee must not get any telephone > number or they can do the lookup (even if the call comes in on the steam > line). > > The effect that the CEO's mug shot appearing on a PC screen has on phone > call answering technique is quite impressive. > > all the best, > Lawrence > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 16 09:08:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyV2T-0007PK-DG; Mon, 16 Jan 2006 09:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyV2R-0007Nh-8Y for enum@megatron.ietf.org; Mon, 16 Jan 2006 09:08:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15354 for ; Mon, 16 Jan 2006 09:07:25 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyVAH-0002Yi-Nq for enum@ietf.org; Mon, 16 Jan 2006 09:17:03 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 29CD91A3BD; Mon, 16 Jan 2006 15:08:21 +0100 (CET) Date: Mon, 16 Jan 2006 15:08:21 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] CNAM on further reflection Message-ID: <20060116140820.GA27702@nic.at> References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> <43C85D78.5030108@shockey.us> <43C867C7.4040800@shockey.us> <43CADE5C.5060903@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2006/01/16 02:01, lconroy wrote: > > The effect that the CEO's mug shot appearing on a PC screen has on phone > call answering technique is quite impressive. > *If* this happens in normal User ENUM then the owner of the number can put any information into his ENUM domain, including wrong CNAM setting. Imagine the pranks one can play with this. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 17 01:46:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EykcL-00059E-Po; Tue, 17 Jan 2006 01:46:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EygD0-0008C4-0S for enum@megatron.ietf.org; Mon, 16 Jan 2006 21:04:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04118 for ; Mon, 16 Jan 2006 21:03:04 -0500 (EST) Received: from [159.226.7.151] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EygKX-0005jp-0a for enum@ietf.org; Mon, 16 Jan 2006 21:12:48 -0500 Received: (eyou send program); Tue, 17 Jan 2006 10:03:05 +0800 Message-ID: <337463385.18775@cnnic.cn> X-EYOUMAIL-SMTPAUTH: fengw@cnnic.cn Received: from unknown (HELO taurus) (159.226.6.125) by 159.226.7.151 with SMTP; Tue, 17 Jan 2006 10:03:05 +0800 Date: Tue, 17 Jan 2006 10:03:14 +0800 From: "Wang Feng" To: "lconroy" , "chenhui" Subject: Re: Re: [Enum] The use of "service type" and "subtype" fieldsin ENUM record X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Jan 2006 01:46:55 -0500 Cc: IETF ENUM WG , Julian Rose X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org hi Lawrence, What you have mentioned is a good method to resolve the asked question. Not to return all records, not to return exactly pattern matched records, just to get back useful or recognizable ("local supported") service records. It's really very flexible, fitting for different level need. Thanks for your opinion. Regards, Wang Feng fengw@cnnic.cn 2006-01-17 ======= 2006-01-16 11:36:00 ======= >Hi there, > filter design depends on what you want to do. If the ENUM client is >in a >voice gateway, then it's fairly simple. > >NOTE: The following is just an "Implementation description". There are >many ways one could process the NAPTRs - this is just the way WE did it >in the U.K. trials. > >---- > >In our systems, we used the "simple" pattern matching scheme >mentioned in >the "Experiences" draft to handle both RFC2916-style and RFC3261- >style NAPTRs. >[Tokenise services field on '+' character, expect (and remove) token >"E2U", >then process the rest]. > >If the client has communication systems that can provide a given >teleservice >(like voice) then that will be included in the filter - IMHO, this >must be >more flexible that an explicit string match against "voice:tel". > >We sub-tokenised each Enumservice on ':' character, "cheated" by >creating a >protocol sub-token for those Enumservices where it is implicit (H323, >SIP) and >re-wrote the RFC2916-style "ldap" and "mailto" services into >"ldap:ldap" and >"email:mailto", then pattern matched the generated list of "published >services" >against the capabilities of the client. > >Our clients could handle voice, so we matched against {voice:tel, >sip:sip} >(and voice:sip, as we were using TS 102 172 as well as the IETF/IANA >services). > >For messaging, we matched against {{email:mailto, sms:mailto, >mms:mailto, >ems:mailto} and {sms:tel, mms:tel, ems:tel} and {fax:tel}}, which >triggered >one of three external communications programs - we did not have a >program >to support ifax:mailto, so just pattern matching against {*:mailto} >would >not work. >For mobile clients with no email, SIP or fax support, we just matched >against >{voice:tel} and {sms:tel, mms:tel, ems:tel} to run the voice or text >features >of the phone. > >This worked well, but as you say it does require some processing to >get NAPTRs >and their services field into a single list of "all teleservices >supported". >The capabilities of the client devices was fixed so we could have >"hard wired" >the "local support" match lists - however, we wanted the user to be >able to >"switch off" sending an SMS/MMS/EMS message - this just consisted of >removing >those items {sms:tel,mms:tel, ems:tel} from the "locally supported" >list. >---- >To summarise the steps: >- process the NAPTRs to generate one list of "published services" of >the form > : > >- match this against a list of "locally supported services", ordered >according > to the user's choice (e.g. voice first, then message using >mailto, then > SMS/MMS/EMS message, then fax) > >- generate a list of "successful" matches, with a pointer to the >NAPTR(s) > that held the service and to the local program that needs to be run. >---- >As a final note - we kept a "winning list" rather than a single >answer so >that, if the first choice failed, the ENUM client could try the next >without >re-processing. This worked as the TTLs on the NAPTRs were a few minutes >- if the NAPTRs had very short TTLs (e.g. 1 second), this would not have >been valid. > >I hope this helps, > Lawrence > > >On 16 Jan 2006, at 10:19, chenhui wrote: >> Hi all, >> >> We are considering how to implement ENUM resolver into current >> communication clients or service systems. >> >> Now most of current communication applications do not support ENUM >> resolution, although ENUM records can be retieved by "nslookup" or >> "dig" query "NAPTR" resource records, different clients or service >> systems can not support all returned results. That is, some records >> are useless for specific services. Also, too many useless records >> will affect service performance. >> >> Using filter is a useful method to resolve this problem. To use >> "service type" and "subtype", only valuable results can be returned. >> >> But, we are not sure how can make the ENUM resolver works more >> reasonable. Because exact "service type" and "subtype" will filter >> many results, including of old "service type". For example, there >> is an ENUM number having NAPTR records of "E2U+email:mailto", "E2U >> +sms:mailto", and "E2U+ems:mailto", if the filter is "E2U >> +sms:mailto", it just returns NAPTR records with exact "service >> type" and "subtype". Or if there is no any corresponding record, >> this call will be failed. Too much failure will affect service >> performance. >> >> Another way is to support not exact filter, like only by "subtype". >> The ENUM resolver can return all relative records of "E2U >> +email:mailto", "E2U+sms:mailto", and "E2U+ems:mailto". Application >> clients or service systems can automatically choose its perferred >> results. However, this may introduce more service delay. >> >> What is the best way? Do you have any suggestion on this problem? >> >> BTW, We find that IANA has published ENUM services on Jan 10th, >> 2006. The webpage is http://www.iana.org/assignments/enum-services >> _______________________________________________ >> 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 17 12:08:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuK7-0008Mg-Jc; Tue, 17 Jan 2006 12:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuK5-0008MS-J7 for enum@megatron.ietf.org; Tue, 17 Jan 2006 12:08:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01151 for ; Tue, 17 Jan 2006 12:07:20 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyuSE-0007c3-Nr for enum@ietf.org; Tue, 17 Jan 2006 12:17:12 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2006 09:08:34 -0800 X-IronPort-AV: i="3.99,377,1131350400"; d="scan'208"; a="1767327878:sNHT25989778" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0HH7tkD001136 for ; Tue, 17 Jan 2006 09:08: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.211); Tue, 17 Jan 2006 12:08:31 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 12:08:31 -0500 Message-ID: <43CD248E.1000501@cisco.com> Date: Tue, 17 Jan 2006 12:08:30 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2006 17:08:31.0493 (UTC) FILETIME=[A46FCB50:01C61B88] X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: 7bit Subject: [Enum] test X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org please ignore _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 18 15:50:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKGB-00042t-4F; Wed, 18 Jan 2006 15:50:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKFp-0003vV-GP; Wed, 18 Jan 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22329; Wed, 18 Jan 2006 15:48:37 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzKOB-0000ye-TE; Wed, 18 Jan 2006 15:58:44 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EzKFm-0007JF-6X; Wed, 18 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 18 Jan 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-pstn-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for an Enumservice Containing PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-03.txt Pages : 12 Date : 2006-1-18 This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype " sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-pstn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-pstn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-18133238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-pstn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-pstn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-18133238.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 19 13:40:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzehY-0006z6-A4; Thu, 19 Jan 2006 13:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzehW-0006wx-Pt for enum@megatron.ietf.org; Thu, 19 Jan 2006 13:40:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15150 for ; Thu, 19 Jan 2006 13:38:36 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezeq5-0000wk-UA for enum@ietf.org; Thu, 19 Jan 2006 13:48:55 -0500 Received: from [10.31.13.193] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0JIeHWp002732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jan 2006 10:40:18 -0800 Message-ID: <43CFDCE8.1040208@shockey.us> Date: Thu, 19 Jan 2006 13:39:36 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [Enum] Desire to go to WGLC on - I-D ACTION:draft-ietf-enum-pstn-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The authors are pretty confident that the draft we have now submitted is pretty much complete and we have had it reviewed by the WG Secretary to check on NITS etc. I'd like to ask the list to review our draft one last time and in the absence of comments we'll request WGLC. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Telephone Number Mapping Working Group of the IETF. > > Title : IANA Registration for an Enumservice Containing PSTN Signaling Information > Author(s) : J. Livingood, R. Shockey > Filename : draft-ietf-enum-pstn-03.txt > Pages : 12 > Date : 2006-1-18 > > This document registers the Enumservice type "pstn" and subtype "tel" > using the URI scheme 'tel', as well as the subtype " sip" using the > URI scheme 'sip' as per the IANA registration process defined in the > ENUM specification, RFC 3761. This Enumservice is used to facilitate > the routing of telephone calls in those countries where Number > Portability exists. > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 23 09:01:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Fm-0003gP-Nj; Mon, 23 Jan 2006 09:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Fj-0003fj-4P; Mon, 23 Jan 2006 09:01:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19916; Mon, 23 Jan 2006 08:59:31 -0500 (EST) Received: from [58.82.168.48] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F12Oz-0006bI-CK; Mon, 23 Jan 2006 09:10:42 -0500 X-Originating-IP: 143.54.169.163 by smtp.58.82.168.48; Tue, 24 Jan 2006 04:09:43 -0800 Message-ID: From: "Teddy Dolan" To: chair@ietf.org, dccp@ietf.org, dccp-admin@ietf.org, dhcwg-admin@ietf.org, dhcwg-request@ietf.org, dinaras@ietf.org, disman@ietf.org, entmib@ietf.org, enum@ietf.org, iab@ietf.org, ieprep@ietf.org, iesg@ietf.org Date: Tue, 24 Jan 2006 04:09:43 -0800 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.3 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] RE: We approved yours loan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Teddy Dolan List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear Homeowner, http://yourforless.com/?ra=3Dciel You have been approved for a $402,000 house loan at a 3.45% Fixed R.ate. This offer is being presented to you right now!. Your credit history is in= no way a factor. We have 99% approval rate. To take advantage of this Limited Time Opportunity, please take a minute and confirm your curiosity or intention to accept thi= s loan, at the following web-site: http://yourforless.com/?ra=3Dciel Best Regards Marcy DeMarcy http://yourforless.com/lit.html absinthe _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 23 13:35:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F16XY-0003ww-GX; Mon, 23 Jan 2006 13:35:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F16XX-0003wr-B4 for enum@megatron.ietf.org; Mon, 23 Jan 2006 13:35:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08556 for ; Mon, 23 Jan 2006 13:34:12 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F16gu-0007xc-9F for enum@ietf.org; Mon, 23 Jan 2006 13:45:25 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0NIZhWo005504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2006 10:35:47 -0800 Message-ID: <43D521D5.1040008@shockey.us> Date: Mon, 23 Jan 2006 13:35:01 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , Allison Mankin Subject: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Containing PSTN Signalling Information X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Title : IANA Registration for an Enumservice Containing PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-03.txt Pages : 12 Date : 2006-1-18 This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype " sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-03.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 for 2 weeks or so from today Jan 23 until at least Feb 6 though we can modify that if new issues come up. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 23 17:29:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ABV-0008LE-BN; Mon, 23 Jan 2006 17:29:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ABT-0008Jx-Nw for enum@megatron.ietf.org; Mon, 23 Jan 2006 17:29:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28981 for ; Mon, 23 Jan 2006 17:27:40 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AKq-0000gq-1D for enum@ietf.org; Mon, 23 Jan 2006 17:38:54 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k0NMSpF08999; Mon, 23 Jan 2006 17:28:52 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006012317285430699 ; Mon, 23 Jan 2006 17:28:54 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Jan 2006 17:28:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Date: Mon, 23 Jan 2006 17:28:54 -0500 Message-ID: Thread-Topic: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Thread-Index: AcYYrqxxu+qgH0cERVSvkcL1W+WENgHr8yDQ From: "Mowafy, Hala" To: "Richard Shockey" X-OriginalArrivalTime: 23 Jan 2006 22:28:55.0077 (UTC) FILETIME=[65106D50:01C6206C] X-Spam-Score: 0.8 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, A few comments and a few questions, please.=20 1) Your draft touches on the Privacy Considerations (Sec 11) at a very high level. I don't need to reiterate what others have mentioned about the different rules and jurisdictions but I do have to add that BEFORE caller ID and CNAM were allowed to be delivered in the PSTN, all the signaling elements and features necessary to preserve the privacy status from the caller to the called party had to be worked out. I understand that was all mandated by the FCC and we're not expecting ENUM to be regulated, but I assure you this topic is extremely sensitive I don't expect any "exceptions" for ENUM or other. And I'm sure we all agree ENUM does not need any negative exposure. 2) You suggest a value of cnam=3Dp or cnam=3Do in that database. How do you know from call to call? Today, I can make all my calls and my number would appear (public status) to the called party. Then, one day I have to call you and I don't necessarily want my number or name to be displayed to you, I have the option to change that status to "private" for just that call. I just have to dial a specific code that toggles the status to private for a single call. These codes are heavily used by law enforcement agencies and women's shelters, etc. to block the delivery of the number+name. The codes alter the signaled info in ISUP and the called party's serving switch has to act accordingly. =20 =20 3) You refer to a new database for this cnam service. Sometimes as "a well-known database source" and other times as just an "ENUM database". Could you elaborate on what is being envisioned? =20 Is it a separate database dedicated to Name storage and queries (sort of like the name databases in the PSTN), or are you proposing this as an addition to the ENUM routing databases (Tier 1B or Tier 2)?? 4) In section 10, there is mention of this "not qualitatively different from publication in a telephone directory.." I am not sure if you are implying that Carrier ENUM will implement something similar to pub and non-pub markings. But even if that happens, it is important to understand that being non-pub does not mean a "private" status or vice versa. Two completely unrelated indicators that serve different purposes. =20 =20 Maybe if you help me understand the ultimate goal/vision, I could appreciate the I-D a bit more. What I mean is I view ENUM as being there for routing purposes. So, how does cnam play a role in ENUM routing? In general, it seems insufficient to consider distribution/access/privacy outside the scope of the document when those ARE the essential elements of Caller ID/CNAM delivery. =20 Thanks in advance Hala =20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, January 13, 2006 9:01 PM To: Paul Kyzivat Cc: enum@ietf.org; mmaharishi@verisign.com; McCandless, Kevin; richard.shockey@neustar.biz Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Paul Kyzivat wrote: > [Igot bounced from the enum list on the original posting. Will see if > this works.] It did. >> >> If you could elaborate on why the use of the tel URI's would be a bad >> idea that would be helpful ..we envisioned using SIP URI's as equally >> bad. >=20 > That isn't what I meant. What I meant was that using tel URIs > *containing a cnam parameter* is a bad idea. For instance, consider the=20 > following: >=20 > INVITE ... > From: "George W. Bush" >=20 > and further assume that the enum lookup, according to your proposal,=20 > of > +12125551234 comes back with tel:+12125551234;cnam=3Djanedoe >=20 > Then what is the proper calling name to use??? IMHO that which service provider policy determines to be the most=20 authoritative which means IMHO the ENUM CNAM query aka janedoe in your case. That obviously does not mean that a proxy can then rewrite the From=20 field data only that it is not authoritative for CNAM display purposes. Out thinking in the next version of this draft is that only RFC 3325=20 P-Asserted Identity can be authoritative for Display Name transport=20 within SIP headers. >=20 > In sip the display name already provides a, uri scheme independent,=20 > way > to convey the name. Having a way to convey the name *in* certain kinds > of URIs just makes things complicated. Yes but there is a substantial back channel argument that you need to=20 convey display name policy in a response in some manner. As some of my distinguished colleagues from Verisign Msr Kevin=20 McCandless and Manjul Maharishi have pointed out to me.... The PSTN defines several values for CNAM data in the event that there=20 are restrictions or that the data is unavaiable. These are defined as=20 "Reason for Absence of Name" [R3-50] in GR-1188 Consequently the following responses to a query from a well known=20 database may need to be reserved. Cnam=3Dp for "Private" defined as the Calling Party does not wish to = have their Display Name displayed. Cnam=3Do for "not available/unaviable" defined as the well known = database=20 has no data available for that particular E.164 number >=20 >>> I am guessing this is just a matter that the enum translations need >>> to be URIs, so you needed some URI that could contain the name. And=20 >>> tel was one choice close at hand. >> >> It was a practical choice yes. >> >>> It all seems pretty circular, with the entry for the number >>> containing a tel uri for the same number, plus the cnam parameter. It=20 >>> also introduces an unnecessary bit of overhead because of this=20 >>> redundancy. >>> >>> Seems like there should be some other URx scheme that would be >>> suitable to just contain the name. >> >> Ideas? >=20 > Taking a quick scan of the IANA scheme registry, I came up with data:=20 > as > in: >=20 > data:,George%20W%20Bush >=20 > That seems to do the job. >=20 Yuck .. Well Ok you could say E2U+cnam:data data:,George%20W%20Bush or data:,p for privacy values .. right ? I'm not dismissing the idea out of hand. Lets make it clear your belief is that the fundamental concept of using=20 a 3761 Query to find CNAM data is sound. Your only issue is with what is the appropriate URI returned. Correct? If the issue is what is the URI vehicle then .... ..again why would tel: be so bad? Inquiring minds. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 23 18:29:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1B8G-0008NO-5R; Mon, 23 Jan 2006 18:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1B8E-0008NG-GI for enum@megatron.ietf.org; Mon, 23 Jan 2006 18:29:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03998 for ; Mon, 23 Jan 2006 18:28:24 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1BHd-0002yp-64 for enum@ietf.org; Mon, 23 Jan 2006 18:39:40 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0NNUAEM007055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2006 15:30:11 -0800 Message-ID: <43D566D7.3040008@shockey.us> Date: Mon, 23 Jan 2006 18:29:27 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Mowafy, Hala" Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Mowafy, Hala wrote: > Richard, > A few comments and a few questions, please. > > 1) Your draft touches on the Privacy Considerations (Sec 11) at a very > high level. I don't need to reiterate what others have mentioned about > the different rules and jurisdictions but I do have to add that BEFORE > caller ID and CNAM were allowed to be delivered in the PSTN, all the > signaling elements and features necessary to preserve the privacy status > from the caller to the called party had to be worked out. I understand > that was all mandated by the FCC and we're not expecting ENUM to be > regulated, but I assure you this topic is extremely sensitive I don't > expect any "exceptions" for ENUM or other. And I'm sure we all agree > ENUM does not need any negative exposure. Sure ... your concerns are well placed and I know well intentioned. This is a 00 draft and we certainly want to clarify the underlying privacy issues in later versions. > > 2) You suggest a value of cnam=p or cnam=o in that database. > How do you know from call to call? Well the general discussion of privacy in SIP is a ongoing topic in SIPPING http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-privacy-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-00.txt The issue in this draftis not to define how SIP deals with privacy only how a proxy could retrieve Caller Display Name information if it was clear that such information were allowed. To answer your first question there is an assumption that the well known database has information and a response needs to be given on a per query basis. A. what is the CNAM data if available. B. in the case of cnam=o that no data exists or C. there is a overriding privacy flag on that data. On a call by call basis if the SIP call is "anonymous" in the From: field then there is a presumption that the Called party's proxy SHOULD NOT attempt a query to discover the CNAM data. > Today, I can make all my calls and my number would appear (public > status) to the called party. Then, one day I have to call you and I > don't necessarily want my number or name to be displayed to you, I have > the option to change that status to "private" for just that call. I > just have to dial a specific code that toggles the status to private for > a single call. Right if such a code is toggled by the Calling party's CUA it is assumed that Calling Party proxy would insert "anonymous" in the From: field of the INVITE and the Called Party's proxy would respect that not attempt a query. > These codes are heavily used by law enforcement agencies and women's > shelters, etc. to block the delivery of the number+name. The codes alter > the signaled info in ISUP and the called party's serving switch has to > act accordingly. > Understood .. as above demonstrates there are mechanisms in SIP that can implement this requirement. > 3) You refer to a new database for this cnam service. Sometimes as "a > well-known database source" and other times as just an "ENUM database". > Could you elaborate on what is being envisioned? Good point. In future versions we will use only one term .."well-known database". What this database is, who operates it and the discovery mechanism for learning the domain of the "well-known database" is out of scope for this document. > Is it a separate database dedicated to Name storage and queries (sort > of like the name databases in the PSTN), or are you proposing this as an > addition to the ENUM routing databases (Tier 1B or Tier 2)?? Completely out side the scope of the ENUM routing databases. What we are doing here is simply proposing the use 3761 technology for query response of another class of PSTN data. We do not specify a domain for the rewrite rule. > > 4) In section 10, there is mention of this "not qualitatively different > from publication in a telephone directory.." I am not sure if you are > implying that Carrier ENUM will implement something similar to pub and > non-pub markings. But even if that happens, it is important to > understand that being non-pub does not mean a "private" status or vice > versa. Two completely unrelated indicators that serve different > purposes. This is unclear. We'll strive to make this clearer in the next version. > > Maybe if you help me understand the ultimate goal/vision, I could > appreciate the I-D a bit more. Eliminate or reduce the need for another class of TCAP query. Access to this data on the SS7 network is cumbersome and expensive. There is a strong desire on the part of some service providers to migrate to a all IP query response system. What I mean is I view ENUM as being there for routing purposes. Yes ENUM as it is currently deployed is principally for routing information however the underlying technology can be used for essentially number translations to find databases of information associated with that number. We view CNAM is just another form of data associated with a TN. So, how does cnam play a role in ENUM routing? It doesnt. In general, it seems insufficient to consider > distribution/access/privacy outside the scope of the document when those > ARE the essential elements of Caller ID/CNAM delivery. Your points are well taken. We can certainly attempt to clarify the distribution/access/privacy issues but the actual usage of of the data is principally a SIP issue. We do make it clear that these "well known databases" are assumed to be private in nature. In addition SIP is now dealing with the opposite privacy case case by which the Called Party may elect to reject any form of "anonymous" communication and signal the Calling Party that it rejects such calls. I suspect this feature will meet with wide spread adoption. > > Thanks in advance > Hala > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Friday, January 13, 2006 9:01 PM > To: Paul Kyzivat > Cc: enum@ietf.org; mmaharishi@verisign.com; McCandless, Kevin; > richard.shockey@neustar.biz > Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt > > > Paul Kyzivat wrote: >> [Igot bounced from the enum list on the original posting. Will see if >> this works.] > > It did. > > >>> If you could elaborate on why the use of the tel URI's would be a bad >>> idea that would be helpful ..we envisioned using SIP URI's as equally > >>> bad. >> That isn't what I meant. What I meant was that using tel URIs >> *containing a cnam parameter* is a bad idea. For instance, consider > the >> following: >> >> INVITE ... >> From: "George W. Bush" >> >> and further assume that the enum lookup, according to your proposal, >> of >> +12125551234 comes back with tel:+12125551234;cnam=janedoe >> >> Then what is the proper calling name to use??? > > IMHO that which service provider policy determines to be the most > authoritative which means IMHO the ENUM CNAM query aka janedoe in your > case. > > That obviously does not mean that a proxy can then rewrite the From > field data only that it is not authoritative for CNAM display purposes. > > Out thinking in the next version of this draft is that only RFC 3325 > P-Asserted Identity can be authoritative for Display Name transport > within SIP headers. > > >> In sip the display name already provides a, uri scheme independent, >> way >> to convey the name. Having a way to convey the name *in* certain kinds > >> of URIs just makes things complicated. > > Yes but there is a substantial back channel argument that you need to > convey display name policy in a response in some manner. > > As some of my distinguished colleagues from Verisign Msr Kevin > McCandless and Manjul Maharishi have pointed out to me.... > > The PSTN defines several values for CNAM data in the event that there > are restrictions or that the data is unavaiable. These are defined as > "Reason for Absence of Name" [R3-50] in GR-1188 > > Consequently the following responses to a query from a well known > database may need to be reserved. > > Cnam=p for "Private" defined as the Calling Party does not wish to have > > their Display Name displayed. > > Cnam=o for "not available/unaviable" defined as the well known database > has no data available for that particular E.164 number > > > >>>> I am guessing this is just a matter that the enum translations need >>>> to be URIs, so you needed some URI that could contain the name. And >>>> tel was one choice close at hand. >>> It was a practical choice yes. >>> >>>> It all seems pretty circular, with the entry for the number >>>> containing a tel uri for the same number, plus the cnam parameter. > It >>>> also introduces an unnecessary bit of overhead because of this >>>> redundancy. >>>> >>>> Seems like there should be some other URx scheme that would be >>>> suitable to just contain the name. >>> Ideas? >> Taking a quick scan of the IANA scheme registry, I came up with data: >> as >> in: >> >> data:,George%20W%20Bush >> >> That seems to do the job. >> > > Yuck .. > > Well Ok you could say E2U+cnam:data > > data:,George%20W%20Bush > > or > > data:,p > > for privacy values .. right ? > > I'm not dismissing the idea out of hand. > > Lets make it clear your belief is that the fundamental concept of using > a 3761 Query to find CNAM data is sound. Your only issue is with what is > > the appropriate URI returned. Correct? > > If the issue is what is the URI vehicle then .... ..again why would tel: > > be so bad? > > > Inquiring minds. > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 25 12:43:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ofq-0002dp-Gp; Wed, 25 Jan 2006 12:43:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ofo-0002c4-Ns for enum@megatron.ietf.org; Wed, 25 Jan 2006 12:43:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04518 for ; Wed, 25 Jan 2006 12:41:35 -0500 (EST) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1opS-0001mQ-Oh for enum@ietf.org; Wed, 25 Jan 2006 12:53:12 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k0PHgdq17402; Wed, 25 Jan 2006 12:42:39 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006012512424223036 ; Wed, 25 Jan 2006 12:42:42 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Jan 2006 12: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] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Date: Wed, 25 Jan 2006 12:42:42 -0500 Message-ID: Thread-Topic: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Thread-Index: AcYgdPT8PpugXVLwSx22RssqgISsowBYIfrQ From: "Mowafy, Hala" To: X-OriginalArrivalTime: 25 Jan 2006 17:42:42.0907 (UTC) FILETIME=[BE7ABAB0:01C621D6] X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Point well taken about TCAP. And that's why most if not all of the existing, TCAP-based Name databases have expanded their access to IP protocols, such as LDAP, SIP, etc.. Hala -----Original Message----- From: richard@shockey.us [mailto:richard@shockey.us]=20 Sent: Monday, January 23, 2006 6:29 PM To: Mowafy, Hala Cc: enum@ietf.org; McCandless, Kevin; richard.shockey@neustar.biz Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Mowafy, Hala wrote: =20 > Maybe if you help me understand the ultimate goal/vision, I could=20 > appreciate the I-D a bit more. Eliminate or reduce the need for another class of TCAP query. Access to=20 this data on the SS7 network is cumbersome and expensive. There is a=20 strong desire on the part of some service providers to migrate to a all=20 IP query response system. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 25 12:44:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ogv-0002vY-NQ; Wed, 25 Jan 2006 12:44:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ogu-0002vN-JF for enum@megatron.ietf.org; Wed, 25 Jan 2006 12:44:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04668 for ; Wed, 25 Jan 2006 12:42:49 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1oqg-0001qb-Jc for enum@ietf.org; Wed, 25 Jan 2006 12:54:28 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k0PHsD1o002615; Wed, 25 Jan 2006 12:54:13 -0500 Received: from dul1trutkow-l1.verisign.com ([10.99.0.40]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jan 2006 12:44:02 -0500 Message-Id: <7.0.1.0.2.20060125161153.06604278@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 25 Jan 2006 18:43:47 +0100 To: hmowafy@telcordia.com From: Tony Rutkowski Mime-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2006 17:44:03.0096 (UTC) FILETIME=[EE469980:01C621D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: enum@ietf.org Subject: [Enum] regulation of ENUM and VoIP callerID X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1303360851==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1303360851== Content-Type: multipart/alternative; boundary="=====================_285713143==.ALT" --=====================_285713143==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Hala, >from the caller to the called party had to be worked out. I understand >that was all mandated by the FCC and we're not expecting ENUM to be >regulated, but I assure you this topic is extremely sensitive I don't >expect any "exceptions" for ENUM or other. And I'm sure we all agree You provided many sage observations regarding the CallerID draft. As to your observations about regulation, however, you seem not to have accounted for the new Prevent Cyberstalking statutory addition to Title 47 which gives explicit jurisdiction to the FCC to regulate VoIP and the provision of exactly this kind service. Similarly, it does not recognize the adoption by the European Commission of the Data Retention Directive which also mandates a number of capabilities relating to ENUM. An then there are the treaty provisions and statutory requirements in every country concerning the use of E.164 numbers. Minor oversights. :-) --tony --=====================_285713143==.ALT Content-Type: text/html; charset="us-ascii" Dear Hala,


from the caller to the
called party had to be worked out.  I understand
that was all mandated by the FCC and we're not expecting ENUM to be
regulated, but I assure you this topic is extremely sensitive I don't
expect any "exceptions" for ENUM or other.  And I'm sure
we all agree
You provided many sage observations regarding the CallerID draft. As to your observations about regulation, however, you seem not to have accounted for the new Prevent Cyberstalking statutory addition to Title 47 which gives explicit jurisdiction to the FCC to regulate VoIP and the provision of exactly this kind service. Similarly, it does not recognize the adoption by the European Commission of the Data Retention Directive which also mandates a number of capabilities relating to ENUM.  An then there are the treaty provisions and statutory requirements in every country concerning the use of E.164 numbers.  Minor oversights. :-) --tony --=====================_285713143==.ALT-- --===============1303360851== 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 --===============1303360851==-- From enum-bounces@ietf.org Wed Jan 25 16:08:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1rsM-0004K9-Fk; Wed, 25 Jan 2006 16:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1rsK-0004K4-Ti for enum@megatron.ietf.org; Wed, 25 Jan 2006 16:08:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23603 for ; Wed, 25 Jan 2006 16:06:49 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1s28-0001o4-W9 for enum@ietf.org; Wed, 25 Jan 2006 16:18:30 -0500 Received: from [10.10.31.4] (72-254-179-242.client.stsn.net [72.254.179.242]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0PL8eKL032187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2006 13:08:41 -0800 Message-ID: <43D7E8AB.2050304@shockey.us> Date: Wed, 25 Jan 2006 16:07:55 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Mowafy, Hala" Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Mowafy, Hala wrote: > Point well taken about TCAP. And that's why most if not all of the > existing, TCAP-based Name databases have expanded their access to IP > protocols, such as LDAP, SIP, etc.. I'm certainly aware of many of the LDAP products out there for Name Databases. I think the consensus concept inherent in this draft was that since proxy's, SS, CMS's etc will now all have extensive 3271 and DNS support why not use the existing query response mechanism already available to access the Name databases. Adding a LDAP stack _may_ add excessive overhead. In any event the two methods can easily co-exist. The market will decide which protocol to use to access the databases. BTW ..which would you prefer as the URI Tel: or Data: I still have not seen a strong argument on why Tel: is a _bad idea_ , though Data: certainly would work. Thanks again for your comments. > > Hala > > -----Original Message----- > From: richard@shockey.us [mailto:richard@shockey.us] > Sent: Monday, January 23, 2006 6:29 PM > To: Mowafy, Hala > Cc: enum@ietf.org; McCandless, Kevin; richard.shockey@neustar.biz > Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt > > > Mowafy, Hala wrote: > >> Maybe if you help me understand the ultimate goal/vision, I could >> appreciate the I-D a bit more. > > Eliminate or reduce the need for another class of TCAP query. Access to > this data on the SS7 network is cumbersome and expensive. There is a > strong desire on the part of some service providers to migrate to a all > IP query response system. > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 26 06:28:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F25It-0008GL-BE; Thu, 26 Jan 2006 06:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F25Is-0008GG-E1 for enum@megatron.ietf.org; Thu, 26 Jan 2006 06:28:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05391 for ; Thu, 26 Jan 2006 06:27:05 -0500 (EST) Received: from saturn.time-travellers.org ([193.0.0.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F25So-000895-83 for enum@ietf.org; Thu, 26 Jan 2006 06:38:55 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by saturn.time-travellers.org (Postfix) with ESMTP id 48E6D146B87 for ; Thu, 26 Jan 2006 12:28:14 +0100 (CET) Message-ID: <43D8B24D.60707@schiefner.de> Date: Thu, 26 Jan 2006 12:28:13 +0100 From: Carsten Schiefner User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Enum] DENIC Launches Productive Phase of ENUM X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear colleagues, I am happy - and to some extent also proud ;-) - to be able to announce that as of 23 January 2006, DENIC has moved ENUM for +49 - delegations under 9.4.e164.arpa - from trial to regular operation. Please find the full press release at: http://www.denic.de/en/denic/presse/press_73.html Best, Carsten Schiefner _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 26 08:52:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Y2-0002v5-Fu; Thu, 26 Jan 2006 08:52:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Y1-0002uw-6u for enum@megatron.ietf.org; Thu, 26 Jan 2006 08:52:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16425 for ; Thu, 26 Jan 2006 08:50:53 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F27hy-0004oi-6c for enum@ietf.org; Thu, 26 Jan 2006 09:02:43 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2006 05:52:15 -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 k0QDqCWL008496; Thu, 26 Jan 2006 05:52:14 -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.211); Thu, 26 Jan 2006 08:52:10 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 08:52:10 -0500 Message-ID: <43D8D40B.7030805@cisco.com> Date: Thu, 26 Jan 2006 08:52:11 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <43D7E8AB.2050304@shockey.us> In-Reply-To: <43D7E8AB.2050304@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2006 13:52:10.0578 (UTC) FILETIME=[B42E9320:01C6227F] X-Spam-Score: 0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > BTW ..which would you prefer as the URI Tel: or Data: I still have not > seen a strong argument on why Tel: is a _bad idea_ , though Data: > certainly would work. Perhaps its not fair for me to respond to this since I was the one to raise the issue in the first place. The advantage to using Data over Tel is that Data exists and requires no extensions to handle this case. To use Tel for this, it must be extended with a new cnam parameter that is not useful in any other context and in fact will probably add confusion around the use of Tel in other contexts. Note that I am not attached to Data, but it just seemed to be an existing URI that was sufficient for the purpose. Paul > Thanks again for your comments. > >> >> Hala >> >> -----Original Message----- >> From: richard@shockey.us [mailto:richard@shockey.us] Sent: Monday, >> January 23, 2006 6:29 PM >> To: Mowafy, Hala >> Cc: enum@ietf.org; McCandless, Kevin; richard.shockey@neustar.biz >> Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt >> >> >> Mowafy, Hala wrote: >> >> >>> Maybe if you help me understand the ultimate goal/vision, I could >>> appreciate the I-D a bit more. >> >> >> Eliminate or reduce the need for another class of TCAP query. Access >> to this data on the SS7 network is cumbersome and expensive. There is >> a strong desire on the part of some service providers to migrate to a >> all IP query response system. >> >> > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jan 26 12:01:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AV9-0001cz-4Z; Thu, 26 Jan 2006 12:01:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AV7-0001cl-Mh for enum@megatron.ietf.org; Thu, 26 Jan 2006 12:01:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04663 for ; Thu, 26 Jan 2006 12:00:04 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Af6-0004FU-9A for enum@ietf.org; Thu, 26 Jan 2006 12:11:57 -0500 Received: from ([10.20.62.13]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.16497324; Thu, 26 Jan 2006 12:01:03 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 12:01:02 -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] DENIC Launches Productive Phase of ENUM Date: Thu, 26 Jan 2006 12:01:01 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39F86@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] DENIC Launches Productive Phase of ENUM Thread-Index: AcYia9ywMFpaEZtCS7i4tZKrRTfB+wALixmA From: "Livingood, Jason" To: "Carsten Schiefner" , X-OriginalArrivalTime: 26 Jan 2006 17:01:02.0990 (UTC) FILETIME=[16D36AE0:01C6229A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Excellent news, congratulations to Germany! Jason=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Carsten Schiefner > Sent: Thursday, January 26, 2006 6:28 AM > To: enum@ietf.org > Subject: [Enum] DENIC Launches Productive Phase of ENUM >=20 > Dear colleagues, >=20 > I am happy - and to some extent also proud ;-) - to be able=20 > to announce that as of 23 January 2006, DENIC has moved ENUM=20 > for +49 - delegations under 9.4.e164.arpa - from trial to=20 > regular operation. >=20 > Please find the full press release at: >=20 > http://www.denic.de/en/denic/presse/press_73.html >=20 > Best, >=20 > Carsten Schiefner >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 27 09:22:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UUE-0000vM-PJ; Fri, 27 Jan 2006 09:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UUD-0000uw-4E for enum@megatron.ietf.org; Fri, 27 Jan 2006 09:22:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12146 for ; Fri, 27 Jan 2006 09:20:28 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2UeN-00007i-0k for enum@ietf.org; Fri, 27 Jan 2006 09:32:32 -0500 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.16521608; Fri, 27 Jan 2006 09:21:32 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 09:21: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] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Date: Fri, 27 Jan 2006 09:17:44 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39FC8@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Thread-Index: AcYh9HsOb0s4ns5XSnGf2Z/GbTPniQBV659Q From: "Livingood, Jason" To: "Richard Shockey" , "Mowafy, Hala" X-OriginalArrivalTime: 27 Jan 2006 14:21:17.0748 (UTC) FILETIME=[EFFD4F40:01C6234C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > I'm certainly aware of many of the LDAP products out there=20 > for Name Databases. I think the consensus concept inherent in=20 > this draft was that since proxy's, SS, CMS's etc will now all=20 > have extensive 3271 and DNS support why not use the existing=20 > query response mechanism already available to access the Name=20 > databases. Adding a LDAP stack _may_ add excessive overhead. I'd say definitely in my experience. Some of the softswitch & proxy guys we've used prefer to keep in in ENUM/DNS as adding LDAP could take a lot of development time and $. =20 > In any event the two methods can easily co-exist. The market=20 > will decide which protocol to use to access the databases. I think that's essentially the bottom line. It is about several technical alternatives and let the market decide which one hunts. Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 27 09:22:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UUF-0000w1-JO; Fri, 27 Jan 2006 09:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UUE-0000vI-FG for enum@megatron.ietf.org; Fri, 27 Jan 2006 09:22:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12152 for ; Fri, 27 Jan 2006 09:20:30 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2UeO-00007i-DW for enum@ietf.org; Fri, 27 Jan 2006 09:32:33 -0500 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.16521607; Fri, 27 Jan 2006 09:21:32 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 09:21: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] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Date: Fri, 27 Jan 2006 09:20:04 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39FC9@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Thread-Index: AcYigEBTNaEh65ruTVyPBXQZIsllJwAzEKDQ From: "Livingood, Jason" To: "Paul Kyzivat" , "Richard Shockey" X-OriginalArrivalTime: 27 Jan 2006 14:21:17.0967 (UTC) FILETIME=[F01EB9F0:01C6234C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org =20 > The advantage to using Data over Tel is that Data exists and=20 > requires no extensions to handle this case. To use Tel for=20 > this, it must be extended with a new cnam parameter that is=20 > not useful in any other context and in fact will probably add=20 > confusion around the use of Tel in other contexts. > > Note that I am not attached to Data, but it just seemed to be=20 > an existing URI that was sufficient for the purpose. Since the URI is the sub-type of an Enumservice, perhaps we can progress with two subtypes, one as data: and one as tel:. We may also discover some others of interest based on discussion in Dallas as folks consider how (and if) they may use it in practice some day. Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 27 10:43:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VlA-0004V6-6b; Fri, 27 Jan 2006 10:43:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vl9-0004UU-1x for enum@megatron.ietf.org; Fri, 27 Jan 2006 10:43:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20291 for ; Fri, 27 Jan 2006 10:42:02 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VvI-0003g9-KU for enum@ietf.org; Fri, 27 Jan 2006 10:54:06 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2006 07:43:24 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0RFhAL7013413; Fri, 27 Jan 2006 07:43:23 -0800 (PST) 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.211); Fri, 27 Jan 2006 10:43:09 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 10:43:09 -0500 Message-ID: <43DA3F8D.3030500@cisco.com> Date: Fri, 27 Jan 2006 10:43:09 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <6EEEACD9D7F52940BEE26F5467C02C7302A39FC9@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A39FC9@PACDCEXCMB01.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2006 15:43:09.0708 (UTC) FILETIME=[5FBEECC0:01C62358] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "McCandless, Kevin" , richard.shockey@neustar.biz, Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jason, My point about using data is that, if you do so, you do not need to extend tel with the cnam parameter. I prefer not to extend tel unnecessarily, since each added parameter then must be considered by all that use the tel uri. I don't think this particular parameter would have applicability except when tel is used as the output of enum for this particular use of enum. Paul Livingood, Jason wrote: > > >>The advantage to using Data over Tel is that Data exists and >>requires no extensions to handle this case. To use Tel for >>this, it must be extended with a new cnam parameter that is >>not useful in any other context and in fact will probably add >>confusion around the use of Tel in other contexts. >> >>Note that I am not attached to Data, but it just seemed to be >>an existing URI that was sufficient for the purpose. > > > Since the URI is the sub-type of an Enumservice, perhaps we can progress > with two subtypes, one as data: and one as tel:. We may also discover > some others of interest based on discussion in Dallas as folks consider > how (and if) they may use it in practice some day. > > Jason > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 27 13:08:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Y1c-0001q7-62; Fri, 27 Jan 2006 13:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Y1a-0001pz-SS for enum@megatron.ietf.org; Fri, 27 Jan 2006 13:08:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01171 for ; Fri, 27 Jan 2006 13:07:09 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2YBm-0008Nk-IX for enum@ietf.org; Fri, 27 Jan 2006 13:19:16 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 Jan 2006 10:08:27 -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 k0RI8PWH000399; Fri, 27 Jan 2006 10:08:26 -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.211); Fri, 27 Jan 2006 13:08:26 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 13:08:26 -0500 Message-ID: <43DA6199.90506@cisco.com> Date: Fri, 27 Jan 2006 13:08:25 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <6EEEACD9D7F52940BEE26F5467C02C7302A39FC9@PACDCEXCMB01.cable.comcast.com> <43DA3F8D.3030500@cisco.com> <43DA55E0.8070009@shockey.us> In-Reply-To: <43DA55E0.8070009@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2006 18:08:26.0116 (UTC) FILETIME=[AB213C40:01C6236C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "McCandless, Kevin" , "Livingood, Jason" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > Paul Kyzivat wrote: > >> Jason, >> >> My point about using data is that, if you do so, you do not need to >> extend tel with the cnam parameter. I prefer not to extend tel >> unnecessarily, since each added parameter then must be considered by >> all that use the tel uri. > > > Well then I'm assuming you dont really support > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-00.txt > Why have a registry if you want to severely restrict parameters > associated with a tel URI? I'm ok with that. I believe in extensibility, and registries facilitate that. But the existence of a registry doesn't obviate the need to carefully consider what extensions one makes. > I don't think this particular parameter would have > >> applicability except when tel is used as the output of enum for this >> particular use of enum. > > Point taken but .. it is pretty obvious that CNAM is directly related to > a PSTN phone number and as such could/should part of the tel URI which > is our argument That is an argument that it *is* applicable more widely. I think it is a fair subject to discuss. But it then should be portrayed that way, and all the implcations of using it considered. My main problem with it is that calling name is a meaningful datum regardless of what sort of URI describes the address of the caller. Embedding the calling name in TEL would result in one of a few outcomes: - a requirement to embed calling name in other URI forms - at least SIP. (ugh) - using some other scheme to convey the calling name in sip requests, and ignoring the use of cnam in TEL for this purpose. (eliminates general requirement to carry calling name in TEL.) - using the cnam in TEL when the calling address is a TEL, and using a different (non URI-based) method to convey the calling name when TEL is not used. (ugh) We already have enough of a problem with too many ways to represent caller identity (including name) in SIP. We don't need more ways that only work in limited contexts. > Another argument is that I'm not sure many proxy SS vendors know how to > deal with data: but the can parse tel: uri's and associated parameters > which is the flip side of your concern. This whole use of enum for calling name is *new* and will require some special development. In the overall context of things, doing this parsing is trivial. Shouldn't be any harder than parsing a new cnam parameter in TEL. > Either option clearly gets the job done, I'm just not fully convinced a > cnam parameter extension harms the usefulness of the tel: URI and when > its clear that we need a registry of tel: parameters because it is > anticipated there may be N of them. It would be one thing if the parameter was already defined for some other purpose. But I just don't buy adding an *extension* to tel for the sole purpose of using tel to *tunnel* information. In the proposed application the rest of the tel URI isn't used at all is it? Paul >> Paul >> >> Livingood, Jason wrote: >> >>> >>> >>>> The advantage to using Data over Tel is that Data exists and >>>> requires no extensions to handle this case. To use Tel for this, it >>>> must be extended with a new cnam parameter that is not useful in any >>>> other context and in fact will probably add confusion around the use >>>> of Tel in other contexts. >>>> >>>> Note that I am not attached to Data, but it just seemed to be an >>>> existing URI that was sufficient for the purpose. >>> >>> >>> >>> Since the URI is the sub-type of an Enumservice, perhaps we can progress >>> with two subtypes, one as data: and one as tel:. We may also discover >>> some others of interest based on discussion in Dallas as folks consider >>> how (and if) they may use it in practice some day. >>> >>> Jason >>> >> > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 27 15:26:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aBI-0002wJ-19; Fri, 27 Jan 2006 15:26:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aBF-0002w7-Tb for enum@megatron.ietf.org; Fri, 27 Jan 2006 15:26:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11474 for ; Fri, 27 Jan 2006 15:25:17 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2aLT-0004M0-JI for enum@ietf.org; Fri, 27 Jan 2006 15:37:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Date: Fri, 27 Jan 2006 21:27:26 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C47C9@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Thread-Index: AcYjbZp+Skx+pLv6Q2aQee5kroaTSQAEnwpd From: "Stastny Richard" To: "Paul Kyzivat" , "Richard Shockey" X-Spam-Score: 0.8 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "Livingood, Jason" , "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >- a requirement to embed calling name in other URI forms - at least = SIP. >(ugh) I always thought the CNAM is there because there is no other way to transport this in call setup I thought CNAM is the Display Name, so I do not see the problem with SIP here. =20 Or do I misunderstand something here? =20 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Paul Kyzivat Gesendet: Fr 27.01.2006 19:08 An: Richard Shockey Cc: enum@ietf.org; McCandless, Kevin; Livingood, Jason; = richard.shockey@neustar.biz Betreff: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt Richard Shockey wrote: > Paul Kyzivat wrote: > >> Jason, >> >> My point about using data is that, if you do so, you do not need to >> extend tel with the cnam parameter. I prefer not to extend tel >> unnecessarily, since each added parameter then must be considered by >> all that use the tel uri. > > > Well then I'm assuming you dont really support > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-00.txt > Why have a registry if you want to severely restrict parameters > associated with a tel URI? I'm ok with that. I believe in extensibility, and registries facilitate that. But the existence of a registry doesn't obviate the need to carefully consider what extensions one makes. > I don't think this particular parameter would have > >> applicability except when tel is used as the output of enum for this >> particular use of enum. > > Point taken but .. it is pretty obvious that CNAM is directly related = to > a PSTN phone number and as such could/should part of the tel URI which > is our argument That is an argument that it *is* applicable more widely. I think it is a fair subject to discuss. But it then should be portrayed that way, and all the implcations of using it considered. My main problem with it is that calling name is a meaningful datum regardless of what sort of URI describes the address of the caller. Embedding the calling name in TEL would result in one of a few outcomes: - a requirement to embed calling name in other URI forms - at least SIP. (ugh) - using some other scheme to convey the calling name in sip requests, and ignoring the use of cnam in TEL for this purpose. (eliminates general requirement to carry calling name in TEL.) - using the cnam in TEL when the calling address is a TEL, and using a different (non URI-based) method to convey the calling name when TEL is not used. (ugh) We already have enough of a problem with too many ways to represent caller identity (including name) in SIP. We don't need more ways that only work in limited contexts. > Another argument is that I'm not sure many proxy SS vendors know how = to > deal with data: but the can parse tel: uri's and associated parameters > which is the flip side of your concern. This whole use of enum for calling name is *new* and will require some special development. In the overall context of things, doing this parsing is trivial. Shouldn't be any harder than parsing a new cnam parameter in TEL. > Either option clearly gets the job done, I'm just not fully convinced = a > cnam parameter extension harms the usefulness of the tel: URI and when > its clear that we need a registry of tel: parameters because it is > anticipated there may be N of them. It would be one thing if the parameter was already defined for some other purpose. But I just don't buy adding an *extension* to tel for the sole purpose of using tel to *tunnel* information. In the proposed application the rest of the tel URI isn't used at all is it? Paul >> Paul >> >> Livingood, Jason wrote: >> >>>=20 >>> >>>> The advantage to using Data over Tel is that Data exists and >>>> requires no extensions to handle this case. To use Tel for this, it >>>> must be extended with a new cnam parameter that is not useful in = any >>>> other context and in fact will probably add confusion around the = use >>>> of Tel in other contexts. >>>> >>>> Note that I am not attached to Data, but it just seemed to be an >>>> existing URI that was sufficient for the purpose. >>> >>> >>> >>> Since the URI is the sub-type of an Enumservice, perhaps we can = progress >>> with two subtypes, one as data: and one as tel:. We may also = discover >>> some others of interest based on discussion in Dallas as folks = consider >>> how (and if) they may use it in practice some day. >>> >>> Jason >>> >> > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jan 28 16:26:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2xaC-00033x-85; Sat, 28 Jan 2006 16:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2xaA-000306-TZ for enum@megatron.ietf.org; Sat, 28 Jan 2006 16:26:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12591 for ; Sat, 28 Jan 2006 16:24:23 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2xkR-0005vU-Np for enum@ietf.org; Sat, 28 Jan 2006 16:36:44 -0500 Received: from [10.31.13.181] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0SK7vMR017025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2006 12:07:58 -0800 Message-ID: <43DBCEF4.2050204@shockey.us> Date: Sat, 28 Jan 2006 15:07:16 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt References: <6EEEACD9D7F52940BEE26F5467C02C7302A39FC9@PACDCEXCMB01.cable.comcast.com> <43DA3F8D.3030500@cisco.com> <43DA55E0.8070009@shockey.us> <43DA6199.90506@cisco.com> In-Reply-To: <43DA6199.90506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Livingood, Jason" , "McCandless, Kevin" , richard.shockey@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > I'm ok with that. I believe in extensibility, and registries facilitate > that. > > But the existence of a registry doesn't obviate the need to carefully > consider what extensions one makes. Of course ... > >> I don't think this particular parameter would have >>> applicability except when tel is used as the output of enum for this >>> particular use of enum. >> >> Point taken but .. it is pretty obvious that CNAM is directly related >> to a PSTN phone number and as such could/should part of the tel URI >> which is our argument > > That is an argument that it *is* applicable more widely. > > I think it is a fair subject to discuss. But it then should be portrayed > that way, and all the implcations of using it considered. > > My main problem with it is that calling name is a meaningful datum > regardless of what sort of URI describes the address of the caller. > Embedding the calling name in TEL would result in one of a few outcomes: > > - a requirement to embed calling name in other URI forms - at least SIP. > (ugh) > > - using some other scheme to convey the calling name in sip requests, > and ignoring the use of cnam in TEL for this purpose. (eliminates > general requirement to carry calling name in TEL.) > > - using the cnam in TEL when the calling address is a TEL, and using a > different (non URI-based) method to convey the calling name when TEL is > not used. (ugh) > > We already have enough of a problem with too many ways to represent > caller identity (including name) in SIP. We don't need more ways that > only work in limited contexts. OK this is what I was hoping to hear as we've said before the authors of this draft have no "moral objection" to the use of data: however I wanted to make sure there was a rational technical argument for not using tel. I just want to see where rough consensus is. This is clearly a warm discussion topic for Dallas and its useful to flush out the arguments in advance and Paul I thank you for that. > >> Another argument is that I'm not sure many proxy SS vendors know how >> to deal with data: but the can parse tel: uri's and associated >> parameters which is the flip side of your concern. > > This whole use of enum for calling name is *new* and will require some > special development. In the overall context of things, doing this > parsing is trivial. Shouldn't be any harder than parsing a new cnam > parameter in TEL. Well could you check with some folks on Bowers Ave or Richardson TX on that first. :-) Every time I heard some vendor whining on what it would take to actually implement 3761 I kept hearing 18-24 months etc. In fact we put the two parameters tel and sip in the PSTN LNP draft specifically because we were aware some vendors ( who shall remain nameless) were unable to process a tel: URI. > >> Either option clearly gets the job done, I'm just not fully convinced >> a cnam parameter extension harms the usefulness of the tel: URI and >> when its clear that we need a registry of tel: parameters because it >> is anticipated there may be N of them. > > It would be one thing if the parameter was already defined for some > other purpose. But I just don't buy adding an *extension* to tel for the > sole purpose of using tel to *tunnel* information. In the proposed > application the rest of the tel URI isn't used at all is it? A. I'm not sure. Its a highly specialized form of query response that in the PSTN does not occur at call origination only after call setup has begun. Now if the "well known" databases were structured differently and contained multiple parameters then I could see cnam parameter combined with others and then it would be logical to combine in a single tel. > > Paul > >>> Paul >>> >>> Livingood, Jason wrote: >>> >>>> >>>> >>>>> The advantage to using Data over Tel is that Data exists and >>>>> requires no extensions to handle this case. To use Tel for this, it >>>>> must be extended with a new cnam parameter that is not useful in >>>>> any other context and in fact will probably add confusion around >>>>> the use of Tel in other contexts. >>>>> >>>>> Note that I am not attached to Data, but it just seemed to be an >>>>> existing URI that was sufficient for the purpose. >>>> >>>> >>>> >>>> Since the URI is the sub-type of an Enumservice, perhaps we can >>>> progress >>>> with two subtypes, one as data: and one as tel:. We may also discover >>>> some others of interest based on discussion in Dallas as folks consider >>>> how (and if) they may use it in practice some day. >>>> >>>> Jason >>>> >>> >> >> > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jan 29 13:39:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3HSP-0006u7-P8; Sun, 29 Jan 2006 13:39:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3HSN-0006tw-JF for enum@megatron.ietf.org; Sun, 29 Jan 2006 13:39:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17327 for ; Sun, 29 Jan 2006 13:37:38 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3Hco-0007qI-Mg for enum@ietf.org; Sun, 29 Jan 2006 13:50:12 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0TIdTRl003298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Jan 2006 10:39:30 -0800 Message-ID: <43DD0BB8.2050006@shockey.us> Date: Sun, 29 Jan 2006 13:38:48 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [Enum] Less than 60 days and counting to IETF Dallas -Agenda Items? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lets start getting those drafts and requests in now if you want slots. NO ..I do now know what day we have. As of now we have 2. So far. 1. the CNAM draft 2. Infrastructure ENUM Requirements. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum